The Dangerous Belief System Behind India’s Recurring Project Delays

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.

The project then enters a continuous cycle of revising dates across agencies and packages. Dates that were intended to provide control begin to generate more negotiation and coordination because each new commitment remains dependent on several other moving parts.

Why pressure does not solve a structural problem

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 Need to Rethink Project Execution

The way leaders define progress eventually determines the way projects are executed. If progress is represented by activity across many fronts, the project will continue to accumulate unfinished work and coordination pressure. If progress is represented by completed handovers that allow the next stage to move without interruption, the project begins to behave differently.

This requires a fundamental rethink of project execution. The question is no longer how to push every stakeholder harder against dates that keep shifting. The question is how to organise execution so that work moves towards completion with greater stability and predictability. For leaders responsible for large capital projects, that is the belief worth examining.

Author: Mohd Aadil Siddiqui, Director – Realization India (www.realizationindia.com )