For decades, organizations have debated why projects fail. Perhaps we should spend more time examining what happens after they're delivered.
A statistic that refuses to go away
For much of my career, I've heard some variation of the same statistic: 70% of projects fail.
Sometimes the number is a little higher. Sometimes it's attached to information technology projects, organizational change, or business transformation. And the explanation often sounds familiar: organizations need better project management.
But I've always had a problem with that explanation.
Not because project management doesn't matter. It does. The problem is that we rarely establish what failure actually means.
Did the project fail to deliver? Did it deliver something the business no longer needed? Did people refuse to use what was implemented? Or did everyone do what they were supposed to do, only to discover that the expected business improvement never materialized?
Those are very different problems. Treating them as one failure category makes it difficult to determine what went wrong, much less how to prevent it from happening again.
And there's another problem with that famous statistic.
How certain are we about the 70%?
In 2011, researcher Mark Hughes published a paper in the Journal of Change Management asking whether 70% of organizational change initiatives really fail.
He examined five published instances of the claim and found that they lacked valid, reliable empirical evidence to support that universal failure rate.
That does not mean organizational change is easy. It does not mean projects rarely fail. And it certainly does not prove that the actual failure rate is lower.
It means that a memorable statistic became conventional wisdom without the evidence needed to justify applying it broadly.
There's another distinction worth noticing. A statistic concerning organizational change initiatives is not automatically a statistic about all projects, information technology implementations, or business investments.
Yet those categories can become interchangeable in casual discussion.
And once we're convinced that a fixed percentage of projects fail, it's tempting to search for the one explanation that accounts for all of them.
Poor project management. Inadequate executive sponsorship. Resistance to change. Unrealistic expectations. The wrong development methodology.
Each can contribute to a bad outcome.
None explains everything.
Before deciding why projects fail, shouldn't we establish what we're measuring?
A project can succeed without the business succeeding
Consider a familiar situation.
An organization invests in a new system to improve operating efficiency. The project has an approved budget, agreed requirements, a schedule, and a team responsible for delivery.
The system is implemented. Testing is completed. Employees receive training. The project meets its acceptance criteria and formally closes.
From a delivery perspective, that may be an entirely legitimate success.
But six months later, the anticipated financial improvement hasn't materialized.
The organization is still maintaining duplicate reports. Employees continue using the old process alongside the new system. Decisions still pass through the same approvals. Managers still allocate people and resources the same way.
The technology works. The organization hasn't changed enough to capture the benefit.
Was the project a failure?
Perhaps the investment failed to achieve its intended result. But calling the entire situation a project management failure doesn't identify the cause.
The delivery team might have performed its responsibilities exceptionally well.
The missing work may have belonged to the business.
That distinction matters because organizations tend to apply remedies based on how they define a problem.
If the problem is poor delivery discipline, better project planning and execution may help.
If the problem is an operating model that never changed, a more sophisticated project schedule probably won't solve it.
When the business owned the project
Earlier in my career, it wasn't unusual for managers within the business to manage projects affecting their departments.
We used project management practices. We planned the work, identified dependencies, managed schedules, dealt with risks, and worked through problems as they appeared.
But the people responsible for the operation were often deeply involved in getting the project delivered, because they were also the people who would have to live with the result.
They couldn't simply declare the implementation finished and forget about what happened next.
Now, I'm not suggesting that everything was better back then. It wasn't. There were poorly run projects, unclear responsibilities, difficult stakeholders, and plenty of decisions we might have handled differently with the benefit of hindsight.
Nor am I arguing against professional project managers.
Project management has developed enormously as a profession, and organizations benefit from specialized expertise. Complex initiatives need people who understand planning, coordination, uncertainty, risk, and delivery.
But specialization creates a question that organizations should answer deliberately:
When responsibility for delivering the project is separated from responsibility for operating the business, who owns the connection between them?
A sponsor's name on a document isn't necessarily an answer.
Someone must remain accountable for the business changes that turn a delivered capability into a realized benefit.
The Waterfall story is more complicated than we remember
There's another familiar story in management circles: before Agile, projects followed rigid, linear approaches in which everything was decided at the beginning and nothing changed until the end.
That doesn't describe all the projects I worked on.
We used what would generally be considered traditional or Waterfall-style approaches, and we iterated. People reviewed work. Requirements evolved. We made adjustments when we discovered something wasn't quite right.
It was part of getting the job done.
That doesn't mean traditional sequential development had no limitations. It did, and those limitations could be significant. Agile approaches helped formalize useful practices around feedback, adaptation, collaboration, and incremental delivery.
But the idea that iteration only appeared when Agile became popular is too convenient a version of history.
Methods are useful because they give people a way to organize their work, not because everyone who came before followed an inferior script.
Sometimes an approach fails because it doesn't suit the problem.
Sometimes it fails because the organization applies the terminology without adopting the underlying discipline.
And sometimes the methodology has very little to do with the business problem that eventually emerges.
We learn more by examining what actually happened than by assigning every project to a winning or losing management philosophy.
We managed change before we called it change management
The same observation applies to organizational change.
On larger projects, we spent plenty of time dealing with people, priorities, and competing interests, even when nobody described that work as a separate change management discipline.
There might be a division leader who wasn't convinced the proposed solution would work for his operation. Another region might prefer a different system. Someone else might be concerned about losing authority, disrupting service, or making an existing problem worse.
And sometimes those concerns were perfectly reasonable.
We talked through them. We negotiated. We adjusted the approach where necessary. We tried to get people on board.
Sometimes the conversations were formal. Sometimes progress came from sitting down with someone over dinner and understanding what was really bothering them.
It wasn't especially glamorous.
It was just part of getting the project accomplished.
That doesn't mean we always handled those situations well, or that informal persuasion was a substitute for sound organizational controls.
Modern organizational change management brings valuable research, structure, and repeatability to the work of preparing, supporting, and sustaining change.
But the underlying management challenge didn't suddenly appear when organizations began creating specialized roles and methodologies.
People have always had interests, concerns, expectations, and reasons to question what someone else wants to change.
The important question isn't whether an organization has someone with a change management title.
It's whether the work required to achieve genuine adoption and sustained performance is being done effectively.
Adoption matters. But adoption of what?
Suppose employees accept the new system.
They attend training, complete their transactions, and follow the revised procedures.
Leadership measures adoption and sees reassuring numbers.
But the organization still isn't getting the anticipated result.
What then?
Perhaps employees are using a well-designed tool inside a badly designed process.
Perhaps the technology makes individual tasks faster but leaves the real bottleneck untouched.
Perhaps the promised savings depended on eliminating old activities, and nobody made the decision to stop doing them.
Or perhaps the original business case assumed benefits that were never realistic.
The organization can achieve adoption and still fail to achieve value.
That doesn't make adoption unimportant. It's often essential. Research from Prosci, for example, reports a strong association between effective change management and meeting project objectives.
But association isn't a universal causal explanation, and adoption itself isn't proof of business success.
A better question is whether people are able and willing to work in a way that produces the intended outcome—and whether the surrounding operating system supports them in doing so.
That means examining processes, decisions, incentives, roles, controls, measures, and leadership behavior alongside technology and training.
Acceptance is one part of the equation.
It isn't the entire equation.
New technologies, familiar management problems
Artificial intelligence provides a particularly contemporary example.
An employee uses an AI tool to complete an activity that previously required an hour. Now it takes ten minutes.
That's a meaningful task-level improvement.
But if the resulting work spends three days waiting for approval, what happened to the customer experience?
If employees produce more reports than managers can review, did the organization gain usable capacity or create another queue?
If automated work requires additional verification and correction, what was the net improvement?
These aren't arguments against artificial intelligence.
They're questions about the operating system surrounding it.
Technology can create new possibilities. Organizations still have to decide how to use those possibilities to produce results.
That means understanding the work, redesigning what needs to change, retiring what is no longer necessary, and measuring what happened across the entire process.
The same management challenge can reappear with a different generation of technology.
And if we misdiagnose it, we'll prescribe the same remedies we prescribed before—just with newer terminology.
Perhaps we need several definitions of success
Rather than reducing every initiative to success or failure, organizations could distinguish at least four questions.
Did we deliver what was agreed?
This is the domain of delivery performance: the agreed solution, acceptable quality, cost, time, and risk. It deserves rigorous management.
Did the organization adopt the change?
Are people using the new capability appropriately? Have necessary behaviors, responsibilities, and procedures changed?
Did the operating system improve?
Were bottlenecks removed? Did waiting, rework, duplication, and unnecessary coordination decline? Did decision-making become more effective?
Did the business realize the intended value?
Did customer outcomes, service performance, financial results, risk exposure, or organizational capability improve in the way the investment was meant to achieve?
These questions are related, but they are not interchangeable.
An initiative might perform well on the first two and poorly on the last two.
Another might deliver late but ultimately create substantial value.
Neither situation should be reduced to a simplistic success-or-failure label without understanding what happened.
And measurement shouldn't stop when the project team finishes its work.
Some benefits take time to materialize. Some are difficult to isolate from market conditions or other initiatives. That makes sound measurement more important, not less.
Who stays accountable after the celebration?
The Project Management Institute's 2025 Pulse of the Profession research emphasizes business acumen and project outcomes beyond the traditional measures of scope, schedule, and budget.
That's a useful development.
But better definitions of project success will accomplish little unless organizations also change how they assign accountability.
At the beginning of an investment, leaders should identify the intended business result, its baseline, the operating changes required, and the person responsible for realizing the value.
During delivery, someone must ensure the technical solution and business changes remain connected.
After implementation, business leadership must continue monitoring the results and making necessary adjustments.
Sometimes those responsibilities can sit with the same people.
Sometimes specialization and scale require several different groups.
Either arrangement can work if the connections are explicit and the authority is real.
The problem arises when everyone completes their assigned portion of the work and nobody remains accountable for the overall result.
Maybe we've been asking the wrong question
I don't dismiss project management. I don't dismiss Agile, traditional methodologies, or organizational change management.
They're all useful disciplines when applied appropriately.
What I question is the tendency to mistake the presence of a methodology for evidence that the underlying management problem has been solved.
We can have certified professionals, established processes, sophisticated tools, detailed reports, and a perfectly reasonable explanation for why every participating group did its job.
And still not produce the result the organization needed.
So perhaps we should spend less time repeating a familiar percentage and more time asking what we actually expected the investment to accomplish.
What changed?
What didn't?
What value appeared?
And who is responsible for doing something about the difference?
Before we argue about why projects fail, perhaps we ought to agree on what success actually means.
From delivered projects to realized value
Peloton Consulting helps organizations identify the operating conditions that prevent investments and transformation initiatives from producing their intended business results.