Preparing Your Team for a System Rollout

A Before / During / After Checklist

Most rollout problems aren't technical — they're communication gaps. This checklist covers the basics that are easy to skip when you're focused on getting the system itself working.

Before Launch

- Explain the why, not just the what. People accept change faster when they understand the problem it solves — not just that something new is coming. - Name a champion in each affected team, someone who gets early access, asks questions before everyone else has them, and can answer peer questions on launch day without waiting for IT. - Schedule real, hands-on training — not just an email with a link to a manual. People retain far more from doing a task once than from reading about it. - Set a launch date and repeat it often, in more than one channel (a meeting, an email, a reminder the week before). A date mentioned once, three weeks out, will be forgotten. - Decide — explicitly — what happens to the old system or process. Will it be switched off the same day, or will both run in parallel for a window? An undecided answer here is one of the most common sources of confusion on launch day. - Identify who answers "it's not working" on day one, and make sure that person or channel is visible to everyone before launch, not announced for the first time after something breaks.

During Launch

- Have support visibly available, not just on standby. People are far more likely to ask for help when they can see where to ask. - Set up one clear channel for problem reports — a single place, not "email whoever you think might know." - Set the expectation that it will feel slower before it feels faster. Naming this in advance prevents "this is worse than before" from becoming the dominant story on day one. - Check in proactively with the champions named above — don't wait for complaints to surface on their own.

After Launch

- Ask for friction within the first week, while it's still fresh in people's minds. Waiting a month means most of the small, fixable annoyances have been forgotten or quietly worked around. - Decide — and communicate — when the old process is formally retired. "Training wheels off" should be a stated moment, not something that happens by default when everyone stops asking. - Set a 30-day review date in advance, with a specific question to answer: is this working the way it was meant to, and what needs adjusting?

The One Thing Every Item Above Has in Common

None of these are technical tasks. They're all about making sure people aren't left guessing — about why, about where to get help, about what's expected of them, and about whether anyone's actually listening once it's live. That's the real substance of "Change Management Fundamentals" (also in this Resource Centre), applied specifically to the moment of launch.

---