Statystycznie niespełna 1/3 projektów kończy się sukcesem, ponad połowa boryka się ze znaczącymi trudnościami, a pozostałe kończą się porażką. W każdym z projektów pojawiają się wyzwania i problemy, z którymi uczestnicy projektów radzą sobie w lepszy lub gorszy sposób. Co zrobić żeby w następnym projekcie lepiej wykorzystać szansę lub uniknąć błędu?


wyniki projektów wykres
Rys. 1. Wyniki projektów
Źródło: The CHAOS Report, The Standish Group, 2015

Odpowiedź na to pytanie jest prosta: lessons learned, czyli wnioski z doświadczeń. Hasło znane, ale czy wykorzystane? Zebranie i udokumentowanie LL, skategoryzowanie i udostępnianie ich dla szerszego grona zainteresowanych znacząco ułatwia wdrożenie usprawnień w istniejących procesach, komunikacji czy chociażby dokumentacji projektowej. To natomiast bez wątpienia ma pozytywny wpływ na kolejne projekty prowadzone w organizacji. 

Niestety, wyniki audytów przeprowadzonych przez naszą firmę ujawniają gorzką prawdę, że tylko co piąta organizacja systematycznie zbiera wnioski z doświadczeń, a mniej niż 10% wykorzystuje je do wprowadzania zmian. W praktyce w większości organizacji doświadczenia projektowe funkcjonują i są rozpowszechniane wyłącznie w sposób nieformalny. Co jednak, jeśli w organizacji zabraknie tych nieformalnych źródeł informacji ukrytych na dyskach twardych lub w głowach pracowników? Z pewnością skutecznym rozwiązaniem mogłaby być dobrze zarządzana centralna baza wiedzy zbudowana na doświadczeniu osób na co dzień pracujących przy projektach.

Druga strona medalu

Ludzie w tzw. „górnych widełkach”, wyświetlają się na czerwono w różnych raportach, zwłaszcza w okresach redukcji zatrudnienia. Dlatego, gdy zależy Ci na stabilności zatrudnienia, nie warto „wyciskać ostatniego grosza”. Myślę, że ta świadomość będzie rosła wśród programistów oraz innych osób technicznych w miarę przechodzenia z rynku pracownika na rynek pracodawcy. Jednocześnie, osoba zatrudniająca również odgrywa tu ważną rolę, jeżeli przekonująco wytłumaczy kandydatowi, dlaczego agresywne maksymalizowanie przez niego wynagrodzenia, może działać na jego niekorzyść w długim terminie. Oczywiście wszystko jest kwestią indywidualnych priorytetów kandydata, natomiast taka argumentacja nie powinna zostać zignorowana.

Zbieranie lessons learned

Pozyskiwanie wspomnianej wiedzy i doświadczeń można przeprowadzić na wiele sposobów – podczas spotkań, warsztatowej burzy mózgów, wywiadów, w formie ankiet czy raportów. Przy czym należy pamiętać, że wnioski z doświadczeń najlepiej jest spisać tuż po wystąpieniu nietypowej sytuacji, a także niezwłocznie po rozwiązaniu problemu. Dzięki temu informacje są świeże i nieskażone długotrwałymi rozmyślaniami z gatunku „jak można to było zrobić lepiej” albo „co by było, gdyby…”. Wnioski zebrane „na gorąco” są najbardziej wartościowe i stanowią idealny materiał pod budowę rejestru doświadczeń projektowych. Taki rejestr to z kolei podstawa do stworzenia jednego zintegrowanego raportu doświadczeń po zakończeniu projektu. Gotowy raport wystarczy wysłać jako podsumowanie po projekcie do biura zarządzania projektami (PMO), które na podstawie informacji zbieranych z różnych projektów może utworzyć jeden ustandaryzowany „dokument” dostępny dla wszystkich. Pracownicy PMO muszą jednak pamiętać, żeby nie doprowadzić do przerostu formy nad treścią i nie wprowadzać rozbudowanych formularzy, które tak łatwo potrafią zniechęcić już na wstępie.

Kategoryzacja doświadczeń

Zadaniem PMO po otrzymaniu raportów jest właściwe skatalogowanie i utworzenie centralnej bazy lessons learned z podziałem na kategorie. Kategorie oraz forma przechowywania powinny w jak największym stopniu ułatwiać dotarcie do potrzebnych informacji. Zaobserwowane wnioski mogą być zatem podzielone zgodnie z obszarem występowania zdarzenia, według rodzaju projektu czy zgodnie z fazami projektu. Stosowanie kategoryzacji jest bardzo praktycznym rozwiązaniem, z którego najlepiej nie rezygnować. Możemy je natomiast uzupełnić odpowiednim tagowaniem, o ile tylko nasze narzędzie na to pozwala i umożliwia sprawne wyszukiwanie haseł.

Rozpowszechnianie wiedzy

Baza wniosków z doświadczeń powinna służyć za powszechne źródło wiedzy dla kierowników projektów i innych zainteresowanych osób. Dlatego nie wystarczy, żeby była uporządkowana i funkcjonalna, ale musi być również ogólnodostępna. A sposobów rozpowszechniania wiedzy jest wiele. 

Pierwszym są spotkania lessons learned, na których w trakcie lub po projekcie omawia się wsad do bazy wiedzy. Następną formą jest bezpośredni dostęp do bazy, gdzie znajdują się dotychczas zgromadzone informacje o pozytywnych oraz negatywnych doświadczeniach wraz z wnioskami i rekomendacją, jak rozwiązać dany problem. Trzecią praktykowaną metodą jest bezpośredni kontakt kierowników projektów, na przykład w formie spotkań czy seminariów organizowanych co najmniej raz na kwartał. W trakcie takich spotkań istnieje nie tylko możliwość wymiany doświadczeń, ale również omówienia napotkanych problemów i sposobów ich rozwiązania. Nierzadko w wyniku dyskusji pojawiają się także pomysły na usprawnienia poszczególnych procesów, a nawet całego systemu. Innym sposobem na rozpowszechnianie najciekawszych lub najczęstszych przypadków występujących w projektach (wraz z cennymi wskazówkami!) może być także ich systematyczne publikowanie w formie graficznej lub w postaci krótkiej historyjki w newsletterze bądź w innej publikacji wewnątrzorganizacyjnej. 

Ważnym elementem, mającym nie tylko charakter edukacyjny, ale również celebracyjny, są konferencje wewnętrzne. Co ciekawe, taka konferencja wcale nie musi się ograniczać do kierowników projektów. Takie spotkania w gronie pracowników dobrze motywują do działania, prezentując pozytywny obraz pracy projektowej. Jest to bowiem okazja do pokazania działań różnych działów, zaprezentowania nowych trendów w zarządzaniu projektami, docenienia sukcesów i nagrodzenia, a także przedstawienia planów na przyszłość.

Wdrożenie lessons learned

Nie zapominajmy, że baza wiedzy nie służy jedynie kierownikom projektów, ale całej organizacji. Analiza częstotliwości występowania danych zagadnień oraz ich wpływu na projekt, program czy portfel projektów prowadzi do zapobiegania i eliminowania błędów. Bo przecież zbieranie wniosków z doświadczeń nie ma na celu tylko i wyłącznie zwiększania wiedzy organizacji (popularny błąd – wiele firm po prostu kolekcjonuje wiedzę, ale jej odpowiednio nie wykorzystuje), ale także sprawiania, żeby nie była ona już potrzebna. Przykładem niech będzie często spotykany problem – trudności z obsługą Karty Projektu. W jednej z firm funkcjonowało podejście, w którym lessons learned były jedynie zbierane i rozpowszechniane. W takiej sytuacji wiele osób opisywało swoje doświadczenia z dokumentem, sugerowało, jak należy go wypełniać, kiedy i jakie dane wprowadzać, itd. W efekcie inni uczyli się go obsługiwać. Natomiast właściwym podejściem powinna być reakcja na powtarzający się komunikat z organizacji: „ten dokument jest skomplikowany, nie umiemy go obsługiwać, uprośćcie go”. Lessons learned mają być przede wszystkim systemem ostrzegania o marnotrawstwie w organizacji, o nieoptymalnych procesach i dokumentach, w drugiej kolejności mogą służyć do wzajemnego rozwoju pracowników. Dlatego PMO powinno nadawać wagi poszczególnym zagadnieniom i utworzyć dokument z wnioskami i sugestiami, na podstawie którego zarząd lub inne ciało decyzyjne będzie podejmować decyzje o zmianach w metodyce zarządzania projektami. W ten sposób usprawniona zostanie dokumentacja, listy kontrolne, metody motywowania czy formy komunikacji. Decyzje zarządu mogą dotyczyć również innych zmian organizacyjnych, niekoniecznie związanych z projektami, a dotyczących poszczególnych jednostek w organizacji. Tak zorganizowany i przeprowadzony proces jest bardzo przydatną częścią zarządzania jakością poprzez niwelowanie błędów oraz generowanie nowych rozwiązań dla ciągłego rozwoju organizacji. Warto systematycznie wdrażać wnioski z doświadczeń do metodyki i narzędzi pracy kierownika projektu i zespołów projektowych, aby w ten sposób zapewnić „automatyzację” ich wykorzystania. 

Pełen schemat przykładowego procesu zarządzania wnioskami z doświadczeń został przedstawiony na rysunku 2. 

zarządzanie doświadczeniami schemat
Rys. 2. Schemat przykładowego zarządzania wnioskami z doświadczeń
Źródło: opracowanie własne

Na podstawie doświadczeń firmy WHITECOM Project Experience jako kluczowe elementy wdrożenia wniosków z doświadczeń w organizacji możemy wskazać: 

  1. Zbieranie i przetwarzanie wniosków z doświadczeń to systematyczny proces w organizacji.
  2. PMO musi zapewnić odpowiednie narzędzia ułatwiające zbieranie i korzystanie z doświadczeń.
  3. Wnioski z doświadczeń powinny być wykorzystywane do wprowadzania zmian zarówno w metodyce zarządzania projektami, jak i w innych obszarach funkcjonowania firmy.

Zarządzanie lessons learned będzie przynosić efekty szczególnie wtedy, kiedy stanie się częścią kultury organizacyjnej. Wówczas mechanizm zarządzania LL pozwoli na rozpowszechnianie i uwzględnianie raz zdobytej wiedzy w planowaniu i realizacji projektów, a także w innych obszarach działalności organizacji. Zatem może jednak warto poświęcić parę chwil na spisanie swoich przemyśleń dla dobra „przyszłych pokoleń projektowych”.