Projekt można wykonać zgodnie z planem, albo zaplanować zgodnie z wykonaniem. Krzywa bólu ilustruje dwa scenariusze podejścia do realizacji projektu.
Pierwsze podejście, proponowane przez metodykę, zakłada, że najpierw planujemy, a później realizujemy. Drugie zaś zakłada, że robimy jak nam wyjdzie, a później staramy się wmówić otoczeniu, że tak właśnie miało być.
Planowanie projektu ma na celu jak najszybciej podnieść nasz poziom wiedzy o projekcie, aby szybciej podjąć racjonalne decyzje. A co się dzieje w przeciwnym wypadku?
Podejście usystematyzowane przyjmuje, że spędziliśmy czas na przemyśleniu przedsięwzięcia. Po drodze być może pokłóciliśmy się o założenia koncepcji, ramy czasowe, bądź budżetowe. Być może, czyjeś pragnienia nie zostały zaspokojone, ale wszystkie te dyskusje odbyliśmy „na sucho”. To znaczy zanim została wydana pierwsza złotówka na dostarczenie zakresu. Zmiany w papierowej koncepcji są tanie, duuużo tańsze niż zmiany dokonywane w realnym świecie, gdy dom już stoi, albo u 1000 użytkowników zainstalowano nowy system informatyczny. Obrazowo wzrost koszt zmian w trakcie projektu przedstawia pierwszy wykres.
Dzięki temu, że większość wymagań przedyskutowanych jest na początku, spada również ilość zgłaszanych zmian. Po prostu im więcej mamy zbudowane, tym mniej potrzeba modyfikować. Stawiamy od razu dobrze, zgodnie z wszelkimi ustaleniami i każdy element do siebie pasuje, jak w puzzle’u.
W podejściu drugim ruszamy od razu. Początkowy postęp prac zachwyca zespół, klienta i sponsora. Zamiast siedzieć nad papierkami widać, jak rośnie w oczach. Po jakimś czasie jednak coś dziwnego zaczyna się dziać. Początkowo bardziej wrażliwi odczują spadek ducha drużyny. Pojawi się dodatkowe spotkanie, na którym trzeba będzie omówić bieżące zgłoszenia klienta. Po kolejnym tygodniu klient zadzwoni do dyrektora i zapyta, czy w projekcie wszystko w porządku i czy na pewno będzie na czas. Znowu spotkanie. W mailach przewijać się będzie coraz więcej adresatów.
W końcu ktoś zapyta o zatwierdzone wymagania, czy specyfikację. Ktoś inny odpowie, przecież od początku wiadomo było, że tak robimy. Ktoś trzeci sprostuje, że miało być zupełnie odwrotnie. Zatem dyrektor poprosi o prezentację stanu projektu.
Niezależnie coraz wolniej będzie dostarczany zakres. Skoro coraz wolniej, to klient zacznie się irytować. Zatem zaczniemy siedzieć po godzinach, aby nadgonić. Z czasem uchylony zostanie aksjomat „najwyższej jakości” i klient stanie się dodatkowym testerem.
Po paru tygodniach dynamika sporów przekroczy dynamikę prac w projekcie. W punkcie, w którym więcej czasu poświęca się na spotkania i slajdowiska, niż na realną pracę, nawet dyrektor zacznie coś podejrzewać. Dalej jest już tylko weselej, więcej DW w mailach, więcej spotkań, ostrożniejsza komunikacja, po 10 podpisów przy każdej specyfikacji i klient jako główny tester. W końcu większość czasu spędzana jest na inwentaryzowaniu zgłaszanych zmian i ciągłym ich analizowaniu.
Właśnie minęliśmy horyzont zdarzeń i wpadliśmy do osobliwości, gdzie nie działają znane nam prawa fizyki. Jedyny cel to machać rękami, aby nie wciągnęła nas czarna dziura.
W podejściu drugim tytułowy ból narasta lawinowo. Udało się uniknąć początkowych konfliktów związanych z planowaniem, ale zemściło się to szesnastokrotnie. W trakcie projektu narasta nie tylko koszt zmian, ale i ich skala. W skrajnej sytuacji, gdy pełzanie zakresu, wypełnia każdą minutę dnia, projekt w ogóle nie jest realizowany, tylko czas poświęcany zostaje na kłótnie. Po kilku zmianach kierownika projektu, taki projekt zawiesza się, odkłada lub kasuje.
Zachęcam do poczytania o projekcie System Taurus. Ciekawy sposób na zmarnowanie prawie 500 milionów funtów.
