As a requirements consultant, I frequently find myself working with new clients. I don’t always have a lot of context to their particular systems, projects, or problems. But I do occasionally find myself in a very familiar landscape: the adversarial relationship between IT and the Business. This is a situation that many analysts have seen repeatedly. Business doesn’t trust IT to deliver what it wants. IT complains that Business doesn’t know what it wants, so there’s no way to deliver it. Familiar?

One common way to address this is by putting much more focus on requirements definition. We spec out the requirements in more and more detail, so that the business can know exactly what it is that it’s getting. We treat the requirements document as a sacred contract to which IT can be held if they fail. And therein lies the problem. The requirements “contract” puts the onus on IT to deliver. IT fights hard to minimize what goes into the contract so that they can lower expectations. Business tries to squeeze as much into the contract as they can, since they figure that IT won’t deliver anything that isn’t in the contract. The contract becomes a document that defines (and perpetuates) the adversarial relationship between business and IT.

I prefer to think of requirements documents as a Constitution rather than a Contract. The document spells out the duties of both sides – business and IT. We recognize that it’s a document that may need to be changed, and we decide on the mechanism for changing it. Most importantly, it’s a document that is created and owned by BOTH the business and IT. This co-ownership of the document makes the document less of an artifact on which to base contention, and more of an artifact on which to base agreement.