The IT factor

IT has opened many doors, but contractual problems are rife. Nick Holland reports on the potholes and safety nets

We often hear about IT contracts going wrong or ending in dispute. Perhaps the most classic example of this reached the public consciousness two years ago – the problems with the issuing of passports due to an alleged defect in the software and the implementation. That is just one example of many in what is a risky business, but there are various things to look out for and precautions that can be taken.

IT contracts
There are many risks associated with such contracts, which inevitably lead to disputes occurring.

The buyer being unclear as to what it wants, but the supplier nonetheless stating that it could achieve this unclear specification.
In the case of the above, once the contract is actually being implemented, the specification becomes more clear with the inevitable increase in costs – 'future creep'.
Time scales that are never achievable with the resources allocated and the costs associated in implementing the project.
There is often too little interaction between the actual users of the system and those who drew up the specification.
Very often the supplier tries to win the deal with Team A, negotiate the contract with Team B and implement the contract with Team C – none of whom talk to one another enough or even at all.
A general failure by both parties to communicate effectively and general poor project management.
The tendency to believe that once the contract is signed, the deal is finalised and the team that negotiated the contract moves on to another opportunity while the contract gathers dust in someone's desk.
Too little attention is paid to contract change control, which is always critical in IT infrastructure contracts, but which is often not formally documented. Disputes will arise as to what has specifically been agreed in relation to any changes.
Very often the parties will not form joint project teams working together to implement the project and to resolve the differences, but will work in two separate teams on their respective sites. This only duplicates efforts and leads to a lack of communication.
Inevitably, the points below are always to some degree compromised by cost and time constraints but undertaking some of them will save on costs and time.
The supplier should never try to oversell its solution to the customer, both from a financial point of view and, more importantly, from a legal point of view, in light of any potential misrepresentation.
The parties should always have some form of joint project management team implementing the project. This should be made up of individuals from both sides who work together on the same site, rather than meet each other periodically.
There should be a very clear dispute resolution procedure, both on a commercial and legal level, which must ensure that it engages the senior people of both sides. Often, such people get involved in these contracts too late.
The specification of what is demanded should be spelt out very clearly and put in layman's terms as much as possible.
w There must be a very vigorous and well-documented change control to ensure 'future creep' does not occur, but that if it does, it is costed as an extra rather than a “we thought that was included in the specification anyway”.
The parties negotiating the contract should ensure that the people who will implement the contract are involved in the negotiation stage so it is clear to everyone what is in the contract.
It is good practice to produce a summary of the contract after it has been signed. However, this should be tempered with the fact that very often people will then look only at the summary rather than the contract as a whole.
A good contract is not one where you have managed to sneak in various nasty terms and conditions that you will have great difficulty enforcing. A good contract is one that is being fairly negotiated by both sides, is clear and unambiguous, has been business cased by both sides prior to signature, and which above all is enforceable in the courts should the need arise.
It is wise to business case the project some months into its implementation to ensure that the business case in implementation approximately matches the business case prior to implementation.
Contract managers for both sides should be used and be part of the implementation of a project at all times. In-house counsel and external lawyers should only be involved during implementation as a sign that something is amiss.
Very often, in-house lawyers and external counsel can make good project managers from the tendering of the contract to its signature and you should not shy away from using lawyers in this way when they can add value to the whole process.
By their very nature IT projects are complex and both parties should not underestimate the amount of time needed to tender, negotiate and finalise the contract prior to its implementation. In almost every case, there will always be risks and pitfalls that you can never anticipate or cater for. The best you can do is undertake the project using the above principles, which should cater for most problems and help deal with those unanticipated ones; in other words, always expect the unexpected.
Nick Holland is a projects partner at Beachcroft Wansbroughs