Keep Your Project On Track

April 2001

How to have less chaos, reduced cost, fewer bugs and increased
schedule predictability.
by Neil Potter and Mary Sakry
As a software developer or project manager, you're probably more than aware of the problems
that plague your organization. The problem list typically starts with overwhelming
commitments and deadlines: The marketing department has been promised the first shipment
by December. The customers have been guaranteed on-time delivery. The managers have
established year-end bonuses based upon product shipment. The programmers are working
longer hours, and the system test group is waiting anxiously to test a copy of the software
during its allotted five-day "make it work" period. The technical writers are lost in 300 pulldown menus and can't get engineering feedback on their documents. And support engineers
are still fixing bugs from the previous release.
You might believe that this is normal for a busy, successful software organization, however,
many of these problems can be avoided. You can anticipate and prevent project problems by
using simple risk management techniques.
Risk management is comparable to performing preventive health care and buying insurance
for your project. It involves identifying potential problems (risks), analyzing those risks,
planning to manage them and reviewing them.
When
to
Perform
Risk
Management
Risk management is usually performed at the start of a project, at the beginning of major
project phases (such as requirements, design, coding and deployment), and when there are
significant changes (for example, feature changes, target platform changes and technology
changes).
The four steps to risk management are risk identification, risk analysis, risk management
planning and risk review. This process is simple, effective and takes 90 to 120 minutes for
projects that are 12 to 60 person-months of effort. Projects smaller than 12 person-months
take 40 to 60 minutes. You can control the length of the session by controlling the scope you
choose, but most sessions usually take less than two hours.
Risk
Identification
To identify risks, we must first define risk. Risks are potential problems, ones that aren't
guaranteed to occur. When people begin identifying risks, they often start by listing known
problems; however, known problems aren't risks. During risk identification, simply move any
known problems to a problem list and concentrate on future potential problems.
A 15- to 30-minute brainstorming session is an effective way to identify risks. Be sure to invite
anyone who can helpincluding the project team, customers, people who have worked on
similar projects, and experts in the project's subject areabut limit the group to a
manageable size of nine people. During the session, participants should call out any potential
problems they believe could hurt the project. Next, as a group, they should generate new
ideas based on the items on the list.
During the brainstorming session, consider the following items:

Weak areas, such as unknown technology.

Aspects that are critical to project success, such as the timely delivery of a vendor's
database software, creation of translators or a user interface that meets the
customer's needs.
Problems that have plagued past projects, such as loss of key staff, missed deadlines
or error-prone software

Possible risks are: "We may not have the right requirements," "The technology is untested,"
"Key people might leave," "The server won't restart in situation X," and "People might resist
the change." Any potential problem or critical project feature is a good candidate for the risk
list.
Once you have created a list, work with the group to clarify each item and remove any
duplicates.
Risk
Analysis
The first step in risk analysis is to make each risk item more specific. Risks like "Lack of
management buy-in" and "People might leave" are vague. In these cases, the group may
decide to split the risk into smaller, specific risks, such as "Manager Jane could decide the
project isn't beneficial," "The database expert might leave," and "The webmaster may be
pulled off the project."
Next, set priorities and determine where to focus risk mitigation efforts. Some of the identified
risks are unlikely to occur, and others may not be serious enough for concern. During the
analysis, discuss each risk item to determine its potential damage, and whether or not it is
likely to occur. For example, if there is a risk of a key person leaving, you might decide that
even though a key person leaving would have a large impact on the project, it's not very likely
that a specific person would leave.
During risk analysis the group agrees on how likely it is that each risk item will occur, using a
simple scale from one to 10 (where one is very unlikely and 10 is very likely). The group then
rates how serious the impact would be if the risk did occur, using a simple scale from one to
10 (where one is little impact and 10 is very large).
To use this numbering scheme, first select the items that rate one and 10, respectively. Then
rate the other items relative to these boundaries. To determine the priority of each risk item,
calculate the product of the two values, likelihood and impact. This priority scheme helps push
the big risks to the top of the list and the small risks to the bottom. See Table 1 for an
example.
Once your group has assigned a priority to each risk, it's ready to select the items to manage.
Some project teams select a subset, while others choose to work on all items. To get started,
you might select the top three risks, or the top 20 percent, based on the priority calculation.
Risk
Management
Planning
There are two things you can do to manage risk. First, take action to reduce (or partially
reduce) the likelihood of the risk occurring. For example, for project teams who work on
special one-time projects schedule earlier deadlines, you need to minimize the likelihood that
team members will be pulled off the project due to changing organizational priorities. In a
software product, a critical feature might be developed first and tested early.
Second, reduce the impact if the risk does occur. Sometimes you can act prior to the crisis,
such as creating a simulator to use for testing if the hardware is late. At other times, it's a
simple backup plan, such as running a night shift to share hardware or ensuring that the new
application runs on the the operating system in case the new one is unstable.

To negate the potential loss of a key person, for example, you might plan to reduce the impact
by ensuring that other people are familiar with that person's work, or you may reduce the
likelihood of attrition by giving the person a raise or providing more flexible working hours.
Another example, using this priority scheme, is illustrated in Table 2.
Once you've developed the risk mitigation actions, you must decide which of them you are
going to pursue. We suggest that you start with two actions for each selected risk: one that
reduces the risk's likelihood and one that prepares the project if the risk occurs. You can add
these actions to your development schedule.
Risk
Review
You will want to review your risks periodically, so you can check how well mitigation is
progressing. You can also see if you need to change risk priorities, or if you've discovered new
risks. You might decide to rerun the complete risk process if the project has experienced
significant changes. Significant changes might include the addition of new features, the
changing of the target platform or a change in project team members. Many people
incorporate risk review into other regularly scheduled project reviews.
Risk
Management
Success
Risk management prevents and reduces the effect of potential project problems. It is a cure
for crisis. By setting priorities, you control your balance between reaction and prevention
during the life of the project. When problems do occur, risk management helps you react
quickly with a well-thought-out solution, reducing the impact to your team. The results are
smoother running projects, less chaos, reduced cost, fewer bugs and increased schedule
predictability.

Table 1. The Priority Scheme

Risk
Items
(Potentional
Future Likelihood of Risk Impact to Project if Priority (Likelihood
Problems Derived from Brainstorming) Item Occurring
Risk Item Does Occur x Impact)
New operating
unstable.

system

10

10

100

Communication problems over system

issues.

72

We
may
not
requirements

right

54

Requirements may change late in the

cycle.

49

Database software may arrive late.

32

Key people might leave.

10

20

to Actions
to Who
Reduce
Should
Impact
if Work
Risk
Does on
Occur
Actions

When
Status
Should
of
Actions
Actions
Be
Complete

have

may

the

be

[Return to text]
Table 2. Advanced Risk Priority Scheme
Risk
Items Likelihood Impact Priority
Actions
(Potentional
of
Risk to
(Likelihood Reduce
Future
Item
Project x Impact) Likelihood
Problems
Occurring if Risk
Derived
from
Item
Brainstorming)
Does

Occur
New operating
system
may
not be stable.

10

10

100

Communication problems
over
system
issues.

72

Develop
Add replan Cathy
system
milestone to
interface
realign the
document for team's
critical
schedule
interfaces.
with
other
areas.

5/6/01

We may not
have the right
requirements.

54

Build
prototype
UI.

Lois

4/6/01

Requirements
may
change
late
in
the
cycle.

49

Prototype top Ship

core Cecil
10
features and
requirements limit initial
to refine the product
scope
of distribution.
initial
release.

1/2/01

Database
software
may
arrive late.

32

Check
with Make
supplier. Get application
early copy of compatible
database.
with
a
Offer testing substitute
help to
database.

Joe

2/2/01

Key
people
might leave.

10

20

Make
sure Earmark
Jim is happy. Fred as
backup.

Pete

3/4/01

[Return to text]

Test
more.

OS Identify
second OS.

Joe

Limit Initial
of product
distribution

3/3/01