Introduction:

Infrastructure projects are notorious all over the world for never finishing on time. It can be baffling that in spite of the amount of meticulous planning that goes in it, the precise dates that are generated, delays are very soon uncontrollable. Resources work overtime and yet their utilization is poor and the project throughput keeps deteriorating. For some, it has become a way of life. Accepting the fact, that in cases of huge projects over a long period of time, uncertainties are going to come again and again and therefore, it will never be possible to complete the project on time, is one way out. Then we also need to accept that because of the delays, costs are going to escalate, therefore it is also a way of life to end up with huge cost overruns. An example is the Bandra-Worli sea link planned with a cost of Rs. 300 Crores and with a planned finish by 2003, finally ended up 5 years delayed with an actual cost of Rs. 1600 crores. A working paper (reference: Working Paper 181, Delays and Cost Overruns in Infrastructure Projects: An Enquiry into Extents, Causes and Remedies, Ram Singh, Delhi School of Economics) examining delays in projects in India (over a thousand projects spread over 25 years), reveals that projects, on an average, end up taking more than double the planned time.

The surprising part is that, whenever projects are planned uncertainties are taken in to account. Safeties are added, yet delays creep in inexplicably. This leads us to question: Is there anything wrong with the way we manage and execute projects?

If we look at how traditionally projects are managed, it starts with an assumption that if we can maximize the output of each resource in the project we will be able to maximize the overall throughput. This appears to be a logical starting assumption. What this does not take in to account is that uncertainties are inevitable in every project. And whenever uncertainties strike, they will lead directly to a delay, or to some rework which will in turn delay the project. Uncertainties need not be catastrophic, Case Study: In a project for making production shops, all designs were frozen for making concrete columns by a contractor. The columns were designed to take huge load and hence, the reinforcement required was dense. At the time of execution (a month after design), it was realized that it is not possible to pour concrete through the bars tied so densely. So the issue went back to design team who were busy in something else for the next 7 days and so finally after 15 days the new designs arrived. However, by then, because of the assumption that utilization of each resource must be maximized for throughput, the resources for making the columns had been diverted to some other job and hence were not available. At the end of it, the project suffered a delay of a month as result of a rework which should have ideally taken just 7 days to solve had the design team solved this problem first and had the resources been available to execute as soon as the new designs arrived. Or, it could have been 0 days had the execution team done a trial ahead of execution. However, the design team had a schedule to follow (on which other people in the project depended) and had loaded their resources accordingly (again to maximize utilization). To them, the priority of this additional work was low and they did not have resources to spare to address this problem. The execution team too, could not sit idle as that means additional cost for 15 days for nothing (which eventually would have saved an additional cost of 30 days for the entire project)

Now imagine what happens if such minor uncertainties continue to strike a project over a planned period of 2 years (If it strikes 10 times, the delay would be 10 months). And of course, there would be bigger uncertainties to account for – e.g. for marine works a cyclone can set you back by a couple of months easily. If a 7 day delay can cascade to a month, imagine what a 2 month delay can do. So there is actually nothing surprising when a project planned for 3 years ends up taking 8 years to complete.

From the discussion above it is clear that there is something wrong with the starting assumption (Fig. 1). Planning for optimized local performances in the face of uncertainties definitely does not lead to optimizing the cycle time. In fact, this implicitly assumes a deterministic world – uncertainties do not exist – which is against the basic nature of projects. So let us examine what happens when we do not necessarily have to keep our resources busy. Let us assume that the design team had a surplus capacity maintained at all times. Then the problem would have been solved and sent back in 7 days by the surplus capacity. And, suppose, contrary to intuition, the execution team had been kept waiting. Then the delay would have been only 7 days. It however, does seem that under these new assumptions, there is an additional cost of maintaining a surplus capacity everywhere (not only design) which would increase the project cost significantly. A closer examination would reveal that the surplus capacity does not need to sit idle all the time. They can actually help out the design team and accelerate their work under normal circumstances. In fact that would complete all design work faster than planned and there would be no additional cost of the surplus capacity at all! If we summarize the advantages — in the second case delay is only 7 days versus 30 days, and cost increase is due to idle cost of a single team over 7 days versus project delay cost of 30 days.

In addition to the above, what we need to stop doing is trying to predict which uncertainty will strike here and simply assume uncertainties are going to come many times in a project. Therefore putting a buffer time in the project to absorb any such uncertainty which might come, we can now actually create a project plan which is much more predictable (Bigger uncertainties can still strike the project, but definitely the impact on the time line will be minimized).

Now on top of this spare capacity, what if we had a system which provided priorities for each task with each of the teams working in the project based on the global project priorities? So, what each team gets is not a list of tasks with start and end dates which must be met, but a list of tasks with assigned priorities so that they need to concentrate all their resources on the task with highest priority and execute it as soon as possible.

Again, with respect to the above example, the rework would have been the highest priority and hence the design team would have put all their resources (including surplus) on the job and it would have come back in 4 days instead of 7. The execution team could have helped out elsewhere with the understanding that whenever their priority 1 task comes back they are going to start working on it. The delays are even less and there seems to be less idle time as well.

To summarize the above, there are 3 very simple rules which emerge:

Plan work in a way that Work < Resources available; Put a buffer in place for absorbing uncertainties; Follow priorities.

This is what Critical Chain methodology suggests and this enables us to complete complex and large projects on or before time (see Fig. 2).

Figure 1: The above shows a vicious cycle that emerges in traditional project management. Each factor positively reinforces and leads to an exponential increase in delays.

Figure 2: The above shows a Critical Chain causal diagram. The initial assumption helps to arrest the delays and recovery plans allow a goal seeking behavior

Solution Elements:

In this paper, we describe the Critical Chain way of managing and executing large infrastructure projects irrespective of the project type (e.g. EPC Projects, Construction Projects etc)

1. Low WIP plan for execution

• Resource Concentration

Typically in a project, there are a lot of things which have little or no technical dependency amongst themselves. When there is a time limit, it is thought to be unwise to keep these things pending for later and it is generally believed that working on all of them will help us meet the timelines.

Case Study: In a project to make a Shiplift, the different components of the shiplift had to be fabricated. Broadly speaking, it could be broken down in to 13 pieces and each piece can be fabricated completely independently of each other. Detailed work breakdown showed that given the welding and movement requirements (these are huge 50 m by 15m by 10m structures of steel) each piece can be fabricated in 43 days at the minimum. It was decided that 7 days after starting to make the first one, we would start the second and so on. This way, at any point in time there would be 7 such pieces in progress and all 13 pieces would get completed in 127 days. Apart from a lot of handling equipment this task would require around 130 welders.

Right after starting, the execution started running in to problems. Hiring welders was becoming a problem. The first 2 pieces took over 55 days to complete and the remaining pieces, though started within 7 days of each other, were progressing even slower. Lack of progress meant that instead of the planned 7 which were supposed to be in the WIP there were now 9 of them in different stages of progress (and the looming due date meant all 11 had to be started pretty soon). Supervisors were going crazy as work was happening at more places than could be humanly handled. The Project Manager and the experts were having to resolve issues which started coming from everywhere in those open work fronts. Pressure to complete so many of the pieces meant that there was no time to really detail out the processes to be followed and hence, defects were plenty, causing rework. And in all this chaos, welder shortage was still there and becoming more and more acute as the required numbers never
seemed adequate. Within two and a half months of starting the project, the delays were more than 3 months.

The first thing that was done to arrest the slide was to freeze fabrication of all pieces other than 3. The
supervision and the available welders were asked to be concentrated on these 3 only. Daily planning was started to ensure maximum resource loading on each task. The cycle time was reduced to 36 days and the required WIP was lowered to 5 with no additional welder requirement. The project was brought back on track.

As seen from the above example, starting too many work fronts can cause huge delays and take a project to a state of chaos. Delays happen everywhere and very soon after starting, things spiral completely out of control.

• Full kitting:

In projects, while leveling of resources is straight forward, what is not always very apparent is the management bandwidth required to support the activities. A large infrastructure project has many functions supporting execution. Approvals are required from customers, statutory authorities, environmental bodies etc. Design teams have to support execution by supplying designs on time. Designs often depend on type of equipment being procured, as design of equipment to be installed is a necessary input. Top Management is required to take decisions (especially cost decisions). QA is required to inspect and certify various stages. Experts and Project managers are called upon to solve execution issues every now and then (especially when the amount of experience available in lower level of management is low). As a result, when delays occur all these bodies are suddenly bombarded with too many issues and delays start cascading. Interactions between multiple functions in the organization can often be a complicated and painfully long procedure.

On top of this, there is always nonproject related work that these functions have to support, which might often be of higher priority. Therefore, management bandwidth is often stretched thin.

Procurement of material, mobilization of resources, making work fronts available etc. usually, are planned to happen just in time and this generates a lot of ‘Integration Dependencies’. Any of these things, if delayed, can cause interruptions to execution. Interruptions during execution can give rise to many problems:
a) Resources go idle and there can always be a tendency to deploy them elsewhere, thus cascading the delay
b) Pace of execution can get affected due to repeated stoppages
c) In absence of an input and pressure of timelines, execution team might be tempted to break dependencies and proceed without the required input, thus leading to rework later
d) The task manager will be multitasking between getting the inputs on time and supporting execution, thus causing delays to cascade
e) The function (viz. procurement, finance etc.) in charge of the input might also be responsible for providing inputs to the next task, which might get further delayed, thus causing delays to cascade in an unpredictable manner.

A low WIP plan ensures that these types of dependencies are minimized and projects are more predictable. In addition, often a concept called ‘full kit’ is used.

A full kit is defined as the list of things which must be completed to ensure that execution can progress
uninterrupted (excepting in case of uncertainties). This essentially means bunching of all integration and
resource dependencies in to a single integration dependency. By not starting until the Full kit is completed, one can minimize the delays and make the plan predictable.

2. Removing Local measurements

• Buffer and Priorities

Progress in projects can be measured in different ways. However, unless the measure is aligned to the objective of the project it can be misleading. E.g. For completing the Civil Works of a project to make a shiplift 414 marine piles are needed to be driven. However, the completion of the project is driven by 222 of those piles (comes on the Critical Chain)

Suppose that the progress is being measured by monitoring the number of piles completed per week and we find that in the first 3 weeks 100 piles have been completed. Execution Management and other support functions Now let us also suppose that none of those 100 piles are on the Critical Chain. This means that our progress in terms of project completion has been 0 in the 3 weeks, which implies we have delayed our project by 3 weeks though we have covered 25% of the piling scope.

As discussed earlier in this paper, uncertainties are inevitable in projects. In order to absorb delays caused by these uncertainties, we have a project buffer for the Critical Chain and feeding buffers for all the feeding chains.

Critical Chain suggests that the only measure of progress is the progress made on the longest chain of activities in the project.

If we have to understand if the project progress is commensurate to the time lines provided, then we need to further compare this progress with the amount of buffer which has been used up in the process.

In any project, the longest chain will have the highest buffer consumption and all other chains will have lower levels of consumption. It is this measure which is also used to provide priorities to tasks (every task belongs to a chain).

• Vendor alignment

In any large and complex project, there usually are a large number of vendors, contractors and sub contractors. Synchronizing all these parties during execution is a difficult job. Each entity is driven by how they are paid. In case of fabrication works, welders might be paid on weld deposits, which will lead them to doing as much welding as possible every day. The welding might have little to do with overall progress of the project. In case of construction works, a contractor might be paid on amount of reinforcement bars that have been tied. The progress of the contractor again might not be in the same places as needed by the project. When multiple entities have to work together, one will have to create front for the other. There is a lot of co-operation required amongst them.

For example, a civil contractor has to provide windows of time or fronts to an electrical contractor for laying of cables and electrical fitments. The objective of the civil contractor is to finish its part in the project and this means that he would not want to waste days allowing the electrical contractor to finish his job.

In any project, there is only one objective and that is to finish the complete the project on time. It does not help if one contractor delivers its part on time or even ahead of time, if the gains do not translate in to completion of the entire project. So it is important to align all entities in a project to a common goal and a common system of measurement (as discussed in 2a). Contracts need to be designed in a way that payments are made when the project progresses.

Case study: In a project for shipyard (that includes freshwater, sewerage, firefighting, electricity supply, and roads network for the entire production facility), there were 7 vendors involved in the execution of the Services and Utilities work. The work involved constructing a road and laying pipes and cables on both sides of the road.
Here, all the vendors were put on board at the same time and a high WIP execution plan was created. It was assumed that work would progress in a precise manner and one vendor would handover work-front to the next vendor timely and so on. When the plan was put in execution, all seven vendors mobilized their manpower and started the work. Manpower mobilization levels of each vendor were less than requirement as each entity was wary of idle costs due to work front unavailability. Very soon one of the vendors got stuck due to mobilization problems. This led to unavailability of the work-front for remaining vendors. Delays led to pressure from management to mobilize more resources. When the vendors mobilized more and did not want to pay for idling charge (throughput of each vendor is different – one vendor would make the other wait), a decision was taken to open up more work-fronts for them. Newly opened work-fronts led to more problems like:

a) Other work fronts were not ready for execution as material from other project works were piled all over
them, lands were not leveled at all locations
b) Support functions like design had to support more requests. This increased their WIP and they were
delayed in supporting vendors with the designs and coordinates as per their requirement, leading to
more stoppages
c) The work required excavation and the area had a high water table. As a result dewatering systems were
required to dry up areas before they could be worked upon. Multiple work fronts increased the requirement of such systems and started a fight for these systems amongst the vendors.
d) Each vendor started spreading their resources over all locations and that slowed down the progress
everywhere. Idle time increased and sub-contractors found it difficult to maintain mobilization of
manpower
e) There were no priorities. Everything seemed equally important. Issues were generated from each work
front and management bandwidth was too low to support resolution.
f) The total area was around a square mile, and due to work happening in multiple locations, supervision
became difficult leading to less throughput.

All in all, it created a chaotic situation where tasks were being done on multiple fronts on a huge one square mile area, but was not making significant progress anywhere. The project which was planned for 3 months suffered delays of over 5 months and faced a significant rise in costs.

Case Study: In one project, the high level plan is shown in the following figure.

As it can be seen that a number of vendors need to interact and work together in the second phase of the project to complete the project. In that phase, it was planned that civil contractors will provide work front to the contractor for pre-engineered installations, who will provide work front to False ceiling contractor, followed by electrical contractor and equipment vendor and so on. When planning like this, it is assumed that things will progress like clockwork and the transition from one contractor to another will be seamless. The previous example shows that it does not happen like that in reality. The surprising part is that all the concerned entities know this. None of the parties actually mobilize fully unless it is sure that the work front available is enough (no one likes to pay idle cost for resources) for them to make progress. This makes plans obsolete right after starting execution.

Moreover, uncertainties occur in projects thus disturbing the clockwork plan. By that time, if some vendors have already mobilized resources then pressure is high to start some work (as otherwise resources will be idle or will have to be demobilized).

In order to prevent such occurrences in the above mentioned project, the following measures were taken to align the vendors and contractors to the project objective:

Vendor Incentives: For the first phase incentives was offered to the civil vendor for on-time or ahead-of-time completion. This was done in order to ensure adequate work front for all vendors and provide a kick start to theproject (Typically, during the beginning of projects the build up and hence execution is slow)
The second phase was divided in to multiple stages and incentives were declared for all vendors only upon completion of each stage successfully. The risk that incompetence of one vendor can jeopardize the effort of others was compensated by offering a part of the incentive right after mobilization (mobilization level discussed in b)

On boarding meetings: Right after the contracts were awarded, the vendors and sub contractors were asked to sit down with the project team and define a full kit. The full kit contained the work front that the project team must ensure for the vendor/sub-contractor to start, the level of mobilization in terms of material and resources to enable fast execution. It was also decided that the project team is going to regularly update the entities about the agreed work front availability to provide adequate time for mobilization.

3. Minimizing delays

• Rapid Issue Resolution

In a project, execution often gets stalled at various stages waiting for a decision from managers and other
support functions. Design team is required to provide a solution for the technical difficulties faced during
execution. Project managers need to decide on resource mobilization. It is commonly observed that in big
infrastructure projects these support functions sustain multiple work streams at any given point of time.
Whenever an issue reaches them for a decision, it has to wait for some time before it can be attended by the respective person leading to a hindrance in the project progress.

Reasons for delay in issue resolution:

(i) Whenever a technical difficulty is encountered in a project, execution team requires an alternate solution or clearance from the design team to proceed with the execution. Design team is usually occupied with their regular work and it takes them some time before they attend to the ad-hoc request sent by the execution team.

(ii) Every resource mobilization issue requires approval from top management as it has cost implications. For example, even an issue as small as mobilizing few additional welders to expedite work might need approval by the project manager for cost approval. Therefore, issues from all work fronts are escalated to top management making them multitask. This leads to delay in decision making.

Whenever a supervisor faces an issue during execution, he makes an effort to resolve it at his level. Quite often he wouldn’t have a solution ready with him and he would try to explore all possibilities as per his capability. Eventually he would escalate it to the next level and so on. Instead, if he directly escalates the issue to his senior manager it may be resolved instantly through the manager’s experience and knowledge. This can significantly reduce the wastage of time by putting the experience/expert knowledge of senior management to good use.

For example, in our project dealing with construction of a marine civil structure, piling is done in the sea for laying the foundations. During the piling job, the chisel (tool bit) of a piling rig was jammed in the soil. The supervisor wasted 12 hours trying to resolve the problem on his own through experimentation. Later, he escalated the issue to his manager who proposed a solution immediately. Had the issue been escalated sooner, they could have saved 12 hours. Thus, having an “issue escalation process” as above in place can save valuable project time. This is known as “Rapid issue resolution”.

Empowering middle level management to take cost decisions based on the criticality of the chain is needed to ensure smoother execution of the project. Whenever a critical task is hindered and delays the project, respective manager should be allowed to take cost decisions to expedite it. It not only reduces the waiting time for that task but also reduces the WIP for the top management. Their time can hence be utilized in resolving higher priority issues to ensure uninterrupted progress.

Moreover, in order to resolve design issues faster, one needs to have dedicated design capacity to support execution issues and resolve them.

• Task preparation

The best way to execute a task is to do it in the minimum time possible without any stoppages. Planned
durations are just estimates put at the commencement of the project. When the task nears execution, it is
possible to plan for executing the task in the shortest time and identify the requirements for uninterrupted progress. If done a couple of weeks before a task can start, it also provides time to arrange for material or resources or design (in case anything is missing). Especially for the Critical tasks which determine the project due date, this is a tool for protecting the buffer.

When a project enters execution phase, project managers get busy in day to day work and issue resolution. This leaves them with less time to prepare for upcoming tasks. Preparatory activities like detailing out technical procedure to be followed, arranging for all material and resources are not performed prior to starting the task. This leads to frequent stoppages and rework which affects progress.

Task preparation is the process which helps a manager in planning for the upcoming activities, defining all the requirements and subsequently arranging them before starting the work. In the process, a detailed plan is also prepared where aggressive execution targets are set for supervisors to execute on ground.

• Task management

The targets set during the task preparation are reviewed at the task management meeting. It is a forum for daily issue resolution, discussion and review of previous day’s progress and establishing targets for the day. Here, resource allocation should also be done based on the requirement.

4. Recovering Delays

The above solution elements are designed to minimize delays in a project. Critical Chain execution also provides an additional benefit – it brings predictability in the plan under execution. That is why it is easier to plan for delay recovery under Critical Chain than in case of traditional project management.
Supervisor Task manager Project manager Top manager Let us suppose, we are on the 100th day of a 200 day plan and we can see that the project is delayed by 20 days. If the all the chains leading to completion are almost equal in length (a High WIP plan), then recovery actions are required everywhere. Instead, if there is a clear critical chain which determines the end of the project then recovery actions are required at only one place. (Only after a certain level of elevation of the Critical chain is the constraint going to move to another chain).

Case study: In a project for manufacture of 54 hoists (lifting mechanism for shiplift, similar to cranes) the projected delay was around 3 months. The project had a stable critical chain that was on the machining of a particular component and the delay could be precisely predicted because the achieved cycle time was 34 days as compared to planned cycle time of 14 days. The area for improvement was very clear to all and the following actions were taken:

1. The work was being carried out at 4 vendor locations. The project team went to one location and set up a process to minimize wastage, provided tooling for improvement and started close monitoring. Over 14 days a stable process was set up and then they visited other vendor locations to replicate the same process.
2. Number of vendors for machining was increased to 7 as compared to 4 earlier and it was ensured that the established process was followed at the new locations as well
3. The cycle times achieved at each location varied between 12 and 24. Due to a clear critical chain, they always had ample amount of material ready for dispatching and maintain a continuous supply for vendors. (Usually, vendors have a pipeline of jobs and if a work station is starved they immediately load it with other orders, which require a different set up. Once the set up is changed, one has to wait for the next window to get the facility again). Automatically, more drums went to vendors with better results

a) Due Date Importance:
In spite of the predictability, we still need to take a decision whether or not to take a recovery action. Typically, a recovery action involves a change in technology or mobilization of additional resources and very seldom these measures come for free.

Case Study: In a project, 5 vendors were planned to work together for completing the Services and Utilities (Sewerage, Fresh Water, Fire Fighting, Roads and Electrical) in a shipyard. Halfway in to execution, one of the vendors ran in to an internal cash flow problem and its mobilization of material and resources started falling behind the requirement. As other vendors depended on its execution, the entire project started getting more and more delayed by the day.

The options that the top management had was either to find an alternate contractor (an additional cost to the tune of Rs. 12 Crores ($2.7 Million)) or take charge of all payments at site to the sub contractors, procurement of material and resources and later deduct them from the payment to the vendors and bear the additional cost (to the tune of $ 1 million).

However, in the absence of any fixed order at the end of shipyard construction the due date had no meaning in monetary terms. That made it difficult for them to take this cost decision as they wanted to minimize investment in absence of a business. The entire project got delayed finally due to this and the importance of due date was compromised by the top management.

Not all projects are like this. There might be other projects where after creation of the infrastructure, the business is assured. E.g. In another project for a new yarn unit the importance of the due date is very apparent as the company stands to lose Rs. 2 crore of profit ($450,000) for every month of delay.

In the case of the former, cost decisions should be enabled by the criticality of the top chains in the project. That would have happened if there was a business plan which is part of the project plan. In absence of business, the plan itself would provide priorities to the project chains and indicate whether or not they are critical and worth taking a cost decision.

b) Cost Buffer:
One of the major determinants of recovery actions is quick and correct cost decisions. In traditional project management, because of the nature of the plan this decision is not straightforward. As a result, in order to spend any extra money during execution decisions have to go all the way to the top management, who would take decisions after a lot of deliberations. This not only delays recovery actions but also because of the inherent uncertainty of project plans often do not help. The result is that towards the end of the project everything becomes critical and the management ends up spending a lot of money in fighting fires.

As illustrated earlier, Critical Chain makes projects more predictable and as a result, the system automatically identifies the chains which would need cost decisions. This enables fast and correct decision making.

In projects, cost overruns are also quite commonplace. The planned cost curve and actual cost curves are shown below.

Cost buffer is the concept of earmarking a fixed amount of money, in the control of the project team, only for the purpose of expediting the project as and when required. Critical Chain indicates the chains on which recovery actions would ensure early completion of the project and so there is very little risk of incurring extra cost unnecessarily. It enables Top Management to delegate the responsibility of taking optimal cost decisions to the project team and also provides the guarantee that recovery actions can be taken for the right reasons.

‍