Prioritising requirements - how to do it and why it is critical to project success
This 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:
- Determine how much currency should be allocated to each individual. It should be limited to ensure that some requirements will receive less currency.
- Explain the approach and steps to the participants
- Allocate the currency. Use different coloured dots for each participant (as far as possible)
- Post the requirements on the wall on post its or in some manner that allow each requirement to receive votes.
- Ask the participants to place their votes.
- Arrange the votes into three groups to represent high, medium and low
- 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) - 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:
(No Ratings Yet)
Loading ...
Email This Post
