Beating project deadlines, the CCPM way
– Satyashri Mohanty
Organizations dealing with projects often make the mistake of adapting the same best practices that have been evolved for operation or production environment. Despite knowing that the key commitments of project (time, budget and scope/quality) are all interrelated, control actions are taken as though each of these commitments can be achieved discretely. The framework of Critical Chain Project Management (CCPM) has offered a holistic approach for dealing with project business. A few of its nuances, however, are far from popular.
Project post-mortem and few wrong diagnoses
When it comes to managing time, in hindsight, everybody is wiser. Planning is usually blamed for poor project performance. A post-mortem of project reveals that there was plenty of opportunity for starting many tasks much earlier. It seems that with good time in hand, price negotiation with suppliers could have been better, alternative sourcing was possible, and also scope control would have been much better. All this in hindsight. This newly-gained perspective impacts the next project from the start.
“Start As Soon As possible.” What’s wrong with this approach?
Does starting as soon as possible really help the cause of completing a project early? Not really. More than 70 to 80% of the tasks in a project are not the time-consuming kind. That means starting them early does not reduce the total duration of the project. But can these tasks delay project completion?
Let us take an example that is applicable to most projects such as large green-filed plant projects, high capital expenditure capacity enhancement projects (CPEX ), multi-project EPC business, custom engineered product business. An activity such as ‘designing and release of drawings’ is a basic task in all these. It leads to major tasks like civil construction at site, manufacturing of equipment and parts, procurement of structural and other items, and many service contracts. The task manager (design engineer) responsible for this task usually works on many such tasks, and sometimes across many projects as well. This activity requires inputs from various departments, agencies, suppliers, and often, decisions from top management.
The pressure to begin is relatively higher when it comes to major tasks with longer durations, where the progress of the project can be shown visibly like in civil construction and manufacturing of equipment involving high expenditure. This phase of the project is sort of rush hour for the design engineer. There will be many expediters from subsequent tasks urging the engineer to release drawings so they can start work.
However, these days, designing and release of drawings itself is not a time-consuming task for a seasoned design engineer. What consumes time is the invisible co-ordination required to integrate all inputs into the design. Missing inputs and decisions from clients is a common issue design engineers must tackle.
In the absence of timely inputs, the engineer ends up moving from one design to another not completing any. The task manager too struggles to keep up his credibility in meeting the schedule, and resorts to one of the following.
1) Get relief from expediting pressures by releasing partial drawings so that the subsequent task (civil construction) can start. Of course, this eventually will delay the completion of the task.
2) Create designs based on assumptions (without waiting for actual data), and release drawings with conditions and omissions
3) Pass on drawings that are relatively easy to finalise without much integration of inputs. Tasks on the longest path require relatively higher integration, and are much more difficult to finalise.
Each of the above action has its consequence. Actions 1 and 2 lead to a situation where civil work either slows down or faces interruptions in execution leading to poor utilisation of civil resources. To improve utilisation of civil resources, more civil work fronts are opened. Resultant effect is frequent day to day expediting, priority changes causing bad multi-tasking leading to further interruptions, rework and associated delays. Drawings go through several revisions, creating a perpetual gap between drawings and actual site work. No wonder insisting on ‘as built drawing’ has become a well-set industry practice.
Action 3 leads to a situation where civil, manufacturing and purchase departments manage to get easier designs early; civil work fronts, procurement, and manufacturing items required later in the project are worked upon much ahead of time. Project budget is eaten up by unplanned activities leaving the finance team grappling with fund flow going haywire.
In such project environments, expecting tasks to be completed as per plan is nothing short of expecting to win the lottery consistently. So what goes wrong? Do we stumble on a few missing steps? Let us study this carefully.
Every project goes through the same cycle. Task type could be different but the end consequences are no different. Unlike operations or production environment, task durations of project are not deterministic. Project tasks are not expected to be completed exactly as per planned duration. Even though uncertainty is the hallmark of projects, the level of uncertainty is not the same throughout a project. The level goes higher at integration points. With increased number of predecessor tasks, the probability of timely completion of integration tasks dips drastically (like in the example described above – designing and release of drawings, final assembly and testing, erection and commissioning etc).
Whenever the project flows through these pockets of integration, it experiences turbulence. Flow rate of tasks goes down and remains unpredictable. Not recognising such flow entities that dictate the speed of the project and pushing all tasks results in only negative ramification, thus giving an impression that bad planning is the cause of all failures.
A simple but robust solution
Planning serves its purpose when it helps execution. The overall project progress is usually measured by extrapolating the current rate of task progress to project plan. Decisions are made and corrective actions are taken with the assumption that the rate of task progress will continue. But this assumption is not valid for tasks at integration. Integration tasks never experience linear flow, and task progress remains erratic. This can be solved if there is high synchronisation of inputs from various predecessor agencies/departments. But, in reality, it is not easy for the owner of integration task to manoeuvre different corporate power centres and seek subordination from multiple agencies/departments.
Identify the Flow entities: Before putting the project plan to work and expecting benefits, the first step is to identify the flow entities within the overall project. Tasks demanding high integration of inputs should be examined first. Merit of any task is usually biased by its associated cost, duration, safety risk and many other factors, but never by the level of synchronisation it demands.
Full-kit Gate control: After identifying the flow entity, synchronisation between multiple agencies can be forced in when there is a strong gate after integration point. This can be achieved by not allowing the chosen integration task to release any output discretely to the subsequent tasks (no piece meal), and also not allowing the subsequent work to start until the integration task is complete in full (full-kit).
This action ensures that delay becomes ‘visible’ which in turn triggers expediting and focused management attention at the right time. For example, civil construction is not allowed until the entire set of design and drawings are complete.
Flow monitoring: Full-kit Gate control indeed provides a visual alert for delays. However, if the delays are not prevented in the first place, there will be pressure to break the full-kit rule which would lead to associated problems. Delays in providing and receiving inputs increase when there are loops of iterations (information moving back and forth between agencies and departments). Such task dependencies are difficult to represent in project network. Having daily cross-functional meetings (flow meetings) chaired by an empowered person to resolve open issues can break the loops of iterations.
Project planning: The functioning of a traditional planning team resembles a game of Angry Birds played by a young lad who makes several attempts to hit the target. Planning should help execution, not the other way round. A large project plan with independent task milestones leads to hidden buffers and hinders early detection of issues. Shifting the safeties (buffers) from the tasks to the end of their respective task sequences (paths) conserves overall project safety through the aggregation effect. (Even though project budget is allocated for each task owner, money is not disbursed upfront. Why take chances with time?)
CCPM helps in establishing buffered project plans for each independent area and enables release for execution based on full kit completion.
Project Execution: In a large project, several tasks are executed simultaneously. Every task delay does not delay the entire project. Critical Chain Buffer Management is the only system that provides priority of task according to its impact on the overall project completion. A suitable graph (fever chart) can give a clear picture of the status of all the project areas. Along with monitoring daily flow, monitoring meetings at the ground level, periodic buffer management review by top management to proactively resolve issues benefit the project more than chasing date after date.
CCPM is a holistic approach for managing projects. Vector Consulting Group has demonstrated significant results for its clients in project business by leveraging CCPM philosophies. By implementing CCPM, VCG has achieved 25% reduction in project lead-time, more than 50% reduction in design lead-time with significant reduction in drawing revisions.
Blaming it on Estimation!
If one goes by the widely acclaimed Chaos reports released by the Standish Group, software projects seem to have a dubious record. In 1995, the report highlighted that only 16% of the IT projects were completed on time, within budget with original scope.Read more- Satyashri Mohanty
Egg before the Chicken?
The logic of CCPM appeals to common sense. The damages of bad multi-tasking and “date driven” behavior are irrefutable.Read more- Satyashri Mohanty
Simple Tactics to Double Team Productivity: The science of getting work done on time
In organizations, leaders must get tasks done through their team members. On the surface, this appears to be an easy thing to do, as leaders have formal authority over their team members (by virtue of organizational hierarchy) and so, can simply issue orders to get things done.Read more- Kedar Amdekar