Relief from relief: Making handling relief events easier and more collaborative

Problems with relief event clauses

In our experience, the drafting of such clauses often does not take into account how administratively burdensome they can be – for example:

• Delays are a regular feature of technology projects, and as much as suppliers require relief for delays for which they are not responsible, such clauses typically require them to keep a ledger of delays and who is responsible. 
• Arguments can arise where each party has a degree of responsibility for what has happened but neither wants the delay written up on their side of the ledger. 

Suppliers will often ask for a period of grace during which they are not held responsible for delays. However, such relief gives customers uncertainty (and effectively extends the timetable for the project), so customers will typically resist these grace periods. 

A proposed solution

A solution to such problems we recently proposed (that both the supplier and customer liked) was a so-called “bucket of days” into which delays of two days or less would be deposited with no consequence for either party. 

The solution required the parties to do a simple check of progress against the agreed timetable at their regular governance meetings; and where delays had occurred since the last meeting, irrespective of which party was responsible, that time was added to the bucket.  

Only if the bucket is filled would the parties need to keep a record of subsequent delays (for relief and liquidated damages purposes). 

The result is a simpler record-keeping process and a likelihood of fewer arguments over responsibility for delays. The supplier benefits from a degree of flexibility for delays caused by it, in return for accepting the risk that the bucket could be filled by delays caused by the customer (with no ability on the supplier’s part to claim additional payment or impose other consequences for those delays).

In the deal where we advanced this solution, the parties contractually agreed to exclude delays of three days or longer from the delay bucket, because it was felt that these would occur more rarely and that consequences should always flow from such serious delays.

Final observations

It ought to go without saying, but it is important to be practical when drafting technology implementation, outsourcing and services contracts. Contracts that increase the administrative burden on the parties may be legally sound but run the risk of being disregarded by the parties in implementing the project until something particularly serious happens. 

At that stage, it can be difficult trying to unravel a project which has not been implemented in line with the contract in order, say, to determine liability for claims (or other consequences). Contracts that make the relationship operate more smoothly at a practical level and that have workable, readily understood governance processes are to be preferred. There are many ways to make relief event clauses simpler and more collaborative.  The solution set out here is just one of them.