A planning specification is the document that tells you how your programme must be built, as distinct from what it must contain. Most UK Tier 1 contractors and major clients have one. Many subcontractors never see it until a submission comes back rejected.
Here's what's usually in one, why each requirement exists, and what fails. If you want to know where your current programme stands against the quality end of this list before you read the rest, put it through our free schedule health check.
1. The EPS and WBS
They'll specify where your project sits in their enterprise structure, and the WBS levels you must build to. Often they'll hand you the top three or four levels and let you decompose below that.
Why: so dozens of subcontract programmes can be rolled into one master without anybody re-mapping them by hand.
Worth knowing: you don't always have to demolish your own WBS to satisfy this. Where the specification is really asking for roll-up and reporting, their hierarchy can often be delivered through activity codes while you keep a native WBS that matches how you actually build the work. Ask whether they want the WBS itself or the reporting it produces. The answer changes how much work this is, and it's the single question most worth asking early.
What fails: burying temporary works, procurement or commissioning somewhere that doesn't exist in their hierarchy, so those activities vanish from their reports. And assuming the two structures have to be the same when codes would have done the job.
2. Activity ID convention
A prefix, a numbering scheme, and sometimes a reserved block of numbers for your package.
Why: IDs must be unique across the integrated programme. Two packages both starting at A1000 can't be merged.
What fails: importing a converted programme and leaving whatever the importer generated.
3. Activity codes
Usually several code structures, each with a fixed list of allowable values. Typical ones are area or zone, phase, discipline, responsibility, subcontractor, and a cost or WBS cross-reference.
Why: codes are how their reports are filtered. If your activities carry no code values, their filters return an empty programme, which looks exactly like you submitted nothing.
What fails: partially populated codes, and invented values that aren't on the allowable list. Both break the report silently.
4. Calendars
Named calendars with defined working weeks, holidays, and any shift, possession or seasonal patterns.
Why: durations only mean something against a calendar. A twenty-day activity is four weeks or three and a bit depending on the working week.
What fails: keeping your own calendar because the dates look better on it. Expect dates to move when you reassign, and expect to explain which ones.
5. Duration limits
Many specifications cap activity duration, commonly somewhere around a working month, with exceptions allowed for level-of-effort and procurement activities.
Why: long activities hide progress. You can't tell whether a sixty-day activity at 40 per cent is ahead or behind.
What fails: a handful of very long activities covering the parts of the work nobody wanted to plan properly.
6. Logic rules
Usually: finish-to-start relationships preferred, no leads (negative lag) at all, lags limited and justified, and every activity to have at least one predecessor and one successor apart from the true start and finish.
Why: a network with open ends doesn't calculate a meaningful critical path, and leads produce dates that can't be defended.
What fails: start-to-start chains used as a substitute for planning the sequence, and negative lags used to pull dates that logic wouldn't produce.
7. Constraints policy
Hard constraints are typically restricted to contractual dates only, and every one has to be justified in writing.
Why: a constrained programme doesn't respond to change, so it can't be used to assess delay. That matters to both parties.
What fails: constraints inherited from a conversion or used to hold dates that logic no longer supports.
8. Milestones and interfaces
A named set of milestones you must include, usually including access dates, key dates, sectional completion and the interfaces where your package hands over to another.
Why: interfaces are how the master programme knits packages together, and they're the first thing examined when something slips.
What fails: using your own milestone names, or omitting the interfaces because they're someone else's responsibility.
9. Progress and the data date
The reporting cycle, the data date, the cut-off for progress collection, and the rules for recording actual start and finish.
Why: if packages report to different data dates, the integrated programme is meaningless.
What fails: submitting with last period's data date, and recording percentage progress without actual dates.
10. Resource or cost loading
Sometimes required, sometimes explicitly forbidden. Where required, they'll specify the resource dictionary and whether loading is by labour hours, by cost, or both.
Why: if they intend to run earned value, every package has to load the same way.
What fails: resource-loading to your own dictionary, which can't be aggregated.
11. Quality thresholds
Increasingly, specifications set numeric limits, usually borrowed from the DCMA 14-point assessment. The commonly cited thresholds are:
| Check | Typical threshold |
|---|---|
| Activities missing a predecessor or successor | 5 per cent or fewer |
| Leads (negative lag) | none |
| Lags | 5 per cent or fewer of relationships |
| Finish-to-start relationships | 90 per cent or more |
| Hard constraints | 5 per cent or fewer |
| Negative float | none |
| High float (total float above 44 working days) | 5 per cent or fewer |
| High duration (baseline duration above 44 working days) | 5 per cent or fewer |
| Critical Path Length Index (CPLI) | target 1.00, 0.95 accepted as tolerance |
| Baseline Execution Index (BEI) | 0.95 or above |
Two points of detail worth knowing: high duration is normally measured on baseline duration rather than remaining, and CPLI's stated target is 1.00, with 0.95 treated as the working tolerance. Clients often adjust the whole set, so read the specification rather than assuming the standard one. Our guide to the DCMA 14-point assessment explains what each check is testing for.
What fails: submitting without running the checks. If you're on P6 Professional 22.12 or later, the built-in Check Schedule Report covers most of this in minutes. P6 Web and EPPM have the native Check Schedule report. On earlier P6 Professional releases the same checks are usually run through layouts or a third-party tool.
12. Deliverable format
The file type, the P6 version to export from, whether a PDF or native layout is required alongside, and the file naming convention.
Read which file type they've actually asked for. Some clients now specify P6 XML rather than XER, because an XER drags a lot of global data across with it and pollutes the receiving database. Others still want XER because it's what their process has always taken.
Why: XER files are version-sensitive. A file exported from a newer P6 than the receiving system can fail to import cleanly.
What fails: sending an XER from a version they can't read, and file names that don't identify the package or period.
13. The narrative
Specifications commonly require a written narrative with each submission: progress in the period, changes to logic or duration, the critical path and how it has moved, risks and mitigation.
Why: the programme shows what changed. The narrative says why.
What fails: a narrative that describes the bar chart instead of explaining it, and one that quietly omits the logic changes.
14. Submission and acceptance
Dates, the route, who reviews, how long they have, and what happens if they don't respond.
Why: because acceptance is a contractual event, not an administrative one.
On an NEC4 contract this sits alongside the contract's own machinery. Clause 31.2 lists what the programme must show, including planned Completion, the order and timing of operations, provisions for float, time risk allowances, health and safety requirements and the procedures set out in the contract, and the dates the Contractor needs access and things provided by others. Clause 31.3 gives the Project Manager four grounds for withholding acceptance: 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 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 built around them.
If you haven't been given a specification
Ask for it in writing, by name. If one genuinely doesn't exist, ask for an exemplar or sanitised programme instead: structures intact, contractual content stripped, from the contractor that produced it. Asking for a live accepted programme tends to get a no, and reasonably so, because it carries commercial information that isn't yours to see. An exemplar answers most of the fourteen points above, and the request itself leaves a record of what you were told.
An undocumented standard is still a standard you'll be measured against. Get it written down before you build, not after the rejection.
Check before you submit
A large share of rejections are structural, and structural problems are the easiest kind to catch before you submit. Put your programme through the free schedule health check before it goes anywhere, and if the result raises questions, get in touch.
Frequently Asked Questions
What's the difference between a planning specification and the contract programme requirements?
The contract says what the programme must contain and when it must be submitted. The planning specification says how it must be structured so it can be integrated and reported. You have to satisfy both, and they're assessed by different people.
Our programme was rejected but nobody said why. What do we do?
Ask for the rejection reasons against the specification, clause by clause. If the contract is NEC, ask which of the four clause 31.3 grounds is being relied on. A rejection without a stated ground is difficult to fix and difficult to defend.
Do we have to rebuild, or can we just add the codes?
Depends how far apart the structures are. If the WBS matches and only coding is missing, it's a data exercise. If the WBS, IDs and calendars all differ, it's a rebuild. It's always worth asking whether they want the WBS itself or the reporting it produces, because codes will often satisfy the second. Our note on what a P6 specification rebuild involves sets out the difference.
Will meeting the specification get the programme accepted?
It removes the structural grounds for rejection. It doesn't make an unrealistic plan realistic, and on an NEC contract that's an independent test.
How do we check the programme before we submit it?
Run the quality checks in section 11. Our free schedule health check will score a file against the DCMA 14-point assessment in a few minutes, free, and you can attach the result to the submission.