Sprzedawcy srebrnych kul - Część 11 - Mission impossible

Nie możesz wygrać - nie możesz zremisować - nie możesz nawet wycofać się z gry. Prawa Ginsberga

Nie możesz wygrać - nie możesz zremisować - nie możesz nawet wycofać się z gry. Prawa Ginsberga

Dzięki psychologicznemu prawu pierwszeństwa RYZYKO na zawsze już będzie mi się kojarzyć z pierwszymi odcinkami polskiego komiksu o przygodach kapitana Żbika. Była to jedna z prób przybliżenia w atrakcyjnej formie szaremu obywatelowi pełnej niewdzięcznego znoju i ryzyka pracy oficerów MO. Dzisiaj też z uwagą śledzę poczynania organów ścigania, ale z zagadnieniami ryzyka mam częściej do czynienia w odniesieniu do projektów IT. Czasem jednak myślę, że może przyjąłby się na rynku pomysł wydania komiksu "Ryzyko - nowe pokolenie" przybliżającego młodzieży równie, jak policyjna, niebezpieczną i ryzykowną pracę wytwórców oprogramowania. Dlaczego komiksu? Bo w tradycyjny sposób o ryzyku w projektach informatycznych napisano już praktycznie wszystko. Wzory na liczenie "ekspozycji ryzyka" znamy na wyrywki, mamy modele statystyczne i rozkłady Monte Carlo, umiemy tworzyć mapy i radary ryzyka. Wiele firm dysponuje obszernymi taksonomiami ryzyka, modelami wyceny ryzyka, procedurami, standardami, a nawet specjalistycznymi narzędziami i systemami do zarządzania ryzykiem. Mamy też niezliczone firmy szkoleniowe, które prześcigają się w dostarczaniu kursów traktujących o ryzyku i strategiach jego tłumienia. W dzisiejszych czasach brak wiedzy z zakresu zarządzania ryzykiem jest dla menedżera jedynie wymówką, i to na poziomie "palca i głowy".

Dlaczego zatem w naszych projektach powszechną praktyką jest ignorowanie ryzyka i rzucanie się w wir wydarzeń z nadzieją na cud w myśl Mickiewiczowskiej maksymy "...sponsor projektu na przodzie

i jakoś to będzie..."?

Ryzyko zarządzania ryzykiem nr 1: Kultura organizacyjna

Główny problem jest związany z kulturą zarządzania w organizacji. Pełni entuzjazmu i nadziei menedżerowie wracający ze szkolenia są najczęściej bezlitośnie "gaszeni" przez bardziej doświadczonych kolegów zdających się "wiedzieć lepiej". Przesada? Być może, ale skąd w 80% szkoleń, które przyszło mi prowadzić z polskimi menedżerami projektów, jedyną stałą opinią wyrażaną przez ich uczestników była ta, że o zarządzaniu ryzykiem powinni słyszeć nie oni, lecz ich przełożeni? Wyjaśnienie jest proste: kultura strachu lub bardziej mądrze, bo z angielska: "we can do it - management". Mój przełożony ciśnie mnie, gdyż musi wykazać się przed swoim, który dostał zadanie od swojego, który odpowiada przed swoim itd. W kulturze strachu, gdzie wątpliwości oznaczają słabość, nie ma mowy o zarządzaniu ryzykiem. Jest rozkaz, musi więc być natychmiastowe wykonanie bez względu na konsekwencje oraz straty w ludziach i sprzęcie.

Jak rozpoznać organizację z taką kulturą projektową? Może na spotkaniach lub naradach usłyszeliście Państwo następujące zdanie: "Mamy tylko jedno ryzyko: projekt może się nie udać. Będziemy zarządzać nim, zasuwając dzień i noc przez siedem dni w tygodniu, robiąc wszystko, co tylko możliwe, i modląc się, by tak się nie stało". Słyszeliście, prawda?

Ryzyko zarządzania ryzykiem nr 2: Koszty

Smutnym faktem życia jest to, że robienie czegokolwiek sensownego związanego z zarządzaniem ryzykiem kosztuje. Jest to tak oczywiste dla wielu menedżerów, że w ogóle rezygnują z ponoszenia tych kosztów. Problem jednak w tym, iż narażają się na inne koszty związane z rozwiązywaniem sytuacji kryzysowych, które w wielu przypadkach są znacznie wyższe niż koszty zapobiegania ryzyku. Zachęcam tych, którzy szukają dowodów, do przeprowadzenia analizy kosztów "gaszenia jakiegoś znaczącego pożaru" w swoim projekcie i zestawienia ich z kosztami "prewencji", której w porę nie podjęli. Robiłem to ćwiczenie wielokrotnie. Pomaga otworzyć oczy. Bo nie chodzi o minimalizowanie do zera kosztów kryzysów, ale znalezienie lubianego przez dyrektorów finansowych złotego środka: minimum sumy kosztów zarządzania ryzykiem i kryzysem projektu.

Ryzyko zarządzania ryzykiem nr 3: Ucieczka nie posuwa nas do przodu

Marzymy o projekcie, w którym wszystko byłoby od początku wiadomo, zakres niezmienny, terminy nienapięte, budżet z dużą rezerwą, zespół miły, umotywowany i doświadczony. Czas się obudzić. Projekt wolny od ryzyka nie jest wart realizacji. Dzisiaj warto robić jedynie te projekty, przed którymi ze strachu słaniamy się na nogach. Budowa nowoczesnego oprogramowania jest biznesem ryzykownym, i nic tego nie zmieni. Jedyne, co możemy zrobić, to oswoić się ze strachem i uważać - zarządzać ryzykiem. Zupełnie jak żołnierze na froncie. Żaden z nich nie zna "dnia ani godziny", ale nie są przecież pozbawieni wolnej woli i potrafią działać racjonalnie tak, aby wykonać zadanie i przeżyć. I jakoś nikt nie ma do żołnierzy pretensji o to, że się boją i otwarcie mówią o swoich wątpliwościach. Taka ekstremalna sytuacja nie tylko wyzwala adrenalinę pomagającą przetrwać trudne doświadczenia, ale przede wszystkim wymusza twórczy dialog prowadzący do kompromisu, który sprowadza ryzyko do poziomu akceptowalnego przez wszystkich. W projektach IT taki dialog występuje jednak bardzo rzadko. Jeśli już, to w sytuacjach kryzysowych, gdy na większość sensownych działań jest już za późno i to, co pozostaje, to jedynie "ewakuować tych, którzy przeżyli".

Informatycy są wychowywani w przekonaniu, że wszystko jest możliwe i zależne jedynie od liczby nadgodzin spędzonych w pracy, a każdy, kto podnosi problem ryzyka, to mięczak, niegodny pracy w naszym zespole.

I na koniec jeszcze jedno praktyczne spostrzeżenie. Organizacje, które naprawdę zarządzają ryzykiem, mało o tym mówią. Zachęcam do zaprzestania niekończących się dyskusji o tym, jak zarządzać ryzykiem, bo to już wiemy! Ważniejsze jest przemyślenie sposobów wdrożenia od dawna znanych wszystkim najlepszych praktyk:

  • Utrzymywanie spisu głównych rodzajów ryzyka projektowego

  • Ilościowa ocena i priorytetyzacja rodzajów ryzyka

  • Określenie najwcześniejszych możliwych wskaźników wczesnego ostrzegania

  • Ciągłe monitorowanie ryzyka

  • Mianowanie osoby odpowiedzialnej za śledzenie rodzajów ryzyka!
Tylko tyle? Niestety, dla wielu organizacji jest to wciąż "aż tyle"! ?

Tomasz Byzia jest dyrektorem ds. rozwoju firmy Premium Technology.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200