Requirements Risk
I have a hypothesis I want to explore:
Requirements Risk management could be a useful approach to requirements analysis, and lead to better requirements management.
High level the idea goes like this:
- Risk management is an important part of project management
- Requirements management is also a critical part of the puzzle
- Should we be running a requirements risk management process on our projects?
The purpose of this article is to introduce the topic of Requirements risk into the Requirements Management discussion. Feedback and commentary is welcome and can be provided at ModernAnalyst.com
Serious projects run risk management processes throughout their lifecycle. In fact, risk management is one of the nine knowledge areas of the PMI’s PMBOK, and one of several key processes in the (British) OGC’s P3M3 project, programme and portfolio management framework.
PM bodies obviously take risk management seriously, and it’s backed up by the academics. Studies are showing that a structured approach to risk management has a correlation with successful project delivery. Risk management is a vitally important part of project management.
I don’t need to explain the problem of requirements again. There are plenty of articles on the web about how poor project requirements management costs billions of dollars and lead to disappointment everywhere. Of course the best way to manage requirements is to put trained and experienced people on the job. Building up the knowledge areas and processes will also support the need to improve requirements management.
[Read more here for a risk management approach you can use for your projects.]
What are Requirements Risks
Requirements risks are risks that are associated directly to specific requirements. The inclusion or addition of a risk can have a number of impacts on a project’s risk profile.
Certain requirements may open up risks of regulatory non-compliance, legal issues, PR issues, unexpected costs or process bottlenecks and so on. In this case each requirement comes with a cost-benefit-risk profile, and each of those aspects need to be considered when analysing requirements.
Requirements can also have an impact on a project’s capacity to deliver on its objectives. Consider an overworked project team which are asked to add on a few more features.
The project should have a change control process to manage the change to the scope of work and the process should consider risks to the project that will come up as a result of accepting the new requirement. Will the new requirement cause cost or schedule over-runs? How will they be perceived by stakeholders? Will it affect the quality of the solution? Do people really have enough capacity to take on the work required to properly consider the analysis and design aspects of the new requirements, and so on.
Positive Requirements Risks
Risks aren’t just negative. The PMI has considered this issue at length and now accepts that risks are uncertainties about the future; they can be positive or negative, depending on how you view the outcomes.
Project requirements can bring a number of positive risks as well as negative risks. For example your project is changing the internal landscape of the organisation, and as things change new opportunities arise.
If you are the first successful agile project you may change the culture of project management in your organisation for the better. If you deliver a new system it may be able to be used to extract non-business cased benefits.
These examples are at the project or product level, but the same principles can be applied to requirements.
A requirement to create a new interface to a database or system opens that interface up for other uses, a new business process can be leveraged for further process improvement opportunities, or a new website design could become a new standard for a whole range of sites or pages.
[You can read more about positive risks here.]
An example of Positive Requirements Risks
Project requirements can bring a number of positive risks as well as negative risks. For example your project is changing the internal landscape of the organisation, and as things change new opportunities arise.
If you are the first successful agile project you may change the culture of project management in your organisation for the better.
If you deliver a new system it may be able to be used to extract non-business cased benefits.
An example of Negative Requirements Risk
Stakeholders are not engaged properly or early enough, and so deliver poorly articulated statements of requirements, and upon receiving requirements from the BA for validation, reject them as incomplete or incorrect.
More examples of Negative Requirements Risks
- Changes to the regulatory or legal environment may be coming down the pipeline causing existing requirements to be come obsolete.
- Requirements may be overly complex leading to a risk of poor understanding by the development team.
- Insufficient time may be allocated to requirements gathering and definition resulting in gaps or errors in requirements
Reflect on your existing project: What risks are presented by the requirements you are managing?
[Wiley Publishing provides a checklist of project risk areas here.]
... continued on Page 2.