Lesson One: Investigate Needs

An excerpt from the auditor's report on the California-Oracle contract reads: "Besides not knowing the actual need for statewide enterprise database licensure, the state entered the ELA [enterprise licensing agreement] without any formal evaluation of the contract's technical or business advantages."

In preparation for the Oracle contract, California's DOIT sent out a query about database needs to 127 state government departments and received only 21 responses. Other state agencies charged with oversight of large IT projects did not conduct a "contract needs" assessment, the auditor's report stated. The state negotiators also relied on statistics provided by the Oracle reseller on the project, Virginia-based Logicon (now known as Northrop Grumman Information Technology). Those reseller's stats indicated the state would save $US110 million on the project. In fact, the auditor's report said, the state overspent on the contract by $US41 million.

Going into any evaluation of possible IT purchases, CIOs should do extensive homework to determine exactly their enterprise needs. SA Water Corporation CIO David Johnston advises that despite the continued failure of many organisations to do so, it is essential to define fully the system requirements before you start. "Unclear requirements often open a Pandora's box of contractual scope disputes down the track," Johnston says. "Some vendors actually rely on unclear requirements to generate profits through the need for them to be paid more for Â'out of scope' services."

Defining requirements is even more vital for central purchasing functions within organisations or government. Johnston notes requirements definition documents effectively become contracts themselves between the purchasing function and the end users. That makes end-user buy-in critical to avoiding bureaucratic bungles such as the California example.

Organisations should also follow an arms-length, formal tender process. "A well-considered tender process is a valuable tool. It should provide a defined set of rules and protocols for vendor behaviour, client behaviour, communication mechanisms, and time frames and evaluation criteria," Johnston says.

Evaluation criteria are particularly important and well worth investing time in before the tender. A vendor is more likely to take seriously the task of responding if the organisation has a well-defined and professional process rather than a haphazard approach to the market.

Bob Luttrell, group IS manager, Asia Pacific Specialty Chemicals, says he tries to head off trouble by conducting a detailed specification of requirements upfront, working with all the users and categorising the list by major categories like applications, software support-type sub-systems, operating system and archiving system. He then breaks down applications lists by modules and prepares a simple one-sentence statement about each function. He also takes care to ensure the specifications include any other specific terms that he might want to cover upfront, such as ensuring maintenance is paid on the purchase price rather than the list price, and factoring CPI adjustments into contracts whenever possible.

When you do write your contracts, think carefully about contract requirements and be specific. "The great contract killer is uncertainty," says Clayton Utz partner, corporate, Peter Knight. "The underlying requirement of any contract is certainty. Lack of certainty may lead to a complete failure of a contract or a crucial section of a contract, as a legally enforceable/meaningful relationship."