The curse of multi-project environments
The problem of multi-project environments
Most multi-project environments (where resources are shared across projects) have a dubious reputation of very low on time delivery of projects (less than 10%), as per the originally committed dates. Yes, in many cases, the due date performance looks better; but only as per the revised dates (or, if one were to ignore the possibility of the scope having been compromised to meet the deadline).
The solution that is not
In such environments, the realization that the project is delayed comes very close to the due date. As a result, management of these companies feels that the root cause behind the mess is lack of visibility, and hence control over the projects.
One way most organizations have tried to solve the problem is by investing in project specific IT systems that claim to provide visibility in these environments. Managers try to solve these visibility problems by making more detailed plans with more date driven milestones for control. However, during execution, when uncertainty hits the project, the associated delays make the plans go haywire. At the same time, the delay in one project causes a cascading effect on other projects, as resource contention multiplies the delays.
With many projects getting delayed, the management mode of operation is mostly crisis driven. In such an environment, management attention to the issues interrupting projects is delayed, as the number of crises far outnumber the bandwidth of management, further adding to the delays.
The solution of making detailed plans to improve these environments does not seem to work. Many managers intuitively feel that the entire exercise of planning is a waste of time – which does not help execution. Many of them stop planning altogether, and by the time the project is mid-way through execution, project managers start using their intuition to manage projects rather than the carefully made plans before the start of the project.
With the common experience of delayed projects, many project managers try another solution – start projects as early as possible. This, in turn, results in an increased load on resources and subsequent damages associated with bad-multi-tasking.
Is there a different way of managing the mess in these environments? Are these environments cursed to be perennially in a state of instability and chaos?
The million-dollar question!
The way out
Critical Chain Project Management (CCPM), invented by Dr Eli Goldratt, using the Theory of Constraints, addresses the root cause of the chaos in multi-project environments.
The two management assumptions that cause all the undesirable effects in these environments are:
- Start projects as early as possible to finish early
- The only way to finish the project on time is to finish each task on time
The first assumption causes many projects to be in a WIP state, causing bad-multi-tasking of common resources, which, in turn, not only wastes the capacity of these resources but also increases the overall lead time of all the projects.
With the second assumption, the task duration estimations are converted to commitments. As a result, buffers are built at the task level. The buffers at task level promote the Parkinson’s effect (work expands to fill up the time allotted to it) or students’ syndrome (efforts are put close to the task milestone). These buffers are wasted as delays are passed on, instead of gains.
The solution: Critical Chain Project Management
The critical chain project management solution components are built in the planning phase as well as the execution phase. Since nobody knows about uncertainties of execution during the planning stage, there is no point scheduling tasks during planning. However, it is important to provide complete protection to the end of the project. Therefore, while using critical chain project management (CCPM), the buffers are shifted from the task level to the end of the project to create a project buffer, and also at the end of every feeding path to create feeding buffers before the integration points with the longest chain of the project.
The project buffer provides protection against uncertainties of the longest path, whereas, the feeding buffer provide protection to the lead time from expanding due to uncertainties of the feeding chain. In execution, these visible buffers are managed actively to prevent wastages of time and capacity.
Further, the WIP of projects in the system is also controlled to contain the bad multi-tasking.
Worldwide, there are numerous success stories for critical chain project management. The environments implementing CCPM have not only reported very high due date (close to 90% +) performance, but also increased output of projects from the same set of resources (close to 30% to 40% increased output). The quality of delivery also improves, as quality and scope compromises are almost negligible when the pressure of time and associated chaos is removed from the environment
Three rules for rapid new product development
Find out how three simple rules of design, WIP and planning can help reduce lead time and increase output
Getting CCPM implementation right
Cherry-picking solution components and sequencing them incorrectly can lead to the failure of CCPM implementations
EPC reborn focus on flow
Find out how to deliver EPC projects on time even in an environment of high uncertainty