A five-person bookkeeping office in Moncton switches to new accounting software on a Monday. The owner has watched the demo twice and likes it. The two people who do most of the data entry were shown it for forty minutes on Friday. By Wednesday one of them has gone back to her spreadsheet "just to double-check," and by the end of the month the spreadsheet is the real system and the software is where things get copied after the fact.
Nobody refused anything. Nobody was told what would change for them, who to ask, or when the old way stopped. That is what change management is, and a five-person team needs it just as much as a five-hundred-person one. It just can't hire someone to do it.
What the research says, with the caveats
Prosci, which has surveyed change practitioners for more than twenty years, reports that projects with excellent change management met or exceeded their objectives 88% of the time, against 13% for projects with poor change management (Prosci, Best Practices in Change Management). Those are self-reported survey answers from mostly larger organizations, so they show a strong association, not proof of cause. We still find the direction hard to argue with.
McKinsey's research on transformations points the same way on the people side. In its report on the people power of transformations, as summarized by Consultancy.uk, 73% of respondents at successful transformations said frontline employees were visibly engaged, against 46% at all the others. That is a survey of large companies. What carries over to a small one is the finding itself: the people doing the work are not an audience for the change. They are the change.
What a small team has going for it
Big-company change programs exist to solve a problem you don't have: reaching thousands of people who have never met the person making the decision. In a five-person shop you can reach everyone before lunch. You know who will be quietly worried, because you know their kids' names. The flip side is that there is no slack. If one person is out sick during go-live, twenty percent of your capacity is gone, and nobody is left whose job is to notice that the new way is stalling.
What actually works
- Tell each person what changes for them, in their own words. Not "we're moving to a new system." Instead: Marie, you stop keying invoices by hand, and you spend that time on collections calls. Dev, you now approve anything over $500 on your phone. Write it down, one paragraph each.
- Name one owner, and one backup. It is the same lesson as in our post on why AI pilots stall: a change that belongs to one curious person stops when they go on vacation.
- Pick a date the old way ends. Running both in parallel feels safe and is how the spreadsheet wins. Two weeks of overlap is plenty.
- Answer every concern in writing within five days. The person asking the awkward question about the new process is usually right about something. If the answer is "you're right, we'll change it," say that out loud and then change it.
- Start with the one person most likely to push back, not the keenest. If it works for her, the rest follows. If it does not, you have found the problem in week one instead of month three.
- A fifteen-minute check-in every Friday for the first six weeks. Three questions: what got easier, what got harder, what did you quietly work around.
Training that fits a team this size
A learning-management platform is wasted on five people. What works is a short walk-through on their real work, done at their own desk, on a quiet afternoon, with a one-page cheat sheet they wrote with you. Teach each role only what that role touches. The bookkeeper does not need the admin screens, and the owner does not need to learn the import tool.
Then leave a plain-language runbook: what the new tool does, where it tends to go wrong, and how to switch it off and go back if it misbehaves. A team that knows the off switch exists is braver about using the thing. This matters most when the new tool makes decisions, as AI tools do, which is the point of our post on why AI needs a pilot.
The opinion: skip the change plan, write the Monday note
We would rather see a small team send one honest note the Friday before go-live than commission a forty-page change plan. The note says what changes Monday, for whom, what is still rough, who to ask, and when the old way ends. If you can write that note, you understand the change well enough to run it. If you can't, the tool is not ready to roll out, whatever the vendor told you.
This is the work Stage 8 of our nine-stage method covers: who is affected, a phased rollout, role-based training, a feedback loop and the runbook. If you are partway through a rollout and the spreadsheet is starting to win, a free 30-minute call is enough time to look at it with you.