Risk·Field Guide
DARK
SE423 · Software Project Management · Chapter 07

Every project has
monsters under the bed.
This is how you find them first.

Risk management isn't pessimism — it's the discipline of admitting, on paper, everything that could still go wrong, then deciding in advance what you'll do about it. A good PM doesn't avoid the storm; they buy the umbrella in January. This chapter walks the full loop: identify → analyze → plan → monitor, threats and opportunities alike.

RE = P × I
Known → Unknowable spectrum
AMTA vs. EESA strategies
PMBOK 7th Ed.
PROBABILITY × IMPACT P I higher P × I = higher priority
§ 01 — DEFINING THE TERM

What is a "risk," precisely?

Everyone thinks they know what a risk is. The exam wants PMBOK's exact wording.

PMBOK Guide (7th ed.)

official definition

"Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Negative risks are called threats and positive risks are called opportunities." "A risk may have one or more causes, and, if it occurs, one or more impacts."

Four questions every risk answers
What can happen? What is the likelihood? What will the damage/benefit be? What can we do about it?
Watch out: engineers usually only analyze worst-case scenarios — that's half the job. A complete risk answers all four questions, including the upside (opportunities), not just the downside.
Three defining characteristics
  • Uncertainty: 0 < probability < 1 — a certainty (p=1) or impossibility (p=0) isn't a risk.
  • An associated loss or gain: financial, human safety, reputation, etc.
  • Manageable: it can be controlled or used in different ways — otherwise it's just fate.
🙈
Memory hook
"Ignoring a risk doesn't make you brave — it makes you unmanaged."
Some PMs avoid naming negative risks out loud, fearing they'll look negative. The slides call this out directly: active risk management — surfacing threats AND opportunities — is a sign of a well-run project and a mature organization. Being proactive reduces problem impact; being reactive just absorbs it.
Negative risk (threat) classification, at a glance
CategoryWhat it looks like
Requirements riskIncorrect (doesn't reflect real needs), incomplete (missing edge cases), unclear/inconsistent (stakeholder contradictions), or volatile (constant churn)
Cost riskUnreasonable budgets — underestimating true delivery cost in time, talent, or tools
Schedule riskSchedule compression from customer pressure, marketing launch dates, etc.
Quality riskThe product ships but doesn't meet the bar
Life cycle / operational riskPoor handoffs (team-to-team, phase-to-phase, internal-to-external, turnover-induced), missing documentation, ignored maintenance
§ 02 — THE HIERARCHY

Risk Management, decomposed

Risk management is a systematic approach to reducing harm from threats and maximizing benefit from opportunities — making the project less vulnerable and its outcome more robust. This chapter focuses specifically on threats management.

Risk Assessment

Figure out what you're facing

Risk Identification → Risk Analysis → Risk Prioritization. The "looking" half of the job.

Risk Control

Decide what to do, then watch it

Risk Management Planning → Risk Resolution → Risk Monitoring. The "acting" half of the job.

🔁
The four-step loop this whole chapter follows
Identification → Analysis → Planning → Monitoring → (loops back to Analysis)
Identification outputs a list of potential risks. Analysis outputs a prioritized risk list. Planning outputs avoidance & contingency plans. Monitoring outputs a fresh risk assessment — which feeds back into Analysis. It never truly ends until the project does.
Reality-check your plan before you start: test the plan, assess it with risk management (so it's resilient, not just optimistic), involve the team (plans made in isolation miss operational realities), build confidence in it, and sell it to stakeholders — not just for approval, but for genuine advocacy (مناصرة).
§ 03 — RISK (THREAT) IDENTIFICATION

What can possibly go wrong?

Risk identification determines what might impact the project, and profiles it so mitigation is possible. It's iterative and incremental — new risks get added, non-risks get deleted, and profiles get refined as the project moves forward.

The "average" project's greatest hits: testing runs long and bugs won't resolve; a vendor misses schedule; the critical engineer has an accident, becomes a parent, or has surgery; the critical engineer leaves; ownership changes and the project goes on hold; major downsizing; dysfunctional staff; natural disasters, internet and power failures.
By predictability — four buckets
🎲
Memory hook
"Known → Predictable → Unpredictable Joker → Unknowable disaster"
Each bucket is a step further from your control. Know which one a risk falls into and you instantly know how (or whether) it can be managed.
BucketDefinitionExampleCan it be managed?
KnownUncovered by careful evaluation of the plan, business/technical environment, or reliable sourcesThird-party vendor delay; key personnel joining/leaving; dev systems downYes — mitigated via management techniques and response plans
Predictable (unknown risk)Extrapolated from past projects; we know a probability exists but not the precise impactLoss of key personnel due to turnover Cannot be managed directly, but mitigated via contingency
Unpredictable"Joker" risks that are simply hard to predict —Largely no
UnknowableOutside the scope of historical or probabilistic models entirelyCorporate failures, natural disasters, terrorism/war, major snowstorm, power lossNo — beyond risk management; handled by crisis/disaster management
Other ways to categorize risk
  • By type: Project, Technical, Business
  • By category: strategic, financial, legal/compliance, quality, schedule, customer/stakeholder
  • By source: internal, external, technical, project environment
Get the team involved

Don't identify risks alone. Use a checklist or similar source to brainstorm, and run a SWOT analysis: Strengths & Weaknesses (what we've got) crossed with Opportunities & Threats (what's out there). The output is a list of risks with potential to disrupt cost or schedule.

Three types of risk (threats)
📋

Project threats

Threaten the project plan — schedule slips, costs increase. Budgetary/funding, schedule, personnel, resources, project plan, PM processes, customers, requirements problems (scope/requirements changes), project complexity & size, hardware, environmental risk.

⚙️

Technical risks

Threaten the quality and timeliness of the software itself. Design, implementation, interfacing, verification, cutover, maintenance, security.

💼

Business risks

Threaten the viability of the product: building something great nobody wants anymore (market risk), something that no longer fits company strategy (strategic risk), something sales can't sell, losing senior-management support (management risk), losing budget/personnel commitment (budget risk), plus contracts, political concerns, legal risk.

Risk Breakdown Structure (RBS)

Risk categories represented hierarchically — analogous to a WBS, but decomposing risk sources instead of work.

🌳
Memory hook
"Techies External Organize Projects" — T · E · O · PM
The four top-level RBS branches: Technical, External, Organizational, Project Management.
Technical
  • Requirements
  • Technology
  • Complexity & references
  • Process
  • Analytical
External
  • Regulators
  • Market
  • Subcontractors & suppliers
  • Customer
  • Weather
Organizational
  • Project dependencies
  • Staffing quality
  • Staffing sufficiency
  • Decision making
  • Prioritization
  • Funding
Project Management
  • Culture
  • Estimating
  • Planning
  • Controlling
  • Communication
§ 04 — TOOLS & TECHNIQUES

How you actually go find the risks

Documentation reviews

Start by reviewing every input: project charters, contracts, plans, lessons learned, technical documentation.

Information-gathering techniques
Brainstorming: diverse participants, self-regenerating — one idea sparks another, cascading into more insights.
Delphi technique: a facilitator distributes a questionnaire and synthesizes results. Experts respond independently (no direct interaction, unlike brainstorming) — reduces groupthink or dominant voices. Best for complex or politically sensitive projects where open discussion could bias input.
Interviews: one-on-one or small-group, structured or semi-structured questions, with any stakeholder holding project-relevant knowledge.
Root Cause Analysis (RCA) — the Five Whys

The visible source of a risk is often just the surface. Hall's method: ask "Why?" five times (more or less); each answer moves closer to the true root cause. Not rigorous, but simple and effective.

Worked example — Problem: the team keeps missing sprint deadlines.
Why 1: Devs discover unexpected technical issues late in the sprint.
Why 2: Requirements aren't fully understood before dev begins.
Why 3: The product owner gives only high-level descriptions, no acceptance criteria.
Why 4: Stakeholders assume the team will "figure out the details."
Why 5: There's no formal requirements validation step before sprint start.
→ Root cause found: missing requirements-validation gate, not "the developers are slow."
Checklist analysis

Based on historical information and prior team experience — requires one or more similar past projects. The lowest level of the RBS makes a natural starting point. Checklists can never be exhaustive: projects are unique.

Assumptions analysis

Validates assumptions documented during planning against two factors: strength/validity of the assumption, and consequences to the project if it turns out false. False assumptions get reclassified as risks.

Diagramming techniques
Cause-and-effect (fishbone/Ishikawa) System/process flowcharts Influence diagrams

Fishbone: shows every potential cause/sub-cause feeding into one effect — e.g. Process, Staff, Environment, and Testing causes all converging on "Module Defects."

Flowcharts: familiar to most stakeholders; show logical steps and cause/response relationships.

Influence diagrams: show causal influence among project variables and how risks or decisions ripple — e.g. Scope and Cost/Time both influencing Quality.

A few more identification angles
Past experienceLeverage the team's or organization's prior project experience to anticipate risks.
Historical dataUse documented evidence from past projects, e.g. a project database.
Decision Driver AnalysisExamine key decisions (technology choices, vendor selection, staffing plans) and the risks each one introduces.
Security threat IDFocus specifically on cybersecurity, data protection, and system vulnerabilities.
Output: the Risk Register

All information gathered during identification is documented in the risk register: list of identified risks, list of potential responses, root causes, and risk categories. (Fields like likelihood/impact/risk level are filled in during the Analysis stage that follows.)

§ 05 — RISK ITEM CHECKLIST

Seven subcategories, one question pattern

A checklist supports identification of known/predictable risks across seven subcategories. Each one comes with its own diagnostic questions.

🧩
Chunking mnemonic
"Pizza Boxes Contain Pretty Damn Tasty Slices"
Product size · Business impact · Customer characteristics · Process definition · Development environment · Technology to be built · Staff size & experience

Product Size

risk ∝ size

Project risk is directly proportional to product size. Measure size against previous projects — if past projects were similar and successful, risk is low; a large negative deviation signals HIGH risk. Estimated size (LOC/function points), confidence in that estimate, number of programs/files/transactions, % deviation from average, number of users (and loading impact), anticipated requirements volatility, amount of reused software.

Business Impact

answer NO → investigate

Effect on company revenue, visibility to senior management, reasonableness of delivery deadline, number of customers & consistency of their needs, number of other products it interacts with, sophistication of end users, governmental constraints, cost of late/defective delivery.

Customer

answer NO → investigate

Worked with this customer before? Do they have a solid idea of requirements? Will they commit time to requirements gathering? Establish rapid communication links? Participate in reviews? Are they technically sophisticated? Do they understand the software process?

Process

answer NO → investigate

Consistent repeatable process, actually used? All developers trained in it? Formal technical reviews part of it? A mechanism for managing change (formal RFC + config. mgmt.)? Specific methods per phase? Supported by tools? Managed via metrics?

Technology

answer YES → investigate

New to your org? New algorithms required? Interfaces with new/unproven hardware or vendor products? Requires building components unlike anything built before? Demands new analysis/design/testing methods? Excessive performance constraints?

Development Environment

answer NO → investigate

PM tool available? Analysis/design tools available? Compilers & code generators suitable? Testing tools suitable? Tools integrated with each other? Team trained in the tools? Tool mentors available?

Staff Size & Experience

"people make the difference"

Best people available? Right combination of skills? Enough people? Staff committed for the product's duration? Anyone spread across multiple projects? Received necessary training?

§ 06 — RISK ANALYSIS

Turning a hunch into a number

Objectives: analyze risk cost-efficiently, determine its source, determine its exposure, determine the time frame for action, and determine the highest-severity risks.

🎯
The one formula this whole section hangs on
RE = P × I
Risk Exposure = Probability (0 to 1) × Impact (e.g. weeks lost, cost units). Sum all RE's across the register to get an expected overrun — a quantitative forecast of how much delay/cost the project might face.
Worked examples
"Facilities not ready on time" — probability 25%, size 4 weeks → RE = 0.25 × 4 = 1 week of expected delay.
"Inadequate design — redesign required" — probability 15%, size 10 weeks → RE = 0.15 × 10 = 1.5 weeks.
How to estimate each half
Impact: the size of the loss — break it into chunks to estimate more accurately.
Probability: use team-member estimates with a risk-estimate review, Delphi/group-consensus techniques, a "gambling analogy" ("how much would you bet?"), or "adjective calibration" (highly likely, probably, improbable, unlikely, highly unlikely).
Quantifying probability — Likert scales

For most situations, a five-point Likert scale is appropriate:

  • Highly unlikely (p < 20%)
  • Unlikely (20% < p < 40%)
  • About even (40% < p < 60%)
  • Likely (60% < p < 80%)
  • Highly likely (p > 80%)

For less well-defined situations, use a three-point scale:

  • High (p > 75%)
  • Moderate (35% < p < 75%)
  • Low (p < 35%)
Likert scale: a psychometric scale commonly used in surveys to measure attitudes, opinions, or perceptions.
Impact

Impact is the amount of pain or gain a risk poses to cost, time, scope, and quality. Like probability, it can be subjective (low/medium/high) but the probability-and-impact matrix needs a cardinal (numeric) scale. Employ consistent decision criteria so a borderline impact doesn't drift between categories arbitrarily.

Probability & Impact Matrix

Combines P and I into one ordinal risk rating (Minimum → Low → Moderate → High → Extreme). A high-probability, high-impact risk warrants a formal response plan.

Probability ↓ / Impact →NegligibleMarginalModerateCriticalCatastrophic
Almost CertainLowModerateHighExtremeExtreme
LikelyMinimumLowModerateHighExtreme
PossibleMinimumLowModerateHighHigh
UnlikelyMinimumLowLowModerateHigh
RareMinimumMinimumLowModerateHigh
Risk prioritization

Remember the 80-20 rule: 80% of outcomes come from 20% of causes — focus on high-impact risks. Possibly group related risks; this helps identify which risks to ignore (those at the bottom). Use the risk register to track it all.

Risk data quality assessment

Low-quality data renders qualitative analysis almost useless. Examine: quality of data used, availability of data, how well the risk is understood, reliability/integrity of data, accuracy of data.

How risk-averse is the PM? (it matters)

The quality of the analysis depends on the personality of the analyst:

Risk averse: values dependability & punctuality, unlikely to take risks, prefers efficient/responsible work, service- over self-oriented, values institutions/traditions.
Risk seeking: likes action, acts impulsively, seeks the thrill, resourceful but avoids planning/preparing, self- over service-oriented.
Risk neutral: trusts intuition, comfortable with unknowns, thinks long-range, naturally curious ("Why?"), generates new ideas, works best inspired.
Output — updates to the risk register: risk ranking (ordered by exposure), risks grouped by category, a list of risks needing near-term responses, a list needing additional analysis, a watch list of low-priority risks (still worth monitoring), and qualitative-analysis trends to inform response planning.
§ 07 — RISK MANAGEMENT PLANNING

How you'll approach, plan, and execute all of it

A well-defined, comprehensive risk management plan enhances the chances the whole risk process succeeds. Risk analysis and planning continue throughout the project.

Risk urgency assessment: don't try to deal with every risk at once — analogous to rolling wave planning, determine how soon each risk might occur and plan for those first. For efficiency, only the top ten risks should be actively managed; keep a watch list of the rest to promote onto the top 10 as items get resolved, mitigated, eliminated, or simply don't materialize.
Inputs to the plan
InputWhat it contributes
Enterprise environmental factorsRisk tolerance levels of the org & stakeholders (a trade-off between benefit and cost); consulting-firm reports; forums like comp.risks for industry/academic research.
Organizational process assetsExisting policies/guidelines defining risk tolerance.
Project scope statementDeliverables, constraints, assumptions, initial project organization, initial defined risks, schedule milestones.
Risk management plan (existing)Risk categories (e.g. from the RBS) as a primary input; budget & schedule for risk-management activities.
Project management planThe risk plan becomes an integral part of it — every other process/guideline should be considered in light of potential risks.
Tools & output

Planning meetings are the main tool — attended by the PM, project management team, and any stakeholder who can contribute risk-related information; they cover analysis of project risk, org risk tolerance, and calibration. The risk management plan is the only output of this process.

What the risk management plan contains
  • Methodology: how risk mgmt will be performed — methods, tools, data sources
  • Roles & responsibilities: who manages which risks and responses — the risk "owners"
  • Budgeting: resources and cost estimates for risk activities
  • Timing: frequency of risk processes
  • Risk categories: may need refining
  • Revised stakeholder tolerances
  • Reporting formats: content/format of the risk register
  • Tracking: how risk activity history is documented and audited
§ 08 — RISK RESPONSE PLANNING

Threats get AMTA. Opportunities get EESA.

Risk response planning develops options and reactions to mitigate threats and exploit opportunities uncovered during analysis. The severity of the risk dictates how much response planning is worth doing — a low-severity risk isn't worth a detailed plan, and every response should be more cost-effective than the risk it addresses.

⚖️
Memory hook — the mirror-image strategy table
Threats: Avoid · Mitigate · Transfer · Accept (AMTA)
Opportunities: Exploit · Enhance · Share · Accept (EESA)
Every threat strategy has a positive mirror: avoiding a threat ↔ exploiting an opportunity; mitigating (reducing probability/impact) ↔ enhancing (increasing it); transferring risk to a third party ↔ sharing an opportunity with one. Accept is the one strategy shared by both.
1234
ThreatAvoidMitigateTransferAccept
OpportunityExploitEnhanceShareAccept
Strategies for threats
Avoidance: evade the risk, eliminate its cause, or change the plan to protect objectives from it. Removes the risk (or its cause) entirely. Most suitable early in a project, via better communication, added resources, or clearer scope.
Example: avoid the risk of interfacing the Membership Management System (MMS) to external art-museum systems by simply eliminating that requirement.
Transfer: move the risk (and its consequences) to a third party — responsibility now rests with them. Most effective for financial risks. Example: transfer KYC legal-requirement risk to an external KYC services provider.
Contracting (a form of transfer): the contractor accepts certain risk/cost-of-failure. Fixed-price: contractor absorbs overruns and prices in the risk up front. Cost-reimbursable: contractor bills actual costs plus a fee; most of the risk stays with the buyer.
Mitigation: reduce probability and/or impact to an acceptable level. Rests on the idea that fixing a problem earlier is cheaper than fixing it later. Examples: more testing, simpler processes, simulations, choosing vendors for reliability over cost.
Acceptance: acknowledge the risk, take no action unless it occurs — appropriate when no other response is possible or cost-effective. Passive acceptance: just documents the decision, leaves the team to deal with it if it happens. Active acceptance: sets aside risk reserves (a pool of funds, time, or resources) in advance.
Mitigation vs. Monitoring vs. Management (the three questions): Mitigation asks "how can we avoid the risk?" Monitoring asks "what can we track to see if it's getting more/less likely?" Management asks "what contingency plans exist if it becomes real?"
Strategies for opportunities
Exploitation: actively look for positive impact. Example: reduce project duration by putting more experienced resources on critical tasks.
Sharing: assign the opportunity to a third-party owner better able to exploit it. Example: form a joint venture between a technical software company and a marketing/sales firm.
Choosing a strategy — decision guide
IF THREAT…
…can be entirely designed out of scope early → Avoid it.
IF THREAT…
…can't be removed, but its odds or damage can be shrunk → Mitigate it.
IF THREAT…
…is handled better by someone else (a vendor, insurer, contractor) → Transfer it.
IF THREAT…
…costs more to respond to than to simply absorb → Accept it (passively or with reserves).
§ 09 — CONTINGENCY, RESIDUAL & SECONDARY RISK

The plan for when the plan isn't enough

Contingency Plans

"Plan B," pre-built

Contingency planning plans alternatives for when risks occur — it doesn't reduce probability or impact, it accepts the risk may happen and plans the response. A contingency plan is executed when the risk event actually occurs, so it must be in place well before that time. Built for risks with very high impact, or for risks whose response strategies are themselves risky. Usually involves a significant alternative path through part of the project. Example: a disaster recovery plan.

Contingency planning tools
Contingency allowances (reserves): a pool of funds, time, or resources held for use in response to an unavoidable risk event. Example: contingency time budgeted for the loss of key personnel.
Fallback plans: developed for high-impact risks or risky response strategies. May address secondary risks. Example: use a relational database plus an ORM interface in place of a pure object-oriented database.
Residual vs. Secondary risk
Secondary risks arise from implementing a risk response — they're the risk inherent in the fix itself. Plan for them with tools like fallback plans. Example: the O-O/RDB expert consultant you hired to mitigate the original risk becomes ill.
Residual risks are those that can't be fully dealt with by the rest of the risk plan — some risk simply remains. Usually addressed through contingency reserves. Example: developer-skills (resource-planning) risk tied to an alternate database solution.
Risk response planning outputs: risk register updates (descriptions, WBS element/area impacted, root causes, objectives impacted, risk owners & responsibilities, risk triggers — the precursor symptoms/warning signs of an occurrence), response plans & strategies (specific actions + fallback plans), cost/schedule activities to implement responses, contingency plans + reserves, the list of residual & secondary risks, and probabilistic analysis (e.g. Monte Carlo simulations, decision-tree analysis) yielding a range of possible completion dates/costs and confidence levels (e.g. "80% chance we finish within 12 months").
§ 10 — RISK MONITORING

The loop never really closes

Monitoring feeds straight back into Analysis — it's how the four-step loop stays alive for the life of the project.

The Top 10 Risk List

Tracks: rank, previous rank (history), weeks on list, risk name, and resolution status (active, mitigated, resolved…). A low-overhead best practice — easy to maintain, easy to communicate, and scalable. Re-assess it at interim project post-mortems (after major milestones), evaluating how effective the responses have actually been. Communicating it to stakeholders keeps them informed of evolving risk and builds trust.

Key concepts in Monitor & Control
  • Workarounds: unplanned corrective action for unanticipated problems
  • Risk reassessments: periodic review and adjustment
  • Risk audits: prove preparedness, produce lessons learned
  • Reserve analysis: accounting for financial & schedule reserves — for risk only
  • Status meetings: should primarily focus on risk
  • Closing risks: once conditions surrounding a risk are in the past, close it out

Outputs: risk register updates, change requests, PM plan updates, project document updates, lessons learned.

Miniature Milestones — reduces risk by shrinking the unknown

Break the schedule into small (1–2 day) goals so delays are spotted before they compound. Requires a detailed schedule with early milestones; use binary status (done / not done).

Pros: enhances status visibility, good for project recovery, can improve motivation through frequent achievements, encourages iterative development.
Con: increases project-tracking effort.
📣
Closing principles worth memorizing verbatim
"Risks must be managed. Risks must be reported."
Risk stays one of the PM team's principal concerns for the whole project. Every weekly team meeting should briefly review all outstanding risks — even eliminated ones, to catch reappearances — estimate whether each risk's probability increased, decreased, or stayed the same, and have risk owners report on their assigned risks. The project status report should list every risk whose degree of risk has changed, preparing management for when risks actually happen.
§ 11 — CHEAT SHEET

The whole chapter, one table

StageQuestion it answersKey tool(s)Output
IdentificationWhat could happen?Brainstorming, Delphi, interviews, RCA/5-Whys, checklists, SWOT, RBS, fishbone/flowchart/influence diagramsList of potential risks (risk register)
AnalysisHow bad, how likely?RE = P × I, Likert probability scales, probability & impact matrixPrioritized risk list
PlanningWhat will we do about it?Planning meetings; AMTA/EESA strategies; contingency plans & reservesRisk avoidance & contingency plans
MonitoringIs it changing?Top 10 list, workarounds, reassessments, audits, miniature milestonesFresh risk assessment (loops back)
Threat strategies—Avoid · Mitigate · Transfer · Accept (AMTA)
Opportunity strategies—Exploit · Enhance · Share · Accept (EESA)
Predictability spectrum—Known → Predictable (unknown) → Unpredictable → Unknowable
RBS branches—Technical · External · Organizational · Project Management
§ 12 — COMMON MISTAKES

Where students actually lose points

These are the specific mix-ups this material invites — drill these until the right answer is automatic.

1. Confusing "Predictable" with "Known" risk
✗ WRONG"Staff turnover is a known risk because we know it happens."
✓ RIGHTStaff turnover is predictable — we know a probability of it occurring exists (extrapolated from past projects), but not the precise impact. "Known" risks are uncovered by careful evaluation of this specific project's plan/environment (e.g. "this named vendor is often late").
2. Mixing up Mitigation and Contingency
✗ WRONG"A contingency plan reduces the probability of the risk happening."
✓ RIGHTMitigation reduces probability and/or impact before the risk occurs. Contingency planning does the opposite — it accepts the risk may occur and pre-builds the response to execute if/when it does. They are sequential, not interchangeable.
3. Treating "Transfer" as making the risk disappear
✗ WRONG"We transferred the risk to the vendor, so it's no longer a project risk at all."
✓ RIGHTTransfer moves who is responsible for managing the risk and its consequences — it doesn't eliminate the risk itself. A fixed-price contract still leaves the buyer exposed if the contractor fails outright; that's a secondary/residual risk.
4. Reading the Technology Risks checklist backwards
✗ WRONG"Investigate technology risk if the answer is NO — same rule as every other checklist."
✓ RIGHTEvery other checklist (business impact, customer, process, development environment) flags risk on a NO answer ("no, we don't have a repeatable process"). Technology risk flips this — it flags risk on a YES ("yes, this requires new algorithms / unproven hardware").
5. Confusing Secondary risk with Residual risk
✗ WRONG"Residual and secondary risk are the same thing — leftover risk after a response."
✓ RIGHTSecondary risk is caused by the response itself (the consultant hired to fix Problem A gets sick). Residual risk is what's simply left over that no part of the plan fully addresses. Secondary risk is new; residual risk is unresolved.
6. Forgetting opportunities exist at all
✗ WRONG"Risk management" = only listing bad things that could happen.
✓ RIGHTPMBOK explicitly defines risk as having positive or negative effects — positive risks are opportunities, with their own strategies (Exploit, Enhance, Share, Accept). This chapter narrows focus to threats, but the exam can still test whether you know EESA exists as AMTA's mirror.
7. Miscalculating Risk Exposure
✗ WRONG"Probability 25%, impact 4 weeks → RE = 25 + 4 = 29."
✓ RIGHTRE = P × I, always multiplied, not added: 0.25 × 4 weeks = 1 week of expected exposure. Probability must be expressed as a fraction (0 to 1), not a raw percentage number.
8. Assuming Delphi and Brainstorming are interchangeable
✗ WRONG"Delphi is just brainstorming with extra paperwork."
✓ RIGHTBrainstorming is a group, self-regenerating conversation — participants build on each other's ideas out loud. Delphi deliberately keeps participants from interacting; a facilitator collects independent responses to reduce groupthink — better for politically sensitive topics where open discussion would bias the input.
§ 13 — POP QUIZ

Quick self-check

Click any question to reveal the answer.

1. A risk has probability 40% and impact of 8 weeks. What's its Risk Exposure? Reveal
3.2 weeks. RE = P × I = 0.40 × 8 = 3.2. Multiply, don't add — and keep probability as a decimal fraction.
2. Which technique deliberately prevents participants from talking to each other? Reveal
The Delphi technique. A facilitator distributes a questionnaire and compiles the independent responses, reducing groupthink and dominant voices — useful for complex or politically sensitive projects.
3. True or False: Contingency plans reduce the probability of a risk occurring. Reveal
False. Contingency plans do not seek to reduce probability or impact — they accept the risk may occur and plan the response to execute when it does. That's Mitigation's job, not Contingency's.
4. Name the four top-level branches of a Risk Breakdown Structure (RBS). Reveal
Technical, External, Organizational, Project Management. Each branches further — e.g. Technical → requirements, technology, complexity/references, process, analytical.
5. A vendor risk is transferred via a fixed-price contract. Who absorbs cost overruns? Reveal
The contractor. In a fixed-price contract, if costs exceed expectations the contractor absorbs the loss — which is why they price in extra cost up front to compensate for the risk they're accepting. (In a cost-reimbursable contract, it's the reverse — most risk stays with the buyer.)
6. What's the opportunity-side mirror of "Mitigate"? Reveal
Enhance. Mitigate reduces a threat's probability/impact; Enhance increases an opportunity's probability/impact. (Avoid↔Exploit, Transfer↔Share, and Accept is shared by both.)
7. Short answer: why does the Technology Risks checklist flag risk on "YES" instead of "NO"? Reveal
Because its questions ask whether something new/unproven/unbuilt-before is required (new algorithms, unproven hardware, novel components). A "yes" to any of those means you're pushing into unfamiliar territory — the opposite framing from checklists like Process or Customer, which ask whether good practices are already in place (so a "no" is the red flag there).
8. What's the difference between "Passive" and "Active" risk acceptance? Reveal
Passive acceptance just documents that the strategy was adopted and leaves the team to deal with the risk if it happens. Active acceptance sets aside risk reserves — a pool of funds, time, or resources — in advance, in case the risk occurs.
§ 14 — PRACTICE LAB

Applied scenarios, worked through

Same shape of question you'll see on an exam — reason through the category and strategy before checking the answer.

1. Your team notices the same critical developer has been the sole owner of the payment module for the past three releases, and no one else understands that code.
→ Predictable risk → Mitigate (cross-training) or build a Contingency reserve
Why: staff turnover/bus-factor is a classic predictable risk (extrapolated from past project patterns, probability known but not precise impact). The proactive move is mitigation — pair programming or documentation — reducing the probability of a costly handoff gap; a contingency reserve covers it if it happens anyway.
2. A project requires interfacing with a brand-new IoT sensor platform your company has never used, and requirements call for algorithms nobody on the team has written before.
→ Technical risk / Technology risk checklist — both questions answer "YES," so investigate immediately
Why: "new to your organization" and "requires new algorithms" are two of the exact diagnostic questions from the Technology Risks checklist — and unlike most checklists, a "YES" here is the red flag.
3. Legal counsel identifies that the app's data-retention policy may not meet new regional compliance requirements, but the org has no in-house legal-compliance expertise.
→ Business risk (legal risk) → Transfer, via contracting outside compliance expertise
Why: this threatens the viability of the product from a legal-risk angle (a Business risk subtype). Since the org lacks the expertise to mitigate it internally, transferring the risk — e.g. contracting a compliance consultant — moves both the work and the consequence to a party better equipped to handle it.
4. Estimate the Risk Exposure: probability of a scope-creep event is "Likely" (use midpoint of 60–80%), and if it happens it will cost roughly 6 weeks.
→ RE ≈ 0.70 × 6 = 4.2 weeks of expected delay
Why: "Likely" on the five-point Likert scale spans 60–80% probability; using the midpoint (70%) and multiplying by the impact size gives the expected exposure — exactly the RE = P × I calculation used for facilities/redesign examples in the slides.
5. After hiring an outside specialist to mitigate a database-migration risk, the specialist's visa renewal gets delayed and they may be unavailable for weeks.
→ Secondary risk, addressed via a Fallback plan
Why: this new risk exists because of the response you implemented (hiring the specialist) — the textbook definition of a secondary risk. A fallback ("Plan B") should already be queued, such as an internal team member or a second contracted expert.