THE REAL REASON PROJECTS FAIL – AND IT IS NOT WHAT YOU THINK

I want to tell you something that most project management literature will not tell you.

Projects do not fail because of inadequate planning. They do not fail because of scope creep, or resourcing problems, or technical complexity, or any of the other causes that tend to appear in post-implementation reviews. These are symptoms. They are the visible manifestations of something that went wrong earlier and at a deeper level.

Projects fail because the people responsible for delivering them do not have accurate information about what is actually happening until it is too late to address it effectively.

This observation comes from twenty+ years of delivering complex, mission-critical programmes across multiple sectors and multiple continents – programmes where the consequences of failure were measured not in budget overruns but in operational disruption, regulatory exposure, strategic setback or in financial hardships and lives. And it holds, in my experience, almost without exception.

The failure process is consistent. A project encounters a problem. The problem is real, but it is manageable at the point when it first appears. The people closest to the problem know it exists. They also know that surfacing it – escalating it to the people who could help address it – carries a risk. It might be interpreted as a performance failure. It might trigger a response that creates more disruption than the problem itself. It might simply not be welcomed in a culture that has learned, over time, to prefer optimistic reports to accurate ones.

So, the problem is “managed” rather than addressed. It is reframed in terms that are technically accurate but strategically misleading. It is absorbed into the project’s contingency. It is kept off the risk register because acknowledging it will require a very uncomfortable conversation.

And then, three months later, it is a crisis.

The pattern is so consistent that I have come to see it as the primary failure mode in project delivery – more common, more costly, and more preventable than any of the causes that typically appear in post-mortems.

It is preventable because the information needed to address the problem existed at the point when the problem was still manageable. What was missing was not information, but the conditions that would have allowed that information to travel quickly and accurately to the people who needed to act on it.  And the missing guardrail? The right people did not know enough to make the right decision to prevent the crisis.

Creating those conditions is harder than it sounds. It requires building a culture in which early, honest escalation is valued rather than penalised. It requires leaders who respond to difficult news with curiosity rather than blame. And it requires decision-makers who can distinguish between a project that is in difficulty and a project that is being managed well – because the management of difficulty, when it is done early and honestly, is exactly what good delivery looks like.

The technical dimensions of project management – planning, scheduling, risk identification, resource management – are important and well understood. The frameworks are mature. The tools are sophisticated. And yet the failure rate for complex programmes remains stubbornly high.

The reason is that the technical dimensions are being addressed in an environment where the social and cultural dimensions are working against them. No planning tool can overcome the problem of a team that will not tell its leaders what is actually happening. No risk register is useful if the culture around it punishes the honest identification of problems.

The real work of project leadership is not in the plan. It is in creating the conditions in which accurate information travels fast enough to allow good decisions to be made at the moment when they can still make a difference. That is harder than any Gantt chart or Status Report. And it is the thing that most consistently determines whether complex programmes succeed or fail.