1 February 2010

Understanding the root causes of poor requirements; Invest in clear requirements

Early last year Nick Malik of Microsoft posted decision tree analysis of Requirements Failure modes. I thought I'd take a run through some of his points and offer them to you for discussion.

It's a long list so I'll break this up over several posts across the next few weeks/months. Jump in if you have any questions.

Failure mode: Business stakeholders may not believe that it is important to invest time in creating clear, unambiguous requirements.

Nick suggests stakeholders to projects perceive requirements definition as a time consuming and overly expensive activity: "We know what we want! Just build the damned thing!"

The obvious example is an organisation that has been sold a solution by a vendor and is now looking to impose it on some poor business owner. But this can also happen when the problem domain is very familiar in a business context but the organisation doesn't have much technical capability - and so underestimates the risks and complexity they are about to bite off.

The project and solution scope needs to be grounded in some real beneficial initiative - either a problem or opportunity, or a blend of several of these. And you need to set a limit to the work you are going to do or you'll just keep pouring money into a never ending pit.

So, the argument goes that we should not start until the business requirements are defined. Actually, depending on your domain knwoldge and the availability of key SMEs you could very well just start.

The ramp up phase of a technical project may be longer than the requirements definition phase and for newly forming teams is unlikely to be much shorter.

The solution architecture should be able to be modelled within a few days of a high level business model being defined. And the sponsor should be able to develop their business model within a week, if they are committed to the project. Once you have this high level framework you have enough to kick off in a typical enterprise project.

The flip side of this fast start is that business stakeholders and the sponsor need to stick around throughout the project paying attention. (And the PMI and Prince2 people say exactly the same thing as the Agile folks by the way.) So, it's the up-frontness that agile argues against, not the overall requirements definition effort.

Next point; Requirements need to be clear and unambiguous. This is one of the toughest parts of the job. If your sponsor and stakeholders think they are all speaking the same language there are plenty of learning games around to show them that they are not.

And if games are not your thing try the very pragmatic approach of drafting a data dictionary or set of preliminary business rules and watch as they start to argue through the meanings embedded in the words.

By demonstrating that clear and unambiguous don't come naturally you begin to show them 'the way.' Of course you can't be a smart arse. It has to be done with respect.

Do any readers have war stories about sponsors and stakeholders that thought all they had to do was pay the bills? What happened? How did you tackle it?

Picture "Fail, Ok" by Ricky Romero at flickr


  1. " How did you tackle it? "

    I stopped. If the business did not participate, there would be no requirements produced.

    Did I get any pressure from IT Management to do "it" anyway? Not much but, if I did, I would ask what "it" would consist of, and when no one knew, pressure went away.

  2. David, I have a hunch that it was a successful approach. How did it go to your reputation for getting things done?

  3. I have to hope that any negative impact was overcome by the recognition that what did get done was good. (If not, I was probably on my way to somewhere else fairly soon.)


Search This Blog