Sheridan Pinheiro is an Implementation Success Partner in Legal Technology at Thomson Reuters, with more than 20 years’ experience spanning legal practice, knowledge management and innovation.
A common situation that keeps coming up in my implementation work goes something like this. A legal team has invested in a new technology platform. The vendor has handed over the keys. And the team is staring at a system that can be configured almost any way they want, with no idea where to start.
The platform isn’t the problem. The blank canvas is.
For many in-house legal teams, the underlying problem is structural. Work arrives through multiple channels – email, messages, informal conversations – with no consistent way to capture, track, or prioritise it. A missed matter, a request that gets lost in someone’s inbox, a GC who can’t answer the board’s question about team workload – these are the real consequences. Without a defined way of working, the team can’t report meaningfully on what it does, and without that reporting, it becomes very difficult to make a case for additional headcount or resources.
Technology is the obvious response to this. But the way these platforms are implemented can sometimes introduce a different kind of problem.
Most legal technology projects don’t fail because teams chose the wrong platform. They fail because they were sold infinite flexibility when what they needed was a clear starting point.
Operational control, without the overhaul.
Matter Management Foundations gives your legal team structured visibility from day one. See how it works →
When flexibility becomes the obstacle
Highly configurable platforms offer real value – technically. The same outcome can often be achieved several different ways, and for an experienced implementation partner, that range of options is useful. However, for a smaller legal team without the time or dedicated resources to evaluate each path, it can be overwhelming.
The question I hear most often at the beginning of an implementation project is: “Can you just tell us the best way to do this?” That question is diagnostic. It tells you that what teams are looking for isn’t more options – it’s a clear recommendation from someone who knows what works in practice.
A shift in what teams are asking for
The conversations I’m having with legal teams have changed over the past few years. The ambition used to be transformation: overhaul the intake process, rethink matter management, build dashboards for the board, all at once. Now the ask is more focused: solve one specific, high-friction problem first – centralise legal intake, get visibility on legal requests – and build from there.
This isn’t a lowering of ambition. It’s a more practical approach to achieve what actually succeeds.
Focusing scope is what makes progress possible
When a team tries to design everything from scratch, the project becomes a system design exercise. Decisions about how work should flow, who should own what, how matters should be categorised – these take weeks of internal debate before a single user logs in. The complexity of the platform creates a more complex implementation project.
The more effective approach is to start from a recommended configuration – one that reflects how legal intake and matter management actually work in practice – and adapt from there, rather than build everything from scratch.
Teams that begin with a defined structure, rather than an open field, reach a working system faster and build confidence in it sooner.
Built from repeated experience
The configurations that work aren’t theoretical. We’ve built them from watching the same problems repeat across implementations. Work falls through because there’s no single place to record it. Two people assume they own the same matter, or nobody does. Teams try to report on workload and find they have no consistent data to draw from – because the structure that would generate it was never put in place.
The patterns become clear quickly. Without structured intake, requests disappear into inboxes. Without clear ownership, matters stall or get duplicated. Without standardised reporting methods, the team can’t tell the board what it actually does. None of this is complicated, but you need all three working before anything else can be added to them. The value of packaging these elements into a recommended starting point is that teams don’t have to rediscover them. They start with a structure that reflects best practice, and spend their time aligning it to their context rather than debating what it should look like.
Getting to value faster
Because most of the structure is already in place, the nature of the implementation changes. The project becomes alignment work, not design work. Timelines shorten. Teams start using the system sooner, which means they start learning from it sooner.
For legal teams where time and capacity are already stretched, that difference is meaningful. A six-week implementation that concludes with a working system is more valuable than a six-month project that never quite settles.
Starting focused doesn’t limit what comes next
Starting with a narrow scope doesn’t limit where a team can go with their legal solutions; it’s usually what makes the next phase possible. Matter management is a strong starting point because it addresses the operational core – tracking incoming work, assigning ownership, reporting on workload – and it can be implemented relatively quickly. Once that structure is in place, extending it is straightforward: add a contract management workflow, build additional intake categories, connect it to existing reporting. The foundation makes everything that follows easier, not harder.
A more practical path to control
Gaining operational control doesn’t require a transformation programme. It requires a clear starting point and a structure that’s been tested in practice.
For any legal team assessing how to approach this: the right question to ask a technology vendor isn’t “how configurable is this platform?” It’s “what does your recommended starting configuration look like, and how many teams are actually running it?” If the answer is a blank canvas with infinite options, that’s a warning sign. If the answer is a defined, documented starting point with a clear implementation pathway, that’s the right place to begin. You don’t need to do everything at once. You need to start with something that already works – and build from there.
