Every law firm I've worked inside or alongside has, at some point, bought a system that was supposed to fix everything. A new case management platform. A lender panel portal. A CRM that was finally going to stop leads dying in someone's inbox.
Most of these systems work exactly as advertised. And most of these rollouts still underdeliver.
That gap isn't a software problem. It's a project management problem, and it shows up in almost exactly the same way every time.
The System Isn't the Change. The Habit Is.
When a firm rolls out new software, what's actually being asked of fee earners is that they abandon a workflow that already gets the job done, in favour of one that, for the first few weeks, will slow them down. Nobody adopts that trade willingly under fee pressure and billable hour targets. They'll use the new system when they're told to, for the parts that are mandatory, and quietly route around it everywhere else.
Six months later, the firm has paid for a platform that's running at a fraction of its capacity, and the CRM, the intake forms and the case management system still don't talk to each other, because nobody owned the job of making that adoption stick.
Multi-Office Rollouts Fail in the Gaps Between Offices
Add a second or third office to the mix and the problem compounds. A rollout that's been carefully explained and championed in one office can land as a confusing, half-communicated instruction in another, especially if there was no local advocate in the room when the decision was made.
"A system that isn't on a lender or case management panel at all isn't a training problem. It's a business development problem wearing an IT costume."
I've built exactly this kind of rollout from a standing start: getting an entire residential property team, across multiple offices, from not being on a major lender exchange panel at all, to functioning firm-wide within it. That only worked because it was run like a project, with a sequence, named owners in each office, and a clear read on where resistance would come from before it showed up.
What Actually Gets a System Adopted
The pattern that works isn't complicated, but it's rarely followed:
1. Sequence the rollout by office or team, not all at once.
2. Give each location a named point of contact who is accountable for local adoption, not just IT.
3. Train for the workflow people will actually use daily, not the full feature set.
4. Build in a short overlap period where the old and new systems both run, so nothing falls through the gap.
5. Follow up with the people who quietly went back to the old way, individually, before it becomes the office norm.
None of this is exotic. It's basic project discipline, applied to a rollout that most firms treat as a one-off IT purchase instead of a piece of operational infrastructure.
Why This Matters Beyond the Software Cost
An under-adopted system isn't just wasted licence fees. It's a live risk: data sitting in the wrong place, a compliance-relevant process being run from memory instead of from the system built to track it, and a client intake pipeline that looks automated on paper but is actually still relying on someone remembering to follow up.
If your firm has bought the right software and still isn't seeing the return, the fix usually isn't more training on the same system. It's treating the rollout itself as the project it always should have been.