Alternatywa dla Asany w zarządzaniu ryzykiem projektu: rejestr, który nie jest listą

Rejestr ryzyk, który jest listą zadań

Asana ma gotowy szablon rejestru ryzyk i szablon macierzy. Ich logika jest rozsądna: opisujesz zagrożenie, oceniasz prawdopodobieństwo i wpływ, wskazujesz właściciela, dopisujesz plan reakcji. Przy jednym projekcie i kilkunastu ryzykach to wystarcza. Jest przy tym lepsze od arkusza, bo rejestr leży tam, gdzie toczy się praca. Szerszy obraz daje porównanie FlexiProject i Asany funkcja po funkcji.

Ograniczenie jest w konstrukcji. Ryzyko nie jest tu osobnym obiektem, tylko zadaniem z dodatkowymi polami. Wszystko, co wynika z tego, że ryzyko to nie praca do wykonania, trzeba wtedy zorganizować poza narzędziem.

Co daje szablon, a czego nie da

Szablon porządkuje informacje i to jest jego realna wartość. Nie daje natomiast trzech rzeczy.

Ryzyko nie może wskazywać na inne zadanie, bo samo jest zadaniem. Nie zapiszesz więc, że dane zagrożenie dotyczy konkretnej dostawy w harmonogramie. Ryzyk nie da się też zestawiać między projektami, bo pola własne działają tylko wewnątrz jednego projektu. I nie ma poziomu wyższego niż projekt. Każdy rejestr jest kompletny sam w sobie i ślepy na to, co obok. Trzy zespoły mogą prowadzić to samo ryzyko dostawcy i żaden się o tym nie dowie.

Trzy objawy, że rejestr przestał działać

Rejestr aktualizowany tuż przed komitetem sterującym, a nie na bieżąco. Jeśli aktualizacja jest osobną czynnością, robi się ją wtedy, gdy ktoś o nią poprosi. Zwykle za późno, żeby coś zmienić.

Ryzyka przepisywane ręcznie do karty projektu i do raportu miesięcznego. Ta praca nie tworzy nowej informacji, a w firmie krążą trzy wersje tej samej listy.

Pytanie „czy ktoś już się tym zajmuje” bez adresata. Bez poziomu, na którym spotykają się ryzyka z różnych projektów, każde rozwiązuje się od nowa. Przyglądamy się też temu, czego szukać, gdy rozważasz aplikacje podobne do Asany.

Czego wymagać od rejestru ryzyk

Różnica między listą a modułem sprowadza się do siedmiu rzeczy. Każdą z nich albo obsługuje system, albo wykonuje ręcznie człowiek.

Razem opisują, co musi dawać system do zarządzania ryzykiem. Dalej omawiam te wymagania po kolei i pokazuję, jak rozwiązuje je FlexiProject.

Macierz w wymiarach, których używacie

Konfiguracja macierzy ryzyka wygląda na drobiazg. To jedna z najczęstszych przyczyn, dla których moduł ryzyk w systemie PPM stoi pusty. Firma przez lata wypracowała macierz trzy na trzy, a wdrażany system ma zaszytą macierz pięć na pięć. Nikt nie będzie uczył trzydziestu kierowników projektów nowej skali, bo tak zdecydował dostawca. Skutek jest przewidywalny: moduł zostaje nieużywany, a ryzyko wraca na slajd.

We FlexiProject wymiary macierzy ustawia się na etapie wdrożenia, bez programowania. Firma wnosi do systemu skalę, którą jej ludzie znają, razem z przyzwyczajeniem, że określona ocena wymaga określonej reakcji. Wypracowany standard przetrwa więc zmianę narzędzia.

Karta ryzyka zamiast wiersza w tabeli

W systemie do zarządzania projektami FlexiProject rejestr ryzyk jest osobnym modułem projektu. Każde ryzyko ma nazwę, status, właściciela, powiązanie z zadaniem z harmonogramu, kategorię, wpływ, prawdopodobieństwo i datę identyfikacji. Wpływ na harmonogram i wpływ na budżet ocenia się osobno. To ma praktyczne znaczenie: ryzyko opóźniające odbiór o miesiąc i ryzyko podnoszące koszt o sto tysięcy złotych wymagają innej reakcji. Wspólna ocena „wysoki wpływ” tego nie rozróżni.

Nad rejestrem stoi karta ryzyka. Poza danymi z rejestru zawiera załączniki, plan zarządzania tym zagrożeniem i komunikator, w którym zespół prowadzi rozmowę o tym konkretnym ryzyku. Wygląda to drobno, ale rozwiązuje realny problem. Dyskusja w kanale zespołu ginie w ciągu dwóch dni. Rozmowa zapisana przy ryzyku zostaje z nim na stałe. Kiedy pół roku później ktoś pyta o powody takiej reakcji, odpowiedź leży w tym samym miejscu co decyzja.

Ryzyko przypięte do zadania w harmonogramie

Rejestry ryzyk są zwykle płaskie. Traktują tak samo ryzyko dotyczące całego projektu, na przykład braku zasobów, i ryzyko dotyczące jednego zadania, na przykład dostawy od podwykonawcy. To dwie różne sytuacje i zarządza się nimi inaczej.

We FlexiProject każde ryzyko można powiązać z konkretnym zadaniem w module harmonogramu. Ryzyko dostawcy przypisujesz do zadania zależnego od dostawy, ryzyko regulacyjne do zadania zatwierdzenia. Od tej chwili harmonogram niesie informację o zagrożeniach. W linii zadania pojawia się trójkąt z wykrzyknikiem, a obok niego kółko: czerwone przy ryzyku aktywnym, szare przy nieaktywnym. Kierownik projektu widzi miejsca wymagające uwagi bez otwierania rejestru.

Najwięcej daje to przy zmianie planu. Kiedy harmonogram się przesuwa, od razu wiadomo, które ryzyka stały się pilniejsze. Dotyczą zadań, które zbliżyły się do terminu granicznego albo weszły na ścieżkę krytyczną. W płaskim rejestrze ta informacja też jest, ale trzeba ją wyprowadzić samodzielnie, porównując dwie listy. Dlatego zwykle nikt tego nie robi. Odrębnie tłumaczymy, jak zbudować harmonogram projektu, który system utrzymuje sam.

Ryzyko jako wiedza organizacji, nie jednego projektu

W większości firm sposób, w jaki zespoły identyfikują i oceniają ryzyko projektowe, sprowadza się do spotkania na starcie, gdzie ktoś wymyśla, co może pójść nie tak. Metoda jest zawodna. Ludzie nie doszacowują zagrożeń, z którymi wcześniej się nie zetknęli. Firma jako całość zwykle już je widziała, tylko przy innym projekcie.

Szablony z listą typowych ryzyk

Listę potencjalnych ryzyk dla danego typu projektu można wbudować w szablon. Zespół uruchamiający wdrożenie u klienta, projekt badawczy czy inwestycję zaczyna od gotowej bazy, którą dostosowuje do swojego przypadku. Zmienia to charakter spotkania. Zamiast wymyślać zagrożenia, zespół przegląda znane i decyduje, które go dotyczą. Jest to szybsze i skuteczniejsze, zwłaszcza w mniej doświadczonych zespołach.

Karta zamknięcia i raporty ryzyk

Druga strona tego mechanizmu to zapisywanie tego, co się rzeczywiście wydarzyło. W karcie zamknięcia projektu można wpisać ryzyka, które wystąpiły, i sposoby ich rozwiązania. Zespoły planujące kolejne przedsięwzięcia mają dostęp do historycznych kart zamknięcia.

Trzeci element to raporty. W module raportów zbudujesz zestawienie ryzyk dla projektów z jednej kategorii albo z jednego obszaru organizacyjnego. Nowy zespół dostaje konkretną odpowiedź: to są zagrożenia, które występowały w podobnych projektach. Te trzy mechanizmy razem sprawiają, że zarządzanie ryzykiem przestaje zależeć od kompetencji jednego kierownika.

Kategorie ryzyk i widok dla działów

Ryzyko rzadko interesuje wyłącznie kierownika projektu. Dział prawny chce wiedzieć, jakie zobowiązania i spory kryją się w portfelu. Produkcja pyta o wyzwania technologiczne, zakupy o zagrożenia po stronie dostawców. Przy rejestrze zamkniętym w projekcie nikt z nich nie ma jak zadać swojego pytania.

W ustawieniach FlexiProject definiuje się własną listę kategorii ryzyk, dopasowaną do podziału odpowiedzialności w firmie. Wtedy struktura podziału ryzyka przestaje być diagramem, a staje się czymś, po czym system potrafi filtrować. Na tej podstawie powstają raporty przekrojowe. Dział prawny widzi ryzyka prawne we wszystkich projektach, produkcja swoje, zakupy swoje. Ryzyko przestaje być prywatną sprawą kierownika projektu. Osobno rozkładamy na czynniki, czym jest realna kontrola budżetu projektu.

Poziom portfela, czyli koniec z trzema razami tym samym

Przy kilkudziesięciu projektach część zagrożeń powtarza się z natury rzeczy. Ten sam dostawca, ta sama zmiana przepisów, ta sama niedojrzała technologia. Jeśli rejestry są zamknięte w projektach, każdy kierownik prowadzi własną wersję takiego ryzyka i dochodzi do trochę innych wniosków.

Oprogramowanie do zarządzania portfelem projektów rozwiązuje to inaczej. Każdy portfel we FlexiProject ma osobną zakładkę ryzyk. Zbiera ona zagrożenia ze wszystkich projektów portfela. Koordynator widzi powtarzalność i może rozwiązać ryzyko centralnie, korzystając z całej wiedzy, a nie z jednej perspektywy. Trzykrotny wysiłek zamienia się w jednego właściciela i jedną reakcję. Znika też sytuacja, w której trzy projekty stosują trzy różne strategie wobec tego samego dostawcy. Osobno opisaliśmy, czym musi być alternatywa dla Asany dla PMO.

Koniec przepisywania: karta projektu i raport statusowy

Najbardziej odczuwalna oszczędność dotyczy przepisywania, nie analizy. W wielu firmach procedura wymaga, żeby najistotniejsze ryzyka trafiły do karty projektu, a raz w miesiącu do raportu dla zarządu. Przy osobnym rejestrze ktoś przenosi te same wpisy w dwa miejsca i sprawdza, czy wersje się zgadzają.

We FlexiProject moduł karty projektu pobiera ryzyka z rejestru automatycznie. Oba dokumenty są spójne z założenia, a nie dzięki czyjejś staranności. Tak samo działa cykliczne raportowanie statusów. Jeśli raport zawiera sekcję ryzyk, uzupełnia się ona z rejestru, a kierownikowi zostaje komentarz o tym, jak tymi zagrożeniami zarządza. Znika czynność, która nie tworzyła nowej informacji, a zabierała czas w najgorszym tygodniu miesiąca.

Kiedy wystarczy szablon

Prowadzisz jeden projekt, sam nim zarządzasz, masz kilkanaście ryzyk i nikt nie wymaga formalnego raportowania? Szablon rejestru w narzędziu zadaniowym wystarczy. Osobny moduł doda formalności, a nie doda kontroli, bo opisane wyżej problemy pojawiają się przy większej skali. Jeśli szukasz szerszego przeglądu, osobno porównaliśmy najlepsze systemy do zarządzania ryzykiem.

Sygnały, że ta skala nadeszła, są konkretne. Pojawia się drugi i trzeci projekt, a ryzyka trzeba zestawiać między nimi. Ktoś spoza projektu pyta o zagrożenia w określonym przekroju. Procedura wymaga ryzyk w karcie i w raporcie. Od tego momentu lista z polami własnymi kosztuje więcej pracy, niż oszczędza.

Jak sprawdzić to na własnym rejestrze w dwa tygodnie

Porównania funkcji niewiele rozstrzygają, bo strona każdego dostawcy odpowiada twierdząco na wszystko. Więcej powie test na własnych danych. Weź rejestr jednego trwającego projektu i przenieś go w całości, razem z waszą skalą oceny. Ten pierwszy krok pokaże, czy macierz mieści się w narzędziu bez zmiany przyzwyczajeń zespołu.

Potem cztery próby. Powiąż trzy ryzyka z zadaniami w harmonogramie i sprawdź, czy widać je na Gantcie. Przesuń jedno z tych zadań o dwa tygodnie i zobacz, czy obraz zagrożeń się zmienia. Zbuduj raport ryzyk dla jednej kategorii, na przykład dostawców, obejmujący kilka projektów. Otwórz zakładkę ryzyk portfela i sprawdź, czy któreś zagrożenie powtarza się w kilku miejscach. Ta ostatnia próba zwykle sama wystarcza za uzasadnienie zmiany.

Najczęściej zadawane pytania

Czy Asana ma rejestr ryzyk?

Asana udostępnia szablon rejestru ryzyk i szablon macierzy. Tworzą one listę z polami takimi jak prawdopodobieństwo, wpływ, właściciel i plan reakcji. Nie jest to osobny moduł, tylko projekt zbudowany z zadań. Dlatego ryzyka nie powiążesz z zadaniem w harmonogramie, nie zestawisz z innymi projektami i nie zobaczysz na poziomie portfela.

Czym różni się rejestr ryzyk od listy zadań z polami własnymi?

Tym samym, czym ryzyko różni się od pracy do wykonania. Rejestr traktuje ryzyko jako osobny obiekt z własnym cyklem życia, oceną, właścicielem, planem reakcji i powiązaniami z harmonogramem oraz budżetem. Lista zadań pozwala te informacje zapisać, ale nie pozwala z nich korzystać poza jednym projektem.

Co daje powiązanie ryzyka z zadaniem w harmonogramie?

Pokazuje, w którym miejscu planu leży zagrożenie. We FlexiProject zadanie z powiązanym ryzykiem ma na wykresie Gantta ikonę ostrzegawczą, a kolor obok informuje, czy ryzyko jest aktywne. Po każdej zmianie harmonogramu od razu widać, które zagrożenia stały się pilniejsze.

Czy można zachować własną macierz ryzyka?

Tak. Wymiary macierzy ustawia się na etapie wdrożenia, więc firma pracująca na skali trzy na trzy nie musi przechodzić na pięć na pięć. To jeden z ważniejszych warunków tego, żeby moduł ryzyk był używany, a nie omijany.

Jak zacząć, jeśli rejestr ryzyk prowadzimy dziś w Excelu?

Od przeniesienia jednego trwającego projektu razem z obecną skalą oceny i kategoriami. Arkusz zwykle zawiera już wszystkie potrzebne informacje. Brakuje mu powiązań: z zadaniami, z innymi projektami i z dokumentami, które i tak uzupełniacie ręcznie. Te powiązania są powodem zmiany, a nie sam fakt prowadzenia rejestru.

Alternatywy dla Asany w zarządzaniu ryzykiem projektu szuka się zwykle nie dlatego, że nie ma gdzie zapisać zagrożenia. Powód jest inny: zapisane zagrożenie nic dalej nie robi. Rejestr będący listą kończy się na dokumentacji. Informacja istnieje, ale nie łączy się z harmonogramem, nie sumuje się między projektami, nie wraca do firmy przy kolejnym projekcie i do każdego dokumentu trzeba ją przepisywać osobno. Rejestr będący modułem robi te cztery rzeczy sam. Kierownikowi zostawia to, czego żaden system za niego nie zrobi: decyzję, jak zareagować. Jeśli wasz rejestr jest dziś aktualizowany głównie przed komitetem sterującym, najtaniej sprawdzicie to tak: przenieście jeden projekt i powiążcie trzy ryzyka z zadaniami w harmonogramie.