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:

• Lack of experience
• Lack of control
• Lack of information and
• Lack of time

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.

Assessing Risk

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:

• Avoidance. Where we don't engage in the risky activity.
• Prevention. Where we take proactive steps to reduce the probability and severity of the unwanted outcome.
• Mitigation. Where we accept the risk and develop contingency plans as a buffer against loss and
• Transfer. Where we transfer the responsibility for the risk to another party.

Creating a Risk Register

The results of our risk assessment are recorded in a risk register. For each risk we'll:

• Reference the work package activity
• Describe the risk scenario
• Document its probability and severity and rank the risk using the risk matrix
• Where possible we'll quantify its impact on project cost scope, schedule, quality and safety
• We'll describe our risk management strategy
• We'll nominate responsibility for managing the risk, describing who will do what and by when
• If we've accepted a risk we'll describe our contingency plan should the risk scenario be realised
• Lastly we'll nominate how often the risk should be reviewed in the course of the project.

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:

• Identifies significant risks - focussing on the top 10 risks from the risk register
• It outlines the broad strategy for risk management
• It specifies resource requirements
• It identifies risk management responsibilities - nominating:
• who Identifies risks
• who proposes actions
• who approves actions
• who performs actions
• who verifies actions are complete and
• who maintains the risk register
• It also describes the process for risk monitoring and control during project execution.

Conclusion

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.