Channels ▼
RSS

Keep Your Project On Track

, April 01, 2001


April 2001: Keep Your Project On Track

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 pull-down 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 help—including the project team, customers, people who have worked on similar projects, and experts in the project's subject area—but 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 Problems Derived from Brainstorming) Likelihood of Risk Item Occurring Impact to Project if Risk Item Does Occur Priority (Likelihood x Impact)
New operating system may be unstable.
10
10
100
Communication problems over system issues.
8
9
72
We may not have the right requirements
9
6
54
Requirements may change late in the cycle.
7
7
49
Database software may arrive late.
4
8
32
Key people might leave.
2
10
20

[Return to text]

Table 2. Advanced Risk Priority Scheme
Risk Items (Potentional Future Problems Derived from Brainstorming) Likelihood of Risk Item Occurring Impact to Project if Risk Item Does Occur Priority (Likelihood x Impact) Actions to Reduce Likelihood Actions to Reduce Impact if Risk Does Occur Who Should Work on Actions When Should Actions Be Complete Status of Actions
New operating system may not be stable. 10 10 100 Test OS more. Identify second OS. Joe 3/3/01  
Communica-tion problems over system issues. 8 9 72 Develop system interface document for critical interfaces. Add replan milestone to realign the team's schedule with other areas. Cathy 5/6/01  
We may not have the right requirements. 9 6 54 Build prototype of UI. Limit Initial product distribution Lois 4/6/01  
Requirements may change late in the cycle. 7 7 49 Prototype top 10 requirements to refine the scope of initial release. Ship core features and limit initial product distribution. Cecil 1/2/01  
Database software may arrive late. 4 8 32 Check with supplier. Get early copy of database. Offer testing help to Make application compatible with a substitute database. Joe 2/2/01  
Key people might leave. 2 10 20 Make sure Jim is happy. Earmark Fred as a backup. Pete 3/4/01  

[Return to text]


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video