Page 197 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT

Unit 10: Risk Management

 Risk Monitoring and Control Notes
 Risk Mitigation

10.5.1 Risk Identification

In this stage, we identify and name the risks. The best approach is a workshop with business and
IT people to carry out the identification. Use a combination of brainstorming and reviewing of
standard risk lists.
There are different sorts of risks and we need to decide on a project by project basis what to do
about each type.
Business risks are ongoing risks that are best handled by the business. An example is that if the
project cannot meet end of financial year deadline, the business area may need to retain their
existing accounting system for another year. The response is likely to be a contingency plan
developed by the business, to use the existing system for another year.

Generic risks are risks to all projects. For example the risk that business user might not be
available and requirements may be incomplete. Each organization will develop standard
responses to generic risks.
Risks should be defined in two parts. The first is the cause of the situation (Vendor not meeting
deadline, Business users not available, etc.). The second part is the impact (Budget will be
exceeded, Milestones not achieved, etc.).

Notes Hence a risk might be defined as “The vendor not meeting deadline will mean that
budget will be exceeded”. If this format is used, it is easy to remove duplicates, and
understand the risk.

10.5.2 Risk Quantification

Risk need to be quantified in two dimensions. The impact of the risk needs to be assessed. The
probability of the risk occurring needs to be assessed. For simplicity, rate each on a 1 to 4 scale. The
larger the number, the larger the impact or probability. By using a matrix, a priority can be established.

Figure 10.6

LOVELY PROFESSIONAL UNIVERSITY 191