Uncertainty Is Not a Planning Failure
How Reliable Is a Date When Its Prerequisites Are Still Open?
A specific date creates an immediate sense of commitment. But its value depends on the conditions that must hold for the planned duration to be realistic in the first place.
A transition scenario made this particularly tangible for me. A relatively short period had been planned for knowledge transfer and the subsequent takeover of responsibilities. That timeline was explicitly tied to several prerequisites. One of them was that the required documentation had to be available, complete, and up to date when the transition began.
The timeline therefore only held under certain conditions. Whether those conditions were later met is not the point here. What matters is that the date depended on prerequisites whose own status also needed to be understood.
In the schedule itself, those prerequisites are often far less visible than the date that depends on them. A milestone can be entered with absolute clarity. The schedule alone does not tell us whether all the conditions required to reach it are equally clear.
That creates an important distinction that is easily lost in project plans:
A date can be precise without being reliable.
Its reliability depends on whether the assumptions and prerequisites behind it actually hold.
Why Not Everything in a Plan Should Look Equally Certain
Not every statement in a project has the same level of reliability at the same point in time. For some outcomes, scope, prerequisites, and dependencies are sufficiently clear to make a firm commitment reasonable. For others, information is still missing or risks remain whose impact cannot yet be assessed with confidence.
One example of this principle can be found in PI Planning within the Scaled Agile Framework (SAFe), which distinguishes between committed and uncommitted objectives. The former are explicitly committed to. The latter remain visible as objectives whose achievement still depends on unresolved factors. (Scaled Agile Framework: “PI Objectives”; SAFe.)
The interesting part is not the method itself but the principle behind it: A plan does not have to pretend that every element carries the same degree of certainty.
Uncertainty can be part of what the plan communicates rather than something that has to be explained outside the plan.
What a Reliable Plan Must Not Hide
If dates depend on prerequisites and not every part of a project carries the same level of commitment, the plan should make those differences visible.
Good planning does not try to hide uncertainty in the project plan. It makes clear where uncertainty still exists.
A reliable plan does not need to project the same level of confidence everywhere. It should show which statements are already robust—and which still depend on assumptions, prerequisites, or future developments.
Fünf Fragen, bevor aus Planung Verbindlichkeit wird
Before dates, budgets, or outcomes become firm commitments, it is worth taking a brief look at the foundations beneath them. More detail does not automatically help. The more important question is how reliable the central statements really are at that point in time.
- What do we actually know—and what are we merely assuming?
- Which prerequisites must be met for the plan to work?
- Which dependencies can we influence ourselves?
- Which statements can we genuinely commit to today?
- How will we know early that an assumption no longer holds?
These questions do not require another planning process. They can be asked before a firm commitment, a new forecast, or a significant update to the plan. At those moments, it is worth checking whether only the numbers have changed—or whether the knowledge behind them has changed as well.
None of these questions eliminates uncertainty. Together, however, they help prevent assumptions from quietly becoming facts and possible outcomes from turning into seemingly certain commitments.
What Happens When Change Suddenly Gets Cheap?
AI agents introduce another question: What changes in this logic when drafts and implementation steps can be created, tested, discarded, and rebuilt much faster?
How much do we still need to decide in advance?
