‘Oh dear,’ ran the headline in The Telegraph addressing the failure of the NHS IT contract, ‘is this another costly IT failure?’
The issues surrounding the NHS IT contract have been widely debated but more interesting is The Telegraph's reference to ‘another’.
Public perception of IT contracts is often biased as the press rarely publish ‘good news’ and so the impression given is that all IT expenditure is doomed to either complete failure or underwhelming delivery.
This is not true – although, admittedly, when IT projects fail they often do so in spectacular fashion – but the majority of IT implementations pass by without much consternation, litigation lawyers or bad press.
There are many reasons why IT contracts fail or do not live up to expectation – here are some of the top considerations.
1. Money
Contracts are entered into to make money for the contractor and to either save or make money (or both) for the customer. This simple cornerstone is often ignored in the way that contracts are drafted. The customer drive for best value is often evidenced by clauses which regulate cost and delivery including 'added value' and 'benchmarking' and clauses which are designed to punish for poor or non-delivery such as liquidated damages.
The problem is that all of these clauses erode the profit margin of the supplier. Nothing is for free and squeezing margins is often an empty victory for the customer as the supplier looks to recoup elsewhere. This doesn’t mean that they do not have their place but the impact on the supplier needs to be considered. Incentives to delivery can be as effective as punishment.
2. Technical specification vs. contract
On too many occasions, the technical specification is treated by all parties (including, sadly some lawyers) as something for the 'tech guys' to sort. It is appended to the IT contract with flippant disregard on how it works with the remainder of the contract. The technical specification needs to be an integral part of the contract, consistent in definitions and consistent in overall objectives.
3. Flexibility
The problem with technology in general is that we are no longer looking at long term investment cycles. IT infrastructure can be out of date (or worse – obsolete) within months of implementation. The drive for agile contract methodology is a useful approach to provide customers with flexibility of solution but the price to be paid is the uncertainty of what will or will not eventually be delivered and so customers need to be realistic on what their primary goals are. Is it certainty at the expensive of flexibility or flexibility at the expense of certainty.
4. Intellectual property
There is an obsession in the UK with 'ownership'. On many occasions IT contracts are littered with complicated provisions running into several pages on who 'owns' what. Long definitions of 'background' and 'foreground' IP become battle grounds for the lawyers. This is not to say that IP is not a vital component – but before embarking on complicated IP ownership provisions an analysis should be undertaken on what is needed and what rights are needed to obtain that objective.
5. Expectation mismatch
One of the biggest problems is that there is often a difference between the supplier 'sell' and actual delivery. Over-enthusiastic salesman will often promise everything in an attempt to win the work which often results in disappointment on delivery. It is also important that customers remember that simply awarding the contract does not mean they can now sit back and wait for delivery. They need to remain an integral part of the process if they wish to ensure that delivery and expectation are aligned.
6. Change of requirements
One of the biggest frustrations for suppliers is often change in scope as the customer defines or redefines their requirements. Whilst an agile contract is much more able to accommodate this, change in scope will inevitably lead to delay and/or addition cost.
>See also: The top 10 ways why BYOD initiatives fail
When IT contracts go wrong the potential implications are vast. Even if the customer is able to recover their costs and investment, they will have lost market ground and often the contractual terms will limit their ability to recover damages that are reflective of the actual loss suffered.
Any IT contract should have clear mechanisms for dealing with disputes so as to give both parties the best opportunity to remedy and keep the relationship intact. Clear deliverables and realistic timescales are imperative. Where possible, customers and suppliers should ensure that there is "fat" in the timescales so as to not only allow for slippage but also allow time for rectification.
What is clear is that when IT contracts go wrong, the only parties that are likely to benefit are the press in their ability to report bad news and the lawyers (whichever side they are on) in attempting to ensure that someone is held responsible.
