In the second part of this five-article series, we examine another common problem in tech contracting, when the solution a customer buys isn’t up to scratch. What causes this, and how can you draft to avoid it?
Solution fit for purpose
Surprises arise further down the line once any IT is designed and built. If a solution/software does not perform in the manner the customer was expecting, this could be discovered during testing or, even worse, following acceptance and payment.
Again, commonly the customer will blame the supplier for overpromising at a pre-contact stage in order to win the work, or will again allege incompetence. Conversely, the supplier will blame the customer for not properly expressing its objectives, or for failing to engage in the scoping and design phase of the project.
There are a few things to focus on when drafting here – primarily, the commercial schedules to any agreement. Typically, these will include specifications of the technical solution, which really need to emphasise the customer’s key objectives in procuring the solution and accurately describe the technical solution including any critical functionality (the more specificity, the better). Service levels also should be clearly spelled out, with appropriate remedies for any failure to meet these levels (considering, in particular, whether service credits will always suffice, or whether a threshold should be included which, if passed, escalates available remedies beyond mere financial recompense).
During delivery phase of the solution, customers should ensure that testing and acceptance of the solution are conducted thoroughly. This is particularly the case where the solution is delivered in multiple phases and there is a degree of interdependency between different aspects of the solution. The waters are sometimes muddied by premature or ill-considered acceptance of a certain part of the solution, without the customer having gone through the proper testing steps (or having waived testing until a later part of the solution also is ready and then being unable to row back on acceptance).
From a supplier perspective, the contract should make very clear the input required from the customer during the design and implementation phases of any project. Whose input you need, for what purpose and by what date are things that should be specifically called out to ensure the customer is engaged in the development process of the solution, along with making sure any misunderstandings as to functionality, capacity, etc. can be identified early.
Suppliers also should ensure that entire agreement clauses are watertight. Where a solution turns out to fall short of customer expectations, in the absence of very specific technical/commercial schedules, customers sometimes resort to misrepresentation claims. This involves an assertion that, pre-contract, the supplier overstated its capability to deliver what the customer was looking for. Entire agreement clauses exclude the possibility of relying on pre-contractual statements in this way. Fraudulent misstatements cannot be excluded, as a matter of English law, but the threshold for proving fraud is very high, and so claimants face an uphill battle if this is their only option.
Our team recently presented a webinar on Technology Contract Disputes – watch on demand here.
Contributors