RISK MITIGATION PLAN - DRAFT

2/10/97

MJY TEAM

Table of Contents

1. Introduction 3

2. Top Ten Risk List 3

3. Minimizing the Risk 4

Appendix A 6

---

Introduction

The purpose of this risk mitigation plan is to outline the risks that have been identified by the team as having highest probability to impact our schedule. These risks have been categorized as High, Medium and Low.

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) 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)?

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

• (H) Schedule

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

• (M) Requirements "creep"

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

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

• (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?

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

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

---

Minimizing the Risk

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.

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.

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.

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.

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.

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.

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.

Availability of other search engines

1. Assign to specific team members to investigate.

---

Appendix A

Risk Exposure Calculation Table