Progressive Elaboration: Why Good Plans Become More Detailed Over Time
Every project knows less at the start than at any later point, which is an obvious statement with an awkward consequence: the plan produced when least was known is the one people remember, and every subsequent version looks like a revision of a promise. Progressive elaboration is the principle that plans legitimately gain detail as knowledge arrives, and the practical difficulty is entirely in demonstrating that gaining detail is not the same as changing the deal.
The PMBOK® Guide Eighth Edition treats this as a basic property of planning rather than a technique to be applied, which is right, and it leaves the project manager with the harder half of the problem: showing the difference to people who have a number in their heads from month one.
Detail increases; the commitment does not drift
Elaboration adds specificity to the same commitment. The plan said the building would be handed over in March and that the fit-out would be designed to the client's standard. Nine months later it says which contractor, in what sequence, with what acceptance regime. Nothing has been added to what the project will deliver; the description has become usable.
Creep adds commitment without a decision. The plan said the same thing, and somewhere in the detail a second floor has appeared, or an interface to a system nobody mentioned, or an acceptance standard higher than the one agreed. The tell is that nobody can point to when it was decided or who approved it. One question separates the two, and it is worth asking of every plan revision: is anything here that we did not previously agree to deliver? Where the answer is yes, that is a change, and it goes through the change process even if it arrived inside an elaboration.
Where elaboration shows up beyond the schedule
Estimates narrow. An early estimate is a range and a late one is a number, and the narrowing should be visible and explainable: the range was plus or minus forty per cent at concept, plus or minus fifteen after design freeze, plus or minus five once the subcontracts were let. Reporting the same single figure throughout hides the whole of that progression and makes every later movement look like an error.
Risks become specific. A risk that begins as integration may be difficult becomes, six months on, the message format for the third-party feed is undocumented and the vendor has quoted eleven weeks for a specification. That is the same risk, elaborated, and it is now something somebody can act on. Registers where entries never change their wording are registers nobody is working.
Requirements become testable. What starts as the system must support offline working ends as the fifteen operations that must work offline, the reconciliation on reconnection, and the conditions under which a conflict is flagged. Elaboration is how a requirement acquires acceptance criteria, and a requirement that never elaborates will be disputed at handover.
An integration programme accused of moving the goalposts
A defence integration programme was fitting a new mission system into an existing platform. At concept, the mounting arrangement was described as a set of brackets to be designed to the platform's structural standard, and the cost estimate carried a wide range.
Through design, the brackets elaborated the way engineering things do: a printed plastic check piece to prove the envelope, a machined prototype that came back with two holes in the wrong place and a hand-marked correction, then a qualified part with a serial tag. The estimate narrowed as this happened, and at the third governance meeting it had risen within its own range and become a firmer number.
The programme board's reaction was that the cost was increasing and the requirement was moving. Neither was true, and the programme manager had no way of showing it, because every previous report had carried a single point estimate with no range and no record of what had been elaborated between one report and the next.
The recovery was a one-page addition to the report. Each significant line carried its estimate as a range, the point in the programme at which that range was expected to narrow, and a short note of what had become better understood since the last meeting. The first time it was presented, the board could see that the bracket cost had moved within its stated range and that the range itself had halved, which is a programme behaving well.
Two meetings later the same page caught something real. A line in the interface scope had elaborated from one feed to three, and the note had to say that this was new. It went to change control, was approved with funding, and nobody accused the programme of anything, because the page had spent two meetings establishing what honest elaboration looked like.
Saying it to governance
Report ranges from the beginning and narrow them at named points. A governance group that has been given a single number at concept will treat every later figure as a deviation from it. One that has been given a range and the date at which it narrows is participating in the actual state of knowledge, and it will not be surprised.
Keep a short record of what became clearer. A few lines per reporting cycle, saying what is now understood that was not before, does more to protect a project from accusations of drift than any amount of explanation at the time. It also makes the genuine changes visible, which is the point, because those are the ones that need a decision.
For a PMP® candidate, the practical reading is that increasing detail is expected and increasing commitment is not, so a scenario about a plan that keeps changing is asking which of the two is happening. A response that freezes the plan to stop the movement prevents the project from learning. Situations where the distinction is genuinely arguable are the ones a structured PMP exam preparation course lingers over.
Compare the current plan with the version from six months ago and sort the differences into two piles: things described better, and things added. The second pile should be small and every item in it should have a decision behind it. Anything in that pile without one is a change that happened to you, and it is worth finding out how.
Interested in going further?
Defending a plan that has legitimately changed shape, in front of people holding the first version, is a regular and underrated part of the job. Omega's PMP® Exam Preparation works through planning as a process of narrowing uncertainty in public.
Progressive elaboration runs through the planning material of the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A168: Business Case vs Project Charter: What’s the Difference?
A169: Assumption Log vs Risk Register
A170: Decision Log: The Forgotten Project Control
A171: Change Log vs Issue Log
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
