An order goes into the new system, then into the old spreadsheet too, just in case. When you introduce a new system to your team, that's the sign the old way is still running beside it.
Every question about it lands on one person, usually whoever set it up. That might be you.
You picked it and paid for it, and maybe you spent a few late nights getting it ready. Until people use it, it's a cost that hasn't started paying you back.
It's easy to start wondering whether you picked the wrong one. Before you go shopping for another tool, look at how this one was introduced.
Often the fix is the order you introduce a new system in the workplace. Get the order right, and the old spreadsheet can stop getting a second copy of everything.
Getting people to use the new system is the harder half of the job
Setup is the part you can see. The logins work, the settings are done, and the old information has moved across. It feels like the finish line. It's where the harder half starts.
The harder half is people changing how they work. They know the old way by heart. It's slow, but it works, and they don't have to think about it. The new way costs them time and attention until it starts paying them back, and they're the ones paying.
So plan the rollout the way you'd plan any other piece of work, with steps, an order, and one person who owns it. If the new system is one change on a longer list, a business implementation plan gives each change an owner and a place in the order. Its definition of done includes people using it. The Rolling Out New Systems overview puts both in context.
For a change with no new software in it, read how to roll out a new process to your team so it sticks.
Start with the problem it solves for the people using it
People take up a tool when they can see what it does for them. That's why the reason comes before the training. Someone who knows what a button is for remembers where it is.
Start by writing down the problems the new system fixes, in the words of the people who live with them. "I type every order in twice" is a reason. "Better data" isn't. Then sort the list into what the business needs and what would just be nice. The needs are what you tell people. The nice-to-haves can wait until it's running.
Tell people before anything changes, not on the day it does. Say what changes for each of them: what they'll do differently, what they won't have to do anymore, and when the old way stops. If a part gets harder for someone, say so. They'll find out anyway, and it lands better coming from you.
Most of what people call getting buy-in from employees is this: the reason, given before the work.
Choose how the new system goes live: all at once, side by side, a small group first, or a piece at a time
There are four common ways to switch from an old system to a new one. Each trades speed against risk.
- All at once, on a set day. Quickest and cheapest. Also the riskiest, because if something is wrong, it's wrong for everyone at the same moment.
- Old and new side by side for a while. The safest, because the old system is still there if the new one stumbles. The cost is that every piece of work gets done twice. Decide before you start what has to be true for the old one to switch off, or "a while" has no end.
- A small group first. A few people use it before everyone else. Problems stay with them, and help can focus on them. Everyone else starts on a version that has already had its rough edges found.
- One piece at a time. Each part of the old way switches off as the matching part of the new one switches on.
You'll see these called direct cutover, parallel, pilot, and phased if you read further.
Which one fits depends on two things: how complex the system is, and how much the business relies on it. The more of your day that runs through it, the less you want everything riding on one switch-over. Rolling it out in phases is the usual advice for easing people in, and the last two options are both ways of doing that.
Train people on the new system before it goes live, and again once they're using it
A demo on launch day shows people where things are. It doesn't show them how to do their job in it, and that's the part they need.
Train hands-on, on their own work. Have people enter a real order, a real client, or a real request, the kind they handle every day. Fit the training to how your workplace runs, so it follows the work people do in the order they do it.
If your provider offers training, use it, and put someone from your side in the room who knows the system well. The trainer knows the software. Your person knows how your business uses it, and can answer the questions that start with "but what do we do when…"
Then train again once people have been using it. The real questions only show up in use: the odd case, the step nobody mentioned, the shortcut that turns out to skip something. The second round is where those get answered, with people who now know what to ask.
Name the person people ask, and listen to what they tell you
Once it's live, everyone should know where a question goes. It might be someone on your side, or it might be the provider's support. Name it out loud, and write it down where people will look.
Without a name, questions go to whoever seems to know. That person becomes the help desk on top of their real job. The questions they can't answer turn into workarounds.
Once people have settled in, ask them what's working and what isn't. Then change something. If you ask and nothing changes, people stop answering. A question that keeps coming up points to a gap in the training or the write-up, and that's where to fix it.
Write down how it's used, so it stays in use
Without something holding it in place, people drift back to old habits. A new hire learns the workaround from the person at the next desk, and the workaround becomes the way it's done.
What holds it in place is a write-up of how the system is used in your business. Say what goes into it, who does what, and where to look when something's unclear. The provider's help pages cover the software. This covers how you use it.
I'm autistic and ADHD, diagnosed in my late 30s. It's why I write down how each system is used in my own businesses, instead of trusting memory to hold it, mine or anyone's. A system that only runs while one person remembers how isn't in use yet. And if you need it written down to keep it, so does everyone else.
Processes and SOPs covers how to write it down well, starting with how to document business processes while the work is getting done.
A rollout needs an owner as much as the system did
No more orders typed in twice, and no more questions piling up on one person. That's what a rollout done in the right order gets you.
Each step that gets you there is small. Together they're a piece of work. A rollout that sits on top of everyone's day job is the part that slips. Then the system stays paid for, and the old way stays in charge.
The rollout's owner can come from outside the business, too. Sparkitive can take the rollout on while your people stay on their real work.
Picture your people opening the new system every day without a second thought. If the rollout that gets them there is part of a bigger body of work you'd like planned and run for you, let's look at it together on a free 30-minute discovery call.
Just need a website or blog content, and nothing else? FableForge and its Tech Team handle that.
