Having done quite well in manufacturing, the “term critical chain” had migrated and taken root in the world of project management. It was strongly adopted – and still used today.  Not only is it used  for calculating the project’s shortest path, but also as a way for thinking about the structure of the project. The term “feeding chains” offers a little buffering room and even improves how the project structure is described, along with the project manager’s ability to understand the makeshift dependencies logic of the project.

While this terminology might be good for project management, it is followed by a common and awkward mistake of assigning project risk to the critical chain. This is where this marriage between the terminology and the project management happens, leading the project manager to invest time in the wrong places. Let’s see why.

The critical chain

The term “critical chain” goes together with GANTT chart methodology. It’s all about describing production lines. It was strongly adopted by the Project Management world and with time, it became even more sophisticated. Especially when the Theory of Constraints (“TOC”) and the “Critical Path” came on-board. To make a long story short, production lines have bottle necks. In manufacturing, opening a bottle neck in one place, moves the problem elsewhere. When this process is repeated several times, the line eventually becomes more efficient, faster and more productive. The “TOC” suggests that this cyclical process can in fact create on-going improvement and uncover production line issues on the way to optimization.

These terms, which are very native in manufacturing lines, latched on strongly in world of project management and in the wrong manner. They assume projects also have lines, chains and bottle necks that need to be opened. It worked fairly well as long as it was being used to analyze the plan. But issues began to emerge when people started marking the critical chain in red, to highlight risks and started thinking in terms of risk management. While it may “work” on paper, it is as far from reality as the Earth is from the Sun. So, even if the critical chain offers a good representation of the project structure, it does nothing to show the project’s risks and weak points.

The Good, the Bad and the Ugly

Let’s be Clint Eastwood for a moment and assume our project only has three vendors. They are the Good, the Bad and the Ugly. You are now kicking off your project with this trio.

The Good is professional and accurate. He estimates the project will last 12 weeks, no less. This is based on his experience and it is what he can deliver. He is not willing to compromise.
The Bad doesn’t really give two cents. In fact, your failure has already made him happy in the past. He will give you dates and estimations that sound great but which he can’t deliver on. He will estimate the project will last five weeks.
The Ugly is neither good or bad. He actually wants to help you but doesn’t really know how. With pressure from you, he is forced to provide aggressive targets which he will not be able to meet. He estimates the project will last eight weeks.

Now you go to your desk to calculate your critical chain. You introduce the project risks in red.  Then, you finally (and wrongly) conclude that the Good vendor is your main problem because he is the longest chain in your plan!
But, is that really where the risk lies?
As you focus your efforts on the wrong risk, you totally miss Mr. Bad, who can’t stop laughing and Ugly who will unintentionally surprise you at the last minute.

Areas of activity

Most organizations build their projects around the organization’s core capabilities. The critical chain seems to erupt from the most common tasks. So, the longest chain cannot be considered a risk without first evaluating the risks assigned to each task.

Let’s pour our example into a semiconductor company mold and think in terms of Areas of Activity. In chip production, you run several development rounds before the controller, CPU or memory are production ready. This area of activity is the company’s core process. It is where they excel and where they invest all the talent, knowledge, experience, and expertise, so it’s going to be performed as planned. It’s an expected process on the critical chain, it’s not a risk! The risk is hiding elsewhere. Maybe in chip verification, in packaging, in factory delays. Possibly even in things either unknown or out of company reach. It is sometimes managed with or by vendors who are off the critical chain during project planning.

The risk is in between

If risk is not in the longest process, then where is it? You will most likely find risk where the company engages its core process and area of activity with other areas of activity. If chip development is an area of activity, other areas are in moving the design to the factory and getting it back. Testing and providing feedback. Dealing with governmental regulatory bodies and in getting test results from the customers.
But, are any of these risk drivers on any critical chain per-se? No. Because they are between areas of activity. They are weak points that in fact really need your attention, even though they might be far from the critical chain. When unattended to, they will be on the critical chain “faster than you can say Ferrari”.

In order to tackle this risk, the project must have a very robust coordination plan, focusing on links between areas of activity. Critical chain analysis is not going to reveal these points. It suddenly seems obvious that you must have a good coordination plan to avoid this risk.

What then?

In good project planning, you must obviously identify the location of the critical chain and the feeding chains. They will provide the project structure. Identifying them will yield a list of activities characterized simply but importantly either as activities that set the project back or push it forward. When you know where the real hold up is, you can focus on these activities, improve their certainty level and try to shorten them to secure the success of your project. But this is all about optimizing the plan, it’s not about risk.

The most common mistake made is thinking that just because you don’t see the issue, there’s not going to be one. Meanwhile the fact remains that risk lies in the unseen connections between areas of activity, or in the coordination between teams.
Moreover, because project risk is not all calculable, you must apply it to issues and obstacles you anticipate based on experience . Remember Mr. Bad, who already failed to deliver in the past?

Now that you are thinking more in terms of areas of activity and assigning risk to links between areas of activity, remember that the ultimate risk to a project is a risk which is not handled correctly. It may sound trivial, but in fact, many projects have really amazing risk assessment tables but no risk prevention plan.