Construction and IT demand separate packages to work
Many clients are reluctant to separate construction and IT contracts. But, as Sachin Kerur reports, variations in procurement and supply mean that the two are very different entities and can be successfully divided.
With Playstation 3 going on sale in the UAE this week I suspect the number of readers of this column will be down. And who can blame those games freaks and sorry aficionados, eager to play with the console packed with the latest IT hardware and software. Our gaming readers will also recognise that IT infrastructure is now of course an important part of construction procurement.
Many employers want their contracts to deal with the procurement of the IT part of a project as well as the bricks and mortar. Employers consider it inconvenient to have different contracts for the concrete and IT elements. They believe it threatens the principle of having single-point responsibility for the performance of the works and that it would be inconvenient to have different sets of rules to administer different types of work. Indeed, the control and communications, data transmission, signalling, and other intelligent systems are often thought of either as being ancillary to or as not being sufficiently different from the concrete parts, as to merit separate treatment under the contract.
But from a lawyer's point of view there are problems associated with this approach. Contracts are sophisticated, and cover in detail important issues such as the quality of the service to be provided, product descriptions or specifications, contract periods and entitlements to extensions of time, payment mechanisms, testing, hand-over, warranty periods, liquidated damages for delay and so on. They are almost alone in being in a readily available standard form for the procurement of significant capital assets. IT and buildings are, for many companies, their two largest categories of capital expenditure, so it seems to make sense to treat them similarly. These are all very sensible points but there are many key areas where the use of construction contract terms is not suited to the procurement of IT.
The key distinction between construction and IT projects is the nature of the procurement and supply process, which are at odds in a number of ways. While both construction and IT projects require a high level of certainty in the project specification and design at the start, IT projects require a distinction to be made between what is a business requirement specification and a functional requirement specification - a fuller and more specific document than a business requirement. Also, the party procuring IT generally has more input into the design of the IT system than in construction projects. This is because the specification must take on board bespoke business requirements where considerable reliance is placed upon the purchaser for their input. Consequently there is a need for more sophisticated ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“change control' procedures to take account of the almost certain changes that will need to be made to IT procurement before the system is finished.
Internationally, fitness for purpose warranties for construction work have now become quite normal. IT suppliers are, however, reluctant to give such warranties. Indeed, IT companies insist on greater protection from liability than is tolerated in the construction industry. Also, acceptance testing for IT systems is a major undertaking, whereas for static structures that is much less the case. Therefore, procedures specified in the most common construction contracts are not sophisticated enough. At the very least, the contract needs to spell out who will be responsible for testing and who will provide the test data. It needs to define the categories of defects, system performance and response time, how to deal with exceptional results and to specify what the consequences of test failure might be.
In the world of IT, there seems to be more tolerance of the appearance of faults or defects after system acceptance. Indeed, it is normal in IT for there to be continued involvement by the supplier in the further development or the maintenance of the product. Construction contracts do not normally address such post-completion services and instead deal with post-acceptance defects in the defects liability period.
Standard form construction contracts barely touch on the issue of intellectual property rights in software developed for the purpose of an IT project - those forms that mention it in passing treat it as part of the definition of ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“plant' or ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“works', which simply does not reflect the complex questions of software ownership. For example, who owns pre-existing proprietary software and what about modifications to such software?
Admittedly, the construction industry has attempted to provide for an appropriate standard form contract for IT works. Take the MF/1 form for the supply of electrical, electronic or mechanical plant, produced by the UK's IEE. It contains a section called: "Additional special conditions for use in contracts involving incidental supply of hardware and software." Although the form uses IT-specific terminology such as ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“software', ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“hardware', ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“software system specification' and ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“functional specification', it still seems to envisage a supply process along traditional construction lines. Even the reference to ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“incidental supply' betrays exactly where the emphasis lies. Indeed, it does not allow for an evolving specification and does not reflect the reality of software ownership in such projects.
It is sometimes difficult to see how it is better to have a single contract for construction and IT, or how it is worth living with those aspects of standard construction contracts that are inappropriate for or inapplicable to IT, just for the sake of convenience. Shoe-horning an IT system development and supply process into a standard construction contract may cause difficulties.
However, many clients continue to want to use standard form construction contracts for IT. When this is the case, they must know what they are getting into. Employers should not expect their IT project to run smoothly under a construction contract just because their project manager has ÃƒÂ¢Ã¢â€šÂ¬Ã‹Å“control', and suppliers should not start work under a construction contract unless the specification is sufficiently developed. While not as good as using bespoke IT contracts for the IT aspect of infrastructure projects, steps can be taken to alleviate some of the problems associated with using standard construction contracts for IT procurement. And that means more time to beat Tiger Woods with a thrilling finish on the last hole, PS3 style.