Must-Have vs. Nice-to-Have Requirements
By Jessica Popp

In addition to checking for solid requirements using the SMART methodology it is important to properly prioritize or categorize the project requirements. This can become especially critical in the large project or project with seemingly unrealistic expectations. There are many ways to categorize these; personally I like to apply the easily understood labels of must-have and nice-to-have.

This method is easily understood by the customer and provides the project manager with a significant amount of latitude for negotiation later in the project, the importance of which cannot be underestimated.

So the way it works is quite simple. After all of the requirements have been recorded, the list is re-visited with the customer to specify each requirement individually as must-have or nice-to-have.

• Must-Have: this is any requirement that absolutely has to be delivered for the project to be considered successful. This helps create the base set of expectations with the customer. These are sometimes also known as critical, base, or minimum requirements or a host of other names that indicate their status as absolutely required.

• Nice-to-Have: these are the complement of objectives or requirements that are considered desired or even important to the overall deliverable, but can be considered as optional or nice-to-have in the overall completion of the project. These may alternatively be classified as optional, non-critical or auxiliary requirements.

This exercise may seem trivial and unimportant, but its importance cannot be underestimated. It provides additional information to the project team of the relative importance of requirements and is often the first time the customer has really thought about the difference between the requirements that are critical and those that fall under the category of bells and whistles. Let’s look at an example.

In the case where a customer needs a new report we’ll list 3 must-have and 3 nice-to-have requirements.

Must-have

• The sales report shall be available online the first business day of each work week by 9 AM MDT.
• The sales report shall contain sales data by store for the previous week (Sunday-Saturday).
• The marketing report shall include the fields (store id, total sales revenue, total cost of good sales, gross margin).

Nice-to-have

• The total sales number shall display in green if (current week sales > prior week sales).
• The total sales number shall display in red if (current week sales < prior week sales).
• Each individual data column (store id, total sales revenue, total cost of good sales, gross margin) shall be able to be sorted in ascending or descending order.

Categorizing requirements by must-have and nice-to-have is not intended as a way to not have to deliver on requirements. In the ideal scenario, the project team will deliver all 6 requirements. The value in the nice-to-have requirements is all about negotiating to fulfill the customer’s request in the best way possible.

The simplest approach is to provide the customer a project cost and completion timeline of the must-have and nice-to-have requirements separately. This allows the customer to make an informed decision to get the most out of their request. Below are two examples:

• Cost/ Timeline – The project team estimates that they can deliver the first 3 requirements in 2 weeks and all 6 requirements in 7 weeks. If the customer is in a hurry they may request to have just the first 3 requirements fulfilled on.

• Determining Expensive Requirements – Again the estimate for the must-have is 3 weeks and all 6 requirements in 7 weeks. By probing the customer learns that the most expensive requirement is the color-highlighting of the data (2 weeks of effort) because of the amount of effort needed to access this additional data and it is not readily available. The customer re-negotiates to receive all other remaining requirements for a 4 week effort.

Hopefully it is clear from this simplified example the value of the exercise. The goal here is to maximize the value for the customer. In these examples, the additional information along with the categorization of the requirements allows the customer to make the best decision for their project.

Consider a project with tens to hundreds of requirement and delivery estimates in the months-to-years time frame. This exercise can be extraordinarily valuable in prioritizing the requirements and helping the customer to understand which of their requirements are absolutely required. Its amazing when you ask customers to participate in this exercise what an eye-opening experience it can be:

Customer: “Yes we absolutely have to have this data available 24 hours a day with no down-time on the weekends.”

Project Manager: “What if I told you that we would have to buy double the hardware at a price tag of $50,000 to keep the data up over the weekend since normal backups require 2-4 hours of down-time per week.”

Customer: “So you’re saying that we would pay $50,000 extra to cover a weekend downtime window.”

Project Manager: “Yes, because the system would normally be available 24×7 M-F; but we can’t guarantee uptime over the weekend unless we buy a backup set of hardware.”

Customer: “OK- Monday-Friday 24×7 is the must have requirement. The rest is nice-to have.”

In this example, you could (and it’s recommended) still characterize the nice-to-have requirement as part of the overall recording of the requirements to fully capture the requests of the customer. During the project you will document that either this requirement is removed (often placed in a list of “dead” requirements) because of cost or on the off-chance that hardware costs come down, or there are other opportunities to provide availability over the weekend you should keep the requirement until you are sure of its destination.

Jessica Popp is a practicing project manager in software engineering. She has more than 13 years experience in software development, project management and people leadership in both Fortune 500 and startup companies. She has a wealth of hands-on project experience from the smallest project to projects whose budgets exceeded $50M per year. Jessica holds a BBS in Information Systems, an MS in Decision Sciences and has a current PMP certification. Jessica runs Project Management 101, a blog dedicated to disccussing various topics about Project Management.