Your programme came back rejected, and the reason given was that it doesn't meet the main contractor's Primavera P6 specification. In rejections of this kind the problem is usually structural rather than a fault in the plan, though both can be true at once. The work now is to rebuild the programme inside their WBS, their activity coding, their calendars and their layouts, so it can be accepted and then reported against every month.
It's seldom a file problem, which is why exporting and re-importing doesn't fix it. Before you commission anything, run the current programme through our free schedule health check so you know whether you're dealing with a structural mismatch, a quality problem underneath it, or both.
Why main contractors reject subcontract programmes
A Tier 1 contractor is assembling dozens of subcontract programmes into one integrated master. That only works if every incoming file shares the same skeleton. If your WBS doesn't map to theirs, your activity IDs collide with someone else's, or your calendars disagree about what a working day is, your programme can't be integrated. It gets sent back.
The rejection notice usually says something short, like "does not comply with the planning specification". It almost never itemises what's wrong. That's the first thing to fix.
Step one: get the specification in writing
Do not start rebuilding until you hold the main contractor's planning specification or programme requirements document. Ask for it by name. If they can't produce one, ask instead for:
- the WBS dictionary, or at minimum the WBS levels they expect you to sit under
- the activity code structures and the allowable values in each
- activity ID conventions, including any prefix reserved for your package
- calendar definitions, including holidays and any shift or possession patterns
- milestone naming and the interface milestones that tie your package to others
- the reporting layouts and filters they'll run against your file
- the acceptance and rejection criteria, and who signs
You can also ask for an exemplar or sanitised programme: a file with the structures intact and the contractual content stripped out, from whoever produced it.
Skipping the specification is how contractors pay twice. Once for the rebuild, and again for the rework after the second rejection.
Step two: separate the plan from the structure
A rebuild has two halves, and confusing them is the commonest mistake.
The plan is your sequence: how your package actually gets built, in what order, with what durations, constrained by what access. That's yours. It shouldn't change because a main contractor wants a different coding structure.
The structure is the container: WBS, activity codes, activity IDs, calendars, percent complete type, scheduling settings, layouts. That's theirs, and it's non-negotiable.
A good rebuild pours your plan into their container without altering the plan. Where the two genuinely conflict, and sometimes they do, that conflict is worth raising in writing rather than resolving quietly. If their WBS has no home for your temporary works, that's a gap in their specification, and you want it on the record before you're held to a programme that hides your critical activities.
Step three: the rebuild itself
Working from the specification and the sample file, the rebuild covers:
WBS. Build their hierarchy, then re-home every activity under the correct node. This is where most of the manual effort sits, and it's the part least amenable to automation, because only someone who understands the work can decide where an activity belongs.
Activity IDs. Renumber to their convention. Keep a mapping table from your old IDs to the new ones. You'll need it the first time someone asks why activity A1020 disappeared.
Activity codes. Populate every code they've specified, with values from their allowable list. Blank code fields are a frequent cause of a failed resubmission, because their filters return nothing.
Calendars. Rebuild to their definitions and reassign every activity. Watch what happens to durations when a five-day calendar becomes a six-day one, or when their holiday list differs from yours. Dates will move. That's not an error, but you need to know which ones moved and why before they ask.
Logic. Re-link inside the new structure and check the network end to end. Open ends, redundant links and out-of-sequence logic tend to surface here, partly because the rebuild exposes them and partly because they were always there.
Constraints. Planning specifications commonly restrict hard constraints. Every date constraint you're carrying needs to be justified or removed, and the ones you keep need a reason recorded against them.
Percent complete type and scheduling settings. Duration, units or physical percent complete, and the scheduling options the receiving system runs: retained logic or progress override, the calendar used for relationship lag, how float paths are calculated. These decide what your file reports once it's inside their environment, and they're easy to miss because nothing looks broken until your numbers disagree with theirs.
Interface milestones. Tie your package to theirs using the milestones they've named, not equivalents you've invented.
Progress and data date. If the package is already under way, the rebuilt programme has to carry actual progress correctly, and the data date has to match the reporting cycle they work to.
Layouts and reports. Build the views their specification asks for and check that each one returns what they expect.
Step four: check it before you send it
Run a quality check before resubmission, not after. At minimum, look at logic completeness, constraint count, negative float, out-of-sequence progress and critical path continuity. If you're on P6 Professional 22.12 or later, the built-in Check Schedule Report gives you a DCMA-aligned view in a few minutes. On earlier P6 Professional releases the same checks are usually run through layouts or a third-party tool.
The point is to arrive at the second submission with the check already done, and ideally with the check results attached. A main contractor who can see that you've tested the file is a main contractor who reads it differently.
What a rebuild won't fix
It's worth being blunt about this.
A rebuild won't make an unrealistic programme realistic. If the durations were optimistic before, they're optimistic afterwards in a nicer container. If the sequence assumes access you haven't been given, restructuring doesn't create the access.
It also won't win you an argument about scope. A conforming programme makes your position legible. It doesn't make your position right.
And it won't survive the month if nobody maintains it. A programme rebuilt to a main contractor's specification has to be updated to that same specification every period, which is a different commitment from a one-off rebuild. Worth deciding up front which one you're buying.
How long it takes
It depends on the size of the package and on whether the specification and a sample file are available. Without them, the work usually gets done twice.
Scope it as a defined deliverable, and agree that acceptance by the main contractor, rather than handover of the file, is the point at which it's complete. That keeps everyone pointed at the outcome that matters.
Before you commission anything
Run the programme you have through the free schedule health check. It takes a few minutes, it's free, and the scored result tells you whether you're looking at a structural rebuild, a quality problem, or a plan that needs rethinking before either.
Planned rebuilds programmes to client and main contractor specifications, with or without a tool conversion in front of it. See MS Project to Primavera P6 conversion and rebuild, or get in touch with the rejection notice and the specification.
Frequently Asked Questions
Can't we just export to XER and send it?
No. An XER carries your WBS, your codes, your calendars and your IDs. Sending it to a main contractor whose structures are different produces a file they can't integrate, which is usually what caused the rejection in the first place. See our note on what breaks when you move a programme between tools.
Our programme is in Microsoft Project. Is that a separate job?
It's the same job with an extra first step. The conversion gets the content into P6; the rebuild gets it into their P6. Treating them as one piece of work avoids making the same structural decisions twice.
The main contractor hasn't given us a specification. What now?
Ask in writing. You can also ask for an exemplar or sanitised programme from whoever produced it, though a live accepted file usually can't be shared. If nothing turns up, agree the structures with their planner before you build, and record the agreement. An undocumented standard is still a standard you'll be measured against.
Does this help with an NEC programme submission?
It helps, but it isn't the same test. NEC4 clause 31.3 lets the Project Manager withhold acceptance on four grounds: the Contractor's plans aren't practicable, the programme doesn't show the information the contract requires, it doesn't represent the Contractor's plans realistically, or it doesn't comply with the Scope. Conforming to a main contractor's coding standard goes, at most, to whether the programme shows the information the contract requires. It doesn't answer the other three. Our NEC4 Programme Acceptance Review is the test built for that question.
Who should do the rebuild, our planner or an external one?
If your planner has the specification, the time and recent P6 experience, they should. Bring someone in when the package is live and they can't stop, or when the file has already been rejected once and you want a fresh reading of why.