Most rollouts of a new tool or process fail in a way nobody notices for about six weeks. The kickoff goes fine. People nod. Then the new thing quietly does not get used, or gets used wrong, and you are left wondering whether your team is resisting it. Usually they are not resisting. The rollout was just never built to make anything stick.
When I work with leaders on this, here is the sequence I walk them through. It does not need budget and it does not need a project plan. It needs you to treat the rollout as something you maintain over a few weeks, not something you announce on one day.
1. Name the one job the new thing is for
#Before you tell anyone anything, finish this sentence: “We are adopting this so that ___.” One reason, the most important one. Not the feature list, the job. If you cannot say it in a sentence, your team will not be able to either, and a tool nobody can explain the point of gets opened once and then quietly ignored. When I skip this step, every later step gets harder. When I do it, the rest goes smoothly.
2. Lead with the old pain, not the new feature
#Do not open the rollout with a demo. Open it with the problem your team already feels. “You know how reconciling the month-end numbers eats two whole days. Here is why we are changing that.” People do not adopt features. They adopt relief. If the team does not recognize their own pain in the first two minutes, the demo is just noise played at them.
3. Make the first real use happen in the room
#The most fragile moment in any rollout is the gap between “I saw it demoed” and “I did it myself.” Close that gap immediately. Before anyone leaves the session, have each person do the actual first task in the actual tool, once, with you there. Not a walkthrough they watch. A rep they do. The first independent use is the one most likely to go wrong and least likely to happen on its own.
4. Schedule the second use, and the third
#This is the step almost everyone skips, and it is the one that decides whether the rollout survives. A new process is a new memory, and a new memory fades fast without retrieval. So do not leave the second use to chance. Put it on the calendar. For the first three weeks, build one small, real use of the new thing into a meeting your team already has. Three weeks of light, spaced repetition will outlast a one-day intensive every time.
5. Watch for the quiet drift, and name it early
#Around week two or three, you will see a few people slide back to the old way. This is the normal middle of every change, not a sign of failure. The mistake is letting it pass unspoken, because unspoken drift spreads. When you see it, name it lightly and early, to the person, that day: “I noticed you went back to the old sheet. What got in the way.” Usually it is friction you can remove, not resistance you have to overcome.
6. Hand it a visible owner who is not you
#A rollout that depends on you forever has not actually landed. Within the first month, give the new thing an owner on the team, someone other than you, who answers the questions and holds the standard. The change is not complete when everyone has used the tool once. It is complete when it no longer needs you.
Done this way, a rollout stops being an announcement and becomes a short, deliberate stretch of maintenance. It is more work than sending one all-staff message, and far less work than relaunching the same tool in six months because the first attempt quietly died. Pick the next change you have coming. Walk it through these six steps before you schedule the kickoff.