When IT contracts go wrong, avoid litigation whenever possible. That was a core message delivered to a meeting of technologists last week.
The seminar, one of a series on law and IT run by lawyers Wigley and Co, the Technology Law Society and the NZ Computer Society with help from professional mediator Geoff Sharp, presented an escalating series of ever more formal and increasingly expensive solutions to contract disputes. The series went from negotiation through mediation, conciliation and case presentation in an informal “mini-trial” setting, to ruling by an independent expert and arbitration, or litigation as a last resort.
Sharp noted that the progression from informal to formal also marks a shift from “you [the parties to the contract] decide” to “someone else decides for you”.
Wigley partner Michael Wigley says most IT contract disputes will be resolved with little or no reference to the contract, other than in relation to specifications and other project detail.
“A good resolution clause will have an escalation path with, say, the project managers trying to resolve things first. If they can’t, then the clause escalates the problem to the CEOs.
“The integrity and experience of both parties is important, and in terms of risk reduction, this can be more important than the flashiest of agreements,” Wigley says.
The question of reference to the specification raises the wider and often-canvassed IT question of how definite a specification is or can be at the beginning of the project, when the contract is typically signed. This has become more difficult as iterative and “agile” programming methodologies have succeeded the simple “waterfall” model, which attempted an early rigid specification.
Usually the commitment to produce a system includes complex clauses, says consultant Ian Mitchell, and unless the requirements are very detailed, these clauses will be subject to interpretation.
It can be hard even to decide on acceptance criteria at the start, says Wigley. In about half the cases he has encountered, work had started on the project before a formal contract had been signed.
Acceptance testing should be agreed on even before the design is done, says Mitchell. “Scope creep” and the emergence of impossible objectives is a sign that “a lot of management are generalists, and a lot of them are bullies”.
Expert determination is a useful technique for resolving such specification disputes, says Wigley. You appoint a neutral individual who says “I will read the contract and documentation and then I will tell you”, and both parties agree to abide by that decision. This is less expensive and time-consuming than formal arbitration or mediation.
Mediation, if the dispute comes to that, is a matter of isolating the issues, developing options and considering the alternatives to arrive at a mutually satisfactory solution, says Sharp. Crucially, it involves moving the parties “from positions to interests”. True interests, once identified, are perhaps not as conflicting as initially entrenched positions.
Perce Harpham, former managing director of Progeni, spoke from that company’s experience as a key partner in the development of the original “Wanganui computer” law enforcement IT system. As a result of the collapse of its planned police successor, Incis, this project, which ran quite smoothly, has acquired a kind of reverse kudos.
The Wanganui contract was settled on a set of general specifications, says Harpham.
“Then we set aside a nine-month period for development of a detailed specification, and we quoted a price on that basis. If [the government agencies involved] told us to go away, then we agreed they could take the specification to another developer.”
Contracts for large projects should be written to provide for such an intermediate process, he says.