Frustration To Automation: Practical steps for lawyers to transform the way they work
Authors: Anne Wong and Minwoo Yim
Table of Contents
- Assessing Your Current Process(es)
- Preparing Solution Requirements
- Prioritising Requirements
- Failing To Prepare Is Preparing To Fail
- What Happens When You Have More Than One Automation Use Case?
- Calculating Project Size
- Determining Return
- Alignment With Team Goals
- Time To Choose!
- A Challenge
It’s 11:42pm on a Tuesday night and your friend, Harold Gunderson (a lawyer) is still working on those never-ending documents for his client. The worst part is… he’s not actually drafting technical legal content.
Harold’s compromising his sleep time to manually:
(1) choose basic optional text in precedents;
(2) pluralise words; and
(3) insert repetitive data such as party and company details into documents.
To satisfy his standard of perfectionism and to avoid waking up from another nightmare about using the wrong ACN, Harold then spends another hour or two reviewing those details, ensuring that he’s copied and pasted all of the correct information into the documents. It’s now almost 3:00am.
If you’re a legal professional reading this article, you can probably resonate with Harold’s story. It’s incredibly frustrating, leading most of us to spiral and think…
“How did spending all those years in law school and completing the practical legal training or admissions exam lead to this very unstimulating experience?”
This is a critical moment…
Frustration can often lead to creativity and pain can be a very powerful motivator. From this experience, you’re now faced with two choices - you either accept or reject the status quo. If you accept it, nothing changes and you find yourself doing the same thing on your next matter at 11:42pm the following week. BOO! 😭
However if you reject it, you’re one step closer to making your life easier.
“They say that the best way to complain is to make things better.” - Seth Godin
When you reject the status quo, you’ll naturally begin to ask the important questions, triggering brilliant ideas to come to light.
“Surely there must be a better and quicker way?”
“Is there a way to improve (or even automate) this drafting process?”
Before we jump into how you can practically bring your idea(s) to life, we’d like to quickly introduce ourselves.
Ok so you’ve hit a big milestone! Through frustration and curiosity, you realise that there’s actually an opportunity to improve your drafting process.
What’s next?
- Assessing Your Current Process
- Preparing Solution Requirements
- Failing To Prepare Is Preparing To Fail
You may click on the links above to navigate through this article.
Assessing Your Current Process
Process underpins everything we do. Before you take any further action, it’s really important to understand and map out your existing processes (e.g. how the documents are drafted, the relationships between each document, the common data points etc). This will help you to:
- clearly identify your pain point(s);
- gain visibility and understanding of how things are done and why they’re currently being done in a certain way;
- establish the overall project scope; and
- avoid wasting money on automation software solutions that don’t solve the right issues.
All of the above information will provide you with accurate options on how to best address your current problem.
Think about it this way, would you make pizza (from scratch) without using a recipe? Probably not.
So… how and where do you start?
The first step is to do your research to capture all of the relevant information and data, like figuring out what ingredients you need to make that pepperoni pizza, and when and how to combine those ingredients. 🍕
Your research can be done by interviewing people involved in the overall process (e.g. stakeholders, subject matter experts, managers etc). You’d be surprised by how the interviews can illuminate additional steps or reasons behind those steps that you may not have been aware of.
💡 Tip: Interviews can be done one-on-one or in groups. You can also explore the use of post-interview surveys for further feedback if required.
The second step is to document your current process. This will include defining and identifying the tasks, tools, capabilities, people and third parties involved. Depending on what you find easier to do, you can either:
- visually outline the steps by hand or by using platforms like Lucidchart, Draw.io, Microsoft Visio, PowerPoint etc — see below image as an example; or
2. write out the entire process in a Word document.
The third step is to analyse the process to understand where the pain points are and why they’re occurring. Common things to look out for are:
👎🏻 manual approvals
👎🏻 repetitive admin tasks
👎🏻 bottlenecks
👎🏻 unnecessary correspondences (often due to potential misunderstandings or a lack of clarity on what’s required from each other)
Note: It’s equally as important to prioritise those pain points because it might not be realistic to address all of them at once. Let’s be honest, you’re most likely experiencing different levels of agony throughout the process.
💡 Tip: To prioritise your pain points, consider using the impact effort matrix below.
Preparing Requirements
Now that you’ve assessed the current process, it’s time to detail everything you wish your solution would look like so you can start mapping out the “future state”.
⚠️ FYI: Not detailing the requirements for your solution would be akin to building a house without a floor plan — chaotic!
Listing out your requirements will provide you with a clear guideline around what the solution should look like, how it should function, and more importantly, whether it addresses the pain points you’ve flagged as part of your existing process.
Defining Your Requirements
Leveraging the user story template below is one practical way to start defining your requirements for a future state solution.
As a [role], I want to [action] so that I can get [outcome].
As a [lawyer], I want to [be able to enter details of my transaction in an online questionnaire], so that I can [efficiently generate a suite of documents without having to manually edit any basic repetitive information].
Ideally your requirements should address any pain points that are embedded within your current process.
Note: The “Role” might be the same person the whole way down the requirements list. If so, no need to over think it — best to just address the action and the outcomes.
Prioritising Requirements
Once you have your list, you’ll need to start thinking about how to prioritise your requirements. Chances are there isn’t a solution out there that does everything on that list. So, it’s time to distinguish between which requirements are essentials and which are really just nice to haves.
A really easy way to do this is by using the MoSCoW prioritisation technique.
Named after its constituent components, the MoSCoW technique provides a clear way to organise your requirements and determine what your solution should look like.
Must haves (M)
These are the absolute essentials — without these, the solution would not work. A great way to determine whether the requirements are ‘must-haves’ is to examine the pain points list and identify if these requirements resolve those key pain points.
Should haves (S)
Requirements that aren’t critical to the success of the solution, but certainly deliver a lot of value when it comes to user experience and general functionality can be classified as ‘should-haves’.
Could haves (C)
Otherwise known as ‘nice-to-haves’. Whether you have these or not does not affect the outcome of the solution, but will add a nice touch.
Won’t haves (W)
Requirements that you do not need to add as part of this project.
All of these are good to note particularly if you have multiple stakeholders to manage and want to avoid scope creep. Remember to document anything that you want to explicitly exclude as part of this build.
Failing To Prepare Is Preparing To Fail
Defining and prioritising your requirements can be a time consuming task — but done well, it can make the rest of the solution build process so much easier.
These steps will also help with → Implementation and User Adoption!
If you’re curious about driving successful implementation and facilitating user adoption, drop a comment below! We’d love to share our thoughts and experiences with you. 😎
What happens When You Have More Than One Automation Use Case?
Our wise friend, Evan Wong (CEO of Checkbox) once said that “Just because you can automate everything, doesn’t mean you should”.
What about starting with the mammoth project that’s going to bring lots of value but take a long time to complete? Or maybe choosing the project that’s easy to implement, but brings only marginal value.
Sometimes it isn’t about choosing what use cases you could begin to automate, but rather which ones you really should be automating! Cliche but true.
It’s no wonder that this choosing process can be frustrating! But don’t worry, we’ve prepared a simple framework below to help determine what you should focus on. 🔎
You may click on the links above to navigate through this article.
Calculating Project Size
Partner: “So, how long will this solution take to build?”
Harold: 😳
This can be a challenging question to answer, particularly if this is your first time attempting an innovation project.
If you know, roughly, the amount of time it will take to build — great! Detailing this will help in step (3).
Otherwise, it may be helpful to use a simple t-shirt sizing exercise to measure the relative effort of each project.
Examine your project list, see how much you’re attempting to transform and note:
- S: Can be accomplished in a couple of weeks
- M: Might take a few weeks to a couple of months
- L: Will need a few months
- XL: May take years
Now if you’ve jotted down L or XL, it might be worth considering whether you can address a smaller portion of your solution and iteratively tackle it.
That is to say, instead of trying to address 100% of the use case, could you potentially address a smaller scope of the use case and achieve, say, 60% of what you’re (ultimately) trying to achieve?
This Minimum Viable Product (MVP) mindset will break down potentially high effort use cases into something more achievable and realistic.
Determining Return
How much time (and therefore money) will this particular solution save?
Don’t be surprised when your stakeholders grill you on this when deciding whether or not to invest in the project. They need to see how your solution will generate or save the business $$$.
Here’s a simple formula we’ve put together!
Return per year = (Hours spent performing the task pre-solution — Hours spent performing the task post- solution) ✖ Charge-out rate ✖ Task frequency per year
Here’s an example. It’s common for in-house legal teams to manually generate Non-Disclosure Agreements (NDAs) on behalf of the business.
Assume you have a team of 10 lawyers and on average, each lawyer drafts one NDA per week and that drafting process takes around 2 hours per NDA.
Hours spent (pre-solution): 10 lawyers ✖ 52 NDAs ✖ 2 hours = 1,040 hours
So in just this instance, your team spends over 1,000 hours a year on low value, menial work… 😱 (And that’s not even considering all the time that the business spends on NDAs!)
If an automated solution could help you draft an NDA in 15 minutes instead, that would be roughly 900 hours saved annually!
Multiply that by the average cost for a lawyer within your team (say, $300 per hour) and ta-da! You’ve got your $$$ dollar figure return for the solution.
(2 hours — 15 minutes) ✖ 520 ✖ $300= $273,000
To calculate your return on investment, simply divide that figure by the cost to use the solution over the same period.
Alignment With Team Goals
This is one point that we’ve seen grow more and more relevant over the past few years. Choosing strategically aligned projects can help with getting buy-in to change, and unlock further funding to focus on solving more problems.
You may like to start assessing this alignment by using a simple Low, Medium, High scale to determine which projects have a strong business case.
💡 Tip: Popular examples of the type of projects that your legal team may be looking to implement (which are likely to align with most strategic priorities) include:
- A matter management system to track what work the legal team is doing
- Automating a specific document that is frequently requested by the business (or a suite of documents for that matter!)
- Intake and triage to help the business self-serve their own frequently asked questions before engaging a lawyer
- Delegation of authority (e.g. approval process) self-service tool to help the business determine who is authorised to sign off on their agreement
Time To Choose!
The reality is — you won’t always have the capacity to be 100% focused on your project… and that’s okay!
Pick the project that (1) makes the most sense in light of your schedule and (2) fits the framework. If this is your first innovation project, consider starting with the smaller, easier to implement use case as it will demonstrate value quickly and get your work into the ecosystem.
💡 Tip: Avoid being a perfectionist and think of the MVP!
Your first project will help you better understand the parameters of the technology you’re implementing and hopefully create an environment that is conducive to further innovation.
A Challenge
You’ve gone through years of legal education and training… Don’t waste another minute of your precious time on low-value work.
Aspire to do more with less. Over the next two weeks, challenge yourself to proactively think about how you can enhance the way you work. How can you drive more efficiency and deliver better value to your clients? Is there an opportunity to revamp an existing process?
Reach out if you have any questions or need a sounding board, we’d love to connect over LinkedIn (@ Minwoo Yim and @ Anne Wong) and brainstorm ideas with you.
⚡️ ️COMING UP: We’ll be co-presenting in a webinar on legal tech on Thursday 29 October at 9:00pm (AEDT). Tune in if you’re interested in learning about how legal tech gets considered and used, as well as how lawyers and legal tech vendors can collaborate on projects! Here’s the link to register.
