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:
Supplier does meet the delivery deadlines
Supplier is providing weekly interim releases, which we
integrate, test, and track.
deliveries are prioritized, so highest priority items will
be received first.
Higher priority outstanding items will be moved in-house.
2) Lower priority
outstanding items will be de-scoped.
3) Progress of
supplier's interim deliveries will feed back into the
Customer does not provide timely feedback on interim
Project manager and account manager are communicating
closely with the customer to ensure that they understand the
project's dependency on their deliverables.
2) For each
interim release to the customer, we are tracking how quickly
they progress through their evaluation.
If the feedback is not received in a timely manner, further
customer requests will be handled in future releases.
2) Identify other
sources for product feedback.
response time will feed back into the project plan.
You can download this Risk Register Template (in Excel 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
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
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
Let's now take a look at the risk register a little more closely.
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.
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.
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
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.
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.
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 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.
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
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
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
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.
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.
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