3.0 RISK MANAGEMENT


3.0 RISK MANAGEMENT

3.1 Scope and Intent of RMMM Activities

This project will be uploaded to a server and this server will be exposed to the outside world, so we need to develop security protection. We will need to configure a firewall and restrict access to only "authorized users" through the linked faculty database. We will have to know how to deal with load balance if the number of visits to the site is very large at one time.

We will need to know how to maintain the database in order to make it more efficient, what type of database we should use, who should have the responsibility to maintain it, and who should be the administrator. Proper training of the aforementioned personnel is very important so that the database and the system contain accurate information.

3.2 Risk Management Organizational Role

The software project manager must maintain a track record of the efforts and schedules of the team. They must anticipate any "unwelcome" events that might occur during the development or maintenance stages and establish plans to avoid these events or minimize their consequences.

It is the responsibility of everyone on the project team with the regular input of the customer to assess potential risks throughout the project. Communication among everyone involved is very important to the success of the project. In this way, it is possible to mitigate and eliminate possible risks before they occur. This is known as a proactive approach or strategy for risk management.

3.3 Risk Description

This section describes the risks that may occur during this project.

3.3.1 Description of Risks

  • Business impact risk. This risk would entail that the software produced does not meet the needs of the client who requested the product. It would also have a business impact if the product no longer fits into the overall business strategy for the company.

  • Customer characteristics risk. This risk is the customer's lack of involvement in the project and their non-availability to meet with the developers in a timely manner. Also, the customer's sophistication as to the product being developed and ability to use it are part of this risk.

  • Development risk. Pressman describes this as "risks associated with the availability and quality of the tools to be used to build the product." The equipment and software provided by the client on which to run the product must be compatible with the software project being developed.

  • Process definition risk. Does the software being developed meet the requirements as originally defined by the developer and client? Did the development team follow the correct design throughout the project? The above are examples of process risks.

  • Product size risk. The product size risk involves the overall size of the software being built or modified. Risks involved would include the customer not providing the proper size of the product to be developed, and if the software development team misjudges the size or scope of the project. The latter problem could create a product that is too small (rarely) or too large for the client, and could result in a loss of money to the development team because the cost of developing a larger product cannot be recouped from the client.

  • Staff size and experience risk. This would include appropriate and knowledgeable programmers to code the product as well as the cooperation of the entire software project team. It would also mean that the team has enough team members who are competent and able to complete the project.

  • Technology risk. Technology risk could occur if the product being developed is obsolete by the time it is ready to be sold. The opposite effect could also be a factor: if the product is so "new" that the end users would have problems using the system and resisting the changes made. A "new" technological product could also be so new that there may be problems using it. It would also include the complexity of the design of the system being developed.

3.4 Risk Table

The risk table provides a simple technique to view and analyze the risks associated with the project. The risks were listed and then categorized using the description of risks listed in section 3.3.1. The probability of each risk was then estimated and its impact on the development process was then assessed. A key to the impact values and categories appears at the end of the table.

Probability and Impact for Risk

Table A4 is the sorted version of Table A3 by probability and impact.

Table A4: Risks Table (sorted)

Risks

Category

Probability (%)

Impact

Customer will change or modify requirements

PS

70

2

Lack of sophistication of end users

CU

60

3

Users will not attend training

CU

50

2

Delivery deadline will be tightened

BU

50

2

End users resist system

BU

40

3

Server may not be able to handle larger number of users simultaneously

PS

30

1

Technology will not meet expectations

TE

30

1

Larger number of users than planned

PS

30

3

Lack of training of end users

CU

30

3

Inexperienced project team

ST

20

2

System (security and firewall) will be hacked

BU

15

2

Impact values:

1 - catastrophic

2 - critical

3 - marginal

4 - negligible

Category abbreviations:

BU - business impact risk

CU - customer characteristics risk

PS - process definition risk

ST - staff size and experience risk

TE - technology risk

The above table was sorted first by probability and then by impact value.