Why good projects go bad

The number of IT projects that end in failure is staggering. According to a 2007 study by researcher Market Dynamics, 62% of all IT projects miss their deadlines, 49% go over budget and 41% fail to deliver the benefits that were expected. That is worrying enough for IT departments.

But for consultants and software vendors, keenly aware that project failure could well result in litigation, it is a constant concern. It is that concern that specialist insurer Hiscox addresses with its offering to IT vendors, insuring them against being sued by their customers. And it is a genuine danger. Stephen Wares, UK manager of Hiscox’s IT practice, tells of a small software development company with a turnover of £5 million that was sued for £18 million for the alleged failure of a project (the suit was eventually unsuccessful).

And although most IT disputes don’t make it to court, they don’t have to in order to be devastating: the average cost of just preparing the documents for trial is £1.5 million, says Wares. Many of the lessons learned by Hiscox in assessing potential clients, and helping clients avoid litigation, are equally applicable to IT departments as they engage both with the business and with their own suppliers. For example, it is vitally important to provide an accurate reflection of your ability to deliver at the start of any project. “All of the due diligence focuses on the way that they sell,” explains Wares.

“One way for the customer to get out of liability on the contract is to claim fraudulent misrepresentation. So we need to see accuracy in the sales pitch.” Equally, the specifications of any project must be rock solid. “A lot of the claims we have seen have been when the spec was ambiguous,” Wares explains.

“When the client is no longer committed to the project, and claims that you haven’t delivered what you said you would, you can’t prove them wrong if the spec is ambiguous. You need to make sure there is a good solid foundation.” But the burning issue is change control, Wares says. “Change control is still the biggest issue in terms of causes for a claim,” he explains.

A dispute will often arise over the extra work that materialises after the specification has been agreed upon. Documenting changes to the specification is essential in order to prove what is included in the original contract, and what isn’t. However, while most contracts include change management clauses, in practice they are not always followed to the letter. “Part of the problem is informal change control,” explains Wares.

“If you work on a project for five years, you become friends with the people you are working with, so the project meetings can become chummy.” In those circumstances, he adds, documentation can become lax. Encouragingly, the industry does learn from its mistakes, says Wares. “Ten years ago, we wouldn’t have seen a change control clause in a typical contract. In the contracts being written today, there almost certainly will be one,” he says. “But that doesn’t mean it will be used, necessarily. So we are moving on, but we still have some way to go.”

Pete Swabey

Pete Swabey

Pete was Editor of Information Age and head of technology research for Vitesse Media plc from 2005 to 2013, before moving on to be Senior Editor and then Editorial Director at The Economist Intelligence...

Related Topics