Getting your teams to adopt a new tool

Business software brings in nothing as long as the team keeps working in its spreadsheets. Adoption is not an internal communications task at the end of the project: it is decided in the very first workshops. Here is the method I use to make sure a new tool actually gets used, and the signals to watch over the first three months.

Why a tool does not get adopted

The causes are almost always the same, and they can be spotted early:

• the tool was designed for management, not for the people entering data: it produces nice dashboards but takes more clicks than the old file;
• it does not cover a frequent case, so the team keeps its spreadsheet “for those cases,” then for all of them;
• the starting data is missing or wrong: nobody trusts an empty tool or one full of errors;
• the old process stays open, so nothing forces anyone to change habits;
• training happened once, three weeks before go-live, and was forgotten.

None of these causes is technical in the strict sense. All of them can be handled during the project.

Involving users before the first line of code

This is the most effective lever, and it costs almost nothing. In my process, clickable mockups (1 to 3 weeks) are tested by real users before development: a sales rep, an office assistant, a workshop lead, depending on your case. They click, make mistakes, comment. Every issue fixed at this stage prevents resistance later.

Two practical rules:

1. Pick representative testers, including a skeptic. If they are won over, the rest of the team will follow.
2. Time a common task before and after: entering an order, finding a record. If the new tool is not faster on daily tasks, fix it before building.

The adoption plan, step by step

The three months of support included in my projects exist precisely for this last phase: fixing whatever slows usage down, before workarounds take hold.

Getting the switchover right

Go-live week decides a lot.

• Migrated, verified data. Customers, products and open cases must be there on day one. Data migration is part of scoping ($900 (€800)excl. VAT among the building blocks of my estimator for a standard migration, more if heavy cleanup is needed).
• Short training close to go-live, on each profile’s real tasks, rather than a general demo.
• Named leads in each team who can answer simple questions and escalate the rest.
• An end date for the old tool, announced from the start and kept. Moving from Excel to an application only makes sense if the file is then archived as read-only.

Measuring real usage

I recommend planning a few simple indicators from the design stage, visible in the dashboard:

• weekly active users, by team;
• the share of records created in the tool rather than elsewhere;
• tasks still done outside the tool, listed with the team leads;
• support requests, grouped by screen: they show where the interface gets in the way.

These measurements also feed the real return on investment, as explained in calculating the ROI of a business tool.

When a new tool is not the answer

Sometimes the problem is not the tool. If the process itself is unclear, or if two departments disagree on who does what, software will only make the disagreement more visible. In that case it is better to clarify the process first, even if that means postponing the project.

Likewise, if your team already uses an off-the-shelf product properly and the pain points are minor, switching tools costs more in adoption effort than it brings in. Extending what you have with a small custom component is often the wiser move.

Where to start

1. List your team’s pain points by asking them directly: re-entry, side spreadsheets, information nobody can find.
2. Identify two or three testers willing to give an hour a week during the project.
3. Book 30 minutes with me to check whether a custom tool makes sense, and with what scope.

Scoping, tested mockups, initial training and support are included in every business app project. Additional team training is listed on the pricing page.