Attack Major Risks Early and Continuously. , or They Will Attack You

Attack Major Risks Early and Continuously. , or They Will Attack You

As Tom Gilb said, "If you don't actively attack the risks, they will actively attack you." ^[1] As Figure 2.1 shows, one of the prime benefits of the iterative approach is that it allows you to identify and address major risks early in the project.

^[1] See Gilb 1988.

Figure 2.1. Risk Reduction Profiles for Waterfall and Iterative Developments. A major goal with iterative development is to reduce risk early on. This is done by analyzing, prioritizing, and attacking top risks in each iteration.

Why address top risks early on? Unaddressed risks mean that you are potentially investing in a faulty architecture or a nonoptimal set of requirements. This is bad software economics. In addition, the amount of risk is directly correlated to the difference between the upper and lower estimates of how long it will take to complete a project. To come up with accurate estimations, you need to identify and address risks up front.

How do you deal with risks early on? At the beginning of each iteration, the RUP advises you to make, or revise , a list of top risks. Prioritize the risk list; then decide what you need to do to address, typically, the top three to five risks. For example, the risks may look as follows :

• Risk 1: You are concerned , based on past experience, that Department X will not understand what requirements you plan to deliver, and as a result will request changes after beta software is delivered.

• Risk 2: You do not understand how you can integrate with legacy system Y.

• Risk 3: You have no experience in developing on the Microsoft .NET platform or in using Rational Rose.

• Risk 4: ...And so on.

Now, how will this risk list be used? Addressing risks should be a priority for everyone throughout the project. Look at what you would "normally" do for the iteration at hand, then slightly modify the plan to make sure that you deal with your risks. Typically, risks need to be addressed from multiple perspectives, such as requirements, design, and testing. For each of these perspectives, start with a coarse solution and successively detail it to diminish the risk. You may, for example, add the following actions to address the earlier-identified risks:

• Risk 1: As the use cases related to Department X are developed, complement them with a user -interface (UI) prototype. Set up a meeting with Department X, and walk them through each use case, using the UI prototype as a storyboard. Get a formal sign-off on the requirements. Throughout the project, keep Department X in the loop on progress, and provide them with early prototypes and alpha releases.

• Risk 2: Have a "tiger team" with one or two skilled developers build an actual prototype that shows how to integrate with legacy system Y. The integration may be a throw-away, but the prototype should prove that you actually can integrate with the legacy system. Throughout the project, ensure appropriate testing of the integration with legacy system Y.

  An alternative would be to cut the scope of the project, so you do not have to integrate with legacy system Y. This strategy is called "risk avoidance " and is typically highly effective. Note that all other examples in this list are of the strategy type "risk mitigation."

• Risk 3: Send a couple of people for training on Microsoft .NET and Rational Rose, respectively, and find the budget to bring in a Rational Rose mentor two days per week for the first three weeks of the Elaboration phase. Recruit a team member with an understanding of the .NET platform.

• Risk 4: ...And so on.

Many project risks are associated with the architecture. This is why the RUP's primary objective in the Elaboration phase is getting the architecture right. To do this you not only design the architecture, but you also implement and test it. (Find out more about this in the section Baseline an Executable Architecture Early On.)

One thing to keep in mind is that the risk list continuously changes. Attacking risk is a constant battle. In each iteration you will be able to reduce or remove some risks, while others grow and new ones appear.

Summary

The RUP provides a structured approach to addressing top risks early, which decreases overall costs and allows you to make earlier, more realistic, and more accurate estimations of how much time it will take to complete the project. Remember that risk management is a dynamic and ongoing process.