Can CCPM reinforce Parkinson’s law?

In this post I share a post-mortem analysis of a situation we’ve encountered while helping a company to improve its performance. This company was specialized in custom-made machine engineering and asked for help to improve its On-Time Deliveries performance. We proposed to install Critical Chain Project Management (CCPM), an obvious choice given the circumstances.

Critical Chain Project Management (CCPM) is supposed to supersede Critical Path Method (CPM) with its capability to deliver projects on time, something CPM has consistently failed to do for more than sixty years now.

Among the obstacles to on-time project termination is the Parkinson’s law. This law – not to be confused with the disease of the same name – states that “work expands so as to fill the time available for its completion”,

The Critical Chain Project Management approach recognizes this specific behavior consisting of refining the work, add unrequired features or perform additional tests instead of handing the task over to the next person in charge when finishing a project task ahead of time.

The main reasons for this behavior refered to as “Parkinson’s law” are that someone finishing earlier will:

  • fear to see the allocated time to achieve the task reduced by management the next time
  • fear to appear unable to give a trustworthy estimation of the time necessary to complete a task
  • enjoy the extra time when finishing earlier instead of being late and under pressure
  • enjoy to seemingly deliver just-in time and as predicted something that is ready and waiting for a while

Critical Chain Project Management being aware of the Parkinson’s law, its proponents educate the project members about the consequences of this behavior and put the relay race principles as well as common project buffer in place.

The relay race principles state that when a task on the Critical Chain is nearing its completion, a signal is sent to the next resource that will take over. This resource is then using this early warning to make sure to be ready on the high priority task that soon will be handed over. This is like the relay runner starting to run when the baton is approaching in order to be at top speed when it’s handed over.

The common buffer is a shared protection of the finishing date made of the sum of roughly the half of all individual protection margins. Please see Introduction to Critical Chain Project Management for more details about CCPM protective buffer.

So far so good. Now here is a developers team that was working in constant hassle, with chaotic and permanent priority changes and countless interruptions. Multitasking was so bad that some of the members could not work on a given task more than 3 minutes in average before the next interruption occurred.

Thanks to CCPM, multitasking was banned, interruptions prevented and focusing on one single project at a time became the new rule. The team members soon acknowledged the positive change and the comfort of getting rid of all the hassle and the multitasking.

Yet top management was not happy because the development team did not deliver more by finishing projects earlier, and taking a closer look concluded that CCPM reenforced Parkinson’s law. Indeed, the team members took it easy and did not really rush to the next priority job once their current task on the critical chain was completed.

What went wrong?

Well, nothing went really wrong, simply putting the system under control and stopping the constant chaos let the true problem show up: the team was not managed.

As long as everyone could influence the work on the projects, mainly sales managers and general manager worrying about the delivery date, someone was giving orders. Under such a pressure the developers managed to push the projects to their completion, even they finished late. As things were progressing, even in a total uncoordinated way, there was a general feeling that the process was delivering.

Once the CCPM rules were agreed and installed, sales managers and the general manager refrained to interfere with development team and developers had their list of priorities to work on. What they did not have was a manager taking care about work intensity (another word for productivity), cadence, challenging for continuous improvement. In one word: a manager.

Without the management’s constant challenge and care, the developers simply laid back, feeling legit to do so after all the years of stress and bad working conditions.

Insufficient cause

Reflecting on this story I realized that the top management was assuming that CCPM principles of stopping multitasking and keep focusing on the critical chain priorities was enough to squeeze out the unnecessary individual margins and consequently speed up the development process. This in turn would allow to increase throughput with the same resources.

In the Logical Thinking Process (LTP) lingo, this is an insufficient cause, meaning that by itself it will not be sufficient to cause the expected effect; increasing throughput.

What we consultants, and probably the general manager, considered a given was that this team was managed. As well this was clearly a Necessary Condition, we felt it was “oxygen”, another LTP term for conditions that are supposed so obvious that it is not necessary to express them, just as oxygen is necessary for humans to breath.


The CCPM principles worked well. The chaos was tamed and the developments could finish within the estimated time, now based on so-called focused durations.

The Throughput did increase, but not dramatically. There a three reasons for this:

  1. First reason is that the increase of throughput allowed new projects to start earlier, but given the average length of a project (10-12weeks), the speeding up was not very noticeable.
  2. Second, CCPM was applied on the work packages without challenging the work package contents nor engaging continuous improvement at once. The local management chose to collect data about buffer consumption first, in order to understand where and what to improve. Given the projects durations, this is a slow process.
  3. Third, there was no incentive to improve due to the lack of team management. This later becoming blatant once all other disturbing factors have been neutralized.

So CCPM did not enforce Parkinson’s law. CCPM did what it is supposed to: set the scene for efficient focused work and deliver the projects on promised dates.

CCPM is no cure for everything and no substitute for failing management.

View Christian HOHMANN's profile on LinkedIn


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s