HOW TO BUILD THE BUSINESS CASE FOR A CONTRACT MANAGEMENT SYSTEM

On today's episode of the Contract Lens Podcast, Gary Zuder, VP of Sales at Malbek, chats with Matt Linder, Senior Manager for Stout's Legal Management Consulting practice, about how to build the business case for a contract management system. Matt begins by explaining how creating several "flavors" of the business case improve the effectiveness and cohesiveness within an organization. Matt shares the who, what, and how that goes into a business case and the best ways to appeal to all facets of the business impacted by contracts. Using anecdotes from his experiences defining business requirements, he points out that the best business cases go way beyond cost benefits to align with business goals. He also dives into the pains, gains, and fears that push companies to buy and how to show that a CLM solution can help solve these problems. So grab a glass of wine – or beer in this case – and let's talk contracts!

 

 

Transcript

Intro:
Welcome to the Contract Lens podcast, brought to you by Malbek. In this podcast, we have conversations with contract management thought leaders and practitioners about everything contracts and its ecosystem. Today's episode focuses on building the business case for a contract management. We are joined by Matt Linder, senior manager at Stout. As part of Stout's legal management consulting practice, Matt assists corporate counsel and law firms to contain risks and costs through contract management process improvement. He is an expert at defining business requirements and helping companies select legal tech to meet their individual needs. So now, it's time to relax, grab a glass of wine, and let's talk contracts.

Gary:
Hi there, Matt, how are you today?

Matt:
Hey, Gary. I'm doing great. Thanks.

Gary:
Great. It's our pleasure to have you as part of the contract lens, so thank you for making some time. I think we're going to have a great session today.

Matt:
Yeah, I agree. Thanks for having me on.

Gary:
Sure. What's interesting is that we have somebody from Malbek and somebody from Stout. So I think at the intro we say grab a glass of wine, but if beer's your thing too, that's no problem in this case,

Matt:
I'm raising a glass. I love it.

Gary:
Perfect. Matt, we're going to talk about a business case today, and it sounds kind of scholastic, right? People talk about, "Oh boy, I have homework to do," that kind of thing. But in today's day and age, what we're seeing is, especially with the pandemic and people restructuring their application infrastructure, lots of mergers and acquisitions. And there's tight competition for dollars to be spent on a variety of areas, whether it be people, technology, process, whatever it might be, especially in the case of CLM, contract lifecycle management, which sometimes resides in legal, but also touches other areas. I'm going to throw a softball, I guess, as I first started this conversation out, but a business case, is it really even required?

Matt:
Yeah. A little bit of a trick question there, Gary, to start. The way that I would respond to that is it's required in various flavors. To your point that you made just previously around the pandemic, COVID has made companies a little more selective and the technology initiatives they're pursuing. And I guess that I'd say on the CLM side specifically, is that it's at the top of many organizations; minds right now, given its inherent focus on placing information at your fingertips, even outside of the office, especially through things like electronic signature.Matt:
I think a business case also can create a very real emotion in people which is more centered around intimidation when crafting the business plan. People immediately jumped to ROI and it trips them up a little, and there's a lot more to a business case than just the hard dollars. This is really an opportunity to involve a multitude of stakeholders, secure commitment. And without it, you're operating in silos and putting the entire effort at risk. This type of exercise is important. It encourages tough discussions with a variety of different opinions and perspectives. And candidly, it's very helpful.

Gary:
You know what, Matt, people look at this creation as a task like it's their responsibility, it's their deal only. And I think what I heard there, it's an opportunity to understand your organization a little better, maybe reach out a little bit and find out are there commonalities and business challenges that you may not be aware of. So if the company culture is what it should be, that should be a natural thing to do, to say, "Okay, this isn't just my task. Maybe it's an opportunity to get to know my colleagues, get to know department heads," that kind of thing.

Matt:
Absolutely. It's really the beginning of the requirements gathering exercise. You need to solicit buy-in and support. And without that, your potential for automation through a technology like CLM is very limited because you're considering individual groups in silos as opposed to the entire enterprise.

Gary:
So Matt, what kinds of departments, and you've been doing this a long time and you have a certain focus for certain areas of the business, but from previous discussions, I understand that this is expanding a little bit across different kinds of departments for different reasons. Can you walk me through a little bit on, aside from legal, maybe what areas of the business are needing this type of technology or that might touch this type of technology?

Matt:
Sure. So one department that comes to mind immediately obviously is IT, given that this is impacting the technology landscape at the organization and there'll be a need for ongoing support and maintenance, as well as IT being the client in this regard, right? There's a variety of IT contracts which can benefit from technologies like this. Of course depending on the problem that the organization's looking to solve and the complexity and the maturity of the organization, procurement or finance, or even a contracting team, which may be onshore or offshore, may be involved in this process.

Matt:
We're working with an organization right now that's chosen to outsource most of their non-disclosure agreements and some other more standard, low complexity contract types to an offshore team. And they're realizing a significant amount of cost savings from that. And as a result of their interest in purchasing a CLM solution, we've had to work with them to gather requirements from the various groups, including this offshore team. So it can really touch a variety of different groups.

Gary:
So when you're having this conversation with IT, are they interested in other areas of the business that can also benefit? Are they being brought into the conversation later if they're not the sole focus of the conversation?

Matt:
Typically they're being brought in a little later in the process, Gary, more so at the point when the business case is continuing to develop and mature and gearing up for presentation and approval. It really depends on where the need is emanating from. I think IT is being viewed in most organizations more in a role of supporting the technology as opposed to being the primary users of the application.

Gary:
Got it. Perfect. Well, let's take a half a step back and expand upon that business requirements gathering. Obviously that's the first step, is understanding why you even need this? Can you walk me through, if I'm sitting there at my desk and I say, "Okay, I have to go prepare a business case for contract lifecycle management system application," where do I start? What is the first thing I do? I pick up the phone, who do I involve? Who's going to help me get this thing started?

Matt:
Well, I think the first thing that you do is is you take a half step back and understand your users and the problems that they're trying to solve. Defining what success looks like is paramount to this exercise, and the success criteria will be a guiding force as you get into the selection and implementation exercises.

Matt:
I think also it's important to consider how this initiative aligns with enterprise goals, right? That can make the justification process quite a bit easier and can help resonate with some of the decision makers in the organization.

Matt:
The other thing that I would note at the start of preparing the business case is to start to consider some of the components of the project charter, some initial timelines. What are some of the risks that are involved in not moving forward? Once you have a good grasp on that, ballparking the estimate that's needed and considering very informed assumptions and benchmarks can really go a long way. The best business cases demonstrate more than just the one benefit, right? It's not just cost benefits. It's efficiency gains. It's quality gains. It's consistency gains in the way that that contracts are being presented and authored.

Gary:
This actually reminds me of a recent experience with my fifth grade daughter. She actually had to be part of a invention convention, and I thought it was going to be the funest thing we've ever done. So what we're going to do is we're going to make some really cool thing that no one's ever seen before. We're going to show how cool it is, but the first thing she had to do was like a 20 page business case. She had to understand the market. She had to understand the strategy, the need, the competitors out there, what competing technologies existed. So this is something that every age group has to go through. And it's good to know that some of the school-age children are learning this, because again, as you mentioned, just understanding the success criteria of the business is so important.

Matt:
It's funny you bring that example up. That just stirred a thought in my head. I remember my first year of college, as part of business school, they required us to come up with some certain ideas that we would present as part of a business plan and a business case to different banks to solidify funding. And it was the crux of the entire class for that semester. And while it was an intimidating experience, it was certainly impactful and rewarding to be able to think through some of these ideas and consider the different competitors that are available in the market for these types of things.

Gary:
And I assume that when you went through that exercise, it was a team exercise in the class-

Matt:
It was.

Gary:
As part of the entire project.

Matt:
It was. It was. It certainly made it feel less intimidating. I think we had a team of four or five of us.

Gary:
Yeah, I'm not going to ask your grade, but I'm sure it was very, very good, otherwise we wouldn't be talking today in this context. So you talked about soft costs and hard costs, and I'd like to dive into that just a little bit and give people sort of a blueprint on the specific kinds of things that they can consider when looking at these kinds of metrics. So maybe we take the hard costs first.

Gary:
As we're talking to our clients here at Malbek, one of the most interesting metrics that they're using is turnaround time from drafting a contract all the way through to getting it out the door. In one of our organizations, that time went from two days to less than an hour through configurable processes. Similar to that, what other kinds of ROI number kinds of quantitative metrics are you seeing out there that help people justify their business case?

Matt:
Well, I think ROI is a big one. To your point around reducing negotiation time, automating the intake process, driving efficiency I think is an important one. Some of the others that come to mind are we're very much in an on-demand society right now. If you think about how most people are operating in the Netflix era, being able to quantify the number of self-service contracting opportunities that are available to eliminate the time suck, right, on attorneys and others that touch the contracting workflow so that they can focus in on what they do best and not necessarily drafting non-disclosure agreements, for instance.

Matt:
Another that comes to mind, and people don't think of it as quickly when they're considering some of the hard costs here, is net promoter score. Companies want to be easy to do business with. When they're working with their clients, when they're working with their suppliers, it's a driving force behind that. And satisfaction rankings, both from their own employees, as well as the clients and suppliers that they work with, is very important to a lot of organizations. Are there others, Gary, that you're seeing as well?

Gary:
Absolutely. I think visibility to the status, you know, where is this thing? So how can I quantify the time that it takes to look up, make the phone call, ask, "Where is this contract?" To your point, a lot of efficiencies.

Gary:
I want to go back to something that you just talked about, NPS and employee satisfaction. One of our employees just recently wrote a blog about this very topic where let's understand the happiness of our employees at work that have to use these systems. So if we're making a system that is more consumer grade, easier to adopt, easier to use, I think that's going to go a long way into making their jobs easier and making them want to come to work and not only use the application, but help their business partners.

Matt:
That's right. And it's the intuitiveness of the system I think that contributes a lot to that. Are we able to do things like create an application that allows for mobile compatibility, right? People are always on the move. Can I check the status of a contract request when I'm on the train commuting home from work? Those types of little things really add up, not only the intuitive interfaces and the dashboards and some of the more key and paramount components of a solid system, but also just the general ease of use, to your point. It goes a long way.

Gary:
I'll go to another analogy here. And I always break it down into three. And people who know me, they know I'm all about three, whether it's red, white, blue, Larry, Curly, Moe, it doesn't matter. I like three because it's easy to just remember and understand. So I look at it this way, people buy anything because of one of three reasons, and that's it. It doesn't matter whether it's a car, whether it's enterprise software, whatever it might be. It's either because they have a gain to go out and get, they have a pain that they're experiencing, or there's a fear of pain. That's kind of the tricky one. So you buy an umbrella before a trip. Well, you don't really need it right now, so it's not really giving any benefits and you don't have a pain at the moment. It's not raining in your house, right? But it's something that you buy as part of that risk aversion.

Gary:
So maybe if we can kind of just take a moment and break down some of these things, but I think it just helps people really focus on categorizing criteria to an easy to digest fashion. So let's start with a gain. Matt, what are some of the gains that you're seeing by an enterprise contract lifecycle management solution?

Matt:
Well, I think the primary gain that sticks out to me is visibility, whether that's visibility into a repository of contracts and simply understanding the volume of contracts and where they're emanating from and the exposure that those contracts present. I think just generally, the visibility is impactful, both within the contracting workflow and at the point that the contracting workflow concludes and the repository takes over, so to say.

Gary:
And they can access that from anywhere, right? I mean, that's the whole point of how we're seeing the transition of the workforce into that work from home. I mean, that's huge to not have to go to, I don't know that we're talking about filing cabinets anymore, but certainly unsecure F drives on your laptop. That's probably not where contracts ought to be and they're difficult to find anyway.

Matt:
Especially in today's day and age, when you need to get to information quickly, being able to use intuitive searching, being able to use filters, to get to a dataset without having to walk down the hall and open up a cabinet and spend most of your day searching for a contract can really cut down on some headaches.

Gary:
Matt, the second one is the pain, and the most common that we're seeing in terms of pain is the inefficiencies around contracting. And you can categorize that a lot of different ways, but can you walk us through some of the client's experience where they are looking for some application like this to help solve a pain?

Matt:
Sure. So one of the primary inefficiencies that we see most often is simply the ability to track and manage the status of a request, right? Being able to, in a very seamless and automated way through technology, to initiate a contracting request. And the inefficiency is in the handoffs through that process, right? Because of the number of people that are involved in the contracting workflow, oftentimes there's a need to communicate with different groups. There's a need to shuffle a draft of a document between different parties, both for the purposes of approval, as well as for red lines. And simply having a solution in place that helps with automating those handoffs can cut down a lot on email traffic and the inefficiencies that stem from trying to manage things outside of a central location.

Gary:
We've seen that as well, where, again, those emails would go back and forth. And while email is still a benchmark of most of our communication, today anyway, we will be able to cut down that email traffic back and forth, and even to the wrong people. So if you have something that is set up as a template or an infrastructure for where those communications have to go and when they have to go there, I think you're going to have a lot more success.

Gary:
So looking at that third risk aversion with some kind of fear of pain, some of the things that we're seeing, Matt, signing contracts with non-standard language, finding an old copy, and I haven't done this personally, of course, but finding an old copy of an NDA on your desktop and saying, "I think this is the most recent one. Let's go send this out." So can you walk through some of your experiences with some of the risk associated that might be existing today that could be mitigated by contract lifecycle management application?

Matt:
Sure. Risk aversion and standardization is a key benefit of a CLM technology. Organizations that don't use CLM are signing contracts with non-standard language, non-standard clauses, and it introduces the company to risk and ambiguity. We're working with an organization right now that is hyper-focused on being able to capture high-risk terms within their contract. So they're actually building out separate solutions to track and manage when high-risk terms are included in a contract, what that's doing for the company from a risk perspective, and then being able to quantify that as to the number of high-risk terms that are appearing in contracts throughout the organization. So it's certainly top of mind for a lot of the larger, especially financial institution clients that we're working with.

Gary:
So as I'm looking at task with this business case and I am trying to understand the risk associated with contracts, who would I go to in my company? What department would I go to? Or maybe there's multiple departments that would help me understand the risk that is there from a contract standpoint.

Matt:
Sure. So if I'm evaluating a CLM solution internally, there are a variety of resources and groups that I may want to reach out to. Depending on the size of the organization, it may be the chief financial officer, it may be delegates to the chief financial officer. You may also want to loop in compliance, right? And the chief compliance officer that oversees some of the contracting process and the information contained within standard contracting templates.

Gary:
Thanks, Matt. So this is really interesting. I think what we've given our audience hopefully is a bit of a blueprint. And I think that whenever you have a blueprint, you're ultimately going to have challenges. So if the blueprint's there, if I'm looking for hard costs to be saved, soft costs, those kinds of things, what are some of the common questions or challenges you get from clients when they're trying to build this business case after it's been started?

Matt:
So one common challenge that I see is just indecision around who is ultimately going to be funding an initiative like this. We also see quite frequently, and I think I mentioned this, just the general feeling of being overwhelmed in creating this business case, right? We're talking about a technology that's spanning the enterprise of a certain volume of templates and the number of stakeholders. There may be data migration needs. These are all factors that play into the business case that can create a challenge for the individuals that are tasked with drafting this.

Matt:
Another one that sticks out is just the prospect of passing through internal security approvals when you get to that point in time.

Matt:
Gary, earlier you were talking about different costs. Quantifying certain types of costs is very difficult. You obviously have direct costs, which are more software related, but then there's internal costs. How much is this going to cost for IT to support the application? You have the indirect costs. And this is probably the most challenging of them all. How do you quantify inefficiencies that stem from not deploying a technology like this? You have to look at it from a variety of different perspectives. People are emotionally invested in presenting a sound and justifiable business case, and they just want help. This is a technology that is near and dear to their heart. Some of the pain points we've talked about are near and dear to their heart, and they're looking for comfort and support in crafting this comprehensive plan.

Gary:
Would it be safe to say though that a good sale and business case or any software technology business case is mainly data-driven? Is that what's going to resonate the most?

Matt:
I think that's right. There's no silver bullet. It needs to tell a compelling story. It needs to consider the human element of a change like this. And it also needs to leverage industry benchmarks and make the most informed assumptions that you can make for some of the components that aren't necessarily quantitative in nature.

Gary:
Sure. I want to take a left-hand turn based on something you said about a couple minutes ago regarding data migration needs. So a lot of people have trouble separating what are the project and ROI is about the data migration, the contracts that you already have in your past, and the efficiencies that you'll gain from a go forward standpoint in terms of contracts that you'll be creating. Isn't it true that probably the first step is to look at what you have and what's most important to you and what kind of data is in there. I mean, how have you helped companies understand what they have there, because really, that's the lifeline of their business, correct?

Matt:
It is. It is. Especially if you're implementing a solution, that's going to act as the foundation for multiple groups moving forward, having disparate data locations where your contracts are stored is terribly inefficient and can lead to a lot of headaches in the way that you're managing contracts over time.

Matt:
So one of the first places that we start is by understanding your universe of contracts. Where do they live? Who touches them? What information have you captured about those contracts? And ultimately, what do you want to pick up and move into the system? Maybe some of that information can stay where it is. Maybe some of the information is housed in a different location, but aligning your current state with your future state business process is paramount in this exercise.

Gary:
So as I'm looking at this, and a lot of times I had this conversation about, again, pulling contracts in and which ones do I do, the most common advice I would give is let's make sure that you have the go forward straightened out. Make sure that you understand of the five different agreement types that you have moving forward, just make sure that you have the right metadata in there. Make sure the right clauses are in there because that can have a direct effect on what you want to bring in, that it has a home. So that way, in the future, you're able to actually have that aggregate reporting that makes sense.

Matt:
Absolutely. The searching and reporting benefits that you just alluded to are very important. You want to make sure that you're creating that comprehensive landscape to be able to query effectively, to be able to locate contract documents, to be able to generate reports on a regular basis. All of that is important. And if it's treated in silos in the way that you're looking at your data migration versus how you're going to operate moving forward, that exercise becomes incredibly cumbersome.

Gary:
Looking at the business case being approved, okay, I just got the green light. Everything is looking great. I'm about to go into that wild world of software vendors and I'm going to find out who's the best fit for me. So where do you go from there?

Matt:
Well, jumping back to the theme at the beginning, I assume you mean after popping the champagne, but- [laughs]

Gary:
Exactly. It all depends when you want to pop that champagne. Exactly.

Matt:
That's right. The natural next step is an RFP, RFI, or even a proof of concept exercise. And we've helped many organizations through this process to ensure that they're considering all different angles when evaluating the market. And not only the market and what different technologies offer and where they're strong, but also aligning things internally and conducting internal information gathering exercises so that our clients understand and clearly document the requirements that are most important to the different stakeholders that are touching this process.

Matt:
So the RFP RFI exercise is clearly important. I think another thing is stemming back to our theme of strength in numbers and working in a team, establishing a steering committee, compiling a group of leaders from these different groups to be able to help shepherd the process and weigh in with their input as different decisions are made. That will really help define what success looks like, both through the selection exercise, and then what success looks like looking ahead to go live.

Gary:
This is a journey, Matt. And I think that what we find is customers that may involve people that are outside their departments once it's been purchased, or they may involve them when they run into problems in their implementation. Some people may have involved them in very early, but do the reverse. Maybe they're not quite as involved in the implementation, and they're certainly not involved a year down the road.

Gary:
So I think the common theme behind all of this is that consistency, having everybody involved early, having everybody involved in the decision is important, but I do have a caveat. When I look at RFPs that come into me with a lot of different requirements, sometimes I see that some of the questions are duplicate, some of the questions are variations on a theme and some of them are even contradictory. So as the project sponsor, what's my main job? As I'm getting all these different wish list items from all the different areas, how do I make sure that when that RFP goes out the door, that it is... And it makes sense to the vendors so everybody knows what action they need to take so that I can make a better decision.

Matt:
The key in that is to be able to prioritize some of the requirements that are entered into an RFP. When you're going through an exercise like this to gather information from different groups, oftentimes some of these groups are experiencing different pain points and problems than other groups. And in some instances, they may even conflict with one another. I think in a lot of ways, it stems back to a comment that was made earlier around aligning this with enterprise initiatives and goals, and just ensuring that the requirements that you are setting forth through this exercise hit on the primary pain points of the users that will be touching the system, but also account for some of the conflicting nature of how businesses will operate. And oftentimes in this type of workflow, there's a little bit of finger-pointing that can happen, right?

Matt:
And sometimes when you're creating or trying to find a solution that can help these different groups in different departments, there's this kumbaya moment that needs to happen where, and again, kind of in the spirit of the healthy conversations, where you put out front and center some of the challenges that you've been experiencing and fall on the sword to some degree, and that can be a very challenging thing to do, but it's a worthwhile endeavor and it helps considerably with the requirements for the RFP.

Gary:
Sure. And to use a tired phrase, we want to keep our eye on the prize because there is a better place ahead once this hard work is finished. Obviously it never ends. It's a journey. Keep everybody close to you, keep everybody involved. Especially now when we have everything done virtually, we want to try extra hard to maintain those communications and contacts and important projects, especially in the year 2021.

Matt:
Right on.

Gary:
So, Matt, we'll keep an eye out for Stout in the future, but is there anything that's coming up that we should be aware of?

Matt:
Yeah. We have a couple of thought leadership activities going on. We have a webinar coming up around data analytics and spend management. So keep an eye out for that. Of course, legal week will be coming up here as we get into 2021, so we certainly have a presence there. And you can always feel free to reach out to us through our website, stout.com, or follow me on LinkedIn.

Gary:
Perfect. And I could from personal experience, it's an extremely professional and talented team, and the Stout team would love to have a conversation no matter where you are in this journey. So please do reach out to them.

Gary:
And Matt, I think we've talked about three different kinds of beverages on this call. We talked about beer, wine, and champagne. So here's to you. And really, thanks for joining us today. We sincerely appreciate it. Hope to see you soon.

Matt:
Thanks, Gary. Cheers.

Gary:
Cheers.