Change management for new software

Why software rollouts stall in small firms

In a large company, change management is a department. In a 25-person firm it is usually the owner announcing a new tool in a staff meeting and hoping for the best. The software gets configured, a vendor runs a webinar, and within a month half the team is back on the old spreadsheet because it feels faster and nobody stopped them.

The cause is rarely resistance for its own sake. People are busy, the new tool was set up without their input, and the old way still works well enough. A light, deliberate plan fixes most of this, and it does not need consultants or workshops.

There is also a cost to getting it wrong a second time. Staff who watched one rollout fizzle will be slower to trust the next. Taking care with this change makes every later change easier.

Start with the reason and the owner

Write one short paragraph explaining why the change is happening, in terms of the work. For example: we are moving scheduling from the paper book and phone tag into Housecall Pro so customers get confirmation texts, technicians see their day on their phones, and the office stops double-booking. Avoid general phrases about efficiency or innovation. People support changes they understand.

Then name one internal owner. This is the person who answers questions, collects problems, decides small configuration changes and reports on progress. In many firms it is the office manager or operations lead. The owner needs a few protected hours a week during rollout, or the job will lose to everything else.

Be honest about the short-term cost too. The first weeks will feel slower, and saying so in advance makes it easier for people to persist.

Involve the people who do the work

Before configuration is final, sit with two or three people who will use the system most. Show them the planned setup using their real work, such as yesterday's jobs or last week's new clients, and ask what would slow them down. They will spot problems quickly: a field nobody fills in, a required step that does not fit how calls arrive, a report the dispatcher needs every morning.

This is also where you find your early adopters. One enthusiastic technician or paralegal who helps colleagues is worth more than any training video.

Ask the early adopters to help test the configuration and to sit beside colleagues in the first week. Peer help feels less like being told what to do, and it surfaces practical tips that formal training misses, such as the fastest way to log a callback or a saved filter that shows only today's work.

Plan the cutover

Running two systems in parallel for a short time is fine. Running them in parallel indefinitely is how rollouts fail. If the old spreadsheet stays editable, it will stay in use.

Be explicit about what is changing for each role. A technician may only need to learn how to see the schedule and close a job on a phone, while the office coordinator learns booking, invoicing and reporting. A short one-line summary per role prevents a lot of anxiety.

• Pick a cutover date and tell everyone at least two weeks ahead.
• Decide what data moves over, and clean it first: duplicates, closed accounts, old price lists.
• Run a short pilot with a small group or one team before everyone switches.
• Agree what happens to work in progress on the cutover date.
• Set a date when the old tool becomes read-only, then a date to cancel it.
• Keep a simple issues list that the owner reviews daily during the first two weeks.

Train on real work

Train people on the tasks they actually do, in the order they do them, using real examples. A front desk coordinator at a dental practice needs to practice confirming tomorrow's appointments and handling a cancellation, not tour every menu. Keep sessions short, record them, and write a one-page cheat sheet for each role.

Plan a second round of training two or three weeks after go-live. By then people know what confuses them and will ask better questions. Most of the real learning happens in that second session.

Ask the vendor what training and onboarding are included in your plan. Many software providers offer setup calls, help articles or live sessions, and using them saves your own team time. Supplement vendor training with your own examples so it reflects how your business actually works.

Communicate through the change

Communication in a small firm does not need a campaign, but it needs to be regular. Tell people what is changing, when, why, and what it means for their day. Then repeat it, because the first message is rarely the one people remember.

A simple rhythm works well: an announcement with the reason and the date, a short demonstration using real work, a reminder a week before cutover, a quick daily check-in during the first week after go-live, and a short note at 30 days sharing what has improved and what is being fixed. Sharing early results, even small ones, helps people see the change is worth the effort.

Make it easy to raise problems. A shared channel in Microsoft Teams or Slack, or a simple form, lets staff report issues without feeling they are complaining. The internal owner should reply to every report, even if the answer is that the item is on the list for later. People keep using a system when they can see their feedback being heard.

Measure and adjust

Track two kinds of numbers. Usage: how many people log in, how many records are created in the new system versus outside it, and whether key steps are being skipped. Results: the workflow measures you chose before the change, such as time to schedule a job, no-show rate or days to invoice. Compare them with your baseline at 30 and 60 days.

If usage is low, ask why before pushing harder. Often a small configuration change, like removing a required field or adding a saved view, fixes it. If results have not moved, revisit whether the software was the real constraint. This measure-and-adjust step is part of how InTheory approaches any rollout, but any owner can run it with a spreadsheet and a calendar reminder.