Why Most Systems Fail in the 90 Days After Launch

We have argued before that a digital system needs an operating model, because launch is the beginning of the work rather than the end of it. This piece is the practical sequel. It is about the specific window after go-live when workarounds form.

The window is roughly 90 days. Most organisations spend it celebrating and looking away at exactly the moment the outcome is being determined.

This piece is for leaders who have a system launch coming or one that happened recently. We will cover why this window matters, why smaller systems are at greater risk than larger ones, and a 90-day protocol with what to watch in weeks 1, 4, and 12.

Key Takeaways

• Go-live is a technical milestone. Adoption is decided in the weeks that follow, when the project team has usually moved on.
• Behavioural research puts habit formation at a median of 66 days, which is why a 90-day window is the right frame.
• Gartner found that routinising change is roughly three times more effective than inspiring it, and launch-day enthusiasm is the inspirational approach.
• Smaller, non-critical systems are at higher risk than large ones because big systems force their own adoption, and small ones can be quietly ignored.
• Data quality is set by the habits people form in the first weeks. Placeholder values entered in week two are still in your database in year three.
• Three checkpoints are enough: watch for the first workaround, watch for the silence, and watch for what has hardened.

Why 90 days, and not 30 after system launch

The number comes from behaviour.

The best-known research on how long new routines take to stick is Phillippa Lally’s study at University College London, published in the European Journal of Social Psychology. 

Her team tracked 96 people forming a new daily behaviour over 12 weeks. They found that reaching automaticity took on average 66 days, with a range from 18 to 254 days depending on the person and the complexity of the behaviour.

We treat the number as a useful frame. The shape holds, and it explains why a 30-day check is too early to tell you anything durable and a six-month review arrives perhaps too late.

There is a matching finding on the organisational side. Gartner’s research of 426 Chief Human Resources Officers (CHROs) found that when change becomes an instinctive part of how people work, the probability of healthy adoption is three times higher than when leaders rely on the inspirational approach.

Only 32% of business leaders say their most recent change achieved healthy adoption. As you can see, we’re still largely stuck on inspiration pathways.

Small systems fail a lot more

A large system forces its own adoption. Nobody can decline to use the new ERP because you cannot raise an invoice without it.

A smaller system has no such forcing function. A new internal portal, a reporting tool, a module that covers one team’s process… All of these can be ignored indefinitely. For several weeks, nobody noticed.

So the attention is inverted. Companies pour post-launch energy into the big systems that would survive anyway, and give almost none to the small ones that die in silence.

Three things make the smaller rollout harder, and they are rarely acknowledged.

1. The fear is more personal 

In a company-wide transformation, everyone is in it together, and that shared experience normalises the discomfort. When a tool changes the work of four people, those four are alone with it. 

If the system automates part of what someone does, the threat is specific and it has a name. People in that position comply visibly and continue the old way quietly, which is far harder to detect than open objection. 

This is the ground that people readiness is meant to cover, and it gets skipped most often on the projects that look too small to need it.

2. The levels are in conflict 

Management sees efficiency. The people doing the work see a change to how their competence is measured. On a large programme, that gap gets addressed because it has to be. On a small one, it goes unspoken.

3. Nobody owns it 

A major programme has a steering group and a sponsor. A small system has someone doing it alongside a full workload.

Prosci’s benchmarking research, which has run since 1998, has found active and visible sponsorship to be the top contributor to success in every single study. In fact, 79% of projects with highly effective sponsors met or exceeded objectives, compared to 27% where sponsorship was weak.

Small projects are where sponsorship is thinnest, which is exactly where this research says it costs the most.

The 90-day system post-launch protocol

Three checkpoints. Each one has a thing to watch and a decision to make.

Week 1: Watch for the first workaround

People are doing real work in the system for the first time. The first workaround will appear this week, and what happens next sets the rule for everything that follows.

Watch for where it appears and what the manager does about it. A quiet “let us put it in the system first, then talk about the gap” protects the data. Saying nothing teaches the team that the parallel spreadsheet is acceptable. That lesson spreads within days.

Also, watch where the “how do I” questions cluster. Questions concentrating on one step usually indicate a design problem rather than a training problem.

The decision: Set a retirement date for the old way and name it publicly. As long as both routes exist, people will take the faster one, and in week one, the old one is always faster.

Week 4: Watch for the silence

The project team has moved on. Support tickets are falling, and someone in a steering meeting reports that as good news.

Falling tickets mean one of two things. People have learned the system, or people have stopped asking and started working around it. The difference is visible only if you look at usage alongside tickets.

• Watch usage by team rather than in aggregate, because an average will hide the one team that has opted out. 
• Watch the correction rate, meaning how much data gets edited or reversed shortly after entry. 
• And watch for placeholder values, the dummy entries people use to get past a required field they cannot complete. 

That last one is how a process gets adopted on the surface while the data underneath it goes wrong, and it is why minimum viable data standards need to be agreed upon before launch rather than after.

The decision: Pick the single worst point of friction and fix it visibly, this month. One repaired annoyance buys more adoption than any additional training session, because it proves someone is listening.

Week 12: Watch for what has hardened

You are now at the habit horizon. Broadly, what people are doing in week 12 is what they will be doing next year.

• Watch whether the system settles arguments. If two people in a meeting still arrive with different numbers from different places, the official source has not been accepted and parallel reporting has already started.
• Watch whether the reports the system was built to produce are actually trusted enough to act on. 
• And check whether a named owner is still in place, or whether ownership evaporated when the project closed, which is the most common ending and the one that produces an orphaned system three years later.

The decision: Formally hand ownership to a named person, with a time to do it. If no name can be found, that is the real finding, and it is better to know it in week 12 than in year two. Clear ownership is what separates a system that improves from one that merely survives.

The Net Group view: The project ends, but the system does not

Most of what goes wrong in the first 90 days is cheap to fix and expensive to discover late.

A workaround caught in week one is a conversation. The same workaround found in month nine is a data cleanup, a retraining exercise, and a credibility problem for the next system you try to introduce.

We ask clients about this during analysis because the questions are cheapest to answer before anything is built.

• Who owns this after launch?
• What happens the first time someone works around it?
• What comes off the team’s plate while they learn.

Those answers belong in the plan.

A go-live deserves a celebration. It is genuinely hard, and the people who got there earned it.

But afterwards, think about week 1, week 4, and week 12. Put a name against each one. That is the entire protocol.