Applying the ADKAR Model to Software Change in Your Accounting Practice

BLOG

Applying the ADKAR Model to Software Change in Your Accounting Practice

Changing software at an accounting firm is as much about people as it is about the platform. The firms that get the most out of a switch aren’t necessarily the ones with the slickest technical migration – they’re the ones where everyone affected was properly brought along for the change.

The ADKAR model, developed by Prosci founder Jeff Hiatt, gives you a structured way to do that. It treats change as something that happens one person at a time: a firm adopts new software once each partner, manager and team member affected has moved through five stages – Awareness, Desire, Knowledge, Ability and Reinforcement. Used well, it turns a software switch into something your team gets real benefit from, rather than just gets through.

What follows is our interpretation of how each stage can apply when you’re bringing new software into your practice.

Awareness: Explain Why the Change Is Happening

Software changes at a firm can feel unnecessary if things seem to be working well enough already. That’s exactly why it’s worth project champions — often the partners or managers driving the switch — taking the time to explain the change properly, rather than just announcing it.

Three things are worth covering directly:

  • Where the firm is heading. How the change connects to future goals — for the firm, for clients, for the team.
  • Why now. What’s making this the right time for the change — a quieter point in the financial year, other projects wrapping up, a growth stage, or a gap that’s become harder to work around.
  • An honest read of the current state. Naming where the current process is falling short shows the team you understand their day-to-day, rather than assuming.

Naming the specific opportunity tends to land better than a general statement about “improving efficiency.” A line like “we want to automate work that our current systems don’t support” gives people something concrete to picture, rather than a broader statement about progress.

Desire: Make the Benefit Personal

Awareness explains the change. Desire is what makes someone want to go through it. This is where “what’s the benefit for the firm” has to become “what’s the benefit for me,” and it requires you to know your team well.

CA ANZ’s 2025/26 member remuneration survey found that a manageable workload is one of the strongest drivers of retention for accountants, sitting right alongside fair pay and pride in the organisation. For a lot of accountants, what matters isn’t the list of features itself, but what those features add up to — fewer manual steps, less double-handling, and genuinely getting time back. For others, it’s confidence that the numbers are right, or peace of mind that a process no longer depends on one person’s memory of how it’s done.

Social proof helps too. If peer firms have already made a similar switch, say so – and if anyone in the firm took part in a trial or pilot before the decision was made, their honest take on the experience will land better than anything management says on its own. Seeing that someone else got through it – and is better off for it – does more to build desire than any explanation of benefits on its own.

Knowledge: Give People a Way to Learn the System

Once someone wants to make the change, they need to know how. Most software providers offer a good range of resources – structured courses, support articles, live training – and usually communicate these directly, making them easy enough to find. It’s still worth reiterating them yourself, though, to reduce friction and confusion. The clearer the course, the better.

Beyond the software’s own resources, there may be gaps worth building out yourself – how the new system interacts with your other internal tools, for instance, or anything specific to how your firm works that no vendor’s generic training will cover.

Ability: Let People Practise Before It Counts

Knowledge and ability aren’t the same thing. Someone can complete a training course and still feel unsure the first time they use the new system on a live client file. Ability is the gap between knowing what to do and being able to do it comfortably under normal working conditions.

Build in time for people to test the system without consequence – a demo client, whatever the platform allows. Expect the first few weeks to be a little slower than the old process, and say so up front, so people read that as normal rather than a sign something’s wrong. New muscle memory takes a bit longer to build than most rollout timelines assume, and that’s fine.

Reinforcement: Make the Change Stick

This is the stage that’s easiest to overlook, and it’s the one that determines whether the change actually lasts. Awareness, desire, knowledge and ability get someone to adopt a new system once. Reinforcement is what keeps them using it three months later.

In practice, this means:

  • Checking login and usage data where it’s available, rather than assuming adoption based on training attendance.
  • Regular, short check-ins – not just a single follow-up a week after go-live.
  • Naming project champions in each team, so support doesn’t rely on one person at the top.
  • Acknowledging the people who’ve made the switch, and showing the results: hours saved, tasks removed, WIP time down.

Reinforcement is also the stage that turns a change into a story the firm can point to – which then feeds back into Awareness and Desire the next time something needs to change.

Where We Come In

We provide onboarding support to the firms who move to Cimplico Workpapers, and we’re always happy to talk through change management – training resources, case studies from firms who’ve made the switch, whatever’s useful. If you’re interested in learning more about workpapers you can book a demo here.

See Cimplico Workpapers in action.

A scalable, cloud-based approach to workpaper preparation and review — built to give your team consistency, control, and visibility across every job.

Book a demo