A few months ago I came across a discussion on Linkedin that started with someone asking for guidance on in-house contracts administration. That started a chain of replies, most of which focused on different technologies companies were applying to their contract challenges. There was one particular comment that caught my eye. It was from someone who expressed frustration with the contracts management system her company had been trying to implement for over a year that she described as “much more complicated (and antiquated) than we were led to believe.”
This got me thinking about the issues companies face in evaluating contract management systems. It isn’t the first time I’ve heard that many companies that have invested in what I’ll call “name-brand” contract management systems have found them to be expensive, inflexible, cumbersome, and out of date. So I decided to turn that thinking into a blog series on things to consider if you want your contract management system to meet your strategic initiatives. I’ve had the opportunity to learn from dozens of successful (and unsuccessful) contract initiatives, both at Pramata and at other companies. Every company’s needs will be different, but based on my experience I can offer some things to consider as you evaluate your options.
Today I’ll begin with a general discussion on system capabilities, and over the next few weeks move on to cover additional factors to consider including:
- Data vs. Search
- Don’t Try to Take on Too Much Too Soon
- Non-Standard Contracts, Related Contracts, & Automation
- Can you build it yourself?
- The SaaS Option
- Information Access, Security & Training
Part 1: System Capabilities – Is more always better?
Adopting a contract management tool, even a “name-brand” system, is no guarantee of success in a contracts management initiative. In fact, many of Pramata’s customers had another contract management system that wasn’t working well for them. The last thing you want is for the contract management system you spent countless hours and dollars to choose and implement to become “shelfware,”, so it’s important to realistically consider your needs, your budget, your capabilities, and your culture as you embark on a contract management project. And it’s important to learn from the successes and failures of others.
One of the first things to think about is what do you want your system to do and what do you really need it to do? Any contract management system will allow you to store contracts, along with a certain amount of data about those contracts, in a repository. Most systems will provide alerts of critical events, such as renewals and expirations. Some systems allow users to create their own contracts using templates and guidelines stored in the system. The most complete (and complex) systems allow for management of a contract from request to creation, through workflow and approvals, and finally signature and storage of the contract and related data in a central repository. In theory, the more your system can do the better, but more capability can also add more complexity in system implementation, system management, and change management. There are always tradeoffs. If your system requires hours and hours of training and forces people into a rigid and unrealistic workflow it’s probably not going to work for your users. More system complexity also means your implementation timeline is going to be longer, meaning it’s going to be longer before you actually see benefits from the system.
Aaron Levie had an interesting take on this theme in a recent Techcrunch Article, in which he discussed the phenomenon of enterprise software vendors creating “feature-bloated” solutions so they can hope to check all the boxes of an ever-growing list of requirements in RFPs. Often, however, there’s a disconnect between the ultimate users of the systems and the people making the buying decisions based on these RFPs. “This has created an oddly perverse dynamic where the vendors with the most feature-rich solutions win the contracts, but the users lose due to the complexity of the technology.”
So don’t let the “bells and whistles” distract you from what’s really important to your company. The most feature-rich system is not necessarily the best choice. Sometimes simpler is better.
We’d be interested in hearing about more real-world examples. Have you dealt with this tension between feature-rich and user friendly? If so, what did you learn? Would you make a different choice if you were starting the project today?
Next Monday: “Don’t take on too much too soon”
Dave Munn is General Counsel and Contracts Intelligence Architect at Pramata. He is an experienced contracts attorney and veteran implementer of contract management software. You can reach Dave at (david dot munn at pramata dot com) or connect with him on LinkedIn.
Thoughts On Contract Management Software – Later Entries in this Series
Part II: Don’t Take On Too Much Too Soon
Part IV: Non-Standard Contracts, Related Contracts, and Automation
Part V: Can (Should) You Build it Yourself?
Part VI: The SaaS Option – Can you manage your contracts in the “cloud”?
Part VII: Access, Security & Training
Brian Smith says:
David, One comment i would add is that a bad process that is automated is just a faster version of a bad process. So whatever tool you use, should make your (hopefully good) contract building and review process more effective for your company.
David Munn says:
Brian,
That’s a good point. I would hope that any company looking at contract management systems is also looking at their processes to see if there are opportunities to improve them. But I don’t think the only problem involves automating bad processes. Even if you have great processes with your current technology (or lack thereof) it would be rare that putting a new technology in place wouldn’t also provide an opportunity to reengineer your contract processes to improve speed, efficiency, consistency, etc.
Maybe you can cut out entire steps and get high-priced resources out of the business of drafting, routing, and approving routine documents using document creation tools and rules-based approvals. That is likely to also require redesigning your contract templates to make them more efficient (maybe simpler?) and suitable for automation. Maybe it’s just a matter of replacing email-based routing and approval with a more streamlined system that can track where things are in the process and give people reminders of pending tasks. Maybe you have people coming to lawyers asking for copies of contracts and answers to routine contracts questions and you want to provide them a self-service system.
If someone goes into a project like this thinking they just want to automate their current processes they are probably not taking full advantage of what the technologies have to offer. Whatever you’re doing today, it’s likely that a contracts management system will allow you to improve on some aspects of your processes. And don’t necessarily dismiss a system because it won’t support your current processes or what you have in mind as the ideal process. The vendors have generally worked with a lot of companies and have a pretty good idea of what works and what doesn’t work. You can learn a lot by listening to what they recommend. Obviously, they all have strengths and weaknesses, and their recommendations are going to play to their strengths, so you need to carefully evaluate what they have to say, but it’s worthwhile to get the perspectives of a number of vendors because that may cause you to think differently about your situation and your processes.
David Munn