Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product (at least, not if they want the features to work). However, if the development team cannot deliver every requirement by the scheduled initial delivery date, the project stakeholders must agree on which subset to implement first. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements.

A project manager has to balance the project scope against the constraints of schedule, budget, staff resources, and quality goals. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and urgency, the project manager must make these trade-off decisions. Because customers may not agree with the project manager’s decisions, they must indicate which requirements are critical and which can wait. Establish priorities early in the project, while you have more options available for achieving a successful project outcome.

It’s difficult enough to get one customer to decide which of his or her requirements are most important; gaining agreement among multiple customers with diverse expectations is even more challenging. People naturally have their own interests at heart and they aren’t always willing to compromise their needs for someone else’s benefit. However, making such priority decisions is one of the customer’s responsibilities in the customer-developer partnership.

Customers prioritize requirements initially from the perspective of how valuable each one is to them. Once a developer points out the cost, technical risk, or other trade-offs associated with a specific requirement, though, the customers might decide it isn’t as essential as they thought. The developers might also determine that certain lower priority functions should be implemented early on because of their impact on the product architecture. When setting priorities, you need to balance the business benefit that each function provides against its cost and any implications it has for the product’s architectural foundation future evolution.

The knee-jerk response to a request for customers to set priorities is, "I need all of these features. Just make it happen somehow." This doesn’t help. It can be difficult to persuade customers to set priorities if they know that you may never be implement low priority requirements. A developer once told me that priorities are unnecessary, because if we wrote something in the software requirements specification (SRS), we intend to build it. However, that doesn’t consider the issue of when you should implement each function. Developers may not wish to bother with priorities, because that conflicts with the "we can do it all" attitude they want to convey to their customers and managers.

The reality is that some features are more essential than others. This becomes apparent during the all-too-common "rapid descoping phase" late in the project, when lower priority features are jettisoned to ensure the product is shipped on schedule. Setting priorities early in the project helps you make those trade-off decisions along the way, rather than in emergency mode at the end. Getting a feature half-developed before you determine that it’s low priority is wasteful and frustrating.

If left to their own devices, customers will set perhaps 85% of the requirements at high priority, 10% at medium, and 5% at low priority. This doesn’t give the project manager much to work with. Steve McConnell identified requirements scrubbing—eliminating those that are not essential and simplifying any that are unnecessarily complicated—as a best practice for rapid software development (see Rapid Development, Microsoft Press. 1996).

On one project I know of, the management steering team became impatient when the analyst insisted on prioritizing the requirements. The managers pointed out that they could often do without one feature, but another feature may need to be beefed up to make up for the omitted requirements. They reasoned that if they deferred too many requirements, the resulting system wouldn’t achieve the revenue that the business plan promised. When you evaluate priorities, look at the connections and interrelationships among different requirements and their alignment with the business requirements.

Follow eight steps to use this prioritization model.

Step 1. List all of the requirements, features, or use cases that you wish to prioritize in a spreadsheet; we’ll use features in this example. All of the items must be at the same level of abstraction. For example, don’t mix individual requirements with product features. If certain features are logically linked (that is, you would only implement feature B if feature A were included as well), include only the driving feature in the analysis. This model will work with up to several dozen features before it becomes unwieldy. If you have more items than that, abstract related features together to create a more manageable initial list. You can do a second round of analysis at a finer granularity of requirements detail if you need to.

Step 2. Estimate the relative benefit that each feature provides to the customer or the business on a scale from 1 to 9, with 1 indicating very little benefit and 9 being the maximum possible benefit. These benefits indicate alignment with the product’s business requirements. Your customer representatives are the best people to judge these benefits.

Step 3. Estimate the relative penalty the customer or business would suffer if the feature is not included. Again, use a scale from 1 to 9, where 1 means essentially no penalty and 9 indicates a very serious downside. For example, failing to comply with a government regulation could incur a high penalty even if the customer benefit is low, as would omitting a feature that any reasonable customer would expect, whether or not they explicitly requested it. Requirements that have both a low benefit and a low penalty add cost but little value; they may be instances of gold plating.

Step 4. The Total Value column is the sum of the relative benefit and penalty. By default, benefit and penalty are weighted equally. As a refinement, you can change the weights for these two factors. In Table 2, all benefit ratings are weighted twice as heavily as the penalty ratings. The spreadsheet totals the feature values and calculates the percentage of the total product value provided by these features that is attributable to each feature.

Step 5. Estimate the relative cost of implementing each feature, again on a scale ranging from a low of 1 to a high of 9. The spreadsheet will calculate the percentage of total cost for each feature. Developers estimate the cost ratings based on factors such as the requirement complexity, the extent of user interface work required, the potential ability to reuse existing designs or code, and the levels of testing and documentation needed.

Step 6. Developers estimate the relative degree of technical or other risk associated with each feature on a scale from 1 to 9. An estimate of 1 means you can program it in your sleep, while 9 indicates serious concerns about feasibility, the availability of staff with the needed expertise, or the use of unproven or unfamiliar tools and technologies. The spreadsheet will calculate the percentage of the total risk that comes from each feature.

By default, cost and risk are weighted equally, and each carries the same weight as the benefit and penalty terms. You can adjust the cost and risk weightings in the spreadsheet. In Table 2, risk has one-half the weight of the cost factor, which has the same weight as the penalty term. If you don’t want to consider risk in the model, set the risk weighting value to zero.

Step 7. Once you enter the estimates into the spreadsheet, it calculates a priority number for each feature. The formula for the Priority column is: priority = value %/ (cost % * cost weight + risk % * risk weight).