Software adoption: why your team won't use the new system
Software adoption after a custom build: why employees don't use new software, how to prevent it before handover, and when the software is to blame.
Software adoption is the period from handover to the day the whole team works in the new system and stops going back to the old one. In a custom software build this is where money is most often lost: the application works, but employees don’t use it because the old way is faster or feels safer.
Why don’t employees use new software?
Rarely out of laziness. Three causes repeat:
| Cause | What it looks like | What helps |
|---|---|---|
| Slower than the old way | Two minutes per entry vs 20 seconds in the spreadsheet | Fix the software, not the people |
| Two systems at once | The old spreadsheet is kept “just in case” | A date after which the old one is locked |
| Nobody owns it | Questions go to the director, or to no one | One person per process |
If people avoid a tool, that is usually a build defect, not a discipline problem - which is why future users are asked before the build, as digitalization mistakes companies make warns.
Adoption starts before handover
Adoption is planned in the scope, not in the training. Three things should be agreed before the last phase:
- Real data, not sample data. A team that sees its own customers on day one trusts the system: from Excel to a custom application.
- A lock date for the old system. While people enter data in both, the old one wins.
- First users who took part. Two people who tried each phase, as in phased software delivery, become the ones colleagues ask.
The first two weeks decide it
After go-live, every obstacle becomes a reason to go back. The vendor should answer the same day and make small changes (one more field, a different report) immediately.
Change-management research firm Prosci reports that projects with extremely effective sponsors meet their objectives 79 % of the time, against 27 % with extremely ineffective ones. In a small company the sponsor is you: if the owner still asks for the old spreadsheet report, the team has got the message.
When the problem is not adoption
Sometimes the software is fine and the process is not: nobody knows who approves what. That needs a process review, not more training. If the system is too big for a first step, the answer is a smaller scope, as small-scope software projects explains. The whole build decision is in custom software development for a small business, and the term itself in what is custom software development.
Frequently Asked Questions
How much training does new software need? A few hours per person, on your own data. If it takes more than a day, the system is too complex.
Can we run both systems in parallel for a while? A few days at most, with a lock date set in advance. Longer almost always sends the team back.
Who should own the new system inside the company? The person who works most in the process, not necessarily the most technical one. They collect feedback and agree changes with the vendor.
Is employee resistance normal? Yes, and it is useful: first-week complaints are the best list of fixes you will ever get.
Related Articles
- From Excel to a custom application: what about the data
- Phased software delivery: how to break up a big build
- 10 digitalization mistakes companies make (and how to avoid them)
Rolled out a new system and the team keeps going back?
Tell us what you use and where it sticks. We will reply with a list of what to fix first - no obligation.
Reach out at [email protected] or via the form on our homepage.