FREE TRIAL

Are You Engaging Honestly with Project Management Risks?

Holger Lörz

When it comes to project management, conventional wisdom holds that projects should start early with time buffers incorporated into each phase. On the surface, this seems an intuitive approach and reflects how we tend to assess risks as part of our daily routine. When planning a trip, for instance, we would naturally factor in possible delays, such as traffic. But is it wise to apply the same logic to project planning?

The normal method for engaging with risks is straightforward. Estimated time requirements are collated from each participant and safety buffers are incorporated into the respective project phases accordingly. The problem with this approach is twofold: firstly, safety buffers are seldom displayed transparently. Since each participant’s contribution is assessed by their adherence to deadlines, they may well be inclined to err on the side of caution when establishing a safety buffer. Oftentimes, this leads to excessive safety buffer in the planning phase. Secondly, the estimated time each participant requires for their phase is set in stone as fixed deadlines. As a result of these rigid and excessive time buffers, the entire project contains far too many time reserves. To make matters worse, these time buffers are often invisible to others. 

You may reasonably ask, then, “If project plans contain so many unnecessary time reserves, why do projects so rarely end ahead of schedule?”  There are three main reasons for this:

  1. Work tends to expand to fill the time set aside for it. For this reason, even if a project phase includes a significant and unwarranted safety buffer, project phases are more likely to be completed on time rather than ahead of time. 
  2. There is a natural tendency to postpone unpleasant or more challenging tasks – this is something physicist and management theorist Eliyahu Moshe Goldratt refers to as “student syndrome”. When deadlines approach, resources become tied up to these more difficult tasks as a consequence and are frequently reallocated from other continuing projects. 
  3. Delays are inevitably passed on to the next project phase, yet early finishes are rarely carried forward. This is where the disadvantage of fixed deadlines is clear: the potential for an early phase handover is simply not accounted for in conventional capacity planning and supply chains. 

How, then, can these issues at the planning phase be addressed? Naturally, risks should be taken into account when planning projects. It is important, however, to ensure that the resultant safety buffers are made transparent to all project participants. In order to do this, the following three steps should be introduced into the project planning phase. 

1. Just as conventional methodology encourages, the relevant experts should be asked how much time they need for their respective phase. This will allow you to establish a project plan based on the estimates provided with safety buffers incorporated into the plan. 

2. Next, it is important to introduce the concept of net processing time. Put simply, net processing time is the minimum achievable duration for each planning phase and is also ascertained by asking the relevant experts how long their phase will take assuming there are no delays. With the net processing time now established, the time buffers required for each project phase should be established. For this, you will need to ask the expert what the risks presented by each phase are and how much time they will take up should they arise. By gathering this information, it is now possible to calculate the gross duration of the project: this will be the net processing time in addition to the time buffer.  


It is at this stage that a more significant adaptation is made to the conventional approach. The net processing times are now presented in the project plan with time buffers placed at the end of the project, available and transparent for all. Since there is now no space to allow net work time to expand endlessly, the safety buffer can now be trimmed down. Crucially – and unlike before -, early finishes in the project can be passed on to subsequent steps, with risks no longer factored in multiple times. 


3. The previous actions allow for a decreased, transparent safety buffer, but what to do with the time saved? Though it may seem counterintuitive, this time is best used to postpone the project start date. There are two reasons for this: firstly, a delayed start mitigates the risk of student syndrome. Secondly, this buffer at the start of the project now allows for changes and iterations the customer might wish to make at the beginning – a common occurrence. 

Example screen from Allex.ai. Buffers are represented in the green bars and are used, for example, to protect the shipment and of course the project deadline.

Following these three steps, as well as familiarizing yourself with the pitfalls of conventional project management practice, will lead to more effective and efficient project planning and guard against the common causes of delays. With this new system in place, work can now no longer expand endlessly since this approach replaces fixed milestones with goals according to net processing time. Moreover, by starting later, challenging tasks are no longer postponed. In the event that delays do occur, they can now be offset by early finishes. 

The ability to work collaboratively and transparently is one of the foundations of good project management practice. Projects invariably encounter challenges and delays when their participants do not work together. By communicating with project participants honestly about risk and adapting planning strategy, a cohesive project management culture is made possible, with all participants working together in harmony. 

Example screen from Allex.ai. Here you can see a typical chart of a single project planned, with buffer. The target is to steer the project through the green corridor.

For more guidance on now to accelerate your projects, purchase The Project Accelerator: Fair, Fast, Focused. Available here.

Edited by Daniel O'Dwyer