Why new software fails and what to do about it

Organisations spend considerable time and money selecting the right software. They run procurement processes, evaluate vendors, negotiate contracts. Then they roll the system out and find that six months later, half the team is still using the old spreadsheet. The software was not the problem. The adoption process was.

The gap between go-live and actual use ¶

Go-live is the moment a new system becomes available. It is not the moment people start using it. The gap between those two events is where most technology investments are lost.

In the organisations we have worked with, the gap is almost always caused by the same thing: the people who will use the system were not involved in designing how it would fit into their work. The system was configured by a project team, handed over with a training session, and then left to compete with the habits and workarounds that people had spent years developing.

What change management actually involves ¶

Change management in a technology rollout is not a communications plan and a training day. It is a sustained process of understanding how work currently happens, identifying which parts of that process the new system will change, and working with the people affected to redesign those parts before go-live.

That process takes longer than most project plans allow for. It also requires someone who is not invested in the success of the software itself, because the people selling and implementing the system have an incentive to minimise the apparent complexity of the change.

Measuring adoption honestly ¶

Adoption is not measured by whether people can log in. It is measured by whether the system is being used for the decisions it was designed to support. Those are different things, and the gap between them is often large.

We recommend agreeing on three or four specific adoption indicators before go-live: not 'percentage of staff trained' but 'percentage of client records updated in the system within 24 hours of a meeting'. Specific, observable, tied to the actual work. Those indicators give you something to act on if adoption is slower than expected.

If you are planning a system rollout and want to think through the change management side before the project starts, that is exactly the kind of conversation the discovery call is designed for.