As Business Analysts, we deal with requirements prioritisation nearly every day. Prioritising requirements is an excellent way of ‘drilling down’ and understanding the real critical success factors which apply to your project, and it’s a great way to help with scoping.
The trouble is that stakeholders are often incredibly bad at prioritising. This is one area where we can add a huge amount of value, by clarifying and facilitating their thoughts.
Much has been written about prioritisation, however here are 3 “Quick Tips” that I find personally useful whenever I’m working to prioritise requirements.
1. Flip the “But”: A great way to ‘test’ the relative priority of a requirement is to look out for the word but when a stakeholder is talking about their needs. For example, a stakeholder might say something like:
“It would be incredibly beneficial for xyz document to be made available to our staff in Singapore, but it’s likely to be extremely expensive”
At first glance, this sounds like a low priority requirement and you could certainly be forgiven for categorising it as such! However, in this example, the priority will actually depend on the stakeholder’s appetite for budget. A great way to test this is to ‘flip the but’ and play the sentence back.
“Ok, are you saying that it’s likely to be expensive but you’d like the xyz document available in Singapore? Or are you telling me that this is a low priority requirement?”
This will give you a good feeling for their attitude towards the requirement.
2. Check the consequence/benefits: Ask your stakeholders what would happen if this requirement wasn’t included in the final implementation. What would the impact be? Would it reduce sales, increase processing time?
On the flip side, what are the benefits of including this requirement? Even a high-level understanding of these consequences can be incredibly useful when prioritising. Clearly, those requirements that have most benefit (or most impact) should be the highest priority, providing these contribute towards the objectives of the project.
3. Have a plan for Medium/Low requirements: We’ve all seen projects that are de-scoped to an inch of their lives, where only the “highest” priority requirements are delivered. This is totally understandable, but in some cases it might leave operational stakeholders with an extremely sour taste in their mouth!
If you can, always consider having a plan for Medium/Low requirements (e.g. will they be implemented in phase 2, or perhaps stored in a ‘wish list’ for future developments?). By sharing this with your stakeholders it can help avoid the temptation for all requirements to be stated as “Essential” (as they are fearful that any other requirements won’t be delivered!).
There are many other tools and techniques that can help when prioritising, but these are three that I have used time and time again. I hope that you will find them useful!
Do you have any ‘favourite’ tools or techniques? If so, please share them by responding to this post!
This article was originally published by Adrian Reed on Pragnalysis.com, a site dedicated to Business Analysis in the real world, and more importantly, home to an entirely free requirements toolkit.