Schedule vs Plan
Most distressed projects didn't have a bad schedule. They had a schedule that everyone treated as the plan.
A schedule and a plan are not the same thing.
Most distressed projects I’ve seen didn’t have a bad schedule. They had a schedule that everyone treated as the plan, until reality forced the gap into the open — usually three or four months in, usually after the slip had already compounded into something that couldn’t be quietly recovered. The schedule was fine. The plan had stopped existing somewhere along the way, and nobody noticed because the schedule was still being updated.
This is a piece about that gap. What a schedule actually is, what a plan actually is, how the two come apart, and what to do about it before the steering committee starts asking why the curves are flat.
A schedule is a document. Dates, dependencies, milestones, durations, the critical path mapped across the work breakdown structure. It lives in Primavera or MS Project. It tells you what was agreed at a point in time.
What that flat description leaves out is that a schedule is also a contract. It encodes commitments — to clients, to internal teams, to the cost department, sometimes to legal counsel. It has reporting weight. It’s the artefact that gets reviewed at steering committees, exported into status decks, referenced in dispute correspondence, and audited when things go wrong. The weight is the point. Schedules ossify because that’s their job; they’re supposed to be the stable reference that everything else moves around.
The same weight is also why they go stale. Once a baseline is set, changing the schedule is politically expensive even when the underlying work has clearly moved. Re-baselining is a conversation, sometimes a difficult one, and most teams will defer it longer than they should.
The schedule is the artefact. It’s not the work.
A plan is the team’s shared understanding of how the work actually gets done. It’s a different thing from the schedule, and it lives in a different place — in the engineers and leads who know what’s happening this week, in the working sessions where sequencing actually gets decided, in the conversations between disciplines about what’s blocked and what isn’t.
The plan covers things the schedule can’t carry at its level of resolution. Who’s actually doing what, on what equipment, with what dependencies on whom else. The order the work flows in, including the small handoffs and parallel tracks that don’t appear at a milestone level. Where the slack genuinely is, versus where the schedule shows it — and these are usually different. Which dependencies are real, and which are conventions that can be relaxed under pressure.
The plan is what a senior engineer means when they say we can probably get Stage 3 starting before Stage 2 finishes if we sequence the deliverables right. None of that is in the schedule. It’s never going to be in the schedule. The schedule is a representation of the plan, deliberately compressed for reporting and contractual purposes — and the compression is lossy.
A plan can survive a missing document. A schedule cannot survive a missing plan.
In my experience there are three patterns. They look the same from the outside — schedule slipping, project drifting, milestones quietly moving — but they’re different failures, and they have different fixes.
The first is when the plan changes faster than the schedule. The team adapts to a delay, an early delivery, a client request, or a discovery in the work itself, and the working plan shifts within a week. The schedule reflects the change at the next monthly update, if at all. By the time the schedule catches up, the plan has shifted again. The schedule is now permanently a step or two behind the actual work, and the gap keeps widening.
The second is when the plan was never built. The schedule was constructed from a template, a sales commitment, or an estimate from a comparable project — but the team that has to deliver it never sat down to build a real understanding of the sequence. There’s no plan. There’s only a schedule and the assumption that the plan will materialise as the work progresses. It usually doesn’t.
The third is the one I see most often, and it’s the most damaging. The schedule is being used as the plan. The team treats milestones as instructions instead of as targets. People do work because the schedule says so, not because the work makes sense to do now. The schedule has stopped being a measuring instrument and become a script — and once that happens, the team’s ability to think for itself about the sequence quietly degrades.
When the schedule and the plan diverge, the project controls function gets slowly hollowed out, even if nobody notices for a while.
Status reports become accurate but useless. The schedule reflects what happened, not what should happen next. Steering committees read the report, see the slip, ask why, and the only honest answer is it just slipped — because the document doesn’t carry enough resolution to expose the lever. Nobody can intervene because nobody can see what to intervene on.
The risk register goes quiet at the same time. The risks the team is actually navigating — the ones the working plan is built around — never make it into the formal log, because the formal log is keyed to the schedule, and the schedule has stopped being where the real plan lives. The team is managing risk. The project controls function isn’t seeing it.
And recovery becomes much harder when you finally need it. You can’t recover a project to its schedule if the plan that produced the schedule no longer exists. You’re recovering to a document, not to a delivery path. By the time someone tries to pull the project back, half the work has to be reconstructed before any meaningful recovery plan can be written.
The discipline isn’t complicated. It’s just unglamorous, and it has to be done at moments when there’s pressure to do almost anything else.
Build the plan first, schedule second. Sit with the leads who will actually deliver the work and map the real sequence — the real dependencies, the real slack, the real handoffs. The schedule is the artefact you produce from the plan, not the input to it. If you find yourself building the schedule before the plan exists, the project is already at risk, regardless of what the dates say.
Re-baseline when the plan moves, not when the schedule slips. The most common discipline failure I’ve seen is updating the schedule to reflect slippage instead of updating it to reflect that the underlying plan has changed. The first is reporting. The second is project controls. They produce the same numbers in the short term and very different outcomes over six months.
Accept that the plan will live partly in conversation, and that this is fine. You can’t write down everything that’s in the team’s shared understanding, and it’s not the project controls function’s job to try. The job is to make sure the schedule remains a faithful enough representation of the plan that decisions made from it are good decisions.
The schedule keeps the plan honest, only if you keep the plan first.