This section includes two risk management plans: one for the ACIC project and one from another project (here called XYZ). As you will see, the risk management plans tend to be small usually a table that fits on a page. The activities mentioned in the mitigation plan become part of project activities and may even be explicitly scheduled.

6.4.1 The ACIC Project

The ACIC project manager chose to work with numbers for risk prioritization and analysis. As shown in Table 6.4 , the top risk items have impact ratings that range from 8 to 3. The risk mitigation steps are also shown for each risk. For example, the second risk is working with the RUP methodology. That is, the project incurs a risk because the methodology is new to the project personnel. Furthermore, it seems that other projects have not used RUP. One of the risk mitigation plans is the most obvious one: to plan for training in the RUP methodology. In addition, it is suggested that the people from the R&D labs be consulted because they have knowledge of RUP and related concepts, that the customer be kept in the loop continuously, and that any problems be escalated quickly.

Table 6.4. Risk Management Plan for the ACIC Project

Sequence Number




Risk Exposure

Mitigation Plan


We will need support from the database architect and the customer's database administrator.




Plan carefully for the time required from each of these groups and give enough prior notice.

Have an onsite coordinator work closely with these groups.


Because RUP is being used for the first time, the understanding of the team may not be complete.




Work closely with experts in the Infosys R&D lab.

Keep the customer in the loop throughout the project and escalate for any schedule or effort deviations.

Train the team on RUP methodology.


Personnel attrition: Team members might leave on short notice.




Assign tasks so that more than one person is aware of the units and use cases in the project.


Working with the customer's mainframe DB2 over the link: Link may not be as efficient as it is expected.




Do extra code reviews, desk checking, etc. to minimize the reliance on the link.

Escalate as soon as the link goes down.

Note that once these options are accepted as the risk mitigation steps, they influence the detailed schedule of the project; the schedule must include time for appropriate training and proof-of-concept building activities. This need will arise with many risk mitigation steps. Because they represent actions and because the detailed project schedule represents most of the actions to be taken in the project, the risk mitigation steps will frequently change the detailed project schedule, adding to the project's overall effort requirement.

6.4.2 The XYZ Project

This project used the rating system for its risk management. Table 6.5 shows the various ratings and the risk mitigation steps. This risk management plan is a part of the project management plan for the project and has been extracted from it.

The method for performing the risk analysis at a milestone is essentially the same as described earlier, except that more attention is given to the risks listed in the project plan (that is, greater emphasis is placed on the output of earlier risk analyses for the project). During this risk analysis, project managers may reprioritize risks. In the XYZ project, when an analysis was done at a milestone about three months after the initial risk management plan was made, the risk perception had changed somewhat. Table 6.6 gives some of the risks for which the exposure had changed.

Based on the experience in the project to date, the project manager decided that the consequences of change reconciliation were considerably less dire. This situation might have arisen because, for example, the reconciliation problems encountered had been less difficult than expected. Similarly, the perception of the risk of manpower attrition had increased again, perhaps because of experience with team members and perhaps the fact that people were leaving in the middle of the project was now perceived as a greater problem than at the start of the project. Whenever risks are analyzed, the risk mitigation plans may also change, depending on the current realities of the project and the nature of risks. In this project, there was no change in the risk mitigation plans.


Software Project Management in Practice
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2005
Pages: 83
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net