Where is the bottleneck in project organizations?

Is the bottleneck a resource, a team or something else?

This page is an extension of a lively discussion on Linkedin which you can find here.

This article includes pictures and tables that we were not able to include in the original Linkedin discussion.

The initial question

Classic Theory of Constraints (TOC) practitioners might argue that there is no real bottleneck in a project organization. Instead, it is a virtual constraint. This constraint is very stable.

But, according to Peter Mello, there are effects that demonstrate there can be more than one constraint and even this is not stable but changes over the time!

Question: is there one Critical Chain or many?

Peter Mello gave this example as starting point:

  1. In a project where I was following the application of CCPM we had tasks in several networks, such as: A (10) > B (10) > C (10) > D (10) > E (10) and alternative paths.
  2. Each task was reduced to some extent. So it became: A (8) > B (5) > C (7) > D (8) > E (5)
  3. A part of the amount taken from each individual duration was added to the end of the chain. So A reduced by 2 + B reduced by 5 + C reduced by 3 + D reduced by 2 + E reduced by 5 – totalling a reduction of 17, which could be more than halved to create a buffer of 6.
  4. So, the new chain became: A (8) > B (5) > C (7) > D (8) > E (5) > BUFFER (6)
  5. The total original duration of the project was 50 days, and it became 39 days.

Statement of Peter Mello: "However, by simply scheduling all tasks with proper resource levelling (while continuing to respect all mandatory dependencies), I could find a different sequence to perform the same tasks in such a way that all tasks could still be allocated their original duration but the total duration of the project reduced to under 39 days."

How a Critical Chain Project Plan would look

The reduction Peter Mello described could only happen if there was another even more critical chain. So the originally identified path as the critical chain (A > B > C > D > E) was not necessarily the critical chain.

In the example the real critical chain must have been defined as A > B > X > Y > Z > W so that C > D > E would be performed in one of the non-critical paths. As a result, the project could be performed in less time, even without taking individual reserves from tasks.

The CCPM plan described above was not exactly wrong but not standard CCPM either. In CCPM you typically take the estimates as they are, then cut them by 50% and add a buffer of 50%.

In Peter Mello's example, the durations of W, X, Y and Z were missing, so I assumed for each work package a duration of 5.

Based on this assumptions the original project plan must have looked something like this:

After reducing the durations by 50% and adding a 50% buffer, the Critical Chain plan looks like this. But are there alternative chains and do these chains change? No! It’s the same structure as in the beginning – just compressed.

Now it's clear - the full project information of the Example

Peter Mello gave the complete example:

Once we can see the complete project planning information, we can understand that:

  1. A > B > E > F is in fact the Critical Chain of this Project
  2. Müller is critical resource only for Task A
  3. Mello is critical resource for Tasks B and E
  4. Hodgson is critical resource only for task F 

What is the Problem?

In the beginning of the project Müller’s work is essential, in the middle Mr. Mello’s is necessary, and in the latter stages Mr. Hodgson’s is vital. So it seems that the constraint is moving!

Moving Constraint versus Bottleneck?

Now it's easy to see where the problem is! Here’s the answer:

If you look at one single project it looks like the constraint is moving. You could use Critical Chain here but the value is reduced. In this case, there are very few resources and tasks so there is no real potential to shorten the project or to stabilize the due date. The real domain of CCPM is multi-project management or the management of a large single project.

Once we focus on a complete project portfolio, everything changes. I put the data in a "Pipeliner-Tool" of mine. Using it, you can simulate the effects at a portfolio level. Even with just one project in the pipeline you can see the problem – look on the right; the mean load of the resources.

Everything looks fine. Peter did a good job in leveling; none of the resources are overloaded at any time.

But, if you look at the mean load of the resources, you can already see where the constraint may be.

If you now assume that the projects have a more or less equal footprint of resources then you can add additional similar projects to the portfolio. Look what happens:

So, the constraint is definitely Peter. Even if the projects begin with a delay of one month.

So you have to do something against this overload: you have to stagger (or level) the projects. That means the correct solution would be to stagger every project with a lead time of two months (and no longer).

In order not to overload the constraint (Peter Mello) all the others have to have some protective capacity.

And if they have protective capacity it is of no value for the throughput of the overall portfolio to optimize anything there. The protective capacity is enough to deal with some disruptions or distortions.

To gain a good overview of the teams you can sort them by the average load. Then you'll get this picture (the numbers are a bit smaller because of the lead in/out).

This is an example of a real company with many projects and many developers (250) in different teams.

Now you can imagine how much protective capacity you can find in such a system or company. It's really not worth planning the teams with less than 80% of mean load.

Virtual Drum - the real constraint!

To go a little further – the stable solution is one abstraction layer higher. If we take the same example and ask one more question, then the model changes again.

The question is: "What is the real constraint in a knowledge-based company?"

In our experience the constraint is: "the time the super-senior experts (with the most extensive experience and knowledge) have to a) talk to each other to transform the market demand to a practical concept that will work and to b) help with tests in the integration phase to identify the source of tricky problems."

In a project this is effectively the conceptual and integration phase.

Now back to the example: assuming that 10% (and that is not very much if you want to have innovative projects) of the total work is conceptual and integration work. That means that Müller/Mello/Hodgson have to spend 10% of their capacity doing this. So their capacity is reduced by 10% and their planned effort in the work schedule is affected by the same amount.

But because they have to work together the resulting capacity of the constraint (we call it a Virtual Drum because it's not a real team) is not 30% but just 10%. So this constraint is a very tight constraint! And stable too, because it does not change easily; you need experienced and educated people there.

Now the project’s resource plan looks like this. The efforts per month are reduced and the Virtual Drum is included – with just 10% conceptual and integration work (far too little).

Now that the constraint is really visible it is clear that you can't start such a project every two months. Instead you have to wait three months before starting the next project to get at least the mean load below 100%.

This will work even if the Virtual Drum resources are overloaded in some months by factor 3. That is not a problem because they will just simply use some of their other capacity. But bBecause thatis is not the constraint and there is some protective capacity left over, this will not hurt much.

If you now look at the load of the teams you'll see a lot of protective capacity.

This is also the key when tackling the reduction of project durations (if there is more than one person in a team and they have buffers at the end of the project). You don't have to worry about negative multi-tasking or local overloads. Now the resources are waiting for work. Every project seems to have all capacity it needs – so the flow is perfect and the throughput too!

By the way, the staggering at team level indicated that the projects should be started every two months. But the Virtual Drum staggering shows every three month. That is very typical for the companies with whom we consult. Either they have a realistic plan but the due dates won't be met because of the overload of the Virtual Drum, or the quality is not acceptable or the projects simply overrun. We’ve learnt that if you stagger at team level you won't get a stable portfolio and you won't see the problem.

There are a lot of testimonials about CCPM in the internet. One of my favorites is from Yuji Kishira (a client of one of my colleagues) at Mazda, which saw a 50% reduction in project lead time.

Then, if you finally get rid of the constraint involving your super experts (the Virtual Drum), the constraint will move to the market – and then it gets even easier!

How can the reduced duration be explained?

Critical Chain is not a scheduling algorithm at all; actually it has the characteristics of a closed-loop corrective action. That means that there are many influencing factors that can help to reduce the project duration.

The most important ones are:

  1. If you had negative multi-tasking and you use the Virtual Drum as the basis of your staggering then you can free a lot of hidden capacity in the Virtual Drum. This alone leads to reduced task switching and better synchronization – and that results in an immediate speed-up.
  2. If you put the buffers at the end, then for statistical reasons you do not need as much buffer anymore. And, if you operationally prioritize according to the buffer consumption, then this effect will be even more drastic.

But there are many more:

  • higher quality of concepts = less rework
  • less negative multi-tasking = focused work and reduced set-up times
  • focus on buffer consumers = measures to improve flow will target the right places = focused continuous improvement
  • better synchronization = faster conceptual work and faster problem-solving
  • reduced need for reporting = team lead, developer and project manager gain capacity
  • fewer escalations about operative priority = project manager can concentrate on project order clarification and conceptual work
  • impediments become obvious = improved capacity to solve them = kaizen
  • easier and faster decisions = lower latency = reduced effort to solve problems
  • less communication needed = communication is more focused

So it's much more than simply cutting the task durations. Critical Chain Project Management leads to full-blown organizational change.

But I promised to calculate the duration of the project we discussed, so here it is:

Please be aware we are talking about probabilities. If someone estimates a duration of 30 days then one has to factor for all the negative experience calculated in. If people are measured on how good their estimates are, then they will feel the need to put some more buffer in.

If I assume that on a 30 day job the optimistic value would be something like 12 days, the realistic 20 and the pessimistic 30 then you will get a resulting probability curve for the example above like this:

If you look at the percentiles you will see that with a probability of 95% that the duration is already slightly below 80 days (near the 75 days of CCPM).

If you had a plan with 6 jobs then the effect will increase and you will have a plan of 75 days.

But, as I said before, this is only a part of the picture. All the other associated effects mean the overall improvements are much more useful and much more effective. Otherwise it would not be possible to reduce the total project duration by 50% (including the buffer) as in the Mazda example – or, as one customer of ours did, to reduce the average duration by 70%!

A 50% improvement is just the starting point of the optimization made possible by using Critical Chain.