SOFTWARE IN PRACTICE
What is Risk Management Planning?
Risk management planning is the process of reflecting on what could go wrong and developing risk management strategies to either eliminate the risk or reduce its impact on the project.
Sources of Risk
In complex systems projects risks commonly arise from:
For example we often lack experience in the technologies we're applying. The result is unplanned time and effort spent in learning and reworking nonperforming designs.
When we contract development services or purchase components from external suppliers we give up direct control of delivery schedules. This can expose us to late delivery of the integrated system.
With critical activities such as requirements capture we depend on external organisations for information. For example, we depend on the customer for a complete and correct statement of requirements. Incomplete requirements can result in the delivered system not meeting the customer's needs.
Our projects are chronically time poor because we set unrealistic delivery schedules. This is often the result of underestimating the effort needed to deal with project size and complexity.
To analyse what could go wrong on this project we'll perform risk assessments when developing each work package in the WBS. For each risk identified we'll determine its probability and severity of outcome. For a comparative analysis we'll then rank each risk using a probability/severity matrix.
Developing Risk Management Strategies
We'll then develop risk management strategies. All risks have some root cause These causes present threats to our project. For example, lack of experience in a new technology is a threat In the presence of a threat we may have an unwanted outcome where we lose control of a situation. For example, mistakes made in applying a new technology may require us to rework our design. When we lose control there are consequences. In this case design rework may cause cost and schedule overrun. We can reduce the probability that we'll lose control by introducing risk management strategies that act as barriers to loss of control. For example, we can avoid rework by budgeting for technical investigation and prototyping of new technologies.
If we accept the risk which means we don't introduce barriers or if the barriers we DO introduce fail, and we DO experience the loss of control, we can still reduce the severity of the consequence with a contingency plan. In this case, to make our delivery deadline, we could deliver a subset of system functionality - that is, the critical set of functions the customer needs on day one.
With these strategies we hope for the best but prepare for the worst. Most of the time we have no choice ... unless of course we can avoid the risk altogether by not proceeding with the risky activity. For example, in this case we could choose to employ proven technology.
Alternatively if we must use new technology we can transfer the risk to another party who is more capable of managing it. For example we can contract out risky subsystem development to specialist organisations.
To summarize, we can manage risk by:
Creating a Risk Register
The results of our risk assessment are recorded in a risk register. For each risk we'll:
To help us focus on high risk activities we sort the risk register by rank. A top 10 risk list will be published on the project intranet. The register provides a mechanism for tracking and controlling risk throughout the project. An up-to-date risk register demonstrates a project's commitment to formal risk management.
Developing a Risk Management Plan
At project commencement the overall approach to managing the project's risk profile is documented in a Risk Management Plan. The plan:
To conduct a project is to be in a state of perpetual risk; things will go wrong. We can choose to ignore risk and, to quote Shakespeare: "Suffer the slings and arrows of outrageous fortune", or we can act with vigour and "... take arms against a sea of troubles, And by opposing end them?"
On this project we will take the purposeful and sometimes painful steps to prepare for and hopefully avoid the unimaginable. This is the essence of risk management.
About this talk
Most software projects are risky enterprises. Budget and schedule overruns are common place. The good news is that the common risk factors that produce these unwanted outcomes are well documented. In sixty years of software development we've learned that time spent reflecting on what could go wrong and developing risk management strategies has an attractive return on investment. Les Chambers summarises common project failure modes and works through best practice in risk management, focussing on important outputs from the risk management process: the risk register and the risk management plan.