How do you identify and manage project risks (RAID)?

Question

Accepted Answer

A **risk** is something that *might* happen and would hurt the project if it did. **Risk management** is identifying those threats early and deciding what to do about them *before* they bite. The cheap insight: problems are far easier to handle when you've thought about them in advance.

## The RAID log

A simple, widely-used tool to track project threats and items:

```text
R — RISKS        → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS  → things we're taking as true (validate them)
I — ISSUES       → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
```

## Assess each risk

```text
For each risk, score:
  LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
```

## Choose a response

```text
AVOID    → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT   → live with it, but have a fallback ready
```

## A concrete example

A project depends on a third-party API that's new and unproven. Risk: it may not perform. Likelihood medium, impact high. Mitigation: spike it early, build an abstraction so you can swap providers, and have a fallback. Now an unknown is a managed risk with a plan.

## A common pitfall

Treating risk management as a one-time kickoff checklist. Risks evolve — review the RAID log regularly and add new ones as they emerge.

## Why it matters

Unmanaged risks become crises, usually at the worst possible moment near a deadline.

The cost of handling a risk early is tiny compared to firefighting it after it hits.

Naming risks out loud also builds trust — stakeholders prefer "here's what could go wrong and our plan" over confident silence followed by a nasty surprise.