Making a Change Stick in a Small Team
New systems and new processes fail for the same reason most of the time, and it is almost never the technology. It is that the people who had to change how they work were told rather than involved, and nobody checked whether the change actually took.
Change management sounds like something large organisations do with consultants and workshops. In a small business it is much simpler than that, and skipping it is what turns a good decision into a project nobody uses.
Six weeks later is when you find out
Rollouts are usually declared successful on launch day. The system is live, training happened, everyone nodded.
What matters is what people are doing six weeks later. That is when the old spreadsheet comes back out, when the new step gets skipped when things are busy, and when two versions of the process start running side by side.
If you only measure adoption at launch, you will consistently believe changes landed when they did not.
Tell people why, in terms that include them
The reason a change is happening is usually explained from the business point of view. Better reporting, fewer errors, a platform that scales. All true, and none of it answers the question the person actually has, which is what does this mean for my Tuesday.
Say both. Here is why the business is doing this. Here is what changes in your day, here is what gets easier, and here is the part that will be more annoying for a while. That last admission buys more credibility than any amount of enthusiasm.
People do not resist change. They resist being changed without being asked, and they resist changes that make their own week harder for someone else's benefit.
Involve a few of the right people early
You do not need everyone in the design. You need two or three people who actually do the work, brought in early enough that their input can still change something.
They will find the exceptions nobody in the meeting knew about, and they become the people their colleagues ask instead of you. Both of those are worth far more than the time it costs.
Choosing who is important. Pick people who are respected rather than people who are enthusiastic. Quiet credibility travels further than early adoption.
Be honest about what is being taken away
Every change removes something, and the loss is usually unacknowledged. Autonomy over how someone does their job. A shortcut that made a hard week manageable. Expertise in the old system that made someone the person others asked.
That last one is the most common source of quiet resistance, and it is rarely about the software. Naming it, and finding the person a role in the new arrangement, resolves more objections than another training session.
Train on the real work, close to when they need it
Training three weeks before go live is forgotten by go live. Training on sample data teaches people the buttons and not the job.
Run it close to the change, using real cases from your own business, including the awkward ones. Keep sessions short and role specific. Then leave something written behind, because people will not remember and will not want to ask twice.
Plan the messy fortnight
There is always a period where the new way is slower than the old way. Productivity dips, people are frustrated, and this is when changes get abandoned.
Say in advance that it will happen and roughly how long it will last. Reduce other demands for that period if you can. Have somebody obvious to ask, and make the answers fast. And decide beforehand what would count as a real problem versus normal friction, because in the middle of it everything feels like a real problem.
Close the old door
If the previous system or spreadsheet is still available, some people will keep using it, and you will end up maintaining two versions of the truth.
Set a date, tell people, make it read only, then remove it. Sooner than feels comfortable, but only once the new way genuinely works, because forcing people onto something broken is how you lose the next change as well.
Check adoption on purpose
Two weeks in, six weeks in and three months in, look at whether the change actually happened. Not whether people say it did. Are the records being created the new way. Has the old shortcut reappeared. What are people asking for help with.
Where the answer is disappointing, the useful question is why this is easier for them, not why they are not following the process. The answer is almost always a step that does not work in a real week.
Give it an owner past go live
Projects end and processes do not. Somebody needs to own the new way of working after the project team disperses, including the documentation, the training material for new starters, and the decision when something needs adjusting.
Most of what we do with clients sits in exactly this territory. Not the installation, the part where the change has to survive a busy quarter and still be there a year later.
We work with businesses in Pompano Beach, across South Florida and remotely to make changes stick past go live. Book a consultation, or visit www.expertechsolution.com.
