Dziennik RAID to dokument używany przez kierowników projektów, analityków biznesowych, menedżerów ds. ryzyka, liderów zespołów i kadrę kierowniczą w celu wspierania zarządzania ryzykiem projektu poprzez podsumowanie następujących kluczowych informacji:
- Ryzyka
- A — założenia lub działania
- I — problemy
- D — zależności lub decyzje
Jako kierownik projektu możesz używać dziennika RAID, aby zapewnić interesariuszom — i sobie — jasny obraz najnowszych informacji o projekcie. Jeśli jest prowadzony prawidłowo, dziennik ten może pełnić funkcję kluczowego dokumentu strategicznego podsumowującego kondycję projektu na poziomie kadry kierowniczej.
Dzienniki RAID są często używane wraz z oprogramowaniem do zarządzania ryzykiem.

Czym jest dziennik RAID i co oznacza skrót „RAID”?
RAID oznacza: ryzyka, założenia (lub działania), problemy oraz zależności (lub decyzje).
| Definicja elementu dziennika RAID | Przykłady |
|---|---|
| Ryzyka. Identyfikuj i kategoryzuj ryzyka oraz szanse, prawdopodobieństwo ich wystąpienia, ich wpływ lub dotkliwość w przypadku wystąpienia, a także plan ograniczania ryzyka i działania | -Ryzyko: Niekorzystne warunki pogodowe opóźniają harmonogram gromadzenia danych |
| A — założenia lub działania. Dokumentuj parametry projektu, aby zapobiegać niekontrolowanemu rozszerzaniu zakresu; prowadź listę zadań do wykonania na podstawie bieżących prac projektowych | -Założenie: wymagane zasoby są dostępne do realizacji prac projektowych -Działanie: skontaktuj się z zespołem finansowym w celu uzyskania zestawienia kosztów obecnych dostawców zewnętrznych |
| I — problemy. Dokumentuj zdarzenia, które wystąpiły i wpływają na postęp projektu, oraz wyjaśniaj sposób ich rozwiązania | -Problem: Naruszenie bezpieczeństwa naraża na szwank integralność danych klientów |
| D — zależności lub decyzje. Wymieniaj działania, których nie można rozpocząć ani ukończyć bez rozpoczęcia lub ukończenia innego działania; dokumentuj wcześniej uzgodnione sposoby postępowania oraz uzasadnienie ich realizacji lub rezygnacji z ich realizacji | -Zależność: przeprowadź analizę alternatyw przed zakupem nowego systemu zarządzania dostawcami -Decyzja: zbuduj wewnętrzny system zarządzania talentami, aby utrzymać koncentrację na kulturze wysokiej efektywności, mimo że w krótkim okresie będzie to bardziej kosztowne |
Jak widać, definicja RAID obejmuje kilka podwójnych akronimów: założenia lub działania, zależności lub decyzje. Oto moje spostrzeżenia dotyczące podejścia do tych elementów:
- Założenia a działania. Nie potrafię powiedzieć, ile razy sama lista założeń powstrzymała niekontrolowane rozszerzanie zakresu. Jeśli chcesz, aby dziennik był skierowany do kadry wyższego szczebla, zalecam przechowywanie elementów działań w osobnym dokumencie skoncentrowanym na realizacji taktycznej.
- Decyzje a zależności. Z mojego doświadczenia wynika, że nikt nigdy nie pamięta, dlaczego podjęto konkretne decyzje — zwłaszcza jakie alternatywy rozważano, ale odrzucono, ani z jakich powodów. Aby uniknąć powielania sposobu myślenia w trakcie długotrwałej współpracy, zalecam dokumentowanie decyzji w dzienniku RAID, oprócz zależności.
Kiedy należy utworzyć dziennik RAID?
Dziennik RAID należy utworzyć na początku projektu, podczas fazy inicjowania lub planowania, gdy znane są już wystarczające informacje na temat zakresu, interesariuszy i celów, aby zidentyfikować początkowe ryzyka i założenia. Następnie należy go przeglądać przy głównych kamieniach milowych, za każdym razem, gdy zmienia się zakres, lub gdy pojawia się istotne ryzyko albo problem. W projektach Agile naturalnym momentem aktualizacji jest początek każdego sprintu.
Dziennik RAID a rejestr ryzyka
Chociaż te dwa dokumenty częściowo się pokrywają, różnica polega na tym, że dziennik RAID jest bardziej kompleksowy niż rejestr ryzyka. Oprócz dokumentowania ryzyk dziennik RAID obejmuje również założenia lub działania, rejestr problemów oraz zależności lub decyzje.
Szablon dziennika RAID
Dołączyłem plik do pobrania z szablonem dziennika RAID szablonu w programie Microsoft Excel (aby otrzymać szablon, musisz być członkiem DPM). Możesz użyć tego szablonu do dokumentowania ryzyk, założeń, problemów i zależności. Kolumny M i N służą do śledzenia decyzji oraz dat ich podjęcia.
Przykład dziennika RAID
Oprócz szablonu dziennika RAID dołączyłem również przykładowy dziennik w programie Excel, aby można było zobaczyć, jak wygląda gotowy produkt (aby uzyskać do niego dostęp, również musisz być członkiem).

Oto kolejny przykład pokazujący, jak dzienniki RAID można zastosować w scenariuszu projektu polegającego na organizacji wyjazdu kempingowego.

Jak utworzyć dziennik RAID
Skoro masz już gotowy szablon, jak dokładnie go wypełnić? Podczas fazy planowania projektu będziesz w stanie zebrać informacje dotyczące następujących elementów dziennika RAID:
- Ryzyka
- Założenia
- Zależności
Działania, problemy i decyzje pojawiają się dopiero po rozpoczęciu projektu.
Dla każdego rejestrowanego elementu zapisz co najmniej następujące pola:
- Opis — krótkie podsumowanie ryzyka, założenia, problemu lub zależności
- Właściciel — osoba odpowiedzialna za zarządzanie danym elementem lub jego rozwiązanie
- Priorytet — wysoki, średni lub niski
- Status — otwarty, w toku lub zamknięty
- Termin docelowy — termin, do którego element powinien zostać rozwiązany lub poddany przeglądowi
- Plan ograniczania ryzyka/działań — kroki podejmowane w celu rozwiązania problemu
Stosowanie spójnych pól dla każdego wpisu ułatwia interesariuszom szybkie przeglądanie dziennika i jego późniejsze utrzymanie.
Potencjalne źródła informacji dla dziennika RAID
Informacje do dziennika można pozyskiwać z wielu źródeł:
- Wywiady z interesariuszami
- Bieżąca lub wcześniejsza dokumentacja projektu
- Przykłady: szablon wniosków, retrospektywy, analizy po zakończeniu projektu, karty projektu, plany projektu, harmonogramy projektów
- Wcześniejsze doświadczenie w realizacji podobnych projektów
- Materiały dostępne w internecie
- Myślenie krytyczne oparte na informacjach zebranych z powyższych źródeł (np. interesariusze nie mówią wprost, że coś stanowi problem, ale ich niechęć do poruszenia tego tematu sugeruje, że ten obszar wymaga dokładniejszego rozpoznania).
Najlepsze praktyki
Po rozpoczęciu projektu i przygotowaniu wstępnego dziennika RAID pamiętaj o poniższych najlepszych praktykach dotyczących korzystania z dziennika podczas zarządzania projektem:
- Dostosuj poziom szczegółowości do odbiorców. Interesariusze korzystają z dziennika RAID, aby zrozumieć kontekst projektu oraz ryzyka i problemy, które mogą zagrozić jego powodzeniu. Skup się na wpływie na biznes, a nie na aktualizacjach taktycznych, które mogą nie mieć znaczenia dla osoby niezaangażowanej w codzienną pracę.
- Monitoruj dziennik i aktualizuj go przez cały cykl życia projektu. Ten dokument jest bezużyteczny, jeśli go nie aktualizujesz i nie wykorzystujesz zawartych w nim informacji w innych dokumentach, takich jak dziennik decyzji. To kolejny powód, aby zachować zwięzłość treści, dzięki czemu dokument nie będzie uciążliwy w utrzymaniu. Większość czasu powinna być poświęcana na usuwanie przeszkód, a nie na ich dokumentowanie.
Korzyści
Dzienniki RAID przynoszą korzyści interesariuszom, członkom zespołu projektowego, firmie oraz Tobie jako kierownikowi projektu.
- Stanowią jedno miejsce zawierające istotne informacje o projekcie i zapewniają łatwy dostęp do aktualnych informacji o kondycji projektu
- Umożliwiają śledzenie ryzyk, zanim przerodzą się w problemy, a następnie szybkie ustalanie priorytetów problemów, jeśli ryzyka się zmaterializują
- Kierownicy projektów mogą dokumentować założenia i decyzje, aby ograniczyć ryzyko konieczności powracania do dyskusji, które mogą opóźnić projekt.
Jak używa się dzienników RAID w metodyce zwinnej?
Zazwyczaj projekty zwinne unikają dokumentacji na rzecz tworzenia działającego produktu. Mimo to uważam, że przygotowanie dziennika RAID jest warte dodatkowego wysiłku.
Dlaczego? Projekty zwinne zazwyczaj opierają realizację projektu na podejściu iteracyjnym, które sprzyja większej liczbie eksperymentów. To podejście doskonale sprawdza się w szybkim popełnianiu błędów, aby szybciej wyciągać wnioski.
Jednak odejście od stygmatyzowania porażek wiąże się z dodatkowymi ryzykami, które mogą wykoleić projekt. Organizacja może wyciągać wnioski z porażek tylko wtedy, gdy dokumentuje założenia i proces podejmowania decyzji, które stały za każdym eksperymentem.
Co dalej?
Jeśli potrzebujesz dodatkowej pomocy w zarządzaniu ryzykiem, rozważ udział w naszym kursie „Mistrzowskie zarządzanie projektami cyfrowymi”. Oprócz zarządzania ryzykiem nauczysz się również zarządzać projektami przez cały cykl ich życia — od rozpoczęcia po zamknięcie projektu.
