Why software projects fail (and it isn't the code)

When a software project goes wrong, the official explanation is almost always technical: the vendor wasn't up to it, the technology was wrong, there were integration problems.

It's almost never true. In the failed projects we've been called in to rescue, the code worked. What had failed happened earlier, and was visible from week one.

1. Nobody owned the process

The symptom: eight people in the meeting and none of them can decide. Every decision "needs to be checked." The project advances at the speed of the next steering committee.

When a process has no owner with authority to define how work is done, the software ends up implementing every version of the process at once, so as not to contradict anyone. The result is a system with fifteen configuration options that serves none of the fifteen well.

The early signal: if in week one you can't name the person who signs off on scope, the project is already at risk.

2. Nobody questioned the process before automating it

Many processes contain steps that exist because the previous system demanded them, or because eight years ago something went wrong and a control was added that now protects against nothing.

Automating that crystallises it: the useless step is now faster, more consistent and much harder to remove, because it lives in code.

Before automating, every step has to answer "why does this exist?" It's an uncomfortable conversation — somebody put that step there — and it's where roughly 30% of a project's savings usually surface, before a line is written.

3. Scope was locked for twelve months

In January you sign a document describing what the company needs in January. In March a priority changes. From then on, every necessary change becomes a contractual negotiation, and everyone starts defending the document instead of the outcome.

What gets delivered is exactly what was signed, and it's useless — and both sides are right: the vendor complied and the client didn't get what they needed.

The antidote isn't signing less. It's signing more often, in smaller pieces: four-to-eight-week stages at fixed prices, where priorities get re-ranked at the end of each one with the new information.

4. It was built far from the people who'd use it

The project is defined with management, built for three months, and shown to the team on launch day. That's when the five cases that happen every week and nobody mentioned surface — because to the people doing the work they're so obvious they weren't worth saying.

The healthy version: the person who will use the system sees it in week two, while changing it is still cheap. Not in a formal demo — sitting in front of it, using it.

5. "Done" meant "delivered"

The quietest trap. The vendor delivers, invoices and leaves. The system sits installed while the team keeps using the spreadsheet, because nobody stayed for the three weeks in which the new thing costs more effort than the old one.

A project ends when the old process is switched off. Everything before that is delivery, not adoption. And the adoption stage has to be budgeted from the start, because if it appears as an extra at the end, nobody will pay for it.

6. Nothing was measured before starting

Without a baseline, it's impossible to prove the project worked. And a project that can't demonstrate its return doesn't get a second stage, however well it ran.

It takes half an hour: before starting, write down how many hours the process takes today, how many errors it produces a month, how long one case takes end to end. Three numbers. After go-live, measure again.

What actually correlates with success

Looking back at the projects that went well, they share four things, and none of them is technological:

• An owner with authority, available every week, not only at milestones.
• Short stages that reach production, instead of one large delivery at the end.
• A real user involved from the start, with veto power over what doesn't work.
• A number agreed in advance that defines whether it worked.

None of those four depends on the language, the framework or the vendor. They depend on how the project is set up — and they are, nearly always, the difference between a system that gets used and one that gets installed.

If you have a project that's stretching, or one starting shortly, let's talk for half an hour. Sometimes re-sequencing the stages is enough.