Kako identificirate in upravljate tveganja projektov (RAID)?

Question

Accepted Answer

**Tveganje** je nekaj, kar se *morda* zgodi in bi škodilo projektu, če bi se zgodilo. **Upravljanje tveganj** je identifikacija teh nevarnosti zgodaj in odločitev, kaj storiti glede njih *preden* te zadanejo. Poceni vpogled: probleme je daleč lažje obvladati, če ste jih že vnaprej razmislili.

## Dnevnik RAID

Enostavno, široko uporabljeno orodje za sledenje grožnjam projektov in predmetom:

```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)
```

## Ocenite vsako tveganje

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

## Izberite odgovor

```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
```

## Konkreten primer

Projekt je odvisen od nove in nepreizkušene zunanje API-je. Tveganje: morda ne bo delala dobro. Verjetnost srednja, vpliv visok. Zmanjšanje tveganja: preizkusite jo zgodaj, zgradite abstrakcijo, da lahko zamenjate ponudnike, in imejte rezervni naročnik. Sedaj je neznanka upravljano tveganje s planom.

## Pogosta past

Objavljanje upravljanja tveganj kot enkratni uvodni seznam. Tveganja se razvijajo — redno preglejte dnevnik RAID in dodajte nova, ko se pojavijo.

## Zakaj je to pomembno

Neupravljena tveganja postanejo krize, navadno v najslabšem mogočem trenutku blizu roka.

Stroški obvladovanja tveganja zgodaj so drobni v primerjavi s gajenjem požara po tem, ko se zgodi.

Poimenovanje tveganj na glas tudi gradi zaupanje — deležniki raje vidijo »tukaj je, kaj bi šlo narobe in naš načrt« kot samozavesten molk, ki mu sledi neprijetna presenečenja.