Today’s post is by Dr. Giovanni Siepe.
Every ground breaking solution that is part of the Theory of Constraints springs from challenging limiting assumptions of the situation at hand. It is exactly the same for the Critical Chain algorithm for project management.
In the late 1990s, Dr. Eliyahu Goldratt brilliantly tackled a foundational limiting belief in Project Management connected with protection of tasks.
Project Managers always have to satisfy two legitimate needs in order to manage a project successfully:
- Complete the project on time
- Promise the client a short lead time
So PMs face a fundamental conflict. In order to satisfy the first need, a PM would like to add protection to project tasks. However, In order to satisfy the second need, a PM would NOT want to add protection to project tasks.
Solving the problem
Using the Conflict Cloud Thinking Process, we can represent the conflict as follows (we call it the Cognitive Constraint of the PM):
PMs perceive this conflict as real because they make assumptions about the situation they experience (assumptions are the stuff our reality is made of).
Let’s add the assumptions to the conflict:
A breakthrough for project management
Dr. Goldratt’s breakthrough solution to this conflict is the Project Buffer; it invalidates the limiting assumption that “all tasks need protection”. How? We can decide to add protection only to the sequence of tasks that determines the length of the project, i.e. the Critical Chain. So instead of protecting every single task in the critical chain, we strip it out and cumulate the protection at the end of it in one buffer, the project buffer.
But how do we determine the Critical Chain?
The Theory of Constraints is based on the concept that available resources are finite. Whether it is for managing production (DBR – Drum-Buffer-Rope), managing projects (Critical Chain) or managing the replenishment of raw materials, each solution in TOC aims at synchronizing activities by relying only on resources that are available.
Let’s see how “finite capacity” logic works in managing a project.
Let’s consider a project made up of five tasks whose network of interdependencies is represented as follows:
By adding durations to the tasks, it is possible to obtain what is commonly called the Critical Path:
The Critical Path gives us the shortest possible project length given the declared duration of tasks. It has the sole purpose of telling us that if we had infinite resources, the project would last six days.
But what happens if tasks 4 and 1 that are concurrent have the same resource associated with them? And likewise, what would happen to tasks 1, 3, and 2? The logic (the algorithm) must consider that a resource cannot be ubiquitous and work on two different tasks at the same time. Multitasking is not allowed!
The algorithm, therefore, must move one or more tasks to resolve the “resource contention”.
Coming from the experience of creating the algorithm for managing production, Dr. Goldratt used the same concept of “physical constraint” to develop the Critical Chain algorithm. He used the idea of “pacing resource” to emulate the physical constraint for production: a pacing resource is the critical resource, or group of resources, that would allow the correct synchronization of all the tasks in the project.
The length of the project, the Critical Chain, is defined as the “Constraint of the Project”.
Here’s how the project gantt transforms from the critical path to the critical chain using the critical chain algorithm:
The sequence that determines the length of the project, the Critical Chain, is eight days long. Taking into consideration the protection (the buffer) at the end of the project, the realistic length is ten days.
Our discovery about multi-project environments
Everything in the previous section is valid in a single project environment. Now let’s think about this apparently simple exposition of how a project should be managed at “finite capacity” when compared to the complexity that is generated in a multi-project environment.
At Intelligent Management, we discovered “by accident” something of vital importance when it comes to managing multi-projects with finite resources. We decided to create a piece of technology (see Ess3ntial ) to support the organization design we developed that we called Network of Projects. We first published the Network of Projects concept and the importance of competencies back in 2010 in our book ‘Sechel: Logic, Language and Tools to Manage any Organization as a Network’. We later expanded on it in ‘Quality, Involvement, Flow: The Systemic Organization‘ in 2016 and ‘Moving the Chains‘ in 2019. When we started writing the algorithm for a multi-project technology based on Critical Chain, something became obvious to us from the math.
Let’s try to imagine having two or more projects running simultaneously.
Firstly, we must consider that, unlike a manufacturing environment, the demand for projects cannot be cumulated at the end of a given timeframe (a week, a month…). In fact, the delivery date requested by one customer rarely coincides with the delivery date of another.
In addition, the competencies required for the execution of these projects may differ from one project to another, making it virtually impossible to define a pacing resource for the set of projects.
As a result, the original project management algorithm can no longer work in a multi-project environment.
This is the reason why, at Intelligent Management, we modified the original algorithm.
To facilitate the simultaneous execution of more than one project we realized that what we had to schedule was NOT resources to synchronize projects but competencies.
Competency-based projects
Any individual is, in fact, a bearer of competencies. When we think of people not in terms of their job descriptions or departments, but in terms of their competencies, we open up a whole new scenario of possibilities and much greater flexibility. We multiply the possibilities of managing simultaneous projects with fewer resource contentions to solve. This is because by scheduling a competency, we can choose from various people that have that same competency–we are not limited to considering one person per task as we would do in conventional project management.
With this new logic, what determines the length of a project is the total available time of competencies within the organization.
Let’s consider, for example, that we have to schedule two projects simultaneously. Besides the fact that in this scenario resource contention is more complicated to solve, a more complex problem emerges during execution.
Even in the fortunate event that the two projects do not completely overlap (as in the example below), any delay on the Critical Chain of the first project could be transferred to the second project. This is a predicted effect caused by interdependencies in a multi-project environment.
As is easy to imagine, the more projects we have to manage simultaneously, the greater the complexity. How can we manage such complexity? By understanding variation and protecting our projects with project buffers.
Buffer Management, thus, becomes the most important activity within the organization.
It is only by understanding the nature of variation (the nature of delays passed on to the chain) and how it impacts buffer consumption that managers can make rational decisions about any corrective actions to be taken during execution.
Project management and the new physics
As physicists, we can say that the Network of Projects that is generated in a multi-project environment is a Complex System. The Network of Projects is, in fact, a network of critical tasks whose structure resembles that of a self-similar fractal.
Mathematically, the Network of Projects is like the jagged coast of Britain, the measurement of which helped inspire Benoit Mandelbrot’s fractal geometry. To use an image we can relate to, it is more like a fractal fern:
This is an important indication to understand that there are no simplistic solutions to manage a multi-project environment. In a multi-project environment, the only way to greatly increase the likelihood of success is to rely on an epistemological approach, i.e. based on knowledge.
Any empirical or semi-empirical approach is destined to fail. Fortunately, thanks to Goldratt’s original algorithm that we started working with in the 1990s, our determination and some solid math, the knowledge, method and tools to successfully manage a truly multi-project environment now exist, without resorting to “workarounds”. We warmly invite you to explore all the new possibilities this new solution provides for your organization.
To find out more about ten guided steps to a systemic leap ahead for your company, contact Angela Montgomery at intelligentmanagement@sechel.ws
SCHEDULE AN INTRODUCTORY CALL WITH US
Intelligent Management works with decision makers with the authority and responsibility to make meaningful change. We have helped dozens of organizations to adopt a systemic approach to manage complexity and radically improve performance and growth for 25 years through our Decalogue management methodology. The Network of Projects organization design we developed is supported by our Ess3ntial software for multi-project finite scheduling based on the Critical Chain algorithm.
See our latest books: From Silos to Networks: A New Kind of Science for Management from Springer, Moving the Chains: An Operational Solution for Embracing Complexity in the Digital Age by our Founder Dr. Domenico Lepore, and ‘Quality, Involvement, Flow: The Systemic Organization’ from CRC Press, New York by Dr. Domenico Lepore, Dr. .Angela Montgomery and Dr. Giovanni Siepe.
Leave a Reply