Często jest tak, że po zakończeniu projektu w natłoku kolejnych zadań nie skupiamy się nad tym co szło źle lub dobrze, zamykamy pewien rozdział i idziemy dalej. Chyba, że kończymy totalną katastrofą, to wtedy konieczne będzie tłumaczenie się przed kierownictwem :) Warto jednak wyrobić sobie taki nawyk, by poświęcić trochę czasu na analizę, to zdecydowanie procentuje w przyszłości.
Lessons learned nawiązuje właśnie do takich praktyk. To angielskie stwierdzenie przyjęło się na tyle mocno, że praktycznie nie używamy polskich zamienników (bo i w sumie ciężko takie znaleźć- wyciąganie wniosków? a może bardziej nawiązując do agile retrospektywa?). No dobrze, tylko co to właściwie jest? Zacznijmy od obrazka
PMBOK (Project Management Body of Knowledge ) definiuje LL, jako podsumowanie wniosków, doświadczeń zdobytych w procesie realizacji projektu. Formalnie prowadzone sesje tradycyjnie odbywają się podczas zamknięcia projektu lub na ostatnim etapie zakończenia projektu. Jednak wnioski mogą zostać zidentyfikowane i udokumentowane w dowolnym momencie cyklu życia projektu. Istotą udokumentowania wyciągniętych wniosków jest dzielenie się i wykorzystywanie wiedzy uzyskanej z doświadczenia w celu:
- promowania i powtarzania pożądanych rezultatów
- zapobiegania nawrotom niepożądanych skutków.
Jako praktyka, działania te obejmują procesy niezbędne do identyfikacji, dokumentacji, zatwierdzania i rozpowszechniania wyciągniętych wniosków, a także określenie działań, które zostaną podjęte w celu ulepszenia procesu i zbudowania swoistej bazy wiedzy.
Niezależne badania wykazują jednak, że tylko co piąta firma zbiera doświadczenia z przeprowadzonych projektów, a mniej jak 10% wykorzystuje je do wprowadzania zmian. Na szczęście tendencja jest rosnąca, ale wciąż pozostaje wiele do zrobienia. Żyjemy w świecie "szybkich" projektów, rozwoju podejścia zwinnego i ograniczenia dokumentacji. Mało czasu poświęca się na budowanie bazy wiedzy. Nie dotyczy to tylko projektów, ale wielu innych zagadnień IT, jak chociażby zarządzania usługami. Jeżeli czytaliście "Projekt Feniks" , wiecie jak brak standaryzacji i udokumentowania procesów może wpłynąć na organizację. Myślę, że każdy z nas ma w zespole takiego Brenta, który całą wiedzę ma w głowie i jak go zabraknie to jest katastrofa :) Ale wracając do lessons learned, pierwszy krok to uwzględnienie takich spotkań po zakończeniu projektu, drugi to udokumentowanie ich przebiegu i wyciągniętych wniosków. To by była sytuacja idealna. Jeśli jednak działa tylko pierwszy element to już zawsze coś, gdyż zauważyłem że ważny jest także aspekt psychologiczny. Zespół spotykając się po zakończonych pracach mocniej integruje się i nabiera do siebie zaufania. Głównie w przypadku świętowania sukcesu, ale napotkane trudności też potrafią budować dobrą relację, jeżeli proces jest odpowiednio pokierowany. Podkreślenie sukcesu i satysfakcji z dobrze wykonanego zadania podnosi morale w kontekście kolejnych wyzwań, natomiast wypunktowanie problemów i wyjaśnienie sporów, niweluje powstawanie bariery przed przyszłą pracą z tym samym dostawcą.
Kto powinien uczestniczyć w takich spotkaniach? Najlepiej jak będzie to cały zespół projektowy, sponsorzy czy nawet zespół wspomagający, nie do końca związany ściśle z projektem. Ciekawe i warte odnotowania sugestie mogą napływać z każdego źródła. Ważne też, by uczestnicy czuli się swobodnie, nie bali się wytykać błędów i sami byli w stanie się do takich błędów przyznać. To działa też w drugą stronę, nie należy wstydzić się sukcesów i głośno o nich mówić :) Nawet jeżeli są to tylko pojedyncze kroki składające się na większą całość.
Nie ma jasnych reguł jak powinno przebiegać spotkanie w ramach lessons learned, ale podczas niego można spróbować odpowiedzieć sobie na poniższe pytania:
- Czy dostarczony produkt spełniał określone wymagania i cele projektu?
- Czy klient był zadowolony z produktu końcowego? Jeśli nie, dlaczego nie?
- Czy zostały utrzymane budżety kosztów? Jeśli nie, dlaczego nie?
- Czy harmonogram został spełniony? Jeśli nie, dlaczego nie?
- Czy zidentyfikowano i złagodzono ryzyko? Jeśli nie, dlaczego nie?
- Czy metodologia zarządzania projektami działa? Jeśli nie, dlaczego nie?
- Co można zrobić, aby usprawnić proces?
- Jakie wąskie gardła lub przeszkody były odczuwalne, które miały wpływ na projekt?
- Jakie procedury powinny zostać wdrożone w przyszłych projektach?
- Co można zrobić w przyszłych projektach, aby ułatwić osiągnięcie sukcesu?
- Jakie zmiany pomogłyby w przyspieszeniu przyszłych projektów przy jednoczesnym zwiększeniu komunikacji?
Jeżeli nasza organizacja jest już na pewnym etapie dojrzałości i ma świadomość wagi zbierania doświadczeń, możemy pokusić się o stosowanie "najlepszych praktyk":
- Uwzględnij wszystkie doświadczenia - wyciągnięte wnioski powinny czerpać zarówno z pozytywnych, jak i negatywnych doświadczeń.
- Działaj szybko - uzyskaj informacje zwrotne tak szybko, jak to możliwe, aby uniknąć zapominania o wyzwaniach stojących przed projektem.
- Dokumentuj - przechowuj wnioski wyciągnięte z całego projektu w centralnym repozytorium.
- Uczyń dostępnym - wykorzystaj zdobyte doświadczenia w innych projektach, udostępnij wyniki innym zespołom.
- Archiwizuj - wyciągnięte wnioski powinny być archiwizowane jako historyczne dane projektowe i włączane do zdobytych doświadczeń organizacji.
- Rozpowszechniaj - rozpowszechniaj wyciągnięte wnioski do społeczności zarządzającej projektem.
- Ponownie wykorzystuj - wykorzystaj doświadczenia zdobyte podczas poprzednich projektów, aby lepiej zarządzać bieżącymi projektami.
- Zaangażuj interesariuszy - zaangażuj wszystkich uczestników projektu i interesariuszy w proces uczenia się.
- Zabiegaj o opinie - przeprowadź ankietę postprojektową, aby uzyskać opinie na temat projektu od zespołu projektowego, klientów i interesariuszy dobrze zaznajomionych z zarządzaniem projektem.
- Zidentyfikuj wyciągnięte wnioski - analizuj zebrane informacje i buduj know-how dla przyszłych projektów.
I jeszcze na koniec modelowy schemat zarządzania wnioskami z doświadczeń*
* żródło: Strefa PMI, nr 12, marzec 2016
Ja sam jestem wielkim zwolennikiem przeprowadzania takich warsztatów i gorąco polecam je każdemu, kto ma styczność z projektami. Widzę w praktyce jak wiele to wnosi do zarządzania projektami, do niwelowania błędów i podkreślania mocnych stron. W kolejnych wpisach postaram się podać przykłady jak w fajny sposób można poprowadzić sesje lessons learned.
