The curse of multi-project Environments

The curse of multi-project Environments

- Satyashri Mohanty

The curse of multi-project Environments

The problem of multi-project environments

Most multi-project environments (where resources are shared across projects) have adubious reputation of very low on time delivery performance (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 not considering that the scope may have 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 feel that the root cause behind the mess is lack of visibility and hence control on the projects.

One way most organizations have tried to solve the problem is by investing in project specific IT systems, which 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, in execution, when uncertainty hits the project, the associated delays make the plans go haywire and at the same time, the delay of one project, causes cascading effect on other projects as resource contention multiplies the delays.

With many projects under delays, the management mode of operation is mostly crisis driven. In such environments, the 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 give up efforts of planning and by the time, project is mid-way of execution, the 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 – which in turn causes increased load on resources and subsequent damages associated with bad-multitasking.

Is their a different way of managing the mess in these environments? Are these environments cursed to be perennially in a state of instability and chaos?

Million dollar question!

The way out

Critical Chain Project Management, 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 which cause all the undesirable effects in these environments are:

1. Start projects as early as possible to finish early
2. The only way to finish the project in time is to finish each task on time.

The first assumption causes many projects to be in WIP state, causing bad-multitasking 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 student’s 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 solution: Critical Chain Project Management.

The 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 – so 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 provide 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.
curse-1

Further, the WIP of projects in the system is also controlled to contain the badmultitasking.

Results

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Share on Google+

Related Articles

EPC Reborn Focus on Flow

EPC Reborn Focus on Flow

The last few quarters have been tough for most Engineering Procurement and Construction (EPC) companies.Read more

- Satyashri Mohanty
Getting CCPM implementation right

Getting CCPM implementation right

Cherry-picking solution components and sequencing them incorrectly can lead to the failure of CCPM implementationsRead more

- Satyashri Mohanty
Three Rules for Rapid New Product Development

Three Rules for Rapid New Product Development

New product development for auto companies is one of the most complex operations environments due toRead more

- Satyashri Mohanty