Risk Management

What a Risk Is exam

Before you can manage risks you have to recognise one. The problem is that everyday English uses "risk" loosely: for anything bad, for anything uncertain, even for problems that have already happened. This section pins the word down, because the exam asks for the definition and for the difference between a risk, an uncertainty and an issue.

Two definitions, and the one this subject uses

The Week 3 (W03) slides give two definitions. Webster's dictionary calls a risk a "possible future event that has negative results": a hazard, a peril, an exposure to loss. In that view a risk is always bad news.

The project objectives are what the project has promised to deliver: its scope, by a certain time, for a certain cost, at a certain quality. A threat would push one of those the wrong way; an opportunity would push one the right way. For example, the chance that a key developer resigns mid-project is a threat to the schedule, while the chance that a hardware maker offers to co-fund the project is an opportunity for its budget.

Risk versus uncertainty versus issue exam

Uncertainty is a lack of complete knowledge about an outcome: the probability p of the event is somewhere strictly between 0 and 1. You don't know who will win this weekend's football match, so the result is uncertain. But unless you have something riding on it, it is not a risk to you.

A risk is an uncertainty that has an impact on you. The moment you place a bet on the match, the same uncertain result becomes a risk, because now it can cost you (or win you) money. Hence the slogan worth remembering: risk comes from uncertainty, but not every uncertainty is a risk.

At the other end, once an event is certain (p = 1, it is happening or has happened), it is no longer a risk but an issue: a problem to deal with now, not a possibility to plan for.

The lecture polls tested this with two scenarios, and both are risks. A software library with a history of occasional bugs might fail in your system (uncertain, and it would affect you). A 25% chance that a new regulation will affect your software is uncertain and would affect you too.

When should you treat an event as a risk?

The slides give three characteristics. Treat an event as a risk when (1) its probability is greater than 0, (2) it would have an impact on the project, and (3) you have some control over the event or its outcome, so that managing it can make a difference.

Generic and product-specific risks

Pressman, a standard software-engineering author the slides draw on, separates two families. Generic risks threaten every software project, whatever it builds: staff turnover, budget pressure, schedule pressure. Product-specific risks come from this product and its technology, so only people who understand the product and technology can spot them. In the Medic case (the tutorials' surgical simulator, introduced properly in 4.13), whether the haptic hardware can respond fast enough is a product-specific risk.

Check yourselfDefine risk and distinguish it from uncertainty. (Guide self-test Q1)

A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on the project objectives (PMBOK). Uncertainty is incomplete knowledge of an outcome (0 < p < 1). A risk is an uncertainty that has an impact on you: a football result is merely uncertain until you bet on it, and then it is a risk. Every risk comes from uncertainty, but not every uncertainty is a risk.

Check yourselfThe database server crashed this morning and the team is restoring it. On the risk register, what should this be called?

1. A threat with high probability
2. An issue
3. An uncertainty
4. A product-specific opportunity

B. The event has happened, so p = 1: it is an issue, to be dealt with now. A risk needs p strictly below 1. (The risk that it crashes again is still a risk.) Calling an issue a risk is one of this Part's listed pitfalls.

Check yourselfSelect all statements that are correct under the definitions this subject uses.

1. Every uncertainty is a risk.
2. A risk can have a positive effect on the project objectives.
3. An event with probability 1 is an issue rather than a risk.
4. Product-specific risks are the ones every software project shares.

B and C. A is backwards: every risk comes from uncertainty, but an uncertainty is a risk only if it has an impact on you. D describes generic risks; product-specific ones come from this product's technology.

Why Manage Risk Formally

If risks are just "things that might go wrong", why not deal with them when they happen? Because by then they are issues, and fixing a problem after it has struck is when it costs most. Projects face many significant business, project and product risks at once, so they need a planned process, not improvisation.

Boehm's view: risk drives the whole process

Barry Boehm (1988), who created the spiral model (Part II), goes further. For him risk is not one activity among many; it decides what the project does next. Each loop of his spiral attacks the highest remaining risk, so the dominant risk picks the next kind of step. It also answers a question every project faces: how much specification, testing or prototyping is "enough"? Boehm's answer is that it depends on "the level of risk incurred by not doing enough".

Check yourselfState the goal of risk management as the slides phrase it, and say what a "firefighting" team gets wrong.

The goal is "minimising the impact of potential negative risks while maximising the impact of potential positive risks". A firefighting team has no planned process: it deals with problems only after they occur, when they have become issues and are most expensive to fix. It also never looks for opportunities, so it misses the second half of the goal.

Kinds of Risk exam

A blank page is a poor place to start looking for risks. Sorting risks into kinds gives you categories to work through, so you don't forget a whole area, and it tells you who should own each risk. The slides sort risks three ways: by what they affect, by where they come from, and by a checklist of sources. Boehm adds a ready-made top-10 list.

By what they affect: project, product, business

This is the classification the exam asks for most. What separates the three kinds is what the risk would damage:

(A CASE tool is a computer-aided software engineering tool, such as a design or code-generation tool.) The kinds are not exclusive: one risk can be two kinds at once. A change in requirements, a delay in the specification, or a product that turns out bigger than estimated hurts both the plan (project) and what gets built (product).

Check yourselfA rival company may release a similar app three months before yours. Which kind of risk is this?

1. Project risk
2. Product risk
3. Business risk
4. Technology risk only

C. It threatens the economic success of the project (sales, market share), not the plan or the quality of the software. "Competitor launches first" is one of the slides' own business-risk examples.

By source: where the risk comes from

The slides also classify risk types by source. This view is useful when brainstorming, because each source is a question to ask ("what could go wrong with our tools?").

A checklist of seven risk sources

A further slide groups the risk sources into seven categories, handy as a checklist when reviewing a project:

A stakeholder is anyone who affects or is affected by the project: clients, users, sponsors, the team, regulators. Contingency here means spare time or money held back for things going wrong. The three scope risks are easiest to tell apart as pictures of how the agreed scope moves over time:

Boehm's top-10 risk items (1988)

Boehm distilled his experience into a top-10 list of the risks that most often sink software projects. It works as a ready-made checklist, and for several items he names a typical technique for handling it.

Check yourselfSelect all that are examples of a project risk in the slides' sense.

1. A key developer resigns halfway through.
2. The required hardware is delivered three weeks late.
3. Nobody wants to buy the finished product.
4. The code generator produces inefficient code.

A and B. Both hit the plan (personnel and schedule). C is a business risk (economic success). D is a product risk (quality or performance; the slides' "CASE tools underperform"); by source it is a tools risk.

Check yourselfA client keeps adding "just one more small report" each fortnight. Which scope risk is this, and how does it differ from scope leap?

It is scope creep: gradual additions. Scope leap is one sudden, large change (say, the client announces the system must now also handle billing). Scope grope is different again: the scope can't be pinned down at all.

The Risk Management Process exam

Knowing what risks are doesn't tell you what to do. The W03 slides answer with a process of five steps, each producing something the next step uses. The process is not run once at the start: monitoring keeps turning up new risks and changed estimates, which go back into identification, so it cycles for the whole life of the project.

1. Plan. Decide how to approach and plan the risk management activities.
2. Identify. Find the possible risks.
3. Analyse and assess (qualitatively and quantitatively). Set the relative priorities of the risks.
4. Respond (take action). Reduce each risk's likelihood or impact.
5. Monitor and control. Detect each risk's ongoing status and control it effectively and efficiently.

Other versions of the same process

You may meet the process under other names. A Sommerville/Pressman slide names each step by its output, and Boehm (1991) groups the steps under two headings, assessment (working out what the risks are) and control (doing something about them). They line up like this:

Check yourselfWhich ordering of the W03 risk management steps is correct?

1. Identify → Plan → Analyse and assess → Respond → Monitor and control
2. Plan → Identify → Analyse and assess → Respond → Monitor and control
3. Plan → Identify → Respond → Analyse and assess → Monitor and control
4. Identify → Analyse and assess → Plan → Respond → Monitor and control

B. You decide how to manage risk (Plan) before looking for risks, and you must analyse them before you can decide which ones to respond to. D is tempting because Sommerville/Pressman call the response step "planning", but in the W03 version "Plan" is the first step and produces the Risk Management Plan.

Step 1 · Plan: the Risk Management Plan exam

If every team member invented their own way of scoring and tracking risks, nobody could compare or act on them. The first step therefore produces one agreed rulebook: the Risk Management Plan (RMP), which sets out the procedures for managing risk throughout the project.

The team reviews the plan and applies the approach of the organisation and of the sponsor (the senior person who funds the project and owns its business case). How much detail it contains scales with the project: a small internal tool needs a page, a hospital system much more.

Contingency plans and fall-back plans

The last two fields work as a pair, one backing up the other. A contingency plan lists the actions to take if a risk occurs. A fall-back plan says what to do if the contingency plan fails.

Boehm's simpler RMP (1988)

Boehm's version of the plan is lighter and can be used with any lifecycle. Identify the project's top-10 risks and plan how to resolve each one. Then update the list monthly, report its status in monthly reviews against last month's ranking, and take corrective action.

Check yourselfDistinguish a contingency plan from a fall-back plan.

A contingency plan is the set of actions to take if a risk occurs. A fall-back plan is what to do if the contingency plan itself fails. Both are fields of the slides' RMP template, and the fall-back backs up the contingency.

Check yourselfSelect all items that are fields of the slides' Risk Management Plan template.

1. Scales for risk probability and impact, with matrix thresholds
2. The Sprint Goal for each Sprint
3. Roles and responsibilities
4. Budget and schedule for risk work

A, C and D. The template also holds the methodology, the risk categories, tracking and documentation, and the contingency and fall-back plans. The Sprint Goal is a Scrum planning artefact, not part of an RMP.

Step 2 · Identify exam

You can only manage risks you have found, and the risks nobody thought of are the ones that hurt most. Identification therefore uses deliberate techniques rather than whatever comes to mind, and it writes each risk in a form precise enough to analyse.

Six identification techniques exam

The slides list six techniques. Each has its own strength or limitation, which is what MCQs test.

1. Pondering. One person thinks the risks through with "pencil and paper". It is a typical first step, but it is limited by one person's knowledge.
2. Interviews and questionnaires tap the knowledge of stakeholders and domain experts. They are needed because the risk manager rarely knows enough alone.
3. Brainstorming. The team works through a risk framework or the WBS (work breakdown structure: the project's tree of deliverables and tasks, Part VIII). Everyone contributes ideas first, and only then does the group evaluate them.
4. Checklists are risk drivers collected from past experience and used as prompts. Their weakness is that they miss novel risks.
5. Delphi technique. Experts identify risks individually, then see each other's answers anonymously and revise their own, repeating until they reach consensus. The anonymity stops dominant voices from taking over.
6. SWOT analysis looks at internal Strengths and Weaknesses (advantages and disadvantages) and external Opportunities and Threats. Because it includes opportunities, it also finds positive risks.

The Delphi technique, round by round

Why go to the trouble of anonymity? In an ordinary meeting the most senior or most confident person speaks first and everyone else drifts toward their view. Delphi is built to stop that, as the stepper shows.

SWOT: looking inside and outside

Writing a risk statement exam

A risk written as a bare noun ("the UI", "staff loss") can't be scored, because nobody knows what exactly would happen or how bad it would be. The tutorial therefore requires each risk to be written in a fixed three-part form: ACTION – CONSEQUENCE – IMPACT. An alternative form is EVENT – CAUSED BY – CONSEQUENCES.

The slides' running example: a third-party application

The W03 slides follow one example through every step, so it is worth knowing well. A third-party application (software bought from another company) is being developed in parallel with our system, which depends on it. Three things could go wrong:

Check yourselfWhich identification technique's main weakness is that it misses novel risks?

1. Delphi technique
2. Checklists
3. Brainstorming
4. SWOT analysis

B. A checklist is built from past experience, so it can only prompt for risks someone has met before. A brand-new technology's risks won't be on it. (Pondering's limitation is different: one person's knowledge.)

Check yourselfIn the Delphi technique, what is the purpose of anonymity, and what ends the process?

Experts see each other's answers anonymously so that dominant voices can't take over: a senior or forceful expert's view carries no extra weight because nobody knows whose it is. Experts revise and the rounds repeat until they reach consensus.

Check yourselfA register entry reads "Loss of an experienced team member". Explain why it is inadequate and rewrite it in ACTION – CONSEQUENCE – IMPACT form.

It names an event but gives no consequence or impact, so it can't be scored or responded to sensibly. A rewrite: "Because only one developer knows the payment module, if that developer leaves (action/event), work on the module may stall while someone else learns it (consequence), resulting in a two-sprint delay to the release (impact)." Any rewrite works if it states what happens, what goes wrong as a result, and what that costs the project.

Check yourselfSelect all correct statements about identification techniques.

1. SWOT can identify positive risks.
2. In brainstorming the group evaluates each idea as soon as it is suggested.
3. Interviews are needed because the risk manager rarely knows enough alone.
4. Pondering is a typical first step.

A, C and D. B is wrong: in brainstorming everyone contributes first, and the group evaluates afterwards, so ideas aren't shot down before they are heard.

Step 3 · Analyse and Assess exam

Identification typically produces dozens of risks, and no project can act on all of them. Step 3 measures each one so the team can see which few deserve attention first. It has two halves: analysis estimates each risk's probability and impact, and assessment then prioritises the risks so that an effective strategy can be formulated.

The methods come in two types. Qualitative methods are subjective and based on experience (people's judgement, expressed as numbers or words). Quantitative methods are mathematical or statistical.

The qualitative approach in four steps exam

1. Estimate the probability P, usually by expert judgement, as a value from 0–100%.
2. Estimate the impact I on a 1–5 (or 1–10) scale, where 1 is none, 2 minimal, 3 moderate, 4 severe and 5 catastrophic. You can also express the impact in money or days.
3. Compute the risk exposure: RE = P × I.
4. Identify root causes. This pays off because fixing one shared cause controls several risks at once.

Worked example 1: impact in dollars (slides)

The slides score the three third-party-app risks from 4.6 with impact in dollars, so RE also comes out in dollars.

Worked example 2: score impact, ranking and the risk matrix (slides)

This time the impact is a score from 1 to 10, and the risks are ranked by RE, highest first.

The slide rounds risk 7's RE to 0.4; the exact value is 0.35. Either way it ranks last.

The course uses a 3 × 3 matrix. Read it by finding the column for the likelihood and the row for the impact:

                     LIKELIHOOD
IMPACT        Low        Medium     High
High          Medium     HIGH       HIGH
Medium        Low        Medium     HIGH
Low           Low        Low        Medium

The bands implied by the slides' placements are: likelihood ≤ 20% Low, 40–60% Medium, ≥ 80% High; impact ≤ 3 Low, 4–6 Medium, ≥ 7 High. The stepper places each risk of worked example 2, exactly as the slides do.

Justifying the scores (tutorial)

Probability and impact are judgements, so the same risk can validly get different scores on different projects. What makes a score acceptable is a project-specific reason that passes the "so what?" test: a reason a reader can check against the case. The tutorial shows this with the UI risk from 4.6.

Scores also differ with the PM's experience, the PM's or organisation's risk appetite (how much risk they are willing to live with), the information available, bias, and stakeholder expectations.

Quantitative methods (named only)

The slides name quantitative methods but say they are "beyond the scope of this subject". They model a risk with probability distributions; examples are decision tree analysis, simulation (for example Monte Carlo, which runs a model thousands of times with random inputs) and sensitivity analysis (seeing how much the result changes when one input changes). Just know the names and that they are mathematical rather than judgement-based.

Check yourselfRate each on the slides' matrix: (a) P 80%, I 6; (b) P 10%, I 9; (c) P 20%, I 3. Which comes first? (Guide self-test Q9)

• (a) is High (RE 0.8 × 6 = 4.8): high likelihood, medium impact.
• (b) is Medium (RE 0.1 × 9 = 0.9), because it has low likelihood but high impact.
• (c) is Low (RE 0.2 × 3 = 0.6).

Act on (a) first. Still prepare a contingency plan for (b), because its impact is severe. (These are risks 4, 3 and 6 of worked example 2.)

Check yourselfA risk has a 25% chance of occurring and would cost $8,000. Another has a 50% chance and would cost $3,000. Which has the higher risk exposure?

1. The first, RE $2,000
2. The second, RE $1,500
3. They are equal
4. The first, because its impact is larger

A. RE₁ = 0.25 × 8,000 = $2,000; RE₂ = 0.50 × 3,000 = $1,500. D reaches the right risk for the wrong reason: a bigger impact alone doesn't decide it, the product P × I does (compare worked example 1, where the less likely risk 2 loses to risk 3 despite equal impact).

Check yourselfSelect all correct statements about step 3.

1. Qualitative analysis is subjective and based on experience.
2. Monte Carlo simulation is a quantitative method this subject expects you to perform.
3. Identifying root causes helps because one fix can control several risks.
4. Two analysts may validly give the same risk different scores if each justifies them with project-specific reasons.

A, C and D. B is wrong: the slides name quantitative methods (decision trees, Monte Carlo simulation, sensitivity analysis) but call them beyond the scope of this subject.

Step 4 · Respond exam

Analysis has told you which risks matter; now you decide what to do about each. One rule first: you should not respond to every risk. That is neither feasible nor advisable, because every response pulls time, money and people away from the project itself. Respond to the risks that analysis ranked highest, and consciously accept the rest.

Four strategies for threats (slides) exam

1. Accept (or ignore). Do nothing about the risk itself. Accept it when the exposure is acceptable, when we hope the event won't happen, or when RE is less than the cost of avoiding, mitigating or transferring it.
2. Avoid. Prevent the event completely by making P = 0 or impact = 0, for example by changing the scope, the plan or the technology.
3. Mitigate. Reduce P or the impact. Mitigation leaves a residual risk: the same event with lower exposure, which must be analysed again.
4. Transfer. Shift the burden to another party, which comes at a cost. Insurance, outsourcing to experts and contract clauses all do this.

The four strategies on the third-party app example

A dummy implementation (also called a stub) is a stand-in piece of code that offers the same interface as the real component but does almost nothing, so the rest of the system can be built and tested before the real component arrives.

Four strategies for opportunities (slides)

Positive risks get a mirror-image set, because now you want the event to happen:

Check yourselfA team buys insurance against the cost of a data-centre fire. Which strategy is this?

1. Avoid
2. Mitigate
3. Transfer
4. Contingency

C. Insurance shifts the financial burden to another party (the insurer), at a cost: the premium. It neither stops the fire (avoid) nor makes it less likely or less damaging to the data centre (mitigate). D is not a strategy at all; contingency is a plan.

Check yourselfSelect all correct statements about responses.

1. Mitigation always removes the risk completely.
2. A backup and recovery plan is an example of mitigation.
3. Accepting a risk can be sensible when its RE is lower than the cost of any response.
4. A project should plan a response for every identified risk.

B and C. A is wrong: mitigation leaves a residual risk; only avoidance makes P or I zero. D is wrong: responding to every risk is neither feasible nor advisable, because responses pull resources away from the project.

Check yourselfFor the third-party app, classify each action: (i) use a standard interface plus a dummy implementation; (ii) build the function in-house; (iii) a contract making the vendor pay for late delivery; (iv) ask for delivery well before it is needed.

(i) Mitigate, lowering the impact (work continues if the app is late). (ii) Avoid (no dependency, so P = 0). (iii) Transfer (the vendor bears the cost). (iv) Mitigate, lowering the probability that lateness hurts.

The risk register exam

The decisions of step 4 are written down in a risk response plan, also called a Risk Register. It is the working document of risk management: the place anyone can look up what is being done about a risk and who is doing it.

Check yourselfName the five fields of the slides' risk register template, and say which field monitoring watches.

Risk ID (unique identifier), Trigger (the sign that the risk has occurred), Owner (who monitors it and responds), Response (the strategy) and Resources required. Monitoring watches the triggers (4.9), and each risk's owner does the watching.

Step 5 · Monitor and Control

A register written in week 1 and never opened again is useless: probabilities change, responses fail, new risks appear. Step 5 keeps the register alive. Monitoring means watching the triggers, and identifying, analysing and responding to new threats and opportunities as they appear. Risk monitoring is part of the project's overall monitoring and control, not a separate activity.

The tutorial adds a set of practices for doing this well:

• monitor continuously, not once;
• brainstorm regularly for new risks;
• have owners check that their responses work and keep the register current;
• hold audits on demand.

Check yourselfWhich monitoring tool is carried out by a team from outside the project?

1. Risk review
2. Risk status meeting
3. Risk audit
4. Daily Scrum

C. A risk audit is done by an external team, checking how complete the identification was and that procedures exist. Risk reviews are internal and periodic, and status meetings are the regular internal meetings with risk on the agenda.

Risk Exposure and Risk Reduction Leverage exam

RE tells you how big a risk is. It doesn't tell you whether a particular response is worth its price: a response that cuts a $4,000 exposure to zero but costs $8,000 is a bad deal. Boehm's risk reduction leverage answers that question. (RRL is an older exam topic, not in the 2026 slides, but it appears in the predecessor subject's past papers below.)

Where each measure is used

Past exam · 433-443 (1998) Q6Describe risk exposure and risk reduction leverage. Name the steps of the risk management process and where each measure is used. (Predecessor subject; model answer from the study guide.)

• RE = P(loss) × loss, which is the expected loss.
• RRL = (RE_before − RE_after) / cost of reduction. An RRL > 1 means the response is worth doing, and among several responses you prefer the one with the highest RRL.
• The steps are Plan, Identify, Analyse and assess, Respond, and Monitor and control. Boehm's version groups them into assessment (identification, analysis, prioritisation) and control (planning, resolution, monitoring).
• RE is computed in analysis, used for ranking in assessment (prioritisation), and tracked in monitoring. RRL is used in response planning to choose and justify responses.

Past exam · 433-443 (1999) Q9Give the equation for RE. Apart from ranking, how can RE be used? (Predecessor subject; model answer from the study guide.)

RE = P(UO) × L(UO). Apart from ranking, RE has several other uses:

• It lets you compute RRL, to test whether a response is cost-effective.
• It tells you to accept a risk when RE is less than the response cost.
• It sizes contingency reserves; for example, summing the REs gives a schedule buffer (as in the agile register, 4.11).
• It lets you track trends and residual risk over time.
• It lets you compare alternatives, such as build versus buy, by their total RE.
• It helps decide "how much is enough" testing or prototyping, as Boehm proposes.

Check yourselfA risk has RE $10,000. Response X costs $4,000 and reduces RE to $6,000. Response Y costs $2,000 and reduces RE to $7,000. Which should you choose?

1. X, because it removes more exposure
2. Y, because its RRL is higher
3. Neither; accept the risk
4. Both, because each has RRL > 1

B. RRL_X = (10,000 − 6,000) / 4,000 = 1.0, which is not above 1. RRL_Y = (10,000 − 7,000) / 2,000 = 1.5. Only Y exceeds 1 and it has the highest RRL. A falls for "biggest reduction" instead of "best reduction per dollar".

Risk Management in Agile exam

Scrum has no "risk phase" and no risk manager, which leads students to say Agile ignores risk. The opposite is true: Agile builds risk handling into its ordinary artefacts and events. (Part III explains Scrum itself; here we only need its parts: the Product Owner who orders the Product Backlog, the Developers who build, the Scrum Master who keeps the process working, and short fixed-length Sprints with planning, a Daily Scrum, a Review and a Retrospective.)

How it differs (slides). Agile risk management stresses continuous adaptation and collaboration. It is built into the framework rather than run as a separate phase, and responses are split into small, collaborative pieces. Three things make it work: transparency, so risks surface early; collaborative planning, because the whole team spots more risks; and customer involvement throughout. The Scrum Guide 2020 says Scrum's iterative approach aims "to optimize predictability and to control risk".

A lightweight agile register (tutorial)

The tutorial's agile register measures impact in days rather than on a 1–10 scale. That has a useful consequence: REs in days can be added up, and the total exposure can be used as a schedule buffer (spare time added to the plan to absorb risks that occur).

Check yourselfHow does Scrum manage risk without a separate risk phase? (Guide self-test Q11)

Scrum handles risk through its ordinary artefacts and events. Risks become backlog items, prioritised by the PO, who owns business risk, and spikes tackle areas of high uncertainty. Sprint Planning analyses the risks, and mitigation happens within the Sprint. The Scrum Master monitors daily at the Daily Scrum and removes impediments.

The Review exposes product risk and the Retrospective exposes process risk, while short Sprints cap the exposure. A lightweight risk register is also kept.

Check yourselfSelect all correct statements about risk in Scrum.

1. The Product Owner owns business risk.
2. Agile teams keep no risk documentation at all.
3. A spike is a time-boxed research item used to reduce uncertainty on high risks.
4. The Retrospective is where process risk is covered.

A, C and D. B is wrong: little is documented in Agile, but risk registers are.

Case Studies: Bank of America and Google Checkout

Two lecture case studies show that the dangerous risks are often not technical at all. In the first, a missing risk plan for stakeholders turned a pricing decision into a disaster. In the second, SWOT reveals the business risk that killed a technically sound product.

Bank of America's debit-card fee (stakeholder and business risk)

Check yourselfWhich step of the risk management process failed at Bank of America? (Guide self-test Q12)

Identification and planning failed. Without stakeholder consultation, BoA missed a high-P, high-I customer backlash, which brought mass account switching and the fee being withdrawn. The lesson is to research the consequences before going "full steam".

Google Checkout: SWOT for risk identification

Google Checkout offered one-click payment using card details stored in a Google account, with fraud protection. It launched in 2006, was merged into Google Wallet and was retired on 20 Nov 2013. The slides analyse it with SWOT:

Lesson: business risks, such as a dominant rival controlling the key marketplace, can kill a technically sound product. SWOT also shows which opportunities to exploit or enhance.

Check yourselfIn Google Checkout's SWOT, is "banks control the fees" a weakness or a threat? Is "banks or Microsoft may enter the market" a weakness or a threat?

The slides list "banks control the fees" as a weakness (a built-in disadvantage of Checkout's position) and "banks or Microsoft entering" as a threat (an external event that may or may not happen). The test: weaknesses describe how things are for us now; threats are uncertain external events, which is why they are risks.

Applying It to the Medic Case exam

The tutorials' running case is Medic: a virtual-reality simulator that lets trainee surgeons practise cochlear-implant and temporal-bone surgery, because quality cadavers for practice are scarce. The clients are surgeons at a hospital (RVEEH), and the hospital's IT team (RVEEH IT) will maintain the system after handover. Exam case-study questions look exactly like this section: write risk statements, score them, place them on a matrix and propose responses.

Why Medic is risky (tutorial)

The Medic risk register

P is scored from 0–100% and I from 1–10. Medic's own bands are: likelihood < 30% Low, 30–69% Medium, ≥ 70% High; impact 1–3 Low, 4–6 Medium, 7–10 High. (Note these differ slightly from the slides' bands in 4.7: a register sets its own scales, which is exactly what the RMP is for.) Each statement is abridged to action → consequence → impact, and the risks are listed in order of RE.

Responses, triggers and owners

Responses are given for the top five (R1–R5 by RE), plus R8 and one opportunity, each with its trigger and owner.

Velocity (R3's trigger) is the amount of work a team completes per Sprint (Part VI); falling below plan is an early sign the C++ learning curve is biting.

Monitoring, and one root cause

The register is reviewed, and RE recomputed, at weekly status meetings or Sprint Reviews. Notice that R1–R5 share one root cause: the team's inexperience. Fixing that one cause helps control all five, which is exactly why the qualitative method's fourth step says to look for root causes.

Check yourselfMedic: write one risk statement, justify P and I, and give a response with trigger and owner. (Guide self-test Q10)

• Statement: "Because the team is largely unfamiliar with C++, implementing the real-time simulator in C++ may cause low productivity and memory defects, resulting in schedule overrun and an unreliable system."
• P 70%, because the case says the team is unfamiliar with C++ and must also learn 3D and haptics.
• I 7, because defects in the real-time core cause system-wide rework.
• That gives RE = 0.7 × 7 = 4.9, which is High on the matrix.
• Response: avoid the risk by negotiating Java, since the case says C++ is negotiable; otherwise mitigate it with training, a mentor and code reviews.
• The trigger is velocity below plan, and the owner is the PM.

Check yourselfWhy is R3's first-choice response avoid rather than mitigate, and what does mitigation leave behind if avoidance is refused?

The case says the language choice is negotiable, so negotiating Java removes the cause entirely (P = 0) rather than just shrinking it. If the clients insist on C++, mitigation (training, a C++ mentor, reviews) lowers P or I but leaves a residual risk that must be re-analysed and kept on the register.

Pitfalls and Past-Exam Questions exam

This section collects the mistakes that cost marks and works through the remaining past-exam questions. The past questions come from 433-443, a predecessor subject of SWEN90016 (no SWEN90016 paper is publicly available); the model answers are the study guide's own, not official answers.

Strategies across the project stages

Past exam · 433-443 (2000) Q4a–c(a) What is risk exposure? (b) What are the key risk management strategies? (c) At which project stages should each be used? (Predecessor subject; model answer from the study guide.)

(a) RE = probability × loss, and it is used to prioritise risks.

(b) For threats the strategies are avoid, mitigate, transfer, accept; for opportunities they are exploit, enhance, share, accept. Both sets are backed up with contingency and fall-back plans.

(c) Each strategy belongs to particular stages, as the figure shows.

A calculation: is the speed-up worth paying for?

Past exam · 433-443 (2001) Q8 (predecessor subject; model answer from the study guide). A $1,000,000 contract is due in 12 months. If it is late by less than a month (that is, delivered in month 13), there is a −$200,000 penalty. After 13 months, there is no payment at all. P(on time) = 80%; if late, month 13 and later are equally likely. (a) Compute RE. (b) Is spending $50,000 up front worth it, if it gives a 75% chance of month-13 delivery when late?

Assumptions (state them in the exam): the loss is the lost revenue, because the costs are incurred anyway; the spend leaves the 80% on-time chance unchanged; and the decision is made on expected value.

Scenario questions: name the risks

Past exam · 433-443 (1999) Q8Technocrat (a GIS company) must integrate a real-time fire alarm and control system within 12 months on the supplier's newly released real-time OS. Give two risks and mitigations. (Predecessor subject; model answer from the study guide.)

(GIS means geographic information system: mapping software, a very different field from real-time safety systems.)

1. The new OS is immature, so it may be buggy or miss response times. Mitigate by benchmarking and prototyping the real-time paths early, getting a supplier support agreement, and putting an abstraction layer over OS calls. Transfer the risk through supplier warranties.
2. The team has no real-time or safety-critical experience (its background is GIS), and a failed alarm is catastrophic. Mitigate by contracting specialists, training staff, running independent safety reviews and testing with hardware simulators.

Poorly specified alarm interfaces are also a valid answer, mitigated with an early interface agreement. Note how both main answers are product-specific: they come from the new OS and the team's GIS background, not from a generic list.

Past exam · 433-443 (1999) Q19.3 (predecessor subject) describes three builds. Build A is 4 phases of 1 month, delivered at T0+4. Build B is 4 phases of 2 months, delivered at T0+10. Build C is 4 phases of 2 months, delivered at T0+16. C depends on B passing test, and there is a full requirements review at T0+4. To meet those dates, B must start at T0+2 (overlapping A) and C at T0+8 (during B's test):

Past exam · 433-443 (1999) Q19.3Name two schedule risks in this plan. (Predecessor subject; model answer from the study guide.)

Both risks come from the overlap.

1. C starts before B is proven. If B fails test, C's early work is wasted and staff are pulled back to B, so C slips. Response: a go/no-go gate, and keeping the early C work light.
2. The requirements review (T0+4) follows the start of B's analysis, so B's analysis starts while customer needs are uncertain, and changes then cause rework. Because there is zero slack (no spare time between dependent tasks) and staff are shared across overlapping builds, any slip ripples forward. Response: a buffer, an earlier review, and resource levelling (smoothing the plan so nobody is double-booked).

Past exam · 433-443 (2001) Q13 (predecessor subject): Jeopardy's new system arrives in 9 months. Meanwhile, staff will learn a vendor's 4GL (fourth-generation language: a high-level, often database-oriented programming language) on the old system and re-engineer the critical application there first, then move it across.

Past exam · 433-443 (2001) Q13(i) What are the risks? (ii) What affects likelihood and loss? (iii) What should management do? (Predecessor subject; model answer from the study guide.)

(i) Risks. The new hardware is late. The old-system 4GL is late, buggy or behaves differently, so the code won't port. The 4GL learning curve is slow. Performance on the old hardware is poor. Re-engineering introduces errors into the critical application. Data conversion causes problems. The project depends on the vendor.

(ii) Factors.

• The likelihood depends on the vendor's track record and contract, the maturity of the port, the staff's experience and training, the application's complexity and documentation, and the slack available.
• The loss depends on how critical the application is, whether the old system can keep running, the size of the rework, and penalties and lost business.

(iii) Run the process with a register.

• Identify the risks with checklists and by brainstorming with the vendor.
• Analyse them by estimating P, L and RE, and place them on the matrix.
• Respond by transferring the risk of late delivery through contract penalties, by mitigating with an early pilot port of one module, training and vendor consultants, and with a contingency plan to run the old application in parallel and migrate incrementally.
• Monitor triggers such as the vendor's milestones, and check them weekly.