Managing Requirements Risks
The same general frameworks and management plans can be adopted, but a focus on dropping, handing off, changing or maintaining requirements would come to the fore. These approaches align with generic project risk management strategies of
- Avoidance
- Transference
- Mitigation
- Accepting
In the context of requirements risk management I propose narrowing down the management strategies further to subsets of each of the above;
- Dropping a requirements
- Handing off a requirement
- Changing a requirement
- Maintaining a requirement
Dropping/Avoidance
By dropping a requirement you are avoiding the risk that comes with it altogether. You are also dropping the benefits that come with it.
Typically the requirement will be related to delivery issues such as capacity, skills and feasibility, but not always. Risks can also come from the end product being available to operations. For example marketing campaigns to sub-prime borrowers has had a negative impact on many lenders.
When you look to drop a requirement remember to assess the benefits you are forgoing. What does dropping a particular requirement do to your business case? Also what does it do to your stakeholder acceptance of the solution? Don’t take this strategy lightly. A requirement is there for a reason. Dropping requirements requires serious analysis and usually significant communications effort.
Handing-off/Transference
The classic example of risk transference is insurance, but how do you transfer a requirement? If your organisation is mature enough to be managing risks pro-actively there is a good chance it’s managing a portfolio of projects, and many of them are run through a project management office.
Requirements transference can be the process of projects handing one requirement across to another project.
Here is an example; a company wants to offer staff discounts to its employees for the services it sells. At the same time it is deploying a new employee database. Both projects will probably need to call on things such as employee email addresses and phone numbers. One of the projects is going to have to construct an interface with the existing staff email database.
In this scenario there will be uncertainty about the requirement for each project as there will be constraints generated by the other project (for example the availability time.) As a result there is risk. A solution to the risk could be for one project manager to agree with the other to hand the requirement to only one project to manage. This is an example of transference.
Changing/Mitigation
You can mitigate requirements risk by putting something in place that will, if the risk eventuates, minimise the impact of the risk. Requirements risks can be mitigated by identifying compromises to the requirement, or additional requirements that act as fail-safes. Business continuity processes and hardware redundancy are good examples of mitigation plans.
If you have a requirement that presents a particular requirement risk (i.e. it’s a deal-breaker) what can you does to ensure the impact of failure is minimised?
Maintaining/Accepting
And then there are the risks that you can live with. You simply say if it doesn’t work, we’ll live with it, or we’ll deal with it when it happens.
Facebook applications are rife with this type of requirement risk. There are plenty of features that have intermittent failures and the developers have decided to launch anyway and ignore or fix the bugs in production.
Consider this; if you can live with a requirement risk, do you really need the feature? Or at the least do you want to address the error messaging you send people?
Communicating with stakeholders and the project team
You should select your requirements risk management strategy as a result of an analysis and assessment. This should incorporate consultation with the key stakeholders to the requirement. Who does the requirement benefit? Who do the potential changes to the requirement affect? Consultation should be with both the client groups and the development team.
Integrate Requirements Risk Management into Project Risk Management
Don’t forget to include these risks in the project risk register. They should be included for discussion at general project risk management forums, but the requirements manager will probably be doing most of the legwork and analysis to deal with it.
A word of caution - Don’t turn this approach into a full time job for an analyst. Ideally this approach to requirements risk management should be an activity the requirements management or business analyst/team carries into the existing project risk management processes.
Your next steps
Review the project you are on. Look at the requirements and assess whether any of them have brought particular risks to your project? Have they eventuated? Did your project include requirements based risks into it’s risk management processes or were the requirements just accepted as law once the requirements specification was approved?
How would you project have been different if a requirements risk management process had been run? Would addressing requirements risk be useful to you?
About the Author
Craig Brown lives and works as a Project Manager and Business Analyst in Melbourne Australia.
In 2007 Craig launched a web based business at providing web based property reports at www.evaluator.com.au. This was the second business Craig started; the first was a family legal practice, Erina Legal where his mother and brother still work.
Craig’s extra-curricular interests include his lovely wife Charlotte and son Henry and writing on project management and business analysis. Craig is an active contributor to Modern Analyst and runs his own blog called Better Projects.
References
Better Projects on Positive risks
http://betterprojects.blogspot.com/2007/01/positive-risks.html
Wiley Media’s risk checklist
http://media.wiley.com/product_ancillary/01/07821360/DOWNLOAD/Checklist%20of%20CPR.pdf