Graeme Johnston / 9 March 2026
If you’ll forgive the gush, one of my favourite writers addressing “law meets tech” issues is Ryan McDonough. Something which makes Ryan’s work special is how he addresses the techy aspects in a highly specific way and links it up to realistic law-related needs in a meaningful way while not drowning the reader in unnecessary technical or legal detail.
My own work focus for years now, and that of Juralio, has been on process in legal work – things like planning, budgeting, adjusting to developments and learning from all this. As such, Ryan’s latest piece – Legal work is a planning problem not a question answering problem – is music to my ears. Please read it.
The fact that lawyers’ use of tech has become so focused on documents is understandable but, as Ryan notes, there is a much bigger picture. An obsessive focus on better or faster doc-handling only gets you so far: the more important question is “How do we build systems that understand where a legal matter is going next?”
All I want to do in this piece is to offer some information on how Juralio and I approach two of the themes in Ryan’s article.
1. Process mapping and the challenge of detail
The first point concerns the level of detail in which processes are mapped. The term “process mapping” in legal has become associated in practice with a highly detailed approach in which a highly repeatable “volume” type of work is modelled in great detail in a rule-based system which also assembles documents from templates. Traditional software with all edge cases handled, something which involves a level of effort you won’t believe unless and until you’ve actually tried it.
But in practice, as noted in Ryan’s article, lawyers can and do learn how to do a particular type of complex work in ways not readily modelled as detailed rules in that traditional software sense.
To help with that type of work, less is more when it comes to software. The process should be modelled in a way which strikes a balance between desirable consistency and necessary flexibility, not trying to capture too much by way of rules, and ensuring that what is modelled in software is at a level of detail which is approachable in practice by a wide range of people.
Practically speaking, this involves building process maps / project templates (whichever term you prefer) which start at a high (phase) level and include deliverables, milestones and underlying tasks at a level which is properly designed, tested and improved with real world users. Which in practice involves not building too much detail initially, but getting the broad lines right first. This creates value quickly, and details can be built up later. Progress over perfection, as lawyers have lots of ways to fill in the gaps which arise in practice.
One point I would emphasise here is that there is an engineering tendency to emphasise dependencies. But in practice complex legal work often involves elements of parallel work which are tricky to map precisely, and which vary from matter to matter. Dependencies are often softer in complex work and, crucially, mostly obvious to lawyers with even a small amount of experience in a particular area. And lawyers tend to be good at handling them pragmatically. The need for detailed modelling is less than might be thought. And anything you can avoid doing in this area is helpful in that it reduces the challenge and cost of mapping.
On the other hand, deliverables and assumptions – mentioned by Ryan in his article – are enormously important for complex legal work for any client who wishes to control budget effectively and for any legal services provider who does not have a blank cheque for how to handle a matter.
What this boils down to is
- Mapping the process for complex work can be relatively quick to see value from, as a “minimum useful process map” is quite light. This contrasts with a classical highly detailed logical path approach which models twists and turns in great detail.
- Once you have that minimum version out there, you can then gather data on how people use it, and start building up improvements.
- You still need to do the initial mapping work, though, to give it a sensible shape which can be extended elegantly. Leaving it to AI, for example, is not a great idea.
- The return on investment from doing the work can come rather quickly if you take this approach.
- The cost side of the ROI is therefore less than might be feared. And in expressing the benefit side of ROI, issues such as institutional knowledge, educating new team members, better budgeting, improved situational awareness and reduced risk should all be taken into account.
To reduce the cost of getting started, make it clearer how to do it, one of the ongoing open source endeavours I’ve been undertaking with others in noslegal in recent years is mapping elements such as phases, deliverables and work required to get different types of legal matter done.
You can find what we’ve done already in facet 8 of the March 2025 noslegal release. And, although the current (2025/26) round of work in noslegal (due to release in May 2026) is focused on other things, the expectation is to build out more of these work elements in the 2026/26 season. Let me know if you’d like to participate.
And on the Juralio software side, we enable these things to be mapped very easily, linked up to your document-related knowledge (such as templates, guidance notes and doc assembly flows) and then used in actual matters.
2. More automated approaches to situational awareness.
As Ryan observes, getting people to update a system of record about the status of a project can be a challenge, irrespective of domain. It involves a habit change, which is never easy even when the benefits are clear.
One big thing to focus on here, we’ve found, is that the various benefits of keeping things up to date – such as easier reporting, better budgeting, happier clients, better profitability, lower risk – are understood and motivational for some people but not everyone.
One solution for where some people won’t engage is to focus on helping those people who get it to do so easily, and to ensure that those who don’t still see some immediate benefits, for example being able to click through an update email to see the status of work much more reliably and easily. This can unlock better engagement over time.
One thing clients can do, for example, is to insist on their lawyers keeping the system up to date so that it provides an accurate record of status. This benefits the client but also the lawyer as there is no need to duplicate this with manually-prepared reports. And this trade should be emphasised: “We’re not asking you to do more work, we’re asking you to do it in this more beneficial way.”
But automation of updates is a sort of holy grail in this area for the reasons Ryan gives. My two cents on that problem, based on our experience:
- First of all, it’s a reasonable assumption that lawyers doing complex work will continue to work in their established email and document software (notably, a DMS) supplemented by a separate budgeting / projecting software (such as Juralio). Putting all eggs in one basket on this has well-known risks.
- That being so, the question arises of integration between these applications. Our approach to that is to be agnostic as to the precise way in which a customer wishes to analyse their emails, documents and (where relevant) chats for project-relevant information, but to encourage them to do so outside Juralio and just send us succinct indications of suspected updates.
- This involves linking up matters in Juralio with matters in (e.g.) a DMS then filtering emails and documents for likely updates on the DMS side then identifying, again on that side, what kind of update it might be. There are some important cost / confidentiality / accuracy issues to balance here and it is ultimately a % game rather than something on which perfection can be expected.
- We don’t want to be processing documents and emails ourselves for this purpose, and we don’t see any likely demand for us or similar products to do so.
- The next step is then to feed these updates into Juralio and to display them in relevant context. And in UI terms, not just present them as a long list of updates to work through, but against particular phases, deliverables, milestones and tasks.
- And in all of this, there needs to be a human involvement in validating or amending the updates before they are adopted in Juralio as definitive updates.
Success here is not perfection: it’s about making the updating easier and quicker and more accurate by a variety of complementary means. This is a substantially better path than the alternatives of
(i) leaving lawyers just to work in email / docs and hoping AI will sort it out one fine day, or
(ii) expecting lawyers to migrate entirely to a work management platform and leave behind their existing ways.
An approach as we’ve outlined can unlock a lot both in terms of immediate value and in what it lays the data foundations for not so far down the line.
Whether you call it “agentic AI” doesn’t matter. That phrase can perhaps be off-putting as it feels hypey to many and also risks underplaying the human element. But that’s just personal taste.
I hope these thoughts are helpful and, again, please read Ryan’s article if you haven’t already done so!