This blog was first published as part of the white paper companion piece to our Digital Transformation webinar on 10 September 2020.

In any given digital transformation (“DT”) project, there are numerous potential issues and pitfalls that may lead to failure – or at the very least – result in the project failing to meet the “on time, on budget and to standard” threshold. This piece focusses on 3 key issues that arise on every digital transformation project: (1) early adopter risk v. reward, (2) “toothless” functional and service standards, and (3) responsibility for/relationship with third parties and other service providers.

Early adopter risk v. reward

Very few customers want to be the first to purchase new software or deployment models – people naturally gravitate to suppliers, products and services that are tried and tested, as evidenced by success stories and positive feedback. The recent great shove online and the speed of deployment of new digital business methodologies means that it’s not always the case that another company has “been there, done that and bought the t-shirt” for DT projects. Customers are therefore, at present at least, slightly more nervous when undertaking a DT project simply because the supplier may not be able to refer to a number of successful deployments or successfully point to issues that have arisen and been quickly and efficiently addressed with minimal impact to the customer.

This lack of confidence – and potential inability to foresee problems – means that customers are likely to assume increased risk of failure in scenarios where the supplier is unlikely/unwilling to offer additional protection/legal rights to the customer.

To mitigate these risks, it’s important to ensure that:

• as amplified below, the contract includes meaningful commitments from the supplier as to what it will deliver and that delivery will be “on time, on budget and to standard”;
• as amplified below, the customer has meaningful and enforceable remedies to address failures to avoid incurring irrecoverable additional expenses and losses; and
• the enthusiasm and positivity of the supplier in relation to its newer offerings is tempered by enforceable contractual provisions that actually assist the customer should issues arise. It may be tempting to rely on the supplier’s experience and statements made during procurement and pre-contract negotiations, market position or the nature of the relationship between the parties as sufficiently persuasive for the customer to remove the need for detailed contractual terms around fixes issues and dispute resolution. The disadvantage with this approach is that any change in the relationship or the supplier’s approach means that the supplier’s word is no longer its bond and the customer may be without a remedy. For this reason, we always advise that the customer vet and assess the nature of the remedies available to it for different types of breach so that it is confident that the contract provides sufficient protection, irrespective of the quality of the parties’ relationship and the issues that may arise.

Functionality and performance commitments

It’s easy to be swayed by enthusiasm and marketing spin about the benefits and functionality of new technologies and how those technologies will deliver efficiencies and performance improvements for the customer. There’s usually a relatively large disconnect between these pre-contractual statements around functionality and performance and what the contract actually requires the supplier to deliver: it’s commonplace for customers to ask for suppliers to confirm that its product/service includes specific functionality on an item-by-item basis but for the contractual commitment for the supplier to state that the product/service will perform “in all material respects in accordance with” the supplier’s high level, generic, product/service description. This approach makes it more difficult for customers to have a clear contractual hook on which to hang allegations of breach or failure to perform. It’s therefore important that the parties address these issues during the contract negotiations and the risk can be mitigated in the following ways:

• Any requirements list that has been prepared by the customer reviewed by the supplier during the RFP should be included in the contract as a baseline expectation of functionality/performance.
• Proofs-of-concept can be used to test functionality and performance against the supplier’s standard commitments and the customer’s requirements list.
• Formal, official acceptance by the customer should ideally be based around successful completion of user acceptance testing by the customer and a period of live, production use without P1 or P2 issues.
• Remedies for failed acceptance test/breach of commitment to deliver functionality/requirements should be assessed by reference to the potential impact of a failure and any resultant delay. It’s unlikely that the supplier’s standard approach of a “fix/replace commitment” as the customer’s sole remedy will compensate the customer for any wasted costs and additional expenses it may incur because of the supplier’s failure to deliver on time and to standard. Liquidated damages, or the ability to recover operational losses and additional costs/expenses, may go some way to re-balance the risk here but it’s unlikely in our view for the customer to have carte blanche to sue for all loss/damage and/or terminate the agreement in these circumstances.

Relationships with third party providers

No DT project is completely ringfenced such that it can be implemented without interaction with, or support from, other third party service providers to the customer and/or the supplier. The transformative nature of the DT journey means that a change to one element in the IT stack  is likely to impact other layers/elements within the technology ecosystem. This cross-party dependency can easily be overlooked by a blinkered focus on one supplier or one system/service at a time and that narrow “worldview” of the impact of each individual “DT project” can result in increased complexity and additional cost and expense for all parties involved. It’s not unusual in our experience for both customers and suppliers to overlook downstream consequences on other suppliers and to fail to identify early in the implementation process when support and input from other suppliers is required. The project plan/governance methodology should therefore incorporate processes designed to:

• Identify all impacted suppliers/service providers to both customer and supplier and what support/assistance/input is required of those suppliers/service providers.
• Address who is responsible for managing the third party and the consequences of a failure to do so.
• Ensure that the supplier is responsible for the acts and omissions of its sub-contractors and service providers – be wary of force majeure clauses or other disclaimers buried within documentation which operate to remove/reduce the supplier’s liability because of a breach by/failure of its sub-contractor or service provider. This is particularly key in cloud and “as a service” deployment models where suppliers routinely seek to exclude liability for third party failures by declaring them to be force majeure.

Be SMART

Ultimately, the points we’ve discussed above are intended to assist both parties during any DT project. Fundamentally, we’re advocating a SMART approach to a DT project where each party is aware of the detail, intricacies and risks associated with the project and commits to SPECIFIC, MEASUREABLE, ACHIEVABLE, RELEVANT, and TIMELY contractual rights and obligations to successfully deliver it. Using these principles can help the parties ensure that both are acutely aware of what’s required to deliver any DT project successfully “on time, on budget and to standard” and can also reduce scope of disagreement and conflict.