Blog
Because the decisions that sink them are made months before anyone builds anything. In most of the failed projects I have seen, the software worked. The organisation never agreed what problem it was solving, two departments wanted different things and nobody resolved it, there was a sponsor but no owner, and training happened once. Before committing, check that the leadership team can each write the same one-sentence purpose, name an owner who will still be there in a year, and agree now what failure would look like.
Because nobody changed how they worked. The software did roughly what the contract said, somebody accepted delivery and signed the invoice, and eighteen months later it is unused, half used, or worked around by people who have gone back to the spreadsheet. The failure was decided before implementation, usually before the supplier was appointed, sometimes before anyone wrote down the problem.
The software then takes the blame, because it is the only part of the arrangement with an invoice attached, and the supplier is a convenient defendant: external, expensive and not in the room. Sometimes the supplier did do a poor job. Often it built exactly what was asked for when the organisation did not know what it needed. The two failures have different fixes. If the supplier was the problem, change the supplier; if the organisation was, changing the supplier gets you the same result eighteen months later at a similar price.
Four things, which I have seen in commercial businesses, central government programmes and small charities alike. Nobody agreed what the problem was: the business case described a solution, and five people asked what the project is for give five different answers. Two departments wanted different things and it was never resolved, so the party that lost the requirements document went quiet and expressed it later by not using the system. There was a sponsor, who approves and reports, but no owner whose working life gets worse if it fails; on the projects that went well I can name that person, and on the ones that did not the question produces a pause. And training happened once, in a room, and was never mentioned again.
That delivery risk is real but rarely the largest one. I led public sector programmes, including rationalising 41 government websites and their content management systems. Programmes of that shape cannot be quietly shelved: the stakeholders do not all want the same outcome, there is public accountability, and no failure stays inside the building. The bigger risk is building the right thing for an organisation that cannot absorb it, when everyone is too committed to say so. So you spend what feels like an unreasonable amount of time before the build on who has to agree, what happens to the people whose jobs change, and a one-sentence purpose everyone will sign. It feels slow, and it is much faster than the alternative.
Four questions, before the budget goes anywhere. Can each member of the leadership team write down what the project is for, separately, and produce roughly the same sentence? That 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? What has to change about how people work, and who will make that happen, given that systems do not change behaviour and people with authority do? And what would tell us, six months in, that it is not working? Agree that now, while nobody has anything invested.
Where nobody else in the room is free to say the project should not go ahead. The supplier wants the work, the internal champion has staked their credibility, and the board has already been told it is a good idea. I have no software to sell, no reseller agreements and no platform commissions, so I can say the timing is wrong, or that the problem is a process that no system will fix.
If you are approving a significant technology investment, a digital maturity assessment looks at whether the 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.
Related evidence: Central government: large scale digital transformation. Later in this journey: What happened when the consultant stopped helping….
Sometimes, but often the supplier built exactly what was asked for when the organisation did not know what it needed. The two failures need different fixes, and changing the supplier only solves the first.
A sponsor approves and reports. An owner is someone whose working life gets worse if the project fails, who is in the room for the awkward decisions and who is still there in a year.
Most clients begin with a conversation. No pitch, no hard sell.
Just a straightforward discussion about where you are and whether I can help.
Book a free 30-minute call