Module 6

1. Risk – Definition
Risk is “an uncertain event or condition that, if it occurs, has a positive or negative
effect on project objectives.”

PRINCE2 defines risk as “uncertainty of outcome, whether positive opportunity or

negative threat.”

The authors emphasize:

Risk is always about the future.

Risk has both a cause (hazard) and a consequence (impact).

Plans are built on assumptions, and an incorrect assumption creates risk.

2. Nature of Risks
Risks occur due to uncertainty in software projects.

Categories highlighted in the book:

Technical risks – new/unproven technology, integration problems.

People risks – lack of skills, staff turnover, motivation issues.

Organizational risks – resource conflicts, political or management changes.

Business/project risks – delivered system may not meet business needs.

External risks – regulatory changes, suppliers, environment.

3. Managing Risks
1. Identify risks – brainstorm, checklists, past projects.

2. Analyse risks – estimate probability and impact.

3. Plan responses – avoid, reduce, transfer, accept.

4. Monitor and control – track risks in a risk register and update regularly.

Risk planning takes place especially in Step 3 (analyse project characteristics) and
Step 6 (identify activity risks) of Stepwise planning.

Risk Identification Methods

Module 6 1
 1. Schedule-based Identification

Analyse the project schedule to find tasks with tight deadlines or dependencies.

Risks: slippage of critical tasks, unrealistic milestones, resource conflicts.

2. Brainstorming Sessions

Conduct structured discussions with the project team.

Encourages creative thinking to identify potential risks.

Works best when guided by a facilitator and supported with past project data.

3. Checklist Approach

Use a pre-prepared list of common risks (technical, people, organizational,

estimation).

Ensures no typical risks are overlooked.

Limitation: may miss project-specific risks.

4. Expert Judgment

Consult experienced project managers or subject-matter experts.

Experts can spot risks based on previous projects.

Often used along with Delphi technique for consensus.

5. Stakeholder Interviews

Talk to clients, end-users, and sponsors.

Identifies risks related to requirements, expectations, and business constraints.

Helps uncover hidden risks not visible to the technical team.

5. Risk Analysis
Quantitative approach: Risk Exposure = Probability × Potential Loss.

Qualitative approach: Use descriptors (high, medium, low).

The book provides tables:

Table 7.3 Probability levels:

High > 50%

Significant 30–50%

Moderate 10–29%

Module 6 2
 Low < 10%

Table 7.4 Impact levels (on cost):

High > 30% cost overrun

Significant 20–29%

Moderate 10–19%

Low < 10%

Risks are ranked by exposure, focusing on the top ~10 in large projects.

Four Risk Response Strategies

1. Risk Acceptance
Definition: Do nothing beyond monitoring; accept the possibility that the risk may
occur.

When used:

Module 6 3
 If the consequences are small.

If the cost of dealing with the risk is greater than the potential loss.

Acceptance is valid only if management is aware of the risk and is prepared to live with
it. Sometimes paired with a contingency plan (e.g., budget reserve).

2. Risk Avoidance
Definition: Alter the project plan to remove the risk entirely.

Examples from the book:

Use a proven technology instead of an untested one.

Buy an off-the-shelf package instead of building a risky bespoke system.

Avoidance often means changing project scope, technology, or approach.

3. Risk Reduction (Mitigation)

Definition: Take action to lower the probability of the risk happening, or reduce its
impact if it does.

Examples:

Training staff → reduces risk of poor performance.

Prototyping → reduces uncertainty about requirements/technology.

Extra testing/reviews → reduces risk of errors.

Cross-training team members → reduces impact of staff leaving.

Reduction (lowering probability).

Mitigation (lessening impact).

Includes Risk Reduction Leverage (RRL) formula to check cost-effectiveness.

4. Risk Transfer
Definition: Shift responsibility for the risk to another party.

How:

Insurance (e.g., equipment damage).

Outsourcing risky work to a supplier.

Module 6 4
 Using fixed-price contracts.

The supplier/insurer may charge a premium, but may also have advantages (specialist
knowledge, higher productivity)

Evaluating Risks to Schedule

a) PERT (Program Evaluation and Review Technique)
Each activity is given 3 estimates: optimistic (a), most likely (m), pessimistic (b).

Expected time:
te=a+4m+b/6

Standard deviation:
s=b−a/6

Variances add along a path; project variance = sum of variances of critical activities.

Probability of meeting a deadline is found using z-values and the normal distribution.

b) Monte Carlo Simulation

A probabilistic simulation that models uncertainty in activity durations.

Process:

1. Assign probability distributions (e.g., triangular, beta) to activity times.

2. Randomly sample durations thousands of times.

3. Build distribution of possible project completion dates.

Output: probability curve showing risk of missing deadlines.

More accurate than PERT because it considers all paths, not just the critical path.

Schedule Risk Index (SRI)

Purpose: Measures the degree of schedule risk in a project network.

Definition in the book:

SRI=Sum of critical path expected durations/Sum of expected durations of all paths

Interpretation:

If SRI is low, the project has a higher risk of delay because non-critical paths could
easily become critical.

Module 6 5
 If SRI is high (close to 1), most of the effort lies on the critical path, meaning fewer
chances for hidden delays elsewhere.

Book’s point: SRI provides a numerical index that allows comparison between different
projects or different versions of a plan to see which schedule is riskier.

Performance Index (PI)

Purpose: Used to check whether a target completion time is realistically achievable
given expected durations.

PI=Target Duration/Expected Project Duration

Interpretation:

If PI ≥ 1 → project schedule is feasible.

If PI < 1 → target is unrealistic, meaning it is unlikely the project can finish within
the planned time.

PI helps managers understand whether deadlines are achievable or whether they are
set too aggressively

Module 6 6
Module 6 7