On most project plans, the rollout is a bar near the right-hand edge, about two weeks long, called training and handover. It is the first thing compressed when the build runs late, and it is where the return on the whole investment is decided.
That is backwards, and it is worth understanding why it happens before looking at what to do differently.
Why it gets squeezed
Not carelessness. Structure.
The build has a definition of done you can point at. The rollout does not, so it is hard to plan and easy to shorten. Everyone involved has also been living with the new system for months and it feels obvious to them, which makes it genuinely difficult to remember that nobody else has seen it.
And the incentives are wrong. Under a fixed-scope project, the milestone is delivery. Adoption happens after the last invoice, so the team best equipped to fix the early problems is already on something else.
The first three weeks decide it
There is a window after launch, roughly three weeks, where people are willing to be patient. They know it is new, they expect some friction, they will tell you what is annoying if you ask.
In that window there are always two or three steps that are genuinely worse than the old way. Not bugs — design decisions that seemed reasonable and are not, in practice, with real hands and a real queue.
Fix those fast and people conclude that the system works and someone is listening. Leave them past the window and people conclude that this is what the system is. They stop reporting things and start working around them, and that verdict is very hard to reverse. The same fix landing in week two or week ten has completely different effects.
Run the old way alongside it
The instinct is a clean switchover, because parallel running looks like double work.
It is the cheapest insurance available. Keep the old method going for one full cycle — a month, a quarter, whatever your rhythm is — and compare the outputs. Two things come out of it. You find the discrepancies while there is still a safety net, and the people most sceptical about the new system become the ones who verified it. That is worth more than any amount of training.
A clean cutover is only safe when you already know the new system produces the right numbers, and you cannot know that until it has run on real volume.
Start with the people who will benefit
Do not roll out to everyone at once and do not start with the loudest sceptic.
Start with the group whose job the system genuinely improves. They will find the rough edges without concluding the whole thing is a waste, and once it is working for them, the case for everyone else is made by colleagues rather than by management. That is a different kind of persuasion and it is far more effective.
Then take on the harder group deliberately, with the early problems already fixed.
Look after whoever gained work
Almost every improvement moves effort rather than removing it. Several people save a few minutes and one person inherits the exceptions.
That is still a net win, and the person carrying the new load is exactly who you need on side. If nobody acknowledges what happened to their day, they work around the system, and they usually sit at the point everything flows through. Find them before launch and design their part properly.
What to actually plan
Give the rollout the same rigour as the build. Who goes first and why. What runs in parallel and for how long. Who is available to make small fixes in the first three weeks, and with what authority. What you will measure to know it is being used, not just that it is live.
That last point is the one worth insisting on. Live and adopted are different states, and only one of them returns anything.
