29 October 2007

3 tips to improve requirements management

Darren tells us that user requirements are at the top of the list of reasons why project fail. No surprises there.

But he elaborates; it's not the elicitation of the requirements, it's the communication of them to the developers, and the dev team's understanding of them that is where the problem is occurring.

It's no surprise when you consider the long liked communications process that often occurs, especially in large organisations. It's even more obvious when you consider outsourced development houses that don't have much business or even industry domain knowledge. How does a fresh develop with no history with the client organisation fill in the gaps in the communicated requirements?

Avoid requirements failure by doing these things;

  1. Have developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often. Use workshops, wireframes, prototypes, or documents, but do it.
  2. Bring the subject matter experts and requirements owners into the same room as the developers. Get them talking to each other. If you can't be in the same room, arrange regular meetings. Don't rely on written communication.
  3. Make sure your BAs are trained and highly skilled at requirements management (ie not just elicitation, but the whole shebang.)

Business Analysts are the main key to successful projects. Pay them more and pat them on the back when they do a good job.


  1. Just some short comments: ad 1. documents aren't sufficient enough - have a prototype (even a very rough one) ready ASAP to earlier avoid possible misunderstanding and possible complete re-development.
    Ad 2. regular communication and feed back of developers with stakeholders - subject matter experts and requirements creators is a must! On some of my projects, where development was off-shored, Skype helped a lot.
    And maybe 4. have your developers make developments in one run if possible! They usually tend to do it in more separate approaches, alternating different developments for different customers which protracts time of the development and allows more misunderstanding between what was requested and what was really delivered.
    And don't forget to manage your developers in their promises. "Anything" can be developed, the only question is in what time and for what money - developers usually have no responsibility for these issues, but they tend to make a Porsche Carrera where only Fiat Punto is needed :-)

  2. I would also suggest managing the business rules for your system separately but linked to your requirements. Especially by defining the decision nodes in use cases that can be described using externalized business rules.
    Check out this entry on the Smart Enough Wiki - Business Rules and Requirements
    James Taylor
    The Smart (Enough) Systems blog
    My ebizQ blog
    Author of Smart (Enough) Systems

  3. Thanks for the feedback guys. All useful.

    There is a lot of knowledge around business rules management. My focus in this blog is not so much on the tchnical aspects of requirements management, but principles like this are very important to understand.

    When I want to look into topics like this I go to Scott Sehlhorst's blog at Tynerblain

    Scott doesn't always have the answers but canoften oint you in the right direction.

  4. Anonymous4:53 pm

    (Disclaimer: I work for a company called Accompa - we make affordable requirements management software.)

    With that out of the way - Craig, you make a very good point in this post. In our customer surveys - "misunderstood requirements" are consistently rated as one of the biggest problems our customers face.

    Your suggestion of "Have developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often." is an excellent suggestion. As a matter of fact, this is one of the 7 tips we share with our new customers to help them improve their requirements management as well! :)