Three tips on designing a contract exit strategy

One of the knocks against lawyers is that we spend all our time planning for failure and thinking about ways out of a contract even as the parties are about to sign it.

So forgive me a moment of pleasure when something comes along to prove why sometimes we’re right.

The recent High Court case of AstraZeneca v IBM concentrated on a terminated IT services arrangement in which the parties ended up in court because they fundamentally disagreed about how some aspects of exit should be dealt with.

This wasn’t a quick-and-dirty contract: it was 90 clauses and 32 schedules, and yet two of the most experienced outsourcing firms couldn’t agree on how to exit.

The situation illustrates a few problems of dealing with exit in any ICT relationship.

1 Devils in details First, probably the most common error in any kind of services arrangement is that the parties will agree at the outset to have a high-level outline exit plan and then agree the detail in the first few months after contract signing.

Nine out of 10 times that never happens. This means that the parties come to the end of the contract without a detailed blueprint of how to exit.

2 Agree the terms Second, I feel strongly that parties should work hard at the outset of an agreement to agree the terms for exit.

The last thing you want to do when you’ve fallen out with the other party is to start agreeing new terms on which business will be transitioned away. It is much better to try and hammer this out in advance.

Certainly, any planning for exit and implementation of handover responsibilities at the actual point of handover could be priced in.

There is also an argument for paying extra for any additional services that may be required post-handover.

3 Multi-client environments. Finally, one of the more difficult areas for exit is handover from a multi-client environment. This is what caused many of the problems in the AstraZeneca v IBM case.

That contract anticipated that the terminating services may be provided by using shared infrastructure and, in that case, it would be hard to split up.

The court interpreted the phrase “shared infrastructure” very widely to include all IBM’s equipment, systems and facilities and its shared datacentres at various points around the world.

The breadth of this interpretation may actually push large service providers to go into detail about how segregation from a multi-client environment back to a single-client environment at the point of exit ought to happen. Their fear must be that they would become obliged to provide continuing services to potential competitors from their global datacentre suites.