Guide · Adoption
Make a rollout stick after go-live.
Go-live is where the work starts, not where it ends. Here is why rollouts slide back, the store-team rituals that hold them, and how to measure adoption on the floor instead of installs on a dashboard.
This guide, in 6 parts
Go-live is the start line, not the finish.
Most rollout plans end on the launch date. The screens light up, the project closes, the team moves on. But the tool being on is not the same as the floor using it, and the gap between the two is where the value lives.
The numbers say it plainly. The tools have been piloted and deployed widely, and still the P&L does not move, because installing a tool is not adopting a way of working. The work that closes that gap happens after go-live, on the floor, in the weeks almost nobody resources.
« The tool went live. The work had not started. »
Why rollouts slide back.
Five failure modes behind almost every rollout that went live on schedule and then quietly decayed.
Go-live was treated as the finish line
The plan ended at the launch date. The screens lit up, the email went out, the project closed. But a rollout is not done when the tool is on. It is done when the floor uses it without being asked, and nobody had budgeted for the weeks where that is won or lost.
The person who does the gesture never shaped it
The tool was designed in a room, then handed down to the people who do the actual gesture all day. They were trained on it, never asked about it. So the first time it slows them down on a busy shift, they route around it, and the workaround becomes the real process.
Adoption was declared from the dashboard
The report showed logins, licences, installs, all green. None of those is use. A team can be fully provisioned and still doing the job the old way in parallel, and the dashboard will never see it, because the dashboard cannot watch the floor.
No one owned it the morning after launch
The build team rolled off, the sponsor moved on, and the rollout had no operational owner for the long, unglamorous middle. With nobody to fix the friction, answer the floor and hold the line, the new way decays back to the old one, one tired shift at a time.
The old way was left switched on
The new tool went live beside the old workflow, and the old one still worked. Given any pressure, people fall back to what is faster today, not what is better in three months. A rollout with no plan to retire the old path is a rollout with a built-in exit.
The store-team rituals that hold it.
Adoption is held by small habits repeated on the floor, not by a launch event. These are the rituals we wire into the shift so the new way is simply how the shift runs.
- A two-minute shift huddle that names yesterday's friction and one thing to fix today.
- A visible board on the floor that shows the new way is being used, in view of the team.
- A shift lead who opens the new tool first, so the floor follows the example, not the memo.
- An open idea box, the IKEA method: the person who does the gesture proposes the fix.
- A weekly floor walk that checks the new way is run as designed, not quietly routed around.
- A fast loop that feeds the floor's fixes back into the tool, so input visibly changes it.
- A switch-off date for the old way, known to everyone, so there is no path back to slide into.
The thread through all of them is the same: involve the person who does the gesture. That is the IKEA idea-box method, and it is what turns a handed-down tool into one the floor defends.
Measure adoption on the floor, not in the dashboard.
A dashboard counts installs, logins and licences. None of those is use. A fully provisioned team can still be doing the job the old way in parallel, and the report will never see it. So we measure differently.
What it shows: the tool is installed.
- Logins, active licences, seats provisioned.
- Features clicked at least once.
- Training completed, access granted.
- All green, while the old way runs alongside it.
What proves it: the work changed.
- The gesture is done the new way under real pressure.
- The old workaround has stopped, not just been told to.
- The floor proposes its own fixes through the idea box.
- The number it was meant to move is actually moving.
The make-it-stick sequence.
Five moves, in order. The goal is not a clean launch. It is a floor that runs the new way without being asked, and without us.
Treat go-live as day one, and resource the weeks after it
The launch is the start line. Plan and staff the four to six weeks that follow it as deliberately as the build, because that is when adoption is actually won. Put a named person on the floor for that window, with the time to watch, fix and coach. A rollout that ends its budget at go-live has ended it one step before the work.
Involve the person who does the gesture, before and after
The people who run the new way every day are the ones who decide whether it sticks, so make them co-authors, not recipients. We use the IKEA "boite a idees", the idea-box method we grew on the floor: the person doing the gesture proposes the fix, because they see the friction first and they own what they helped shape. Feed those fixes back fast, so the floor watches its own input change the tool.
Build the rituals into the shift, not the project plan
Adoption lives in small, repeated habits, not in a launch event. A two-minute huddle that names yesterday's friction, a visible board, a shift lead who opens the tool first, a weekly walk that checks it is used as designed. Wire these into the rhythm of the floor so the new way is simply how the shift runs, not a thing layered on top of it.
Measure adoption on the floor, not installs in the dashboard
Stop counting logins and start counting use. Pick two or three behaviours that prove the new way is actually happening, then go and observe them where the work is. Adoption-of-tool is not adoption-of-value, and only the floor tells you which one you have. The device below is how we hold that line in practice.
Hand it to a named owner and retire the old way
Adoption holds when one person owns the running after the build team leaves, with the runbook, the rituals and the authority to keep the floor on the new path. Then switch the old way off on a date everyone knows, because a fallback left running is the thing the rollout quietly slides back into. The goal is a floor that runs it without us, not one that needs us.
The stuck checklist.
A rollout has stuck when it can tick all six. Until then it is live, which is not the same thing.
- The weeks after go-live are resourced, with a named person on the floor for that window.
- The people who do the gesture shaped the tool, through the idea box, before and after launch.
- The rituals are wired into the shift, not parked in a project plan that has closed.
- Adoption is measured by observed behaviour on the floor, not by logins on a dashboard.
- A named owner runs it after the build team leaves, with the runbook and the authority.
- The old way has a switch-off date, so the rollout has no fallback to decay into.
Sequencing all of this, and seeing where a stalled rollout actually leaks, is its own discipline. We map that with the Hub Map, so the fix lands on the real seam rather than the obvious one.
Frequently asked.
Our rollout went live on schedule. Why is the floor drifting back?
Because go-live was almost certainly treated as the finish line, when it is the start one. A launch that lands on time can still slide back over the following weeks if nobody owns those weeks, the rituals are not wired into the shift, and the old way is left switched on. The fix is to resource the period after go-live, put a named person on the floor, and retire the old path on a known date so there is nothing to drift back into.
The dashboard shows full adoption. Why does it not feel like it?
Because the dashboard is measuring installs, logins and licences, none of which is use. A team can be fully provisioned and still running the job the old way in parallel, and the report will never see it, because the report cannot watch the floor. Pick two or three behaviours that prove the new way is actually happening, then go and observe them where the work is. Adoption-of-tool is not adoption-of-value, and only the floor tells you which one you have.
What is the idea box, and why does it make a rollout stick?
It is a simple method we grew on the floor inside IKEA: the person who does the gesture is the one who proposes the fix, because they see the friction first and they own what they helped shape. It makes a rollout stick because adoption is decided by the people who run the new way every day. Bring them in as co-authors before and after launch, feed their fixes back fast, and the floor watches its own input change the tool, which is what turns a handed-down system into one the team defends.
How long after go-live does adoption actually take?
Plan for four to six weeks of deliberate, staffed work after the launch, not a single event. That is the window where a new way either becomes the habit or decays back to the old one, and it is the window most plans forget to resource. It does not need a big team. It needs one named person on the floor with the time to watch, fix and coach, and the authority to keep the floor on the new path until it runs without them.
Why not just train everyone harder at launch and move on?
Because training tells people how the tool works; it does not make the work stick. The MIT research is blunt about this: most organizations have piloted the tools and many have deployed them, yet the value does not follow, and McKinsey finds the impact comes from redesigning the workflow, not from installing the tool. Adoption is won in the weeks after launch, on the floor, through rituals and ownership and the people who do the gesture, not in a one-off session before everyone moves on.
You can run much of this yourself. Bring us in when a rollout went live and the floor drifted back, when the dashboard says adopted and the work says otherwise, or when you need the weeks after go-live owned by someone who has stood on the floor.
We resource the launch, wire the rituals, measure adoption where the work is, and hand the running to your team. We stay until it holds. Adoption, not launch, is the whole of how we work.
Went live, and the floor drifted back?
No relaunch deck. A working session on the real floor, with the operators who would make it stick.