May 2025
Why legal tech implementation fails, and what to do instead
By David Curtain
We’ve all been through it. The weeks of building the business case, the endless vendor demos, navigating the internal politics, and finally, the relief of securing the budget. You’ve finally got sign-off from stakeholders who may not fully understand the detail, but are very clear on the cost.
So, when the new tool is finally implemented, there’s a quiet, collective sigh of relief. The heavy lifting is done. This should just work.
A few months pass. You look at the usage data or, worse, you look at your team’s screens, and you see it. The system is being bypassed. People are back to their old ways of working – with all the chaos, inefficiency, and general lack of coordination that you bought the tech to avoid.
It’s easy to blame the software. You start wondering if you picked the wrong vendor or if the product was over-promised. I’ve spent years watching teams buy tech and fail to get anywhere near what they thought they would from it. In most cases, the problem isn’t the tech.
Transition, not transaction
The problem is treating the purchase of technology like a procurement activity. It’s much more complex than that – it’s an operational change. One that requires a lot of careful planning and support if you want to see results. If you’re popping champagne on go-live, you’re looking at it the wrong way. It’s worth celebrating, but it’s not the finish line. Your team is about to surprise you with all kinds of unexpected questions and behaviour. There’s a lot of work still ahead of you to help them successfully adopt this new tool, and honestly, some of them are sitting there quietly pledging to never use this stupid thing.
When a new system enters a team, it doesn’t magically clean up years of mess and ambiguity. If there were issues with the way people were working and you don’t fix them before you add new technology, it will amplify the chaos. And it can also make people feel threatened and resentful if it’s not rolled out properly.
To avoid a tech purchase being a monumental waste of time, ask:
- What does the current workflow look like?
- What specific problems are arising with that workflow, and how often?
- What are the consequences of those problems, and how important are they to the business?
- Why are those problems arising?
- What are the most important things we need from the tool?
- Who will own the project to select, purchase, and onboard this tool?
- Who is going to manage and maintain this tool?
If you don’t address these issues before engaging with vendors, you’re likely to waste a lot of time and money – two things that no in-house legal team has enough of. The early work is hard, messy, and takes time. It’s very appealing to skip it.
But skipping it means you’re likely to buy something that won’t solve your problems. Obviously, it’s hard to solve those underlying problems if you don’t even know what they are. And your people won’t adopt the new system if they don’t believe it helps them.
Without involving the people who will actually be living in the system during the design phase, you’re not building a solution. You’re just forcing them to adopt your version of reality (spoiler alert: they won’t adopt your version of reality).
True adoption starts with consultation. Innovation is not tearing the wrapper off a shiny new tool. The tool lands as ‘innovation’ when it comes after careful, thorough analysis to really understand what’s missing and what’s needed to fill that gap. Tech vendors won’t tell you how often these projects fail because their customers don’t do this work (Bain recently reported this failure rate to be 88%).
Someone needs to lead
These failure rates are high because there’s often a big gap between what the tech can do and what most buyers think they’re getting. Most buyers don’t really know what they need or understand what’s required to use the tool as intended. Someone needs to lead the project from inception, through onboarding, and then manage daily. Systems need maintenance. There will be bugs, friction points, and user questions. All tools need to evolve to remain relevant.
To keep a tool from drifting into disuse, you need a system owner who has:
- The skills and time to maintain and improve it;
- The authority to make changes as the team’s needs change; and
- A direct line to feedback from the people actually using the tool.
This person is rarely a lawyer. Whether you call them a legal ops or tech lead, a legal engineer, or whatever new term LinkedIn throws at us next week, you need someone to sit in that space and make the machine hum.
Don’t rush it
Legal teams are under a lot of pressure to use AI to deliver efficiencies. It’s tempting to think that it’s as simple as buying the latest tool to achieve this.
Before buying a tool, ask yourself two questions:
- Have you done the work needed to understand what tool the team needs, and how it should be used?
- Do you have the right people to buy, set up, and manage the system (i.e., the people who have the skills and time to do this properly)?
The most successful teams don’t have the most tech; they have the tech that is most aligned to how their people work. They have streamlined their processes so the technology supports, rather than dictates, the day-to-day.
Stop treating technology as a procurement project. Start treating it as the beginning of a long-term conversation about improving how your team works. It’s the only way to ensure your tech works as hard as you do.
