Setting Requirement Priorities

Many projects are plagued by the phenomena of "scope creep” and some of that creep can be managed by prioritizing your project’s requirements. Scope creep is a problem from the perspective of the project manager and project sponsor because it inflates the cost of the project (more work means more cost) and extends the schedule because the extra work can rarely be done in the original window for the project. If the additional work can be done to the original schedule, the extra costs incurred through overtime or additional resources add additional expenses to the budget. Some scope creep is due to project stakeholders wishing to add additional features or functionality to the project’s product. These additional features may be due to the stakeholder not being engaged properly during the requirements gathering process or due to changing market demands, technology or other influences outside the control of your organization. These new features are actually changes and need to be managed by the project’s change management process, regardless of the source.

The other source of scope creep, and it’s the one I’m talking about here, is the phenomena of estimates for the amount of work increasing as more is learned about the features of the project’s deliverable. Let me illustrate what I’m talking about here with an example. Let’s say you’ve decided it’s time to remodel your kitchen. You’ll leave the original footprint but you’ll replace the existing floor with slate, install new cupboards, replace the existing counter top with a granite one, and replace the existing appliances, taps, and sinks. You can estimate the cost in both materials and labour for all these upgrades and so you estimate a budget and schedule for the job. Everything looks good until you begin the work and find out that the slate floor will require a considerably stiffer subfloor and joist system. The joist system you’ve currently got is 2” by 8” joists on 16” centres. The one you need is 2” by 10” on 16” centres. Now what you’re faced with is beefing up the existing joist system to meet the criteria for the slate floor. You haven’t added any new features (at least from your point of view) but you’ve added considerable work and some materials you hadn’t envisioned when planning the job. The effort required to do the renovation will increase by the amount of effort required to beef up the joist system and the budget will increase by the cost of the new joists. Or you could choose another floor that could be supported by your existing joist system.

Just about any project you undertake is susceptible to this kind of scope creep. No one is asking for new features, but you find out in the course of building your house, refinery, or software system that you’ve overlooked some work that is needed in order to deliver a solution that meets all the goals and objectives stated in the project charter. In fact, this is an especially common phenomenon in the business of building software systems and the less experience the organization has in building systems using the software tools and methods available the more likely they are to experience this kind of scope creep. The addition of work and materials not originally planned could be managed by the change management process but the additional work is not so much a change to the project as it is a correction to the plans. If the additional work and materials change the budget and schedule baselines, the change must definitely be handled by a change request. Another solution must be found where budget and schedule are constrained.

The solution required for constrained budgets and schedules is to eliminate features or requirements so that the remaining work fits within the budget and schedule constraints imposed on the project and prioritizing the requirements as they’re being gathered can make this exercise a "no brainer” as opposed to the political war that is likely to ensue if requirements priorities have not been agreed upon ahead of time. So now that I’ve convinced you of the need for prioritizing your project’s requirements, let me offer some tips and tricks on prioritization.

Requirement priorities can be contentious; the more interest the stakeholder has in the project, the more contentious priorities are likely to be. Projects which have trouble engaging stakeholders will have a different problem: stakeholders are reluctant to give you the time you need to gather their requirements and priorities. Let’s tackle the first situation first. This situation can produce 2 problems: stakeholders disagree on each other’s priorities and some stakeholders will want to identify all their priorities as "must haves”. By the way, these two problems are not mutually exclusive.

Here are some tips on reaching consensus on requirements priorities. First of all, identifying priorities should be integrated into the requirements gathering process, after all the initial set of requirements should fit within the budget and schedule constraints identified for the project so the stakeholders will have to agree on the set of requirements that should be built. Some requirements will make the cut and others won’t. If you make setting a priority for each requirement a part of the process, the requirements will not be complete until a priority has been assigned to the requirement and the set to be built has been agreed upon. A workshop can be an aid to both requirements gathering and to priority setting. The workshop collects all the stakeholders, or their designates, in one room for the purpose of identifying all the requirements. There are two advantages of workshops over other one-on-one methods: the duration of the process is shorter because requirements are identified more or less simultaneously rather than sequentially and a consensus decision can be reached on the priority of the requirement on the spot. If a workshop is not possible some other form of decision making may have to be used. Another approach to decision making is to capture the priorities from the stakeholders but leave the decision as to their priority to the project’s sponsor, or a subject matter expert they designate for the purpose.

There are several ways of assigning a priority to requirements. One is to use a numeric scale, say from 1 to 5 with 5 being the most important requirement and 1 being the least. Another method is to use high, medium, and low or must have, important, and nice to have. The descriptions may make setting the priority easier. You can also weight the priorities by categorizing the requirements. Let’s say you’re building an order management system with components for capturing an order, creating the order, managing the inventory, and reporting. You might rank these components using the same scale as the one you selected for prioritization and then apply these weights to the prioritization scores. Let’s assume that reporting is ranked as a low priority. A high priority requirement for the reporting component would be a high/low priority when weighting is applied and would not be as high a priority as a high priority for an order capture requirement.

Some stakeholders that are passionate advocates for the group they represent may be reluctant to give a realistic evaluation of the relative importance of their requirements. To them each and every one of their requirements is a "high” or "must have” and they may be very reluctant to accept a lower priority. You will need to move them from this stance in order to complete the prioritization process. For one thing their intransigence may influence other stakeholders to take the same approach. If everyone adopts this approach, there is no prioritization. One way of getting your stakeholders to assess their requirements more realistically is to provide them with the roadmap for the future which includes the upgrades that are planned during the lifecycle. This means that even the lowest priority requirements are never discarded; they will go into a queue with the other lower priority requirements and new requirements and will be reconsidered for the next iteration of the product.

Prioritization is done for the purpose of determining which requirements will be developed for the first iteration of the project and determining which requirements will be jettisoned first if you discover the identified requirements require more work than the budget can afford for the first iteration. Let’s assume that you’ve identified the requirements that can be developed for the project and have approved the scope, budget and schedule based on those requirements. Now you’re developing your product and discover that you’ve underestimated the work required for a requirement either due to an unrealistic estimate or because you failed to identify all the work required. You’ve also determined that there is no appetite for increasing the budget to pay for the additional work or for increasing the schedule to accommodate the additional work. You might do this by initiating a change request or by simply asking the sponsor. Your alternative is to eliminate work from the project so it fits within the budget and schedule constraints and this is where prioritization goes to work. You’ll begin by dumping the lowest level priorities; again these are not simply eliminated they will go into the queue for the next upgrade. By this time, estimates should be refined enough so that you know exactly how many lower priority requirements must be dumped before the project fits within the constraints again.

There is an alternative to simply dropping a requirement. You could revisit the requirement and the features required to deliver it; sometimes by altering those features, the original requirement can be met within the budget. Let’s look at our floor example. You want a slate floor because of the way it looks, not because of its weight or rigidity. There is a multitude of excellent stone substitutes available including imitation slate. These substitutes tend to look like slate but are lighter and less brittle so it is possible that a slate substitute could provide the "look” you want and be light enough to use the existing joist system. By taking a little closer look at a requirement it may be possible to identify a different way of delivering it that requires less work, less costly materials, or both.

The last step is to implement the change in project scope properly and you’ll need a change request to do this. The change request will ask that the identified excess requirements be removed from the plans and the change management process will identify the work necessary to remove the requirements and the necessary changes to the plans. Approval of the change request should not be controversial given that the stakeholders have already agreed on the requirements to be removed by prioritizing them. Once the request has been approved, you need to inform all the stakeholders of this change in scope. Don’t forget to identify the reason for the reduction, how the requirements to be removed were identified, and what will happen to the removed requirements. The scope reduction will be an easier sell if you can tell affected stakeholders that the requirement you removed will be added to the queue of requirements for the next release of the product.

Now that we’ve explored all the nuances of prioritizing requirements and why they should be prioritized I’ll lay out 8 tips and tricks for making prioritization work for your project.

1. Make requirements prioritization a part of your requirements collection process. Remember that if you don’t have a document describing the process, you don’t have a process.
2. Identify the decision making method for choosing a priority for each requirement. This could be a consensus amongst stakeholders, an executive sponsor decision, or some other method. Make the method clear to the stakeholders.
3. Choose a workshop to identify and prioritize your requirements where timelines are tight. Workshops are not only a quick way to collect requirements; they are almost mandatory where a consensus decision is required.
4. Capture the priority with each requirement and also the stated reasons for the priority.
5. Make acceptance of the priorities, as well as the requirements, a gating criteria.
6. Look for alternative ways of delivering a requirement for less cost before dropping it.
7. Identify each requirement and associate it with its supporting features in the project’s design and test documentation. This makes removal of the requirement much easier.
8. Use your project’s change management process to manage the removal of requirements from the project scope.

Using these tips and tricks won’t guarantee you won’t be victimized by scope creep, but they will eliminate one of the major causes of it and it. It will also show your sponsor and stakeholders that you have a well thought out approach to ensuring your organization gets the maximum benefit for their project dollars.