The first ninety days of a stalled-rollout rescue.

When a live system is failing on adoption, the rescue is not mysterious. It has a shape. And the first ninety days decide whether it works, because that is the window where you either rebuild belief or confirm everyone's suspicion that this was never going to work.

Here is how those ninety days actually go when you do it right. Not a theory. A sequence.

The hardest discipline in a rescue is also the first one: doing less, slower, before you do more.

First, resist the relaunch

The strongest instinct when a rollout is failing is to relaunch it. Bigger push, louder mandate, another round of training. Resist it. You do not yet know what is broken, and a relaunch of the wrong thing just spends the last of your credibility.

A failing rollout has already taught the organization to be skeptical. Another big launch that goes nowhere confirms the lesson and makes the eventual real fix harder.

The first move is not to push harder. It is to find out, precisely, what is actually wrong.

Weeks one to three: find the real break

Spend the first three weeks on diagnosis. Map how the work actually flows now, where usage is dropping, and what the stall is costing in real numbers.

Most importantly, talk to the people working around the system, because they know precisely where it breaks and why. They have been telling you, quietly, for months, through their workarounds.

The output of this stretch is not a plan. It is a diagnosis you trust, with a number attached. Without it, everything after is a guess, and the organization has had enough guesses.

Separate the three failure modes

Stalled rollouts usually fail for one of three reasons, and the fix is different for each. Either the underlying process is broken and no system could save it, or the process is fine but sponsorship collapsed after launch, or both are sound but the people were never made ready.

Diagnosing which one you are dealing with is the whole point of the first three weeks. Treating a process problem as a training problem, or a sponsorship problem as a technology problem, is how rescues fail twice.

Often it is more than one of these at once. The diagnosis is not just naming the break. It is naming which break to fix first.

Weeks four to eight: redesign and re-sponsor

Now you fix two things in parallel, because they fail together. The process and the sponsorship.

On the process side, fix what the system was actually supposed to support, not just the configuration. If the underlying workflow is broken, no amount of better adoption will save it, and pushing people toward something that genuinely does not work will only burn what trust remains.

On the sponsorship side, rebuild the visible leadership backing that almost certainly faded after the original launch. A rescue with a quiet executive fails the same way the first attempt did. The sponsor has to be back in the room, visibly, and the organization has to see it.

Get one win fast

People who have lost faith need to see a win before they will reinvest their energy. So within these weeks, sequence the changes by return and land something real and visible quickly.

It does not have to be the biggest fix. It has to be the most credible one, the change that makes a daily frustration go away in full view of the people who doubted this would ever improve.

That first win does double duty. It improves the work, and it tells the organization that this time is different. Both matter, and the second one is often what unlocks the rest.

Weeks nine to twelve: drive usage and measure

With the process fixed and sponsorship restored, you drive the redesigned way into live operation, manage the resistance that surfaces in real time, and track adoption against the baseline you set in week one.

By day ninety, you should be able to show the curve moving. Not assert that things feel better, show it, against the number you started with.

That measured proof is what converts a rescue from a hopeful effort into a credible turnaround, and it is what buys you the room to finish the job properly.

What separates the rescues that work

The rescues that work and the ones that do not are not separated by effort. They are separated by sequence. The failed ones skip the diagnosis and jump to a relaunch. The successful ones earn the right to act by understanding the break first.

It is the same discipline as any good transformation, just under more pressure and with less goodwill in the bank. Which is exactly why the order matters more, not less.

Pressure tempts you to skip steps. In a rescue, the steps you skip are the ones that already failed the first time.

Ninety days is enough to turn the curve

You will not finish a transformation in ninety days. But you can absolutely turn its direction, and prove that it is turning. That is the goal of a rescue. Not done, but credibly recovering, with the evidence to show it.

From there, the work is the same as it should have been all along: redesign, align, activate, anchor. The rescue just gets you back to the starting line you should have begun from, with an organization that now believes the climb is worth it.

If a rollout in your world is quietly failing, do not reach for a relaunch. Reach for a diagnosis.

The first ninety days are not about pushing harder. They are about finding the real break, fixing it where it actually is, and proving, with a number, that it can be turned around. Do that, and the rest of the work becomes possible again.