Ryzyko projektowe (ang. project risk) to niepewne zdarzenie, które - jeśli wystąpi - wpłynie na cele projektu: zakres, termin, budżet lub jakość. Dobrze opisane ryzyko ma trzy części: przyczynę (fakt, który już istnieje), zdarzenie (co może się stać) i skutek (co to zrobi celom). Ocenia się je prawdopodobieństwem i wpływem, a odpowiedzią może być unikanie, mitygacja, transfer albo świadoma akceptacja.
Analityk biznesowy zarządza zwłaszcza ryzykami wymagań (BABOK: risk analysis and management): niejasne wymagania, niedostępni interesariusze, sprzeczne oczekiwania działów - to wszystko pozycje do rejestru ryzyk, nie tylko westchnienia na retrospektywie.
Przykład (MediFlow). Rejestr projektu e-rejestracji, pozycja R-07: ponieważ dostawca systemu gabinetowego nie potwierdził gwarantowanej przepustowości API (przyczyna), może się zdarzyć, że w porannym szczycie rezerwacje nie będą się zapisywać (zdarzenie), co podważy zaufanie pacjentów do nowego kanału w pierwszych, decydujących tygodniach (skutek). Prawdopodobieństwo: średnie. Wpływ: wysoki. Mitygacja: kolejkowanie żądań plus potwierdzenie asynchroniczne SMS-em; właściciel: architekt; przegląd co dwa tygodnie. Po PoC, który wykazał limit 10 zapytań na sekundę, ryzyko awansowało z "możliwego" na "prawie pewne bez mitygacji" - i właśnie po to prowadzi się rejestr.
Częsta pomyłka. Wpisywanie do rejestru problemów zamiast ryzyk: "dostawca opóźnia dostarczenie API" to nie ryzyko, to fakt - problemami zarządza się inaczej (natychmiast, nie przeglądem miesięcznym). Druga pomyłka: ryzyka-ogólniki w stylu "projekt może się opóźnić", bez przyczyny, właściciela i planu - takich pozycji nie da się ani monitorować, ani mitygować. Trzecia: rejestr wypełniony rytualnie na kickoffie i nieotwierany do końca projektu.