Most software engineering projects are risky because of the range of serious potential problems that can arise. The primary benefit of risk management is to contain and mitigate threats to project success. You have to identify and plan, and then be ready to act when a risk arises—drawing upon the experience and knowledge of the entire team to minimize the impact to the project.
Software Risk management includes the identification and classification of technical, programmatic and process risks, which become part of a plan that links each to a mitigation strategy. The project manager monitors risk during the project. If any materialize, a specific owner implements a mitigating action. In this article, we explain the elements of an effective software risk management plan and provide examples of plan elements.
After cataloging risks according to type (technical, project, process, organizational), the software development project manager crafts a plan to record and monitor these risks. As part of a larger, comprehensive project plan, the risk management plan outlines the response that will be taken for each risk—if it materializes. The core of the risk management plan is the risk register, which describes and highlights the most likely threats to a software project.
To ensure that risks remain in the forefront of project management activities, it’s best to keep the risk management plan as simple as possible. For both conventional and agile software project management methodologies, a risk register is a proven tool for organizing and referring to known projects risks. A comprehensive risk register would contain consist of the following attributes:
Description of risk — Summary description of the risk—easy to understand.
Recognition Date — Date on which stakeholders identify and acknowledge the risk.
Probability of occurrence — Estimate of probability that this risk will materialize (%).
Severity — The intensity of undesirable impact to the project—if the risk materializes.
Owner — This person monitors the risk and takes action if necessary.
Action — The contingent response if the risk materializes.
Status — current team view of the risk: potential, monitoring, occurring, or eliminated.
Loss Size — Given in hours or days, this is a measure of the negative impact to the project.
Risk Exposure — Given in hours or days, this is is a product of probability and loss size.
Priority (optional) — This is either an independent ranking, or the product of probability and severity. Typically, a higher-severity risk with high probability has higher relative priority.
For the purpose of illustration, we provide an example of a risk register that includes four of the attributes given above. It is sorted according to the probability of occurrence, and the total risk exposure is a sum of all the individual risk exposures.
|Risk Description||Probability of Occurrence||Loss Size (Days)||Risk Exposure (Days)|
|Insufficient QA time to validate on all browsers and OS types.||45%||6||2.7|
|Lack of verifiable sample data may affect the ability of the primary external stakeholder to validate end product.||35%||18||6.3|
|Inadequate staff available from external stakeholders until very late in cycle.||25%||7||1.8|
|Following end-user testing, more effort on the user guide may be necessary.||25%||18||4.5|
|Backup and restore requires 3rd-party solutions (not evaluated yet).||20%||12||2.4|
|Insufficient time for external stakeholders to submit feedback on layout and composition of reports.||10%||5||0.5|
|Total Risk Exposure||18.2|
Software risk management is a balance of risk and reward, therefore it is essential that—as the team reviews the requirements (user stories in the product backlog)—it must also evaluate the risk for each one. In software, a high risk often does not correspond with a high reward. Instead, the driving question for managing risk should be: Does the potential reward for each story or requirement warrant the level of risk that the team is assuming as it proceeds with development? By considering alternatives, a development team can often achieve (nearly) the same level of reward without nearly as much risk. Adoption of this posture will help improve requirements prioritization.
We hope this article has given you solid guidance on how to plan for risk on software development projects. There are many details and subtleties that we don’t have space to cover here, but you can find more exploration of this topic and others on our website.