Or why precise dates do not necessarily make a plan reliable.
The Illusion of Precision
A project plan creates something complex initiatives often lack: visibility. Milestones are set, responsibilities assigned, dates entered. In a steering committee, you can show where the project stands and what is supposed to happen next. The larger the initiative, the more important that sense of orientation becomes.
The more important question is how reliable that order really is. A plan can look highly precise while some of its foundations are still unresolved. Which dependencies do we actually understand? Which assumptions are we already treating as facts? And how dependable are dates when critical prerequisites will only be clarified later?
Aus der Praxis
For several years, I was involved in a major transformation program at an international telecommunications group in Germany—at the time, one of the largest transformation programs in the German corporate landscape.
Business processes, the organization, and an IT landscape that had evolved over many years were to be fundamentally renewed and significantly standardized.
In a program of that scale, the demand for clear roadmaps, milestones, and dates emerges quickly. It also made one thing particularly clear to me: much of the most important planning work happens before those dates are set—when teams establish what is already understood, where dependencies lie, and which prerequisites still need to be clarified.
I will return to several observations from that project environment throughout this article.
When Precision Is Mistaken for Reliability
The first article in this series focused on what should be clarified before a project truly gets under way: a shared understanding of the objective, a sufficiently concrete picture of the intended outcome, and the key constraints surrounding the work.
But even once those points are clear, another question remains: How does that understanding become a plan whose milestones and dates are genuinely reliable?
The desire for concrete plans is understandable. Dates provide orientation, budgets can be allocated, resources reserved, and expectations aligned across sponsors, management, and project teams. In large initiatives, that level of commitment is essential if many people are to move in the same direction.
The problem begins when the precision of the plan is confused with the quality of the assumptions beneath it. A detailed schedule can look highly convincing even when important assumptions, dependencies, or relevant experience have not yet been tested rigorously enough.
The Outside View
One reason may be a human tendency identified by Bent Flyvbjerg and a team at the University of Oxford in their research on large IT projects. The researchers analyzed data from more than 1,300 projects and examined 219 of them in greater depth. They found that the more strongly decision-makers perceived their own project as unique, the worse it performed on average. Each additional point on the ten-point uniqueness scale was associated with an average increase of five percentage points in cost overruns. (Flyvbjerg, B., Budzier, A., Christodoulou, M. D. & Zottoli, M. (2025): “The Uniqueness Trap”, Harvard Business Review, 103(2), pp. 118–125; Harvard Business Review.)
Flyvbjerg refers to this pattern as the “uniqueness bias.” When people treat their own initiative as a special case, they are less likely to look for lessons from comparable projects and more likely to build budgets and schedules around an inside view of their own situation. His recommendation comes surprisingly early in the planning process: before the first planning steps, ask what comparable initiatives already exist and what can be learned from them.
Before asking when a project can be finished, it is worth asking a different question: What is our plan actually based on?
What the Project Plan Doesn’t Show
A project plan can look remarkably precise while resting on assumptions and prerequisites that are far less clear. The reliability of the plan depends on those foundations.
Before dates and milestones are locked in, it is worth looking at the work that has to happen first.
