Contracting needs a refreshing change

Technology refresh is a recurring area of disagreement between customers and technology service providers. Mostly, this is because technology refresh calls for speculation about the future, which tends to get resolved by broad principles — about which the parties then disagree when faced with real expenditure choices some years later.

During the recession,costs were cut by extending technology refresh cycles, thereby deferring expenditure and reducing charges. This is leading to a bottleneck of issues from deferred refresh decisions. The issues usually boil down to two questions: when does the requirement to refresh arise? And who pays?

Technology refresh is inherently uncertain because it’s easy to set out generalised principles for addressing the issues but often harder to apply those principles as new and potentially unforeseen developments in technology come along. Much of this comes down to good governance and relationship management, and also how transparent the original contract was in terms of what was included or priced-in.

The more you can be specific about the technology refresh requirements in relation to different systems or platforms, the less room there is for future debate. Most agreements on technology refresh typically distinguish between the principles that apply to different types of technology. Considering how each type ought to be refreshed is an obvious place to start.

It’s common to see requirements that systems should be maintained on a ‘like-for-like’ basis (same hardware vendor and software suite, for example) or that no element of the overall infrastructure should fall into an unsupported ‘end-of-life’ trap. The problems here are that those key terms mean different things to different people, and they address different aspects of the technology refresh issue: like-for-like being more about ‘what’ and end-of-life more about ‘when’.

‘Like-for-like’ doesn’t address the central dilemmas of when refresh should occur and what happens if circumstances change — for example if a particular third-party provider is no longer a strategic supplier or there are looming end-of-life concerns.

My recommendation is always to make express provision for as many individual systems and platforms as possible. You’re still likely to need some general principles in the software area but at least you’ll have reduced the scope for future disagreement. And if you use general principles, try to anticipate obvious areas where you might disagree over application.

Alistair Maughan is a partner at law firm Morrison & Foerster