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.
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.
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.
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.