Good Planning Starts Before the Project Plan
What Other Projects Can Tell Us About Our Own
Even a new initiative rarely starts from zero. There is often experience that can provide useful orientation for at least parts of the project. Flyvbjerg and his team therefore recommend first looking for comparable initiatives within the same organization and then outside it. If there is no direct analogue, the project can be broken down into components for which meaningful comparisons may still exist. (Flyvbjerg, B., Budzier, A., Christodoulou, M. D. & Zottoli, M. (2025): “The Uniqueness Trap”, Harvard Business Review, 103(2), pp. 118–125; Harvard Business Review.)
Looking at those reference cases changes the basis of the plan. Instead of merely estimating how long we believe our own initiative will take, we can examine what actually happened under comparable conditions. How long did similar projects take? How often did budgets or deadlines slip? And where did the same difficulties appear repeatedly?
This is the logic behind Reference Class Forecasting: the estimate for the project at hand is calibrated against the actual outcomes of a suitable comparison group. The outside view does not replace detailed planning for the project itself. It provides a reference point against which our own expectations can be tested.
That leads to a first question before expectations turn into dates: What do we already know about initiatives of this kind?
What We Know—and What We Only Think We Know
Comparing our project with others solves only part of the problem. Information within our own initiative does not all have the same status either. Some relationships are well established, others are based on experience or forecasts, and still others are assumptions we hope will later prove correct.
Rita McGrath makes this point very clearly in the context of strategy: companies should be able to say when they acted on assumptions that later proved wrong. Strategy therefore has to remain flexible enough to adjust actions when the underlying conditions change. (McGrath, R. (2025): “Strategy: Rita McGrath on the Shelf Life of Corporate Strategies” [German-language interview], interview by Gesine Braun and Christiane Sommer, Harvard Business manager, 9/2025, 2 September 2025.)
Applied to project planning, this creates an important distinction: What do we know? What are we assuming? What are we dependent on? And what simply describes the outcome we want to achieve?
A plan does not become more reliable simply because it contains more information. What matters just as much is whether it reveals what kind of knowledge that information is based on.
Aus der Praxis
This kind of work was especially visible in the transformation program I mentioned earlier. Before a reliable implementation plan could emerge from a large number of individual topics, the content first had to be made progressively more concrete.
Initial descriptions developed into high-level concepts. Those concepts were then elaborated, reviewed, and aligned with the affected areas. The work went beyond documenting individual requirements in greater detail. Concepts were also mapped to business processes and process steps. Over time, this created a kind of map showing which topics were connected, which areas were affected, and where dependencies existed.
Those relationships mattered enormously for the planning that followed. A single topic could look manageable in isolation. Only when connected to other processes, concepts, or organizational areas did it become clear which additional prerequisites had to be met and what effects a change in one area might have elsewhere.
This was not a one-off exercise. Requirements and solution ideas were refined iteratively with different stakeholders and became progressively more detailed. Only after concepts had gone through this process were they handed over into broader portfolio planning and prioritization.
For me, a significant part of the planning effort therefore consisted of creating a reliable map first. It showed what had to be delivered, how the individual pieces connected, and which prerequisites had to be taken into account.
Detailed implementation planning did not come at the beginning of this work. It built on the knowledge created during that process of clarification.
When Knowledge Becomes a Plan
A project plan does not appear out of thin air. It consolidates experience, known relationships, assumptions, dependencies, and the current level of functional and technical clarification.
For me, a project plan is above all a condensed representation of what a project knows at a particular point in time.
That is also its limitation. The project’s knowledge will never be complete. Some prerequisites remain unresolved, some assumptions can only be tested later, and some dependencies will change.
So what do we do with everything that is still unclear at the point when the plan is created?
