Quantum Planning is Planning Without Illusion – More Detail Does Not Make Transformation Predictable
- Kenneth Linnebjerg
- Aug 6
- 11 min read
The Plan Looked Convincing But Reality Was Very Different
Most transformation programs begin with a period of apparent certainty. The objectives have been agreed. Workstreams have been established. Dependencies have been mapped. Resources have been allocated. Milestones have been placed on a timeline, and the steering committee has approved the plan.
Then the transformation meets reality.
A technical interface turns out to be more complex than expected. A regulatory interpretation changes. A critical specialist becomes unavailable. A business unit revises its priorities. A decision expected within one week takes six. Work that appeared independent turns out to depend on the same data, architecture, environment, or business owner.
The plan is updated. More activities are added. Dependencies are redrawn. Dates move, and confidence is temporarily restored.
A few weeks later, the plan is outdated again.
This cycle is familiar in almost every large transformation. Yet organizations continue to govern uncertain work through planning models that assume the future can be specified with sufficient precision. When reality moves away from the plan, the deviation is usually treated as an execution problem. Perhaps the teams did not deliver as expected. Perhaps the estimates were poor. Perhaps governance was not strong enough. Perhaps more detailed planning is required.
But the deeper problem is often simpler:
Prediction has been mistaken for planning. transformation starts falling behind. Several teams are waiting for decisions. Features are not ready when development begins. Architects are overloaded. Test environments arrive late. Operational questions remain unresolved.
The response is often predictable: Add more people.
More developers are brought in. Additional analysts are assigned. Another supplier is asked to contribute. New project managers are added to improve coordination. The underlying assumption is simple: if the transformation is not producing enough output, it must need more capacity.
But after the additional people arrive, something unexpected happens. Meetings increase. Coordination becomes harder. Existing specialists spend more time onboarding and answering questions. More work is started, but the same decisions, architectural issues, and dependencies continue to block progress.
The program becomes larger without becoming faster. The problem is not necessarily that the new people are unqualified. The problem is that transformation capacity is not a generic quantity. It depends on having the right skill, applied to the right type of work, at the right moment.
A Detailed Plan Can Still Be Built on Weak Knowledge
Traditional transformation plans normally describe one expected future. They show one sequence of activities, one expected duration for each activity, and one intended completion date. Risks may be listed separately, but the main schedule still presents a single path as though it were the future that will occur.
This creates an illusion of control.
A plan containing hundreds or thousands of activities looks rigorous. It has dates, owners, milestones, dependencies, status indicators, and reporting structures. But the amount of detail in a plan is not the same as the amount of knowledge behind it. A precisely dated activity may still depend on requirements that have not been clarified, interfaces that have not been validated, skills that have not been secured, and decisions that have not been made.
The planning fallacy helps explain why forecasts so often become optimistic. People tend to imagine how the current work should progress while underweighting evidence from how similar work has actually progressed in the past. [1]
Large transformation programs add another complication. Forecasts are not only used to describe what is likely to happen. They are also used to gain funding, approval, resources, and organizational commitment.
An attractive forecast may therefore survive because it is easier to approve, not because it is more probable. Once the plan has been approved, the forecast gradually changes character. It stops being treated as the current best estimate and becomes a promise. The organization then begins defending the plan even when the evidence supporting it has changed.
More Planning Detail Does Not Remove Uncertainty
When confidence in a transformation plan begins to fall, organizations often respond by adding detail. Large work packages are divided into smaller activities. Dependency logs grow. Teams are asked to provide firmer estimates. Reporting becomes more frequent. Planning workshops multiply. Additional governance forums review the schedule. Some of this may improve visibility.
But more detail only improves predictability when it reflects better knowledge. A twelve-month work package does not become more predictable simply because it has been divided into twenty-four two-week activities. When its requirements, interfaces, skills, ownership, and decision conditions remain unclear, the uncertainty has merely been distributed across more planning lines.
The additional detail also creates maintenance work. Every changed assumption may affect dates, dependencies, resource plans, financial forecasts, risk registers, and steering material. Significant program capacity is then spent synchronizing the plan while the underlying work remains no more ready to move. This creates a particular form of transformation stall.
People are busy updating the representation of the work, but the work itself does not become more executable, more decidable, or more mature.
Transformation systems also contain feedback delays. Decisions are made using information generated by an earlier system state, while their full effects may not become visible until much later. In systems with delayed feedback, repeated interventions can produce instability rather than control. [2]
A static schedule cannot eliminate this behaviour. It can describe what the organization intended to happen. It cannot force delayed information to arrive earlier or remove uncertainty from interactions that have not yet been tested.
Quantum Planning Should Design Adaptability
Planning becomes more useful when it stops trying to describe the future in complete detail and starts designing the conditions required to respond to it.
The planning question changes from:
What exactly will happen over the next eighteen months?
To:
What must be structured now so that we can make good decisions as uncertainty resolves?
This does not mean abandoning direction, investment boundaries, milestones, accountability, or expected outcomes. It means recognizing that all work cannot be known at the same level of precision at the same time. Some work is already shaped and ready for commitment. Some work remains dependent on decisions or technical validation. Some work is still conceptual and should not yet carry a precise delivery promise.
A credible plan must make these differences visible.
Within Transformation Patterns, this starts with representing work as consistent units. Quantum Work provides a stable work object that can move through refinement, decision, delivery, validation, and operation. Without such consistency, transformation plans often mix activities, documents, decisions, business outcomes, system components, and organizational initiatives in the same structure.
These different objects cannot be reliably compared, sequenced, estimated, or governed as though they were equivalent. Work must also be shaped before it is committed.
A large and ambiguous initiative should not receive a precise delivery date merely because a governance process requires one. It should first be decomposed into smaller quanta with identifiable outcomes, dependencies, required skills, ownership, and acceptance conditions.
Phase Contracts then define what must be true before a work quantum moves from one maturity state to another.
A date does not make work ready. Work becomes ready when the required decisions, information, capacity, interfaces, and acceptance conditions are in place. Planning therefore becomes the design of a controlled maturation system. Its purpose is not to eliminate uncertainty at the beginning. Its purpose is to reduce uncertainty before it becomes expensive.
Replace the Single Date with a Confidence Range
A deterministic plan asks for one completion date. A probabilistic plan asks how likely different completion dates are. The difference is important because a point estimate hides several different questions inside one date.
When a plan says that delivery will occur on 1 October, is that date:
an ambition?
a target?
the most likely outcome?
a contractual commitment?
a date with a 50 percent probability?
a date with a 90 percent probability?
Different stakeholders may interpret the same date differently.
A probabilistic forecast makes the uncertainty visible. It might show a 50 percent probability of completion by 1 October, a 75 percent probability by 1 November, and a 90 percent probability by 15 December. The organization can then make an explicit decision about risk.
A regulatory obligation may require a high-confidence commitment. An internal learning milestone may reasonably operate at a lower confidence level.
Reference class forecasting strengthens this approach by comparing the initiative with actual outcomes from similar work rather than relying only on the internal logic of the current plan. [3]
Monte Carlo methods can also combine variations in throughput, duration, dependencies, and other inputs to create a distribution of possible outcomes rather than one apparently certain answer.
These methods do not remove uncertainty - They reveal what uncertainty means for the decision being made.
The governance conversation can then move from:
Why will you not commit to the date?
To:
What confidence level do we require, and what would increase it?
That question may reveal that confidence depends on resolving an interface, reducing the size of a work package, obtaining a delayed decision, securing a scarce skill, or validating an assumption. The forecast becomes connected to the structure of the work rather than negotiated through optimism and pressure.
Smaller Work Produces Faster Evidence
Large work packages contain many hidden uncertainties. Their progress may depend on numerous specialist contributions, handovers, approvals, external conditions, and technical decisions. Because completion is only visible at the end, the organization receives limited evidence while the work is underway.
Smaller and more consistent quanta create more frequent completion events.
This gives the transformation actual evidence about cycle time, throughput, rework, blocked states, and dependency behaviour.
The organization can gradually forecast from observed flow rather than opinion alone.
Queueing theory explains why this matters. Little’s Law connects work in progress, throughput, and flow time. When throughput is relatively stable, increasing the amount of concurrent work increases the time that work spends in the system. [4]
A transformation plan containing a large amount of started work may therefore look ambitious while making each outcome slower and less predictable. Starting more work is not necessarily evidence of stronger planning. It may be the opposite.
A more credible plan limits work in progress, introduces well-shaped work quanta into the system, and updates expectations based on completed work. This is where planning and flow governance become inseparable. The plan defines the intended movement of work. Governance protects the conditions required for that movement.
Feedback Must Be Designed into the Plan
Traditional planning often treats feedback as a correction mechanism. The plan is established first. Reviews are then scheduled to detect whether execution is deviating from it. Adaptive planning treats feedback as part of the planning architecture.
Different planning horizons require different levels of precision and different decision cadences.
Strategic direction may remain stable for several years. Investment boundaries may be reconsidered quarterly. Delivery forecasts may be updated monthly or weekly. Individual work quanta may be validated whenever new evidence emerges. The purpose is not to create more meetings. It is to ensure that decisions are made while they can still change the outcome.
A useful planning review should establish:
what new evidence has emerged
which assumptions or forecasts it changes
which decision is now required
which work should start, stop, continue, or be reshaped
Without these questions, planning reviews become reporting rituals.
The transformation describes variance without changing the conditions that created it.
Research into high-performing delivery organizations shows the value of small batches, short feedback loops, and frequent integration and validation. [5] The same mechanism applies beyond software delivery.
Faster feedback reduces the time during which an incorrect assumption can remain embedded in the transformation plan. A plan that cannot be changed by evidence is not a control mechanism. It is an archive.
Governance Must Protect Outcomes, Not Old Forecasts
Governance should protect intent, responsible investment, and organizational commitments.
It should not protect an outdated planning model merely because that model was previously approved.
Plan worship begins when adherence to the baseline is treated as evidence of control, even after the baseline has lost its connection to reality. Teams then delay reporting problems. Forecasts remain artificially precise. Scope is moved between categories to protect milestones. Contingency is consumed invisibly. Local plans appear healthy while end-to-end flow deteriorates.
A stronger governance model distinguishes between four different things:
Intent: the outcome the transformation is expected to create.
Constraint: the limits within which the work must operate.
Forecast: the current probability-based view of what is likely to happen.
Commitment: the level of outcome and timing risk the organization has consciously accepted.
These are related, but they are not interchangeable.
A forecast may change while the intent remains stable. A deteriorating forecast may require additional capacity, reduced scope, a changed sequence, or a reconsidered commitment.
A constraint may need to be challenged when it makes the intended outcome structurally impossible.
Good governance does not punish forecast changes simply because they are inconvenient. It asks whether the change is supported by evidence and whether the required decisions are being made early enough to protect flow.
Match Planning Precision to Available Knowledge
Not every part of a transformation should be planned with the same level of detail.
Near-term work can be precise because its requirements, dependencies, decisions, interfaces, and skill needs should be increasingly known.
Mid-term work can be represented as shaped options and probable sequences. Long-term work should remain focused on outcomes, boundaries, major dependencies, and alternative paths. This is not an excuse for vague planning. It is a discipline of matching precision to knowledge.
False precision is not rigor. It is uncertainty that has not been acknowledged. Quantized work and phase contracts make this distinction observable. The plan can show not only when work may occur, but whether each quantum is conceptual, shaped, decided, ready, executing, or validated.
A program containing many long-term quanta in early maturity states is not necessarily unhealthy. A program with near-term commitments resting on immature work is.
The most useful planning signal is therefore not how many dates have been assigned.
It is whether the maturity of the work matches the commitment being made.
A Plan Should Learn
Planning without illusion does not mean abandoning ambition or deadlines. It means replacing unsupported certainty with structured learning. A credible transformation plan uses consistent work units. It separates intent, forecast, constraint, and commitment. It uses probability ranges where certainty is unavailable. It limits work in progress. It includes feedback loops that can change decisions. It requires work to satisfy explicit phase conditions before commitment. It updates expectations using actual system behaviour.
Most importantly, it treats changed knowledge as progress rather than failure.
When a hidden dependency becomes visible, updating the forecast is not evidence that planning has failed. The failure would be to preserve the old forecast after its assumptions were disproved. Control does not come from preventing the plan from changing. Control comes from ensuring that the plan changes in a disciplined way when reality changes.
Traditional planning attempts to stabilize the future by specifying it. Structural planning stabilizes the transformation by improving its ability to adapt. The first creates confidence before evidence. The second creates confidence through evidence.
References
Roger Buehler, Dale Griffin and Michael Ross — Exploring the “Planning Fallacy”: Why People Underestimate Their Task Completion Times Link: https://doi.org/10.1037/0022-3514.67.3.366
Why it matters: This research explains why people regularly create optimistic completion forecasts even when previous experience suggests that similar work will take longer.
Donella H. Meadows — Leverage Points: Places to Intervene in a System Link: https://donellameadows.org/wp-content/userfiles/Leverage_Points.pdf
Why it matters: Meadows explains how delays and feedback loops shape system behaviour. This helps readers understand why static plans cannot control transformations whose conditions and consequences emerge over time.
Bent Flyvbjerg — From Nobel Prize to Project Management: Getting Risks Right
Link: https://www.pmi.org/learning/library/nobel-prize-project-management-risks-2545
Why it matters: Flyvbjerg introduces reference class forecasting as an alternative to relying only on the internal assumptions of a project plan, supporting more realistic estimates of cost, time, and risk.
John D. C. Little — A Proof for the Queuing Formula: L = λW
Link: https://doi.org/10.1287/opre.9.3.383
Why it matters: Little’s Law shows the relationship between work in progress, throughput, and flow time. It helps explain why starting more transformation work can reduce predictability and increase delay.
Nicole Forsgren, Jez Humble and Gene Kim — Accelerate: The Science of Lean Software and DevOps
Link: https://myresources.itrevolution.com/id006657092/Accelerate
Why it matters: The research demonstrates the performance value of smaller batches, faster feedback, frequent validation, and observable delivery flow—mechanisms that are equally important in transformation planning.
Comments