Prioritising requirements – how to do it and why it is critical to project success

priority_signThis article is the first in a series on requirements prioritisation. It explores why it is critical to project success to prioritise requirements, why it can be unsuccessful and describes one technique to achieve consensus.

Why prioritise?

On most projects of reasonable complexity, there is a limited budget and the budget must be wisely targeted to maximise value and minimise costs. Prioritisation provides transparency to the business and allows them to make informed decisions when deciding on the scope of the project. In other words, they will understand where the money will be spent and that it is spent on the most critical requirements. This enables an informed decision on  the initial scope of the project and whether there should be subsequent phases. This is critical for Agile projects where there are many releases of code or increments and the content of each must be agreed.

As the project progresses, internal or external events (e.g. budget cuts, market downturn, competitor activity) can cause the scope and cost of a project to be reconsidered. Without prioritised requirements, any decisions on cuts in scope are more challenging and may be flawed.

Under specific circumstances, it is possible to avoid prioritisation or it may not prove necessary. This would be the case where the prioritisation is imposed or already decided. For example, a project that is required for regulatory reasons will tend to have well-defined mandatory requirements so all other requirements are not mandatory. There is an obvious risk if the requirements are imposed by, for example, senior management as there may be poor buy in if stakeholders representing users are not consulted on priorities which may impact project success.

What requirements can be prioritised?

It can be done at several levels including features (e.g. order management), individual capabilities (e.g. use case – credit check customer), constraints (e.g. must manage 60 purchases per second) and business processes (new or changed). The business analyst, in conjunction with the project manager and business sponsor (or lead stakeholder), needs to decide at which level(s) it is relevant to prioritise. It is usually sensible to prioritise at all these levels as it is not known either how the scope may need to change and where the costs will be incurred.

Why is prioritisation unsuccessful?

Stakeholders will ask for everything if there is no disincentive. If they are not responsible for managing cost, there is no incentive to recognise the need for tradeoffs and prioritise one requirement over another. Stakeholders will have different perspectives – for example, users will be focused on usability and speed. Legal stakeholders will be focused on mitigating legal risks and ensuring compliance. The project sponsor (or equivalent) will be interested in overall business impact, benefit and costs. The customer will focus on their own criteria which don’t take account of commercial realities.

It is no wonder that it is a challenge to balance these different priorities and achieve consensus!

Techniques for success

There are many different approaches available. We need to consider the following when choosing an appropriate technique:

  • How do we achieve consensus across a group?
  • How do we ensure an even spread of priorities?
    As a rule of thumb, a third should be high, one third medium and one third low
  • How do we accommodate different stakeholders relative importance? For example, the project sponsor is likely to have the final say
  • What approach will best suit the organisation? Formal or informal

Dot voting

One technique that can be used for gaining consensus in a group is called ‘dot voting’. There are variations on this theme but the core idea is that each stakeholder has a limited allocation of currency (in this case, sticky dots) that they can use to spend on buying requirements. The key benefit of this approach is that it doesn’t allow the stakeholder to give every requirement a high priority as there will not be enough dots. There is a gaming element to this as you have to consider how the other stakeholders will vote which could influence how you will spend your money.

This approach should not be considered scientific, not least because results can be unpredictable; it is a means of generating discussion and teasing out people’s priorities. It should be used as an input when gaining consensus on real priorities.

The approach is summarised as follows:

  1. Determine how much currency should be allocated to each individual. It should be limited to ensure that some requirements will receive less currency.
  2. Explain the approach and steps to the participants
  3. Allocate the currency. Use different coloured dots for each participant (as far as possible)
  4. Post the requirements on the wall on post its or in some manner that allow each requirement to receive votes.
  5. Ask the participants to place their votes.
  6. Arrange the votes into three groups to represent high, medium and low
  7. Start a discussion about the priorities with any or all of the following:
    Which requirements are low or medium priority which must be delivered? Why are they low priority? (you may agree to move them into the high priority group)
    Which requirements are high priority that should not be high priority?
    Which requirements are almost high priority? Are we happy with them being medium priority? (you may agree to move them)
  8. If any requirements change priority, you should give serious consideration whether there should be a requirement you swap to ensure that you maintain the group sizes

In this article, I have described why requirement prioritisation is important, why it tends to be unsuccessful and one approach to gaining consensus in a group.

Relevant links

Requirement Ranking – No, No, No to High, Medium or Low
Tyner Blain has posted a number of useful articles on requirements prioritisation:

Planning Sprints by ROI

Three alternative techniques

Product segmentation

It's only fair to share...
Share on Facebook3Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

9 Responses to “Prioritising requirements – how to do it and why it is critical to project success”

Read below or add a comment...

  1. Rose Broadbear says:

    I think the authorneed to use spell check more often on the documentation (article). I was very distracted by the grammatical errors in this article. The content was very informative.

  2. TOM GILB says:

    well we agree on need for prioritization of requirements.
    But, I think there are smarter and more dynamic ways to prioritize

    Here is some detail

    Choice and P…
    http://www.gilb.com/tiki-download_file.php?fileId=48

    Mng Priorities

    http://www.gilb.com/tiki-download_file.php?fileId=60

    • Alex P says:

      Tom

      thanks for your comment. I’ve looked at the documents but won’t claim I’ve fully understood as there is clearly a lot to absorb!
      I’d be interested to hear how receptive your clients have been as the highly formalised approach would initimidate or turn off many business representatives.

      Alex

  3. DougGtheBA says:

    That would be exactly the point I was trying to make but…um….forgot to state. Thanks for covering for me.

  4. DougGtheBA says:

    Alex:
    Though it may have been implied, I thought it worthwhile to post an explicit reply….the one thing that I didn’t pick up on in your article is the architect/designer as stakeholder. I learned and have used a technique in which both the tech reps above perform a priortization and so do the business stakeholders. Both sides apply numerical weighting and the combination of biz/tech values that are highest indicates the hipri reqs. Why is this valuable? Because the tech people have an understanding of what reqs will have the most architectural impact if implemented. Hence building one req that is medium for a user yet high for a techie may bring more intrinsic value by describing a larger portion of the app architecture…..so the user gets more functionality earlier and the IT can define tech aspects, and the probs they might encounter with it earlier as well.

    • Alex P says:

      Hi Doug

      I absolutely agree with your comment. I haven’t explicitly mentioned IT architect/designer as stakeholder but their view must always be considered. There is often a degree of technical risk associated with a project and that could be as it is unproven technology, untried in the company or particularly complex. All of these provide reasons for tackling this first. HOWEVER, this is only one of the reasons and, typically, this exercise should start a debate so that consensus is reached by all the parties.
      Ideally, you would deliver requirements that deliver most value to the business AND tackle architectural risk earlier.

      Alex

Trackbacks

  1. […] Dot-voting is a another form of democratised feedback where each stakeholder gets typically 3-5 dots to put against one or more features. It works well when you need to understand priorities at a high level and gets stakeholders to focus on the key priorities. It’s fun way to relate to the stakeholders and have them interact in a positive way. Here’s a good article on dot voting: Prioritising requirements – how to do it and why it is critical to project success. […]

  2. […] being resistant then more formal requirements prioritisation techniques should be pursued. ( see article) There is a strong argument that these should be undertaken anyway to support discussions later in […]

  3. […] have written a post on this subject here and will report back on this meeting if you are unable to […]



Leave A Comment...

*