Use your contracts as checklists for managing risk on IT projects

An IT contract should be a checklist and a reference point for project risk management, not a dry legal document forgotten about...

An IT contract should be a checklist and a reference point for project risk management, not a dry legal document forgotten about in a drawer: that was the message delivered to a BCS meeting this month by IT solicitor and former system developer Rachel Burnett.

"Most people think a contract is just a lot of restrictions, and that drawing one up is rather expensive," Burnett told the Kingston and Croydon branch meeting. "But getting an acceptable contract and ensuring compliance with laws and regulations in advance can be seen as an investment. It is certainly cheaper to anticipate and avoid risk."

Burnett, a BCS fellow and vice-president, added, "The contract can add value by being a checklist for various issues that might otherwise be forgotten about in the heat of agreeing to go ahead with a project."

She underlined this by pointing to the long-running dispute between Co-operative Group and ICL, now part of Fujitsu, which has ended up in the Appeal Court, not least because no contract was finalised before the work began.

"Imagine the enormous cost and effort that has gone into this," Burnett said. "It would have been to everyone's advantage to have had an agreement that clearly set out what should have been delivered.

"A good contract should enable both parties to achieve what they want. It is the backbone to a commercial relationship. It allocates risks and responsibilities and interests: who should be doing what, by when. It should identify the important issues by setting the context. It should reflect the terms of the transaction itself, not be something pulled out of a precedents book."

Burnett said a contract should be focused, enabling discussion and clarification of what both parties mean. "For example, it is useful at the outset to say what is included in the price and what will be extra," she said.

"It should cater for contingencies, up to a point - for example what might happen if the customer was late with payment or service levels were not met."

Contracts need not be complicated, and should be structured to be useful to different people. Burnett said, "It is normally best to have a framework agreement, which can be short and manageable. It will have the main provisions and then appendices to organise the different parts of the contract.

"This can be useful if a supplier has standard terms and conditions and wants to include them: they can be appendices and schedules, and any differences that have been negotiated can be set out.

"The point is that a contract should not be incomprehensible. It should be structured so that different people can find and use the different parts they need. For example, the agreed service levels, the pricing, the specification."

Burnett summed up the value of a good contract by concluding, "The number of cases with good contracts that go to court is minimal."
This was last published in January 2004

CW+

Features

Enjoy the benefits of CW+ membership, learn more and join.

Read more on IT risk management

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close