In 2024, Contract Lifecycle Management (CLM) has almost taken a back seat to artificial intelligence. However, there will still be a huge number of businesses looking to implement CLM tools in order to improve efficiency and mitigate risk. Here are some things I picked up during my time implementing CLM for global corporates:
Always get a reference
Whether it is the CLM provider that implements the solution, or one of the CLM provider’s implementation partners, you should always get a reference from them to make sure that there have been no issues with the product itself after it has gone live, or with the implementation partner’s ability to implement the solution. This should ideally be done when considering vendor of choice pre-implementation.
Doing your homework usually saves time and costs
For me the timeline usually slipped at the discovery phase of the project – the point at which requirements are absorbed from the customer and translated into a business requirement document (or configuration design). Often it took some time to fully understand the contracting processes, who was involved with them and which documents were being produced as a result of those workflows. This sort of information could have probably been gathered by the customer prior to the project kick off. The result was usually that the discovery phase slips as it takes longer to discuss and the end design approved. More often than not that leads to a delayed go-live and an extended project that could have been avoided.
Don’t bite off more than you can chew
I was involved with the pricing and negotiation of a number of different projects – often running into the hundreds of thousands. When the figures are sizeable for the implementation there is often a view that the customer needs to get as much value out of the deal as possible ie implement as much as possible before go live. I’d say getting as much value for money as possible usually conflicts with the ease at which you can manage change. The more complex the implementation the more training will be required to provide users with the ability to use it.
It’s better to start simple and get an easy win that users can quickly pick up and get value from. Then after that follow up with subsequent phases that build on that original success. If you pack a lot of complexity into the first implementation then it will take longer to build, longer to test and increases the risk of scope drift.
Make sure you have your own Project Manager
As a large digital transformation project it is good practice to have a Project Manager within your organisation who is there to effectively hold the implementer to account. This person should be a person experienced in project management – and not for example, an in-house lawyer doing it part time. There are no issues about the competency of an in-house lawyer – it’s more about the capacity they are likely to have. There needs to be someone that has the capacity to both gather information internally (and be able to chase for it), continually review the implementers updates and RAG status, reach internal consensus on design issues and reach internal consensus on project timelines. Ultimately though without a devoted person you risk project delays – and in turn costs associated with that.
Don’t customise unless absolutely critical
Where possible you should avoid making product customisations a blocker to an implementation going live. There will undoubtedly be aspects of the CLM tool you’d want to customise to suit the needs of your company – however, resist the urge to do this as much as possible. The key reason for this is that there is a risk that they will create a customisation just for you. If that’s the case then after each product update you may have to go back to the vendor again to re-configure the customisation (as it probably won’t be included in the update). It can be a ticking time bomb that you won’t be aware of until the day the software update comes out..
Don’t get annoyed with consultants that say “no”
I’ve been on a number of projects – some project managers rigidly adhere to the design, while others can be more amiable and accept small improvements here and there. In the past, I’ve tended to fall into the latter category and felt that by saying ‘yes’ the customer is able to get more value out of what is being implemented. The reality is that by saying ‘yes’ to things it increases the risk of scope drift during the project – and in doing so it sometimes throws up some issues that weren’t foreseen or worse conflicts with the thinking made at the design stage. I’d say it’s sometimes better to adhere fully to the design and improvements can then be looked at holistically and implemented in a subsequent phase.
Implementations should be as quick as possible
The longer the implementation the more chance of scope drift. This usually happens where the scope changes based on customer requirements. I’ve seen before where the implementation partner has implemented a CLM tool with a specific CRM integration that had a lot of customisations around it. The customer then came back during the project to say they were sunsetting the use of that CRM in favour of another one. Things like that just add significantly more time and cost to projects from additional configuration work and testing.
Keeping implementations short and having subsequent phases to iterate and improve them is the way to go. This mitigates some of the impact of IT curve balls like the one above and the risk of changing customer needs (e.g. due to internal re-organisations or fundamental shifts in contracting workflows). On the whole though a quick implementation usually means a quicker time to value.
Don’t forget about support!
Usually during negotiations for CLM implementations the conversation is naturally around the value that will be delivered once all the requirements are fulfilled and the configuration goes live. However, really that is just the beginning of the journey as that’s when users will get into the system and start using it. At the point of go live users will start trickling into the system but it won’t be until probably 4 weeks later when there is much more usage that bugs appear that maybe didn’t come up during user acceptance testing. By that point hypercare from the implementation partner might be over and you’ll be on your own to fix them.
So I’d make sure that you get a decent hypercare period from whoever implements it for you. On top of that, and depending on complexity of the configuration, I’d also look at getting a stronger support package from the vendor also. Issues with CLM tools can sometimes have a significant business impact so you’re mitigating a bit of risk here by getting more support at the point of need.
Don’t forget about knowledge transfer!
CLM implementations are usually quite complex which multiple facets that will require maintenance after it goes live e.g. amendments to workflows/approvals, amendments to templates, etc. These are things that can be done by an administrative user within your business e.g. a legal operations manager. However, in order for them to do that they’ll need to have an effective knowledge transfer from those implementing it to those maintaining it. So while you’re negotiating you may want to factor in a certain number of hours of training and/or complete guides to how it has been implemented. Some organisations even request videos. The bare minimum should be recorded calls of the implementer going through the full configuration with you – so you have it for reference at a later date.
If the knowledge transfer isn’t effective then there is a greater risk that something could go wrong when its maintained later. Consultants are only on the line for a certain amount of time for questions and after that you’re either on your own or reliant on support. The ideal is to have someone internal already in place that understands the CLM tool (e.g. has implemented it or maintained it elsewhere previously) so they can ask the implementer more probing questions to get a greater understanding of the configuration. They can more effectively hold the implementer to account – which in itself mitigates risk by avoiding shortcuts or issues that are likely to impact maintenance later.
Conclusion
I hope these nine points above were useful. They cover some observations and lessons learnt from my time implementing CLM. Let me know if there are others that should be added to the list and I’ll tack them on the end so it’s a comprehensive lessons learnt resource. For those embarking on their CLM journey good luck!
Marc May
Founder, The Legal Technologist
Photo by Pixabay
Not yet a member? Become part of the Legal Ops Career community here.
Add a Comment