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.
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.
CAST hosts demonstrations of the CAST Application Intelligence Platform and Analytics Dashboard each Tuesday and Thursday. Choose your appropriate schedule and complete the registration form below to join us.
Please Select your Session
Copyright 2016 - CAST | All Rights Reserved