Training a team on software they did not ask for

The system is live, and the notebook is still behind the counter. Two weeks after launching something that took three months to build, half the team is entering everything twice and the other half is waiting to see which way it goes. This is the ordinary result of a good build with no plan for the people who have to use it.

Why the old method survives

• It is faster for them today. The notebook takes four seconds. The form takes forty, until the fortieth time.

• Nobody has said what happens if they get it wrong. A mistake in a notebook is crossed out. A mistake in a system feels permanent and attributable, and people avoid tools that can blame them.

• It asks for information they do not have yet. A required field they cannot fill at the moment they are asked to fill it makes the whole screen unusable, so they wait, and waiting becomes a pile.

• Somebody senior still asks for the old report. As long as the old report has to exist, the old process has to exist to produce it.

Only the first of those is about training. The rest are about the system or the manager, which is why a training day on its own so rarely changes anything.

Train on their own work

Demo data teaches nothing, because the difficulty was never the buttons. It was the awkward cases: the customer who pays in three parts, the order that came in by phone, the return without a receipt.

So the session is the last three days of real work, entered by the people who did it. Every awkward case appears within the first hour, and each one is either answered on the spot or written on the list of things to change. That list is the most valuable thing produced by a launch and it only exists if the training used real work.

One person per team, taught a week early

Choose somebody who does the job rather than the most senior person in the room, and teach them properly before everybody else. Not as a reward, and not as a title.

The reason is plain: people will ask a colleague at the next desk something they would never ask a consultant or a manager. A question asked out loud on day three is a workaround that never gets invented, and workarounds invented in the first fortnight tend to still be there a year later.

A page per role, not a manual

Nobody reads forty pages. One side of paper per role, listing the five things that person actually does, with the exact steps and one picture each. Printed and put up where the work happens, not saved in a shared folder.

It has to be short enough that updating it is not a project, because the software will change and a guide that no longer matches the screen teaches people to ignore guides.

Run both, then stop, on a date everybody knows

Parallel running is sensible for a fortnight and corrosive after a month. While both exist, neither is trusted, everybody works twice, and the two records drift apart until somebody has to decide which one is real.

Name the date the old method stops before the new one starts. Put it where everybody can see it. Tell the person who asks for the old report, because that is the request that quietly keeps the old system alive after everybody else has moved on.

Look at week three, not week one

Week one is nerves and best behaviour. Week three is the truth. Four things to look for.

• A field that everybody leaves blank. Either it is not needed, or it is being asked for at the wrong moment in the day.

• Notes typed into a description box that should be a field of their own, which is people telling you what the system is missing.

• A spreadsheet that has quietly come back.

• One person entering everything because the others have started funnelling their work through them. That is a queue, and it will be blamed on the software.

Each of those is a change worth making, and each is cheap in the first month. After a year of data has been entered around a problem, fixing it means fixing the data too.

How we handle it

Training is part of every system we build rather than a line added at the end, and the sessions run either at your own place of work or in our Event Space in Abeokuta when a team needs a room away from the phones. What a build includes is on the software development page.

For individuals looking for courses rather than a team being brought onto a new system, the catalogue is on Bitnox Education. For everything else, tell us what the team does and what they are using now.