Over the past couple of months I’ve shared some of the experiences gained from my own contracts management projects, some insights gained from working with our customers and prospective customers, and impressions from reading comments on various online discussion groups. I’ve tried to touch on a number of things you might want to think about as you consider options for your own contract management software selection and implementation. I think I should wrap it up with a call to action.

Since you’re reading this I assume you have some interest in contracts management systems. Because I work for a company that provides contracts management systems and services I’d like nothing better than for you to choose Pramata as your contracts management system vendor. We have a great product and customers who love us. I’m sure there are other companies in our business that can say the same thing. However, the odds are that you don’t have a contracts management system and that even if you’re thinking about one it will probably be years before you have one.

Why is that? Why is it that even though so many companies (maybe even most companies) recognize that their contracting processes aren’t optimal and that they have a hard time even finding their contracts, and they know there is something out there called “contracts management software” that might be able to help them, the usual course of action is to “stay the course” and do nothing? Companies recognize a need and know they need to do something, but instead they typically do nothing.

Why is that? Here are a few reasons:

• Too many choices. There are a lot of choices. There are too many choices. As this article points out, having too many options makes it harder to choose. That article highlights the number of choices you have when you go to a store to buy toothpaste. I’m pretty sure there are even more contracts management systems to choose from than there are types of toothpaste in the largest big-box store.*
• The best is the enemy of the good. Many people start a selection process with the goal of finding the “best” system. In this area it’s not likely to happen. There is simply no one “best” system for every situation. Even within a single company a system that works well for one purpose (e.g., procurement or sourcing) may be a poor fit for other contracts (e.g., sales contracts. As I pointed out in the first post in this series, an extensive RFP process is not likely provide the best outcome either.
• Lack of budget. In the past it wasn’t uncommon for a company to spend six or even seven figures for a contracts management system. But with the advent of Software-as-a-Service (Saas) contracts management systems it’s possible to have a robust system with little up-front investment and for many companies annual costs less than the cost of a single in-house contract manager.
• We’re creatures of habit. People don’t like change. Lawyers, in particular, seem to be resistant to changing the way they’ve always done things. Even if they aren’t efficient at least they’re familiar. And if you make things more efficient you won’t need as many of us.

I don’t think any of these is a good reason to do nothing. So if you’ve identified a need in your company but you’re being held back by any of these factors, what can you do? My primary advice is just to do something. The longer you wait to get control of your contracts the harder it’s going to be. According to a study by the Corporate Executive Board’s General Counsel Roundtable, as reported in Corporate Counsel Magazine, information will continue to grow exponentially, which “will increase the premium of how companies organize and manage their information. “ The longer you wait the harder it’s going to be to get control of this information, and the sooner you get started the sooner you should see a return on the investment.

The investment in a contracts management system can be one of the most important initiatives a company can take on. There’s tremendous value in the information that’s normally locked up in contracts and inaccessible, and having a system to not only improve efficiency and controls around the contracting process but to easily and quickly make use of that contracts intelligence is proving to provide tremendous business value. It doesn’t have to take years and hundreds of thousands of dollars. You can take that approach, but I wouldn’t recommend it. As I’ve noted in previous posts, you can start with small projects, learn from your successes and failures before you’ve spent a huge amount of money, adjust as needed, and see a return on your investment far faster and with less risk than if you start out thinking you need to solve all your problems at once.

Good luck. This is your opportunity to be a hero within your organization. Please share your experiences, both good and bad, for the benefit of others, in comments on this blog or other forums, such as Linkedin’s Contracts Intelligence group.

* It would be easier if there were a small number of market leaders that clearly dominated the market, but that’s not the case when it comes to contracts management systems. I’d be surprised if any company has a market share exceeding 5% or if the overall market penetration of dedicated  contracts management systems (not counting things like SharePoint, Excel spreadsheets, and other home-grown tools) exceeds 5%. For many years people have been talking about the inevitable consolidation in the industry, but the trend seems to be in the other direction. It seems that every month I come across another company that has the world’s leading contracts management system. So there’s no equivalent of Microsoft, IBM, or Salesforce.com in contracts management. And there’s no “Consumer Reports” of contracts management to help. Even if you look at reports from groups like Gartner or work with a consultant, they have their own biases and there’s no way any of them will have complete knowledge of all the competing options.

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.

Previous Entries in this Series

Part VII:  Access to Information & Training

Access to Information and Security. A question that always needs to be asked in selecting a contracts management system is “who should have access to which contracts in the system?” That question relates both to access and security, and it can have a huge effect on the utility and efficiency of the system.

The simplest approach is to simply lock down the system so that only a small group of authorized users has access to the contracts. In a paper world that might be analogous to locked file cabinets in a locked file room that only a few people have keys to. In any company there are certainly some sensitive contracts where access needs to be strictly limited, but applying that approach broadly to all types of contracts is probably not going to maximize the value of the system or the efficiency of contracts processes, and it certainly doesn’t fully leverage the advantages of having your contracts in electronic form.

While there are some companies that take this approach and strictly limit access to contracts to a small group within the company, such as their legal or contracts team, for most companies we work with the vast majority of their contracts are not extremely sensitive. They do want to make sure that people only have access to the information they have a legitimate need to see, but generally they want to empower their people with the business intelligence tools they need to do their jobs more effectively, and contractual information is key business intelligence for many users in such roles as sales, finance, legal, operations, and compliance.

Most companies seeking to improve their contracting processes also want to provide some degree of self-service to get their legal and contracts teams out of the business of finding copies of contracts and answering routine contract-related questions. So we find that the better practice for most companies is to provide access to contracts information to a broad range of people within, and possibly even outside, the company, subject to appropriate security controls that allow people to see only those contracts or that information they need to do their jobs.

A simple example of access limitations could be that sales people should only be able to see contracts related to their customers, sales managers should be able to see the sales contracts related to their region of responsibility, and finance and legal should be able to see all sales contracts. A good contracts management system will allow for this kind of access control based on the characteristics of the contracts and the roles of the users.

To ensure that people have access to only the contracts and information they should have access to, however, requires a security framework that is more sophisticated, and more difficult to maintain over time, than the locked file cabinets in a locked file room scenario. And the more granular the need to limit access, the greater the challenges of maintaining the security framework over time. So there’s a tradeoff that needs to be considered between security and usability. How easy or hard the system vendor makes security configuration and maintenance can mean the difference between whether you can realistically provide access to a broad group of people within the company or you need to lock it down to a small number of key people.

Note that there can also be advantages to making your contracts system available to people outside the company, such as outside counsel and auditors. Having the ability to provide that sort of access is an advantage of a SaaS system, and security and access controls will be particularly critical in that situation. So you need to think carefully about how people will access the system, how much control you need over access, and how you are going to maintain that access control over time as the business changes and people change roles and leave the company. You don’t want to create something that will be a nightmare to administer, but there’s usually a balance that can allow you to give people access to the information they need without making system administration unduly burdensome. It’s definitely something you want to understand well before you commit to any specific system.

Training. Training is absolutely critical for the success of any technology initiative, and contracts management is no exception. The more broadly you want to give access to the system, the more important it is that the system be easy to use, and you don’t want training to become an obstacle to proving that broader access.

Ask the potential vendors how much training their systems require, both for general users and administrators. We’ve heard of some systems that actually require multiple days of training just for regular users. Personally, I would run quickly from any vendor that tells you something like that. If regular users can’t learn how to use a system with an hour or two of training it’s simply too complicated and it’s almost guaranteed to fail. That’s especially true because many users are likely to use the system only occasionally, and the training is unlikely to “stick” if the system is to complex and not intuitive.

That doesn’t mean that every user only needs an hour or two of training. With any system there are typically going to be power users or administrators who really need to understand what the system can do and how to get the most out of it, and there are going to be casual users who only need to know how to use the basic features of the system. You should be thinking about those groups very differently when it comes to training. Obviously, the power users will need more training and probably ongoing training.

So you need to find out what kind of training is offered for different types of users, how much it’s going to cost, where it will be held (or whether it’s offered virtually or remotely), and how much training is required or recommended for different types of users. If a vendor provides training at additional cost you need to factor that into your financial calculations.

Hopefully whatever system you choose will be intuitive and easy to learn, so training needs will be minimal. The easier the system is to use, the greater the likelihood that you’ll have good user adoption. It seems that SaaS offerings designed to take advantage of Internet technologies tend to be newer and can often be more user friendly than some other systems.

Training is another challenge for companies that try to design their own systems. It’s not easy to create and maintain training materials and training programs internally. Typically that’s something that may happen at project roll-out, but it tends to get neglected over time. A good vendor, on the other hand, will have training materials that they continually update and improve in an effort to both reduce their support costs and improve user adoption and satisfaction.

Next week I’ll wrap up this series with some final thoughts.

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.

Previous Entries in this Series

Part VIII:  Final Thoughts

Increasingly companies are choosing to get their software as a service through what has become known as “the cloud.” Software as a service, or SaaS, means that the vendor hosts and manages the software “in the cloud” and users access it over the Internet, in most cases using only an Internet browser, and more and more through a dedicated smartphone or tablet app. Typically SaaS is sold on a subscription model and the up-front costs are greatly reduced compared to software that the company installs and runs on its own hardware. More and more contract management systems are being offered on this basis as companies are becoming comfortable with this model and are realizing the advantages of using software “in the cloud” and having the vendor manage the hardware and the software.

Author and speaker Rhonda Abrams recently wrote a piece in USA Today Money in which she strongly encourages businesses to develop a strategy to incorporate cloud applications into their businesses. In the article she also mentions a book she’s published called Bringing the Cloud Down to Earth: How to choose, launch and get the most from cloud solutions for your business. Dell is offering a free download of the e-book here. According to Abrams “cloud-based solutions are typically far more powerful, yet easier to use than on-premise software. And your costs are stable and predictable.”

The typical SaaS pricing model is a per-user, per-month fee, which gives business flexibility as their needs and work forces change over time. However, because many companies see advantages in giving a broad range of users access to their contract systems, the per-user, per-month model can sometimes become an obstacle. Companies know that many employees will only access the system occasionally and don’t want to pay monthly fees or user license fees for these kinds of users. The same issue can apply to installed software if there are per-user license fees. To overcome this, some SaaS providers have adopted a more flexible pricing model where the cost doesn’t necessarily go up if you give more users access to the system.

Some companies still are resistant to the SaaS model, but today they seem to be in the minority. Fewer companies are opting to pay the large up-front and ongoing costs to manage their contracts software internally. For companies concerned about the security of cloud applications, consider that the data centers where the servers are housed tend to have more robust security than most company IT departments can provide. Also, the flexibility and ease of implementation of SaaS applications means that they can often be up and running in days or weeks rather than the months or years that installed systems often take to implement.

Another question companies have about SaaS applications is how they are going to integrate them with other SaaS or internal systems. That is an important consideration but it’s becoming less of a concern as the SaaS providers develop increasingly sophisticated integration with other systems and “cloud brokers” are emerging to assist with integration issues. For companies that are using SalesForce.com as their CRM system the choice of a SaaS model for managing sales-related contracts should be an easy decision. While SalesForce can be used on a limited basis for contracts management, it isn’t designed a full-featured contracts management tool. However, more contract management systems are being designed to integrate with SalesForce. In fact, the SalesForce.com company itself uses a separate contracts management tool that integrates with SalesForce. Sales people typically do not want to have to learn to use a separate contract management system. They want to use the CRM system they are familiar with for as much as possible, so making it easy for them to get the contractual information and tools they need through their CRM system will go a long way toward increasing adoption of your contract management system.

In summary, cloud computing applications are here to stay and it is definitely worth considering SaaS contract management offerings. With some providers even offering free trials you have little to lose in considering Saas as an option for your contracts.

Next Week: Information Security & Training

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.

Previous Entries in this Series

Part I:  System Capabilities:  Is More Always Better?

Part II:  Don’t Take On Too Much Too Soon

Part III: Data vs. Search; The Importance of Data; The Challenge of Data; The Myth of Full-Text Search

Part IV:  Non-Standard Contracts, Related Contracts, and Automation

Part V:  Can (Should) You Build It Yourself?

Later Entries in this Series

Part VII:  Access, Security & Training

Part VIII:  Final Thoughts

 Note: This is the fifth in a series of posts on contract management software. Click here to go to the first post.

Can you (or your IT staff) build a contracts management system using only internal resources? The answer is probably “yes.” As long as you have people with some basic computer skills, building a contracts management system internally is an option. But whether you should is another question. Although I’m admittedly biased because I work for a company that provides a contracts management system, I will try to share some of the things I’ve learned over the years that may help you in a make-or-buy decision.

Your IT people may tell you they can work with you to create a system using the resources they already have. Often they are referring to Microsoft SharePoint, which is a “free” tool that comes bundled with Microsoft Exchange Server, which most companies already have. IT people love to do projects in SharePoint because it’s a ubiquitous application and SharePoint experience looks good on their resumes. However, as great a tool as SharePoint is, out of the box it isn’t a contracts management system.

Some companies use spreadsheets or generic database programs (e.g., Microsoft Excel and Access) to manage their contractual information and Outlook to manage tasks and reminders. The advantage of products like this is that many people are familiar with at least the basic functionality of these programs, so you may think you’ll be able to get by without relying on IT resources.

But saying you can build a contracts management system using programs like SharePoint or Excel is a little like saying you can build a house because you have access to a free lumberyard. Everything you’ll need is probably there, but you still need someone who knows how to put it all together to make something useful. And knowing how to build it is only part of the challenge.

Before you decide to build something internally, here are some other things to consider:

• How many people need to have access to the contracts and related information? Most companies want to provide some degree of self-service to get their legal and contracts groups out of the business of providing copies of contracts and answering basic questions about contracts. If you build a system internally, will you be able to easily share the information with the people (and only the people) who need access to the information? A spreadsheet maintained on someone’s PC and reminders maintained in a contract administrator’s Outlook system are definitely not best practices in contracts management.
• Note that “free” doesn’t mean no cost. While you may have an IT tool that you don’t have to pay extra for (e.g., MS SharePoint or Office) there are a lot of costs involved in designing and maintaining internal systems. First you’re going to have to put a project team together, which may have to involve IT, legal, sales, finance, and others. The time they spend on the project is not free. And once you build the system you have to maintain it. When something goes wrong you have to have someone who knows how to fix it. The more groups you need to involve, the more complex the system you design, and the more integration it has with other corporate systems the more important these cost factors become.
• Do you really have the internal expertise to design and maintain the system? With a commercially available contracts management system you’ll be getting the benefit of the vendor’s experience in working with many other companies and learning what works and what doesn’t work. You will also get the benefit of improvements to the system that the vendor makes over time. If you go it alone all that will fall on you or your IT people.
• Will you be able to keep up with changes in technology? When the next major thing comes along (e.g., the iPad and Android phones and tablets) will you or your IT staff be able to support the home-grown system on the new technology? It’s not a given that all commercial vendors will be able to support this technology either, but it’s probably more likely that they’ll have an incentive to do so.
• How dependent is your system on one IT person? Many internally built systems have been abandoned after the only IT person who knew how to maintain or make changes to the system left the company. The IT people who originally said they could build it and support it may lose their enthusiasm over time as it becomes more and more difficult to maintain the system and keep up with changes in the business. I was recently talking with a company that had built its own contract request and work flow system a few years ago using SharePoint and Oracle. Building that system was a major undertaking, but they are now looking at commercial alternatives because their home grown system has grown cumbersome over time and is difficult to support. This is a very common scenario.
• How much time do you have? With a commercial contract system you may be up and running in a few days or weeks. If you decide to design your own system how quickly will you be able to get benefits from it?
• If you decide to go it alone and create your own system you will still have the issue of getting your legacy contracts and related data into the system. As I’ve discussed in prior posts, this can be an important consideration if you have a high volume of documents, but you also need to consider day-to-day administration and data entry. If you have one contracts administrator charged with entering information into the system, what do you do when that person is on vacation or leaves the company? With some commercially available systems the vendor will actually load your contracts and data into the system for you, freeing your staff to concentrate on more valuable activities.

Building your own contracts management system is definitely an option, but there are so many commercially available systems out there – at all price points – that I’m not sure why anyone would want to try to design their own system today. Even large companies with huge IT staffs that are clearly capable of designing complex internal systems are deciding to go with commercially available contract systems.

Some companies have been able to successfully design and maintain their own systems, but that seems to be the exception rather than the rule. If you do some basic research into commercially available contracts management systems you’ll quickly discover that you have a wealth of options. Then the problem becomes trying to sort out those options, but that’s a subject for another post.

Next time: “The SaaS Option”

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.

Previous Entries in this Series

Part I:  System Capabilities:  Is More Always Better?

Part II:  Don’t Take On Too Much Too Soon

Part III: Data vs. Search; The Importance of Data; The Challenge of Data; The Myth of Full-Text Search

Pt. IV:  Non-Standard Contracts, Related Contracts, and Automation

Later Entries in this Series

Part VI: The SaaS Option – Can you manage your contracts in the “cloud”?

Part VII:  Access, Security & Training

Part VIII:  Final Thoughts

While on the surface, it seems that these two functions should work together with Sales bringing in the business and Administration working to optimize the deal for financial and risk purposes.  In fact, this should be an excellent combination as it is an opportunity to employ the typical good cop-bad cop routine.  The reality is that these functions are often at loggerheads with each other with Administration accusing Sales of being rogue elements intent on corporate destruction for personal gain while Administration is often ‘lovingly’ referred to as the “Sales Prevention Department” or some other equally non-productive name.   This friction then leads to longer sales cycles, lower job satisfaction and, in worst case scenarios, deals that are less than what they could be (sometimes even destructive to the company).

While the personalities of people who go into Sales and those that go into Administration couldn’t be more different, it is possible to bring these groups together.  I found that a combination of collaborative data sharing, accountability through visibility and clear communication, understanding and leveraging of roles can create this unified team.   I will discuss these different approached in more detail in Part 2 later this week as well as other attempts to solve this dilemma which may backfire and cause even more issues for the company.

In the meantime, let me know if you have any specific thoughts.

Updated December 5, 2011

I don’t think there’s any question that automation has the potential to significantly improve the contracts function at many companies. Whether we’re talking about automation of document creation (aka document assembly), automation of information extraction, automation of workflow, automation of alerts, or automation of anything else in the contract process, there are systems that will do some or all of those things. But automation tends to work best when everything is standard and everyone follows the “rules.” And, as I’ve discussed in prior posts, there are limits to what machines can do and therefore limits on what automation can do.

There are also tradeoffs to consider. Setting up automated systems can be complex, time consuming, and expensive. So companies need to be smart about where they spend their efforts in automating contract processes. This is another area where a simpler, more flexible system can have advantages over an overly complex, overly rigid approach.

The Challenge of Data in Non-Standard Contracts

Last week I wrote about the importance of using human beings to “curate” information to ensure a high degree of accuracy of complex contractual data. But what if your system allows users to create the contract within the system and track all the relevant information automatically and in a structured way so no separate data entry is required? That sounds good in practice, but in theory it often breaks down. One of the common criticisms of contract management systems is that they are great for standard contracts but don’t handle non-standard situations or complexity well. For companies that are lucky enough to be able to do most of their contracting using their own standard forms without substantial negotiation it might be practical to manage all the data in a completely automated system. In the real world, however, many contracts are either on the other party’s form or are heavily negotiated. In either case it becomes difficult for automated systems to capture data because the data is no longer structured in a way that allows it to be easily captured. Also, in these kinds of situations, or when people are under time pressure, they tend to go outside the established processes and systems anyway. Once that happens you’ve lost control of the information.

Added December 5, 2011: Contract management vendor Mumboe (formerly Finetooth) closed its doors in the last month or so. Law Technology News Article. Mumboe’s most advertised feature was its automated data extraction technology. Mumboe’s web site is no longer available, but you can still find information about it here (warning: there is an autoplay video if you click on the link). The description of the system includes:

“To compete with the handful of other vendors in this narrow space, Mumboe has now added a new feature called On-Demand Contract Intelligence, which takes advantage of the service’s semantic processing engine to deliver something the others don’t: automatic extraction of data.”

Three years ago Mumboe claimed to have nearly 5,000 customers using their free trial (I was one of the people who signed up for a free account but I never really used it. I assume I was counted among the 5,000.) but apparently didn’t have enough paying customers to keep the lights on. Aside from the claimed automatic data extraction the system seemed to have some nice features, so it’s too bad the company wasn’t able to make it.

One reason for their failure might be that even though the system featured automatic extraction of some data the user was still required to verify all the data and enter additional data manually for each contract. I doubt the system was able to extract more than very basic information automatically. So even though the system seemed to have some nice features it still suffered from the common challenge of needing to have users manually input data. That was probably a surprise to those who assumed Mumboe would relieve them of that task and probably created some disconnect between customers’ expectations and reality. How you’re going to get good quality data into your system should be one of the main considerations as you think about implementing a contracts management system.

Maybe the main lesson to be learned from the Mumboe situation is that you need to do your due diligence in selecting a contract management system vendor. A company without enough paying customers may  not be around long. Although many of the other vendors attempted to pick up the Mumboe customers I’m sure the transition to another system will still be painful for many of those customers.

Contract Creation/Document Automation

How often do you get to use your form contracts? Automating the creation of form contracts has tremendous potential to improve efficiency – until you have to use the other party’s form. Investing energy and resources in creating the greatest contract creation tool won’t pay off if you rarely get to use your contract forms. For high volume contracts (confidentiality agreements are a typical example) document automation can make a lot of sense. For lower volume contracts it may not be worth the investment. Having standard templates and a library of standard and fall-back clauses organized in a contracts “playbook” may provide a better return in some situations. That’s the first step on the road to document automation anyway, so the time spent creating standard clauses and templates and a playbook to guide negotiations is likely to pay off whether or not you are ever able to automate the document creation process.

Workflow

A typical contract workflow involves RFPs, responses to RFPs, initiation of contract requests, contract creation, internal approvals, negotiation, more approvals, more negotiations, signatures, distribution, and post-contracting administration, all made more complex by potential interactions between systems such as CRM and ERP systems. That’s a lot of pieces to try to figure out, let alone try to automate and accommodate all the variations, different kinds of contracts, non-standard requests, personnel changes, and product changes that always pop up in the process. That complexity is one of the main reasons that efforts to automate the entire contract process are fraught with pitfalls and delays. That’s not to say it can’t be done or that it isn’t a good investment in some situations, but it’s another place where you need to carefully consider your needs and balance that against what can realistically be done in a given situation.

Related Contracts and Amendments

Another challenge for automation is in handling related documents, such as contract amendments, master agreements, orders, statements of work, and change orders. At the most basic level a contracts system will simply store related documents in some kind of a flat filing system, requiring the user to figure out how all the pieces fit together, while other systems provide a graphical representation that allows a user to easily grasp how different documents relate to each other. Another question is how the changes made by amendments are reflected in the system. Does the system still require users to look at amendments to determine the current state of the contract or does it roll all the amendment information up to the parent document? There are clear efficiency gains if the contractual information can be gleaned by looking in one place rather than having to look at multiple documents. This is one area where it is almost impossible to rely on automation. Figuring out how different documents relate to each other can be very much like trying to put a puzzle together – often with some of the pieces missing. While there are certain common themes, there are so many variations in the way contracts and related documents can be structured and even named* that it is essential to have human beings analyze the documents to uncover their real meaning and piece the puzzle together properly.

All of this is not to say there isn’t a place for automation. But the reality is that it’s unrealistic to think you can address all of a company’s contracts challenges through automation alone.

Next week: Can you build it yourself? (Is SharePoint the answer?)

* A seemingly simple question on the IACCM’s Contract & Commercial Management Linkedin group asking “what is the basic difference between a contract amendment and addendum” generated 47 responses, and no definitive answer. People’s interpretation of those terms depended on what industry they were in, what culture they were coming from, and what their experiences had been. In other words, you can’t rely on the title of a document to understand what its function is. The only way to know what a document means is to understand the contents of the document and the context surrounding the document, which again is very difficult for a machine to do.

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.

Previous Entries in this Series

Part I:  System Capabilities:  Is More Always Better?

Part II:  Don’t Take On Too Much Too Soon

Part III: Data vs. Search; The Importance of Data; The Challenge of Data; The Myth of Full-Text Search

Later Entries in this Series

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

Part VIII:  Final Thoughts

How much data do you need to have about your contracts?

Some systems store only very basic “metadata” about the contracts, such as the names of the parties and effective dates and expiration dates. Obviously, limited data means limited search capabilities, but that may be fine for companies with a very small number of relatively simple contracts. At the other extreme, some systems are capable of storing hundreds of pieces of data about any given contract, with the data fields and the data structure specifically tailored to your contracts and your business. This enables robust reporting and analytics, such as a search for contracts with specific attributes (e.g., all contracts expiring or renewing in the next 90 days where we’ve sold X product or all contracts executed with customers in the EU in the last five years). This is what Pramata calls “contracts intelligence.” The problem for most companies is that this kind of rich data doesn’t exist, because the ability to get at this kind of data isn’t built into the normal contracting process. To answer even relatively simple questions about their contracts requires a time-consuming and expensive manual review process. 

The more data you have about your contracts (assuming the data is entered in a structured and consistent way), the better your ability to find and report on contracts. But you also have to consider how you’re going to get that information into the system. The more data you want to have in your system the bigger this challenge becomes. A system that relies on sales people or lawyers for entering more than very basic data is likely to suffer from incomplete and inconsistent data, which greatly reduces the usefulness of the system. And if users can’t rely on the quality of the data in the system they lose confidence in it and over time use of the system will decline as people find work-arounds to help them get the information they need.

Getting data into a system is a huge challenge for companies that have thousands of legacy contracts that are still governing current relationships. To get value out of their system they have to load at least some subset of their existing contracts into the system.

Full-Text Search.

Many people are interested in full-text search, thinking that will be the answer to enabling robust search capabilities without the need for detailed data entry or a data structure. There are a couple of major problems with the full-text search approach. First, most companies store contracts electronically as pdfs, but the pdf starts out as a paper contract and the pdf version is merely a picture of the document. In its native form the scanned document doesn’t contain any searchable text unless and until an optical character recognition (OCR) process is performed on the file. Unfortunately, OCR technology isn’t perfect. With a poor quality scanned image the OCR process is likely to produce unreliable results. In fact, we’ve seen many documents that were so poorly scanned that they were completely unreadable by the OCR technology. Even with a good quality image OCR results aren’t always reliable. Also, OCR technology is unlikely to ever be able to read and interpret hand-written changes to a contract. Again, without good data, people can’t rely on the information in the system, and the value of the system is greatly reduced.

The other major problem with relying solely on full-text searching is that the language of contracts is not standardized. There are many ways to say essentially the same thing in a contract using very different words. How do you make sure your search will pick up all the variations the contract drafter might have used for the concept you are searching for? Natural language processing is touted as a solution to this problem, and it may be able to get you part of the way there, but today it’s not perfect, and it can’t work at all if the quality of the underlying document doesn’t allow for nearly perfect OCR. Our experience is that a substantial portion of scanned pdf documents cannot be successfully OCR’d, so we are skeptical of any system that relies solely on a machine “reading” the text of scanned documents.

If you’re trying to answer a critical question such as, “what companies do we have most-favored pricing obligations to that might be breached by the deal we’re now contemplating” you need a reliable process to uncover the contracts that might contain such an obligation. Relying on full-text search could subject the company to liability if even a single contract is missed.

Added October 6, 2011: In an article in Law Technology News, Andrew Peck, a United States magistrate judge for the Southern District of New York, discusses the limitations of key-word searches in the context of discovery. Here’s what he wrote about the effectiveness of keyword searches: “How effective is keyword searching? In 1985, scholars David Blair and M.E. Maron collected 40,000 documents from a Bay Area Rapid Transit accident, and instructed experienced attorney and paralegal searchers to use keywords and other review techniques to retrieve at least 75% of the documents relevant to 51 document requests. Searchers believed they met the goals, but their average recall was just 20%. This result has been replicated in the TREC Legal Track studies over the past few years.” “The problems with keyword search are well known. Lawyers are used to doing keyword searches in “clean” databases, such as Westlaw and Lexis, which use full sentences, full words (not abbreviations), and largely the same words to describe the same concept. E-mail collections are not clean databases. People use different words to describe the same concept; even business e-mails are informal, rampant with misspellings, abbreviations, and acronyms.” Although they typically don’t contain as many misspellings as do emails, many of the same problems limit the effectiveness of keyword searches of contract text.

The Human Factor

You can’t underestimate the importance of the human brain in dealing with complex, unstructured information. Steven Rosenbaum, the author of “Curation Nation: How to Win in a World Where Consumers are Creators ” was interviewed on NPR’s “On the Media.” Here’s what he had to say about the capabilities of human beings:

Well, curation begins with this idea that Google, as remarkable as it is, is beginning to show kind of some wear and tear around the edges. And the reason for that is simply that there’s just so much out there that their methodology, which says we can find everything with a robot, starts to kind of fall down a little bit.

And what it gets replaced with in, in my world view, is this shocking idea that, in fact, the way you find things is by working with humans, as opposed to robots.

Some analysis and data entry can be done through automated processes, but we have yet to see a successful automated approach that is able to extract meaningful data, establish the relationships between various contracts, amendments, etc., and resolve the inevitable missing and ambiguous documents that are uncovered in a legacy document entry project. The only way to successfully overcome this challenge is by using people who can exercise the kind of judgment that’s needed to handle this kind of unstructured information. So another consideration in a system selection process has to be whether the vendor offers this kind of service or whether you’re going to have to find the resources needed for this task. If you do it on your own will you be able to ensure that the information going in is of high quality and consistency? The same challenges are present with your ongoing contracts. You need to think about how high quality and consistent data is going to get into the system every time you sign a new contract.

As long as we continue to have contracts on paper we are probably going to need some degree of “curation” by human beings to handle the complexities of contractual information and relationships and to ensure that the data about complex and non-standard contracts is reliable and robust enough to meet a company’s needs. That’s why Pramata’s approach has always been to rely on automation to the extent we can, but to augment that with people actually reading contracts and looking for meaning and context in addition to words. This is critical to ensuring quality data, whether that means only a few pieces of critical data or potentially hundreds of pieces of data.

Next week: Non-Standard Contracts, Related Contracts, and Automation

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 – Previous Entries in this Series

Part I:  System Capabilities:  Is More Always Better?

Part II:  Don’t Take On Too Much Too Soon

Later Entries in this Series

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

Part VIII:  Final Thoughts

How big a project can you handle? How big a project should you handle? Many companies start out thinking they want to reengineer their entire contracting function, but they quickly realize that a contracts project touches on so many aspects of the business that the project needs to extend well beyond just the group responsible for the contracts themselves. As companies start to investigate their contracting process and its greater implications for the business they often start to realize how little they really know about their current contracts and their current processes. Going through a thorough requirements-gathering process to attempt to uncover all the “unknown unknowns” in an ever-changing business may work for some companies, but in our experience it is more likely to lead to paralysis.

The other day I met someone who said her company had spent the last two years just trying to figure out what data they wanted to capture from their contracts. In the meantime they’re still managing their contracts in an antiquated, manual system. The best is the enemy of the good.

Often a better, more realistic approach is to take on a subset of the contracts process as a way to get started. This approach can achieve tangible results more quickly and it allows for an iterative approach to the project, building on what’s learned and allowing the learning to feed back into the overall design of the system. In our experience this approach allows companies to quickly get value from the system and to learn things about their own business and their own processes that cause them to change their thinking about what their true needs are. In other words, rather than trying to force a chosen solution that may or may not work for your company, you can avoid a lot of dead ends and increase your chances of success by assuming at the start that you can’t know everything and that you will learn more valuable lessons through actual implementation of a limited project than you could from trying to define all your requirements up front.

Next week: Data vs. Search; The importance of data, the challenge of data; the myth of full-text search

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 – Previous Entries in this Series

Part I:  System Capabilities:  Is More Always Better?

Later Entries in this Series

Part III:  Data vs Search 

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

Part VIII:  Final Thoughts

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 III:  Data vs Search 

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

Part VIII:  Final Thoughts