Why IT Projects Really Fail (It's Rarely the Technology)

There's a post already on this blog about why digital projects fail. It covers the usual suspects — unclear requirements, scope creep, poor communication. All true. But after two decades working inside enterprises, municipalities, and large organizations, I want to go deeper. Because the most dangerous failure modes aren't technical. They're organizational. And they're almost always visible before the project starts — if you know what to look for.

The wrong sponsor

Every project has an executive sponsor. The question is whether that sponsor actually owns the problem, or whether they've simply been assigned to the project.

A sponsor who owns the problem loses sleep over it. They show up to steering committee meetings with opinions. They make decisions quickly because they understand the stakes. They protect the project budget when the CFO comes asking questions.

A sponsor who was assigned to the project sends their chief of staff to the meetings. They approve decisions without reading the briefing notes. When the project hits trouble — and it will — they're nowhere to be found.

I've seen more projects killed by sponsor disengagement than by any technical failure. The warning sign is usually visible in the first kickoff meeting. Watch how the sponsor talks about the problem. Are they describing their pain, or reading from a slide someone else prepared?

Procurement as project killer

In large organizations — especially in the public sector, where I've spent significant time — procurement processes can destroy a project before a single line of code is written.

The problem isn't that procurement exists. Governance matters. The problem is when procurement timelines are completely disconnected from technical reality. A six-month RFP process for a project that needs to be live in four months. A vendor selection framework that evaluates proposals against criteria written two years ago for a different problem. A contract negotiation that introduces requirements the technical team has never heard of.

By the time the project actually starts, the window has often closed. The business need has evolved. Key stakeholders have moved on. The budget has been reforecast. And the team is expected to deliver against requirements that no longer reflect reality.

The fix isn't to skip procurement — it's to involve technical leadership in procurement design, not just procurement execution.

The committee that designs by consensus

There is a specific kind of organizational dysfunction that I have watched kill more projects than I can count, and it goes like this: a steering committee is formed. Everyone on the committee has a different definition of success. Rather than resolving that conflict upfront — which is uncomfortable — the committee approves a project scope that is vague enough for everyone to agree with.

The project launches. Decisions get made. Each decision is measured against each committee member's private definition of success. Nobody agrees. The project stalls. Scope expands to accommodate everyone. The budget blows. The timeline slips. Morale collapses.

The technical team gets blamed. The project manager gets replaced. A lessons-learned document is filed. And six months later, the same committee approves the next project with the same vague scope.

The solution requires someone with enough organizational authority to force the hard conversation at the beginning: what does success look like, exactly, and who gets to decide when we disagree? If nobody in the room can answer that question, the project isn't ready to start.

The people who will actually use it

I have been part of projects where an entire system was designed, built, tested, and launched without a single conversation with the people who would use it daily. The requirements came from managers. The acceptance criteria were written by the project team. The training was delivered in a two-hour session the week before go-live.

Then the system went live, and the frontline staff — the ones who actually understood the workflow — found a hundred ways in which it didn't match reality. Not because the developers did poor work, but because no one ever asked the right people the right questions.

User research is not a nice-to-have. It is the foundation of a system that actually gets used. And getting it wrong is expensive — not just at launch, but over the entire lifetime of the system, as workarounds proliferate and adoption stays low.

What I do differently

Before I write a line of code or recommend a technology, I spend time understanding the organizational context of a project. Who is the real sponsor? What is their actual stake in the outcome? How are decisions made, and who has veto power? Who are the end users, and have they been consulted?

These aren't soft questions. They are the questions that determine whether a project succeeds or fails — far more than any technical choice.

After 20 years, I've learned that the best technology in the world cannot compensate for organizational dysfunction. But a well-run project with clear ownership, honest stakeholder alignment, and genuine user involvement can succeed even with imperfect technical choices.

That's the part of consulting that nobody puts in the proposal. It's also the part that matters most.