Understanding why some CCPM implementations fail to deliver the promised results. The logic of CCPM appeals to common sense. The damages of bad multi-tasking and “date-driven” behaviour are irrefutable to a logical person. Every CCPM workshop is successful in conveying the logic of the new paradigms. However actual implementations have mixed results. There are a significant number of implementations worldwide, which do not deliver any discernable improvements in lead times (reduction in inventory) and output. At the same time, there are many others with huge improvements. These two categories of implementations have typical and predictable responses whenever you seek to study the actual improvements. Surprisingly, even in implementations without results, the protagonists of the change talk in terms of intangible yet vague improvements like “improved visibility”, “discipline of planning” and so on. Ask questions on concrete improvements, in terms of reduction in lead-time (or inventory) and improvement in output, and they have an excuse for calculation complexity due to the wide variety in product mix. On the other hand, the users, in such assignments, have a different point of view – they see the CCPM processes as more of a burden, while the priority conflicts still remain at the resource level for their day-to-day work. The top management has a “mixed feeling” – the project plans and updates give them a feeling of improved “systematic” working but at the same time, they still suffer from the age-old problem of weak control – the issues causing significant delays are brought to their notice very late. They have the same feeling of “people-not-being-proactive-enough” as before the implementation. The experience of hugely successful implementations is vastly different. The best way to understand the impact is to seek  informal feedback from the lowest-level resources in the design department. They will invariably talk about a dramatic change in their environment – they are able to work without being pulled in different directions and at the same time issues get resolved at a much faster pace. They experience a condition of “flow” – working with much-reduced interruptions, while each one of them feels more productive. In such environments, the data of actual improvement is also much beyond the noise of product mix. The improvement at the global level is never debatable. The top management gets a feeling of real control as they see the organization always ready much before the critical customer deadlines. The 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’s 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” behaviors hold good in every project environment – right from new product development, software development to ETO and EPC environments. The main reason for such differing results is what we call the “cherry-picking” of solution components for implementation. The CCPM solution components are built on a strong foundation of sequence logic. Each solution component is built on the success of the previous component and the wrong sequence of implementation results is no overall improvement. For example, in an environment of rampant bad multitasking, the reliability of plans is extremely low- so trying to set up a CCPM planning process without dealing with the problem of badmultitasking only leads to a lot of hard work in maintaining project plans with nearly no benefit to the actual users. Similarly, in some environments, people like the rules of common priority and gating policy of full kit but put no effort into implementing the necessary conditions to ensurethe reduction of work in progress in different departments. They assume that such a diluted effort will at least give them some benefits. However, all efforts to set up a common priority list are only a one-time temporary act. Without  WIP control, the pressures from different stakeholders force one to change the priority and very soon the common priority list goes haywire. The erroneous sequencing and cherry-picking of solution components are the main reasons for the failure of CCPM implementations. Such erroneous implementation approaches also lead people to conclude that CCPM is not applicable to their environment. Surprisingly, there is also a pattern even in “cherry picking” of 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 rule of triggering the start of work based on the rule of “one-in-and-one-out”. The transition step of freezing 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 similar risks and stay away from deploying this step. Is this step of freezing and aggressively reducing WIP a very risky approach? Or is it actually a step, that dramatically reduces the current ongoing risk of the status quo? The best way to check is to ask every section or department in the current environment to highlight the top 3 priority projects of their department. One will be surprised to see that the list is widely varying across departments and thus reflects a huge gap in understanding what is truly important. Since the number of work fronts that one can work upon is more than the available resources, at any point in time, there is small active list and many projects, which are not being worked upon – “the frozen list” in almost every department. Having a frozen list bigger than the active list already exists! And people decide on it at the lowest level of the organization. The real problem is that the active and the frozen list is widely varying across departments and keeps changing on a day-to-day level causing overall de-synchronization and delays in every project. So, the rule of common priority and strict WIP rules actually brings everyone under the same platform of what should be done and what should not be done, thus improving overall synchronization. Management of these two lists is centrally controlled rather than leaving it to be changed rampantly at the lowest level of the organization. This in turn brings an ability to implement 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 and any attempt to violate this sequence can be a disaster. Understanding the complete solution and understanding the sequence of implementation of the solution components are two different know-hows! Mastery of these two know-hows is crucial for any successful implementation.

BA Read More

Problem – Many project management transformations fail because organisations “cherry-pick” components, applying tools out of sequence. This leads to low reliability, continued multitasking, weak synchronisation, and no tangible improvements.<o:p></o:p><o:p></o:p> Solution - Adopt a structured sequence of implementation—starting with reducing work-in-progress and aligning priorities across departments. Centralising control of active vs. frozen tasks ensures synchronisation and creates the foundation for further improvements.<o:p></o:p><o:p></o:p> Benefits - Teams experience smoother workflows, fewer interruptions, and faster resolution of issues. Management gains real control, lead times shrink, and projects are consistently delivered ahead of deadlines with less chaos.

Key Takeaways

The success of Critical Chain Project Management (CCPM) implementations hinges on the sequence and completeness of solution components. Successul implementation results in improved workflow and productivity, while failure precipitates resource conflicts and lack of control.

Egg before the chicken?

Understanding why some CCPM implementations fail to deliver the promised results. The logic of CCPM appeals to common sense. The damages of bad multi-tasking and “date-driven” behaviour are irrefutable to a logical person. Every CCPM workshop is successful in conveying the logic of the new paradigms. However actual implementations have mixed results. There are a significant number of implementations worldwide, which do not deliver any discernable improvements in lead times (reduction in inventory) and output. At the same time, there are many others with huge improvements. These two categories of implementations have typical and predictable responses whenever you seek to study the actual improvements. Surprisingly, even in implementations without results, the protagonists of the change talk in terms of intangible yet vague improvements like “improved visibility”, “discipline of planning” and so on. Ask questions on concrete improvements, in terms of reduction in lead-time (or inventory) and improvement in output, and they have an excuse for calculation complexity due to the wide variety in product mix. On the other hand, the users, in such assignments, have a different point of view – they see the CCPM processes as more of a burden, while the priority conflicts still remain at the resource level for their day-to-day work. The top management has a “mixed feeling” – the project plans and updates give them a feeling of improved “systematic” working but at the same time, they still suffer from the age-old problem of weak control – the issues causing significant delays are brought to their notice very late. They have the same feeling of “people-not-being-proactive-enough” as before the implementation. The experience of hugely successful implementations is vastly different. The best way to understand the impact is to seek  informal feedback from the lowest-level resources in the design department. They will invariably talk about a dramatic change in their environment – they are able to work without being pulled in different directions and at the same time issues get resolved at a much faster pace. They experience a condition of “flow” – working with much-reduced interruptions, while each one of them feels more productive. In such environments, the data of actual improvement is also much beyond the noise of product mix. The improvement at the global level is never debatable. The top management gets a feeling of real control as they see the organization always ready much before the critical customer deadlines. The 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’s 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” behaviors hold good in every project environment – right from new product development, software development to ETO and EPC environments. The main reason for such differing results is what we call the “cherry-picking” of solution components for implementation. The CCPM solution components are built on a strong foundation of sequence logic. Each solution component is built on the success of the previous component and the wrong sequence of implementation results is no overall improvement. For example, in an environment of rampant bad multitasking, the reliability of plans is extremely low- so trying to set up a CCPM planning process without dealing with the problem of badmultitasking only leads to a lot of hard work in maintaining project plans with nearly no benefit to the actual users. Similarly, in some environments, people like the rules of common priority and gating policy of full kit but put no effort into implementing the necessary conditions to ensurethe reduction of work in progress in different departments. They assume that such a diluted effort will at least give them some benefits. However, all efforts to set up a common priority list are only a one-time temporary act. Without  WIP control, the pressures from different stakeholders force one to change the priority and very soon the common priority list goes haywire. The erroneous sequencing and cherry-picking of solution components are the main reasons for the failure of CCPM implementations. Such erroneous implementation approaches also lead people to conclude that CCPM is not applicable to their environment. Surprisingly, there is also a pattern even in “cherry picking” of 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 rule of triggering the start of work based on the rule of “one-in-and-one-out”. The transition step of freezing 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 similar risks and stay away from deploying this step. Is this step of freezing and aggressively reducing WIP a very risky approach? Or is it actually a step, that dramatically reduces the current ongoing risk of the status quo? The best way to check is to ask every section or department in the current environment to highlight the top 3 priority projects of their department. One will be surprised to see that the list is widely varying across departments and thus reflects a huge gap in understanding what is truly important. Since the number of work fronts that one can work upon is more than the available resources, at any point in time, there is small active list and many projects, which are not being worked upon – “the frozen list” in almost every department. Having a frozen list bigger than the active list already exists! And people decide on it at the lowest level of the organization. The real problem is that the active and the frozen list is widely varying across departments and keeps changing on a day-to-day level causing overall de-synchronization and delays in every project. So, the rule of common priority and strict WIP rules actually brings everyone under the same platform of what should be done and what should not be done, thus improving overall synchronization. Management of these two lists is centrally controlled rather than leaving it to be changed rampantly at the lowest level of the organization. This in turn brings an ability to implement 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 and any attempt to violate this sequence can be a disaster. Understanding the complete solution and understanding the sequence of implementation of the solution components are two different know-hows! Mastery of these two know-hows is crucial for any successful implementation.