Cherry-picking solution components and sequencing them incorrectly can lead to the failure of CCPMi implementations. The logic of Critical Chain Project Management, or, CCPM appeals to common sense. Anyone looking for a way to tackle the damages done by bad multitasking and ‘date driven’ behaviour would readily embrace the solutions offered by CCPM. The concept of CCPM doesn’t need any hard selling. Workshops are making believers out of managers everywhere. While it is easy to convey the logic of the new paradigm, it isn’t simple to implement the principles of CCPM in an actual situation. There are numerous instances of implementations where no discernible improvements in lead times (reduction in inventory) and output were achieved. At the same time, there are also instances where huge gains were made. So what’s different between these two categories? If we were to study the actual improvements achieved in both these sets, we’d see some typical and predictable patterns. Surprisingly, even in implementations sans results, the protagonists of the change talk in terms of intangible yet vague improvements like ‘improved visibility’, ‘discipline of planning’, and so on. The absence of concrete improvements in terms of lead time or inventory reduction and increase in output is usually blamed on calculation complexity compounded by wide variety in product mix. The users in such assignments see CCPM processes as a burden even as priority conflicts remain at the resource level and hamper day-to-day working. Often, top management is ambivalent about such implementations. While project plans and updates give them a feeling of improved ‘systematic' working, they also get a sense of not being in control over things. They continue to feel that people are not being proactive enough, a malaise that existed even before the implementation. The experience of hugely successful implementations is vastly different. The best way to understand the impact of an implementation is to seek informal feedback from the lowest-level resources in the design department. They would describe the dramatic change in their environment, talk of being more productive, and the ability to work without being pulled in different directions. They experience a condition of ‘flow’ – working with fewer interruptions. They would also point out that issues get resolved much faster. In such environments, the data of actual improvement is also much beyond the noise of product mix. The improvement at the global level is evident. Top management gets the feeling of real control as they see the organization always ready much before critical customer deadlines. Chronic symptoms of “rush-hour” work close to customer deadlines are almost gone! These two types of results have nothing to do with environmental conditions or people capabilities. The exemplary success stories have no correlation to the type of environment or the level of ‘intellect’ of the people affected by the change. The logic of damages of bad multitasking and ‘date driven’ behaviours holds good in every project environment – right from new product development, software development to ETO and EPC environments. It’s easy to pinpoint the reason behind unsuccessful implementation – cherry-picking of solution components. CCPM solution components are built on the strong foundation of sequence logic. Each solution component is built on the success of the previous component. Incorrect sequencing of the components would not bring in any results at all. For example, in an environment of rampant bad multitasking, the reliability of plans is extremely low. So, trying to set up a CCPM planning processii without dealing with the problem of bad multi-tasking would only lead to a lot of hard work in maintaining project plans with nearly no benefit to the actual users. Similarly, in some environments, people favour the rules of common priority and gating policy of full kit but put no effort into implementing the necessary conditions to ensure the reduction of work in progress in different departments. They assume that such a diluted effort will at least give them some benefits. However, efforts to set up a common priority list are only a one-time act. Without WIP control, pressures from different stakeholders force one to change the list, and very soon, the common priority list goes haywire. Erroneous sequencing and cherry-picking of solution components are the main reasons for failure of CCPM implementations. Such approaches also lead people to conclude that CCPM is not applicable to their environment. Surprisingly, there is a pattern even in cherry-picking solution components in these failed implementations. These implementations usually skip the first step of WIP reduction in critical starting departments like design, which calls for freezing of work fronts as per agreed priority and move on to the rule of triggering the start of work based on the rule of ‘one in and one out’. The transition step of freezing work fronts to reduce WIP in the starting departments creates a perception of ‘high risk’, and hence, managers shy away from this step. At times, even consultants perceive this risk and refrain from deploying this step. Is this step of freezing and aggressively reducing WIP risky? Or is it a step necessary to eliminate the risk of the status quo? The best way to find out is to ask every section or department in the current environment to highlight the department’s top three priority projects. One will be surprised to see that the list would widely vary across departments, thus reflecting a huge gap in understanding what is truly important. Since the number of work fronts that one can work on is more than the available resources, at any point in time, there is a small active list and a frozen list (many projects which are not being worked upon) in every department. Often, the frozen list is longer than the active list; the lists widely vary across departments. They keep changing daily causing, overall de-synchronization and delays in every project. So the rules of common priority and restricted WIP bring everyone on the same page, thus improving overall synchronization. These two lists have to be centrally controlled and not left to people at the lowest level of the organization. This in turn facilitates implementation of other steps of CCPM solutions.The sequence of solution implementation holds the key to a successful CCPM deployment. The icing on the nicely conceptualized cake can only be put when the base is ready.Understanding the complete solution is different from understanding the sequence of implementation of the solution components. Mastery of these two know-hows is crucial for any successful implementation.

Getting CCPM implementation right

Cherry-picking solution components and sequencing them incorrectly can lead to the failure of CCPMi implementations. The logic of Critical Chain Project Management, or, CCPM appeals to common sense. Anyone looking for a way to tackle the damages done by bad multitasking and ‘date driven’ behaviour would readily embrace the solutions offered by CCPM. The concept of CCPM doesn’t need any hard selling. Workshops are making believers out of managers everywhere. While it is easy to convey the logic of the new paradigm, it isn’t simple to implement the principles of CCPM in an actual situation. There are numerous instances of implementations where no discernible improvements in lead times (reduction in inventory) and output were achieved. At the same time, there are also instances where huge gains were made. So what’s different between these two categories? If we were to study the actual improvements achieved in both these sets, we’d see some typical and predictable patterns. Surprisingly, even in implementations sans results, the protagonists of the change talk in terms of intangible yet vague improvements like ‘improved visibility’, ‘discipline of planning’, and so on. The absence of concrete improvements in terms of lead time or inventory reduction and increase in output is usually blamed on calculation complexity compounded by wide variety in product mix. The users in such assignments see CCPM processes as a burden even as priority conflicts remain at the resource level and hamper day-to-day working. Often, top management is ambivalent about such implementations. While project plans and updates give them a feeling of improved ‘systematic' working, they also get a sense of not being in control over things. They continue to feel that people are not being proactive enough, a malaise that existed even before the implementation. The experience of hugely successful implementations is vastly different. The best way to understand the impact of an implementation is to seek informal feedback from the lowest-level resources in the design department. They would describe the dramatic change in their environment, talk of being more productive, and the ability to work without being pulled in different directions. They experience a condition of ‘flow’ – working with fewer interruptions. They would also point out that issues get resolved much faster. In such environments, the data of actual improvement is also much beyond the noise of product mix. The improvement at the global level is evident. Top management gets the feeling of real control as they see the organization always ready much before critical customer deadlines. Chronic symptoms of “rush-hour” work close to customer deadlines are almost gone! These two types of results have nothing to do with environmental conditions or people capabilities. The exemplary success stories have no correlation to the type of environment or the level of ‘intellect’ of the people affected by the change. The logic of damages of bad multitasking and ‘date driven’ behaviours holds good in every project environment – right from new product development, software development to ETO and EPC environments. It’s easy to pinpoint the reason behind unsuccessful implementation – cherry-picking of solution components. CCPM solution components are built on the strong foundation of sequence logic. Each solution component is built on the success of the previous component. Incorrect sequencing of the components would not bring in any results at all. For example, in an environment of rampant bad multitasking, the reliability of plans is extremely low. So, trying to set up a CCPM planning processii without dealing with the problem of bad multi-tasking would only lead to a lot of hard work in maintaining project plans with nearly no benefit to the actual users. Similarly, in some environments, people favour the rules of common priority and gating policy of full kit but put no effort into implementing the necessary conditions to ensure the reduction of work in progress in different departments. They assume that such a diluted effort will at least give them some benefits. However, efforts to set up a common priority list are only a one-time act. Without WIP control, pressures from different stakeholders force one to change the list, and very soon, the common priority list goes haywire. Erroneous sequencing and cherry-picking of solution components are the main reasons for failure of CCPM implementations. Such approaches also lead people to conclude that CCPM is not applicable to their environment. Surprisingly, there is a pattern even in cherry-picking solution components in these failed implementations. These implementations usually skip the first step of WIP reduction in critical starting departments like design, which calls for freezing of work fronts as per agreed priority and move on to the rule of triggering the start of work based on the rule of ‘one in and one out’. The transition step of freezing work fronts to reduce WIP in the starting departments creates a perception of ‘high risk’, and hence, managers shy away from this step. At times, even consultants perceive this risk and refrain from deploying this step. Is this step of freezing and aggressively reducing WIP risky? Or is it a step necessary to eliminate the risk of the status quo? The best way to find out is to ask every section or department in the current environment to highlight the department’s top three priority projects. One will be surprised to see that the list would widely vary across departments, thus reflecting a huge gap in understanding what is truly important. Since the number of work fronts that one can work on is more than the available resources, at any point in time, there is a small active list and a frozen list (many projects which are not being worked upon) in every department. Often, the frozen list is longer than the active list; the lists widely vary across departments. They keep changing daily causing, overall de-synchronization and delays in every project. So the rules of common priority and restricted WIP bring everyone on the same page, thus improving overall synchronization. These two lists have to be centrally controlled and not left to people at the lowest level of the organization. This in turn facilitates implementation of other steps of CCPM solutions.The sequence of solution implementation holds the key to a successful CCPM deployment. The icing on the nicely conceptualized cake can only be put when the base is ready.Understanding the complete solution is different from understanding the sequence of implementation of the solution components. Mastery of these two know-hows is crucial for any successful implementation.

<h4>Getting CCPM implementation right</h4>

Download PDF

Learn how to achieve successful Critical Chain Project Management (CCPM) implementation with proper sequencing of solution components and avoiding cherry-picking pitfalls.

Let's Empower Growth