Risk Management W03

Risk Management

• All projects involve a degree of uncertainty.
• Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.
• A risk is a probability that some adverse circumstance will occur.
  • Project risks affect schedule or resources.
    • Loss of an experienced designer, finding a replacement will take
      time and the project will take longer.
  • Product risks affect the quality or performance of the software being developed.
    • Failure of a purchased component to perform as expected.
  • Business risks affect the organisation developing or procuring the software.
    • Competitor introduces a new product, sales forecasts may be too
      high.
• Risk management is particularly important for software projects because of the inherent uncertainties which most projects face :
  – Loosely defined requirements;
  – Difficulties in estimating time and resources required;
  – Dependence on individuals;
  – Requirements changes

Examples of Common Project, Product and Business risks

The risk management process

• Risk identification
  – Identify risks
• Risk analysis
  – Assess the likelihood and consequences of these risks
• Risk planning
  – Draw up plans to avoid or minimise the effects of the risk
• Risk monitoring
  – Monitor the risks throughout the project

• The outcome of the risk management process should be documented in a risk management plan which will be included in the project plan.
• Is an iterative process. As more information about the risks become available they have to be reanalysed and the priority may change. This will be reflected in changes to the plan.

Risk identification

• The starting point of risk management. It is concerned with identifying the risks that could pose a major threat to the project, the product being developed or the business
• Carried out as a team process using a brainstorming session or may be based on the manager’s experience. To help the process a list of possible risk types may be used

– Technology – risks which derive form the s/w or h/w being used as part of the system under development.
– People – risks which derive from the project team.
– Organisational – risks which derive from the organisational environment where the software is being developed.
– Tool – risks which derive from the CASE tools and other support s/w used to develop the system.
– Requirements – risks which derive from changes to customer requirements and the process of managing the requirements change.
– Estimation – risks which derive from the management estimates of the system characteristics and the resources required to build the system.

Examples of Different Types of Risk

Risk type – Technology
Possible risks…
The database used in the system cannot process as many transactions per second as expected. (1)
Reusable software components contain defects that mean they cannot be
reused as planned. (2)

Risk type – People
Possible risks…
It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)

Risk type – Organizational
Possible risks…
The organization is restructured so that different management are responsible
for the project. (6)
Organizational financial problems force reductions in the project budget. (7)

Risk type – Tools
Possible risks…
The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)

Risk type – Requirements
Possible risks…
Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)

Risk type – Estimation
Possible risks…
The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)

Risk Analysis

• Assess probability and seriousness of each risk based on judgement and experience from previous projects.
• Probability may be very low(10%) , low (10 -25 %), moderate (25-50%), high (50 -75%) or very high(>75%).
• Risk effects might be catastrophic (threaten the survival of the project), serious (would cause major delays), tolerable (delays are within allowed contingency) or insignificant.

1. Assign an expectation number between 1 and 10 based on the probability that the problem will occur, with 10 representing high probability, and 1 representing low probability.
2. Assign a number between 1 and 10 based on the impact of the problem on the project, with 10 representing high impact and 1 representing low impact.
3. Multiply the value produced in step (1) by the value produced in step (2) to produce the measure of severity for the problem.

Risk Types and Examples

Risk – Organizational financial problems force reductions in the project budget (7).
Probability – Low
Effects – Catastrophic

Risk – It is impossible to recruit staff with the skills required for the project (3).
Probability – High
Effects – Catastrophic

Risk – Key staff are ill at critical times in the project (4)
Probability – Moderate
Effects – Serious

Risk – Faults in reusable software components have to be repaired before these
components are reused. (2).
Probability – Moderate
Effects – Serious

Risk – Changes to requirements that require major design rework are proposed (10).
Probability – Moderate
Effects – Serious

Risk – The organization is restructured so that different management are responsible for the project (6).
Probability – High
Effects – Serious

Risk – The database used in the system cannot process as many transactions per
second as expected (1).
Probability – Moderate
Effects – Serious

Risk – The time required to develop the software is underestimated (12).
Probability – High
Effects – Serious

Risk – Software tools cannot be integrated (9).
Probability – High
Effects – Tolerable

Risk – Customers fail to understand the impact of requirements changes (11).
Probability – Moderate
Effects – Tolerable

Risk – Required training for staff is not available (5).
Probability – Moderate
Effects – Tolerable

Risk – The rate of defect repair is underestimated (13).
Probability – Moderate
Effects – Tolerable

Risk – The size of the software is underestimated (14).
Probability – High
Effects – Tolerable

Risk – Code generated by code generation tools is inefficient (8).
Probability – Moderate
Effects – Insignificant

Risk Analysis

Risk – It is impossible to recruit staff with the skills required for the project. (3)
Probability – 10
Effects – 10
Severity – 100

Risk – The organisation is restructured so that different management are responsible for the project. (6)
Probability – 10
Effects – 5
Severity – 50

Risk – The time required to develop the software is underestimated. (12)
Probability – 10
Effects – 5
Severity – 50

Risk – Software tools cannot work together an an integrated way. (9)
Probability – 10
Effects – 5
Severity – 50

Risk – The size of the software is underestimated. (14)
Probability – 10
Effects – 5
Severity – 50

Risk – Key staff are ill at critical times in the project. (4)
Probability – 5
Effects – 5
Severity – 25

Risk – Reusable software components contain defects that mean they cannot be used as planned. (2)
Probability – 5
Effects – 5
Severity – 25

Risk – Changes to requirements which require major design rework are proposed. (10)
Probability – 5
Effects – 5
Severity – 25

Risk – The database used in the system cannot process as many transactions per second as expected. (1)
Probability – 5
Effects – 5
Severity – 25

Risk – Customers fail to understand the impact of requirements changes. (11)
Probability – 5
Effects – 5
Severity – 25

Risk – Required training for staff is not available. (5)
Probability – 5
Effects – 5
Severity – 25

Risk – The rate of defect repair is underestimated. (13)
Probability – 5
Effects – 5
Severity – 25

Risk – Organisational financial problems force reductions in the project budget. (7)
Probability – 1
Effects – 10
Severity – 10

Risk – The code generated by software code generation tools is inefficient. (9)
Probability – 5
Effects – 1
Severity – 5

Strategies to Help Manage Risk

Risk – Organizational financial problems
Strategy – Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost-effective

Risk – Recruitment problems
Strategy – Alert customer to potential difficulties and the possibility of delays;
investigate buying-in components.

Risk – Staff illness
Strategy – Reorganize team so that there is more overlap of work and people, therefore, understand each other’s jobs.

Risk – Defective components 
Strategy – Replace potentially defective components with bought-in components of
known reliability.

Risk – Requirements changes
Strategy – Derive traceability information to assess requirements change impact;
maximize information hiding in the design.

Risk – Organizational restructuring 
Strategy – Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.

Risk – Database performance
Strategy – Investigate the possibility of buying a higher-performance database.

Risk – Underestimated development time
Strategy – Investigate buying-in components; investigate the use of a program generator.

Risk Planning

• Consider each risk and develop a strategy to manage that risk.
• Avoidance strategies
  – The probability that the risk will arise is reduced. Replace potentially defective components with components of known reliability.
• Minimisation strategies
  – The impact of the risk on the project or product will be reduced. Organise the team so that work overlaps and people understand each other’s job.
• Contingency plans
  – If the risk arises, contingency plans are plans to deal with that risk. Prepare a briefing document for senior management.

Risk Monitoring

• Assess each identified risks regularly to decide whether or not it is becoming less or more probable
• Also assess whether the effects of the risk have changed
• Each key risk should be discussed at management progress meetings

Risk factors

Risk type – Technology
Potential indicators – Late delivery of hardware or support software; many reported technology problems.

Risk type – People
Potential indicators – Poor staff morale; poor relationships amongst team members; high staff turnover.

Risk type – Organizational
Potential indicators – Organizational gossip; lack of action by senior management.

Risk type – Tools
Potential indicators – Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations.

Risk type – Requirements
Potential indicators – Many requirements change requests; customer complaints.

Risk type – Estimation
Potential indicators – Failure to meet agreed schedule; failure to clear reported defects.

Example

Letterkenny I.T. student medical centre has requested the automation of a patient tracking system that traces each patient throughout their stay in college for each visit to the facility. Each time a student visits the medical centre the appointment details are recorded along with a diagnosis and results of tests etc. performed. It is proposed that the new system will interface with the existing hospital database to automatically receive these test results.

The requirements of the system are not completely documented and users have indicated a reluctance to spend time on the project. Software For You has a number of programmers with a lot of experience in developing this type of product and indeed plan to reuse some code from these projects. In addition, new CASE tools are to be employed on the project. Software For You has only agreed to take on the project because things are fairly slack for the company at the minute and as it is a fixed price contract it is essential that there is no overrun in the project schedule.

Identify possible risks for this project.

• Interface with hospital database Unknown requirements.
• Users unwilling to commit to project.
• Code reuse.
• New CASE tools may not perform as expected.
• Project may be underestimated

Example

Your company has been selected to develop a project with the following characteristics:

• rapidly changing requirements due to feedback and unknown requirements;
• the need for short development cycles so that a stable version of the software is available as soon as possible (in weeks) for demonstration and delivery to the customer;
• software that will expand in scope over time as additional functionality is added.
• a strong need to deliver software on fixed schedules;
• people leaving the company (a number of software houses have located in the region and are actively recruiting staff);
• typically very experienced development personnel but initially inexperienced management, you are managing your first project.

Identify possible risks for the project and suggest an appropriate
strategy to deal with each.

Possible risks

• Changes to requirements which require major design rework.
• Staff leave at critical times
• Time to develop software is underestimated
• Inexperienced managers may not be able to manage

Strategies for the above:

• Requirements Changes – Derive traceability information to assess requirements change impact, maximise information hiding in the design.
• Staff leaving – Reorganise team so there is more overlap of work and people understand each other’s jobs.
• Time underestimates – Investigate buying in components, investigate the use of a code generator.