Getting Employees to Adopt a New System: A Practical Plan

A system nobody uses isn't a project that's half succeeded: it's a full cost, plus a second system to maintain, because the old method keeps running in parallel. The moment that decides whether this happens isn't launch day. It's the weeks before, when the people who will have to use it either get listened to or don't.

Adoption isn't a matter of employees' goodwill. It's a matter of how much the new system helps or hinders each person's work at the moment they're doing it. Anyone who finds a faster shortcut outside the system will use it, and they'll be right to.

Who to Involve, While It's Still Possible to Change Course

Involving people doesn't mean calling a presentation meeting once decisions are already made. It means bringing to the table, during the mapping phase, the people who know the cases no one else knows.

• Whoever performs the most frequent operation, the one repeated dozens of times a day: this is the person who pays for every extra click.
• Whoever handles the exceptions — the person everyone asks when a case is unusual. Usually not a manager.
• Whoever receives the work downstream and bears the consequences of errors made upstream.
• Whoever talks to customers, because they know what information is asked for and at what point.

The process described by management is the one that's supposed to happen. The one actually carried out contains exceptions, shortcuts, and special cases that someone has been resolving from memory for years. The gap between the two is the measure of the project's risk.

Train on Tasks, Not on Features

The most common kind of training is a guided tour of the menus: the system is shown screen by screen to everyone together. It's the format that gets forgotten fastest, because none of the people in the room are learning their own job — they're learning everyone's job.

Useful training starts from the real tasks of each role and uses real, or at least realistic, data. It needs to happen close to the moment people will start using the system: if three weeks pass between training and launch, it needs to be redone.

Retiring Old Tools, Not Running Them Alongside

As long as the old spreadsheet stays accessible and convenient, some people will keep using it. Not out of resistance to change: because it works, they know it, and at that moment they're in a hurry.

1. Declare a date after which the old tool becomes read-only, and stick to it.
2. Bring in the history that's actually needed for daily work, not the entire archive: the rest stays accessible elsewhere.
3. Remove the shortcuts that let people keep going as before, such as paper forms still in circulation.
4. Replace, don't add: if the new system asks for one more piece of data without removing another, adoption ends up competing directly with people's time.

Double entry "just to be safe" needs to be decided explicitly, with a stated duration and an end date. If it's left open-ended, it becomes permanent, and at that point the new system is perceived as extra work — which, in effect, it has become.

Where Questions Go

If the answer to a question depends on who happens to be available at that moment, people stop asking and go back to improvising. You need a single path, known to everyone.

• One point of contact per department, chosen from among those who took part in the mapping phase, with time actually set aside for this role.
• One single place where problems are written down: not the hallway, not private messages to the consultant, not emails to different people.
• A stated rule on what to do when the system won't allow an urgent operation: who to call, what to note down, how it gets fixed afterward.
• An expected response time, even a generous one, as long as it's known: knowing the answer will come tomorrow is better than not knowing at all.

The Issue Log, and What to Do With It

The log is only useful if someone reads it regularly. The useful fields are few: who, when, what they were doing, what they expected, what happened, and how they worked around it in the meantime.

At the weekly review, every entry goes into one of three categories: a system defect, which gets fixed; missing knowledge, which gets re-explained, to everyone if it keeps recurring; or an unplanned process, which requires a decision from the company, not the vendor. Confusing the third with the first is the fastest way to make the list of change requests grow without end.

Measuring Adoption: Completed Work, Not Logins

Logins tell you that people are getting in. They don't tell you that the work is actually going through the system. The signals that truly describe adoption are different.

• The share of the period's operations recorded in the system compared with those that actually happened.
• Operations completed without a later correction, which show whether people know how to do them or are working by trial and error.
• The lag between an event and when it gets recorded: if it grows, the system is being experienced as a chore rather than a tool.
• The number of help requests on the same point: it shows where the system or the explanation isn't working.

These signals need to be looked at department by department. A good average adoption rate can hide a department that's stalled, and that's the department the missing data will come from that ends up spoiling everyone's views.

When It's Worth Postponing or Starting Smaller

There are moments when even a well-executed rollout fails anyway, and it's worth recognizing them in advance.

• A seasonal peak period, or a deadline that absorbs the company's attention.
• No internal person with time assigned to oversee the rollout: the vendor can't stand in for them.
• A process still being debated between departments: the system would just make a disagreement visible, and that disagreement needs to be resolved first, not with software.
• An essential feature not yet ready: better to start with one department or one type of operation and expand later.

Starting with a small group has a benefit that goes beyond caution: it produces internal people who know how to use the system and can explain it to others in the company's own words, which work better than the manual's.

What This Guide Doesn't Cover

This guide covers organizational adoption: who to involve, how to train, how to close out the past, and what to measure. The technical tests to run before putting the software into daily use — edge cases, test data, checks on calculations and permissions — are covered in the dedicated testing guide. The choice of what goes into the first version and what waits also has its own guide.