Na jednym z projektów wdrożeniowych zespół przez trzy miesiące budował integrację z systemem, do którego dostawca nie dał jeszcze dostępu testowego. Wszyscy o tym wiedzieli. Nikt tego nie zapisał. Kiedy dostęp w końcu przyszedł, okazało się, że API wygląda inaczej niż dokumentacja - i sprint planowany na tydzień zajął pięć.
To nie był pech. To było ryzyko, które widzieli wszyscy, ale nie miało właściciela, oceny ani planu. Dokładnie od tego jest rejestr ryzyk - i w tym artykule pokażę Ci, jak go zbudować krok po kroku, z gotowym szablonem i kompletnym przykładem dla wdrożenia CRM.
Ryzyko to nie problem - różnica, która zmienia sposób planowania
Zacznijmy od rozróżnienia, które w praktyce myli się nagminnie:
- Problem (issue) - coś, co JUŻ się dzieje. Dostawca nie dostarczył API. Główny analityk odszedł. Reagujesz.
- Ryzyko - coś, co MOŻE się wydarzyć i wpłynąć na cele projektu. Dostawca może się spóźnić. Analityk może odejść. Planujesz.
Różnica brzmi akademicko, ale ma twarde konsekwencje. Problemem zarządzasz w trybie gaszenia pożaru. Ryzykiem zarządzasz, zanim pożar wybuchnie - taniej, spokojniej i z większym wyborem opcji. Jeśli w Twoim projekcie "rejestr ryzyk" to w praktyce lista rzeczy, które już się wysypały, to nie masz rejestru ryzyk. Masz kronikę porażek.
Jeszcze jedno: ryzyko ma dwie strony. BABOK definiuje ryzyko jako wpływ niepewności na wartość - zmiany, rozwiązania albo całej organizacji. Ten wpływ może być negatywny (zagrożenie) albo pozytywny (szansa). W praktyce zdecydowana większość wpisów w rejestrach to zagrożenia i tym się tu zajmiemy, ale miej z tyłu głowy, że "klient może chcieć rozszerzyć zakres o moduł X" to też pełnoprawny wpis do rejestru.
Identyfikacja ryzyk: techniki warsztatowe, które naprawdę działają
Najgorszy sposób identyfikacji ryzyk: PM siada sam przy biurku i wypełnia tabelkę, bo audyt wymaga. Ryzyka zna zespół, biznes i dostawcy - nie jedna osoba. Dwie techniki, które u mnie działają najlepiej:
Pre-mortem: "projekt się wywalił - dlaczego?"
Zbierasz zespół i interesariuszy na 60-90 minut i ogłaszasz: "Jest rok po wdrożeniu. Projekt okazał się porażką. Napiszcie, co poszło nie tak." Każdy pisze samodzielnie, na kartkach albo w tablicy online, przez 10 minut. Potem grupujecie i omawiacie.
Dlaczego to działa lepiej niż pytanie "jakie widzicie ryzyka?" - bo odwraca psychologię. Przy zwykłej burzy mózgów ludzie nie chcą wyjść na malkontentów, którzy torpedują projekt. W pre-mortem porażka jest założeniem scenariusza, więc wskazywanie przyczyn to zadanie, nie krytyka. Nagle ludzie mówią rzeczy w stylu "sponsor i tak nie ma czasu na decyzje, utkniemy na akceptacjach" - czyli dokładnie to, czego potrzebujesz.
Przegląd założeń: każde założenie to uśpione ryzyko
Otwórz dokumentację projektu i wypisz wszystkie założenia - te spisane i te "oczywiste". "Zakładamy, że dane klientów w starym systemie są kompletne." "Zakładamy, że dział sprzedaży wydeleguje osobę do testów." "Zakładamy, że licencje wystarczą dla 200 użytkowników."
Teraz przy każdym zadaj dwa pytania: co jeśli to nieprawda? Skąd wiemy, że to prawda? Jeśli odpowiedź na drugie pytanie brzmi "no... nikt tego nie sprawdził", masz świeży wpis do rejestru. Z mojego doświadczenia to najtańsza technika identyfikacji - założenia już są spisane, wystarczy je zakwestionować.
Do tego dorzuć: wywiady z ludźmi, którzy robili podobny projekt wcześniej, oraz lessons learned z poprzednich wdrożeń, jeśli organizacja je prowadzi. Ryzyka lubią się powtarzać.
Jedna zasada zapisu: ryzyko formułuj jako przyczynę i skutek, nie jako hasło. Nie "integracja", tylko "ponieważ dokumentacja API dostawcy jest nieaktualna, integracja może wymagać przeróbek, co opóźni start testów UAT". Hasłem nie da się zarządzać. Zdaniem przyczynowo-skutkowym - tak.
Ocena ryzyka: prawdopodobieństwo x wpływ, z przykładem punktacji
Masz listę 30 ryzyk z warsztatu. Nie ogarniesz wszystkich - i nie powinieneś. Ocena służy temu, żeby wiedzieć, którymi pięcioma zająć się w pierwszej kolejności.
Standard: oceniasz prawdopodobieństwo (jak bardzo możliwe, że ryzyko się zmaterializuje) i wpływ (jak mocno uderzy w cele projektu - termin, budżet, zakres, jakość). Najczęściej w skali 1-5:
| Ocena | Prawdopodobieństwo | Wpływ (przykład kalibracji) |
|---|---|---|
| 1 | rzadkie (byłoby zaskoczeniem) | pomijalny (wchłonie go bufor) |
| 2 | mało prawdopodobne | mały (do 1 tyg. opóźnienia / drobny koszt) |
| 3 | możliwe (50/50) | średni (2-4 tyg. / zauważalny koszt) |
| 4 | prawdopodobne | duży (przesunięcie kamienia milowego) |
| 5 | prawie pewne | krytyczny (zagrożony cel biznesowy projektu) |
Wynik = prawdopodobieństwo x wpływ, czyli 1-25. Umowne progi: 1-6 niskie (monitoruj), 8-12 średnie (zaplanuj odpowiedź), 15-25 wysokie (działaj teraz i eskaluj do sponsora).
Dwie pułapki, na które uważaj:
- Kalibruj skalę wpływu razem z interesariuszami. "Duży wpływ" dla dewelopera i dla dyrektora sprzedaży to dwie różne rzeczy. Spisz, co znaczy 3, a co 5 - w tygodniach, złotówkach albo procentach celu - zanim zaczniecie punktować.
- Nie uśredniaj głosów w nieskończoność. Jeśli jedna osoba daje ryzyku 2, a druga 5, nie wpisuj 3,5. Rozbieżność oznacza, że ktoś wie coś, czego nie wie reszta - dopytaj. Sama rozmowa o rozbieżności bywa cenniejsza niż wynik.
Macierz ryzyka (siatka prawdopodobieństwo x wpływ z kolorami) to tylko wizualizacja tych samych liczb - przydaje się na spotkaniu ze sponsorem, bo jedna plansza pokazuje, gdzie się pali.
Strategie odpowiedzi: unikaj, przenieś, ogranicz, akceptuj
Ocena bez odpowiedzi to sztuka dla sztuki. Dla każdego ryzyka powyżej progu wybierasz jedną z czterech strategii:
- Unikaj (avoid) - zmieniasz plan tak, żeby ryzyko zniknęło. Przykład: ryzyko "nowy framework, którego nikt w zespole nie zna, może wysadzić harmonogram" - decyzja: robimy w technologii, którą znamy. Ryzyka nie ma, bo nie ma jego źródła. Cena: czasem rezygnujesz z korzyści.
- Przenieś (transfer) - ktoś inny bierze skutki finansowe lub odpowiedzialność. Przykład: kara umowna za opóźnienie po stronie dostawcy, ubezpieczenie, kontrakt fixed-price zamiast time&material. Uwaga: przenosisz skutki, nie samo ryzyko - opóźnienie dostawcy nadal opóźnia TWÓJ projekt, tylko rachunek płaci kto inny.
- Ogranicz (mitigate) - obniżasz prawdopodobieństwo albo wpływ. Przykład: ryzyko "dane do migracji są brudne" - robisz próbną migrację na 10% danych w drugim tygodniu projektu, zamiast odkryć skalę problemu na produkcji. Najczęściej wybierana strategia, bo najbardziej elastyczna.
- Akceptuj (accept) - świadomie nic nie robisz, bo koszt odpowiedzi przewyższa skutki albo prawdopodobieństwo jest znikome. Ważne słowo: świadomie. Akceptacja to decyzja zapisana w rejestrze z nazwiskiem, nie brak decyzji. Dla akceptowanych ryzyk o większym wpływie przygotuj plan awaryjny (contingency): "jeśli jednak wystąpi, robimy X".
Dla szans działają lustrzane strategie (wykorzystaj, wzmocnij, dziel się, akceptuj). Po te sięga się rzadziej, ale kiedy w projekcie pojawia się okazja warta zapisania, dobrze mieć je pod ręką.
Rejestr ryzyk kolumna po kolumnie + gotowy szablon
Rejestr ryzyk to żywy dokument - tabela w Confluence, Sharepoincie czy arkuszu, byle była jedna, wspólna i przeglądana regularnie. Minimalny sensowny zestaw kolumn:
| Kolumna | Co wpisujesz | Po co |
|---|---|---|
| ID | R-01, R-02... | żeby dało się odwołać w rozmowie |
| Opis ryzyka | przyczyna -> skutek (pełnym zdaniem) | jednoznaczność |
| Kategoria | np. ludzie / technologia / dostawca / biznes | wzorce i raportowanie |
| Prawdopodobieństwo | 1-5 | ocena |
| Wpływ | 1-5 | ocena |
| Wynik | P x W | priorytet |
| Strategia | unikaj / przenieś / ogranicz / akceptuj | decyzja |
| Działania | konkretne kroki z terminami | wykonalność |
| Właściciel | jedna osoba (nie "zespół") | rozliczalność |
| Status | otwarte / w trakcie / zamknięte / zmaterializowane | cykl życia |
| Data przeglądu | kiedy ostatnio ktoś na to spojrzał | świeżość |
Skopiuj ten nagłówek do arkusza i masz szablon. Trzy zasady użycia, bez których rejestr umiera:
- Właścicielem ryzyka jest jedna osoba z imienia i nazwiska. Ryzyko "zespołu" nie ma nikogo, kto w nocy o nim myśli.
- Przegląd w stałym rytmie - u mnie sprawdza się 15 minut co dwa tygodnie, np. doklejone do planowania sprintu. Rejestr aktualizowany raz na kwartał to dekoracja.
- Ryzyko zmaterializowane przenosisz do listy problemów i uruchamiasz plan awaryjny - nie udajesz, że dalej "monitorujesz".
Rola BA w zarządzaniu ryzykiem wg BABOK
W BABOK Risk Analysis and Management to jedna z technik analizy biznesowej (rozdział technik, 10.38) - obejmuje identyfikację, analizę, ocenę i obsługę ryzyk, dokładnie w tym cyklu, który przeszliśmy wyżej. I to jest ważny sygnał: zarządzanie ryzykiem nie jest wyłączną działką PM-a.
Gdzie analityk biznesowy wnosi najwięcej:
- Ryzyka wymagań: niejednoznaczne, sprzeczne albo niezatwierdzone wymagania to jedno z najczęstszych źródeł problemów w projektach IT - i nikt nie widzi ich wcześniej niż BA.
- Ryzyka interesariuszy: decyzyjny interesariusz bez czasu na warsztaty, dwa działy o sprzecznych oczekiwaniach, brak decydenta dla spornego procesu. BA pracuje z tymi ludźmi na co dzień i pierwszy wyczuwa, że coś zgrzyta.
- Ryzyka rozwiązania i wartości: czy proponowane rozwiązanie faktycznie dowiezie wartość biznesową? Co jeśli użytkownicy go nie przyjmą? BABOK każe oceniać ryzyka także na poziomie strategii (Assess Risks w obszarze Strategy Analysis), nie tylko harmonogramu.
W praktyce: PM zwykle prowadzi rejestr, a BA jest jego najlepszym dostawcą wpisów - bo siedzi najbliżej wymagań, procesów i ludzi. Jeśli budujesz kompetencje w tę stronę, zerknij na ścieżki wejścia do analizy biznesowej - zarządzanie ryzykiem to jedna z tych umiejętności, które przenosisz z niemal każdego wcześniejszego zawodu. A jeśli myślisz o formalnym potwierdzeniu wiedzy z BABOK, porównanie certyfikacji znajdziesz w przeglądzie certyfikacji BA.
Przykład kompletny: rejestr ryzyk dla wdrożenia CRM
Scenariusz: średnia firma handlowa, ok. 80 użytkowników, wdrożenie CRM z migracją danych ze starego systemu i integracją z ERP. Zespół: dostawca zewnętrzny + wewnętrzny PM, BA i dział IT. Dziesięć wpisów, które w takim projekcie pojawiają się niemal zawsze:
| ID | Ryzyko (przyczyna -> skutek) | P | W | Wynik | Strategia i działanie | Właściciel |
|---|---|---|---|---|---|---|
| R-01 | Dane klientów w starym systemie zawierają duplikaty i braki -> migracja da błędne rekordy na produkcji | 4 | 4 | 16 | Ogranicz: próbna migracja 10% danych w tyg. 2, raport jakości, sprint czyszczenia przed migracją właściwą | BA |
| R-02 | Handlowcy traktują CRM jako narzędzie kontroli -> nie wpisują danych, system umiera po starcie | 4 | 5 | 20 | Ogranicz: 2 handlowców w zespole projektowym od dnia 1, pilotaż na jednym regionie, uproszczenie formularzy do pól faktycznie używanych | Sponsor (dyr. sprzedaży) |
| R-03 | Dokumentacja API systemu ERP jest nieaktualna -> integracja wymaga przeróbek i opóźnia UAT | 3 | 4 | 12 | Ogranicz: proof-of-concept integracji w pierwszym miesiącu, zanim ruszy budowa właściwa | Architekt IT |
| R-04 | Jedyna osoba znająca stary system może odejść lub być niedostępna -> wiedza o danych i procesach znika | 2 | 5 | 10 | Ogranicz: sesje dokumentacyjne z tą osobą w pierwszych 3 tygodniach, nagrywane; mapowanie danych w wiki | BA |
| R-05 | Dostawca może się spóźnić z głównymi modułami -> przesunięcie go-live | 3 | 4 | 12 | Przenieś + ogranicz: kary umowne za kamienie milowe w kontrakcie, przegląd postępu co tydzień zamiast co miesiąc | PM |
| R-06 | Zakres może puchnąć od życzeń działów ("skoro wdrażamy, to jeszcze...") -> budżet i termin przekroczone | 4 | 3 | 12 | Ogranicz: formalny proces zmiany zakresu z wyceną każdej zmiany; backlog "faza 2" na życzenia poza MVP | PM |
| R-07 | Sponsor ma napięty kalendarz -> decyzje czekają tygodniami, zespół stoi | 3 | 3 | 9 | Ogranicz: stały slot decyzyjny 30 min/tydz. w kalendarzu sponsora, lista decyzji z terminami i opcją domyślną | PM |
| R-08 | Przepisy o ochronie danych osobowych -> migracja danych klientów bez podstawy prawnej naraża firmę | 2 | 5 | 10 | Ogranicz: przegląd zakresu migrowanych danych z IOD przed migracją, minimalizacja pól | BA |
| R-09 | Szkolenia zaplanowane na szczyt sezonu sprzedażowego -> frekwencja bliska zeru, użytkownicy nie umieją pracować w systemie | 3 | 3 | 9 | Unikaj: przesunięcie szkoleń i go-live poza szczyt sezonu (decyzja sponsora, zapisana) | Sponsor |
| R-10 | Sieć w 2 oddziałach terenowych bywa niestabilna -> praca w CRM w terenie frustruje użytkowników | 2 | 2 | 4 | Akceptuj: poza progiem działania; plan awaryjny - tryb offline aplikacji mobilnej w fazie 2 | IT |
Zwróć uwagę, co w tej tabeli wygrało: najwyższy wynik ma R-02, czyli ryzyko adopcji - ludzie i procesy, a nie technologia. W projektach wdrożeniowych ten wzorzec powtarza się uparcie i właśnie dlatego BA, który siedzi najbliżej użytkowników, jest w zarządzaniu ryzykiem tak cenny. Druga rzecz: każde działanie to konkretny krok z miejscem w harmonogramie, żadnego "będziemy monitorować". I jeszcze R-10 - zaakceptowane świadomie, z uzasadnieniem i planem awaryjnym w rejestrze, zamiast przemilczenia na zasadzie "jakoś to będzie".
Taki rejestr, przeglądany co dwa tygodnie, kosztuje zespół może godzinę miesięcznie. Jedno zmaterializowane ryzyko R-01 bez planu kosztuje tygodnie.
Od czytania do robienia
Analiza ryzyka projektu to umiejętność, którą buduje się na konkretach: przeprowadzonym pre-mortem, wypełnionym rejestrze, obronionej przed sponsorem punktacji. Sama teoria nie wystarczy - rejestr z tego artykułu możesz skopiować w 5 minut, ale pewność w prowadzeniu warsztatu przychodzi z praktyką.
Jeśli chcesz ćwiczyć takie rzeczy na realistycznych scenariuszach - z wyzwaniami, case studies i feedbackiem, a nie tylko wideo do obejrzenia - załóż darmowe konto na platformie Analify i sprawdź, jak wygląda nauka analizy biznesowej przez robienie.
Najczęstsze pytania
Czym rejestr założeń różni się od rejestru ryzyk?
Założenie mierzysz pewnością i wpływem, ryzyko - prawdopodobieństwem zdarzenia i wpływem. W lekcji o odkrywaniu problemu groźny róg to niska pewność i wysoki wpływ; z niego bierzesz jedno najbardziej ryzykowne założenie i sprawdzasz je pierwsze, zanim ruszy budowa. W MediFlow było to zdanie "pacjenci-seniorzy będą umawiać wizyty przez aplikację" - nikt z zespołu nie rozmawiał z żadnym seniorem. Założenia, których nie zdążysz sprawdzić przed startem, przenosisz do rejestru ryzyk z właścicielem i terminem weryfikacji; trzy kroki tej pracy opisuje hasło założenie projektowe.
Jak pokazać ryzyka sponsorowi, który nie czyta rejestru?
Zamiast rejestru daj mu jedną stronę: decyzja, ryzyko, czego od niego potrzebujesz. Tak radzi wątek na naszym forum o sponsorze z dużą władzą i zerem czasu, który na odbiorze mówi "to nie tak miało być". Gdy za ryzykiem stoi spór dwóch działów, kartką decyzji jest tabela z dwiema-trzema opcjami i trzema kolumnami (koszt, ryzyko, termin), zamknięta pytaniem "które ryzyko akceptujesz?" - sponsor wybiera, Ty facylitujesz wybór. Jak dojść do takiej tabeli, gdy obie strony mają rację, opisujemy w tekście o sprzecznych wymaganiach.
Czy w projekcie zwinnym też prowadzi się rejestr ryzyk?
Tak, tylko rygor dobierasz do ryzyka osobno dla każdej części projektu. Lekcje o planowaniu pracy nad wymaganiami i o priorytetyzacji pokazują to na MediFlow: integracje i wymogi RODO ustalone z góry, ekrany dopracowane iteracyjnie na makietach, hybryda zamiast niezdecydowania. Ryzyko przestawia też kolejność sprintów: integrację z bramką SMS zespół bierze na warsztat wcześnie, choć samo przypomnienie ma dopiero priorytet Should, bo jeśli coś ma nie wyjść, lepiej dowiedzieć się na początku niż pod koniec. Na tej samej zasadzie Barry Boehm oparł model spiralny: o tym, co zespół robi w kolejnej pętli projektu, decyduje analiza ryzyka. Różnicę roli analityka w obu podejściach zbiera tekst Agile vs Waterfall.
Czym jest ryzyko zaniechania i czy wpisuje się je do rejestru?
To ocena skutków tego, że zmiany nie zrobimy - BABOK każe ją wykonać w zadaniu Assess Risks obok ryzyk samej zmiany. Zapisujesz ją w business case'ie jako opcję zerową, zanim powstanie rejestr: w lekcji o anatomii business case'u opcja "nic nie robić" jest obowiązkowa, bo status quo też kosztuje, a CFO i tak zapyta "a co, jeśli nie zrobimy nic?". Ryzyka samej zmiany idą do rejestru - w MediFlow choćby bojkot współdzielonych grafików przez lekarzy, z reakcją: przedstawiciel lekarzy w komitecie projektu. Budowę takiego wpisu (przyczyna, zdarzenie, skutek) opisuje hasło ryzyko projektowe.