Ryzyko to coś, co może się zdarzyć i zraniłoby projekt, gdyby się zdarzyło. Zarządzanie ryzykiem to wczesne zidentyfikowanie tych zagrożeń i zanim się objawiają, zdecydowanie co z nimi zrobić. Tania mądrość: problemy są znacznie łatwiejsze do obsługi, gdy myślałeś o nich wcześniej.
Prosty, szeroko stosowany narzędzie do śledzenia zagrożeń i elementów projektu:
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)
For each risk, score:
LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
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
Projekt zależy od nowego i nieprzetestowanego interfejsu API zewnętrznego. Ryzyko: może nie działać. Prawdopodobieństwo średnie, wpływ wysoki. Łagodzenie: przetestuj to wcześnie, zbuduj abstrakcję, aby móc zamieniać dostawców, i miej zapasowe rozwiązanie. Teraz nieznane jest ryzykiem zarządzanym z planem.
Traktowanie zarządzania ryzykiem jako jednorazową listę kontrolną kickoff. Ryzyka ewoluują — regularnie przeglądaj dziennik RAID i dodawaj nowe w miarę ich pojawiania się.
Niezarządzane ryzyka stają się kryzysami, zwykle w najgorszym możliwym momencie tuż przed terminem.
Koszt obsługi ryzyka na wczesnym etapie jest znikomy w porównaniu z gaszeniem pożaru po tym, jak się pojawi.
Zwerbalizowanie ryzyk na głos buduje również zaufanie — interesariusze wolą "tu jest to, co może się nie udać i nasz plan" niż zaufaną cisz, a potem niespodziana niespodzianka.