19 May 2011

How good are your requirements specifications?

[Start at the beginning]

A quick quiz for you:
  • Have you ever worked on a project where you've picked up requirements from someone else and they were incomplete?
  • Have you ever created requirements specifications but have really needed more time and more work to make them really - to your standards - good enough, but you simply ran out of time?
  • Have you ever worked on a project where the Sponsor, or some senior client has come up with a brilliant idea at the last minute? And the requirements suddenly changed radically?
  • Have you ever got stuck at a sign-off stage of a project, unable to get consensus?  To push things through you have to make compromises that create flaws in the logical model of the solution you were seeking?
I score 4/4 on that little quiz.

Requirements management in the real world is not as logical and delimited as you'd like it to be.  In defining requirements there are a number of intangible human factors that need to be accommodated.

The end result is that almost (always?) all the time requirements specifications are flawed.  They do not represent the true target model of the client.  They omit things, they include logical inconsistencies, they duplicate things, they emphasis things in a way that makes no sense to someone trying to build a solution.

There is certainly "good enough."  I have often developed specs that are good enough in days or only a few weeks.  Projects work well from good enough.  Possibly good enough is even better than the "high quality" requirements specification.

Good enough or not, requirements specs will not be sufficient tools to define project work on anything of scale.  Your understanding of requirements will change over time, and thus the work effort required to fulfill requirements will also change.

Did you know that someone has gone to the trouble of tracking the rate of scope change (creep) over time?  Did you know that the people/person who has done this shares his knowledge with the world relatively liberally?

You could (and should) buy the book Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies but the shortcut in this conversation is 2%.

Capers Jones in his research highlights that there is an industry standard scope growth of 2% PER MONTH.  That is quite a lot over a 12 month project (or program.)  Even more in 2-3 year projects.

Additionally you should consider that the group Capers has been surveying consider measurement of requirements growth a worthwhile activity and so are likely on the higher side of requirements management maturity.

What's your company's monthly scope change rate?

No comments:

Post a Comment