To start, let me apologize for going quiet on Substack for a couple of weeks. We had a new baby girl arrive in the Clark household, and it’s been 100% baby bubble mode over here since then.
Now let’s jump back into things on the topic of CLM implementations. I know this is a heavy lift, so thanks in advance for putting some thought into it.
We’d like you to describe your ideal CLM implementation process. Either one you were involved with in the past, or your ideal map for a CLM implementation in the future. Our impression is that CLM implementations are different from other software implementations, and that they fail more often. We’d like to understand why, and what an ideal design might look like for an implementation.
Your feedback might include:
What did you need to do in preparation to implement (template creation, establish approvals, other)?
Which elements or workflows did you implement first?
Which elements of the implementation were 100% on legal’s shoulders v elements that were shared with your vendor, or other parts of the business?
Which software integrations did you start with?
Was there a project manager on your team who led the implementation for the business?
What was the hardest part about implementation?
What in your opinion is unique about the CLM implementation v other software implementations?
Did you hire a consultant to support the implementation?
What else can you tell us about your CLM implementation (or your ideal implementation)?
Preparation: Make sure contract templates are drafted/refreshed/standardized; have contract review policy to know what requires legal review and what doesn't; document approval policy (spend thresholds, types of contracts, any additional approvals needed and when, such as Security, Privacy, HR, Finance, etc.); determine metadata to capture/track; plan to integrate with existing systems/processes. Create playbooks with standard language, fallbacks, etc.
Workflows: We implemented the NDA first, which gave us a chance to get familiar with the process and fix any issues that arose before implementing a more complex workflow. Next we did the MSA. We started with simpler/higher volume contract types, as we learned along the way.
Implementation: The vendor assisted with creating the first 3 workflows -- we did them together via live calls. All additional workflow creations were on legal's shoulders, but the vendor was very accessible to answer questions and help with issues.
Software Integrations: We did not integrate with existing software at my former company. At my current company, we will want to integrate with Coupa at a minimum.
Once we got to the implementation, project management duties fell to me. We would have benefitted from having an actual PM helping, as implementation often took a backseat to my normal job duties. Because of this, our implementation was slower than it needed to be and we didn't take advantage of all of the functionality of the tool (too much effort required, not enough time/help).
Things that took a lot of time during implementation included having to document our specific process, flows, fields, metadata, etc., and training legal users, approvers on other teams, and business users. As we continued to iterate on our workflows, that meant constant updates to the documentation and communication of changes to stakeholders.
If budget allowed, I would 100% hire a consultant next time to support the preparation and implementation.
Thanks @mindy - this is very helpful. A few quick follow-ups.
1. The "Three workflows" was this a limit set by the vendor? was there an option to engage them for more? did they refer any consultants or was that left for you to figure out?
2. What resources did the vendor provide, other than someone for meetings/calls for implementations help
3. Integrations - Other than coupa, is there no need for other integrations? or is it something else driving that position (e.g. budget or expertise). Did you experience integration with Salesforce? any insights to share there?
1. I believe we paid/contracted to have assistance with 3 workflows, but I'm not certain. Once we started designing the workflows, there was no discussion of having them help in a similar capacity for additional workflows (and by that point, I understood the basic process and only had a few specific questions/issues that I asked on an ad hoc basis). The person that worked closely with me on the development of the first three workflows was readily available for questions/calls, as was the account manager. I didn't feel like I was left to flounder on my own.
2. The vendor had online documentation and training videos available on their website, and helpdesk. I would have appreciated having more guidance on best practices, however, as I felt like I was left making a lot of decisions in a vacuum.
3. Coupa would be our highest priority for integration. We currently have a separate repository solution that might also need to be integrated, but my hope is that we'll instead replace the existing repository with whatever CLM we go with. There's not a big push right now to also move the sales contracts into the CLM, but I can see that happening in the future. If/when that happens, Salesforce integration would be needed. In my prior company, my team was only supporting procurement contracts so we didn't integrate with Salesforce. The sales-side of the company actually used a different CLM (I don't remember which one) and I assume they integrated with Salesforce.
I learned recently that in order to integrate with Coupa, Ironclad requires all Coupa users to also have Ironclad licenses. That would be an issue for us. That said, their integration with Coupa looks pretty slick (they just recently showed it at their live event a week or two ago).
- I was part of, directly and indirectly, 5 CLM implementations. I'd say 4 of the 5 failed. A certain CLM vendor was sued by 2 separate companies I worked for, and another paid back $500K largely for overpromising functionality that wasn't ready yet.
- Preparation really is the key, mainly as you put it having templates firmly established as well as the approval governance. I'd say most companies think they're more advanced in this area then they really are, and often the problem is the process is informal, i.e. "legal decides on appropriate risk" and this can't be systematically work-flowed because its subjective/ad hoc.
- IMO, the other big problem emerges when a 3rd party System Integrator helps configure the CLM software, so now 3 parties are involved. Even if that SI is good generally, e.g. "Deloitte/Accenture, etc.", it doesn't make up for that party can't overwrite the complexity of the licensee not being prepared and weren't in meetings with the CLM vendors to keep them honest on what was promised. So a lot of 3 party finger-pointing happens in the end.
- Another large friction point: Configuration vs. Conformance.. Some customers (especially larger F500) want the system to be configured/customized entirely to fit their processes. At that point the software breaks. The opposite side of coin is licensees accepting that the software's workflows represent efficient "best practices" baked in, which larger software vendors try to convince customers as a means to not configure it to seller processes. This is always in tension. It boils down to communication and expectation setting at the point of sales and then in configuration as the the balance of configuration vs. conformance.
- Customer Profiling. CLMs systems that operate as a point solution will fare better in configuration vs. CLMs that need to integrate with numerous other systems.
- CLM implementations are different because of how many departments are involved. So many departments are involved in the contracting process, vs. other softwares that often are intra-department.
- CLM implementations that appoint the legal department as implementation lead have a very low rate of success. Legal departments have a hard time overseeing operational initiatives, although those that have a Legal OPS function are better equipped and ideally that function is the lead project manager.
- In a perfect world the Software provider would have an implementation team to avoid using a 3rd party SI.
- Not all SIs are made equal, but those with a speciality/partnership for the Software being configured is ideal
- SIs with a proven approach to managing milestones and ESPECIALLY organizing the division of work between them and the licensee, in particular the pre-work, have highest chance of success
- CLMs require a lot of post-implementation maintenance. Any change to approval governance or to contract template language or clause library means workflow/database/permission updates. Having a designated licensee "owner" often falls to the legal department, who tend to not be good at system maintenance. Again, a legal ops function responsible for this is ideal.
-a big issues for us was sorting our historical contracts and organizing them in a way that allowed us to import them. We also had to spend a lot of time defining the attributes we wanted to tag when storing the documents.
-The main element we implemented first was building the repository and structure for how the documents would be stored and then integrating our eSign solution with our CLM.
-it was on us to organize and sort our documents to get them ready to load into the system.
-main integration was with eSign but then also looked at our financial and procurement tools and key additional integrations.
-I put our paralegal who also does our legal ops in charge of the project with weekly check-ins with our vendor.
-Hardest part was preparing the historical contracts. We had to go through and do a lot of renaming of documents and attribute defining for our tagging to get them ready to load into the CLM.
-Hard to say on what is unique because I've only done a few software implementations myself. I feel like though that CLM projects have a lot of historical baggage attached to them that a company has to work through. Not in the CLM themselves but in the fact that every company has contracts but unless they've previously had a CLM those contracts are all over the place and with different departments and not standardized such that you really have to confront that baggaged to get the CLM up and running.
- Yes we did. Our CLM had a preferred implementation consultant that we worked with.
Congrats, Preston, to you and the family!
Preparation: Make sure contract templates are drafted/refreshed/standardized; have contract review policy to know what requires legal review and what doesn't; document approval policy (spend thresholds, types of contracts, any additional approvals needed and when, such as Security, Privacy, HR, Finance, etc.); determine metadata to capture/track; plan to integrate with existing systems/processes. Create playbooks with standard language, fallbacks, etc.
Workflows: We implemented the NDA first, which gave us a chance to get familiar with the process and fix any issues that arose before implementing a more complex workflow. Next we did the MSA. We started with simpler/higher volume contract types, as we learned along the way.
Implementation: The vendor assisted with creating the first 3 workflows -- we did them together via live calls. All additional workflow creations were on legal's shoulders, but the vendor was very accessible to answer questions and help with issues.
Software Integrations: We did not integrate with existing software at my former company. At my current company, we will want to integrate with Coupa at a minimum.
Once we got to the implementation, project management duties fell to me. We would have benefitted from having an actual PM helping, as implementation often took a backseat to my normal job duties. Because of this, our implementation was slower than it needed to be and we didn't take advantage of all of the functionality of the tool (too much effort required, not enough time/help).
Things that took a lot of time during implementation included having to document our specific process, flows, fields, metadata, etc., and training legal users, approvers on other teams, and business users. As we continued to iterate on our workflows, that meant constant updates to the documentation and communication of changes to stakeholders.
If budget allowed, I would 100% hire a consultant next time to support the preparation and implementation.
Thanks @mindy - this is very helpful. A few quick follow-ups.
1. The "Three workflows" was this a limit set by the vendor? was there an option to engage them for more? did they refer any consultants or was that left for you to figure out?
2. What resources did the vendor provide, other than someone for meetings/calls for implementations help
3. Integrations - Other than coupa, is there no need for other integrations? or is it something else driving that position (e.g. budget or expertise). Did you experience integration with Salesforce? any insights to share there?
Hi Ali.
1. I believe we paid/contracted to have assistance with 3 workflows, but I'm not certain. Once we started designing the workflows, there was no discussion of having them help in a similar capacity for additional workflows (and by that point, I understood the basic process and only had a few specific questions/issues that I asked on an ad hoc basis). The person that worked closely with me on the development of the first three workflows was readily available for questions/calls, as was the account manager. I didn't feel like I was left to flounder on my own.
2. The vendor had online documentation and training videos available on their website, and helpdesk. I would have appreciated having more guidance on best practices, however, as I felt like I was left making a lot of decisions in a vacuum.
3. Coupa would be our highest priority for integration. We currently have a separate repository solution that might also need to be integrated, but my hope is that we'll instead replace the existing repository with whatever CLM we go with. There's not a big push right now to also move the sales contracts into the CLM, but I can see that happening in the future. If/when that happens, Salesforce integration would be needed. In my prior company, my team was only supporting procurement contracts so we didn't integrate with Salesforce. The sales-side of the company actually used a different CLM (I don't remember which one) and I assume they integrated with Salesforce.
I learned recently that in order to integrate with Coupa, Ironclad requires all Coupa users to also have Ironclad licenses. That would be an issue for us. That said, their integration with Coupa looks pretty slick (they just recently showed it at their live event a week or two ago).
Wonderfully in-depth feedback as always, Mindy! Thank you!
I'm late again, but @Preston CONGRATS!
- I was part of, directly and indirectly, 5 CLM implementations. I'd say 4 of the 5 failed. A certain CLM vendor was sued by 2 separate companies I worked for, and another paid back $500K largely for overpromising functionality that wasn't ready yet.
- Preparation really is the key, mainly as you put it having templates firmly established as well as the approval governance. I'd say most companies think they're more advanced in this area then they really are, and often the problem is the process is informal, i.e. "legal decides on appropriate risk" and this can't be systematically work-flowed because its subjective/ad hoc.
- IMO, the other big problem emerges when a 3rd party System Integrator helps configure the CLM software, so now 3 parties are involved. Even if that SI is good generally, e.g. "Deloitte/Accenture, etc.", it doesn't make up for that party can't overwrite the complexity of the licensee not being prepared and weren't in meetings with the CLM vendors to keep them honest on what was promised. So a lot of 3 party finger-pointing happens in the end.
- Another large friction point: Configuration vs. Conformance.. Some customers (especially larger F500) want the system to be configured/customized entirely to fit their processes. At that point the software breaks. The opposite side of coin is licensees accepting that the software's workflows represent efficient "best practices" baked in, which larger software vendors try to convince customers as a means to not configure it to seller processes. This is always in tension. It boils down to communication and expectation setting at the point of sales and then in configuration as the the balance of configuration vs. conformance.
- Customer Profiling. CLMs systems that operate as a point solution will fare better in configuration vs. CLMs that need to integrate with numerous other systems.
- CLM implementations are different because of how many departments are involved. So many departments are involved in the contracting process, vs. other softwares that often are intra-department.
- CLM implementations that appoint the legal department as implementation lead have a very low rate of success. Legal departments have a hard time overseeing operational initiatives, although those that have a Legal OPS function are better equipped and ideally that function is the lead project manager.
- In a perfect world the Software provider would have an implementation team to avoid using a 3rd party SI.
- Not all SIs are made equal, but those with a speciality/partnership for the Software being configured is ideal
- SIs with a proven approach to managing milestones and ESPECIALLY organizing the division of work between them and the licensee, in particular the pre-work, have highest chance of success
- CLMs require a lot of post-implementation maintenance. Any change to approval governance or to contract template language or clause library means workflow/database/permission updates. Having a designated licensee "owner" often falls to the legal department, who tend to not be good at system maintenance. Again, a legal ops function responsible for this is ideal.
In order of your bullet points:
-a big issues for us was sorting our historical contracts and organizing them in a way that allowed us to import them. We also had to spend a lot of time defining the attributes we wanted to tag when storing the documents.
-The main element we implemented first was building the repository and structure for how the documents would be stored and then integrating our eSign solution with our CLM.
-it was on us to organize and sort our documents to get them ready to load into the system.
-main integration was with eSign but then also looked at our financial and procurement tools and key additional integrations.
-I put our paralegal who also does our legal ops in charge of the project with weekly check-ins with our vendor.
-Hardest part was preparing the historical contracts. We had to go through and do a lot of renaming of documents and attribute defining for our tagging to get them ready to load into the CLM.
-Hard to say on what is unique because I've only done a few software implementations myself. I feel like though that CLM projects have a lot of historical baggage attached to them that a company has to work through. Not in the CLM themselves but in the fact that every company has contracts but unless they've previously had a CLM those contracts are all over the place and with different departments and not standardized such that you really have to confront that baggaged to get the CLM up and running.
- Yes we did. Our CLM had a preferred implementation consultant that we worked with.