I've been involved in over a hundred digital projects across New Zealand. Some we built. Some we inherited. Some we were brought in to rescue. And the thing that strikes me, every single time, is how predictable the failures are. Not the technology. Not the budget. The patterns. The same mistakes, made by smart people, over and over again.
What You Need to Know
- Only 16% of enterprise IT projects complete on time, on budget, and with full scope delivered
- The root causes are almost never technical. They're structural: unclear outcomes, absent users, and rigid processes
- Methodology doesn't save projects. Clarity of purpose and constant feedback do
- The organisations that succeed treat delivery as a partnership, not a procurement
The Numbers Are Damning
16%
of enterprise IT projects completed on time, on budget, and on scope
Source: Standish Group CHAOS Report, 2018
Let that sit for a moment. Sixteen percent. That means five out of six projects either blow past their budget, miss their deadline, drop scope, or fail outright. Over 31% are cancelled entirely or deliver nothing usable.
$1M+
average cost overrun for large IT projects, with some exceeding 200% of original budget
Source: McKinsey & Company, Delivering Large-Scale IT Projects On Time, On Budget, and On Value
These aren't small numbers. And they aren't new numbers either. The Standish Group has been tracking project failure for over two decades, and the needle hasn't moved as much as you'd expect given how much the industry talks about improving delivery.
The Five Patterns That Kill Projects
After enough projects, you start seeing the same failure modes everywhere. They aren't random. They're structural.
1. No Clear Definition of Success
The most common problem, by a mile. A project kicks off with a vague brief: "we need a new platform" or "we need to modernise our systems." Everyone nods. Nobody defines what success actually looks like.
Without a clear, agreed definition of success, every decision becomes a negotiation. Scope creeps because there's no boundary. Stakeholders add requirements because there's no filter. And six months in, the project is building something nobody asked for because nobody was specific enough at the start.
2. Users Are an Afterthought
The people who'll actually use the system are consulted at the beginning (if you're lucky) and then not again until UAT. By then, the fundamental decisions have been made. The architecture is set. The interface is built. And the feedback you get is "this doesn't work how we work" - which is a design problem masquerading as a testing problem.
If the people who'll use the system every day aren't in the room every fortnight, you're guessing. And guessing at enterprise scale is expensive.
Isaac Rolfe
Managing Director
3. Risk Surfaces Too Late
Most enterprise projects save risk discussions for steering committee meetings. Monthly, if you're lucky. Quarterly in some organisations. By the time a risk is formally raised, it's usually already a problem.
The projects that work surface risk weekly. Not in a formal, bureaucratic way. In a "here's what we're worried about, here's what we're doing about it, here's where we need a decision" way.
4. All Plan or All Flexibility
The industry has split into two camps. Waterfall gives you certainty at the start and rigidity at the end. Agile gives you flexibility throughout but often no clear destination. Both fail for the same underlying reason: they prioritise the process over the outcome.
5. Design Treated as a Skin
Engineering builds the system. Design makes it "look nice" at the end. This is still shockingly common in enterprise projects, and it produces systems that technically work but nobody wants to use. When design isn't in the room from day one, the architecture makes decisions that constrain the user experience in ways that can't be fixed with a coat of paint.
What We Do Differently at IDESIGN
I'm not going to pretend we've cracked the code. But after seven years and more than a hundred projects, we have a delivery track record we're proud of. Every project delivered. Every one. Here's what we think makes the difference.
We define success before we write a line of code. Not in technical terms. In business terms. What does this change for your organisation? How do you measure it? What does the world look like when this is done?
We put users in the room, and keep them there. Not a one-off workshop at the start. Regular, ongoing contact with the people who'll live inside the system we're building.
We surface risk in real time. Weekly. Openly. With the client, not about the client. If something's going sideways, we say so early enough to do something about it.
We blend planning and flexibility. Know the destination. Build in stages. Get feedback constantly. Don't dogmatically follow a methodology when the project is telling you something different.
We design and build together. Strategy, design, and engineering in the same room from day one. Not handed off between teams. Integrated.
It's Not About the Methodology
The project management industry has spent decades trying to solve this problem with better methodologies. Better processes. Better frameworks. And the numbers haven't changed much.
12%
of total project investment wasted due to poor delivery performance
Source: PMI Pulse of the Profession, 2018
That's because the problem isn't the methodology. It's the relationship between the people building the thing and the people who need the thing. When that relationship is transactional - vendor delivers, client accepts - projects fail. When it's a genuine partnership, with shared understanding, shared risk, and shared accountability, projects succeed.
The methodology matters. But it matters less than most people think.
This is the first in a series of posts about how we approach enterprise delivery at IDESIGN Media. We've learned a lot over the last seven years, and it's time we started sharing it.