Confessions of an Operations Guru Turned Legal Ops Novice, Part 5:
5 Things You Actually Need to Know for a Successful Contract Management Software Implementation
Implementing a new software is no simple task. It doesn’t have to be a nightmare either, but accounting for the all the ways you want your software to work is an important piece of the implementation process.
Today, we’ll start the final leg of our “Confessions of an Operations Guru Turned Legal Ops Novice” series of posts. This upcoming set of posts will cover Implementation and Adoption. In the coming weeks, we’ll be discussing document templates, saboteurs and roadblocks, user acceptance testing, training, and follow-up – all elements of software implementation I have been through many times, and several of which I’ve found to be our clients’ biggest sticking points.
Client involvement is critical during implementation – it doesn’t matter how wonderful a system you’ve selected, if it’s not implemented in a way that serves you and your team, you will not receive the benefits you expected.
Implementation begins with gathering information and planning for phases. Now, a lot of posts you’ll find on this subject are filled with incredibly pertinent information about project managing the installation and implementation of a solution. These articles, like this one, are wildly helpful, and I greatly encourage you read them. Nonetheless, from a provider perspective, there are a few things that aren’t frequently covered in these articles that new software purchasers should have in their back pocket.
Determining which kinds of matters you want to be able to create in your system, and what fields/types of information you want to collect for each of them, is an early, critical element in your implementation. Knowing these can lay the foundation for long-term successes, as well as ease the later elements of your software creation.
Below are a set of elements you will want to consider as you think about your matter types and fields. Each will impact this first step, and should be discussed by your implementation team. When building this team, be sure to include knowledgeable members of each team impacted to ensure the system meets each of their needs.
1. Reports
Understanding which reports you want to pull not only helps you understand what fields you need to have and track in the system, but can also be an important part of determining which solutions have the reporting capacity you need. Don’t get burned by a great system with bad reporting capacities!
2. Intake Requirements
There are several important questions you’ll want to ask when looking at the intake element of your solution:
- Do other departments, or people without a login, need to be able to submit requests to the legal team?
- For other teams, what fields do you want them to be able to see/fill in during their request?
- For other teams, what fields do you want to be required so that they can’t submit the request without providing that information?
- For other teams, what kind of confirmation information do you want them to receive after submitting a request?
- When a legal team member using your system creates a matter, do you want additional, internal fields to be visible to them/required from them?
3. Document Templates
I find that many clients do this in phases. Document templates often seems to sneak up on new software purchasers during the implementation process, and if they weren’t using consistent templates prior to buying software, they have to (internally) create something completely new just to move through that part of implementation. This is OK. The beauty of document templates is that you can change them at any time, add more, retire them, split one into two different templates, and more. So, if this portion of implementation is stressing you out, let yourself off the hook a bit. It doesn’t have to be perfect at the start – you can always edit it after it’s generated.
To start, I recommend thinking of your low-hanging fruit. What are several frequently created or simple contract templates, like an NDA or MOU, that you can use to get your feet under you? Next week, we’ll be going through document templates in depth to help you think through what you’ll need. For now, just be thinking about what you want to auto-populate into the template. Those will be clues into fields you’ll need in your system.
4. Pain points/Administrative burdens
What are the point points you tend to experience when moving a matter or contract through your processes?
Have a list of problems you want to solve so that you can approach them with your solution’s implementation team. From this, you’ll learn how the solution can solve the problems, and likely where your automated workflows will need to be developed.
In my experience, workflows are often implemented in phases. ALOE, for instance, comes with three automated workflows included in our implementation package. Typically, our clients easily stay within the three included, and after they have successfully adopted the tool and understand where the largest pain points remain, may phase in new workflows when they are ready.
5. Messaging
This is a step that you can’t quite plan for until you get there with your implementation team, but it is one of the most highly edited elements of our workflows, and can often be sticking points for teams. At various points in workflows or intake processes, you may have email templates that are sent to outside parties, internal approvals, or the requestor. Intentionally thinking of what information you want included in these notes as they are created will make the final portions of your implementation process much easier.
