(#1 in our "Plea for Understanding" Series)
A while ago, we at IMPACT® promised that we would from time to time be looking at why IT lawyers seem to want to delve into areas which are not perceived to be their legitimate concern. After due consultation, the first area we’d like to look at involves specifications.
These come in various types - see for instance our schematic on the traditional software / systems lifecycle.
The key deliverables on IT-based projects are mainly intangibles – software and services – which are in themselves difficult to assess or measure. What in fact are being bought and sold are their outputs: lines of code perhaps, but really functionality (what the software can do) – and the results of services as measured by service levels or performance indicators.
So, when a customer decides to spend thousands of pounds on ACME Software’s Accounts System v 2.1, they are usually buying it because of what it will do. The same goes for buying hosted or managed services – but how is this to be captured and written down? The answer is... a specification.
The problem is that specifications aren’t always very good. The annals of IT litigation are filled with failed projects that were set rolling (often for massive sums) when there was in fact no real capture of what was to be delivered, and so no way to tell whether the supplier has delivered or not. The nightmare scenario is a customer refusing to pay anything until it gets what it thinks it ordered, and a supplier refusing to do any more work until it gets paid – stalemate.
When an IT lawyer asks to see a specification (of whatever kind), many clients appear to suspect their motives. Surely the specification isn’t a "legal" document, so why ask for it?
Lawyers want to see specifications because the whole point of having a written contract is to capture the deal in clear terms so anyone picking up the document can tell what the deal is. If properly written, the contract document promotes certainty and helps avoid disputes. Key people move on and with them their understanding of who agreed what, but the contract document should remain to provide a clear "baseline". If the lawyer needs to write the deal down, and if the essence of the deal is the specification, it can hardly be surprising that the lawyer needs to know what he or she is writing about.
Glad we could clear that up.