One of the first tasks you encounter on any Project Management Professional (PMP)^© training course is Project Scope Management. Within this knowledge area, probably the most important process is Collect Requirements. While the Guide to the Project Management Body of Knowledge (PMBOK^© Guide) advises us to ensure all our requirements are testable and measureable, it is less forthcoming about what we should and should not include in our requirements list.

On this page:

• The Benefits of Requirements Triage in Project Scope Management
• Agile Thinking and Prioritization in Requirements Negotiations
• Stakeholder Management and Addressing Resistance in Requirements Prioritization
• Integrating Risk Management and Triage for Effective Requirements Management

The Benefits of Requirements Triage in Project Scope Management

In the software world, there has been a tendency to tie customers down to a contract at the start of a project. The customer is left in no doubt that they must specify everything they need up front, because change is disastrous. This leads to over-specified products, featuring a lot more functionality than is necessary. But how can we do better?

Over ten years’ ago now, Al Davis proposed the idea of requirements triage. This idea came from the medical world where emergency situations lead to more casualties than medical teams can cope with. In these situations, every incoming patient is quickly assessed and put into one of three categories: (1) will recover without assistance, (2) will most likely die with or without assistance and (3) is likely to recover if given assistance. The medical staff will only work on the third group.

Applying this reasoning to requirements involves getting the stakeholders to assess the requirements list in this fashion. However, the triage approach now consists of three different lists: (1) those requirements that are obvious candidates for inclusion, (2) those requirements that add little or no value and (3) requirements that may or may not benefit the product.

Agile Thinking and Prioritization in Requirements Negotiations

Davis proposed concentrating the requirements negotiations on that third group. He also suggested prioritizing requirements (agile project managers will be familiar with this idea). The must-have requirements go to the top and the bells and whistles style requirements go at the bottom and the rest go in the middle. The goal is to identify a subset of the product’s requirements that gives the best chance of success.

He offers more useful suggestions: (1) Identify dependencies between requirements and bunch these together. If the bunch contains a must have requirement, then they all should be included. (2) Estimate the time and resources needed for each requirement. This allows the developing company to provide costing information for each requirement (or requirement bunch). This can prove very effective. Some nice-to-have features can rule themselves out by simply being too expensive.

While reading this proposal (in IEEE Software, volume 36, issue 3), you can see elements of agile thinking. He recommends a set of releases, rather than one big bang, arguing that stakeholders are happier with the idea of their pet requirements going into a later release, rather than being asked to abandon them altogether. Significantly, he insists that the requirements list must be revisited after every delivery and the goals of the next release are agreed again. This allows for change and also reflects the customer’s experience of the earlier deliveries.

If you have studied for the PMP^© exam, you will be pleased to see mention of optimistic, pessimistic and realistic (although PMP^© courses will use the term most-likely instead of realistic). But unlike the PMP^© training, these optimistic, pessimistic and realistic categories refer to stakeholders, rather than estimates. Davis argues that optimistic stakeholders have an unrealistically sunny disposition and will expect all their requirements to be met in the given time.

Stakeholder Management and Addressing Resistance in Requirements Prioritization

On the other hand, pessimistic stakeholders will regard the whole venture as impossible and will have to be persuaded that something worthwhile will emerge at the end of the project. Essentially, as the PMPs^© among you will have realized, project managers need to practice Project Stakeholder Management. Indeed, getting stakeholders to prioritize their requirements is very difficult. They tend to push back and say they want everything in the list – otherwise they would not have put them on the list. To get around this resistance, it is useful to involve the stakeholders in your risk identification effort (remember Project Risk Management from your PMP^© course?) and let them know that there are things that can go wrong with development.

Integrating Risk Management and Triage for Effective Requirements Management

For instance, a very important requirement, one that everyone has agreed should be at the top of the list, could encounter serious issues. Preliminary investigation shows a huge difference between the optimistic and pessimistic estimates. If the risks materialize, then that one requirement could soak up most of the resources available for the first release. If this happens, what requirements should be pushed into the second release? By presenting this sort of scenario, stakeholders should see the purpose of the triage exercise and be more forthcoming in what their real requirements are.

For more information on Project Scope Management and the other project management knowledge areas, please consider one of our PMP^® Exam Preparation courses. These are held online in our virtual classroom. Find out more by visiting our training page or by contacting us directly.