Jak wiele planowania potrzeba, aby poradzić sobie w projekcie, czyli słów kilka o rutynowym podejściu do projektów

Nieco kolokwialnym językiem zadane pytanie jednak nie jest moim zdaniem trywialne. Standardy opisujące dobre praktyki zarządzania projektami proponują dziesiątki technik, metod, zachowań, które podnoszą sukces projektu. I tak faktycznie jest. Każda z tych praktyk z osobna w pewnych projektach na pewno pomogła. Skoro każda bywa użyteczna, to można by pomyśleć, że dwie są lepsze niż jedna, a jedenaście niż dziesięć. Idąc tym tropem, ktoś mógłby zaryzykować stwierdzenie, że projekt należy zaplanować tak szczegółowo, jak to tylko możliwe. Wszak każdy dzień planowania zwraca się wielokrotnie w realizacji.

I w tym momencie pojawia się podejście zwinne, które mówi, że nie warto planować zbyt daleko wprzód, bo rzeczywistość jest zmienna i nieprzewidywalna. Agile zakłada ogólne zaplanowanie zakresu na poziomie wymagań funkcjonalnych przede wszystkim i z grubsza przewidzenie głównych wersji. Szczegóły dopracuje się w trakcie wraz z oddawaniem kolejnych partii rozwiązania. To buduje poczucie samodzielności zespołu i ułatwia zmianę kierunku, gdy wpadnie nam lepszy pomysł do głowy. Niskie koszty planowania, szybkie przejście do realizacji i ciągła optymalizacja. Idealne rozwiązanie? Niezupełnie.

Bowiem tu wkraczają projekty budowlane na scenę. Wyobraźmy sobie zbudowanie bloku mieszkalnego do połowy i decydowanie, ile jeszcze pięter chcemy postawić. „Skoro tak dobrze sprzedają się mieszkania, to zamiast dwóch pięter dobudujmy jeszcze 6, a może 8. Jak będziemy na szóstym, to się zdecyduje, czy idziemy do ósmego.” Nie chciałbym, ani nikt rozsądny mieszkać w takim zwinnym budynku. Taki budynek przyniósłby mi na myśl styl architektoniczny Pueblo. Po prawej możecie zobaczyć zdjęcie z Encyklopedii Britannica prezentujące ten styl. Przy trzypiętrowych budynkach kilkaset lat temu, to mogło się sprawdzać, choć mam wrażenie, że co jakiś czas można było powitać sąsiada z góry w swoim pokoju jadalnym. Choć z drugiej strony najbardziej zwinna katedra świata – Sagrada Familia – już prawie jest gotowa.

W takim razie jednak trzeba planować szczegółowo. Każdy wymiar projektu z osobna, tak precyzyjnie jak to możliwe. Tylko, co zrobić, gdy wypuszczamy innowacyjny produkt na rynek i nie mamy pojęcia, czego chcą klienci. Można zainwestować w rozbudowane badania, o ile posiadamy budżety, ale po pierwsze to będzie trwało, a po drugie badania nie zawsze przekazują faktyczne potrzeby klientów. Jak powiedział Henry Ford „Gdybym na początku swojej kariery jako przedsiębiorcy zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem.” No to może sprawdzić bojem, co się sprzeda? Szybko wypuścić okrojony produkt na rynek, zebrać uwagi, poprawić, jeszcze raz wypuścić i zebrać opinie.

Powyższym wprowadzeniem chciałem uświadomić, że problematyka wysiłku poświęconego na planowanie wcale nie jest tak oczywista i dyskusje na ten temat ciągną się za nami od dłuższego czasu. Dwight Eisenhower powiedział, że „w trakcie przygotowania się do bitwy plany są bezużyteczne, jednak samo planowania jest nie do zastąpienia”.

Do poniższych rozważań zainspirował mnie eksperyment, który od 2012 roku prowadzimy przy okazji naszych szkoleń. Przy analizie wartości planowania pewną przeszkodą jest fakt, że dany projekt robi się tylko raz. Wyjdzie, nie wyjdzie, mamy dane z próby o liczebności jeden. Za kolejnym razem to już będzie inny projekt, z innymi ludźmi, z inną wiedzą i w nieco innych warunkach. Zatem ciężko porównać. A co by było, gdyby móc zlecić kilkuset osobom realizację tego samego projektu i za każdym razem to zmierzyć. A gdyby dodatkowo części tych zespołów dać plan, a części nie. My tak zrobiliśmy, dla ponad 600 osób przeprowadziliśmy symulację, w której wspólnie realizowali pewien projekt. Część z nich mogła go zaplanować, cześć musiała pójść na żywioł. Gdybyście byli zainteresowani wynikami, to wszystko jest jawne i dostępne tutaj. Pisząc artykuł na temat wyników tego eksperymentu, doszedłem do pewnych przemyśleń na temat wartości planowania.

Otóż po jednej stronie równania mamy wysiłek i koszty związane z planowaniem i czas na nie poświęcony. Wysiłek i koszty można wyrazić w pieniądzu. Czas przy pewnym uproszczeniu również, choć gdyby nie chcieć upraszczać, to można zauważyć, że w przeciwieństwie do kosztów, czas nie można odtworzyć, co generuje ograniczenia decyzyjne. Warto zapoznać się z terminem Last Responsible Moment. Po drugiej stronie równania mamy wartość planu, jaki dotąd opracowaliśmy, albo alternatywnie koszt błędu, gdy tego planu nie mamy. Oba parametry ważone są prawdopodobieństwem wystąpienia.

To, co zauważyliśmy przy okazji eksperymentu Baza na Marsie to, że zespoły z dokładnym i pozbawionym błędów planem radzą sobie lepiej, co jest dość oczywiste. Jednak również lepiej sobie radzą, gdy planu nie posiadają, ale robiły inny projekt razem. Wspólne doświadczenie pomaga, co znowu może być oczywistą konkluzją. Ale nieoczywistym pytaniem jest, kiedy bardziej potrzebujemy planu, a kiedy bardziej zgrania. Albo na ile możemy zrezygnować z planu, na rzecz podejmowania bieżących decyzji przez zgrany zespół.

Prowadzenie projektu można by rozbić na setki decyzji, które zapadają w jego trakcie. Decyzje to wybór między różnymi stanami. Na przykład, na kiedy skończymy, jaki będzie budżet, czy dane rozwiązanie zadziała, czy klient odbierze nasz pomysł itd. Poniżej narysowałem poglądowy model postępowania z  pojedynczą sytuacją decyzyjną.

Podejście kaskadowe różni się od zwinnego tym, że w tym pierwszym większość decyzji omawia się na początku projektu, a w tym drugim główne decyzje zapadają na początku, ale później co sprint następuje powrót decydowania. W efekcie przeciętny dystans planowania jest dłuższy w projekcie kaskadowym niż w zwinnym. Korzyść z podejścia kaskadowego leży w tym, że koszt zmian potrafi rosnąć lawinowo wraz z czasem, więc odkręcenie błędnej decyzji może być kosztowne. Korzyść z podejścia zwinnego leży z kolei w tym, że w trakcie projektu przyrasta nam wiedza, więc decyzje podjęte później mają lepszą jakość niż te wcześniej. Symbolicznie prezentuje to kolejny rysunek. Innymi słowy w podejściu kaskadowym zakłada się, że koszt zmian rośnie szybciej niż ryzyko z podjęcia decyzji. Natomiast w podejściu zwinnym odwrotnie.

Idąc dalej, można by się zastanowić, czy kompromis między oboma podejściami mógłby zakładać przyjęcie różnych dystansów planowania dla różnych typów decyzji. To znaczy, aby jedne decyzje były podejmowane z wyprzedzeniem, a inne na bieżąco, bo i tak koszty zmian są niewielkie. Przykładowo ustalenie ogólnej koncepcji projektu na starcie, ale rodzaj i ilość zamawianych części na bieżąco. We wspomnianym wyżej eksperymencie Bazy na Marsie uczestnicy przy pierwszym projekcie zwykle zastanawiają się nad całym projektem zanim zaczną, analizują układ budynków, wielkości zamówień. Przy drugim lub trzecim część grup dostrzega, że rytm projektu nadaje transport, na który za każdym razem trzeba czekać 30 sekund. W związku z tym wystarczy poprawnie zamówić najbliższą partię klocków. Zaś zastanawianie się nad dalszymi nie przeszkodzi, ale i nie przyśpieszy realizacji. Po prostu zgrany zespół wie, na co zwracać uwagę w trakcie projektu, wie, jakie zasoby chronić, a o jakich może decydować na bieżąco.

Problematyką wyboru istotnych zadań zajmuje się łańcuch krytyczny, ścieżka krytyczna, wartość wypracowana. Problematyką momentów podejmowania decyzji zajmuje się Prince2, mówiąc o delegowaniu zadań i poziomach tolerancji oraz PMBOK Guide pośrednio, pisząc o konstruowaniu planu zarządzania projektem. A także podejścia zwinne, gdy zalecają definiowanie na starcie wizji produktu, a później co sprint planning redefiniowanie zakresu oraz pozostawianie zespołom decyzyjności co do sposobu implementacji w trakcie sprintu.

Jednak żadna z tych metod nie bierze pod uwagę krzywej uczenia się zespołu. Tego, że razem robi kolejny i kolejny projekt. W praktyce, obserwując firm, wiele razy miałem szansę dostrzec, że stosują tą filozofię intuicyjnie. Widać to szczególnie w przedsiębiorstwach, w których występuje niska rotacja i ludzie są zlokalizowaniu w jednym miejscu. W trakcie lat wiele zasad współpracy dogranych jest „na gębę” i nigdzie nie zapisanych. W niektórych z tych firm projekty mimo braku formalnych zasad toczą się zaskakująco dobrze, w innych z niewiadomych powodów notują problemy. I to jest główna słabość podejścia intuicyjnego, nie wiadomo, dlaczego projekt idzie nam gorzej. Na wyjściu brak terminowości, utrzymania marży lub jakości, a na wejściu mnóstwo ukrytych praktyk radzenia sobie w projektach. Brak jawności tych praktyk powoduje z kolei, że trudno nimi zarządzać i dbać o ich powtarzalność.

Podsumowując, zastanawiam się, czy możliwe byłoby opracowanie, obok podejścia kaskadowego i zwinnego, sformalizowanie podejścia rutynowego. Rutynowego, bo eksploatującego rutynowe działania w zgranym zespole.