Implementing new software can often feel like a daunting task, especially when it's touted as the solution to all your problems. But what happens when the software doesn't fit your needs, and you're left trying to make it work? Let's dive into a real-world example of this and uncover the truths behind successful software implementation.

Introduction

Last year, we were brought in to assist a client who was in the midst of a procurement transformation. Specifically, they needed help designing a contract management process for the Contract Lifecycle Management (CLM) software they were implementing.

When we spoke to the executives, they all agreed that one of the biggest gaps in their procurement process was the lack of a robust contract management system. At least that's what their consultants had told them—the same consultants who had advised them to purchase a well-known, expensive CLM software solution. Which begged the question... why did they need us? 

The Misguided Approach

You'd think an army of experienced business consultants and software developers could develop a contract management process that incorporates and optimizes the functionality of a robust CLM solution. But there was the rub. The consultants weren't developing a process to suit the needs of the client, and then implementing a technology solution to work within the process. Instead, they were installing software and then asking everyone to change the way they do things in order for the software to work properly.

Debunking the Lies

Tasked with the responsibility of designing a new contract management process from scratch, we had to begin by debunking the terrible lies the client was being told.

Lie #1: You Don't Have a Process

Any organization that has contracts has a contract management process. It may not be an officially documented process, but it does exist. Rather than painfully building something from scratch, take what you have and tweak it to eliminate the gaps. Fair warning, this approach won't be received well by software providers or the consultants who sell for them.

Lie #2: Technology Will Solve Your Problems

Technology is a double-edged sword, and the cutting edge can also cut you. Unfortunately, contract management often gets lumped in with spend, resource, and asset management. But contract management isn't binary like the other three. Contract language is complex and loaded with subtleties that can't be quantified in a backend database.

Lie #3: You Need to Automate

Automation is not a bad thing, but some things can't be automated. One of the current challenges in our industry is the low adoption rate of contract automation, specifically contract creation and negotiation. Negotiators and lawyers rarely accept the other side’s standard terms in a contract, and there's always some back and forth with redlined drafts. Trying to automate this process with an over-engineered software solution is costly and inefficient.

Why You Should Put Process Before Technology

Once those lies were out of the way, we took a look at their current process for contract management. This particular client was a financial services provider and used in-house counsel for both buy and sell side contracts. On the buy side, they always pushed their standard terms to the suppliers and on the sell side, their customers often pushed terms onto them. 

There were always some contract negotiations with both their customers and suppliers, and they had a fairly consistent review and signature process. Fully executed versions of contracts were all stored on a shared network drive, and renewals were managed in Microsoft Excel.

The Real Needs

In the final analysis, contract management was not one of the biggest gaps in their procurement process. In fact, all this client really needed was a process to ensure contracts were being counter-signed, some security around their storage, and a simple alert tool to give them a heads up when something was going to renew or expire.

Unfortunately, what they had bought was far more complex and required extensive configuration and training to meet their fairly simple needs. Instead, we tweaked their process to incorporate a basic, cloud-based version of the software they had bought (at a much lower cost) which they could start using right away and, much to the chagrin of the consultants, convinced them to cancel the customization/integration work.

Conclusion

Needless to say, we weren't invited to the consulting firm's Christmas party that year. But our client was able to get up and running with a contract management solution that met their needs, fit into their process, and didn't break the bank.

The key takeaway here is that before implementing any new software, especially an expensive one, it's crucial to understand your existing processes and needs. Tailor the software to fit your process, not the other way around. This approach not only saves money but also ensures that the solution is efficient and effective for your organization.