2.4 Risk Management

What is a software risk?

A risk is an event with a probability of occurrence and an impact if it occurs. Risk is forward-looking: we cannot manage past problems, only mitigate future ones.

Risk Exposure = Probability × Impact

Examples:

• Probability that the lead developer resigns mid-project: 20%
• Impact if she resigns: 6 weeks of recovery + ₹15 lakh
• Risk exposure: 0.20 × ₹15,00,000 = ₹3,00,000 (the expected cost)

A project usually has 30–50 identifiable risks. The job of risk management is to identify, assess and control them before they become crises.

---

Categories of risk (Boehm's "Top 10")

Barry Boehm identified the top ten software project risk items:

---

Types of Risk

The IPU textbook (K.K. Aggarwal) classifies risks into three broad types:

1. Project risks

Threaten the schedule, budget, resources, or staff. They concern managing the project.

Examples: turnover, scope creep, budget cuts, stakeholder change, missed dependencies.

2. Technical risks

Threaten the quality and timeliness of the software being produced. They concern building the right thing well.

Examples: untested technology, ambiguous requirements, design flaws, interface incompatibility, obsolescence.

3. Business risks

Threaten the viability of the software itself. They concern whether the product should be built.

---

Known, predictable, unpredictable risks

Risk management focuses on the first two; the third is handled by contingency reserves and insurance.

---

Risk Management activities — the lifecycle

1. Risk Identification

• Brainstorming with the team
• Checklists of common risks (Boehm's Top 10)
• Decomposition (look at each project component, ask "what could go wrong here?")
• Assumption analysis (what must be true for the project to succeed? — if it isn't, it's a risk)
• SWOT analysis (Strengths, Weaknesses, Opportunities, Threats)

Output: Risk Register — a numbered list of risks.

2. Risk Analysis (Assessment)

For each risk, estimate:

• Probability (Low / Medium / High, or 0–1 numeric)
• Impact (Low / Medium / High, or in days / rupees)
• Risk Exposure = Probability × Impact

Risk Matrix (heat map)

              Impact →
              Low    Medium    High    Catastrophic
Probability
High          Med    High      Crit    Crit
Medium        Low    Med       High    Crit
Low           Low    Low       Med     High

Risks in the High and Critical zones get priority attention.

3. Risk Planning (Mitigation Strategies)

For each significant risk, choose a strategy:

4. Risk Monitoring

• Track risks regularly (weekly status meeting)
• Maintain risk indicators — early-warning signals
• Update the risk register
• Trigger contingency plans when indicators fire

---

RMMM Plan (Risk Mitigation, Monitoring & Management) — IPU favourite

The RMMM is the consolidated risk-management document. For each risk it specifies:

Risk Information Sheet
─────────────────────────────────────────────────────
Risk ID:           R-007
Risk Description:  Lead developer may resign mid-project
Probability:       0.20  (Low–Medium)
Impact:            High  (6 weeks recovery, ₹15 lakh)
Risk Exposure:     ₹3,00,000

Mitigation:
  - Pair-program critical modules so knowledge is shared
  - Document architecture in ADRs
  - Offer retention bonus on project completion

Monitoring:
  - Weekly 1-on-1 with lead developer
  - Trigger indicators: requesting leave for interviews,
    decreased participation in stand-ups

Management (contingency plan if it happens):
  - Activate backup architect (pre-identified)
  - Re-plan with 4-week schedule slip
  - Inform stakeholders within 24 hours

Output: a risk register with one such sheet per significant risk.

---

Risk components (Pressman)

Pressman decomposes risk impact into four components:

These map roughly to the quadruple constraint of project management (scope, cost, schedule, quality).

---

Risk projection (impact estimation)

For each risk, estimate impact across the four components on a 4-point scale:

Multiply by the probability to rank.

---

Example risk register (Library System)

Total expected slippage = 6.0 weeks → add as contingency reserve.

---

Key Terms — Lesson 2.4

The terms below define the risk-management vocabulary used in every Unit-II PYQ on RMMM, risk identification, and mitigation strategy.

Risk — An uncertain event with a probability of occurrence and an impact if it occurs. Risks are forward-looking: a problem that has already materialised is an issue, not a risk. The defining property of risk is that it can still be avoided, mitigated, transferred, or accepted before it becomes reality.

Risk Exposure (Risk Magnitude) — The expected cost of a risk, computed as Probability × Impact. A 20%-probable risk costing ₹15 lakh has an exposure of ₹3 lakh. Risk exposure lets you rank risks on a single comparable scale and is the basis for contingency-reserve sizing.

Project Risk — A risk that threatens the schedule, budget, resources, or staffing — turnover, scope creep, missed dependencies, stakeholder change. Project risks concern managing the project.

Technical Risk — A risk that threatens the quality or timeliness of the product — untested technology, ambiguous requirements, design flaws, interface incompatibility, performance shortfall. Technical risks concern building the right thing well.

Business Risk — A risk that threatens the viability of the product itself — will customers want it (market risk), does it fit the company's direction (strategic risk), can sales sell it, will senior management keep funding it. Business risks concern whether the product should be built at all.

Known Risk — A risk that is visible from careful inspection of the project plan, environment, and contractual context. Unrealistic deadlines, unsigned-off SRS, vendor delays you can see in the contract — known risks are the easiest to manage because they are visible.

Predictable Risk — A risk that is anticipated by extrapolation from past project experience — staff turnover rates, customer-communication gaps, integration delays with the IT department. Predictable risks don't show on the current project plan but every experienced team has met them before.

Unpredictable Risk — A risk that cannot be reasonably foreseen — a pandemic, a vendor going bankrupt, a sudden regulatory change. Risk management cannot eliminate unpredictable risks; mitigations include schedule slack, modular design, diversified vendors, and insurance.

Boehm's Top 10 Software Risks — Barry Boehm's classic 1991 list: (1) personnel shortfalls, (2) unrealistic schedules/budgets, (3) wrong functions, (4) wrong user interface, (5) gold plating, (6) continuous requirements changes, (7) externally furnished component shortfalls, (8) externally performed task shortfalls, (9) real-time performance shortfalls, (10) straining computer-science capabilities. Still the starting checklist for most projects.

Risk Identification — The first activity of the risk-management lifecycle: producing the list of risks the project faces. Techniques include brainstorming, checklists (Boehm's Top 10), decomposition (look at each component, ask "what could go wrong?"), assumption analysis ("if this assumption is false, it is a risk"), and SWOT analysis.

Risk Analysis (Assessment) — Estimating, for each identified risk, its probability and impact, and computing its exposure. The output is a ranked risk list. Modern projects use a risk matrix / heat map to visualise probability × impact combinations.

Risk Matrix / Heat Map — A 2D grid plotting probability against impact, with cells colour-coded by combined severity (Low, Medium, High, Critical). Risks in the High and Critical zones get priority attention; risks in the Low zone are usually accepted or just monitored.

Risk Mitigation — Actions taken to reduce the probability of a risk occurring or reduce its impact if it does. Pair-programming critical modules mitigates the key-person-leaves risk by spreading knowledge. Mitigation has a cost, which is weighed against the risk exposure it removes.

Risk Avoidance — A strategy that eliminates the risk source entirely — for example, dropping an experimental feature whose technical risk is too high. Avoidance is the most reliable strategy but may sacrifice value.

Risk Transfer — Passing the risk to another party that is better able to bear it — buying insurance, outsourcing a risky component to a specialist, signing a fixed-price contract with a vendor. Transfer always has a cost — the price of risk-bearing — but it removes uncertainty from your project.

Risk Acceptance — A conscious decision to acknowledge a risk and absorb the consequences if it materialises. Acceptance is appropriate when the exposure is small or mitigation cost exceeds exposure. Accepted risks are still tracked, with contingency reserves sized to cover them.

Risk Monitoring — Continuous tracking of identified risks and watching for new ones. Each significant risk has risk indicators — early-warning signals (lead developer requesting leave for interviews, weekly velocity dropping for 3 sprints) — that trigger the contingency plan.

Risk Register — The master document listing all identified risks, each with ID, description, probability, impact, exposure, mitigation strategy, owner, and current status. The risk register is reviewed weekly and updated continuously.

RMMM Plan (Risk Mitigation, Monitoring, and Management) — Pressman's framework for the consolidated risk-management document — for each significant risk, one risk-information sheet captures the risk description, probability, impact, exposure, mitigation actions, monitoring indicators, and contingency plan. The IPU favourite.

Risk-Information Sheet — One page per significant risk, documenting (in the RMMM format) — risk ID, description, probability, impact, exposure, mitigation, monitoring indicators, and contingency plan. The atomic unit of risk-management documentation.

Contingency Reserve / Buffer — Schedule or budget set aside specifically to absorb the impact of identified risks if they materialise. Contingency is sized from the total expected slippage (sum of P×I across the register) and is separate from management reserve (for unknown unknowns).

Issue — A risk that has materialised — its probability is now 100% and the impact is being felt. Risks move from the risk register to the issue log when they happen. Issue management is reactive (containment, remediation); risk management is proactive.

Performance / Cost / Support / Schedule Risk (Pressman) — Pressman's four-component decomposition of risk impact: performance (will the product meet requirements?), cost (will the project finish on budget?), support (will the product be maintainable?), schedule (will the project finish on time?). Maps to the project-management "quadruple constraint" of scope, cost, schedule, quality.

Risk Indicator / Risk Trigger — A measurable signal that a risk is becoming more likely or about to materialise. Examples: lead developer's leave-day count increasing, third-party vendor missing two milestones, sprint velocity falling for several sprints in a row. Indicators are what risk monitoring actively watches for.

Schedule Slack / Float — The amount of time a task can be delayed without delaying the overall project. Risk management uses slack as a buffer for absorbing minor schedule risks; project management's Critical Path Method is the formal way to compute task slack.

---

Study deep

1. Probability times impact, not just probability. A 90%-probable but tiny risk matters less than a 5%-probable but catastrophic one (e.g. nuclear plant control software). The exposure formula keeps both in view.

1. Risk vs Issue. A risk is a future possibility; an issue is something that has already happened. The same item moves from the risk register to the issue log when its probability hits 100%.

1. The "unknown unknowns" problem. Donald Rumsfeld's framework: known knowns, known unknowns, unknown unknowns. Risk management addresses the middle category; the last is handled by resilience (slack in schedule, modular design, broad testing).

1. Risk reviews must happen on a schedule. Weekly risk review is the minimum. New risks emerge; old risks change probability; mitigations work or fail. A static risk register is worthless.

1. Risk culture. Some teams hide risks ("don't bring me problems, bring me solutions"). Healthy teams surface risks early — even if they have no solution yet. The Project Manager's job is to invite risk reporting, not punish it.

PYQ pattern: "What is risk management? Explain RMMM plan with an example." — Define risk, give formula (Exposure = P × I), describe the 4 activities (identification, analysis, planning, monitoring), end with a sample risk-information sheet (R-007 style).