Blog
Good systems rarely fail at go-live. They fail in the quiet months afterwards, when the people doing the work go back to the spreadsheet because the system was chosen for them rather than with them. What prevents it is involving the team while the decision is still open: describing the process, trying the shortlisted options on real work, and changing the requirements when they object. That costs days, or weeks on a big system, against the full price of a system nobody uses.
I have never seen technology rejected by a team that helped choose it.
I have, however, seen plenty of good systems die. And in forty years, I do not think I have ever watched one fail at go-live. Go-live is the safest day in a system's life: everyone is watching, the consultants are still in the building and there is cake. The failure comes later, in the quiet months, when nobody is looking and the old spreadsheet starts filling up again.
Every organisation that has "successfully implemented" a system it does not really use has the same tell: somewhere, a spreadsheet is doing the actual work. The system gets updated afterwards, grudgingly, for reporting, which means the expensive new platform has become an elaborate way of retyping a spreadsheet.
It is worth being precise about what that spreadsheet is. It is not sabotage and it is not stubbornness. It is a verdict. The people doing the work have run a practical trial of the new system against their actual day, and the system lost. They will not say so in a meeting, because the meeting was where everyone agreed the project was a success. So the verdict gets delivered the only way frontline verdicts ever are: silently, in behaviour.
The phrase that guarantees this outcome is usually said early, at the buying stage, when someone raises the question of the people who will use the thing daily. "The team will adapt." Four words that reclassify the actual users of the system as an implementation detail. The project then optimises for the demo, the features and the price, and the one factor that decides whether any of it gets used is left to hope.
The standard objection is that everyone knows this, which is why projects have change management: the workshops, the champions, the newsletter. But most change management is performed on people, after the decision, to gain their acceptance of it. That is not involvement. That is marketing, and the team can tell the difference immediately, because everyone can tell the difference between being consulted and being informed.
Involvement means the team is inside the decision while it is still a decision. They help describe the process the system must serve, because they are the only people who know it, including the workarounds that never made it into any manual. They see the shortlist, try the candidates on real work and say which one fits. Their objections change the requirements rather than being managed. By the time the system arrives, it is not the thing management bought. It is the thing they chose, and people do not run shadow spreadsheets against their own decisions.
The community foundation I worked with on a major system replacement did this properly. The team that would live in the system daily helped map the process first, and their knowledge reshaped the requirements before a single vendor was scored. Alongside the build, the investment went into coaching the team itself, so that when the consultants left, the capability stayed. Years on, the system is used, not merely installed, and the organisation runs its own digital decisions instead of renting that judgement forever.
The pattern holds at any size. A charity website built on research with the people who use it gets used. A system chosen with the team that operates it gets operated. None of this is complicated. It is just slower at the start, which is exactly where projects are least willing to be slow.
Here is the arithmetic that should settle it. Involving the team properly costs days. Weeks, on a big system. A system that is paid for, installed and quietly unused costs its entire price, plus the years of the problem staying unsolved, plus the harder-to-count cost that the next project inherits a workforce that has learned new systems are done to them.
Days, against all of that. It is the cheapest insurance in technology, and it is routinely declined by people who would never skip insurance on anything else they bought at that price.
So before the contract is signed, one test: can the people who will use this daily name the problem it solves for them, in their own words, and did anything in the requirements change because of something they said? If yes, buy with confidence. If no, you are not implementing a system. You are scheduling a verdict.
That the people doing the work have tested it against their actual day and it lost. The system then gets updated afterwards for reporting, which turns an expensive platform into a way of retyping a spreadsheet.
No. Most change management happens after the decision, to win acceptance of it. Involvement means the team helps describe the process and choose the system while the choice can still change.
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