5 Steps to Master Requirements Prioritization

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel

Recent Posts

Move Beyond Herding Cats

Strategy In a VUCA World—Part 2

Strategy In a VUCA World—Part 1

Just Ignore the Trends—and Run to the Noise

The Brexit Effect—Deal With It

Requirements prioritization is a recognized project management practice. It's a decision-making process that enables project managers to focus on the deliverables that add the most value to a project's outcome.

It is quite rare that projects are conducted without time, scope and budget constraints. Most projects will likely need requirements prioritization.

Sometimes the prioritization process can lead to conflicts between the project beneficiaries. You might have to scope in requirements that address one person's needs, while de-scoping other requirements that address someone else's needs.

This five-step approach can help a project manager master requirements prioritization without getting into conflicting situations:

1. Prioritize as a common practice
Make it clear from the beginning that requirements prioritization is a common and required practice for any project that deals with constraints. Without prioritization, a constrained project could fail to reach its objectives.

2. Involve stakeholders
Not everyone on the project team should be involved in prioritizing requirements, but not involving the right people in this decision-making process could lead to project conflicts or missed project objectives.

The project's beneficiaries -- such as product owners, end-users or business departments -- should prioritize their own requirements. But project sponsors or organizations outside the project, such as legal departments, can be involved in your prioritization process.

3. Qualify requirements    
Identify and apply key qualitative dimensions that support prioritization, such as priority, severity, urgency, complexity or mandatory requirements. Then identify and apply key quantitative dimensions, such as weight or grades.

Use numbers to reflect the possible grades for each qualitative dimension. For example:
  • 0.1 = low
  • 0.5 = medium
  • 0.8 = high
  • 1 = critical
Then, depending on the project's nature and context, use factors that weigh the importance of a qualitative dimension as compared to the others. For example:
  • Factor 0.2 for complexity
  • Factor 0.4 for priority
  • Factor 0.7 for urgency
  • Factor 1 for severity
4. Use a prioritization formula   
Based on the qualitative and quantitative values, define a formula or matrix to apply when prioritizing requirements.
For example, a requirement with high severity will get a 0.8 rating (0.8 x 1) and will be prioritized ahead of a requirement with a high urgency (0.8 x 0.7= 0.56)

5. Document the approach
Document the prioritization approach in the requirements management plan as part of the project management plan. This leaves no room for interpretations, doubts or subjective biases during the prioritization process.

How do you prioritize requirements on your projects?

Posted by Marian Haus on: October 18, 2012 03:47 PM | Permalink

Comments (3)

Please login or join to subscribe to this item
This is a great innovations and from the look of things I think this will be better for me,Am an undergraduate student of Quantity surveying and I want to ask if I can be opportune to be part of this PMI institute.I really love the work of a project manager because I have worked with one and I am using this opportunity to ask how to go about it if I really want to be a project manager

Rich Wheeler
The article has severe flaws. Sample: The example at the end of section 4 compares the severity of one requirement to the urgency of another. Apples and Oranges! The method I show below corrects such problems. A. One can use the same basic approach for any decision such as prioritizing projects, risks, or which car to buy your daughter. B. I have rewritten sections Sections 3 and 4, with comments in square brackets. 3. Rate requirements (a) Identify key qualitative factors that support prioritization, such as severity, urgency, ROI, authority, and risk. [- We don't need to include "priority" as a factor in determining priority! - "Authority" is my alternative to "mandatory requirements." If it is not mandatory, it is not a requirement. However, one can rate the authority of the requirement's source and rate how it is stated. For example, a contract may state preferences that carry less weight than "shall" statements. And most importantly, "authority" makes for better grammar. ;-) ] Assign numbers and define criteria to reflect the possible scores or grades for each factor. For example, for urgency: 1 = We can do this during contract closure. 5 = Due at the end of the next phase 8 = Due at the end of this phase 10 = You need it WHEN??? (Don't forget to upgrade these as the project progresses!) or for risk: 1 = "You want WHAT?" 5 = Medium 8 = Low 10 = "It's in the bag." [I prefer integers over decimals. Call it, "typographical risk control."] Now grade or rate each requirement against each factor. (b).. Prioritize the qualitative factors and assign weights to them. For example: 2 Urgency 3 Severity 5 Risk 8 ROI 10 Authority 4. Calculate the priorities For each requirement, the weighted factors equal the products of the factor grades and the factor weights. A requirement's priority is the sum of its weighted factors. Example: The PM decides that only urgency and risk distinguish the requirements. She rates the factors as follows: - Urgency weight = 10 - Risk weight = 5. She also rates each requirement against the qualitative factors. Requirement 12 urgency grade = 8 Requirement 23 urgency grade = 5 Requirement 12 risk grade = 5 Requirement 23 risk grade = 8 Now she calculates the priority for each requirement: Requirement 12 Priority score = weighted urgency + weighted risk = (8 x 10) + (5 x 5) = 105 Requirement 23 Priority score = (5 x 10) + (8 x 5) = 90 Requirement 12 has the higher priority.

Marian Haus
Richard, thank you for the constructive feedback and the suggested alternate approach. Allow me to clarify a few wording aspects. On the "priority" as a factor – I see this factor equivalent to “importance”. I prioritize requirements based on their importance (or business priority), criticality, time-urgency, complexity and last but not least whether they are “must haves” (i.e. mandatory). Now, regarding “authority” vs. “mandatory” I prefer the later. I see the term “mandatory” synonym with “must-have”. “Authority” is a relative term, can be subjective and can even have negative connotations (how does this sound “this requirement is in because the boss said so; no need to argue further”?) One more thing: regarding the comparison in section 4, this is not a severity vs. urgency comparison. It is a total scores comparison of requirements that have certain severity and urgency grades.

Please Login/Register to leave a comment.


"If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late."

- Henny Youngman