Recently, I was discussing risk management with Bayan Qandil, a colleague at RIM.  Our conversation reminded me that planning for risk is one of the most important considerations in software projects.  Every software development methodology, from traditional to iterative to agile approaches, tailors itself to better manage unknowns in a project.

Today, we examine the risk management tool that must be present in some form in every software project: the risk register.

Does Your Risk Register Look Like This?

Here is one common risk register format:

Why is this Necessary?

I've already mentioned in earlier articles that risk is the single greatest cause of failure of software projects.  These are items that the teams either did not know would happen, or that they knew could happen but did not plan for them adequately.

The risk register fills three critical functions in avoiding these project failures:

First, it requires the team to plan for its risks.  This in itself is invaluable.  If a team plans sufficiently for the unknowns that could occur, then the likelihood of failure is dramatically reduced.

Second, it allows the team to prioritize its risks and mitigations.  Each risk has a different chance of occurring, and each one has a different impact if it does occur.  Identifying this allows the team to spend its time mitigating the risks that have the greatest chance of hurting the project.

Third, it forces the team to follow-up on its mitigation plans.  The risk mitigations in the register become action items, so it becomes more difficult for the team to ignore potentially disastrous unknowns.

So, What is a Risk?

This seems like it has an obvious answer, but let's be sure.  A risk is an uncertain event that could happen in the future, which would impact a project objective (i.e. scope, schedule, cost, or quality).

First, notice that a risk is "uncertain".  We don't know if it's going to happen.  If you know it's going to happen, like you don't have enough QA staff, then it's not a risk -- it's a problem that you have to solve now.

Second, a project risk affects a project objective.  There may be many events that could affect a product or the company, but if they don't affect something that the team is responsible for delivering, then it's out of scope for the project.

Lastly, a risk isn't defined as being a negative thing.  Positive risks (such as unexpectedly good performance of a new algorithm) can also be tracked in a project.  With positive risks, you want to maximize the chance of their occurrence and maximize their impact.  However, for simplicity, we'll examine positive risks in a future article, and simply focus on the negative ones today.

Let's now take a look at the risk register a little more closely.

Risk ID

The first column in the table above is the risk identifier.  This doesn't have to use an elaborate identification scheme.  You just need an easy way to quickly communicate which risk you're talking about with your team and the stakeholders.

Risk Description

This is the summary of the risk you're planning for.  Identifying software project risks is a large topic, so we'll save this for a future article.  However, some key sources of risks are incorrect assumptions, dependencies on other teams, personnel, and requirements changes.

Risks also occur at the task level and at the project level, and both of these must be considered in the risk register.  An example of a task level risk is that a feature may consume too much memory for the customer.

Project level risks are not tied to any particular task.  For example, in projects that are estimated using a Work Breakdown Structure (WBS), the most common project level risk can be called "whitespace risk".  This is the risk that the WBS is missing tasks.  Even if the WBS was created using progressive decomposition, the risk exists that at some point during the project, the team will realize that a piece of work is missing, and the project will be delayed.

Probability

This is the probability that the risk will materialize.  For qualitative risk management, a high / medium / low scale is usually sufficient.  These don't have to map to a specific percentage range, as what matters is their ranking versus the other risks in the register.

An important consideration here is that you should record the probability of the risk occurring before mitigation.  One purpose of the risk register is to identify which mitigations are top priority, so the team may decide that low priority risks do not need to be mitigated.

For quantitative risk management, you will often need to assign a numeric percentage chance of occurrence.  Quantitative risk management is a much larger topic, so we'll merely touch on it here and save the rest of the discussion for a future article.

Impact

This is the impact that the risk will have on the project if it occurs.  Once again, for qualitative risk management, you generally only need a high / medium / low scale, which is relative to the other risks in the project.

With quantitative risk management, you would need to explicitly quantify the impact to the relevant project objective.  For example, if the project does not meet the bandwidth requirements of the customer, the team may forecast that this would result in a 40 business day delay to the project schedule.

Exposure

The purpose of the risk exposure field is to identify the priority of the risk and its mitigation activities.  The highest exposure risks pose the greatest threat to the project and must be mitigated first.  So, the mitigation tasks need to be prioritized accordingly.  Qualitative risk exposure is calculated by combining the probability and impact fields, often using a simple table such as:

On the other hand, if you are doing quantitative risk management, you will calculate the risk exposure by multiplying the actual percentage probability of occurrence by the actual impact to the objective.  If the 40 day delay above had a 10% probability of happening, that would mean a 4 day contingency would need to be included in the project schedule.

Mitigation

Mitigation is the set of tasks that the team undertakes to minimize the chance that a negative risk will happen.  The important thing to remember here is that mitigation leads to action items.  Each of these action items should be assigned to someone and have a deadline associated with it.  Of course, action items associated with risk mitigation can be tracked on the risk register or they can be tracked with the rest of the project action items.

Since the risks are prioritized, the action items associated with the highest priority risks need to be addressed first.  Lower priority risks can be mitigated later, if they are mitigated at all.

Contingency

Identifying risk contingencies can be difficult.  After all, if the schedule for a project is slipping, the two obvious responses are to add more staff (i.e. increase cost) or to drop features (i.e. reduce scope).  If you have flexible project objectives, then this is a feasible approach -- this is the case of, "I don't care what you deliver, as long as you deliver by this date."

However, most projects operate with less flexible objectives, with contracts specifying scope, schedule, and cost.  In this case, "delay the project", "drop features", or "add staff" are not realistic contingency plans.  Challenge the team to be creative here.  Are there temporary workarounds that can be established for the first release?  Can the customer's end goal be accomplished in another way?  It can be difficult to ask these questions while the project is still on track, but considering your options early will help immensely when problems start surfacing.

In terms of quantitative risk management, contingency also typically includes the "buffer" applied to the affected project objective.  In the example above, the 4 days that are added to the schedule are part of the contingency planning for that risk.  "Buffer" is a bad word, because it conjures up images of arbitrary padding.  It's important to remember that you aren't arbitrarily adding safety to the objectives.  You are taking a defined action to reduce the impact of a known risk.  If there is a better contingency to use, then you should plan to use that one instead.

Is that All?

Risk registers sometimes contain other items as well, depending on the needs of the project and the company.  Here are a few possibilities:

Objective affected: When you are performing quantitative risk management, you need to identify the objective that is affected.  The risk exposure for quantitative risk management is measured in the units of the objective affected.  That is, schedule slip in days, cost increases in dollars, and scope in number of features.  The overall contingency for that objective then becomes the sum of all the individual risks that affect the objective.

Probability after mitigation: When you mitigate a risk, the probability of that risk occurring should go down.  Knowing this reduced probability can be especially useful for quantitative risk management, because once a risk has been mitigated, you should be able to reduce the risk exposure, and hence the contingency that is added to the schedule or the budget.

As well, sometimes mitigation also reduces the potential impact of the risk.  In this case, you should include 'impact after mitigation' in your risk register as well, and adjust exposure and contingency accordingly.

Action item assignees and deadlines: If you are tracking mitigation action items in the risk register, then adding these fields will remove a lot of confusion.

Trigger point: How do you decide if a risk has actually occurred, and you need to execute the contingency plan?  With some risks, this is easy -- for example, if a key staff member quits.  But with other risks, such as an increasing defect arrival rate, it's often useful to identify what the threshold will be, to execute your contingency plan.  This threshold is your trigger point: The point at which a trend is deemed to be unacceptably high.  For example, you may set your trigger point for a delayed external dependency to be a one week slip.  If the delivery is more than one week late, you begin your contingency plan, which could be to implement a workaround internally.

Risk category: If you have a large number of risks, you can either drop the lower priority risks (perhaps to a "watch list"), or you can use risk categories to keep them organized.  Possible categories include technology risks, personnel risks, and dependency risks.

Then What?

Risk management doesn't stop once the team has created the risk register for its project and prioritized its risks.  Static plans are not very useful, especially in software, so you need to track the mitigation action items, and you need to continually integrate new learnings from the project.  As the team's knowledge grows, some risks will disappear and new ones will arise.  Keep your focus on the project's risks, and you'll remove one of the greatest sources of software project failure.

Lastly

I hope you're finding these articles to be helpful in managing your software deliveries.  Of course, in future articles, we'll continue to investigate these and other software project management techniques in greater detail.

Let me know what you think!  How did you manage risk in your deliveries?  This field is always changing, and new techniques are continually being developed.  If you have any questions, or if you would like more information on how to implement these or other software development processes in your organization, please feel free to contact me at Charles@CharlesConway.com.

If you know of someone who may find this article of interest, please forward it on!

Good luck!
Charles