The paradox of project planning from an uncertainty perspective

Developed by Freja Ejdrup Andersen, February 2022

The paradox of project planning is characterized by the uncertainty associated with early-stage decisionmaking. In a project, one of the most difficult things to plan is the uncertainty and the risk associated with it. When planning a project, decisions are often made in the early stages where there is a lot of epistemic uncertainty (see Epistemic vs. Aleatory uncertainty). To have a project run smoothly, keep the budget and overall deadlines in check, important decisions need to be made early in order to define a clear schedule. This can however not be made without knowledge, which is sparse in the early stages. Further into the project process more information is available, but the decisions made in these later stages are less important for the success of the overall project. This concept is what is known as the paradox of project planning.

This article will identify the different stages of a project and propose different strategies that can be used to partially overcome the paradox of project planning. Some of the key requirements this article will address, to increase the knowledge in the beginning of the project, include front-end loading with the involvement of experts and the postponement of the decision-making.

Introduction

To help identify when different strategies are preferred over others the project life cycle will be introduced. It consists of five phases: Initiation, planning, execution, monitoring and controlling, and closure. The initiation phase is where the goals and objectives of the project are defined. The planning phase consists of creating a work breakdown structure which helps define the scope of the project, but also estimate the cost and resources required to execute it. The goal of this phase is to create a project schedule. The third phase is the execution phase where all the project deliverables will be completed. The fourth phase is the monitoring and controlling phase. This phase is performed simultaneous to the execution phase to insure the quality and alignment of the project with the scope. The final phase is the closure of the project, where all lose ends are tied of such as evaluating the project and making sure that all deliverables have been completed.

Agile vs. waterfall management methodology

Figure 1: Example of the waterfall and agile management methodology. The waterfall method is presented on the left and the agile methodology is presented on the right [Figure created by the author]

• A traditional project follows the waterfall methodology, where the scope and documentation firstly are precented up front to align the project requirements. Then the design is developed and then implemented. Fourthly the design is verified by tests and then maintained. This is illustrated on Figure 1.

• An agile project is an iterative process where the overall project is broken down into parts and each part is then worked on separately. These parts have their own time restraints, and they are known as sprints. After each sprint the parts are then evaluated before moving further with the next part.

What is the paradox of project planning?

Figure 2: Example of the paradox of project planning [Figure created by the author, inspired by Olsson, N. O. E. & Samset, K. (2006) ]

The paradox of project planning is primarily present in the planning phase as the name might suggest, but it also spans the duration of the execution, and monitoring and controlling phase of the project. It is mainly present in a traditional project and is a project management model that connects the uncertainty or the significance of decisions with the available information about the project at a certain point in time. It states that the important decisions are made in the early stages of a project, where the level of epistemic uncertainty is high. Later in the process, more information is available, but the significance of decisions has decreased. This relationship can be seen illustrated on Figure 2 where it can be seen that there is a large gap between the needed knowledge to make informed decisions and the available information.

The paradox can also be connected to the notion described by Kreiner, in his conceptual paper on challenging the rational project environment, that project planning have limited control over the events that unfolds during the execution phase of the project. Kreiner states that planning, used as a tool for project preparation, can be highly useful, but that it is detrimental to mistake it for reality. This also adds to the risk of over planning, but does however leave little advice on dealing with the paradox and thus other strategies can be used.

Limitations and pitfalls

Over planning

One of the pitfalls created by the paradox of project planning is over planning. This concept is yet another way of adapting to the uncertainty and thus lack of knowledge in the planning phase. Over planning can happen for several reasons, with one of them being that the focus has been on the individual outcomes of the project. This means that everyone involved has their own schedule and thus no combined schedule has been made. To combine these schedules and scattered information takes up a lot of resources. When a main schedule finally has been made, it might fall into yet another category of over planning; which is that it is too complex to adapt to reality during the execution phase. Another reason could be that the focus on the actual tasks ahead are lost in the quest of following the schedule. This can be fixed by including risk management strategies such as lag in the planning phase and also plan for changes. Another downside to over planning is that it can cause unhappy stakeholders because the project ends up exceeding the budget and schedule.

Strategies to cope with the paradox of project planning

Different strategies can be used in order to decrease the amount of uncertainty when making significant decisions. They include Front-end loading and postponing decision-making including the rolling wave.

Front-end loading

Figure 3: Example of how front end loading affects the paradox of project planning [Figure created by the author]

The principle of front-end loading comes from project management and refers to the process in which cost, and time is intentionally increased or allocated to the early stages of a project. This way the uncertainty of a project is rapidly decreased because of the increase in available information. This strategy helps to create more informed decisions, and further minimizes the risk associated with the project and increases the potential for project success . The benefits and influence of this can be illustrated by the influence curve, seen on Figure 3.

This strategy is useful in projects where the uncertainty of initiating the project is high and when the cost of executing the project will increase drastically if information changes. It is however not very useful if the project does not have a clear scope or if it is unstructured with no overall completion date. This is because the allocated resources will be wasted if the scope or structure of the project changes. But with a clear scope this can be used in the planning phase of traditional projects. It is not in the same way needed in an agile project.

But by allocating cost to the early stage of a traditional project, experts can be involved to further increase the knowledge of the project. Here the appropriate stakeholders can also be involved. To get a sense of where to allocate experts or stakeholder knowledge, a useful tool to use would be the learning plan.

The learning plan

Figure 4: Example of how postponing decisions affects the paradox of project planning [Figure created by the author]

The learning plan creates an overview of the project and helps to identify where there is a lack of knowledge and in turn where it would be wise to involve the appropriate experts when it comes to these shortcomings. The learning plan can be divided into two sections: The learning loop and evaluation. The learning loop is needed to assess the uncertainties regarding market, technology, resources, and organization. Here it is important to identify the knowns and unknowns of the project and assess how to acquire the appropriate knowledge. The evaluation should be used to review the outcome of the learning loop and define new learning requirements for the project . This tool is also useful in evaluating and identify if the scope of the project is sufficiently defined when initiating the planning phase.

Postpone decision-making

Figure 5: Example of one of the information waves in the rolling wave, where information becomes more detailed the further into the project you go. [Figure created by the author, inspired by Ledwith, A. (2002) ]

This concept is used as a response to the lack of information in the early stages of a project. It specifies the areas in which knowledge is lacking and postpones the necessary decisions until the required information is acquired, as seen on Figure 4. It is important to note that this must be planned intentionally in the early stage of the project and not performed as the primary way or afterthought when running the project during the execution. If this is not done intentionally and with care, the cost and schedule of the project could be significantly exceeded. A way of postponing decisions would be to use the project management tool known as the rolling wave.

The rolling wave

Figure 6: Example of lead and lag. [Figure created by the author, inspired by Crandall, K. C. (1973) .]

The concept of the rolling wave is to make a rough schedule and cost estimate of the project in the planning phase. Then as the project progresses through the execution phase a detailed schedule for the near future can be made and the rough project schedule and estimated cost can be reevaluated. This concept also supports the notion that Kreiner presented in his conceptual paper. It does so by erasing both the use of the project plan as reality and project over planning, but rather adapts the rough plan to the reality of the project. This can is illustrated on Figure 5. It is also very useful in agile projects, since it focuses on small parts of the project and their short-term objectives in order to complete the project.

Lead vs. lag

It is important to note that the terms lead and lag are sometimes used interchangeably depending on the literature referenced. In this article the term “lead” is used to indicate the amount of time the beginning of an activity is ahead of the beginning of a following activity. The term “lag” is identified by the amount of time between the beginning of an activity and the end of its predecessor activity. This definition of lag is also called finish to start lead but will throughout this article be defined as lag. Lead can be used to determine the amount of time an activity can be postponed in relation to a prior activity. An example of this would be how long you can wait to start an activity and still not change the overall timeframe. Lag can be used in the same way, but it can also be used to include uncertainty in a schedule. This can all be seen on Figure 6. These terms are mainly used in the planning phase of a project.

Examples in the building industry

A prominent example of the paradox is in the building industry, where architects and engineers collaborate in the early design phase. Traditionally architects design a building and when they have locked the design, the engineer create all the necessary documentation needed for the building to be built. This is increasing the effect of the paradox because the architect is the one with the least technical knowledge on how to execute the project in the building phase. A way to overcome some of the challenges and increase the knowledge in the early stages of the project would be to include the engineer when creating the design. This could be done either by front-end loading or postponing decision making by making a performance driven design. This also leans into the agile project management methodology because of the performance feedback in the iterative process, but also the method of the rolling wave where the detail level increases the closer you get to the milestone

Related wiki articles

1. Epistemic vs. Aleatory uncertainty, link: Epistemic vs. Aleatory uncertainty. This page elaborates the definition and the difference between Epistemic and Aleatory uncertainty. It defines the cause of the uncertainties, categorizes types of decisions and how they affect project, program and portfolio management.
2. Learning plan, link: Learning plan. This page goes into detail about the learning plan, how to use it and what the benefits and limitations of the tool.

Annotated bibliography

1. Olsson, N. O. E. & Samset, K. (2006). Front-end management, flexibility, and project success: This paper collects different studies to identify why front-end management is important for the success of a project. It defines effectiveness and the reason why improvement is needed along with different improvement measures. This includes how to minimize the need for flexibility by looking at the maneuver area in the different project phases[10].
2. Kreiner, K. (2012). Comments on challenging the rational project environment; The legacy and impact of Christensen and Kreiner’s Projektledning i en ofulständig värld: This conceptual paper is commenting on the book by the same author called Projektledelse i løst koblede systemer by Kreiner, K & Christensen, S. (1991). The conceptual paper states why projects should not be mistaken for reality and that it is important to adapt to the current state of the project.
3. Kreiner, K & Christensen, S. (1991). Projektledelse i løst koblede systemer: This book is a handbook on how to manage projects in an uncertain world.