31 March 2009

Waste in requirements

This picture is from the ever-useful Standish report (aka Chaos report.)

It indicates how many deliverred features were used - ranging from always to never.

How many of the requirements in your specification/backlog are going to contribute to the orange or red sectors?  And how do useless (?) requirements get into systems when the same report tells us that many important features are never implemented?

A question for the experienced guys and gals reading this site - do you have some tips on how to manage this problem?


  1. I'd really, really like to know a little bit more about those numbers. What were the projects that got that result? Are we talking about some projects that rack up huge numbers of unused requirements or do most projects rack up some? Is that just custom development or are ERP packages on that list (meaning that stuff that was bought but never implemented goes in there)?

  2. Requirements are better managed in Aerospace Software Industry. Poor requirement management generally plagues the non-critical (life-wise) software life cycle. If the discipline of a DO-178B like standard is imposed on all projects, this problem would vanish. That would also mean expensive software. The trade-off is, of course, between 'expensive to buy' versus 'expensive to maintain'. You might want to visit my blog on Aerospace Software to check out some more posts on Requirement Management.

  3. First of all If I had to share what I feel in my guts I'd come with pretty similar results.

    Well talking about dealing with the problem I don't have a good answer. I guess the most obvious way is coaching customers. However that's always tricky and rarely successful so it's hard to consider it as an answer.

    In big organizations decision-makers when it comes to feature range are recruited from marketing and/or business units. Very often they don't really know what their users want since they're filtered from real user requirements by tons of analysis, surveys and guesses.

    Decision about features often are made on "I think I'd like it so let's have it in the solution" way of thinking which also contribute in mentioned statistics.

  4. Anonymous12:17 am

    We have in our aerospace and defense practice when the Capabiltiies definition phase is skipped (resulting in the Concept of Operations - ConOps), the requirements baseline has not justification for eahc requirement - other than "looks like we might need that."
    Starting with Capabilities Based Planning, each requirement has a business or operational reason, and each capability has a requirements that enables it produce the planned business value.
    Thsi approach is not directly applicable to "emerging" systems like an internal IT product.
    But an incremental approach can be used there as well. Rolling Waves of capabilties and their requirements can be used to bound the "emergence."

  5. I agree with Kevin that the numbers need more context.

    But talking about solutions, here's what has worked for me, always.

    Demonstrate to your customers that what they are saying (requirements) is heard and implemented by frequently releasing (or at least showcasing the application).

    The customers need to feel confident about two things:

    1. My requirements get implemented

    2. I can make reasonable changes to the requirements.

    If your customers feel that these 3 months (requirements & analysis phase) is the only time they will get to voice their requirements, they will come up with as many as they can think of. Many of which could be of no practical use to the majority of users.

    Once your customers are confident about these 2 things, you can get into real de-scoping sessions. The backlog will get prioritized much better and you'll have the most useful features bubbling up to the top.

  6. Here is how I do it...

    (part 1 of 6)


    This method is rooted in sensemaking but is very effective for me and really gets the participants engaged.