They rarely fail on the technology. They fail on the human and structural side: no clear owner, scope that creeps, dirty data carried across, no change management or training, stopping at go-live, and starting with the tool instead of the firm. Get those right and the software almost takes care of itself.
After enough implementations you notice the failures rhyme. The system is almost never the problem — Actionstep, Clio and Smokeball all work. What goes wrong sits around the software, in how the project is owned, scoped and adopted. Here are the recurring causes, and how to avoid each.
When everyone is responsible, no one is. Implementations drift without a decision-maker inside the firm who owns the outcome. Fix: name a single accountable owner with authority to make calls, and a partner who backs them.
"While we're at it…" is how a three-month project becomes a year. Every addition delays value and dilutes focus. Fix: agree must-haves versus later, phase the rest, and protect the first go-live ruthlessly.
Migrating years of duplicates and legacy junk imports the mess into a shiny new system. Fix: cleanse before you migrate, and validate against the source before anyone relies on it.
This is the big one. A technically perfect system that people resist is a failed system. Change is a human process, not a switch. Fix: bring people in early, explain the "why", address the fear, and support the transition — not just the go-live.
Implementations don't fail at go-live. They fail in the weeks after, when the support disappears and people quietly return to the old way.
Training crammed into the final week, delivered once, is forgotten by the second week live. Fix: train in context, in role, and repeat — reinforce after go-live when real questions surface.
Go-live is the start, not the finish. The value lands in the optimisation that follows. Fix: plan for the weeks and months after — tuning workflows, fixing friction and embedding the new way of working.
Choosing software before understanding the firm guarantees a poor fit. Fix: start with how your firm actually runs and what you want to change, then let the system serve that — the sequence we hold to on our how we think page.
None of these are technology problems, which is why we treat implementation as a change project first. That's how we stay accountable through adoption — see How We Work, meet the team, or talk to us about de-risking your project.
Weak change management. The technology usually works — what fails is adoption, when people aren't brought along and quietly revert to the old way of working after go-live.
By treating it as a change project: a clear owner, early involvement, training in context, and dedicated support in the weeks after go-live when real questions surface — not just a launch and a handover.
Often yes. A health check can pinpoint where it stalled — configuration, data, reporting or adoption — and a focused effort on those gaps usually recovers far more value than starting over.