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” behavior 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 significant number of implementations world wide, 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 about the actual improvements.
Surprisingly, even in implementations without results, the protagonists of the change talk in terms of intangibles 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 of calculation complexity due to 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 more of a burden, while the priority conflicts still remain at the resource level for their day-to-day working. The top management have 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 an 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 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 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 holds 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 strong foundation of sequence logic. Each solution component is built on the success of previous component and 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 processwithout dealing with problem of bad-multitasking only leads to lot of hard work of 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 efforts to implement the necessary condition of ensuring the 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 a WIP control, the pressures from different stakeholders forces one to change the priority and very soon the common priority list goes haywire.
The erroneous sequencing and cherry picking of solution components is main reason for 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 start of work based on 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 risk 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, which dramatically reduces the current ongoing risk of 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 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.