Every time a new system is implemented, a new set of contracts is signed.
Contract management system (“CMS”) implementation projects are particularly complex to manage because they usually involve high spend, multiple parties and stakeholders, several phases, tons of deliverables, overlapping timelines, critical customer dependencies, and lots of unknowns. Making CMS implementation SOWs ripe with potential business and legal risks for us contracts professionals to navigate.
The recent lawsuit against CMS giant Icertis is an eye opener for us all. At this stage, we don’t know which party is (or to what extent both may be) at fault. But the fact that a lawsuit was filed means one thing for sure – the contract could have been better.
We, as contracts professionals from both sides, should be asking ourselves this question: What can we learn from this lawsuit that will help us draft better CMS implementation agreements going forward? This article provides a high-level overview of the lawsuit and some suggestions on how to avoid common disputes.
Case Summary
Timeline:
- June 2020 – Change Healthcare Operations, LLC (“CHC”) engaged Icertis to design and implement a CMS. The parties entered into three different agreements, the: 1) the SaaS subscription and services agreement, 2) implementation SOW; and 3) admin services SOW. The main subject of the lawsuit and this article being the two SOWs.
- March 2021 – CHC provided notice that Icertis was in material breach of the contract. Icertis had 30 days to cure the alleged breach.
- April 2021 – CHC provided notice of termination based on its assertion that Icertis failed to cure the breach.
- November 2021 – CHC filed Change Healthcare Operations, LLC. v. Icertis, Inc., No. 21-2-15181-3 SEA, (Wash. Super. Ct. Nov. 2021) (the “Complaint”) [1] against Icertis for breach of contract and related causes of action based on claims that Icertis failed to implement and launch the CMS.
Allegations:
At a high-level, the Complaint alleges that Icertis breached the SOWs by:
- Representing it had the ability to apply a single contract amendment to multiple agreements simultaneously and then later telling CHC that it did not have such ability.[2]
- Not providing best practices documentation and classroom training mandated by the SOWs.[3]
- Causing delays and confusion by failing to staff the project with subject matter experts.
- Failing to perform more generally, including by providing substandard efforts regarding template harmonization, using subcontractors without CHC’s prior approval, and not requiring team members to work during CHC’s business hours.[4]
Termination is Not the Resolution
Termination is not a resolution, it is a bigger problem. Many contracts use a right of termination to protect a party against the other party’s failure to perform on an obligation. But since it can take anywhere from six months to two years (and millions of dollars) to implement a CMS, a right of termination doesn’t do much to help when there’s a dispute. Instead of termination, consider how to incentivize cooperation and disincentivize failures, and compensate the parties accordingly.
Allegation: “After Icertis failed to cure its myriad breaches [in the 30 day cure period], CHC informed Icertis that the cure period had ended, and that the entire [contract] had been terminated.” As a result, “CHC is left with nothing tangible to show for months of work and would have to repeat the entire process with a different CMS vendor if it decides to undertake such a project again.”[5]
Business Solution: Business teams should be looking to the itemized costs of various implementation milestones and deliverables, rather than the total spend. The cost of the CMS is the cost of complete success. But what is the cost of incremental failure or misses? From a CMS customer’s perspective, What is a requirement worth to your business? From a CMS provider’s perspective, What is this customer’s trust worth to you?
SOW Improvement: As contracts professionals, we should anticipate gaps in delivery and draft intra-contractual resolutions to compensate the customer for them. SaaS agreements utilize service level agreements and service credits for this exact reason. Similarly, implementation SOWs can include mechanisms to protect against anticipated failures, such as requirement gaps, tardy deliverables, and postponed launch. The greater the failure, the greater the credit/refund.
Here’s some sample language:
“If CMS provider does not timely deliver on a requirement due to a system limitation, the CMS provider shall reimburse the customer $X. If CMS provider does not deliver on a requirement marked “critical”, CMS provider will be in material breach of this agreement and the customer has the option to a) terminate the agreement for breach or b) receive a X% discount on the implementation fees.”[6]
Know the System Limitations
When it comes to system capabilities, there are three main buckets: 1) current out-of-box capabilities, 2) customizations that you pay extra for, and 3) system limitations. A system limitation is a technical limitation and refers to what the defined system is unable to do as of its present state (often reframed as a “future enhancement”). The parties tend to (excitedly) focus their discussion on what the customer wants and what the system can do. Rarely do the parties talk about system limitations during the vendor selection process.
Allegation: CHC alleged that it asked Icertis whether their CMS had the “ability to apply a single contract amendment to multiple agreements simultaneously” and that Icertis said yes. “Icertis did not communicate its inability to accomplish this goal” until after the contract was signed. Since this requirement was “critically important to CHC,” they “would not have selected Icertis absent its supposed ability to meet” this need.[7]
Business Solution: Spend more time discussing critical requirements and system limitations during the vendor selection process.[8] The reality is that no CMS will meet 100% of the customer’s needs. Sometimes, you can pay extra for a customization, and other times, the CMS provider couldn’t do it even if you threw money at them because of a system limitation. If you have consent, record demo and discovery sessions for future reference. Then capture the learnings in a requirements document that you can attach to the implementation SOW. Pro tip: Where possible, start with a proof of concept to verify that the parties are indeed a match.
SOW Improvement: Attach a requirements document to the implementation SOW that details the customer’s requirements, which ones are out-of-box vs. customizable, and related system limitations. Flag the critical requirements. Make sure that payments, failures, and milestones are tied back to the requirements list. In addition, make sure that obligations and penalties flow from missed requirements.
Expect to Do Everything Yourself
There can be over thirty people assigned to work on a single CMS implementation project. Program managers, program sponsors, sales and procurement professionals, project managers for each stakeholder, subject matter experts and technical experts, from both sides. With so many people involved and so many things to do, it can be confusing to understand who is responsible for doing what.
Allegation: CHC alleged that “Icertis failed to provide requested best practices documentation, causing CHC to perform template categorization on its own.” “[T]emplate categorization is the process by which CHC’s various document templates (for example, different varieties of master agreements) are sorted into categories based on CHC’s business needs.”[9]
Business Solution: It is important to understand what each party brings to the table and then capitalize on those strengths with the understanding that they will need to work together to build the system. The CMS provider is the subject matter expert in system implementations and industry best practices while the CMS customer is the subject matter expert on their company’s particular needs and processes. Just because a RASCI chart says that the CMS provider is responsible for producing a document, doesn’t mean that they are going to produce a document that the customer likes or agrees with. So the customer should expect to play a heavy hand in creating each document that will eventually feed into the design.[10]
SOW Improvement: Even if the CMS provider promises to provide best practices and other consulting services, there are so many different ways that the contracting process can be configured. So the customer will need to provide considerable input and ultimate approval. Define a review and acceptance process for each dependency and deliverable that takes revision cycles into account. Many times, the acceptance process applies only to the CMS provider’s deliverables and not to the underlying dependencies (such as workflows or templates). Final approvals should be documented in writing against the version of the document being approved.
* * *
Many of the allegations raised in the Icertis lawsuit rings all too familiar to those of us in the contracting or legal tech space. This could’ve happened to any one of us. Let’s learn from this and strive to avoid ever having to reach the point of litigation in our future CMS implementations. Plus, click here more key learnings from the Icerctis lawsuit from my friends at LegalEase.
[1] The analysis provided in this article is based on the allegations asserted in the Complaint. The Complaint does not attach any of the contracts that are the subject of the lawsuit so we don’t know what the contracts say.
[2] Complaint at 3, Change Healthcare Operations, LLC, v. Icertis, Inc., No. 21-2-15181-3 SEA (Wash. Super. Ct. Nov. 2021).
[3] Complaint at 4.
[4] Complaint at 7.
[5] Complaint at 9.
[6] Requirements should be tied to an attachment that lists out all of the requirements. The parties should come up with a credit fee for a missed requirement and a discount for a missed critical requirement.
[7] Complaint at 3.
[8] CMS providers, it is really important that your salespersons know the technical ins and outs of your system, enough to say what it can do, what it can be customized to do, and what it absolutely cannot do. Or at the very least, when to escalate the question to a technical expert.
[9] Complaint at 5.
[10] CMS customers, it is highly recommended that you have a dedicated, full-time program manager and that you designate a legal/contracts subject matter expert who can spend at least 50% of their time on the implementation. If your designated subject matter expert is buried underneath piles of contract reviews, it will be difficult for them to provide the necessary attention to detail needed to successfully implement a CMS.
