Adoption is where the value is: the first 90 days after go-live

Why value is lost after go-live

On day one, people use a new system the way they used the old one. They were trained once, in the weeks before go-live, on what they needed that week. The features that justified the investment, the ones in the business case, often wait for someone to come back for them. Then the project team disbands, and nobody does.

In our experience the difference between firms that get full value from a system and those that do not is rarely the system. It is whether anyone kept going after the launch. The good news is that it needs a plan and some diary time more than it needs budget.

Measure before you change anything

Without a “before”, every change is a matter of opinion: supporters say it is better, doubters say it is not, and the most senior voice wins. You do not need a data team. Most firms already hold what they need:

• Time recording: non-chargeable admin time per fee earner.
• Case and matter management dates: how long each stage takes for the type of matter you are changing.
• Support requests: how many, about what, and how long they take to resolve.

Pick two or three, note them before go-live, and agree who will look again at 90 days. A small, proven improvement wins more support for the next change than a large claimed one.

Three check-ins

AT A GLANCE

The first 90 days

Put these in the diary before go-live, not after.

1. 1

   Before

   Note two or three measures from data you already hold.

   A baseline to prove the change

2. 2

   Day 30

   What is everyone stuck on? Fix the small things fast.

   Irritations, not workarounds

3. 3

   Day 60

   Are the key features being used, team by team?

   Gaps found while they are small

4. 4

   Day 90

   Compare with the baseline and share the result.

   Proof, and the next priority

Day 30: what is everyone stuck on? Walk the floor, or the Teams channels, and ask. Fix the small things fast: a missing template, a confusing screen, a report in the wrong order. Small irritations become workarounds, and workarounds become permanent.

Day 60: are the key features being used? Most systems can show who uses what. Look team by team at the features in the business case. Where a team is not using one, find out why before assuming resistance; usually it is a training gap, a setting or a step that does not fit how that team works.

Day 90: is it better than before? Compare with the baseline and share the result with the teams, good or modest. Thank the people who made it work. Then agree what comes next.

At every check-in, ask each team the same question: if you could fix one thing next, what would it be? The answers that come up in several teams are your next priorities, and they are changes people have asked for themselves.

Champions beat training sessions

Classroom training teaches the buttons. A respected colleague sitting next to you shows you that it works for your work. We saw this on a paperless project at a firm we worked with: one partner liked things done his way, and his way involved paper. Training did not change that. His secretary did. She began emailing him the documents he would have asked her to fetch, already in the system and already where he needed them. Within weeks he had stopped asking for the files, and she rightly got the credit.

• One champion per team, chosen for respect, not seniority or enthusiasm for technology. Ask who colleagues already go to when they are stuck.
• Early access and a direct line to the technical team, so problems reach the people who can fix them.
• Real time: an hour a week in their diary, agreed with their manager.
• Public thanks when their team gets there.

Nobody told them it was there

“Can the system do that?” “It has done that for three years.” When a feature goes unused, it is usually unknown rather than resisted. Updates arrive as release notes nobody reads, and what people learned at go-live is all they know.

• Five minutes at the team meeting: one “did you know”, shown live on a real matter.
• Learn from your best users: ask what they do that others do not, and share it.
• Translate every update: not “new features in release 4.2”, but “you can now do this, and it saves that”.
• Keep a “we already have it” list: the things people ask for that the system already does. It is often the most useful list in the firm.

Start this week

If you have a go-live coming, note your baseline now and put the 30, 60 and 90 day check-ins in the diary, with a named owner for each. If you went live in the last year, it is not too late: run the 60 day check now, pick a champion in each team, and start the “did you know” slot at the next team meeting.

It follows on from where you should be a month before go-live and migrating so your data works from day one. If you are not sure how much of your current system you use, start with finding out what you already have, and see turning what people say into work that gets done for keeping the requests flowing.

We help firms plan and run adoption after go-live, so the value in the business case turns up in the work.

If you think anything here is out of date, please tell us and we will correct it.