The race to improve, automate, and modernize business operations has led many companies to reexamine their foundational digital platforms to assess whether it is time (or past time) to transform these platforms to better support and keep pace with current and future business needs and leverage state-of-the-art technologies. While the possibilities of platform transformations are exciting—from disruptive functionality and analytics to enhanced user experience—they can also be daunting from a project management, timeline, and cost perspective.
Since most companies do not have the internal resources or skillsets to fully support a major platform transformation, third-party providers are often engaged to design, build, and deliver all or part of the solution. When contracting with a third party for such a major platform modernization, the procurement and legal teams are challenged to balance the business drive to more forward quickly with the need to negotiate a contract that incentivizes on-time, on-budget delivery of all components of the platform (including hosting and application environments) in compliance with business, risk, continuity, and regulatory requirements.
Though all companies and solutions are different, the contracting requirements tend to be similar. Set out below are some high-level negotiation tips to keep in mind.
1. Document Your Requirements
The internal company teams often struggle with documenting the functional and technical requirements in order for the potential third-party providers to submit meaningful fee proposals. It is important as part of the RFP process, and even more so in the actual contract document, to define what is in-scope for solutioning and pricing. The solution may need further refinement during blueprint and design, but unless the pricing is all in (regardless of scope changes), the baseline of what is in scope is key to determining what constitutes a change and potentially an adjustment to the fees.
In most implementations, the solution is based on, incorporates, or integrates with third-party software. Questions to consider include:
- Who is responsible for identifying and selecting the third-party components and dependencies? Are the costs built into the provider’s costs or to be paid by the company? What are the remedies if the usage, capacity, or entitlement assumptions are incorrect?
- Will any third-party software or services be retired? Have the impacted contracts been reviewed to assess termination rights? What are the financial and contractual implications if the implementation timeline is not achieved and the legacy contracts need to be kept in place longer than contemplated?
2. On Prem or Cloud?
With the increased interest of many companies to shift on-premises solutions to cloud-hosted solutions, we are seeing many modernization projects include the requirement that the transformed applications be “cloud native” and hosted in either the company’s cloud environment or as a SaaS-based offering. If the project includes a cloud hosting requirement, there may be additional contractual (and solution) considerations, including:
- Is the solution a dedicated, customized solution for the company that will be hosted in a third-party cloud, or is the solution a one-to-many model where the client will leverage an existing platform that is used to service many other users?
- If one-to-many, is there a dedicated instance or is it a multi-tenant offering? Is the solution managed by the client going forward or is the ongoing management part of a SaaS offering?
- If the application layer is custom (and proprietary) to the client, who is responsible for setting up and configuring the third-party hosting solution?
- How are specific security and compliance requirements cared for in the cloud environment? Do they meet the company’s InfoSec guidelines?
3. Timeline Considerations
Mapping out realistic timelines, with milestone completion dates tied to the transformation methodology and phases, is a key part of the contract for platform modernization. The parties will need to consider what flexibility there is in the timeline for reprioritization and what will happen if the milestones are not achieved as planned.
4. Performance Incentives
Most implementation contracts will include “incentives” to encourage completion of the project on time and on budget. These incentives often are the subject of considerable discussion between the parties. To the extent that they can be included as a requirement of the RFP, it may be less contentious for the company to ensure compliance by the providers. Examples of incentives include:
- Payment subject to milestone completion
- Holdback of a percentage of the fees until project completion
- Credits for failing to meet a milestone by the scheduled completion date (which may be a percentage of the overall project fees with a weighting factor)
- Service levels and service level credits (for metrics such as number of defects during testing)
- Reimbursement for incremental costs incurred for continuing to run the legacy environment
- Termination rights
5. Who Owns What and Who Can Use What
Allocation of intellectual property (IP) rights, including ownership and license rights, are critical to any implementation project where the underlying platform is foundational to a company’s operations. IP rights and the ongoing rights to use the platform (including through corporate changes such as acquisitions and divestitures) can be tricky, particularly if there is preexisting IP that the provider is bringing to the solution or there are third-party components. The parties will need to carefully consider any limitations on the company’s rights to use—and potentially commercialize—the platform.
6. How Much Does It Cost (and What Is a Change)?
We have all heard (and maybe experienced) the stories about complex transformation projects costing much more than expected. A well-structured contract can provide controls, applicable to both the company and provider, on how incremental costs are handled. Controls may include:
- Defined scope with rates to address incremental resources or functionality
- Not-to-exceed or fixed fees for the project with clear levers that, if triggered, that could result in an increase
- Reprioritization rights and rights to change timelines without a change to fees
7. Post-Production: Hypercare, Hand Off to Ops and Warranty
Most projects are not over once all or portions of the platform are placed in production. Typical phases of the delivery process (whether waterfall or agile) include:
- A hypercare or stabilization phase that requires the delivery provider to remain involved until certain exit criteria are achieved.
- A phase during which there is knowledge transfer and hand off to the ongoing operations (ops) provider. It will be important to be clear on the level of cooperation expected and outline what constitutes “hand off” and what happens if the ops provider identifies issues during knowledge transfer.
- A post-production warranty period that required the delivery provider to resolve any issues in the platform discovered during the negotiated “warranty period.”
8. Other Options – If Things Don’t Go as Planned
Implementation projects can be complex and go sideways for a number of reasons—from poor provider performance and missed deadlines to changes in a company’s internal requirements. When this happens, the company may be a good way into a project and then need to switch gears with respect to the delivery provider. If this is the case, it is important to lay out a clear transition plan for the replacement provider (which will be smoother if the IP rights referenced in item #5 above are in good order). Considerations include:
- Good documentation and clear contractual obligations will help determine responsibility for delays and unanticipated costs.
- Many companies find it helpful to do a “lessons learned” review to ensure that the legacy issues are addressed and do not recur.
The benefits of platform modernizations can be vast and transformational to business operations and experience. The role of the contract is to provide a framework to ensure that business expectations are met within the business case—and worst case, provide remedies if they are not.