Logan OliverFollowAug 31 · 10 min read

Legal design: the oft-overlooked hero of innovation

Legal design isn’t talked about enough. That may sound like a backwards way to start given that most of the people that are talking about legal design seem to say that everyone is talking about it, but I’m not so sure. On LinkedIn, #LegalDesign has only 3400 followers, trailing sorely behind other “innovation hashtags” for the industry like #lawtech (5.3k), #LegalInnovation (11.8K), and especially #legaltech (58.2K). Numbers vary by platform but generally maintain the same trends. Even in our experience speaking with law firms, it is very rare that the topic of legal design crops up.

I find this interesting as a “tech vendor” because legal design in some form should be core to the majority of technology procurement. Full disclosure: I am not an expert on legal design. I’ve done a couple seminars on the topic, find it interesting, and want to learn more. That said, I can speak to a particular element of legal design that I’ve noticed surprisingly absent from conversations we’ve had with many firms: process.

My long term relationship with processes

My path leading to Office & Dragons has always surrounded process improvement. It’s somehow become part of every corporate job I’ve had in some way or another, from Blackberry, to Amazon, to BT.

In a way it makes sense given my upbringing. I was raised in a process improvement household. Not the most mainstream upbringing, I’ll admit, but it was mine. My mother is a Lean Six Sigma (L6S) black belt (yes the terminology of all these methodologies is bizarre, but what can you do?), and growing up we used to talk about processes frequently. Conversations led to reading L6S books on rainy days, to eventually getting my first corporate job at 18 as a “support coordinator” at Blackberry.

To this day I’m not exactly sure what my job was meant to be, but after about a week of trying to figure it out I was struck by how inefficient our internal processes seemed to be. How was it possible that they were inefficient? This was a tech company. The people here wore collared shirts with jeans and their phones in holsters on their belts! This was the pinnacle of cool. Clearly I was incorrect, but my naïveté washed away quickly as my first dose of the real world sank in.

I immediately approached my manager and asked her if she was open to me looking at our processes and trying to streamline the team. At this point I had the book learning of a L6S green belt. All that was missing was my first real project and the piece of paper that said I spent a couple thousand dollars to get there. I can only imagine what my manager must have thought of this brash 18-year-old, making minimum wage, asking to run process projects for her team. In the end, she relented, and whatever a “support coordinator” was meant to do, I was now the “process improvement person.” Some version of that story recurs no matter what role I am in: I become obsessed with the processes and look at how we can improve them.

Okay enough about me, what does any of this have to do with Law?

So here I am working with the legal sector, and I don’t see much process improvement at all. Why does it matter? Why SHOULD you be talking about processes in your firms? Is that not only relevant for factories or call centres?

The fact of the matter is that process is a major factor to be considered in any innovation. The problem, I first learned at Blackberry, is that most businesses overlook it. People generally get excited about innovation and dive headfirst into implementing improvements. How many times have you heard people talking about making minor tweaks in the name of improvement and labelling these “quick wins?” These are generally people who don’t consider the process. Whilst well intentioned, they often end up creating more problems than they solve.

It is not to say that there is anything inherently bad with a quick win. If it is truly quick and truly is a win? Fantastic. The problem is that most people chasing quick wins simply do not know. They are approaching innovation from a position of limited data. They generally have personally experienced a pain in the process they are looking to fix (be it as the operator, the customer, the owner, or any other stakeholder in the process). They identify something that could be changed, tech that can be used, or some form of innovation that they feel will ease their pain in this process.

But this is all good right? The people involved in the processes fixing their own challenges! That is surely a good thing, right? Not quite.

Now, sometimes we get lucky! The quick win was an appropriate and meaningful bit of innovation, and it solved the problem, eased the pain, and made the process smoother for everybody! However, more often than not, we end up with one of two scenarios.

1. When zooming out a bit and looking at the end-to-end process (instead of the limited portion that the would-be-innovator is trying to change), it turns out that this “win” will either shift the necessary work to another part of the process (bad), create more work further down the line (worse), or expose the process to some greater risk or defect that jeopardises the efficacy of the entire process (worst)
2. These quick wins potentially have some small marginal gain in isolation, but over time quick wins are layered over quick wins, and the overall solution begins to resemble something out of a Mary Shelly novel. In these circumstances, the quick wins in aggregate usually end up hindering the process. They also have the added detriment of being extremely bespoke and complex, making it more difficult to not only operate, but also to identify the root causes of issues to facilitate future innovation.

When you’re looking to implement any kind of innovation, especially when that innovation will impact a workflow that spans multiple teams, you need to start looking deeper at your processes before you begin implementing any wins, be they “quick” or not.

If quick wins are out, how do I DMAIC it better

There are a ton of different methodologies out there that provide tools for approaching the question of how to assess innovation — from Agile, to Just-In-Time to Kaizen — and they all have their merits. In practice I’ve found the end results tend to be similar, but the approaches and methods are slightly different. I am most familiar with L6S, so I’m going to share the approach L6S uses to assess innovation opportunities: the DMAIC approach.

DMAIC stands for Define, Measure, Analyse, Improve, Control, and is the order of operations when running a L6S improvement project. There are swathes of tools, rules, and technicalities that make up each letter, but I’m going to keep things simple here, as a gateway to start implementing this kind of thinking when you approach innovation. There are tons of examples and templates you can find online to help you with specific tools if you’re interested in digging further (isixsigma has a good roadmap that outlines a whole array of tools you might use at every step in the DMAIC process. Check them out here https://www.isixsigma.com/new-to-six-sigma/dmaic/six-sigma-dmaic-roadmap/).

Define what it is we want to do

First, what is the problem you want to fix? This isn’t the root cause of the problem yet; you want to keep things higher level (too many assumptions at this stage may blind you to the real root causes that you could uncover later). At this stage, the most important things you want to consider are the scope of the project and your desired impact. To learn the scope, you’ll need to step back and get an idea of the high-level end-to-end processes that are at play here. That could be an initial client onboarding process, how you determine your fee structure for a matter and communicate it to a client, or even how you train your new staff. Once you’ve determined the scope, align on the problem and the desired outcome (again keep it high level). For example, “When onboarding a new client, it takes too long to get an engagement letter signed. We would like to streamline this so that we don’t delay in kicking off the matter.”

It is worth calling out at this point that you should use the Define step to apply a bit of proportionality. Process improvement takes time. While the DMAIC process is important, being overzealous can turn a project from a week’s worth of work into 6 months if you apply the structure too rigidly. I always allow the scope and desired impact to guide how much time, relatively, will be spent at subsequent steps. If this is an organisation-wide change that’s going to be a major investment in time, money, and resources, then applying the DMAIC approach more rigidly may be warranted. That said, a project that will make incremental change to one team, while still worth pursuing, should be approached with an amount of effort proportional to the improvement itself.

That was easy enough, but make sure to Measure twice, cut once

Now we know what we want to do and how big a project it’s going to be. Measure is the next step, and it’s the one most people overlook when we start. If I’m going to implement an improvement to our post-deal learnings process, I better make sure I know where we are today!

Now is the time we look to understand each step of the process to gather data that will allow us to understand which parts are not working. This is often started by undertaking a process mapping exercise. Process maps are invaluable in helping understand what happens at every step of the process and how every input feeds into the wider product/service/output. The process map will identify every decision point, input, output, and processes that exist within your workflow. You can then collect data around key metrics like lead time or quality of outputs. Once you’ve determined the baseline of the process, you can move to the analysis.

Before you get ahead of yourself, time to Analyse

What is causing the problem? One of the biggest challenges at this stage is to avoid simply jumping to a solution without understanding its root cause. As with the quick wins discussion above, this can lead to implementing ineffective fixes, and increasing variances in your processes. This is the time to think and review. Use the understanding of the process built during Measure and consult the data to form hypotheses as to what is causing the issue you’re trying to solve. Constantly challenge these hypotheses and try to prove them wrong. The most important thing here is to cut all assumptions and only focus on the causes that are verified as contributing to the problem you are looking to solve.

Both the Measure and Analyse stages can be supplemented with a lot of statistical analysis, comparing relative impacts, standard deviations, and a lot of additional complexity. As discussed above, you should have determined how necessary and granular that needs to be back at the Define step.

The moment we’ve been waiting for… Improve

Have we done it? Are we there? You have defined the problem, understood the impact it is having on the business and its processes, and have identified and verified the actual causes of those problems. So, yes! Now it is time to actually fix the problem.

This stage is all about planning, piloting, and ultimately implementing the actual process improvements. Key, however, to this stage is to collect more data and compare it to our baselines from the Measure phase to confirm that what we are implementing is making a meaningful change. This also makes it much easier to compare and evaluate multiple solutions to the problem. Do I want my document services team to manually handle this work, or will there be a greater impact if I onboard a solution to empower the associates on the relevant team to do the work themselves? A structured improvement effort can lead to innovative solutions that remove the pain experienced and ultimately, improve client experience.

But we aren’t done yet, never forget to Control

Wait, but we did improve. We innovated. Surely we’re done now? Here is where we start to see the adoption question pop up. How do you sustain the improvement? At this stage the question moves from one of process improvement to one of change management. It is a difficult but necessary task to maintain the new standards and best practices you’ve worked so hard to accomplish. Without it, people will revert. It can be helpful to draft a plan to track the success of the updated process, and plan in advance what the appropriate response will be if performance begins to dip. It must be the job of the owner of that process (whether that be a partner, a supervising associate, or a member of the KM team) to ensure the execution of these plans. It is their responsibility to smoothly transition the team from the old to the new and ensure the process is adopted and becomes the new norm for the workflow.

Wrap up

And that’s it! There is no magic to process improvement. All the fancy language and tools that float around for various methodologies can be helpful in getting teams aligned and on the same page, but the most important part of process improvement is the mentality.

In practice, when done correctly, considering your processes when implementing any change can make the entire process much easier. At Office & Dragons, we definitely take this mentality to heart, and so much of our early discovery with our most successful customers is dedicated to understanding those first three letters in the DMAIC method. It helps partners and tech leaders in the business craft more informed business cases to assess if there really is a fit, and helps drive training and adoption by better understanding exactly where and how O&D fits into their existing workflows.