Techniques for prioritizing requirements

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.

Advertisement

These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:

As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.