Prioritizing Requirements – Everybody does it but often too late.
We always prioritize when we are getting close to the delivery and find not everything works or when someone appears with a “more critical than anything else” requirement in the middle of development.

Without prioritization, when changes occur we have much less leeway on how we will proceed and may have to drop some of our previous “must have” requirements or, worse yet, not meet the schedule or budget constraints. All of these outcomes will adversely affect the customer’s expectation and the delivered product.

How much better if we had planned ahead and based our development on priorities.  When budget or schedule problems occur, the important requirements will already have been included.  When change happens we’ll know what to do, because we agreed ahead of time on a descope plan based on priorities and were not in crisis mode.

Prioritization helps you manage your requirements and your resources.
This includes people, time and budget.

Prioritization also helps manage the unknown unknowns. 
A key part of requirements management is managing change.  What happens when a new “must have” requirement is added to your requirement set?  Given you have a fixed budget and defined schedule, this addition could result in you having to eliminate one or more other requirements in order to accommodate the new requirement.  With prioritization, the requirements that would be candidates for elimination are those that are lower priority than the one being added. With prioritization we can intelligently schedule work so when a new “must have” requirement comes along or schedule and budget cuts occur we can easily accommodate the changes because we made the hard decisions up-front.

With prioritization, you improve communication because you’re taking the guesswork out of the project.
What will be delivered and what may be traded if problems or new requirements arise. When budget or schedule problems occur, the important requirements will already have been included.  When change happens we’ll know what to do, because we agreed ahead of time on a descope plan based on priorities and were not in crisis mode.

With prioritization, people tend to rethink their requirements.
When assigning priorities, often they discover some requirements are not really needed or are not feasible and can be removed from the requirement set.  Cost/schedule are primary considerations.  As much as we may want something and as important as we think it is, when confronted with the cost or time for implementation and resulting overall impact on the product delivery, we may conclude it isn’t worth it when compared to other requirements.  Thus as a result of thinking about priorities,  we may now want to delete the requirement as not being feasible or we really don’t think it is a important as we once thought it was as compared to other more desirable (higher priority) requirements. Alternately, we may make keep the requirement but make it a low priority or a goal with the understanding it will only be implemented if it doesn’t jeopardize the cost and schedule constraints and doesn’t take resources away from higher priority requirements.

Prioritization is also helpful when releasing software in phases. 
If your project is such that you can deliver your software in increments, prioritization helps you determine what to include in each release.  Highest priority requirements in release 1, lower requirements phased in in subsequent releases.

Closing thoughts:

• Priorities can help you plan and manage your work better.
• Priorities can help you respond to surprises and the resulting changes that occur.

Read more about How to Prioritize Requirements