W samym środku upalnego lipca dobrym pomysłem będzie poruszyć temat o tak mroźnym skojarzeniu, jak śnieżna zaspa. Efekt o tak obrazowej nazwie pojawia się w wielu firmach realizujących regularnie projekty. To mogą być przedsiebiorstwa stricte projektowe, jak i tych, dla których projekty są tylko sposobem na podniesienie efektywności lub wytwarzanie własnych produktów.
Najlepiej pokazać go na przykładzie. Wyobraźmy sobie, że firma zaplanowała sobie, że wykona 5 projektów do końca roku. Załóżmy, że firma ma 3 zespoły, które mogą te projekty wykonać i że pojedynczy zespół naraz zajmuje się tylko jednym z nich. Kilka z nich to projekty rozwojowe, które dadzą dodatkowe pieniądze organizacji, jeden utrzymaniowy i jeden regulacyjny, które nie dają bezpośrednich korzyści biznesowych, ale trzeba je zrobić. Przy czymy deadline na regulacyjny i utrzymaniowy jest na 12 miesiąc. Regulacyjny musi być do tego momentu zakończony, natomiast utrzymaniowy można trochę opóźniać, ale z każdym miesiącem zwłoki klient będzie coraz bardziej poirytowany. Poniższa tabela prezentuje podstawowe dane projektów z naszego przykładu.
Jak widać firmie może się udać wykonać te projekty w 12 miesięcy. Firma ma dodatkowo zapas 8 zespołomiesięcy, którym może dysponować, gdyby któryś z projektów się opóźniał.
Aby zrozumieć zjawisko śnieżnej zaspy, należy wprowadzić pojęcia trzech rodzajów pracy, która możemy spotkać w projektach. Pierwsza z nich (w tabelce zielona) to ta oszacowana w planie projektu. W projektach zwinnych te szacunki niekiedy bywają nazywane estymacjami w dniach idealnych (mniej więcej). Tyle spodziewamy się poświęcić, aby wykonać dane zlecenie. Druga (źółta w dalszych tabelkach) to praca, o którą rozrasta się projekt w jego trakcie. Wynika ona z błędów estymacji, czynników zewnętrznych (jak rotacja w zespole, czy presja klienta na nowe wymagania), natychmiast nanoszonych poprawek. W końcy trzecia praca (czerwona) to praca wykonywana po oficjalnym zakończeniu projektu. Tej pracy na ogół nie ujmuje się w żadnych rozliczeniach, a dotyczy zaangażowania w naprawy błędów, „drobne zmiany”, koncepcje przyszłych potencjalnie mozliwych do zamówienia funkcji, dodatkowe szkolenia użytkowników etc., które nanosi się już po odbiorze i często opłaceniu projektu przez klienta.
Wyobraźmy sobie, że w maju okazało się, że w trakcie pierwszych trzech projektów pojawiło się kilka dodatkowych prac. Przyjmijmy, że przekroczenie jest niewielkie, bo wynosi 20%. W maju portfel wskazuje, że projekt D opóźni się o miesiąc. Dodatkowa praca pokazana jest za pomocą żółtych pól.
Przenieśmy się teraz do września. Szczęśliwie udało się zakończyć projekt B i C. Jednak opóźnienie spowodowało, że nasza firma poczuła się w obowiązku, aby wynagrodzić to klientowi i wykonać dodatkowe prace nie uwzględnione w kontrakcie. Jednocześnie wobec narastających w dalszym ciągu opóźnień w projekcie A, wzrosła presja na tempo i spadła rzetelność prac. Coraz więcej prowizorycznych rozwiązań, coraz więcej błędów odkładanych na później, powoduje narastanie długu technicznego, oznaczony na czerwono również.
Jak widać na rysunku obok projekt D musiał się opóźnić aż do 16 miesiąca. Klient, który czeka na jego efekty jest już zdrowo zaniepokojony.
Przewińmy czas do listopada. Klient projektu D wpada poirytowany opóźnieniami i wymusza, aby jednak dokończyć jego projekt w miarę szybko. Jednocześnie projekt regulacyjny nie ma już zapasu, a podobnie jak w pozostałych projektach okazało się, że praca o 20% przekracza założenia. Przy okazji pojawił się też nowy projekt rozwojowy, który został wrzucony w najbliższe wolne okienko.
Projekt A, który był najważniejszy dla organizacji jest cały czas odkładany. Po drodze ukończono B i C oraz dzięki przerzuceniu wszystkich trzech zespołó również E (wszak to regulacyjny z terminem na grudzień).
Przenieśmy się do lutego kolejnego roku (14 miesiąc). Pojawia się nowy projekt rozwojowy G oraz regulacyjny H z terminem na 17 miesiąc. W projekcie D rośnie presja klienta na zakończenie. Projekt A jest skończony jednak w związku z dużą presją na terminy, przełączaniem się między projektami oraz słabnącą pozycją negocjacyjną naszej firmy w rozmowie z klientem pojawiły się nowe prace na usuwanie błędów i dodawanie drobnych funkcjonalności. Teraz portfel wygląda jak ponżej.
Projekt A jest już na ukończeniu. Formalnie został odebrany, ale jeszcze tylko drobne poprawki zostały do wykonania. Ponieważ projekt H ma deadline na 17 miesiąc, to nie można go ruszyć, więc przesuwa się projekty F i G.
I ostatnie zbliżenie na przykładową firmę. Przenieśmy się do miesiąca 17. Projekt H tradycyjnie ujawnił dodatkowy miesiąc prac. A ponieważ termin już za progiem, to wszystkie siły rzucono na niego.
Wszystkie zespoły musiały być przerzucone do projektu H, który własnie ma termin oddania. Jednak rozwiązanie oddane jest prowizoryczne i w 18 miesiącu trzeba będzie jeszcze dosyłać poprawki. W efekcie projekty rozwojowe F i G znowu sie opóźniły i wskutek bałaganu pracochłonność F wzrosła.
Takie pełzania mogą ciągną się wiecznie. Tytułowy efekt zaspy to suma prac, które są odkładane wskutek niedoszacowania, bałąganu, presji klienta, usuwania błędów, nowych priorytetów itd. Poniżej pokazałem wykres obrazujący wielkość zaległych prac spychanych na później z miesiąca na miesiąc zgodnie z naszym przykładem.
Dodatkową konsekwencją efektu zaspy śnieżnej jest coraz większy bezwład organizacji oraz skupienie się nie na projektach ważnych, a na tych najbardziej zaległych lub pilnych. W naszym przykładzie projekty rozwojowe były coraz bardziej spychane przez regulacyjne. W pewnej organizacji realizującej około 40 projektów miesięcznie, po dwóch latach, efekt zaspy wynosił kilka tysięcy osobodni i właściwie rozwój tej firmy zatrzymał się.
