A broken Primavera P6 schedule is one you can no longer trust to tell you what will happen next. The fix isn't to drag activities around until the finish date looks right. It's to diagnose why the logic stopped working, rebuild it properly, and put governance in place so it doesn't happen again. Below is the process we use when a client hands us a programme that's stopped behaving.
What Does a “Broken” P6 Schedule Actually Mean?
It's not one thing. It's usually a combination of:
- Negative float on activities that shouldn't have any, meaning the schedule is already telling you it can't hit the date it's showing.
- Open ends: activities with no predecessor or successor, so the tool has nothing to calculate against.
- Out-of-sequence progress, where actual reported progress contradicts the planned logic.
- Hardcoded constraints standing in for real logic, so dates move because someone typed a new one in, not because the plan changed.
- Baseline drift, where the current schedule has quietly diverged so far from the baseline that variance reporting is meaningless.
- A critical path that jumps around from update to update, or doesn't exist in any coherent form at all.
If you want an objective read on which of these apply, run a DCMA 14-point assessment first. We've written a full walkthrough of that check with a P6 example: The DCMA 14-Point Schedule Assessment, Explained. It turns “this schedule feels wrong” into a scored list of exactly what's wrong, which is where recovery should start.
Recovery Schedule or Revised Schedule: Which Do You Need?
This distinction gets muddled online, and it matters before you touch a single date.
A recovery schedule keeps the original contractual completion date and re-plans how the remaining work gets there. It's an acceleration and re-sequencing exercise, not a renegotiation.
A revised schedule accepts that the completion date itself needs to move, usually because delay has already eaten the float and no realistic re-sequencing gets you back to the original date.
Confusing the two causes real problems on UK contracts. Under NEC4, for example, a revised programme submitted under clause 32 needs to show the effect of implemented compensation events on the dates, not paper over them with an optimistic recovery plan the contract administrator won't accept. Decide honestly, before you start rebuilding, which one you're actually producing. If the answer isn't clear yet, that's a sign you need the diagnosis in step one before committing to either.
Step 1: Diagnose Before You Touch a Single Date
Resist the urge to start dragging bars. Run the health check first (the Free P6 Check tool does this from an .xer or .xml export in your browser, nothing uploaded to a server) and get a clear list of:
- Percentage of activities with logic ties missing or with only one predecessor/successor.
- Percentage out-of-sequence.
- Number and type of constraints in use, and how many are hard constraints overriding logic.
- High duration activities and the proportion of the programme they represent.
- Where the calculated critical path actually runs, and whether that matches what the team believes is critical.
This tells you whether you're dealing with a logic problem, an update discipline problem, or both. They need different fixes.
Step 2: Rebuild the Logic, Not Just the Dates
Once you know where the gaps are:
- Remove or downgrade constraints that are standing in for real logic. A “Start On” constraint that's been quietly overriding the plan for six months isn't a constraint, it's a fiction.
- Restore missing predecessor and successor links so every activity (bar the true start and finish milestones) is properly tied in.
- Check for overused Start-to-Finish relationships. They're rarely the right tool and usually a sign someone was forcing a date rather than modelling the work.
- Break down large, unbroken deliverables. An activity running twelve weeks with no intermediate milestone hides whatever's actually going wrong inside it.
- Fix out-of-sequence progress properly, either by adjusting the logic to reflect how work is genuinely being executed, or by correcting progress entries that don't match reality. Don't just let P6's retained-logic or progress-override settings paper over it without understanding which one you're applying and why.
This is the slow part, and it's the part that actually determines whether the recovery plan is credible or just cosmetic.
Step 3: Re-Baseline With Governance, Not Guesswork
Once the logic is sound and the plan is genuinely achievable, set a new baseline. But do it with a paper trail:
- Get formal sign-off on the recovery or revised programme before it becomes the new baseline. On NEC contracts this typically means submission to and acceptance by the Project Manager, with reasons recorded if it's rejected.
- Keep the old baseline available for comparison. You'll need it to explain what changed and why, especially if there's a later dispute about entitlement to time.
- Record the change control narrative alongside the schedule file, not just in someone's memory. What changed, who approved it, when.
Silent re-baselining, where the finish date resets without anyone formally agreeing it, is how schedules end up broken again within a month.
Step 4: Stress-Test the Recovery Plan Before You Submit It
A recovery plan that only works on paper isn't a recovery plan. Before it goes anywhere near a client or contract administrator:
- Sense-check resource loading against what's actually available. A plan that assumes three extra gangs nobody has hired isn't a recovery plan, it's a wish list.
- Run a light-touch schedule risk review on the critical and near-critical paths. Where does the plan have zero contingency against activities that have already slipped once?
- Walk the critical path with the site or delivery team and ask whether it matches their understanding of what's actually driving the finish date. If it doesn't, the logic still has a gap somewhere.
Step 5: Stop It Happening Again
Recovery is wasted effort if the schedule drifts back into the same state in eight weeks. Put a light monthly discipline in place: a quick DCMA-style check at each update, a rule that constraints need a documented reason, and a named person who owns baseline changes rather than everyone editing freely. None of this needs to be heavy. It needs to be consistent.
When Should You Bring in Outside Help Instead of Fixing It Yourself?
If the diagnosis shows isolated issues, a competent in-house planner with a clear afternoon can usually fix it. Bring in outside help when the schedule underpins a live claim or a contractual submission, when the in-house team is too close to the programme to be objective about what's gone wrong, or when the recovery plan needs to stand up to independent scrutiny from a client, funder or the other side of a dispute. That's usually a sign the fix needs a second set of senior, independent eyes rather than another attempt from inside the same team that built the problem.
Planned works as that second set of eyes: Primavera P6 consultancy, remote-first, across construction, energy and infrastructure. If you'd rather have someone run the diagnosis and rebuild for you, book a free consultation, or start with the Free P6 Check to see where things stand.
Frequently Asked Questions
What's the difference between a recovery schedule and a revised schedule in P6?
A recovery schedule keeps the original contractual completion date and re-sequences the remaining work to hit it. A revised schedule accepts that the completion date itself has to change, usually because the float available for recovery has already gone. Which one you're producing should be decided before you start rebuilding, not discovered halfway through.
How do I know if my P6 schedule needs recovery?
Run a DCMA-style 14-point check. High out-of-sequence percentages, widespread missing logic, excessive hard constraints and negative float on activities that shouldn't have any are the clearest signs. If several of those show up together, the schedule needs a proper diagnosis and rebuild, not just a date shuffle.
Can I recover a schedule without changing the completion date?
Sometimes, if there's enough float left in the plan and the remaining work can genuinely be re-sequenced or accelerated. If the float's already gone, forcing the original date through the tool just produces a schedule that looks fine and fails on site. At that point you're looking at a revised schedule, not a recovery schedule.
How long does it take to recover a broken P6 schedule?
It depends on the scale of the logic problems, not the size of the project. A schedule with a handful of missing ties and a few stray constraints can be fixed in a day or two. One with widespread out-of-sequence progress and no clear critical path usually needs a proper diagnostic pass first, then a rebuild measured in days rather than hours.
Does a recovery schedule need approval from the client or contract administrator?
On most standard forms, yes. Under NEC4, for example, a revised programme goes to the project manager for acceptance under clause 32, with reasons recorded if it's rejected. Even where the contract doesn't strictly require it, getting formal sign-off before a recovery plan becomes the new baseline protects you if the recovery doesn't hold and the dates are challenged later.