Nie istnieją projekty całkowicie odporne na strzały. Zawsze może trafić się sytuacja zupełnie nieprzewidziana. Jednak okazuje się, że większość „nieprzewidzianych” sytuacji jest od początku wpisana schemat projektu i tylko brak właściwego planowania i reagowania powoduje, że po raz dziesiąty w nie wpadamy.
Przykłady? Pełno ich:
- Nieterminowy, chaotyczny dostawca nie zmieni się dlatego, że rozpoczęliśmy z nim nowy projekt.
- Niestabilna technologia będzie taka cały czas, dopóki z niej nie zrezygnujemy.
- Niekompetentny członek zespołu projektowego pozostanie taki, aż ktoś go nie nauczy.
- Zbyt ambitne szacunki kosztów i terminów podawane przez handlowca będą dalej zbyt ambitne aż ktoś je przekalibruje.
- Produkt końcowy będzie miał te same defekty, dopóki nie zmieni się jego całej konstrukcji.
- Dopóki klient będzie ciągle zmieniał zdanie nie da się zamknąć zakres i terminy będą uciekały wprzód z prędkością wystrzału.
- Brak motywacji do pracy w firmie przenosi się na wszystkie projekty robione z danym zespołem.
- Niejasnych celów stawianych przez sponsora nie da się obejść dopieszczeniem zakresu.
- Opór organizacji przed zmianami przy jednoczesnym braku wsparcia zarządu może skutecznie storpedować każdy wewnętrzny projekt.
Walka z ryzykiem ma dwa elementy:
- Zmniejszanie niepewności
- Reagowanie na nową wiedzę o rzeczywistości, którą uzyskaliśmy w punkcie powyższym.
Aby uprościć rozważania, wyróżniłbym kilka kroków radzenia sobie z ryzykami. Ważne, że większość z nich jest do wykonania na długo przed pierwszym wbiciem „łopaty w ziemię”. Zastrzeżenie uprzedzające: wiem, że metodyki zarządzanie ryzykiem definiują w nieco inny sposób, ale sądzę, że tak łatwiej będzie zrozumieć, o co w tym chodzi.
Krok 1. to Zmniejsz niepewność, na ile to możliwe
Rzeczywistość jest niepewna, gdyby tak nie było grałbym kilka razy w tygodniu w totolotka (pomijam fakt, że wygrywałbym za każdym razem złotówkę, a Totalizator Sportowy zbankrutowałby po miesiącu, wszak wszyscy inni obywatele też by grali). Duża niepewność oznacza, że zbiór wariantów działania dostępny dla kierownika projektu jest bardzo rozległy, niekiedy nawet tak wielki, że nie znany. Dzięki zdobywaniu nowej wiedzy może on eliminować warianty, które się nie przydarzą i skupić się na tych prawdopodobnych. Na skrajnym przykładzie szacowania czasu zadania wygląda to tak:
– Ile zajmie Ci napisanie programu do zarządzania emocjami? – zapytał kierownik projektu.
– Dotąd robiliśmy programy magazynowe, księgowe, portale internetowe, witryny, system BI, nawet do zarządzania pocztą. Natomiast z emocjami nie miałem i nie mam za wiele do czynienia. – odparł lider programistów.
– Wiem, bo znam twoją żonę. Natomiast to jest prosta sprawa – klient chciałby być szczęśliwy i wiedzieć, kiedy jest. – odparł nie zrażony kierownik.
– Czas wykonania takiego zadania może zawierać się w przedziale 2 minuty (zainstalujmy mu grę Angry Birds na komórce) do 10 lat (poczekajmy na pewne technologie skanowania mózgu, które podobno mają pojawić się w najbliższej przyszłości).
Jednak po zdefiniowaniu przez klienta kilku założeń poziom niepewności może drastycznie spaść.
– No chodzi o to, że klienci wchodzą na witrynę, czytają różne artykuły i trzeba zrobić aplikację, która zareaguje zanim klient zamknie okno przeglądarki. Wówczas wyskoczy buzia doradcy klienta i zapyta, jak go jeszcze uszczęśliwić.
– Aaaaa. To powiedziałbym od 2 miesięcy do roku. – odpowiedział programista.
Idąc dalej, wykonanie analogicznych zadań pozwala jeszcze bardziej zmniejszyć niepewność. Analogicznych, bo robionych z tym samym klientem, na podobnym rynku, w tej samej technologii id.
– Wiesz, co. Okazało się, że dla innego klienta dwa lata temu robiliśmy już coś takiego. Znalazłem archiwum tego projektu, w tym stare harmonogramy. Różnica polega na tym, że okienko ma wyskakiwać zanim klient zamknie przeglądarkę, a nie po tym. To z resztą była główna przyczyna niepowodzenia tamtego projektu. – ciągnął dalej kierownik projektu.
– Z tego, co widzę, wówczas to zadanie zajęło 5 miesięcy dla 3 osób. Dodałbym szacunek na algorytm na szybsze wyskakiwanie okienka – tak z miesiąc i możesz wysłać ofertę do klienta. – zakończył programista.
W ten sposób w miarę wzrostu wiedzy zawęża się nasza zdolność do przewidywania. Ale uwaga, nic za darmo. W trakcie tego zawężania przyjmujemy szereg założeń – czyli zdań, które uznajemy, że pozostaną prawdziwe do końca projektu, np. że klient będzie rzetelnie płacił za projekt. Dobrą praktyką jest zapisywanie wszelkich założeń i regularna analiza ich prawdziwości, bowiem każde założenie może przestać być prawdziwe, np. klient popadnie w tarapaty finansowe w związku z recesją.
W jednej z naszych gier szkoleniowych (Mayday Mayday) uczestnicy zostają postawieni przed wyzwaniem planowania projektu, o którym nic nie wiedzą. Nie wiedzą, ile zajmie dane zadanie, co zrobić po nim, ilu ludzi zaplanować itd. Jakąż to budzi irytację! Ojojoj! J Ale po pierwszych protestach zaczynają planować w ciemno. Pierwszy projekt jest z reguły spalony, nijak się ma do harmonogramu, ale kolejne bazują na wiedzy uzyskanej przy nim. Te już zaczynają być trafione, zaś pod koniec drugiego dnia przy dziesiątym projekcie już nie mamy do czynienia z ryzykiem tylko z powtarzalnymi projektami o stałej zmienności. Nabyta wiedza ujarzmia ryzyka pojawiające się i okazuje się, że działają one według ukrytego początkowo wzorca. Wystarczy się nauczyć środowiska, a nawet zagrożenia stają się sprzymierzeńcami. Wszak głodny lew może równie dobrze zapolować na naszą konkurencję, jeżeli wiemy, jakie ma zwyczaje łowieckie.
Paradoksem projektów jest to, że najważniejsze decyzje zapadają na ich początku, a najwięcej wiemy, gdy projekt się już skończy i nic nie można zmienić.
Ciąg dalszy nastąpi…
