Galen Low dołącza do Kim Essendrup — dyrektora generalnego i współzałożyciela RAIDLOG.com — aby porozmawiać o dziennikach RAID i o tym, jak zintegrować je z nowoczesnym przepływem pracy nad projektem.
Najważniejsze elementy wywiadu
- Jak rozpoczął się podcast PM Happy Hour [1:35]
- Kim prowadził wiele szkoleń dla kierowników projektów. Wciąż przekazywał te same wskazówki i opublikował je na swoim blogu, ale ludzie nie chcieli czytać tak dużej ilości treści. Ktoś zasugerował mu nagrywanie podcastu. Pomyślał, że może uatrakcyjnić niektóre wpisy na blogu, przekształcając je w podcasty.
- Czym jest dziennik RAID [3:25]
- RAID oznacza ryzyka, działania, problemy i decyzje. To kluczowe narzędzie operacyjne pomagające kierownikom projektów prowadzić projekty.
- Niektórzy używają określeń założenia/zależności zamiast działania/decyzje
- Jak dziennik RAID pomaga minimalizować katastrofy lub im zapobiegać [6:58]
- Dziennik RAID to plan prawidłowej realizacji projektu.
- Projekty kończą się niepowodzeniem, gdy nie zwracasz uwagi na podstawy. Dziennik RAID pomaga zarządzać podstawowymi elementami.
Jeśli nie myślisz o ryzyku, nie planujesz działań ani nie doprowadzasz do podejmowania i dokumentowania decyzji. Wtedy plan zaczyna się rozpadać.
Kim Essendrup
- Historie z doświadczenia Kima, w których skuteczny dziennik RAID doprowadziłby do innego, bardziej pożądanego rezultatu projektu [9:09]
- Kim miał doświadczenie z klientem, którego projekt przebiegał tak źle, że klient chciał go anulować i zażądać od nich zapłaty za wszystkie problemy.
- Kim i jego zespół natychmiast polecieli do Wielkiej Brytanii, aby się z nimi spotkać.
- Po obu stronach pojawiła się frustracja i okazało się, że nie było dziennika RAID.
- Kim wraz ze swoim zespołem i klientem wypełnił dziennik RAID.
- Dzięki temu mogli wspólnie zająć się problemami, zamiast skupiać się na niedociągnięciach każdej ze stron.
Dziennik RAID to świetna platforma do uzgadniania stanowisk, upewniania się, że wszyscy wzajemnie się rozumieją, oraz tworzenia wspólnego źródła informacji o problemach, nad których rozwiązaniem możemy wspólnie pracować jako zespół.
Kim Essendrup
- Jak Kim dba o to, aby dziennik RAID pozostał źródłem prawdy [15:20]
- Kierownik projektu musi żyć tym procesem.
- Kierownik projektu musi prowadzić wiele działań związanych ze śledzeniem postępów.
- Spośród nieudanych projektów, które Kim musiał przejąć i uratować, te, w których prosił o pokazanie dziennika RAID, nie miały go.
- Pojawiają się problemy, różne sprawy są odkładane, więc jeśli wiesz, że istnieje duże prawdopodobieństwo ich wystąpienia, musisz użyć swojej superbohaterskiej broni (dziennika RAID), aby utrzymać projekt na właściwym torze.
- Dostępne narzędzia pomagające liderom projektów tworzyć dziennik RAID i zarządzać nim [18:29]
- Wdrożyli narzędzia w ponad 60 organizacjach.
- Odkryli, że dostępne na rynku narzędzia nie radzą sobie dobrze z dziennikami RAID albo w ogóle ich nie obsługują.
- Narzędzia są przeznaczone albo do prezentowania perspektywy kadry kierowniczej, albo znajdują się na drugim końcu skali — są bardzo proste i sterowane przez użytkownika. Te dwa krańce spektrum pomijają kierownika projektu.
- Kim i jego zespół stworzyli oprogramowanie do obsługi dziennika RAID — raidlog.com
- Interfejs to arkusz kalkulacyjny działający na zasadzie podłącz i używaj, wyposażony w elementy wizualne, które umożliwiają prezentowanie go podczas rozmów biznesowych z interesariuszami.
- Czy dziennik RAID jest przeznaczony tylko dla kierowników projektów? [26:58]
- Może być narzędziem do zarządzania produktem, jeśli jesteś właścicielem produktu pracującym w zwinnym środowisku.
- W roli mistrza Scrum dziennik RAID nie dotyczy tak bardzo produktu, jak zespołu — tego, jak wspierać zespół i pomagać mu odnosić sukcesy.
- Z perspektywy kierownika projektu trzeba zarządzać przełożonymi. Jakie zadania trzeba przydzielić poszczególnym osobom i nad czym powinny pracować?
- Problemy same w sobie są trudne, ale jeszcze gorsze jest ciągłe zmaganie się z tymi samymi problemami.
Dziennik RAID nie dotyczy tak bardzo produktu, jak zespołu.
Kim Essendrup
Poznaj naszego gościa
Doświadczenie i wiedza Kim Essendrupa pochodzą z ponad 20 lat zarządzania kluczowymi inicjatywami projektowymi i zespołami odpowiedzialnymi za realizację projektów. Jest dyrektorem generalnym i współzałożycielem RAIDLOG.com, założycielem firmy konsultingowej zajmującej się zarządzaniem projektami, The Kolme Group, oraz współprowadzącym podcast Project Management Happy Hour. Niedawno opublikował również swoją drugą książkę „Kompletny przewodnik po dzienniku RAID”. Kim koncentruje się zawodowo na szkoleniu i mentoringu nowych liderów, aby skutecznie realizowali wymagające inicjatywy o wysokiej wartości. Czerpie przyjemność nie tylko z wyzwań związanych z realizacją projektów, lecz także z wyzwań związanych ze sportami wytrzymałościowymi — ukończył kilka triathlonów Ironman i ultramaratonów

Naszą wizją jest sprawienie, aby oparty na arkuszu kalkulacyjnym dziennik RAID stał się zbędny, ponieważ chcemy zapewnić lepsze rozwiązanie, z którego każdy będzie mógł korzystać.
Kim Essendrup
Materiały z tego odcinka:
- Dołącz do społeczności Digital Project Manager
- Zapisz się do newslettera, aby otrzymywać nasze najnowsze artykuły i podcasty
- Nawiąż kontakt z Kimem na LinkedInie
- Sprawdź RAIDLOG.com
- Sprawdź podcast PM Happy Hour
- Sprawdź książkę Kima: Kompletny przewodnik po dzienniku RAID: jedyne narzędzie potrzebne do prowadzenia dowolnego projektu
Powiązane artykuły i podcasty:
Przeczytaj transkrypcję:
Wypróbowujemy oprogramowanie do transkrypcji naszych podcastów. Wybaczcie wszelkie literówki, ponieważ bot nie zawsze działa w 100% poprawnie.
Galen Low: Znowu gorączkowo przeszukujesz swoją skrzynkę odbiorczą. Tym razem szukasz wiadomości od szefa potwierdzającej decyzję dotyczącą twojego projektu. Jak on się nazywał? Jaka była decyzja? Wszystko stoi w miejscu, dopóki tego nie znajdziesz, więc nastawiasz dzbanek kawy i szukasz dalej. To będzie długa noc.
Dzisiaj będziemy omawiać praktyczne zastosowanie dzienników RAID oraz sposoby włączenia ich do przepływu pracy nad projektem, aby prowadzić rozmowy z interesariuszami, łatwo komunikować status projektu i już nigdy nie spędzać godzin na szukaniu tej wiadomości od szefa.
Cześć wszystkim, dziękuję za dostrojenie się. Nazywam się Galen Low i reprezentuję The Digital Project Manager. Jesteśmy społecznością specjalistów cyfrowych, której celem jest wzajemna pomoc w zdobywaniu umiejętności, pewności siebie i kontaktów, aby zwiększać wartość zarządzania projektami w cyfrowym świecie. Jeśli chcecie dowiedzieć się więcej, odwiedźcie thedigitalprojectmanager.com.
Dzisiaj rozmawiamy o dziennikach RAID i delikatnej sztuce śledzenia ryzyk, działań, problemów oraz decyzji, aby prowadzić projekty do sukcesu.
Moim gościem jest Kim Essendrup, były członek grupy Kolme — organizacji zdecydowanej pomagać firmom w budowaniu podejmowania decyzji opartych na danych w ramach ich procesów. Wielu z was zna go jednak jako jednego z dwóch założycieli i prowadzących bardzo popularny podcast PM Happy Hour.
Witaj, Kim!
Kim Essendrup: Cześć, Galen! Dzięki za zaproszenie.
Galen Low: Dzięki, że jesteś z nami. O rany, to dla mnie chwila spotkania z celebrytą. PM Happy Hour to świetna zabawa. Każdy odcinek, którego słuchałem, był przezabawny.
Tak czy inaczej, zazdroszczę ci podcastu. Uważam, że jest świetny. Jeśli nasi słuchacze go nie znają, koniecznie powinni go sprawdzić. Ma naprawdę dobrą dynamikę. Chciałem zacząć od pytania prawdziwego fana: co sprawiło, że w ogóle zacząłeś prowadzić podcast PM Happy Hour?
Kim Essendrup: Najpierw muszę powiedzieć, że ja również jestem twoim wielkim fanem, więc jesteśmy fanami siebie nawzajem. Dużo szkoliłem menedżerów projektów. Zauważyłem, że wciąż przekazuję te same wskazówki, więc pomyślałem: napiszę o tym na blogu i ludzie będą czytać bloga. Potem odkryłem, że ludzie naprawdę nie lubią czytać dziesięciotysięcznych wpisów o zarządzaniu projektami.
To nie jest zbyt przyjemne. Prowadziłem wtedy także małą firmę typu start-up zajmującą się innym tematem, a konsultant powiedział mi: „Powinieneś zrobić podcast”. Przeszedłem więc cały proces — dowiedziałem się, jak to robić, kupiłem mikrofon — i zacząłem podcast dla tamtego start-upu. Nie odniósł on większego sukcesu, ale dzięki niemu poznałem świat podcastów.
Wciągnęło mnie to. Nauczyłem się, jak wszystko działa, i pomyślałem, że może mógłbym wziąć niektóre wpisy z bloga i uczynić je naprawdę interesującymi. Zastanawiałem się, kogo mógłbym zaprosić do podcastu, aby sprawić, że zarządzanie projektami stanie się ciekawe.
Odpowiedź była oczywista: Kate. Napisałem do niej i zapytałem: „Hej, chcesz zrobić coś szalonego?”. Kate od razu się zgodziła. Od tamtej pory jest coraz ciekawiej.
Galen Low: Uwielbiam to. Macie naprawdę dobrą dynamikę. Prawie czuję się, jakbym słuchał porannej audycji radiowej — naprawdę dobrej porannej audycji. Jest przezabawna wymiana zdań, ale jednocześnie wszystko dotyczy projektów.
Pomyślałem: tak, to coś dla mnie. Jestem wielkim fanem. Jeśli jeszcze tego nie sprawdziliście, PM Happy Hour, czyli Project Management Happy Hour, jest dostępny chyba w niemal każdej aplikacji do podcastów.
Kim Essendrup: We wszystkich, które udało nam się znaleźć.
Galen Low: Właśnie. Świetnie. Dobrze, przejdźmy do tematu.
Dzisiaj zagłębimy się w temat dzienników RAID. Pomyślałem, że warto zacząć od podstaw: czy możesz wyjaśnić naszym słuchaczom, czym według ciebie jest dziennik RAID i dlaczego jest ważny?
Kim Essendrup: Najprościej mówiąc, RAID to akronim od słów: ryzyka, działania, problemy i decyzje. Niektóre organizacje wolą używać założeń i zależności zamiast działań i decyzji, ale możemy o tym porozmawiać później.
Najważniejsze jest to, że dziennik RAID łączy rejestr ryzyk, rejestr działań i wszystkie inne rejestry, które zaleca się prowadzić, szczególnie przy stosowaniu metodyki PMI. Śledzenie tych elementów w jednym arkuszu kalkulacyjnym od dawna jest standardową praktyką. Kiedy zaczynałem zarządzać projektami, dekady temu, było to już rozwiązanie starej szkoły.
Dzienniki RAID istnieją więc od zawsze i są niezastąpionym narzędziem operacyjnym pomagającym menedżerom projektów prowadzić projekty. Z naszych ankiet wynika, że mniej więcej połowa do dwóch trzecich menedżerów projektów korzystała z nich albo o nich słyszała. To naprawdę kluczowe narzędzie, dlatego obecnie zachęcamy do jego stosowania.
Galen Low: Bardzo ciekawe. Byłem jedną z tych osób, które nie zdawały sobie sprawy, że już tego używają. Podczas spotkania rozmawiałem z ludźmi o naszym dzienniku RAID. Nauczono mnie modelu: ryzyka, założenia, problemy i zależności. Ktoś podniósł rękę i zapytał: „Czy na pewno nie chodzi o inny model?”. Zaczęliśmy więc rozmawiać o tym, który wariant preferujemy i dlaczego.
Kim Essendrup: Lubię działania i decyzje. Jeśli pomyślisz o założeniu, jest to założenie planistyczne: realizuję projekt, więc jakie założenia przyjmujemy dotyczące zakresu albo planu? Założenie jest czymś, co stanowi dane wejściowe na początku projektu.
Założenie staje się ryzykiem, jeśli okaże się nieprawdziwe. Dlatego dla mnie założenia naturalnie trafiają do kategorii ryzyk. To samo dotyczy zależności. Jeśli w projekcie występuje zależność zewnętrzna, jest ona ryzykiem albo powinna znaleźć się w harmonogramie, ponieważ wiąże się z terminami, poprzednikami i następnikami.
Zwykle trafia więc do jednego z tych dwóch miejsc. Czasem zależności zewnętrzne są tak poważne, że zasługują na osobną kartę — wtedy mamy RAIDD. Uważam jednak, że skupienie się na elementach działań i decyzji jest bardziej operacyjne. To właśnie nimi trzeba zarządzać w trakcie realizacji projektu, dzięki czemu dziennik RAID staje się narzędziem używanym codziennie do organizowania pracy.
Galen Low: Podoba mi się to. Chodzi o popychanie projektu do przodu i całkowicie się z tobą zgadzam. W moich projektach wszystkie założenia i zależności wyglądały dla mnie jak ryzyka. Zastanawiałem się, czy robię to właściwie.
Kim Essendrup: Najlepszym sposobem rozpoczęcia rejestru ryzyk może być właśnie wypisanie wszystkich założeń i zależności, na których od początku opiera się cały plan.
Galen Low: A kiedy któreś z tych założeń unieważnisz albo potwierdzisz, możesz je usunąć. Podoba mi się to. Rozmawialiśmy o znaczeniu dziennika RAID i szczególnie doceniam część dotyczącą decyzji.
Wszystko jest w jednym miejscu, zamiast w ośmiu różnych dokumentach, które trzeba przeglądać i aktualizować, a których — szczerze mówiąc — nikt później nie sprawdza.
Kim Essendrup: Inaczej musisz przeszukiwać Outlooka i zastanawiać się: „Gdzie jest ta wiadomość? Wiem, że gdzieś tu była”.
Galen Low: Jestem królem wyszukiwania w Outlooku, bo jestem też królem całkowitego nieorganizowania skrzynki odbiorczej. Ale to ma sens. Wspominaliśmy wcześniej, że dziennik RAID może uchronić projekt przed katastrofalnymi scenariuszami. Nie chcę brzmieć przesadnie dramatycznie, ale naprawdę pomaga utrzymać projekt na właściwym torze. Jak funkcjonalnie wykorzystałbyś dziennik RAID do tego celu?
Kim Essendrup: Lubię myśleć o nim jako o narzędziu do prowadzenia projektu albo jego ratowania. Część dotycząca prowadzenia jest bardzo ważna, bo jeśli nie korzystasz z dziennika RAID, prawdopodobnie w końcu będziesz musiał ratować własny projekt.
Jeśli spojrzysz na narzędzia wykorzystywane do zarządzania projektami, masz plan albo backlog — wszystkie elementy, które bezpośrednio przyczyniają się do powstania rezultatów. To świetnie, bo właśnie tym się zajmujemy. Jednak dziennik RAID odpowiada na pytanie: jak dopilnować, żeby te rzeczy zostały wykonane prawidłowo?
Dziennik RAID nie jest planem. Jest sposobem na dopilnowanie realizacji planu. A który projekt przebiega idealnie? Jeśli masz taki projekt, jesteś bardzo szczęśliwą osobą. Problemy i wyzwania się pojawią. Rzeczy mogą pójść źle i rzeczywiście często idą źle.
Czego używasz wtedy do zarządzania nimi? Nie harmonogramu, lecz dziennika RAID. Pomaga on określić, co może pójść źle, jakie działania trzeba śledzić, jakie problemy się pojawiły i jak najszybciej je rozwiązać, aby projekt pozostał na właściwym torze.
Pomaga także przewidzieć decyzje, które trzeba będzie podjąć, wdrożyć albo na które trzeba będzie zareagować, mimo że nie zostały uwzględnione na początku projektu. Wszystko to pozwala utrzymać plan i skutecznie go zrealizować.
Kiedy nie myślisz o ryzykach, nie planujesz decyzji i nie dokumentujesz ich, plan zaczyna się rozpadać. Właśnie na tym polega magia dziennika RAID: jest niezwykle prosty, ale pomaga pilnować podstaw, a to właśnie zaniedbanie podstaw najczęściej prowadzi do problemów w projektach.
Galen Low: Wspomniałeś o szkoleniu i mentoringu. Czy masz przykład sytuacji, w której projekt wymykał się spod kontroli, a rozwiązaniem okazało się coś tak podstawowego jak dziennik RAID?
Kim Essendrup: Tak. Kilka lat temu przejąłem PMO z siedzibą w Europie. Było to świetne, bo firma finansowała moje podróże do Europy. Nadal mieszkałem w okolicach Phoenix, więc mniej więcej raz w miesiącu leciałem do Europy.
Kiedy przejmujesz rolę menedżera PMO, stajesz się również osobą odpowiedzialną za wszystkie pożary. Pewnego piątku zadzwoniono do mnie w sprawie projektu. A kiedy w piątek dostajesz telefon dotyczący projektu, nigdy nie jest to dobry telefon.
Powiedziano mi, że projekt jest w tak złym stanie, iż klient grozi naliczeniem opłat za problemy, a następnie rozwiązaniem umowy. W poniedziałek rano nie byłem już w Phoenix, tylko w regionie Midlands w Wielkiej Brytanii. Musiałem przejąć kontrolę nad projektem.
Klient był wściekły. Spotkałem się z całym zespołem i wysłuchałem wszystkich problemów. Pomyślałem: „To brzmi uzasadnione. Też byłbym zdenerwowany”. Kiedy klient skończył, spojrzałem na swój zespół i zapytałem: „Czy wy macie jakieś problemy?”.
Wszyscy od razu zaczęli mówić: klient czegoś nie dostarczył, wy nie dostarczyliście nam czegoś, nie mogliśmy odnieść sukcesu, bo nie otrzymaliśmy wszystkich potrzebnych elementów. Klient odpowiadał: „Nie powiedzieliście mi o tym”.
Poczekałem, aż zrobi się cicho, i zapytałem: „Czy możecie pokazać mi swój dziennik RAID?”. Zapadła cisza. Nie wiedziałem, czy nie znają tego pojęcia i wstydzą się zapytać, czy też zdali sobie sprawę, że w ogóle nie mają dziennika RAID.
Powiedziałem: „W takim razie go utwórzmy”. Otworzyłem laptopa i przygotowałem dziennik RAID. Zaczęliśmy rejestrować wszystkie problemy. Wyświetliłem go na projektorze i wpisywałem wszystko na bieżąco. Dzięki temu mogłem potwierdzić każdą obawę i każdy problem klienta. Klient widział, że jego uwagi są zapisywane, więc poczuł, że wreszcie ktoś go słucha.
Potem zapytałem swój zespół o ich problemy. Były podobne. Wszystko udokumentowaliśmy, a następnie zaczęliśmy analizować zależności: czego oczekiwaliście od klienta, czego klient oczekiwał od was i czego żadna ze stron wcześniej nie zakomunikowała.
Najciekawsze było to, że w ciągu popołudnia przestaliśmy krzyczeć na siebie. Stopniowo odwróciliśmy krzesła i wszyscy zaczęliśmy patrzeć na projektor. Nie walczyliśmy już ze sobą — walczyliśmy z problemami.
Ta historia pokazuje, że dziennik RAID jest świetną platformą do uzgadniania stanowisk, zapewniania wzajemnego zrozumienia oraz tworzenia wspólnej listy problemów, nad którymi można pracować razem. Dzięki niemu można naprawdę odwrócić sytuację albo przynajmniej odzyskać nad nią kontrolę.
Galen Low: Uwielbiam tę historię, a także opis języka ciała. Zamiast konfrontacji twarzą w twarz wszyscy zaczęli przechylać się w stronę współpracy.
W technikach, procesach i metodach zarządzania projektami często zapominamy, że wszystko to ma przede wszystkim ułatwiać komunikację i współpracę. Wspomniałeś wcześniej o zależnościach. Mogą działać w obie strony.
Jeśli nie zrobisz tego, my nie możemy zrobić tamtego. Ale równie dobrze można powiedzieć: zrób to, abyśmy mogli zrobić tamto. Jeśli ludzie nie widzą tych zależności, trudno im zrozumieć, dlaczego muszą coś zrobić. Mogą odłożyć zadanie, nikt nic nie powie, a projekt nagle znajdzie się bardzo daleko od miejsca, w którym powinien być.
Czasami chodzi po prostu o ślad pozwalający kontrolować rzeczy, które musimy śledzić. Wiem, że może się to wydawać nadmierną dokumentacją, ale trudno pamiętać o setkach elementów, którymi trzeba zarządzać w trakcie projektu.
Kim Essendrup: To prawda. Można rozmawiać na spotkaniu o decyzji, zależności albo ryzyku, ale kiedy zapiszesz to w dokumencie — szczególnie współdzielonym podczas spotkania online albo wyświetlonym na projektorze — i dodasz nazwiska, nagle staje się to konkretną sprawą.
Jeśli przy elemencie widnieje moje nazwisko, zaczynam zwracać na niego uwagę. Dziennik RAID jest więc świetnym narzędziem komunikacji i odpowiedzialności. Kiedy przejmujesz projekt w nowym środowisku, zdobądź dziennik RAID, jeśli go nie ma.
Jedno z moich ulubionych powiedzeń brzmi: jeśli pracujesz przy projekcie związanym z administracją publiczną, traktuj dziennik RAID tak, jakby mógł zostać objęty wezwaniem sądowym, bo pewnego dnia rzeczywiście może się tak stać.
Galen Low: Zdecydowanie. Pracowałem przy projektach, które były kontrolowane z różnych powodów. Brak właściwej dokumentacji dostępnej od ręki może być ogromnym problemem. Nawet jeśli dane gdzieś istnieją, ich wydobycie staje się osobnym projektem. Czysty ślad dokumentujący wydarzenia, ryzyka i sposób, w jaki o nich rozmawialiśmy, jest niezwykle pomocny.
Kim Essendrup: Wyobrażam sobie, że kontrola obudziła cię rano, gdy dowiedziałeś się, że odbywa się tego dnia.
Galen Low: O tak. „Wszyscy otwierają rejestr czasu!”.
Wspomniałeś o praktycznym wykorzystaniu dziennika RAID. Wiele osób pomyśli: „To dużo pracy”. Jak wygląda utrzymywanie go jako źródła prawdy po osiągnięciu porozumienia?
Kim Essendrup: Menedżer projektu musi naprawdę żyć tym narzędziem. Możesz spojrzeć na nie i powiedzieć: „To dużo dodatkowego śledzenia i zarządzania”. I szczerze mówiąc, tak właśnie jest.
Możesz nie prowadzić dziennika RAID i liczyć na szczęście, tak jak możesz zamknąć oczy, dodać gazu na żółtym świetle i mieć nadzieję, że nie spowodujesz wypadku. Czasami się uda. Jednak przy każdym nieudanym projekcie, który musiałem ratować, odpowiedź na pytanie „Czy mogę zobaczyć wasz dziennik RAID?” brzmiała „Nie”.
Kiedy mój projekt zaczyna schodzić z toru, uświadamiam sobie, że nie aktualizowałem dziennika RAID albo w ogóle go nie utworzyłem. Po pewnym czasie przechodzenia przez takie problemy rozumiesz, że trzeba to robić.
Statystyki różnią się zależnie od roku i badania, ale zwykle około 70–80% projektów nie osiąga kluczowych celów, a mniej więcej 19–20% kończy się całkowitym niepowodzeniem. Wszyscy to wiemy, bo jesteśmy menedżerami projektów. Problemy się pojawiają, terminy się przesuwają, a koszty rosną.
Skoro wiesz, że problem prawdopodobnie pojawi się w twoim projekcie, czy nie szkodzisz sobie i projektowi, jeśli nie poświęcisz trochę czasu na jego uniknięcie? To nasza praca. Jesteśmy menedżerami projektów, bohaterami, którzy doprowadzają te rzeczy do końca. Dziennik RAID jest naszym narzędziem superbohatera pomagającym utrzymać projekt na właściwym torze.
Galen Low: Statystyki są zabawne, bo dają nam wymówkę, by nie reagować proaktywnie. Możemy zamknąć oczy i przejechać przez żółte światło albo całkowicie się sparaliżować, myśląc, że projekt na pewno się nie uda.
W rzeczywistości chodzi o przejęcie sterów. Masz plan — mapę z narysowaną linią — ale dziennik RAID jest kierownicą, dzięki której faktycznie prowadzisz projekt i nie pozwalasz mu zjechać do rowu.
Można na nim współpracować w sali konferencyjnej, a jego zawartość jest przejrzysta. To prowadzi mnie do pytania o narzędzia. Mój dziennik RAID zawsze był arkuszem kalkulacyjnym, a wiele osób mówi: „Nie potrzebuję kolejnego arkusza”. Jakie narzędzia można wykorzystać zamiast programu Excel albo Arkuszy Google?
Kim Essendrup: Na rynku jest oczywiście wiele narzędzi do zarządzania projektami. Grupa Kolme, w ramach naszej firmy konsultingowej zajmującej się zarządzaniem portfelem i projektami, wdrożyła narzędzia do zarządzania projektami w ponad 650 organizacjach.
Zauważyliśmy, że dostępne narzędzia nie radzą sobie dobrze z dziennikami RAID. Wiele z nich nie oferuje niczego podobnego. Niektóre są przeznaczone do zarządzania zadaniami, inne do planowania zasobów przedsiębiorstwa, prognozowania albo zarządzania zasobami.
Inne narzędzia upraszczają wszystko do poziomu zespołu: zadania, tablice Kanban i śledzenie tempa pracy. Problem polega na tym, że menedżer projektu zostaje pominięty.
Próbowaliśmy przekonać naszych partnerów programowych do stworzenia dziennika RAID. Odpowiedzieli: „Dzienników RAID nie ma w kwadrancie Gartnera, więc nie”. W końcu stwierdziliśmy, że stworzymy własne rozwiązanie, ponieważ mieliśmy dość arkuszy kalkulacyjnych.
Arkusze działają, ale mają ograniczenia. Udostępnianie ich, śledzenie wersji i współpraca mogą być trudne. Jeśli chcesz śledzić wszystkie wydarzenia związane z konkretnym ryzykiem, arkusz szybko staje się nieporęczny.
Stworzyliśmy więc dziennik RAID w modelu SaaS: raidlog.com. Dopiero zaczynamy, ale naszą misją jest stworzenie najlepszego narzędzia pomagającego menedżerom projektów odnosić sukcesy.
Galen Low: To fascynujące, że oprogramowanie rozwija się w dwóch kierunkach: widok przedsiębiorstwa oraz prosty zestaw narzędzi dla zespołu. A menedżer projektu zostaje gdzieś pośrodku.
Czy możesz opowiedzieć, jak działa wasze rozwiązanie? Czy integruje się z innym oprogramowaniem, czy działa samodzielnie?
Kim Essendrup: To samodzielne oprogramowanie. Oferuje dziennik RAID z interfejsem przypominającym arkusz kalkulacyjny, więc osoby przyzwyczajone do dzienników RAID nie tracą czasu na zbędne klikanie.
Mamy również bardziej wizualny interfejs. Możesz otworzyć szczegółowy widok problemu albo decyzji i przedstawić go w sposób odpowiedni do rozmowy biznesowej z interesariuszami lub sponsorem.
Dodajemy też funkcje ułatwiające pracę. W module decyzji można na przykład korzystać z wykresu T, aby porównać korzyści, wady i opcje. Planujemy również mapy cieplne, analizę Monte Carlo i zaawansowane funkcje analityczne. W przyszłości pojawią się także funkcje oparte na sztucznej inteligencji.
Dziennik RAID nie jest jedynym narzędziem do zarządzania projektem, dlatego budujemy integracje. Mamy już integrację z Planview AdaptiveWork, planujemy integrację z Jirą i chcemy współpracować z jak największą liczbą narzędzi. Jesteśmy także połączeni z Zapierem.
Naszą wizją jest sprawienie, aby dziennik RAID oparty na arkuszu kalkulacyjnym stał się zbędny. Chcemy oferować łatwą w użyciu, podstawową darmową wersję oraz zaawansowane funkcje dla użytkowników o większych wymaganiach.
Galen Low: Najbardziej podoba mi się to, że wykracza to poza zwykły dziennik. Dziennik kojarzy się z zapisaniem czegoś, co się wydarzyło albo może się wydarzyć. Wy natomiast oferujecie analizę i wykres T.
To bardziej zarządzanie RAID niż sam dziennik RAID.
Kim Essendrup: To jeszcze więcej. Nazywamy to raidlog.com, ponieważ dziennik RAID jest podstawowym narzędziem operacyjnym, ale same dzienniki RAID niewiele się zmieniły przez ostatnie dekady.
Chcemy dać menedżerom projektów narzędzia potrzebne do prowadzenia projektu. Nie zatrzymamy się na elementach RAID. Dodamy wnioski wyciągnięte z doświadczeń, protokoły spotkań i możliwość aktualizowania dziennika RAID podczas sporządzania protokołu.
Naszym celem jest stworzenie podstawowego narzędzia, które będzie można podłączyć do dowolnego narzędzia planistycznego, harmonogramu albo backlogu. Chcemy zmniejszyć ból związany z zarządzaniem projektami.
Galen Low: Podoba mi się, że rozwiązanie integruje się z innymi narzędziami i pozostaje otwarte. To warstwa współpracy, której czasem brakuje na poziomie przedsiębiorstwa i na poziomie codziennej pracy zespołu.
Kim Essendrup: Chcemy być czymś więcej niż narzędziem. Dzięki szkoleniom i mentoringowi chcemy wbudować w aplikację wiedzę i edukację. Jeśli dopiero poznajesz zarządzanie ryzykiem, narzędzie powinno intuicyjnie wyjaśniać, czym są prawdopodobieństwo i wpływ.
Chcemy oferować pomoc kontekstową, a także bardziej zaawansowane funkcje, takie jak analiza Monte Carlo i oczekiwana wartość pieniężna. Wprowadzisz dane, klikniesz przycisk i otrzymasz informację, jaką rezerwę powinieneś zaplanować.
Galen Low: Zbudowałem kilka rejestrów ryzyk od podstaw i wymagało to wielu formuł. Chciałbym nie musieć tego robić.
Kim Essendrup: W pewnym momencie dochodzisz do wniosku: „To wystarczy. Mam projekt do realizacji i nie mogę wiecznie zajmować się arkuszem”.
Galen Low: Po prostu wpiszmy 15% rezerwy i działajmy.
Mam ostatnie pytanie. Czy RAID jest przeznaczony wyłącznie dla menedżerów projektów? A jeśli nie, jak można wykorzystać go do budowania kultury zespołowej, odpowiedzialności za ryzyka, działania, problemy i zależności?
Kim Essendrup: Początki RAID rzeczywiście wiążą się z tradycyjnym zarządzaniem projektami, ale chodzi przede wszystkim o realizację planu. Plan nie musi dotyczyć projektu w klasycznym, kaskadowym rozumieniu.
Może dotyczyć produktu i pracy właściciela produktu w środowisku zwinnym. Jak zarządzać ryzykami produktu? Jakie decyzje trzeba podjąć? Jak je udokumentować i śledzić?
Jeśli jesteś mistrzem Scruma i prowadzisz zespół pracujący zwinnie, dziennik RAID pomaga dbać o zespół i zapewnić mu skuteczność. Nie chodzi wyłącznie o produkt, lecz o to, jak pomóc zespołowi odnieść sukces.
Jeśli jestem menedżerem PMO i chcę mentorować menedżerów projektów, mogę powiedzieć: „Pokaż mi swój dziennik RAID”. Widzę wtedy, jak zarządzają projektami, i mogę zaoferować wskazówki.
Z perspektywy menedżera projektu, który zarządza w górę organizacji, mogę filtrować dziennik RAID i pokazać sponsorom trzy lub cztery najważniejsze sprawy. To pomaga zaangażować właściwe osoby i pokazać, że panujesz nad sytuacją.
Dziennik RAID jest więc czymś więcej niż narzędziem operacyjnym projektu. To sposób pracy i współpracy. Pomaga organizować nie tylko własną pracę, lecz także pracę zespołu, utrzymywać jego motywację oraz ułatwiać komunikację.
Galen Low: Podoba mi się to. Niemal każdy ma do czynienia z ryzykami, działaniami, problemami albo decyzjami, niezależnie od rodzaju pracy.
To może być dowolne narzędzie współpracy. Ważne jest filtrowanie informacji. Menedżerowie projektów potrafią radzić sobie z ogromną ilością danych, ale interesariuszom nie można pokazywać wszystkiego naraz. Trzeba zawęzić informacje do formatu, który pozwala przeprowadzić rozmowę biznesową.
Można wykorzystywać dziennik RAID do zarządzania zespołem menedżerów projektów, oczekiwaniami przełożonych i wieloma innymi sprawami. Jeśli jest prowadzony rzetelnie, może znacząco usprawnić pracę.
Kim Essendrup: RAID to dopiero początek. Można rozszerzyć go o wnioski wyciągnięte z doświadczeń. Problemy są trudne, ale jeszcze trudniej jest mierzyć się wciąż z tym samym problemem. Dodanie wniosków pomaga rozwiązywać problemy i poprawiać pracę przy następnym projekcie.
Galen Low: Podoba mi się to i jestem ciekawy funkcji związanych ze sztuczną inteligencją. Gdzie można dowiedzieć się więcej o RAID?
Kim Essendrup: Na stronie raidlog.com. Zachęcam do wypróbowania produktu i przekazywania opinii, ponieważ chcemy stworzyć świetne narzędzie dla menedżerów projektów. Można również skontaktować się ze mną na LinkedIn.
Jeśli dopiero poznajesz dzienniki RAID, napisałem książkę, ponieważ — co zaskakujące — nie było książki na ten temat. W Amazonie wyszukaj „Ultimate Guide to RAID Log”. To prawdopodobnie jedyna książka poświęcona dziennikom RAID.
Galen Low: To niesamowite. Nie miałem pojęcia. Zamieszczę wszystkie te linki w informacjach do odcinka. Sam również to sprawdzę, bo temat jest bardzo interesujący.
Kim Essendrup: Świetnie.
Galen Low: Kim, dziękuję, że byłeś dziś z nami. Bardzo doceniam twoje spostrzeżenia. Uwielbiam zagłębiać się w tematy związane z zarządzaniem projektami, szczególnie w takie elementy tradycji zarządzania projektami jak dzienniki RAID i rejestry ryzyk. Na początku mogą wydawać się skomplikowane, ale po bliższym przyjrzeniu okazują się podstawowymi i rozsądnymi narzędziami.
Kim Essendrup: Dziękuję za zaproszenie, Galen.
Galen Low: Dobrze, oto najważniejsze informacje. Jeśli chcecie dołączyć do rozmowy z ponad tysiącem osób zajmujących się zarządzaniem projektami, dołączcie do naszej społeczności. Odwiedźcie thedigitalprojectmanager.com/membership, aby dowiedzieć się więcej.
Jeśli podobał wam się dzisiejszy odcinek, zasubskrybujcie podcast i pozostańcie z nami na thedigitalprojectmanager.com. Do usłyszenia następnym razem. Dziękuję za słuchanie.
