It is no secret that the source of most problems in a technology-centric contract is the specification.
(1) If the specification is vague, or mistakenly relies on the propensity of the reader to fill the gaps with the same assumptions as the writer, then each party will have a different understanding of what is to be delivered. This leads to two potential problems:
(a) The supplier delivers something different to what the purchaser actually requires; or
(b) The purchaser can continually use the ambiguity in the specification to deny payment or insist on endless rework.
Ultimately, each party will rely on its own interpretation and assert that the other party has breached the contract.
(2) If the specification turns out to be unworkable, there will need to be appropriate contractual mechanisms and an effective working relationship to resolve this. Without this:
(a) The purchaser will assert that the supplier is trying to deliver less than what was agreed to, or repudiating the contract; and
(b) The supplier will be burdened with the cost of rework or even abandoning the project.
The end result (if delivered) will likely struggle to fulfil the purchaser’s purposes for the project. Again, this difference in what each side had in mind when entering the contract provides fuel for disputes.
It is little wonder that most disputes come back to the specification, as it provides the baseline on which the major parts of a technology-centric contract rely:
(a) Payment terms rely on acceptance that certain features of the specification have been met;
(b) Warranty terms rely on answering whether the deliverables have failed to perform according to the specification;
(c) Maintenance and service level agreements rely maintaining or returning the deliverables to the requirements of the specification;
(d) Liquidated damages clauses will rely on determined whether certain aspects of the specification have been met by a certain date;
(e) Variation clauses rely on determining the extent to which a change request is a deviation from the agreed scope of work;
(f) Common law rights of termination and damages rely on discerning the disparity between what was delivered and what was required;
(g) The pricing of the contract relies on the interpretation of what is required to satisfy the specifications;
And ultimately, a failure to translate purchaser expectations into a specification, which, if delivered will satisfy them, risks the agreement ending in disputes and project failure.
The trouble with specifications is that they exist at the intersection of three project vulnerabilities:
(1) Specifications are often drafted by engineers, or other technical professionals. These professionals are accustomed to communicating using the jargon and terminology of their respective fields and not for the broader audience that a contract specification must communicate to. They risk drafting the specification in a manner that is riddled with numerous assumptions because in their mind those assumptions ‘go without saying’.
Unfortunately, any audience outside that area will apply their own assumptions to fill those gaps and arrive at a different interpretation of what is required. Furthermore, a non-technical audience (e.g. lawyers, managers and business people etc) will often be unable to traverse those assumption-gaps in the specification and struggle to read the document at all.
(2) The lawyers engaged by the parties to draft and negotiate the contract often lack the technical literacy to address shortcomings in the specification, don’t know the right questions to ask, and won’t want to concede that they don’t understand it. As a result they are likely to gloss over the specification and revert to risk-shifting clauses to pin the cost of eventual project issues on the other party. For those who desire to ‘leave the contract in the draw’ while administering the project, risk-shifting clauses provide little assistance.
(3) The more unique a project is the more difficult it is to predict all the issues that may arise. As the saying goes, ‘no plan survives first contact with the enemy’. The art in drafting specifications, is in providing adequate quality and performance goals, while allowing room to adapt to handle uncertainties as they occur during the life of the project.
For example, there may be known uncertainty at the outset about what exactly will be required, or whether certain performance levels can be guaranteed. Options to deal with this may include the use of a high level specification, with a more detailed specification to later be accepted or rejected against that high level specification once those unknown have been addressed; or the specification might provide room for the supplier to determine the best trade-off within specified tolerances.
The best way to keep a project on track is to avoid disputes from arising at all. The most fertile origin for disputes in a technology-centric contract is the specification. In the worst case, it will be a legally trained mind (i.e. a judge) that will finally determine the ‘proper’ meaning of the contract.
Therefore, the best means to de-risk a technology-centric contract is to engage professionals at the start who have the skills and expertise to critically analyse specifications from both a legal and technical standpoint. Engaging such expertise before signing the contract reduces the risk to all parties and ultimately, makes the project much more likely to succeed.
See also: How lawyers can serve engineers better