Getting people to use new software: training, champions and change on the floor

A new system can be well designed, properly tested and delivered on time, and still fail. It fails quietly: storekeepers keep their old register "just in case", supervisors enter the day's data in a batch at six o'clock, managers ask for the familiar Excel report, and within a few months the new system holds half the truth. Nobody decided to reject it. People simply carried on doing what they knew.

Adoption is not a phase that happens after delivery. It is work that starts on the first day of the project. This article sets out how to get people to use new software, from the boardroom to the factory floor.

Why people resist new systems

Resistance is usually reasonable from the user's point of view. Understanding it is the first step to addressing it.

It feels like more work. If the new system adds steps for the person entering data and the benefit goes to someone else, they will avoid it.
Fear of looking incompetent. Experienced staff who are expert in the old way become beginners again, sometimes in front of junior colleagues.
Fear of being watched. Systems that record who did what, and when, can feel like surveillance if their purpose is not explained.
Past disappointments. If earlier systems were abandoned, people reasonably expect this one to go the same way.
Practical barriers. Not enough devices, poor connectivity at the workstation, screens in a language or layout that does not suit the user.

People do not resist change. They resist extra work, embarrassment and uncertainty. Remove those, and most of the resistance goes with them.

Before go-live: design for the user

Involve real users early

Include the people who will enter data every day, not only their managers, in discovery and in regular demos. Watch them use early versions. When users recognise their own suggestions in the system, they defend it rather than resist it.

Make the right action the easy action

Remove unnecessary fields, use scanning instead of typing where possible, offer sensible defaults, and design screens for the device and conditions where they will be used. A form that takes two minutes at a desk may be impossible on a noisy floor with gloves on.

Explain the why

Tell people, in plain language, why the system is being introduced, what it will change for them, and what it will not be used for. If the system records individual activity, say clearly how that information will and will not be used.

Check the practical setup

Confirm that every user has a working device, a login, a network connection at their workstation and somewhere to charge equipment, before the first day. Many adoption problems are logistics problems.

Champions: your most important adoption tool

A champion is a respected user in each department or line who learns the system early and supports colleagues. Good champions are rarely the most senior people; they are the ones others already ask for help.

Choose them with care: patient, trusted by peers, and comfortable with phones or computers.
Train them first and more deeply, ideally involving them in testing before go-live.
Give them time. Supporting colleagues takes hours away from their normal work. Agree this with their managers, or it will not happen.
Give them a channel to the project team for questions and problems, with quick responses.
Recognise their contribution openly once the system is working.

Training that sticks

A single classroom session a week before go-live is easily forgotten. Training works better when it is:

Role-based. Each group learns only the tasks they will actually do, using their own real examples.
Hands-on. People practise on a training version of the system, not by watching slides.
Close to go-live. Short sessions shortly before people start using the system, followed by refreshers.
In the right language. Use Bangla or English as suits each group, and keep instructions short.
Backed by quick references. A one-page guide or short video for each common task, kept at the workstation or on the phone.

Go-live: support on the floor

The first two weeks decide whether a system takes hold. During that period:

Have project team members and champions physically present where the work happens, especially at shift starts.
Hold a short daily check-in to collect problems and agree fixes.
Fix small irritations quickly and tell users when you have, so they see their feedback matters.
Set a fixed, short end date for any parallel running of old registers or spreadsheets, and stick to it.

The role of leadership

Staff watch what managers do, not only what they say. If the general manager still asks for the old report, everyone learns that the old way still counts. Leaders should use the system's reports and dashboards in their own meetings, ask questions based on its data, and visibly support people who are learning.

Measure adoption, not just delivery

Track a few simple indicators for the first months:

Are transactions entered when the work happens, or in batches at the end of the day?
Which users or departments have low activity?
How many support requests are being raised, and on which screens?
Are side spreadsheets or paper registers still in use?

Use these signals to target help, not to blame. Low usage usually points to a training gap, a design problem or a practical barrier that can be fixed.

A short adoption checklist

Have real users seen and influenced the system before go-live?
Is there a trained champion in every department or line?
Does every user have a device, a login and connectivity where they work?
Is training role-based, hands-on and close to go-live?
Is there a fixed end date for the old way of working?
Are leaders using the system's information in their own meetings?

Where RAED fits

We plan adoption alongside the build: involving users in demos, training champions, providing role-based training and staying on the floor during go-live. We measure success by whether the system is used, not only by whether it was delivered.