Managing Risks

After you have determined that a project is feasible, it does not mean there are no risks. It only means that, in your opinion, the risks appear manageable and there are no "show stopper" items.

Sources of Risks

Risks can come from any directionsome anticipated, some out of nowhere. Although the MSF documentation has an illustration showing some of the more common risks (see Figure 1.4), it is not an exhaustive list. Most solution architects know that there are risks, but too many of them assume that, like the fictional TV character MacGyver, they will be able to handle things "on the fly."

Figure 1.4. Risk sources. (From Microsoft's TechNet Library: IT Solutions > Teams and Processes > Innovative Solutions > MSF Resource Library > "MSF Risk Management Discipline v.1.1".)

MacGyver was the main character in a television show from the 1980s who could get out of seemingly impossible situations by "whipping up a solution" with objects lying around (pine cones, paper clips, household chemicals, and the like). You get the idea.

A better strategy is to at least identify the risks you can and put a plan into place to manage them, and then maybe you will be able to handle the surprises more effectively. The following sections describe what Microsoft sees as the five-step Risk Management Process.

Risk Management: The MSF Process

All solutions have risks. How you manage those risks can spell success or failure for your solution.

Most project management books have some coverage of risk management, but because this exam is a Microsoft exam, I'm going to take one less risk and use its process (see Figure 1.5).

Figure 1.5. The Microsoft Risk Management Process. (From Microsoft's TechNet Library: IT Solutions > Teams and Processes > Innovative Solutions > MSF Resource Library > "MSF Risk Management Discipline v.1.1".)

Risk Identification

First, you must identify the risks that you can. This step could entail a brainstorming session with your peers and business stakeholders. After you create a fairly thorough list, you make an informal attempt to rank the risks. For the remaining risks, you should write a clear risk statement. For example, although "missing the deadline" is a valid risk, a risk statement might read "Because of lack of resources, the June 2003 deadline is at risk. This will cause us to miss our IRS filing requirement and significant penalties will result."

Another approach that works well is to assess risks from the perspective of each of the six team roles discussed in the previous section. This approach enables you to look at your solution from various angles and might help you see something you would have overlooked otherwise.

Risk Analysis

For analytical readers, here's your chance to pull out the calculator. After ranking the risks subjectively, you need an objective way to assess their impact. A common method is multiplying the probability that the risk might occur by some value scale representing the risk's impact on the success of the project. Here are a few examples:

• Risk analysis that the lead programmer will leave or become ill before the project is completed:

  5% x 4 (scale of 1 to 5) = 0.2

• Risk analysis that the initial volume of users (Internet) will overwhelm the server and database:

  50% x 3 (scale of 1 to 5) = 1.5

• Risk analysis (in dollars) that additional server hardware will be needed:

  60% x $80,000 = $48,000 (potential budget risk)

As you can see, the first risk, although it has a greater impact on the project, is not as worrisome as the risk of having too many people visit your site. Therefore, you would put more time into preventing or planning contingencies for this second risk. The third risk is measured in dollars. If the overall solution budget is more than a million dollars, this risk would not be worth your time. However, if the total budget for everything is $100,000, and the existing hardware can absorb the new solution, you might want to spend more time and effort on managing and mitigating this risk.

A strategy that I've used for years and that Microsoft recommends as well (in case you won't take my word for it) is creating a "Top 10" risks list. It seems that 10 is a workable number of items to manage. It is small enough to allow you to focus on the biggest risks, yet large enough to capture most of the risks that could wipe you out. If you feel strongly about an 11th risk you want to add to the list, go ahead. If you can think of only nine risks, that's okay, too. As a risk falls off the list (that is, gets resolved or ceases to be a risk), you can promote other risks (that didn't make the initial 10) to the list in its place.

Risk Action Planning

The third step in the process is creating a plan for how to manage (mitigate) each risk on your list. To assist in this step, break the effort down into four key tasks (using the hypothetical risk of losing a lead programmer as an example):

• Research Do you know all you need to know about this risk? How would it affect the project if one of the lead developers left before you were done?

• Accept Are the consequences acceptable? If your lead developer leaves, are you going to go outside the company and find a replacement? Promote someone from the team to take his place? Will you survive if the risk occurs?

• Manage What steps could you take to mitigate the risk? Can you reduce the probability that the risk will occur? Can you reduce the impact on your solution? Are there workarounds? In managing the risk of one of your developers "going walkabout," could you create an environment that would make it unlikely that someone would want to leave?

• Avoid Can you sidestep the risk by changing the solution scope? This task is similar to the feasibility check you did earlier. If you have only one vendor that supplies a component you need, and that vendor is financially shaky, can you somehow factor that component out? Returning to the risk of the lead developer leaving, can you establish an environment that promotes knowledge transfer so that no one person is indispensable?

Risk Tracking

The fourth step in the process is to track your risks as the project proceeds. Weekly status reviews of the Top 10 risk list would be a good idea. The ranking you did in the second step can change over time (in either direction), so regular reviews are suggested. If a risk's probability ever falls to 0% or its impact falls to 0, you can safely remove that risk from tracking.

Risk Control

Finally, you take control. This step is basically nothing more than implementing whatever plans you have put in place in the other four steps. If the risk plan says "If we don't find a Web site host by December 15, 2002, drop the remote e-mail feature from scope for this release," you do just that. Remote e-mail becomes a feature for the next release.

Another common strategy that falls into this area is the creation of a "proof of concept" application. Proving the riskiest technologies ahead of time is wise. Waiting until the project is 50% complete to find a fatal flaw in the selected software is not a wise move. Building small applications to test risky software solutions is a good way to manage risk early in the process. Many projects attack this goal by creating "run ahead" teams, in which a small subset of the team works in parallel on the critical technologies so that trouble can be detected early enough to respond without endangering the deadline.

The use of patterns is another way to mitigate risks. Patterns are sub-architectures that have been proved to work by others. A section of the MSDN Web site is devoted to "Patterns and Practices" (http://msdn.microsoft.com/architecture).