Risk Management

Risk Identification

One method for identifying risk is to create a risk item checklist(in this we have included predictable risks for generic subcategories)

Product Size – risk associated with the overall size of the s/w to be built.

Business impact – risk associated with constraints imposed by management or the marketplace .

Customer characteristics – risk associated with the communication of customer and the developer's ability.

Process definition – risk associated with the degree to which the software process has been defined.

Development environment – risk associated with the availability and quality of the tool to be used to build a product.

Technology to be build – risk associated with the complexity of the system to be built.

Staff size and experience – risk associated with the overall technical and project experience of the s/w engineers who will do the work.

Assessing overall project Risk

Following questions arranged in the relative importance to the success of a project :-

1) Have top software and customer managers formally committed to support the project ?

2) Are end-users enthusiastically committed to the project and the system/product to be build?

3) Are requirement fully understood by the software engineering team and its customers?

4) Have customer been involved fully in the definition of requirement ?

5) Do end-users have realistic expectations?

6) Is project scope stable ?

7) Does the software engineering team have the right mix of skills?

8) Are project requirement stable ?

9) Does the project team have experience with the technology to be implemented?

10) Is the number of people on the project team adequate to do the job?

11) Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

“The degree to which the project is at risk is directly proportional to the number of negative response to these questions”

Risk Components and Drivers

“The U.S Air Force[AFC88] has written a pamphlet that contains excellent guidelines for software risk identification.”

The project manager identify the risk drivers that affect software risk components –

* Performance Risk – degree of uncertainty that the product will meet its requirements.

* Cost Risk – the degree of uncertainty that project budget will be maintained.

* Support Risk – the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.

* Schedule Risk – the degree of uncertainty that the project schedule will be maintained and product will be delivered on time.

The impact of each risk driver on the risk component is divided into one of four impact levels

Negligible , marginal, critical , or catastrophic [refer a table in a book page 732]

Risk Projection

It is also called risk estimation.

Risk rate in two ways –

Likelihood or probability that the risk is real

Consequences of the problems associated with the risk

Four risk projection steps : [By project manager & Technical staff]

Establish a scale that reflects the perceived likelihood of a risk.

Delineate the consequences of the risk.

Estimate the impact of risk on the project and the product.

Note the overall accuracy of the risk projection , to avoid misunderstanding.

No s/w team handle the risk with same degree of rigor.

Contents of a Risk Table

It consists of five column

Risk Summary – short description of the risk

Risk Category – one of seven risk categories

(slide risk identification)

Probability – estimation of risk occurrence based on group input

Impact – 1) catastrophic 2) critical 3) Marginal 4) negligible

RMMM – Pointer to the paragraph in the Risk Mitigation , Monitoring and Management Plan.

Developing a Risk Table

List all risks in the first column (by way of the help of the risk item checklist)

Mark the category of each risk.

Estimate the probability of each risk occurring

Assess the impact of each risk based on an averaging the four risk components to determine an overall impact value

Sort the rows by probability and impact in descending order

Draw horizontal cutoff line in the table that indicates the risk that will be given further attention

Assessing Risk Impact Three factor affect the consequences that are likely if a risk does occur

Its nature – This indicates the problem that are likely if the risk occur.

Its scope – This combines the severity of the risk(how serious) with its overall distribution (how mush of the project will be affected)

Its timing – when and for how long the impact will be felt.

Ex: poorly external interface to customer hardware(technical risk)

The overall risk exposure formula is RE=P x C

P= probability of occurrence of a risk

C= is the cost to the project should the risk occur.

Example [steps followed by s/w team]

Risk Identification – Only 70% of the s/w component schedule for reuse

Risk Probability – 80 %

Risk Impact -- 60 reusable component were planned which is 70 % of the total component , then 18 component have to developed from scratch.

Avg. component have 100 LOC , per LOC $10

then RE = .80 x (100x10x18)=

Risk Mitigation, Monitoring and Management

• Risk Referent Level [refer soft.pdf]

• RMMM has single goal – to assist the project team in development a strategy for developing with risk

• An effective strategy must consider three issues:

• Risk Avoidance(i.e mitigation)

• Risk monitoring

• Risk Management and contingency planning

Example Cont..

• Suppose

• high staff turnover is noted as a project risk ri.

• Based on the past history the likelihood li.

• Projected Impact xi.

Cont…

• Develop a strategy to mitigates the risk and reducing turnover.

• Meet the current staff to determine causes for turnover

• Mitigate those causes that are under our control before the project starts

• Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave

• Organize project teams so that information about each development activity is widely dispersed

• Define documentation standards and establish mechanisms to ensure that documents are developed in a timely manner

• Conduct peer reviews of all work (so that more than one person is "up to speed")

• Assign a backup staff member for every critical technologist