The myth of the perfect plan: framing for uncertainty, not against it

The perfect plan does not exist, and the quest for the perfect plan costs more than the uncertainty you are trying to eliminate.

The trap of the frozen plan

The more detailed a plan is early in a project, the faster it becomes wrong. Detail reassures the sponsor, but it does not protect delivery, it just makes it more visible when things go off track.

Framing to absorb uncertainty

• Plan in fine detail only the next 2 to 4 weeks
• Keep the rest as macro milestones, revised at each iteration
• Explicitly provision a risk margin, visible to the sponsor, not hidden in the estimates (a project risk matrix helps size it)

What it changes in steering committees

A plan that is honest about its uncertainty is easier to defend than a falsely precise plan that ends up slipping without explanation. Client trust is built on the regularity of revisions, not on the illusion of initial certainty.

The cone of uncertainty, with figures

This is not just a gut feeling from the field: the "cone of uncertainty", popularised in software project management by Steve McConnell, describes this phenomenon precisely. In his white paper on the cone of uncertainty (Construx, 2010), he states that at the initial concept stage, an estimate produced by a skilled estimator can be off by a factor of 4 in either direction: from 0.25 times to 4 times, a ratio of 16 between the low and the high assumption. And the cone describes the best case: you can do worse, not better.

The most useful passage for a project manager lies elsewhere. McConnell points out that the cone does not narrow by itself over time: it only narrows when you make decisions that remove variability, such as fixing the product vision (including what you will not do), then the requirements. He derives a commitment rule from this: committing at the concept or product definition stage means accepting an error of a factor of 2 to 4, whereas a meaningful commitment becomes possible at around 30% of the project. Wanting a detailed, reliable plan from day one amounts to demanding a precision that the very nature of the work does not yet allow.

The practical consequence: a plan's level of detail should grow as the project progresses, not be fixed once and for all at the framing stage. What really gets fixed during the first two weeks of framing are the assumptions, not the dates. A plan that is macro over 6 months and detailed over 3 weeks is not an incomplete plan, it is a plan that is honest about what can actually be known at any given moment.

Planning in waves: detail 3 weeks, set milestones for 6 months

The technique has a name in project management frameworks: rolling wave planning. You detail near-term work at task level, keep distant work at work-package level, and break it down again at the end of each wave. Nothing about it is reserved for agile: I also apply it to fixed-price projects with a signed specification.

What a rolling wave plan looks like

Horizon	Level of detail	Revision
0 to 3 weeks	Tasks estimated in days, named owners	Every week
1 to 3 months	Functional work packages estimated as a range	At the end of each iteration
Beyond 3 months	Major milestones and deliverables, no firm date	Every month, in committee

What matters is not the exact breakdown. It is that every line of the plan shows its level of confidence. A milestone six months away presented with the same precision as a task next week lies through its form, even if the date is reasonable.

Where to put the risk margin

The margin should not be scattered across every estimate, where nobody sees it and everyone uses it up without saying so. I group it into a single provision, tied to the identified risks, whose consumption the sponsor tracks. When a risk materialises, you draw on the provision and announce it. When a risk disappears, you hand back the corresponding margin. Sizing starts from the risks themselves: probability, impact in days, and what you will do if it occurs.

Presenting a plan as a range to the sponsor

A sponsor does not ask for a range, they ask for a date. I give them two: the one by which I estimate I have a one in two chance of finishing (P50), and the one by which I have four in five (P80). The gap between the two is the useful information. It measures the remaining uncertainty and should shrink from one committee to the next; if it stalls, that is a more reliable signal than any percentage of completion.

In committee, the wording matters. "Delivery will take place on 15 March" is a promise. "At this stage, delivery falls between the end of February and the end of March, and I will be able to narrow it after acceptance testing of the first work package" is information, and it holds up against the first unexpected event.

What I refuse to promise at the framing stage

• A firm end date before the scope has been decided, including what will not be done
• A detailed plan beyond the first wave
• An estimate without a range, even when the client demands "a single figure"
• A hidden margin: if it exists, it is written down and it has an owner

This refusal is not a pose. What I do not promise at the framing stage, I will not have to renegotiate in a hurry in the third month.

A good plan is not the one that predicts everything, it is the one that survives the first unexpected event without losing its credibility.

This kind of honest framing is what I put in place as a Delivery Manager: a plan that survives the first unexpected event rather than one that ignores it.

Further reading: framing debt costs more than technical debt

Frequently asked questions

What is the cone of uncertainty?

It is a model that describes the possible error in an estimate depending on how far a project has progressed. At the initial concept stage, Steve McConnell puts it between 0.25 times and 4 times the final value. It only shrinks as scope decisions are made.

Do you still need a detailed plan at the start?

Yes, for the first few weeks only. The rest is held as milestones and ranges, revised at each iteration or each committee.

How do you justify a risk margin to a sponsor?

By tying it to named risks, with a probability and an impact, and by showing how much of it has been used at each committee. A margin justified risk by risk is far easier to defend than a flat percentage added at the bottom of the plan.