W słynnej powieści W poszukiwaniu straconego czasu narrator wraca do przeszłości po zamoczeniu w herbacie ciastka magdalenki. Przypadkowy bodziec wywołuje falę wspomnień – niespójnych i wyidealizowanych – które zapełniają strony obszernej powieści. W jaki sposób project managerowie kontynuują tradycję prozy francuskiej?
Czy podążanie ścieżkami wielokrotnie wydeptanami przez nas samych lub innych project managerów jest zawsze najlepszym wyborem? Zwłaszcza, kiedy ślady kroków często zbiegają się w jednym punkcie – w ślepej uliczce o nazwie lessons learned [1]. Z jednej strony skończony projekt należy do przeszłości, z drugiej strony nie powinno się o nim od razu zapominać.
Zarządzić – dowieźć – zapomnieć?
Lessons learned w większości przypadków stanowi synonim zaniedbania i dezintegracji kultury projektowej zamiast kojarzyć się z obowiązkowym i wartościowym elementem fazy zamknięcia projektu. Najczęściej powtarzającym się argumentem jest brak czasu. Nie tylko traci na tym zespół projektowy – pozbawiony możliwości konstruktywnej ewaluacji sukcesów i porażek, ale również traci na tym organizacja – nie korzystając z wypracowanych tropów do usprawnień ani nie ucząc się praktyki usprawnień systemowych. Każdy projekt jest inny, jednak pewne problemy potrafią wracać jak bumerang.
Badania pokazują, że 91% kierowników projektów zdaje sobie sprawę z wartości lessons learned, jednak tylko 13% przeprowadza je dla wszystkich swoich programów [2]. Lessons learned nie są jednak remedium na zmiany w trakcie projektu ani tym bardziej nie wspierają usprawnień czy innowacji jeśli czas na refleksje i decyzje ma miejsce po dostarczeniu projektu. Nie budują także strategii usprawnień systemowych w organizacji. Dlaczego?
Po pierwsze, jednorazowe spotkanie to za mało. Warto dlatego uwzględnić algorytm „pamięci obiadowej”, innymi słowy: jeżeli pamiętasz co znalazło się na talerzu każdego dnia minionego tygodnia to jest duża szansa na to, że będziesz pamiętać co znaczącego wydarzyło się przez ostatni tydzień w projekcie. Czy podobną wartość przyniesie próba reminescencji doświadczeń z ostatniego półrocza? Można sobie tylko wyobrazić niestrawność spowodowaną ilością zjedzonych magdalenek dla stymulacji pamięci…
Po drugie, spotkanie nie ma na celu snucia sentymentalnej wyliczanki z bierną puentą o tym, że już niczego nie można zmienić. Wprost przeciwnie, rezultat spotkania powinien zakładać decyzje o reakcjach na rzeczywistość dynamiki projektowej. Głos kierownika projektu nie jest jednak jedynym bądź wyrokującym – jest kolejnym oprócz głosów osób z zespołu projektowego. Suma doświadczeń i perspektyw zaangażowanego zespołu obejmująca tydzień pracy oraz wspólny szacunek ryzyk podejmowanych na kolejny, nowy tydzień aktywności budują strategiczny backlog usprawnień, przenikający do backlogu zadań. Brak regularnych pauz w celu oglądania się za siebie i dostosowywania kierunku pracy skazuje projekt na niewykorzystany potencjał, a zespół projektowy na ograniczone bądź wręcz dysfunkcyjne zaangażowanie w pracę.
Lekcje czy retrospekcje?
Konstruktywne podejście do rozwiązania powyższych kwestii podpowiada podejście Agile w postaci retrospekcji realizowanej w Scrumie. Wartość dodana tego spotkania manifestuje się poprzez regularność, skupienie na wyniku spotkania (lista usprawnień wraz z osobami odpowiedzialnymi za podjęcie się ich w najbliższej iteracji) oraz poprzez monitorowanie kondycji kultury ciągłych usprawnień – statusu zadań i problemów z poprzednich retrospekcji. Scrum definiuje uczestników spotkania poprzez kryterium praktycznego zaangażowania w pracę – jest to spotkanie dla zespołu, bez zewnętrznych obserwatorów.
W przypadku prowadzenia zwinnego projektu – project manager może być również uczestnikiem retrospekcji. Albo dołącza do spotkania w wyznaczonym przez zespół odcinku czasowym, albo jest uczestnikiem tak zwanej Overall Retrospective jeśli w projekcie pracuje więcej niż jeden zespół Scrumowy (Large-Scale Scrum) a spotkanie uwzględnia różnych interesariuszy oraz przedstawicieli zespołów – po tym jak odbędzie się retrospekcja na poziomie zespołów. Ten drugi rodzaj spotkania zdecydowanie wzmacnia i rozwija kulturę myślenia systemowego.
Retrospekcja aktywizuje również do wyjścia ze strefy komfortu zarówno project managera, jak i zespół – zderzając wyobrażenia i założenia karty projektu ze zweryfikowanymi, rzeczywistymi wyzwaniami. W rezultacie backlogi usprawnień mogą stanowić podstawę do meta-retrospekcji, która w ramach lessons learned wyróżni najbardziej adekwatne i strategiczne zmiany lub wskaże powtarzający się, nierozwiązany problem. Powinien to być znaczący sygnał dla organizacji w kierunku rozwijania kultury ciągłych usprawnień.
Backlog usprawnień nie powinien jednak podzielać losu słynnego dzieła W poszukiwaniu straconego czasu, którego tytuł wiele osób kojarzy, ale którego prawie nikt nie przeczytał. Organizacja bowiem – szczególnie PMO – powinna dbać i rozpowszechniać rejestr usprawnień przy okazji przyszłych projektów a project managerowie powinni go uwzględniać, minimalizując dzięki temu efekt „mądrego project managera po szkodzie”
Myślenie życzeniowe czy systemowe?
Nic dwa razy się nie zdarza i nie zdarzy w projekcie – tak podpowiada myślenie życzeniowe. Każdy projekt to nowa przygoda, dlatego nie dziwią postawy kierowników projektów przypominające mobilizację zdobywców nowych światów. Chciałoby się wierzyć, iż nowy projekt nie będzie transmitował starych problemów – gdyby nie to, że jest on częścią danej organizacji i jej wyjątkowego systemu ograniczeń, polityk i zamiecionych po dywan zaszłości.
Gdyby słynny Sherlock Holmes nie praktykował pogłębionych obserwacji oraz nie ćwiczył uważności – nie byłby skutecznym detektywem i straciłby pracę. Przed podobnymi zadaniami znajdowania szkieletów w szafie projektu stają także project managerowie. Często jednak zdarza się, że nie podejmują wtedy „śledztwa”, nie rozmawiają ze świadkami, nie analizują przesłanek, nie słuchają innych… Nie rozwiązują zagadki, którą ostatecznie spotyka los kolejnego punktu w zbiorze lessons learned.
Myślenie systemowe natomiast dyscyplinuje do pogłębionych poszukiwań i analiz, nie zadowala się pewnikami ani nie ufa prostym korelacjom. Te ostatnie bywają najbardziej zwodnicze. W przypadku projektów nierozwiązane problemy czy blokujące postęp pracy niespodzianki mogą oznaczać złożony problem. Być może taki, który został zignorowany przez innego project managera. Być może powtarza się on w innych projektach, ale przybiera zmienioną postać. Z drugiej strony nie wszystkie kwestie muszą być złożone – należy mieć na uwadzę również i tę podchwytliwą cechę właściwą systemom. Dlatego warto żeby kierownik projektu – dzięki retrospekcjom – współtworzył z zespołem interaktywną opowieść o projekcie.
Wszystko zaś jest systemem – od termostatu po drzewo, nie wspominając o organizacjach. Trafnie wyjaśnia to Donella Meadows [3]. Na przykład przekonanie o racjonalności jest dowodem… nieracjonalności. Nie jesteśmy racjonalni, ponieważ nie wiemy wszystkiego o wszystkim – nie mamy możliwości poznania złożoności systemów, w których funkcjonujemy. Przekonywał o tym Herbert Simon, laureat nagrody Nobla z dziedziny ekonomii, twórca teorii ograniczonej racjonalności. Według niej podejmujemy decyzje nie tylko zgodnie z ograniczeniami naszej wiedzy, ale również według osobistych asocjacji i kryterium podobieństwa do znanych nam sformułowań czy przebytych doświadczeń. W związku z tym zawsze warto konsultować swoje decyzje z innymi, gdyż pierwszy, subiektywny wybór wcale nie musi być najlepszym. Jest to szczególnie znaczące w roli project managera, który nie tylko powinien brać pod lupę osobiste nawyki, ale także edukować o tym innych – zespoły i interesariuszy.
Czas nie leczy projektu
Projekt charakteryzuje przewrotna sprzeczność – z jednej strony jest wyjątkowy i niepowtarzalny, z drugiej strony zaś przewodzi stałe problemy i blokady, które w strategicznych momentach – i nie tylko wtedy – powodują spięcia i uniemożliwiają postęp pracy. Podstawowy błąd atrybucji [4] w przypadku projektów polega na uleganiu łatwości automatycznego przetwarzania informacji – bazujących na skojarzeniach i tezach niepopartych analizą kontekstu projektowego, lecz związanych z kliszami twierdzeń czy zredukowanymi best practices.
Nadreprezentacja best practices w organizacji może świadczyć o braku kultury myślenia systemowego. Najlepsze praktyki bowiem okazują się być najgorszym sprzymierzeńcem w sytuacji patowej, gdyż spełniają swoją rolę tylko w danym kontekście i przy okazji podobieństwa bolączek systemowych. Nie są więc szybkim i uniwersalnym skryptem ratowania projektu. Wyręczanie się gotową instrukcją stwarza fałszywe wrażenie alibi dla projektu, nie prowadzi jednak do rozwiązania problemów.
Dobre praktyki powinny natomiast funkcjonować jako argument dla alternatywnych propozycji – o czym powinien przypominać project manager. Uwzględnia to najnowszy raport State of DevOps 2017 [5] punktujący przywództwo transformacyjne jako kluczowy czynnik przesądzający o jakości współpracy zespołowej i związanych z nią wynikach. Decyzyjność zespołu oraz kultura feedbacku są nie mniej ważne od automatyzacji testów.
Project manager nie posiada licencji na zabijanie potencjału projektu – bezkrytycznie poddając się schematom zamiast reagując i dostosowując sposób swojego zaangażowania we wsparcie projektu. Warto dlatego mieć na uwadze, że poprawa tego ostatniego będzie procentować przy kolejnych projektach. Retrospektywne podejście powinno być częścią zintegrowanej kultury projektowej, dzięki czemu zyskują na tym nie tylko projekt i zespół, ale także organizacja.
Przypisy:
- Szczegółowa analiza lessons learned jest uwzględniona w artykułach w 12. numerze Strefy PMI
- Ada Grzenkowicz, Lessons Learned odczarowane, Strefa PMI, nr 12, 2016, s 6-7
- Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008
- Podstawowy błąd atrybucji – pojęcie wprowadzone do psychologii społecznej, opisuje powszechną skłonność do wyjaśniania zachowania obserwowanych osób w kategoriach przyczyn wewnętrznych istałych (np. cech charakteru) przy jednoczesnym niedocenianiu wpływów sytuacyjnych, zewnętrznych.
- State of Devops 2017 Report, https://puppet.com/resources/whitepaper/state-of-devops-report
Antropolożka korporacji oraz praktyk metodyk Scrum i Large-Scale Scrum (LeSS). Specjalizuje się w tworzeniu i praktykowaniu najlepszych metod współpracy biznesowej oraz w kształtowaniu kultury organizacyjnej ze szczególnym uwzględnieniem budowania, wzmacniania i odkrywania potencjału antropologii kulturowej. Obserwacje i komentarze publikuje na blogu: www.itisnotrocketscience.me