Why software rollouts stall after go-live

I get called in at roughly two points. Before go-live, when somebody senses that the plan covers the build and not the landing. Or four months after, when the numbers have not moved and nobody can say precisely why. The second conversation is more common and more expensive.

What I have come to believe is that a rollout does not fail because people resist change. That explanation is popular because it is unfalsifiable and it blames nobody in the room. Rollouts fail because of specific structural gaps, and the gaps repeat.

Failure mode one: nobody owns it after go-live

During implementation there is a project. A project has a plan, a named lead, a cadence, and someone whose week goes badly if it slips. At go-live the project ends, and in most organisations nothing replaces it. Ownership diffuses into "the team" or "operations" or, worst of all, "IT".

The test is simple and it is worth running on any system you already have live. Ask who decides, this week, whether a requested exception to the new process is granted. If the answer is a committee, a queue, or a shrug, the system has no owner. It has caretakers.

Failure mode two: the exception queue is really someone's inbox

Every operational system generates exceptions. That is not a defect; it is the nature of live work meeting a rule set. The question is where they go.

The pattern I see constantly is that exceptions nominally go into the system and actually go to a person. Someone knowledgeable and obliging becomes the informal router. It works beautifully, which is the danger, because the workaround is now load-bearing and invisible. Volume metrics look healthy. Nobody is measuring the thing that is holding it up.

Failure mode three: adoption was mandated rather than earned

A mandate produces compliance in the room and reversion outside it. This is not cynicism about people; it is arithmetic. If the new way is slower for the individual doing it and faster only in aggregate, the individual has a rational reason to route around it whenever they are under pressure. And they are always under pressure.

The tell is whether the people who mandated it use it. Not endorse it in a town hall. Open it, read from it, make decisions visibly out of it. When leadership takes its numbers from the new system, the new system becomes real. When leadership still asks for the old spreadsheet, everyone correctly concludes that the spreadsheet is the source of truth.

The mechanism underneath all three

I have been arguing about this with a lean practitioner who runs week-long improvement events, and the argument sharpened something for me. He talks about area ownership: the person on the floor who owns a zone and whose gains hold after he leaves. I had been thinking of ownership as a role, or a behaviour you can train. I now think it is neither.

Ownership is standing — whether a person has enough credit in the organisation to refuse an exception and not be overruled. And standing is bought early, with visible wins, in the period right after go-live when the system still has attention and goodwill. Which produces an uncomfortable conclusion:

The signal that it actually took

The lean version of this signal is that people send you photographs of improvements they made after you left, without being asked. The software equivalent is precise and I look for it specifically:

Somebody builds something on top of the tool rather than around it. A report nobody requested. A field added for a reason the implementation never anticipated. A colleague trained by a peer instead of by you. Building on top means they have accepted the system as the floor they stand on. Building around means they have accepted it as an obstacle to be managed.

Adoption dashboards cannot distinguish those two, because both generate logins.

What I would do differently

One case in particular still instructs me. A client asked me to fix their project management setup — specifically, to make the tool they already had work properly. I did. Ownership got clearer, workflows got standardised, delivery timelines improved by about forty per cent, and everyone was pleased.

I now think I answered the question they asked rather than the one they had. The tool was a poor fit for how that organisation actually worked, and I made a poor fit function well instead of pushing to change it. Fixing the wrong tool well is slower than changing tools once, and it leaves the original mismatch in place to be rediscovered later by someone else.

The lesson I took is that "make this work" and "solve this problem" are different briefs, and it is my job to say so out loud early — even when the first brief is the one being paid for, and even when saying so costs me the easier version of the engagement.