Requirements Prioritization

From Requirements Management School

Requirements prioritization is a balancing act.

You have to balance customer satisfaction with bringing a project in on time and within budget. An efficient prioritization process ensures the delivery of the most valuable functionality within time and budgetary constraints.

This is not such a big issue on smaller projects where the prioritization can be carried out informally. However on more complex projects with many stakeholders competing for a share of limited resources it can become a challenge.

The biggest issue with prioritization of requirements is that a user is likely to assign their requirements as all high priority! That means that you end up with all requirements being “must haves”. This is a problem because resources are always limited. You need to be able to allocate the resources to meet the most valuable requirements. You cannot do this if they are all classified as “must haves”.

Suggested Prioritization Methodology

So what is the answer to this thorny issue? There are many methodologies available for requirements prioritization. Traditionally the stakeholders provide the prioritization but this in itself is unworkable so another solution is required.

  • A fair initial assessment is carried out to ensure that requirements are grouped into the right categorization. The format for carrying out this process will vary from project to project. All the stakeholders will need to use the same scale and classify the requirements on the following basis (the name of the category does not matter):
    • Must Haves – which are core functionalities; business constraints; legal and regulatory requirements; dependencies and so on. These become top priority and are automatically put forwarded to be included in the initial release.
    • Should Haves – non-core functionality
    • Nice to haves – anything which does not contribute to increase return on investment or customer satisfaction levels.
  • The should haves then become subject to negotiation as to which go into the initial release and which are held off for future releases. Representatives of all the stakeholders usually take part in this process with the project manager acting as facilitator. There are various methodologies that can be implemented to help with this. Here are three commonly used techniques:
    • Questionnaires – A questionnaire would need to be designed and then distributed to all the stakeholder representatives. It would have to be a multiple choice questionnaire. Each answer has to have a score and weighing attributed to it. Once the questionnaires are returned the scores have to be added up to generate the list of priorities.
    • Weighted Criteria – A set of criteria is negotiated with the stakeholder representatives. These may include criteria such as return on investment; service improvement; cost; and feasibility. These criteria are then weighted. Finally the stakeholder representatives assign a score (normally in the range -10 to +10) for each requirement and criteria combination. The scores are then multiplied by the weighting. From these results the priorities list is generated.
    • Group Voting – This is a very informal method which does not work well with long lists of requirements but it is a valid option for some projects. The project manager facilitates a meeting where the prioritization is discussed. The meeting culminates with the stakeholder representatives voting on each requirement. This can be by ballot or by something as simple as placing sticky dots/ticks on a wall chart next to the requirements that they are voting for. Stakeholder representative can be assigned more or less votes depending upon their user class, if required.

Adopting a methodology for requirements prioritization is not optional. It has to be done. The process needs to be as simple as possible and transparent.

Collaborative methods for prioritization will help to achieve consensus and team buy-in while minimizing conflict.