Delays are no longer only a project problem

India is entering another large capex cycle. Across manufacturing, infrastructure, healthcare, education, logistics, real estate, energy and process industries, organisations are committing thousands of crores to new plants, facilities, expansions and development projects. These projects are not just engineering or construction assignments. They are tied to revenue plans, capacity creation, market entry, financing assumptions and competitive positioning

When such projects get delayed, the loss is much larger than the visible cost overrun. Revenue starts late, capital remains blocked for longer, market opportunities are missed, and management bandwidth stays trapped in execution issues. Contractors, suppliers, consultants and internal teams remain engaged beyond the planned period. Equipment, manpower and decision-making capacity that should have moved to the next opportunity remain tied to an unfinished project.

In large capital projects, delay is not merely a schedule problem. It is a business problem
‍

Why large projects are difficult to execute

A large capital project is not executed by one organisation. It is a temporary system where the owner, consultants, equipment suppliers, contractors, statutory authorities, operating teams and multiple specialist agencies have to come together for a limited period and work toward one common goal.

But they are not one organisation. Each participant has its own commercial priorities, capacity constraints and business pressures. An equipment supplier may accept an order for one project, but the same supplier may also have dozens of other orders to deliver. Its business objective is to use capacity well, protect margins and keep multiple customers satisfied. A contractor may be working across several sites, trying to maximise billing, maintain cash flow and keep its workforce productive.

These are not wrong intentions. They are normal business realities. The difficulty begins when the project owner assumes that all these independent interests can be aligned simply through more dates, tighter follow-up and stronger pressure.
‍

The usual response: more dates, more tracking, more pressure

Most large projects are managed through a familiar method. The project is broken into detailed activities. Dates are assigned to each activity. These dates are passed on to contractors, suppliers and internal teams. Once execution begins, every missed date creates a new round of review, explanation, revised commitment, escalation and follow-up.

Over time, the project environment becomes increasingly busy. More dashboards are created. More trackers are updated. More meetings are held. More software is introduced. Today, even AI is expected to help synchronise complex execution environments.

But if the underlying execution logic is flawed, better visibility only shows the delay more clearly. It does not prevent the delay from being created.

This is why spreadsheets continue to survive in project environments despite large investments in project management software. A spreadsheet is not sophisticated, but it is easy to change. When plans keep shifting, commitments keep getting revised and dependencies keep breaking, the tool that can be changed fastest often becomes the most practical tool.

This should make leadership reflect. If the plan requires constant rewriting, is the real issue the tool, or the way execution is being structured?
‍

The belief behind many project delays

The deeper issue is a belief issue. Most large capital projects are driven, consciously or unconsciously, by the assumption that if we start more work, push harder, track tighter and keep everyone busy, the project will finish faster.

This belief is rarely stated openly, but it shapes execution behaviour every day. Starting more fronts is seen as progress. A crowded site is seen as momentum. High manpower deployment is treated as acceleration. Detailed activity tracking is treated as control. When delays appear, the usual response is to add more reviews, more follow-ups, more dashboards and more pressure.

But projects do not finish because many things have started. They finish when the right things are completed in the right sequence.

When the system is designed around starting more and keeping everyone busy, it creates a large volume of unfinished work. Civil work starts in several areas, but few areas become fully ready for the next agency. Installation begins, but connected services, access or utilities are not ready. Materials arrive, but drawings or approvals are pending. Contractors show progress, but handovers do not happen cleanly.

From a distance, the project looks active. In reality, the flow toward completion remains weak.
‍

Conflict 1:contractors need billing, projects need handovers

The first major conflict appears at the contractor level. Contractors are often measured and paid on the basis of quantity completed. Naturally, they try to maximise billable progress. If a contractor can work in multiple areas and generate more volume, that becomes attractive. From the contractor’s point of view, this is rational. It helps billing, cash flow and resource utilisation.

But the project does not move forward merely because quantity is produced somewhere. The next agency needs a complete and usable front.

If civil work is partially completed in five areas but no area is fully ready for the next trade, the next contractor cannot execute smoothly. If structures, services or utilities are completed in fragments, subsequent work becomes interrupted. Everyone may show progress, but the project still struggles to move toward completion.

This is a fundamental difference. Contractors are often pulled toward volume. Projects need handovers. When the system rewards volume more than completion, scattered progress increases and real project movement slows down.
‍

Conflict 2:everyone has reasons, so accountability weakens

The second conflict is accountability. In a delayed project, there is rarely one clean reason for delay. A supplier may miss a date because inputs were delayed. Inputs may be delayed because of design changes. Design changes may arise because site conditions or operational requirements changed. A contractor may underperform because the front was incomplete. The owner may push for faster work, but the material sequence may not support it.

By the time the issue reaches a review meeting, everyone has an explanation, and many of those explanations are valid.

This is where conventional accountability breaks down. Management can express frustration, demand revised commitments and escalate the issue, but if the dependency structure remains unresolved, the next commitment is also made on weak ground. The review may create pressure, but it does not create reliability.

Over time, the organisation becomes very good at explaining delays, but not necessarily better at preventing them
‍

Conflict 3:contract dates assume a cleaner world than execution allows

The third conflict is created by the dates themselves. At the planning and contracting stage, dates are often built on assumptions that look reasonable on paper: drawings will be released on time, approvals will not hold up work, vendors will supply as committed, contractors will mobilise as planned, resources will be available when required and site conditions will remain stable.

Large capital projects rarely operate in such clean conditions.

Once one major assumption changes, the effect travels through the project. A drawing delay affects procurement. A procurement delay affects installation. A partial handover affects contractor productivity. A design change affects already planned work. A late equipment delivery changes the commissioning sequence. The original dates begin to fall like dominoes.

At that stage, holding people accountable to the original dates becomes difficult because the commitments were built on conditions that no longer exist. This does not mean accountability is unimportant. It means accountability must be built on a system where reliable commitments are possible.

If every stakeholder’s date depends on inputs outside their control, and those inputs are unstable, accountability will always remain contested.
‍

Why pressure does not solve a structural problem

Most project systems try to control complexity by multiplying local commitments. Every package has a date. Every contractor has a date. Every department has a date. Every missed date creates a revised date.

But the project is not completed by meeting isolated dates. It is completed by maintaining flow across dependencies. When flow breaks, the number of dates in the system does not matter.

This is why increasing pressure often fails .If work has been released before it is truly ready, pressure creates confusion. If resources are spread across too many open fronts, pressure creates multitasking. If contractors are rewarded for quantity rather than usable handover, pressure creates more fragmented progress. If revised dates are taken without resolving the dependency that caused the slip, pressure only creates the next missed commitment.

The belief that more activity means faster completion is therefore dangerous. It pushes the project toward more starts, more open fronts, more local optimisation and more coordination load. The project becomes busy, but not necessarily faster.
‍

The real waste

The waste in large capital projects is not only the money lost after delays occur. It is also the management energy spent working around a system that keeps producing the same delays.

Every review then becomes a negotiation with reality. Every missed commitment needs a new explanation. Every revised date gives temporary comfort, until the next dependency breaks. Over time, the organisation becomes skilled at managing slippages, but not necessarily at reducing them.

This is why the belief matters. The way leaders think about progress eventually becomes the way projects are executed. If progress is seen as more starts, more activity and more pressure, the project will be organised around those signals.

But if progress is seen as completed handovers moving cleanly towards commissioning, the execution system starts asking different questions. That is where the real improvement begins.
‍

‍

‍Read more articles:

Why Software Has Struggled to Deliver in the Construction Industry?

How CCPM and Little’s Law Reduced Cycle Time in Aircraft Maintenance at WR-ALC?

Reducing Cycle Time by 33% at WR-ALC: A U.S. Air Force Case

Solar Projects Don’t Miss Timelines for the Reasons You Think

Critical chain project management (CCPM): why projects remain late and how CCPM actually fixes it?

Why projects are late even when everything seems managed?

Beyond fragmentation: Toyota's cell manufacturing model offers a blueprint for construction

What if our best attempts to minimize time and cost overruns in projects are pointless?

How we can solve the late project problem?

Implementing critical chain in large infrastructure projects

Part 1: Why critical chain is not a science?

Part 2: Who said critical chain is not a science?

Part 3: Let’s make critical chain a science

‍