A Fail Grade: What Organisations Can Learn from the 2020 Leaving Certificate

The announcement by the Minister for Education, Norma Foley, last week that errors in the code used to build software to calculate Leaving Certificate grades has caused a miscalculation of the grades given to over 6,000 students will have been disappointing for the government, third level institutions and students and their families alike. Polymetrika International Inc. had been engaged by the State to provide two months’ worth of statistical and other services in the event that the examinations were cancelled. It was later engaged again, on a daily rate, to write code for the calculated grades system. Amounts paid to the company are said to total €163,000.

It became clear that Polymetrika were engaged without a “normal, full procurement process” having taken place due, according to the government, to the time constraints involved. Questions are now being asked also about what diligence, if indeed any, was done on Polymetrika prior to engaging it for the services and what, if any, recourse the State has, including whether any or all of the sums paid to the company can be recouped.

Software Agreements: Protecting Yourself

This is a useful and timely reminder of the importance of due diligence, oversight and accountability in an organisation’s relationships with service providers, in particular in the IT field and even more particularly when it comes to development projects. It has brought into keen focus not only the need to ensure that there are proper contractual protections, including remedies, available to the customer by way of a carefully drafted agreement designed to address the specific requirements of the customer and to cater for the desired (and not desired) outcomes in practice, but also the necessity of thorough due diligence checks pre-contract in order to deliver the protections sought by the provisions of the finalised contract.

Below, we have highlighted some of the key elements of a software development agreement, including how to provide (contractually) for when things do not go to plan. We also discuss the preliminary practical steps you and your IT department should take when engaging a software provider or developer, which will both feed into ensuring suitable contractual protection whilst also helping to prevent issues arising in the first place.

Issues and Remedies in Software Development Agreements

Your Requirements

The agreement must meet the needs of you, the customer. The agreement must adequately describe the software solution required; generally, with functional specifications and technical specifications – seek specialist IT advice in order to achieve this. From the customer’s perspective, functional specifications should take priority.

Exclusion and limitation of liability

This is a key element of any contract, not just in the IT space. As a procurer of IT services, you can expect to see certain liability limitations in IT agreements generally, including exclusion of implied and express terms, a statement that software is provided “as is” and exclusion of consequential, indirect or incidental loss or certain types of loss.

The key point to remember, when it comes to software development agreements, is that the product and/or service in question is bespoke – it is being built and provided to your functional (and often technical) specifications. What may be appropriate in terms of liability limitation for an ‘off-the-shelf’ piece of software may be wholly inappropriate when the software is being specifically created for you. Always ensure that your legal advisors review this element of any development agreement.

Delivery

There should be a comprehensive project plan included in the agreement. Key provisions in relation to delivery focus on when the product is deemed to be provided/accepted and the remedies available for a failure to deliver. Development agreements will include an acceptance testing procedure and performance criteria. Make sure that these tests and criteria are both suitable and of a high enough standard, and provide for what you, as customer, want to happen if those tests are failed.

Copyright

The default position should be assignment of the copyright to the customer, otherwise the software developer will hold the IP. In the event of a licence, it should at a minimum be exclusive so that competitors are prevented from benefiting from the customer’s investment. Where available, the customer should also seek the source code so that they can be independent of the supplier for support and maintenance.

Fees

The customer should seek to pay in instalments, given that every software development contract will carry some degree of risk. The customer should also seek for the largest instalment to be payable on final delivery.

Performance warranty

The customer should seek a warranty that the supplier will provide services to a particular standard with reasonable skill and care. More specific warranties may also be sought, for example to guarantee that the incoming software will dovetail with the customer’s current systems.

Agile delivery

If the customer doesn’t have a clearly defined solution at the outset, a form of ‘agile delivery’ can facilitate this, where delivery occurs in phases. The agreement will detail only overall project scope and goals, without detailed specification. Only use this method if appropriate however, as remedies will be much more limited.

Remedies in a Software Development Agreement

If something goes wrong, what should a customer be looking at in the development agreement?

• Limitations: The limits the supplier places on its own potential liability at the outset, as discussed above Here is where the customer’s careful review of this clause before signing is crucial, as it may end up defining what the customer can recoup.
• Fee caps: Another one to be reviewed carefully prior to signing, as this could limit the maximum monetary amount recoverable to a figure that would bear no resemblance to the damage actually caused.
• Remedies for specific occurrences: The contract may provide for pre-defined amounts to be payable if certain events occur (known as a ‘penalty clause’). If not carefully drafted, these may not be enforceable, so always get legal advice.
• Termination: Although an agreement may allow a customer to terminate in the event of a breach, this is of little use if the damage has already occurred (as with the Leaving Certificate coding error).

In Practice: Fail to Prepare…

The most important protections for a customer under a software development agreement can only be put in place at the outset – the contract itself cannot save the customer if it is not carefully prepared to meet the customer’s needs. Connie Wiseman, RDJ’s Chief Information Officer notes in relation to penalty clauses that “[a] penalty clause is of no use after an incident if the penalty award has not been accurately measured against the risk. Carrying out a second party audit on a supplier as part of the due diligence process can help to reduce the dependency on a penalty clause in a contract”.

Just as important, however, is the diligence you do on the provider of the services, as demonstrated by the Leaving Certificate results controversy. There must be significant attention given and care taken by both the legal team and the IT team designated the task of contracting with a supplier. As Connie Wiseman notes: “[d]ue diligence might inform or hint to the customer on the work processes and culture of the third party. Is the software developed in a secure safe fashion? What testing has been carried out on the software? Is there a solid update and patching procedure and notification to the client of incidents? Who owns an incident in the case of a company not providing the service or software as required?”

The IT professional’s view is important for those drafting agreement, as it gives a practical context. It reminds us that it is essential to consider if a specific remedy is workable and effective in reality.

Connie Wiseman poses a testing and sobering thought: “[d]oes your company assess key suppliers to ensure that they treat your critical business assets as they would as if it were personal data under the GDPR?”. The recent results scandal requires companies to focus their energies to be in a position to answer this question with an emphatic “yes”.