1. Introduction

2. Risk Mitigation Process

3. Top Ten Risk List

4. Minimizing the Risk

1. Introduction

The purpose of this Risk Mitigation Plan is to outline the plan and the process that the MJY Team will use to minimize and control the risk for our software development project. Section 2 describes the Risk Mitigation Process, which includes a bi-weekly status report from the Risk Manager and updates to the Risk Exposure Table in Appendix A. The MJY identified risks are outlined in Section 3 as a Top Ten List. These are the risks that have been identified by the team as having highest probability to impact its schedule. These risks have been categorized as High, Medium and Low. Section 4 outlines proposed actions to minimize each risk identified.

2. Risk Mitigation Process

The MJY Team Risk Mitigation Process consists of the following steps:

• Identify the Top Ten Risks
• Assign the risks an initial (H) High, (M) Medium, or (L) Low priority
• Develop a Risk Exposure Calculation Table to rank, update and track the priorities
• Use a weekly status report to track, report, handle and minimize risk by recalculating and reprioritizing the risks in the Risk Exposure Calculation Table

The Risk Mitigation Process will use a bi-weekly status report to bring to the group's attention any change to the Risk Exposure Calculation Table shown in Appendix A. It will included comments about specific items which have changed priority based on the previous weeks' work and it will highlight new or increased risk to previously cited items. This report will be sent to the Program Manager for review and discussion at the group's weekly meeting.

Based on the recommendation of the group, if a item has shown marked increase in priority, a separate analysis of that problem will be reported and action items will be assigned to the group for immediate response to the problem.

3. Top Ten Risk List

The following list contains the Top Ten risks the MJY group has identified during the initial requirements development phase of our program. Each item is also prioritized as being of (L)ow, (M)edium or (H)igh risk. (See Appendix A for the calculation of Risk Exposure used to prioritize this list)

• (H) WEB Site capacity/stability - Is sufficient site communications capacity and connectivity available to support anticipated user traffic (rate and volume)?

• (H) Staffing - All WEB site development is being performed by one developer.

• (M) Access to GMU - Is the permissions process sufficiently responsive/flexible to allow timely changes to WEB page content? Will hosting the site at GMU (versus using another ISP) impose additional operating restrictions or requirements (e.g. active site activity or content monitoring)?

• (M) Interactive chatroom - This feature requires further investigation to access complexity and to finalize requirements.

• (M) Volatility of external links - How stable are the links we are using?

• (M) Schedule

• (L) User interface - This feature requires further investigation to access complexity and to finalize requirements.

• (L) Requirements "creep"

• (L) Availability of other search engines - Identify available search engines and their reliability.

• (L) Support for all WEB browser technology - Given the rapid advances in WEB browser (presentation) functionality and associated standards, how much backward browser capability must be supported by the site to minimize adverse impacts to anticipated user community?

4. Minimizing the Risk

WEB Site capacity/stability

1. Make use of each group member's available disk space by use of links.
2. Minimize risk associated with a central source by having a backup of our site on another machine.
3. Investigate other site possibilities.
4. Have each MJY team member investigate whether their work site offers some space for installing a Software Management WEB site.

Access to GMU

1. Investigate other site possibilities.
2. Have each MJY team member investigate whether their work site offers some space for installing a Software Management WEB site.

Staffing

1. Assign back-up developers. Make sure they are always current on the status of the page and understand the update procedures so they can easily move into Development if the developer becomes ill, drops the course, goes on travel, etc.

Interactive chatroom

1. Investigate other site possibilities.
2. Have each MJY team member investigate whether their work site offers some space for installing a Software Management WEB site.

User interface

1. Assign to specific team members to investigate.
2. Develop typical and atypical user interaction scenarios that the final product must be capable of handling. Build/test to these scenarios.
3. Use prototypes as part of requirements or design phase for user and developer to gain a better understanding of final product requirements.

Requirements "creep"

1. Make use of the CCB to establish a sufficiently high change threshold that will eliminate frivolous or "spur of the moment" changes.
2. Set a firm date for finalizing requirements.
3. Consider an incremental development paradigm that can defer changes to later development increments.

Availability of other search engines

1. Assign to specific team members to investigate.

Volatility of external links

1. Place a disclaimer on the page about the currency of the links.
2. Indicate "last update" date on the page.
3. Assign each MJY team member in rotation each week the responsibility of verifying that the page links are current.
4. Establish a mechanism to alert the site manager of changes in link status.

Support for all WEB browser technology

1. Assign to specific team members to investigate.
2. Provide alternative means of information retrieval form the site.
3. Determine the feasibility of maintaining multiple HTML "versions" of the same document on the site. If feasible:
   1. Determine the maximum number that can be supported
   2. Determine the "earliest version" HTML documents that will be supported
   3. Determine any intermediate versions that will be supported.

Schedule

1. Publish weekly status reports.
2. For each of the team roles assign a back-up person(s). They can help any team member who is having problems meeting the schedule or deliverables.
3. Schedule weekly meetings after class to specific review status, schedule and assign action items.

Appendix A

Risk	P(UO)	L(UO)	RE	Priority
Schedule	7	6	42	High
User interface	3	8	24	Medium
WEB Site capacity/stability	5	4	20	Medium
Volatility of external links	5	4	20	Medium
Support for WEB browser technology	4	5	20	Medium
Staffing	2	8	16	Low
Access to GMU	3	5	15	Low
Availability of other search engines	2	7	14	Low
Interactive chatroom	5	3	15	Low
Requirements "creep"	1	7	7	Low