Requirements vs. specifications

This may be a post to teach grandmothers to suck eggs, but the question has been asked – why do I go on so much about the importance of separate requirements and specifications stages – surely they are the same?

This is, unfortunately, a common problem with IT projects these days – I would say that the vast majority of the problem projects I’m asked to deal with have had core problems in this area – and mostly for suppliers/developers who have contracted against incomplete and/or inaccurate requirements, without a specifications stage for the customer to sign off before development/implementation starts. When analysing such projects, when I ask for the “specifications” I am invariably given the “requirements” – without either the customer or the supplier having realised that the specifications have never been produced.

As my ex-managers and sales staff will testify, this is one area that, as MD of a software house, I drummed into my staff – the difference between requirements and specifications, and the importance of a customer agreeing not just the requirements (i.e. what he wants the system to do) but also the specification (how the system will fulfil his requirements) – and how difficult it is to estimate accurately any development work until a specification has been agreed.

Yes – it is possible, with good in-house IT department and development teams, to short-circuit some of these phases – but not in customer/external supplier, fixed price contracts – the risks can be just too great.

Contracts involving existing software application packages should be a lot easier, but in some cases, despite the supplier’s statement of compliance against the customer’s requirements being accurate, the supplied solution turns out not to be what the customer really wanted – why? – it comes back to the difference between requirements and specifications.

With modern application packages, most common requirements can be met, but in most cases the supplier’s Tender/proposal doesn’t spell out how each requirement will be met – e.g. the customer may expect (want) a single screen format and transaction to meet a specific requirement, yet the supplier’s solution is to use two or more screens and transactions – if the customer hasn’t spelt out the his needs in detail, there can be problems.

More importantly, some customers do not recognise their own responsibilities in the pre-contract stage of buying an existing application package – namely that of satisfying themselves (and their end-users) that the intended solution operates the way they want their requirements met. At the end of the day, most application software packages are purchased on the basis of a statement of compliance (typically against requirements) and then a specification of the software package – which, typically, has been the subject of demonstration and reference visits – and if these latter stages have been skimped, or the wrong staff drafted in, the customer can fail in his part of the procurement.

Buying or supplying systems against requirements can be highly risky – for both customer and supplier. For application products, they can be procured safely without a separate specification stage, provided both parties work together to agree that the proposed solution will meet the customer’s requirements. For bespoke developments (including large changes to existing packages), I always recommend that final fixed price contracts are not let until a firm specification has been agreed between the parties – possibly using the phased fixed price approach I’ve discussed in previous posts.

P.S. I provide consultancy to both customers and suppliers on both the pre-contractual stages of procurement of new systems/services, and the resolution of problems in projects after contracts have been let. Visit my web site at www.systemsolveconsultancy.co.uk for further details, or contact me at phil@systemsolveconsultancy.co.uk .