Digital Product Engineering8.6 Risk Management
VOL. VIII · CH. 8.6 · PROJECT MANAGEMENT

Risk Management

Identifying what could go wrong while there's still time to do something about it.

DivisionProject Management
DifficultyIntermediate
Prerequisites8.1
Related8.7
1 min read · 307 words

8.6.1Definition

Risk management is the systematic process of identifying, assessing, and planning responses to events that could negatively affect a project — technical, resourcing, external dependency, or timeline risks — before they occur, rather than reacting to them only once they've materialized.

8.6.2Why It Exists

Every non-trivial project carries risks that are foreseeable in category even if not in exact timing or magnitude — a key dependency could fail, a team member could become unavailable, a technical assumption could prove wrong. Risk management exists to think through those foreseeable categories in advance, when a mitigation plan is cheap to create, rather than improvising a response mid-crisis when options are far more limited.

8.6.3Risk Assessment Approach

DimensionQuestion
LikelihoodHow probable is this risk actually occurring?
ImpactIf it occurs, how severely does it affect the project?
MitigationWhat can be done in advance to reduce likelihood or impact?
ContingencyWhat's the plan if the risk materializes despite mitigation?

8.6.4Common Mistakes

  • No risk register at all, discovering foreseeable problems only at the moment they occur, with no prepared response.
  • A risk register created once and never revisited, missing new risks that emerge as the project evolves.
  • Treating every risk as equally urgent, spreading mitigation effort thin instead of prioritizing by likelihood and impact.

8.6.5Best Practices

  • Maintain a living risk register, reviewed and updated at regular project checkpoints, not created once and forgotten.
  • Prioritize mitigation effort toward high-likelihood, high-impact risks first.
  • Prepare a concrete contingency plan for the highest-priority risks, not just an identification of the risk itself.
Real-World ExampleThe Supabase free-tier project cap encountered during the DK Car Modifications build is a documented example of an external platform constraint risk — one that, once identified, informs planning for future projects rather than being rediscovered as a surprise each time.