Blog

Why technology projects fail before implementation starts

---

Most of the failed technology projects I have seen were not technical failures.

The software worked. It did roughly what the contract said it would. Somebody accepted delivery, somebody signed the invoice, and eighteen months later the thing is either unused, half used, or quietly being worked around by people who have gone back to the spreadsheet.

That is an uncomfortable observation, because it means the failure was decided long before implementation started. Usually before the supplier was appointed. Sometimes before anyone had written down what problem was being solved.

The four things that decide it

I have watched this pattern in commercial businesses, in central government programmes and in small charities. The scale changes. The causes barely do.

Nobody agreed what the problem was. This sounds too obvious to be true. It is astonishingly common. A project gets approved because something is clearly wrong, and the business case describes a solution rather than a problem. Ask five people in the room what the project is for and you get five answers, all reasonable, none the same. Nobody notices because nobody asks, and disagreement at that stage feels like obstruction.

Two departments wanted different things and it was never resolved. Finance wants control and reporting. Operations wants speed. Whoever holds the budget wins the requirements document, and the other party goes quiet rather than escalating. They do not stop wanting the other thing. They just stop saying so, and they express it later by not using the system.

There was no owner. There was a project sponsor, which is not the same. The sponsor approves and reports. Ownership means somebody whose working life gets worse if this fails, who is in the room for the awkward decisions and who is still there in a year. On the projects that went well, I can name that person. On the ones that did not, the question produces a pause.

Training happened once, in a room, and was never mentioned again. People were shown the new system on a Tuesday in March. By June there are three new starters who were not there, the person who ran the session has moved on, and the workaround has become the process.

None of that is technology. All of it is decided before a supplier is appointed.

What government programmes teach you about this

I spent part of my career leading public sector programmes, including rationalising 41 government websites and their content management systems. Programmes of that shape have a particular quality: you cannot quietly shelve them. There are stakeholders who do not all want the same outcome, there is public accountability, and there is no version of failure that stays inside the building.

That changes how you think about risk. The delivery risk is real, but it is rarely the largest one. The larger risk is that you build the right thing for an organisation that cannot absorb it, and everybody is too committed by then to say so.

You learn to spend an unreasonable amount of time on the part before the build. Who has to agree. What happens to the people whose jobs change. What the thing is actually for, in one sentence, that everybody in the room will sign.

It feels slow. It is much faster than the alternative.

The awkward version

Here is the part that tends to land badly in a review meeting.

A lot of the projects that get written off as failures were technically fine. The software did what it said. Nobody changed how they worked, so nothing improved, and the software took the blame because it was the only part of the whole arrangement with an invoice attached to it.

The supplier is a convenient defendant. They are external, they were expensive, and they are not in the room. Sometimes they genuinely did a poor job. Often they built precisely what an organisation asked for at a point when the organisation did not know what it needed.

I am not making a case for suppliers here. Plenty deserve the blame they get. I am making a case for being honest about which failure you actually had, because the two have entirely different fixes. If the supplier was the problem, change the supplier. If the organisation was the problem, changing the supplier gets you the same outcome eighteen months later at a similar price.

What to do before you commit

Not a methodology. Four questions, asked before the budget goes anywhere.

Can everyone in the leadership team write down what this project is for, separately, and produce roughly the same sentence? If not, you are not ready. This takes ten minutes and I have seen it stop projects that had already been approved.

Who owns it, and will they still be here in a year? If the honest answer is that it is being run by an enthusiastic person with no authority, or by a committee, that is your first risk and it is bigger than anything in the technical specification.

What has to change about how people work, and who is going to make that happen? If the answer is that the new system will handle it, the project is already in trouble. Systems do not change behaviour. People with authority and a reason do.

What would tell us, six months in, that this is not working? Agree it now, while everyone is calm and nobody has anything invested. This is the single most useful thing a board can insist on, and almost nobody does it, because at approval stage everybody wants to be positive.

Where I sit on this

I have no software to sell, no reseller agreements and no platform commissions. That matters here more than it sounds, because the question of whether a project should proceed at all is one that almost nobody in the room is free to answer honestly. The supplier wants the work. The internal champion has staked their credibility. The board has already been told it is a good idea.

Somebody has to be able to say the timing is wrong, or that the problem underneath is a process problem that no system will fix. That is most of what independent advice is for.

The organisations that get this right are not the ones with the best technology. They are the ones that did the unglamorous thinking first, agreed what they were actually trying to change, and were willing to hear that the answer might be smaller and duller than the one they had budgeted for.

---

If you are approving a significant technology investment and want an independent view before you commit, a digital maturity assessment looks at whether your organisation can absorb the change you are planning. If the concern is the supplier rather than the project, an independent supplier review is the closer fit.

---