Cutting through the Requirement Prioritization Nightmare
Requirement prioritization can be a difficult exercise. Often, stakeholders will insist that every requirement is essential, and prioritizing or de-scoping requirements can feel like asking colleagues to part with their most treasured and sentimental personal possessions.
With references to the MoSCW prioritisation framework, here are three considerations that make prioritization significantly easier:
1. Get the foundations right
When prioritization 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 “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 in on a secret: When it comes to prioritization, past project history matters. It is worth finding out how prioritization has taken place in the past but also what has happened to the lower priority “should” and “could” requirements.
In some organizations, stakeholders have been burned in the past—they may have found themselves on projects that were so pressed for time and budget that only the “must” requirements were delivered. 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 prioritization 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. This expectation needs to be set and agreed upon with project stakeholders at all levels.
3. Be bold, and ask the difficult questions
One of the key roles for a business analyst is to ask the difficult questions. Why is a particular requirement important? What would happen if it was not delivered? Would the solution be rejected if this were 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 this question: “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.”
Prioritization can be difficult, but prioritization can be made significantly easier by getting the basics right, being aware of project history, and asking the difficult (but necessary) questions.
