Legal operations departments aim to support the delivery of legal services in an efficient manner. To that end, resource management and solving problems through technology are core responsibilities of the department. But, the tasks of a legal department vary from answering legal phone calls, filing patents, reviewing and approving contracts, and litigating, just to name a few. With such a varied workload, what to automate can be difficult to identify. To help, I have put together a brief overview of where to start.
Step 1: Identification
Start by identifying the tasks that are repetitive. One of the best ways I have found to do this is to set up a quick 15-minute discussion with 3-5 representatives from different functional areas of your legal team, and from different levels (e.g. individual contributor, manager, function head). In that meeting, ask them one or all of the following questions:
- What tasks do you wish your team no longer had to do?
- What tasks do you want to be replaced by robots in the future?
- What tasks are low value but your team still spends a lot of time on?
You should not spend too much time here – the goal is to identify a pretty quick list that is top of mind for people. From these interviews, create a list for further vetting. Just in case you come up empty handed or aren’t able to get time with people within legal, here is a list of items that are commonly automated and we would expect to come up:
- Contract Automation
- Self service retrieval of boilerplate contracts (e.g., NDAs)
- Self service building common contracts (e.g., clause selection for vendor contracts, developer agreements)
- Request for review, negotiation, and signature of other contracts
- Legal Team Approvals
- Marketing document approvals
- Budget approval for any legal team spend
- Legal Assistance Requests (Intake)
- Legal research request
- Legal advice on an issue needed
- Need for outside counsel
- Patent Management
- Alerts for filing and renewal deadlines
- Automatically manage workflow for submissions
Select one or two items from your list and then validate it with your boss and/or general counsel. You want to understand whether others agree on the impact automation will make and identify any potential concerns.
Step 2: Build vs. Buy
Whether to purchase third-party software or build your own internally is always a good question to start with. Building your own tool gives you exactly what you want with, oftentimes, very little need to change your process. But, it is more resource-intensive both for the build and the maintenance. Buying off the shelf software limits you in what’s commercially available but it takes all the load off your development resources.
For some, build or buy may be an easy question as they may not have access to development resources. For others, they may not have any budget for an external tool and/or may be required to use internal teams. For most, however, they fall in the middle and have some access to resources and some budget (but usually not enough of either – that’s a whole other topic).
If you fall into this latter category, you will have to analyze your options. Your organizational culture will dictate what depth of analysis is needed. Regardless of the level of detail, the process is the same. The easiest place to start is by surveying what is commercially available. Even if you decide to build, knowing what software is out there, what features are available, and the general costs is helpful. Next, it is helpful to get an approximate cost of the build and maintenance if done internally. This can be a rough order of magnitude based on estimates from other internal tools developed or can be a more detailed estimate developed with the engineering team. Once you have the costs, you will want to add some information about the pros and cons of each solution – e.g., time to build and implement, technology dependencies (if known), other considerations (e.g., we are moving to the cloud in 6 months and we don’t know impact). Once you have this analysis, you can put forth a recommendation to your boss and whomever else is required to decide on how to proceed.
Step 3: Design
Now that you have a decision, you can move on to design. This is the most critical stage as this is where you are determining exactly what results your automation will produce. The first thing to do here is to map out your current internal process including who does what. You want to make sure you have a representative of each group take a look at the process diagram and validate it.
Once you have the process in place, you’re ready to work with the development team. If you are buying a solution for automation, you should be working closely with the software provider’s onboarding team to overlay your current process with the capabilities of the software. You will want to note where the software does not support your process and where changes will need to be made. If you adjust your process, be sure to involve the same representatives that helped with the initial diagram to provide feedback on any proposed changes in the process.
If you are building the solution, you will meet with your internal product resource. This person (or people) will want to understand the process diagram and may even want to watch people go through the process so they can understand user behavior. They will then likely convert your diagram into user stories that developers will develop against. Make sure to be as specific as possible in this process. This resource will be the one representing your voice with the developers so you want them to really understand the nuances of the process.
Expect some iteration back and forth during this stage and although I have simplified it here, this will be a long stage and the most important.
Step 4: Implementation
The final stage of the process is implementation. Start with a pilot of the automation. Either select a small use case or a small group of users and validate that your automation functions as planned. During this pilot project, it is really helpful to have resources from your software providers or from the development team readily available to make changes and help answer questions. During this pilot, you should also keep track of how the automation is performing versus your expectations. For example, if you expected it to save time, create a way to track the time it saves and report on that metric.
After a successful pilot and necessary refinement, you can move on to your full rollout. Create a plan that includes the deployment of the technology, training, feedback, and adjustment. Make sure to also identify the longer-term maintenance strategy that includes continuing to gather feedback and ways to improve the automation over time.
There are lots of great publications that go into further detail about each of the steps above, but hopefully this points you in the right direction. Once deployed, automation can be a very powerful tool that augments your team without adding additional FTEs.
Explore related content by clicking the links below:
- Legal Operations... Is it a Fad or Here to Stay?
- Budget Busters and How to Avoid Them: Budgeting Tips for Legal Operations Professionals
- Managing Your (Legal Ops) Budget with Five Simple Tips
- Putting Together an Effective Legal Strategy Session
- Delivering Value: Sharing Legal Department Metrics that Move the Core Business
- Legal Operations: Borrowing from Product Management Principles to Implement a Successful Contract Management Solution
- What I Wish I Knew Then - Common Challenges in Building a Legal Operations Department and How to Avoid Them
To discuss this topic more, please feel free to reach out to me at DJones@lighthouseglobal.com.
