Risk Management: Spotting Problems Before They Happen

Risk management is the discipline of identifying what could go wrong, assessing how likely and how painful each problem would be, and putting plans in place before the problems arrive. In field engineering, the cost of unseen risks is unplanned outages, broken trust, and missed deadlines.

Table of Contents

• Identifying Risks
• Assessing & Prioritizing Risks
• Responding to Risks
• Monitoring Risks

Identifying Risks

Risk identification is the act of listing everything that could threaten the project before it becomes a fire. Done early, it turns surprises into planned-for scenarios.

Why it is useful: You can't manage a risk you haven't named. Most project failures aren't caused by the risk that "couldn't happen" — they're caused by the risk nobody wrote down.

Where Risks Hide

Look in these places for the biggest haul:

Example: Brainstorming Risks from an Assumption

assumptions = [
    "Customer SSO will be available by week 2",
    "Export dataset stays under 500k rows",
    "The Ops contact can review the demo weekly",
]

for assumption in assumptions:
    print(f"Assumption: {assumption}")
    print(f"  Risk:     what if this is false? What do we do then?\n")

Simple explanation: Every assumption is a risk in disguise. Walking through each assumption and asking "what if it's false?" is the fastest way to produce a first risk list — no complex tooling needed.

Best Practices

• Brainstorm risks at kickoff and again after every milestone
• Use your assumptions list as a ready-made source of risks
• Dig into your past project postmortems — you repeat the risks you forget

Assessing & Prioritizing Risks

Assessment rates each risk by two questions: how likely is it, and how painful would it be? Combining them gives you a score you can use to decide where to spend attention.

Why it is useful: Not all risks are equal. Scoring separates the "could sink us" risks from the "barely worth a thought" ones, so you don't waste effort on the wrong list.

Probability × Impact Matrix

Rate likelihood and impact from 1 (low) to 5 (high); multiply for the score.

A score of 12+ usually means "act now." Below that, monitor.

Example: Risk Register with Scoring

risks = [
    {"id": "R1", "risk": "Customer IT contact leaves mid-project",
     "prob": 3, "impact": 4, "score": 12,
     "strategy": "Mitigate", "owner": "FDE"},
    {"id": "R2", "risk": "Export API rate limit blocks large pulls",
     "prob": 2, "impact": 3, "score": 6,
     "strategy": "Accept + monitor", "owner": "FDE"},
]

for r in sorted(risks, key=lambda x: -x["score"]):
    print(f"{r['id']} {r['risk']}: {r['score']} -> {r['strategy']}")

Simple explanation: The score (probability × impact) gives each risk a number so you can sort them. R1 scores 12 and gets an owner plus a mitigation; R2 scores 6 and is accepted with monitoring. The register records not just the risk but the decision.

Best Practices

• Score every risk; don't keep a list of unsorted worries
• Set a threshold ("anything above 12 needs a response") so decisions are consistent
• Give every significant risk an owner — nobody's risk is everybody's problem

Responding to Risks

Once a risk is scored, choose a response strategy. This is where you decide what you'll do about it, and what you'll do if it happens anyway.

Why it is useful: A plan made calmly in advance beats a decision made in panic during an outage.

The Five Strategies

Example: Mitigation + Contingency Plan

Risk R1: Customer IT contact leaves mid-project

Mitigation (reduce the chance we're harmed):
- Meet the backup IT contact in week 1
- Store all decisions in a shared doc, not private chats
- Record credentials/access in the vault with a second approver

Contingency (if the risk fires anyway):
- Pause decisions needing IT approval
- Escalate to the sponsor to name a new contact within 2 days

Simple explanation: Mitigation lowers the chance or damage before the risk fires; contingency is the plan you execute after it fires. Having both means the risk is handled whether or not it actually happens.

Best Practices

• Pair every significant risk with both a mitigation and a contingency
• One owner per risk response, with a named person, not a team
• Keep responses realistic — a plan nobody can execute is decoration

Monitoring Risks

Monitoring is the habit of reviewing the risk register regularly and acting when things change. Risks aren't static. They appear, fade, upgrade, and downgrade.

Why it is useful: A risk register written once and never touched is fiction. The whole point is that likelihood and impact move as the project evolves.

Example: Weekly Review Trigger

def weekly_review(risks, trigger_score=12):
    active = [r for r in risks if r["score"] >= trigger_score]
    print(f"{len(active)} risk(s) need attention this week")
    for r in active:
        print(" -", r["id"], r["risk"])
    print("Re-score each risk and check assumption changes.")

weekly_review(risks)

Simple explanation: A short weekly ritual — re-score the list, update assumption changes, check triggers — keeps the register alive. New information (a person quit, an API changed) should immediately bump the relevant risk's score. Two minutes on a calendar beats a two-hour firefight later.

Best Practices

• Put risk review on the calendar as a standing item, even for two minutes
• Update scores the moment reality changes, not just at review time
• Close risks that have passed and add new ones as they appear