Prioritisation doesn’t have to mean cutting out requirements
Requirement prioritisation can be a difficult exercise. Often, stakeholders will insist that every requirement is essential and prioritising or de-scoping requirements can feel like asking colleagues to part with their most treasured and sentimental personal possessions! In this article I’m going to outline three considerations that make prioritisation significantly easier. I’m going to refer to the MoSCW prioritisation framework throughout the article.
1. Get the foundations right
When prioritisation is difficult, this suggests that there isn’t a shared understanding of the business value and the customer value that the project will deliver. This suggests that the foundations of the project are shaky—perhaps insufficient enterprise analysis took place. In these cases, it’s worth taking a step back and asking “What problem or opportunity are we trying to address here?”. If that isn’t clear, then make sure this is resolved before moving forward. Jeff Patton touches on this in his article How I Stopped Worrying and Learned to Love Prioritization and he underlines the fact that business goals must be explicitly stated.
2. History matters and “should” means “should”
I’ll let you into a secret here: When it comes to prioritisation past project history matters. It is worth finding out how prioritisation has taken place in the past but also what has happened to the lower priority “should” and “could” requirements. In some organisations, stakeholders have been burned in the past… they may have found themselves on projects that were so pressed for time and budged that only the “Must” requirements were delivered. Accordingly, they’ll be extremely reluctant to demote anything to a “should” or “could”, as they may assume that there’s no chance of them being delivered.
If prioritisation works well and fairly, then some “should” and maybe even some “could” requirements will be delivered—depending on the business value they deliver and the cost and difficulty of implementing them. Set this expectation up-front, so that stakeholders are clear from the very beginning that they aren’t relegating requirements to the trash can. This expectation needs to be set and agreed with stakeholders at all levels on the project.
3. Be bold and ask the difficult questions
One of the key roles for a business analyst is to ask the difficult questions. This often involves asking why a particular requirement is important. What would happen if it wasn’t delivered? Would the solution really be rejected if this was the only requirement not met?
Tony Heap proposes a great way of asking this question in a comment he posted on the Bridging the Gap blog. Building on Tony’s comment, it can be useful to ask questions such as:
“If I delivered you a solution with every requirement except this one, and it was going to take another year to develop a feature to meet this requirement, would you wait a year before using the solution?”
If the answer is “yes”, then it’s clearly an essential requirement. The solution is not useful without it. If the answer is “no”, then it may still be a highly desirable requirement but it is not a “must have”.
In summary, prioritisation can be difficult, but this can be made significantly easier by getting the basics right, being aware of project history and asking the difficult (but necessary) questions.
This article was first published on TechWell on October 19, 2012