I’ve recently been involved in a discussion on how to better prioritise requirements. It’s an important topic because the requirements prioritisation process can get rather lengthy,and it’s good to speed it up.

The discussion focused on the difficulties with getting business stakeholders to agree on the requirements priorities because all stakeholders “naturally” have different priorities.

Why is it the case? It happens mostly because stakeholders believe that their requirements are in the “must have” category. They are concerned about the solution mostly from their perspective and often lack a holistic view on the solution.

Is there a way to resolve this issue? I looked back on my past projects and the lessons I learned from those projects to find an answer. I think that I manage prioritisation in an effective manner.

When project timelines are short and financial resources are limited, you want to make sure the project will deliver the most essential solution to the identified problem.

Allocating relative importance to the requirements lets you sequence project execution and solution delivery to provide the greatest added value at the lowest cost.

It is well known amongst business analysts that it is difficult to get one stakeholder to decide which of his business requirements are the most important. It is even more difficult to gain an agreement among multiple stakeholders with diverse expectations.

Stakeholders have a tendency to pursue their own interests and most of the time they are not willing to compromise their needs for someone else’s benefit. However, making decisions on priorities of the requirements is one of the stakeholders’ responsibilities.

The prioritisation matrix is meant to facilitate the process of ranking requirements. It’s divided into several areas. First, a solution has to be split into functional areas (which may be associated with use cases). All of the functionality within each functional area then has to be split into three distinct categories:

  • Must (the foundation of the solution),
  • Should,
  • Nice to have.

The boxes at the bottom should contain cost estimations for each of the three categories. This information is required to facilitate discussion about balance in priorities of requirements allocated to the three categories.

The next step is to assign a priority for “should” and “nice to have” requirements. The most important requirements go to the top (P1), while less important requirements accumulate at the bottom (P5).

It’s important for everyone involved to understand that the “must have” requirements form the basis for the solution, while “should have” and “nice to have” requirements can be a source of added value – but not necessarily so!

Armed with cost estimates and priorities of the requirements in these categories, you’ll be able to see whether the value provided by implementing them is actually going to justify the costs.

Once the matrix is filled out in collaboration with business stakeholders, you have full visibility of requirements within the selected functional area, their categories and relative weight, as well as total costs for each category.

When the priorities are finalised, it may be useful to further rank requirements within each priority level by the order of implementation. This information is important to the project manager and software developers responsible for building and delivering the solution.

Click on the image to download the matrix in PDF format:


Download PDF

Summary

The matrix above can be used either for the whole solution (when it is not large) or for functional areas within the large solution. Positioning of the requirements within the matrix facilitates discussions and justification of priorities of the requirements with multiple stakeholders.

It also helps both the project team and business stakeholders to make informed decisions about the functionality of the solution, added value, costs and implementation order.