So, what is an IT system integration? Put simply, it’s a project to connect different IT systems, applications, and devices to work together as a cohesive unit. This typically improves efficiency, productivity, and often functionality, ensuring seamless communication and data exchange between various IT applications or other components. Examples include:

• Omnichannel integration to ensure seamless shopping experiences across online and offline channels.
• Order management, inventory and point of sale integration.
• CRM and e-commerce integration.
• Integration of AI-driven analytics to gain insights from customers and optimise price strategies;
• ERP and software integration to streamline invoicing, payroll, and financial reporting.
• Integration of sustainable tech to support green finance initiatives, using AI and blockchain to track and verify sustainable investments and reduce carbon footprints.
• Integration of cybersecurity tools, including AI-driven threat detection and response systems, to protect sensitive data.

System integration projects involve various services. A customer might engage a supplier to provide professional services at the outset to work with it, through a discovery exercise, to identify its business needs. A customer may then engage one or more suppliers, depending on complexity, to provide configuration, customisation and/or other integration services, and to join-up the underlying technologies. 

There are two main ways that multi-supplier project services can be managed contractually. One is a prime contracting (or turnkey) approach, where the customer engages a single supplier to take primary responsibility for the project. That supplier separately sub-contracts performance of the relevant services to other suppliers. The “head supplier” may perform certain services itself, or its role may be limited to management and co-ordination. This structure means the customer has a single ‘throat to choke’ if issues arise. 

Another way is multi-sourcing (or direct contracting), whereby the customer contracts directly with each supplier, which allows the customer more visibility and control (including in relation to cost and enforcement). This approach a) requires more co-ordination and effort by the customer e.g. to ensure no gaps in responsibility exist (especially between suppliers), b) can result in the customer assuming more contractual responsibility, and (c) means the customer needs more resource to ‘police’ the suppliers’ respective responsibilities. 

We focus below on issues commonly arising with multi-sourcing systems integration projects, which have been the trend over recent years, although many of these are relevant more generally. 

1. Who is doing what?!

The customer needs to ensure there is no gap (or overlap) in roles and responsibilities. The optimal way to achieve this is to schedule to each supplier contract an overall project table outlining each party’s tasks, responsibilities and roles, including those of the customer. This is often referred to as a “RACI” (which identifies whether a party is Responsible for a task, ultimately Accountable for a task, merely needs to be Informed or also needs to be Consulted). Sometimes, the RACI or similar document forms part of a multi-party Cooperation Agreement, which also imposes general duties of cooperation and information-sharing between suppliers and the customer. Creating an agreed table for inclusion in supplier contracts is not always straightforward due to the iterative nature of discovery, and of defining business and functional requirements. However, this is an important task, and can be achieved with the correct contractual structure, sequencing and obligations.     

2. What happens if the customer or other suppliers cause delay? 

Most well-advised suppliers will wish to include in the contract a ‘customer dependencies’ schedule. This is typically kept separate from the RACI. To the extent that a supplier is unable to perform its services due to the customer’s (or another supplier’s) failure to meet the customer dependencies, the supplier will expect relief from liability (both time and cost). From a customer’s perspective, these dependencies should be as specific as possible. They should also be structured only as relief events, rather than as obligations on the customer (so that failure to meet a customer dependency won’t constitute a breach of contract and therefore risk damages claims made against the customer).

If one supplier causes delay, there’s a real risk that one or more other suppliers will have its team ‘on the bench’ and want to charge for their time. There can be a domino effect to a delay, which can be costly for a customer if not anticipated in the contract.  So, it’s important to include express risk-allocation mechanisms to ensure that the customer can recover from the defaulting supplier some or all of the additional costs that it will need pay to other (innocent) project suppliers. Now, there’s a limit to what the defaulting supplier will be prepared to pay, so the customer will also need to manage its own exposure to each of the suppliers. This needs careful thought, both in respect of the Charges, and liability/indemnity provisions, including any liquidated damages provisions. Otherwise, the customer risks suffering a potentially large cost-gap exposure.  

3. Project Timetabling 

Timetabling any systems integration project is not easy, especially if it involves multiple suppliers. What can be done? 

• Ensure that phased timetables, and an overall project timetable, are scheduled to the contracts.
• Ensure the timetables are realistic and build in slack / a buffer – things will go wrong. 
• Include comprehensive, active and collaborative governance provisions. 
• Divide the project into phases, with later phases starting only when earlier phases have been successfully completed, and perhaps with each phase constituting a different SoW (which can help avoid thorny issues around ‘termination for cause’ of one, longer contract).
• Introduce remedial obligations on the supplier, including remediation plans and allocation of additional resources, and introduce specific remedies for failure to reach key deadlines/milestones, such as liquidated damages (or ultimately specific termination rights). 

4. How do I structure charges? 

Structuring charges and payment flows is critical. Some projects may include a fixed fee element but most inevitably include a material degree of T&M costs, mainly due to the uncertain and iterative nature of projects, which naturally evolve as customers and suppliers identify what is needed and what can be provided. We often see cost overrun or disputes because suppliers don’t have enough ‘skin in the game’ or aren’t offered enough ‘upside’ if they perform well. We can help structure arrangements to ensure that there is some degree of risk-sharing but also so that a win-win can be achieved for all involved.  

5. Acceptance testing and remedies

Robust accepting testing procedures are often overlooked. Testing should take place with respect to specific software components as part of project delivery.  In addition, final testing should take place with respect to the new solution/system in its entirety. This naturally feeds into the charges and payment discussion. The contract should be clear on the supplier’s obligations (and the customer’s remedies) where acceptance testing is unsuccessful or late.  

A common formula is that the customer has the option to: (i) require that the software/system is rectified and re-tested; (ii) accept the system with fault for a reduced price (not ideal!); (iii) engage a third party to step in and remedy the faults at the supplier’s cost; or (iv) terminate the contract and be reimbursed.  This last remedy (which is worst case scenario) needs careful drafting alongside the liability clause.

Systems integration projects are complex, and no CTO/CIO will ever guarantee that they will achieve all business requirements and be delivered on time and on budget. But, with the right due diligence (including asking the right questions, both internally and with suppliers), choice of vendors, contractual structure and contractual mechanisms, most risks can be managed to an acceptable level, and we’re here to help you with that process.