Ryzyko żyje w rejestrze. Jest opis, jest ocena, czasem nawet jest „plan reakcji”. Problem w tym, że sam rejestr jeszcze niczym nie steruje. Sterowanie zaczyna się dopiero wtedy, gdy ryzyko jest sprzęgnięte z decyzjami: z jasno ustalonym mandatem zespołu, z progami tolerancji, z zasadami eskalacji i z formatem raportowania, który nie zachęca do dyskusji o tabeli, tylko wymusza rozstrzygnięcia.
Niniejszy artykuł pisałem w formie warsztatownika – pokazuje praktyczny, minimalny zestaw: progi tolerancji, prosty sposób liczenia i trendowania ekspozycji na ryzyko oraz dwa artefakty, które domykają temat operacyjnie: jednostronicowy raport o stanie ryzyka i Risk Decision Log. W efekcie ryzyko przestaje być listą zdarzeń, a staje się elementem procesu zarządczego.
Progi tolerancji
Tolerancja ryzyka to konkretne progi, które mówią: kiedy projekt może działać samodzielnie, a kiedy musi poprosić o decyzję. Dobrze ustawione tolerancje ograniczają chaos w eskalacjach i ucinają niekończące się dyskusje typu „czy to już jest problem, czy jeszcze nie”.
Najprościej zacząć od kilku wymiarów, które w praktyce obejmują większość projektów. Zwykle wystarczą: koszt,czas, zakres/jakość, zgodność i bezpieczeństwo, ewentualnie reputacja/interesariusze. W organizacjach mniej dojrzałych lepiej zacząć nawet od trzech: koszt, czas, zgodność. Chodzi o to, żeby progi były rozumiane, niżeli ładne w dokumentacji.
Najbardziej użyteczny jest model trójkoloru (zielony/żółty/czerwony), bo pozwala połączyć tolerancje z prostą logiką działania:
- Zielony: mieści się w mandacie Project Managera i zespołu, praca odbywa się standardowo (monitoring, działania ograniczające, aktualizacja ryzyk).
- Żółty: przekroczony próg ostrzegawczy, potrzebna jest akceptacja sponsora lub uzgodnienie decyzji (np. uruchomienie rezerwy, zmiana priorytetów, korekta planu).
- Czerwony: przekroczony próg krytyczny, eskalacja jest obowiązkowa i kończy się formalną decyzją (komitet/zarząd), wraz z planem działań i terminem przeglądu.
To, co realnie daje podstawy tolerancji, to uzgodnienia poczynione na start etapu lub projektu. W praktyce to może wyglądać tak:
Karta tolerancji projektu:
| Wymiary tolerancji: koszt / czas / zakres-jakość / zgodność / reputacja |
| Zielony: odchylenia w ramach uprawnień Project Managera |
| Żółty: wymagana akceptacja sponsora |
| Czerwony: obligatoryjna decyzja komitetu/zarządu |
| Kto decyduje w żółtym i czerwonym: (rola + forum) |
| Kiedy przeglądamy tolerancje: start etapu, bramka decyzyjna, po istotnej zmianie zakresu |
Jeżeli potrzebne są przykładowe progi, można zacząć od wartości „bezpiecznie konserwatywnych” i dostroić po 1-2 cyklach raportowania. Przykładowo:
- Koszt: zielony do +2% > żółty +2-5% > czerwony powyżej +5%
- Czas: zielony do 1 tygodnia > żółty 1-3 tygodnie > czerwony powyżej 3 tygodni
- Zgodność: zielony drobne korekty bez wpływu na zgodność > żółty potencjalna niezgodność wymagająca konsultacji > czerwony ryzyko niezgodności nieakceptowalne lub wymagające formalnej decyzji
Najczęstsze problemy: organizacja ma tolerancje „w głowie sponsora”, a zespół ich nie zna. Drugie: progi są tak drobiazgowe, że nikt ich nie pamięta. Trzecie: progi istnieją, ale nie ma reguły „co się dzieje po przekroczeniu”. Właśnie dlatego tolerancje trzeba od razu spiąć z raportowaniem i decyzjami.
Ekspozycja na ryzyko: policzyć i monitorować, żeby dało się porównać projekty i podejmować decyzje
Ekspozycja na ryzyko to odpowiedź na pytanie: „Ile ryzyka niesie projekt (albo portfel) w tym momencie?”. W praktyce ekspozycja jest przydatna tylko wtedy, gdy da się ją porównać w czasie (trend) i między projektami (spójne zasady liczenia). Nie trzeba od razu wchodzić w skomplikowaną matematykę. Dobrze działają dwa podejścia: punktowe oraz finansowe/czasowe (gdy organizacja potrafi estymować skutki).
Zacznijmy od metody punktowej, która pozwala porównać ryzyka między sobą i ustalić priorytety działań. Nie jest to „jedna formalna, poprawna metoda z certyfikatem”, a raczej praktyczny standard: skala P (Probability) i I (Impact) oraz wynik Score, czyli „siła/istotność ryzyka”.
Rozbijmy wzór na czynniki pierwsze, zaczynając od P.
P = Probability (prawdopodobieństwo)
P opisuje, jak bardzo realne jest, że ryzyko się zmaterializuje, czyli że zdarzenie faktycznie wystąpi.
- Skala 1-5 nie jest „matematycznym prawdopodobieństwem” w sensie 17% czy 62% (choć można to tak zdefiniować).
- To zazwyczaj skala porządkowa: 1 = bardzo mało prawdopodobne, 5 = niemal pewne.
Przykładowa definicja (do wklejenia do metodyki projektu):
- 1: rzadkie (może się zdarzyć w wyjątkowych okolicznościach)
- 2: mało prawdopodobne
- 3: możliwe
- 4: prawdopodobne
- 5: niemal pewne / dzieje się już teraz
I = Impact (wpływ / skutek)
I opisuje, jak poważne będą konsekwencje, jeśli ryzyko się zmaterializuje.
Wpływ warto definiować w odniesieniu do tego, co projekt uznaje za realny problem (kosztowo, czasowo etc):
- koszt (budżet),
- czas (terminy),
- zakres/jakość,
- zgodność (compliance) i bezpieczeństwo,
- reputacja / interesariusze.
Przykładowa definicja skali 1-5:
- 1: wpływ mały – bez zmiany decyzji, drobna korekta operacyjna
- 2: niski – lokalna korekta planu
- 3: średni – trzeba zmienić plan/priorytety, ale bez naruszania celów projektu
- 4: wysoki – narusza cele etapu lub wymaga zgody sponsora
- 5: krytyczny – zagraża celom projektu / wymaga decyzji komitetu / ma ciężkie skutki zgodności lub reputacji
Ważna uwaga praktyczna: I powinno być oceniane konsekwentnie. Jeśli raz wpływ „3” oznacza „dwa tygodnie opóźnienia”, a w innym ryzyku „3” oznacza „miesiąc”, to porównywanie przestaje mieć sens. Dlatego dobrze jest dopisać do skali krótkie progi (np. w dniach, % budżetu, typach konsekwencji).
Score = P × I (ocena/priorytet ryzyka)
Score (czasem nazywany „Risk Score” lub „Risk Rating”) to wynik punktowy ryzyka liczony jako iloczyn P i I:
Score = P × I
- jeśli P i I są w skali 1-5, to Score jest w zakresie 1-25,
- im wyższy Score, tym „mocniejsze” ryzyko (bardziej istotne),
- Score służy do priorytetyzacji: na czym pracować najpierw, co eskalować, co raportować w TOP 5.
Przykład:
- Ryzyko A: P=4 (prawdopodobne), I=4 (wysokie) > Score=16
- Ryzyko B: P=2 (mało prawdopodobne), I=5 (krytyczne) > Score=10
- Ryzyko C: P=5 (niemal pewne), I=2 (niski) > Score=10
Wynik pokazuje, że ryzyko A jest w tym modelu bardziej „pilne” (16), ale B i C też mogą wymagać działań – tyle że z innych powodów.
Potem pozostaje wybrać, jak liczyć ekspozycję projektu. Żeby sztucznie nie pompować wyniku długą listą drobnicy, sprawdzają się dwa warianty:
- Wariant A: suma score dla ryzyk powyżej progu (np. liczymy tylko te z wynikiem 12+)
- Wariant B: suma score dla TOP 10 ryzyk (stała liczba pozycji daje porównywalność)
Wariant analizujący ryzyka finansowe:
EMV (Expected Monetary Value) to sposób, by policzyć oczekiwany koszt ryzyka: prawdopodobieństwo wystąpienia razy skutek finansowy. Dzięki temu da się racjonalnie ustalać rezerwy i wybierać reakcje, które najbardziej „opłaca się” wdroży W podejściu finansowym do ryzyka często pojawia się skrót EMV (Expected Monetary Value), czyli oczekiwana wartość pieniężna. To sposób na przełożenie ryzyka na język finansowy: ile „średnio” może kosztować dane ryzyko, jeśli wziąć pod uwagę zarówno jego prawdopodobieństwo, jak i potencjalną stratę.
EMV jest szczególnie przydatne wtedy, gdy trzeba rozmawiać o:
- rezerwach budżetowych (ile rezerwy ma mieć projekt),
- wariantach decyzji (czy opłaca się inwestować w ograniczanie ryzyka),
- priorytetach (które ryzyka „dowożą” największą wartość po ograniczeniu).
Wzór EMV
Zapis jest prosty:
EMV = P × koszt
gdzie:
- P to prawdopodobieństwo wystąpienia ryzyka (najlepiej jako liczba od 0 do 1, np. 0,2 zamiast „2/5”),
- koszt to szacowany skutek finansowy, jeśli ryzyko się zmaterializuje (np. dodatkowe wydatki, kary, prace poprawkowe, koszty przestoju).
Wynik EMV jest w tej samej jednostce co koszt, czyli zwykle w PLN.
Jak interpretować EMV
„Jeśli w podobnych warunkach realizować ten projekt wiele razy, to średni koszt tego ryzyka wyniósłby około X.”
To jest wartość oczekiwana, a więc narzędzie do podejmowania decyzji, której nie należy mylić z gwarancją.
Przykład:
Ryzyko: „opóźnienie integracji > konieczność dodatkowych prac po stronie dostawcy”.
- Prawdopodobieństwo: P = 0,30 (30%)
- Jeśli wystąpi: dodatkowy koszt = 80 000 zł
EMV = 0,30 × 80 000 zł = 24 000 zł
Interpretacja: „To ryzyko wnosi do projektu przeciętnie 24 tys. zł oczekiwanego kosztu”. Jeżeli projekt ma kilka takich ryzyk, EMV pomaga zobaczyć, gdzie jest „finansowy ciężar” niepewności.
EMV a decyzje: kiedy to ma sens w praktyce
EMV jest bardzo wygodne w dwóch typowych sytuacjach:
1) Ustalanie rezerwy na ryzyko
Jeżeli zidentyfikowano kilka istotnych ryzyk i dla każdego oszacowano P i koszt, można policzyć EMV dla każdego, a potem:
- albo zsumować EMV (zachowując zdrowy rozsądek),
- albo wyznaczyć „koszyk rezerwy” na najważniejsze ryzyka.
Co warto podkreślić, nie należy doszukiwać się tutaj gotowej polityki finansowej a jedynie uzasadnienia dlaczego rezerwa jest w takim a nie innej wysokości.
2) Ocena opłacalności reakcji na ryzyko
Przykład:
Ryzyko ma EMV = 24 000 zł.
Proponowana reakcja (np. dodatkowe testy, audyt integracji, prototyp) kosztuje 10 000 zł i obniża prawdopodobieństwo z 0,30 do 0,10.
Nowe EMV po reakcji:
- 0,10 × 80 000 zł = 8 000 zł
„Zysk” z reakcji w sensie oczekiwanym:
- 24 000 zł – 8 000 zł = 16 000 zł
Jeśli koszt reakcji to 10 000 zł, to w ujęciu oczekiwanym decyzja wygląda racjonalnie (redukcja oczekiwanej straty większa niż koszt reakcji).
„Koszt” w EMV
„Koszt” w EMV powinien być możliwie konkretny i policzalny. Zwykle to:
- dodatkowe roboczogodziny (wewnętrzne i zewnętrzne),
- koszty dostawcy (change request, prace poprawkowe),
- kary umowne lub koszty niezgodności,
- koszty przestojów/utraconych przychodów (jeśli sensownie mierzalne),
- koszty obejść tymczasowych.
Dobrą praktyką jest też rozróżnienie:
- koszt bezpośredni (faktury, prace),
- koszt pośredni (np. wydłużenie utrzymania starego systemu).
Na poziomie projektu wystarczy zacząć od kosztów bezpośrednich, a pośrednie dodawać tylko, gdy organizacja umie je sensownie szacować.
Uwaga:
| P powinno być liczbą 0-1, a nie punktami 1-5 Da się to przeliczyć (np. 1=10%, 2=30%, 3=50%, 4=70%, 5=90%), ale trzeba to jasno zdefiniować. W przeciwnym razie EMV staje się dowolne. |
| „Koszt” bywa widełkami, a nie jedną liczbą Jeżeli koszt jest niepewny, lepiej używać scenariuszy (optymistyczny / realistyczny / pesymistyczny) i liczyć EMV na scenariuszu realistycznym, a resztę traktować jako wrażliwość. |
| Suma EMV wielu ryzyk nie zawsze = rezerwa Ryzyka mogą być skorelowane (jedno zwiększa drugie), a część się wyklucza. Dlatego EMV to wsparcie decyzji, a nie automatyczny algorytm budżetowy. |
| EMV nie zastępuje tolerancji Ryzyko zgodności może mieć „niskie P”, ale jeśli skutki są nieakceptowalne, to i tak wymaga eskalacji, niezależnie od EMV. |
Skupmy się teraz na raportowaniu, który miałby umożliwić podjęcie właściwej decyzji.
W mojej praktyce projektowej, szczególnie cenny jest OnePager, przygotowany w dowolnym narzędziu (najczęściej PowerPoincie). Jeżeli ryzyko ma prowadzić do decyzji, to raport nie może być ani wyciągiem z rejestru ani też ścianą liczb, które bez szczegółowej analizy będą tylko surowymi danymi. W zamiajn za to powinien być krótkim obrazem sytuacji i listą decyzji do podjęcia. Stąd powyższa sugestia – najlepiej działa format jednostronicowy, bo zmusza do świadomej selekcji. Minimalny układ jest prosty: trend ekspozycji, TOP ryzyka, ryzyka przekraczające tolerancje, a na końcu lista decyzji.
Poniżej zamieszczam proponowany schemat dla Onepagera (Risk Snapshot)
Nagłówek:
- Projekt / okres raportowania / autor raportu
- Status: zielony / żółty / czerwony (wynikający z tolerancji)
1) Trend ekspozycji (4-8 ostatnich okresów):
- ekspozycja projektu w czasie (wyliczony zgodnie z wcześniej omawianym wzorem score lub EMV)
- krótki komentarz: co wpłynęło na zmianę
2) TOP 5 ryzyk:
Dla każdego:
- opis ryzyka (1 zdanie, „zdarzenie + skutek”)
- P/I/score lub EMV
- Właściciel (dobrą praktyką jest wskazanie osoby, która realnie może coś o ryzyku powiedzieć)
- reakcja (co robimy)
- najbliższy krok i termin
- status działań: on track / off track
3) Ryzyka przekraczające tolerancje:
- lista 1-3 pozycji
- wskazanie progu: np. „czas > żółty/czerwony”, „zgodność > czerwony”
4) Decyzje do podjęcia
- decyzja jako pytanie: „Czy akceptujemy?”, „Czy uruchamiamy rezerwę?”, „Czy zmieniamy zakres?”
- rekomendacja Project Managera wraz z wyszczególnionymi konsekwencjami
Zaproponowany układ umożliwi dwie rzeczy. Po pierwsze, sprowadza rozmowę o ryzyku do tego, co najważniejsze. Po drugie, wymusza przejście z „informacji” do „decyzji”. Właśnie dlatego w raporcie powinna pojawić się sekcja „Decyzje do podjęcia”. Bez niej spotkania z ryzykiem zamieniają się w statusy i komentarze.
Taki raport działa tylko wtedy, gdy jest osadzony w rytmie:
- przegląd ryzyk w zespole: co tydzień lub co 2 tygodnie (krótko, operacyjnie),
- przegląd ze sponsorem: raz w miesiącu lub na końcu etapu,
- komitet/portfel: tylko gdy jest czerwone ryzyko lub gdy decyzja przekracza mandat PM.
Podstawowa zasada: spotkanie portfelowe nie służy do „czytania rejestru”. Powinna słuzyć do podjęcia decyzji na podstawie jednej strony raportu.
Ryzyka też da się KPIować. Warto mierzyć kilka prostych wskaźników jakości zarządzania ryzykiem, bo one szybko pokazują, czy organizacja ma „ryzyka” czy „zarządzanie ryzykiem”:
| % ryzyk z właścicielem, |
| % ryzyk z reakcją i terminem, |
| liczba ryzyk przekraczających tolerancję (trend), |
| czas przebywania ryzyk wysokich w TOP 5, |
| ile ryzyk obniżyło score po działaniach (skuteczność reakcji). |
Risk Decision Log
Warto wprowadzić osobny, prosty Risk Decision Log. Jego rola jest inna niż rejestru ryzyk: rejestr przechowuje ryzyka, a log przechowuje decyzje i pozwala do nich wracać w kontrolowany sposób. To szczególnie ważne, gdy decyzja polega na akceptacji ryzyka, uruchomieniu rezerwy, zmianie zakresu czy przesunięciu priorytetów.
Poniżej proponowane części składowe Risk Decision Log
| ID decyzji |
| Data i forum decyzyjne (sponsor / komitet / zarząd) |
| Powiązane ryzyko(a) (ID z rejestru) |
| Decyzja (1 zdanie) |
| Uzasadnienie (2-3 punkty) |
| Rozważane opcje (A/B/C) i powód odrzucenia |
| Konsekwencje podjęcia decyzji (co poświęcamy, co zyskujemy) |
| Właściciel wdrożenia decyzji |
| Termin przeglądu decyzji (kiedy wracamy i sprawdzamy, czy działa) |
Taki log jest skuteczny, bo wprowadza jakość decyzji. Prosta checklista, którą warto stosować przed zamknięciem wpisu, wygląda tak:
- czy decyzja odnosi się do tolerancji (jaki próg i w jakim wymiarze)?
- czy ma właściciela i termin?
- czy ma warunek przeglądu (kiedy wracamy)?
- czy skutki uboczne są świadome i zaakceptowane?
Dla zobrazowania, krótki przykład z życia projektu: pojawia się ryzyko opóźnienia integracji z systemem zewnętrznym, które przekłada się na przesunięcie kamienia milowego o 4 tygodnie. Tolerancja czasu w projekcie mówi, że powyżej 3 tygodni jest czerwone. W raporcie „Risk Snapshot” ryzyko trafia do sekcji „przekroczenie tolerancji”, a w sekcji decyzji pojawia się pytanie: czy uruchomić rezerwę na dodatkowe zasoby integracyjne i jednocześnie przesunąć zakres etapu (odłożyć funkcjonalności niekrytyczne). Komitet decyduje „tak”, a decyzja trafia do Decision Log z uzasadnieniem, opcjami alternatywnymi i datą przeglądu po dwóch tygodniach. Dzięki temu nikt po miesiącu nie wraca do tematu w trybie „a kto to w ogóle ustalił?” i nie rozpoczyna dyskusji od zera.