Wprowadzenie

Zarządzanie projektami jest praktyczną dziedziną zarządzania, która w ostatnich latach zyskuje coraz większe znaczenie w działalności biznesowej firm i organizacji. Konieczność sprawnej i terminowej realizacji złożonych i w dużej mierze niepowtarzalnych przedsięwzięć sprawiła, że projekty i podejście projektowe na stałe zagościły w bieżącej aktywności przedsiębiorstw.

Wraz z kolejnymi projektami wzrastają zasoby doświadczeń w firmie. Niestety, nierzadko zdarza się, że doświadczenia te rozpraszają się wraz z zakończeniem projektu i rozwiązaniem zespołu projektowego. Kluczowa, nowa wiedza zdobyta lub wytworzona w czasie realizacji projektu nie jest wykorzystywana po jego zakończeniu. Wprawdzie firmy coraz częściej są świadome tego, że coś w ten sposób tracą, jednakże tylko nieliczne nauczyły się już zachowywać i wykorzystywać wiedzę projektową. Celem niniejszego artykułu jest zaprezentowanie wybranych technik zachowywania wiedzy projektowej i powtórnego jej wykorzystywania. Autor, po szerszym nakreśleniu problematyki zarządzania wiedzą projektową i wyzwań zeń wynikających, przedstawia wybrane przykłady dobrych praktyk zarządzania wiedzą w projektach. W drugiej części artykułu skupia się na szczegółowym, bardzo pragmatycznym zaprezentowaniu najczęściej stosowanych technik przekazywania i zachowywania wiedzy projektowej. Dzieli je na dwa rodzaje: wykorzystywane na bieżąco w trakcie trwania projektu (rejestr doświadczeń projektowych) oraz stosowane punktowo na zakończenie projektu lub w kamieniach milowych (analiza ex post, after action review).

Kluczowym wnioskiem płynącym z artykułu jest podkreślenie roli wykorzystywania wiedzy i nieustannego uczenia się organizacji w budowaniu i utrzymywaniu przewagi konkurencyjnej.

Wyzwania dla zarządzania wiedzą w projektach

Zarządzanie projektami jest praktyczną dziedziną zarządzania, która w ostatnich latach zyskuje coraz większe znaczenie w działalności biznesowej firm i organizacji. Konieczność sprawnej i terminowej realizacji złożonych i w dużej mierze niepowtarzalnych przedsięwzięć sprawiła, że projekty i podejście projektowe na stałe zagościły w bieżącej aktywności przedsiębiorstw.

Wraz z kolejnymi projektami wzrastają zasoby doświadczeń w firmie. Niestety, nierzadko zdarza się, że doświadczenia te rozpraszają się wraz z zakończeniem projektu i rozwiązaniem zespołu projektowego. Kluczowa, nowa wiedza zdobyta lub wytworzona w czasie realizacji projektu nie jest wykorzystywana po jego zakończeniu. Wprawdzie firmy coraz częściej są świadome tego, że coś w ten sposób tracą, jednakże tylko nieliczne nauczyły się już zachowywać i wykorzystywać wiedzę projektową. Zarządzanie projektami, zgodnie z definicją Project Management Institute, polega na zastosowaniu wiedzy, umiejętności, narzędzi i technik w działaniach projektu w celu spełnienia jego wymagań¹. Specyfika realizacji projektów i cechy wyróżniające je spośród innych działań przedsiębiorstwa stawiają specyficzne wymagania odnośnie wiedzy projektowej, czyli wiedzy związanej z realizacją projektów (tabela 1).

Tabela 1. Specyfika wiedzy w projektach

Cechy szczególne projektów

Konsekwencje dla wiedzy projektowej

Projekty są złożonymi i niepowtarzalnymi przedsięwzięciami. Projekty są przedsięwzięciami ograniczonymi w czasie, o jasno określonym początku i końcu. Projekty są przedsięwzięciami realizowanymi przez zespół wysoko wykwalifikowanych specjalistów z różnych obszarów organizacji. Praca zespołu projektowego ma charakter zadaniowy - nastawiony na realizację celu projektu.

Realizacja projektów wymaga zaawansowanej wiedzy interdyscyplinarnej. Wiedza ta musi być opisana na odpowiednim poziomie szczegółowości, aby zapewnić jej transferowalność między zróżnicowanymi projektami. Wiedza projektowa, będąca w posiadaniu zespołu projektowego, ulega rozproszeniu po zrealizowaniu. celów projektu i rozwiązaniu zespołu. Podstawowym obiektem procesów zarządzania wiedzą powinien być zespół projektowy.

Źródło: P. Wyrozębski, Zarządzanie wiedzą w projektach - przedmiot i specyfika, Letnia Szkoła Zarządzania, TNOiK, Toruń 2008

Doświadczenia projektowe (lessons learnt, lessons learned) oraz procesy i techniki związane z ich pozyskiwaniem, oceną i upowszechnianiem są elementami zarządzania wiedzą projektową, doskonale wpisującymi się w przedstawioną powyżej specyfikę realizacji projektów.

Doświadczenia projektowe można zdefiniować jako nową wiedzę, doświadczenie, spostrzeżenia i wnioski gromadzone przez zespół projektowy i interesariuszy projektu, dotyczące obszarów jego realizacji. Z punktu widzenia specyfiki doświadczeń projektowych można wyróżnić doświadczenia projektowe zarządcze (odnoszące się do obszarów procesów zarządczych projektu) oraz doświadczenia projektowe techniczne lub specjalistyczne (odnoszące się do specjalistycznych, technicznych bądź technologicznych aspektów projektu). Pozyskiwanie doświadczeń projektowych niesie za sobą bardzo dużą wartość dla środowiska projektowego oraz dla całej organizacji.

Po pierwsze, jeżeli realizacja projektów wymaga wykorzystania zaawansowanej wiedzy interdyscyplinarnej, to analiza doświadczeń projektowych pozwala jednoznacznie wskazać dziedziny tej wiedzy, ocenić niedostatki w wiedzy zespołu projektowego oraz określić obszary, w których wiedza ta powinna być uzupełniona (np. poprzez dodatkowe szkolenia lub pozyskanie dodatkowych ekspertów do zespołu).

Po drugie, gromadzenie doświadczeń projektowych pozwala zachować ciągłość wiedzy projektowej w organizacji. Zakończenie prac w projekcie - czy to na skutek osiągnięcia zamierzonych celów, czy w efekcie utraty uzasadnienia biznesowego - powoduje uwolnienie zaangażowanych w jego realizację zasobów, w tym rozwiązanie zespołu projektowego. Zorganizowane zamknięcie projektu, połączone z jego podsumowaniem i analizą doświadczeń projektowych, zapobiega rozproszeniu nabytej wiedzy, która zanika wraz z odejściem pracowników powracających do swoich macierzystych pionów, działów lub innych organizacji.

Po trzecie, unikalność projektów sprawia, iż ogólnodostępne i uniwersalne źródła wiedzy projektowej mogą zostać odebrane jako zbyt ogólne i niedostosowane do specyfiki realizacji projektów w danym otoczeniu biznesowym. Gromadzenie firmowych doświadczeń projektowych umożliwia budowanie własnej, autorskiej bazy wiedzy, która w pełni odzwierciedla charakter i cechy szczególne realizacji projektów w danej branży, w firmie o konkretnej strukturze, kulturze organizacyjnej i danym typie projektów. Poszczególne doświadczenia projektowe stanowią szczegółowe i wycinkowe elementy wiedzy projektowej, jednakże w dużej liczbie umożliwiają wysnuwanie ogólnych wniosków dotyczących kompleksowego podejścia do zarządzania projektami.

Po czwarte, realizacja projektów wiąże się ze stosunkowo wysokim poziomem ryzyka związanym np. z poziomem złożoności projektów, zaangażowanych zasobów, strategicznego znaczenia dla biznesu. Gromadzenie doświadczeń projektowych uruchamia procesy uczenia się, a przez to jest czynnikiem ograniczającym ryzyko projektów. Efekt ten można osiągnąć poprzez weryfikację zidentyfikowanego ryzyka, jego wystąpienia lub niewystąpienia w trakcie realizacji projektu, ocenę przyjętych strategii i działań zapobiegawczych, weryfikację założeń przyjętych w procesie planowania projektu.

Podsumowując powyższe korzyści, doświadczenia projektowe można uznać za elementy niezwykle cenne i wartościowe dla podnoszenia sprawności i jakości realizacji projektów. Co ciekawe, fakt ten został dostrzeżony także przez armie wielu krajów świata, które w bardzo rozległy i wyczerpujący sposób korzystają z doświadczeń zdobywanych przez jednostki wojskowe, jednostki specjalne i milicyjne podczas działań wojennych i misji pokojowych.

Armia Stanów Zjednoczonych Ameryki posiada najbardziej rozbudowaną bazę wiedzy z doświadczeń związanych z realizacją operacji wojskowych. Działalność ta w sposób zorganizowany prowadzona jest od czasów konfliktu koreańskiego w latach 60. XX wieku.Specjalna jednostka powołana do tego celu nosi nazwę CALL - Center for Army Lessons Learned².

Od roku 2001 w Armii USA działa również system zarządzania wiedzą Army Knowledge Management, który stanowi realizację strategii Departamentu Obrony Narodowej USA w zakresie zdobywania kluczowej przewagi na polu bitwy poprzez wykorzystanie wiedzy swoich jednostek. System zapewniający dostępność wiedzy i kluczowych informacji dla jednostek operujących w terenie nosi nazwę BCKS (Army's Battle Command Knowledge System) i podczas ostatniej wojny w Iraku zdecydowanie dowiódł swojej wartości³.

Przykład działania BCKS ilustruje rzeczywista sytuacja z okupowanego Iraku dotycząca min-pułapek, które powodują ponad połowę strat żołnierzy amerykańskich. W opisanej sytuacji iraccy rebelianci zainstalowali minę-pułpkę za plakatem z antyamerykańskimi hasłami. Patrolujący żołnierze zauważyli plakat wyglądający nieco inaczej niż inne i zgłosili sytuację do BCKS. Po przeanalizowaniu online obserwacji i faktycznym potwierdzeniu zagrożenia informacja o nowym typie min-pułapek została rozesłana do wszystkich oddziałów za pomocą BCKS ostrzegając o niebezpieczeństwie. Sytuacja ta jest tylko jedną z wielu, które w bardzo obrazowy sposób uzasadniają wartość wiedzy w taktyce i operacjach wojskowych⁴.

Podobne przedsięwzięcia nakierowane na doświadczenia zdobywane na polu walki podejmuje wiele krajów, między innymi Australia (CAL, Center for Army Lessons)⁵, Kanada (ALLC, Army Lessons Learned Center)⁶, Francja w Algierii, Izrael, jak również Związek Radziecki w trakcie II Wojny Światowej (Sekcja Doświadczeń Bojowych Dywizji Historycznej Armii Czerwonej)⁷.

Bardzo interesującym przykładem zbioru doświadczeń projektowych jest zbiór zasad dla kierowników projektów, które zostały zebrane przez J. Maddena, emerytowanego zastępcę dyrektora z Dyrektoriatu Przedsięwzięć Lotniczych w Centrum Lotów Kosmicznych Goddard NASA. Pracując w NASA przez prawie 40 lat (od 1959 do 1995 roku), uczestniczył on w większości podejmowanych przedsięwzięć. Wieloletnie doświadczenie pozwoliło mu stworzyć listę dobrych rad (100 Lessons Learned for Project Managers), o których powinien pamiętać kierownik projektu. Wybrane doświadczenia projektowe prezentuje poniższa tabela:

Tabela 2. 100 zasad postępowania dla kierownika projektów według NASA (wybór)

[#01] Kierownik projektu powinien chociaż raz w trakcie trwania projektu odwiedzić każdego, kto wykonuje jakąś część pracy dla niego. Ludzie lubią wiedzieć, że kogoś interesuje to, co robią, a odwiedziny w miejscu pracy są tego najlepszym dowodem.

[#04] Z kimkolwiek współpracujesz - współpracuj uczciwie. Kosmos wcale nie jest taki duży, jak myślisz. Będziesz zdziwiony, jak często przyjdzie ci pracować z tymi samymi ludźmi. Lepiej niech czują do ciebie szacunek niż urazę.

[#20] Menedżerowie, którzy polegają na „papierologii” w śledzeniu postępów, są skazani na porażkę.

[#62] Niestosowanie technologii i narzędzi IT jest błędem, ale zapominanie, że mają one tylko wspierać myślenie, a nie je zastępować, jest nawet większym błędem.

[#66] Nigdy nie zakładaj, że znasz powody decyzji lub działań wyższego kierownictwa. Jeżeli uważasz, że powinieneś je znać, zapytaj o nie. Zdziwisz się nie raz, gdy usłyszysz odpowiedzi.

[#90] Zalążki problemów tworzą się wcześnie. Analiza najgorszych projektów oraz pojawiających się problemów wskazuje, że porażki były do przewidzenia od początku.

[#96] Doświadczenie jest dobre, ale testowanie lepsze. Wiedza o tym, że coś powinno działać nigdy nie zastąpi jej rzeczywistego potwierdzenia.

[#127] Zbyt wielu ludzi w centrali wierzy, że jeżeli codziennie dajesz koniowi coraz mniej jeść, to pewnego dnia nie będzie potrzebował jedzenia wcale. Próbują przełożyć to na projekty, które w rzeczywistości kończą tak samo martwe jak te konie.

[#128] Kierownik projektu, który jest najmądrzejszym człowiekiem w zespole zdecydowanie przeprowadził fatalną rekrutację.

Źródło: J. Madden, 100 Lessons Learned for Project Managers, NASA, Academy of Program/Project & Engineering Leadership, http://appel.nasa.gov, [07.04.2008]

Zbiory doświadczeń projektowych tworzone są przez firmy z wielu branż i sektorów, m.in.: Lockheed Martin (przemysł lotniczy i obronny), DHL Express (usługi logistyczne i kurierskie), Technology Group International (branża IT). Poniżej przedstawiono wybór doświadczeń z projektów zakupu i wdrożeń oprogramowania firmy TGI.

Tabela 3. Doświadczenia projektowe dla projektów wyboru oprogramowania - Technology Group International (wybór)

1. Zrozum znaczenie projektu i zakres pracy do wykonania i na tej podstawie wyznacz realistyczne oczekiwania wobec zespołu projektowego.

2. Na starcie projektu spotkaj się z kluczowymi decydentami, aby zapewnić, że zespół projektowy rozumie miejsce projektu w strategii firmy.

3. Pozyskaj sponsora dla projektu i rozsądnie korzystaj z zasobów.

4. Wybierz kierownika projektu w celu pokierowania wyborem oprogramowania i pracą wdrożeniową.

5. Wybierz najlepszych pracowników do zespołu projektowego.

6. Uzyskaj realistyczny i osiągalny budżet projektu poprzez rozpoznanie wszystkich kosztów systemu.

7. Wyznacz realistyczne oczekiwania wobec organizacji i pamiętaj, że żadne oprogramowanie nie uleczy problemów, które w organizacji narastały przez lata.

8. Uważnie oceń wymierne i niewymierne korzyści z projektu. Wylicz realistyczne wskaźniki zwrotów bazujące na tych korzyściach.

9. Przygotuj solidne uzasadnienie biznesowe, wsparte drobiazgową analizą finansową.

10. Przed definiowaniem wymagań wobec nowego systemu rozpoznaj procesy biznesowe działające w organizacji.

Źródło: Software Selection Lessons Learned, Technology Group International, 2004, www.techgroupintl.com.

Techniki i narzędzia gromadzenia doświadczeń projektowych

Techniki i narzędzia gromadzenia doświadczeń projektowych można podzielić na dwa rodzaje: wykorzystywane na bieżąco w trakcie trwania projektu (rejestr doświadczeń projektowych) oraz stosowane punktowo na zakończenie projektu lub w kamieniach milowych (analiza ex post, after action review).

Rejestr doświadczeń projektowych - LLL (lessons learned log)
Może występować zarówno w formie papierowej (formularz), jak i w formie elektronicznej (np. forum intranetowe, blog, baza doświadczeń projektowych). Istotą prowadzenia rejestru jest zapisywanie gromadzonych doświadczeń i wniosków na bieżąco w trakcie trwania projektu, stąd często LLL porównywane jest do swoistego pamiętnika kierownika projektu. Prowadzenie rejestru jest szczególnie zalecane w przypadku długotrwałych projektów, o czasie realizacji powyżej 6 miesięcy (ale nie więcej niż powyżej 12 miesięcy). Bieżące notowanie ważniejszych informacji zapobiega zapominaniu i pomijaniu doświadczeń z początkowych faz realizacji projektu, które mogą zostać ujęte w podsumowaniu przeprowadzanym zazwyczaj po jego ukończeniu. Gdy projekt trwa rok, a dodatkowo w tym czasie skład zespołu projektowego ulega dużej fluktuacji, rejestr pozwala zgromadzić i zachować całość doświadczeń projektowych z jego przebiegu.

W rejestrze odnotowywane powinny być następujące informacje:
doświadczenia projektowe:

• pozytywne, które wpłynęły korzystnie na projekt i są pożądane w przyszłości,
• negatywne, które wpłynęły niekorzystnie na projekt i należy podjąć w przyszłości kroki w celu ich uniknięcia,
• opis doświadczenia i jego kontekst oraz wnioski na przyszłość (Jak uniknąć? Jak wzmocnić?),
• zakres zastosowania wniosków (Jakiego obszaru projektu one dotyczą? Gdzie mogą okazać się jeszcze pomocne? Komu przekazać te informacje? itp.).

Osoby prowadzące rejestr doświadczeń projektowych uzupełniając LLL, mogą kierować się poniższymi kategoriami:

• zarządzanie projektem i tworzenie produktów projektu (Co poszło dobrze? Co poszło źle? O czym zapomniano?),
• niespodziewane wydarzenia, ryzyka, zmiany (Jak wpłynęły na przebieg projektu?),
• relacje ze współpracownikami i podwykonawcami (Dlaczego były dobre? Dlaczego były złe? Dlaczego obojętne?),
• techniki, narzędzia, pomysły i innowacje (które okazały się pomocne w projekcie)⁸.

Propozycja formularza rejestru doświadczeń projektowych przedstawiona jest w tabeli 4.

Tabela 4. Przykładowy rejestr doświadczeń projektowych

Lp.	Data	Obszar / Kategoria	Tytuł	Opis doświadczenia	Wnioski i zalecane działanie
1	22/03/2008	Komunikacja	Brak strony WWW	Wiele zapytań uczestników konferencji dotyczyło podobnych kwestii, na które można było odpowiedzieć jednym standardowym mailem. Rutynowe odpisywanie na emaile angażowało dużo czasu kierownika projektu.	Stworzenie strony WWW oraz FAQ pozwoli usprawnić komunikację z uczestnikami i oszczędzi czas.
2	25/03/2008	Project Manager	Odwołanie do dokumentacji z poprzedniego projektu	Odwołanie się do doświadczeń projektowych i dokumentacji z podobnego projektu realizowanego w ubiegłym roku pozwoliło szybko wdrożyć kierownika w obecnie realizowane projekty.	Dostęp i promowanie bazy doświadczeń wśród zespołów projektowych, szczególnie na etapie definiowania i planowania projektów.
3	26/03/2008	Zasoby projektu	Niedostateczne zasoby	Pomimo ustnej deklaracji kierownika pionu IT, nie udostępniono zasobów programistów w projekcie. Projekt korzystał z zasobów zewnętrznych, co zwiększyło jego koszt o 5 procent.	W kolejnych projektach żądać pisemnego potwierdzenia dostępności zasobów. Zaangażować sponsora projektu w razie potrzeb.

Źródło: opracowanie własne

Techniczna konstrukcja rejestru doświadczeń projektowych może według potrzeb uwzględniać również dane tworzące rozbudowaną metryczkę doświadczenia m.in. informacje na temat: nazwy projektu (programu), fazy projektu, której doświadczenie dotyczy, imienia i nazwiska autora, jego stanowiska (roli w projekcie), wpływu zagadnienia na cele projektu, oceny wartości doświadczenia, jej priorytetu i innych, które zespół uzna za istotne.

Rejestr doświadczeń projektowych jest prostym, skutecznym i łatwym do zastosowania narzędziem wspierającym ich gromadzenie. Chociaż jego wartość jest trudna do przecenienia, posiada także pewne słabe strony, które należy mięć na uwadze.

Po pierwsze, zespół projektowy powinien mieć jasną wizję korzyści, które przyniesie korzystanie z tego narzędzia. W przeciwnym wypadku zostanie ono potraktowane wyłącznie jako jeszcze jedna bezużyteczna i biurokratyczna fanaberia kierownika projektu. Brak zrozumienia i zaangażowania w prowadzenie LLL spowoduje, że wpisy nie będą uzupełniane lub ich faktyczna wartość będzie niska.

Po drugie, z czasem zespół projektowy czy organizacja zgromadzi znaczną liczbę doświadczeń, o różnej wartości, jakości i poziomie szczegółowości. W gąszczu wpisów problemem staje się właściwa ich organizacja i zapewnienie sprawnego mechanizmu wyszukiwania pożądanych informacji. Wskazany problem jest szerszy i dotyczy de facto wszystkich dużych zbiorów, baz wiedzy i hurtowni danych w organizacjach. Jego rozwiązaniem może być przemyślana kategoryzacja doświadczeń projektowych, jasne zasady opisu doświadczeń, okresowa ocena i weryfikacja wpisów oraz zastosowanie informatycznych narzędzi wspierających wyszukiwanie informacji (wyszukiwarki internetowe, indeksowanie, data mining i inne).

Prowadzone na bieżąco rejestry doświadczeń projektowych mogą zostać wykorzystane do sporządzenia jednego, zintegrowanego raportu doświadczeń projektowych, przygotowywanego przez cały zespół projektowy pod koniec projektu lub w ważnych kamieniach milowych.

Technika spotkań podsumowujących projekt
Sposobem, który umożliwia gromadzenie i ocenę doświadczeń projektowych w danych momentach projektu, jest technika spotkań podsumowujących projekt (lessons learned meetings, after action review - AAR, debriefing session)⁹. Polega ona na kompleksowej analizie projektu (lub jego fazy, etapu) z punktu widzenia wiedzy i doświadczeń zdobytych przez zespół projektowy. Podobnie jak w przypadku całego zagadnienia dotyczącego gromadzenia doświadczeń projektowych, technika spotkań podsumowujących projekt ma swoje korzenie również w dziedzinie taktyki prowadzenia działań bojowych¹⁰.

Technika spotkań podsumowujących projekt przebiega w trzech etapach:

• przygotowanie do spotkania,
• realizacja spotkania,
• podsumowanie i przygotowanie raportu doświadczeń projektowych.

Przygotowanie do spotkania powinno uwzględniać:

• wybór prowadzącego spotkanie - odpowiedzialnego za cały proces,
• wybór uczestników i przesłanie informacji o celu, miejscu i terminie spotkania,
• wstępną analizę realizacji projektu (dokumentacja zarządcza: dokument inicjujący projekt, plany, harmonogramy projektu, dokumentacja przeglądów jakości i inne),
• krytyczny przegląd indywidualnych rejestrów doświadczeń projektowych,
• przeprowadzenie i opracowanie wyników ankiety podsumowującej projekt,
• przygotowanie agendy spotkania podsumowującego projekt.

Generalną i dobrą praktyką jest powierzenie przeprowadzenia takiego spotkania osobie niezależnej lub o wysokim poziomie zaufania wśród zespołu. Warunek ten powinien zostać spełniony, aby zapewnić swobodę wypowiedzi, otwartość i chęć współpracy wśród uczestników spotkania. Dodatkowo podsumowanie takiego spotkania, w formie raportu streszczającego projekt (ang. lessons learned report), będzie w ten sposób wartościowe i bezstronne, a wysnute wnioski nakierowane na problem, a nie na osoby i stanowiska. Osoba prowadząca spotkanie powinna mieć też na uwadze następujące zasady:

• podczas spotkania pozbądź się jakichkolwiek uprzedzeń,
• zachęcaj wszystkich do dzielenia się komentarzami,
• nie pozwól na ataki personalne,
• skoncentruj się na procesie nauki i ciągłym doskonaleniu,
• pozostań w cieniu, pozwól innym dochodzić do wniosków, niż samemu je proponować¹¹.

W celu spojrzenia na obszary projektu, przedyskutowania ich z różnych punktów widzenia oraz uwzględnienia różnych wniosków, należy zapewnić udział w zebraniu zróżnicowanego grona dyskutantów. Zaproszenie do udziału w spotkaniu powinno uwzględniać przynajmniej osoby pełniące główne role w projekcie, tj.: kierownika projektu, sponsora projektu i członków komitetu sterującego, członków zespołu projektowego (core team), przedstawicieli funkcji i innych menedżerów, pracowników silnie zaangażowanych w realizację projektu, głównych dostawców i użytkowników oraz osób zaproszonych na prośbę wyższego kierownictwa. Liczba zaproszonych gości nie powinna utrudniać sprawnego przeprowadzenia spotkania. Jeżeli jest to konieczne, spotkania podsumowujące projekt można przeprowadzić w turach, z poszczególnymi grupami interesariuszy.

Wstępna analiza realizacji projektu ma przede wszystkim na celu dostarczenie niezbędnych informacji na temat celów projektu, przygotowania do realizacji, procesów planowania, organizacji wykonawstwa, realizacji projektu i odchyleń pojawiających się w jego trakcie. Szczegółowa analiza dokumentacji powinna objąć: organizację zespołu projektowego, dokumentację zakresu projektu, wymagania biznesowe, plan projektu, raporty z kamieni milowych, minutki, rejestr ryzyk, rejestr zagadnień projektowych, rejestry zmian. Analiza może zostać powiązana z wstępnymi wywiadami z głównymi interesariuszami projektu.

Przegląd rejestrów doświadczeń projektowych ma na celu odświeżenie zidentyfikowanych uprzednio doświadczeń i ocenę ich przydatności z punktu widzenia innych projektów i całej firmy. W przypadku długotrwałych projektów przegląd rejestru doświadczeń pozwoli odwołać się do doświadczeń także z wczesnych etapów projektu. LLL stanowi bardzo wartościowe zasilenie dyskusji podczas spotkania podsumowującego projekt.

Opcjonalne przeprowadzenie ankiety umożliwi zdobycie anonimowych ocen i uwag na temat projektu, które nie zostałyby prawdopodobnie zgłoszone otwarcie w dyskusji, a mogą stanowić punkt wyjścia lub dodatkowe wsparcie podczas spotkania. Przykładowe pytania ankiety przedstawione zostały w poniższej tabeli.

Tabela 5. Ankieta podsumowująca projekt - fragment
Część A. Ogólne zagadnienia programowe i komunikacja

1. Cele projektu były zdefiniowane jasno i klarownie
Zdecydowanie się zgadzam	Raczej się zgadzam	Raczej się nie zgadzam	Zdecydowanie się nie zgadzam
2. Cele i oczekiwania odnośnie mojego udziału były dobrze określone
Zdecydowanie się zgadzam	Raczej się zgadzam	Raczej się nie zgadzam	Zdecydowanie się nie zgadzam
3. Uważam, że dobrze spełniłem moją rolę w projekcie
Zdecydowanie się zgadzam	Raczej się zgadzam	Raczej się nie zgadzam	Zdecydowanie się nie zgadzam
Uważam, że mój udział w podejmowanych decyzjach był odpowiedni
Zdecydowanie się zgadzam	Raczej się zgadzam	Raczej się nie zgadzam	Zdecydowanie się nie zgadzam

Źródło: opracowanie własne

Spotkanie podsumowujące projekt powinno mieć dynamiczny, warsztatowy charakter, nastawiony na zaktywizowanie uczestników do wskazywania i dzielenia się doświadczeniami projektowymi. W części organizacyjnej należy przede wszystkim przedstawić cel spotkania, czyli wspólną naukę i wyciągnięcie wniosków dla kolejnych projektów. Ważną kwestią jest zapewnienie uczestników o poufnym charakterze spotkania. Dyskutanci powinni wspólnie zaakceptować treść i formę informacji udostępnianych na zewnątrz, czy to w formie raportu podsumowującego projekt, czy innej. Należy również podkreślić, że celem nie jest szukanie winnych ani rozliczanie ich z popełnionych błędów (jest to szczególnie ważne przy spotkaniach omawiających projekty zakończone porażką).

Technika „piramidy ex post”
W celu uporządkowania przebiegu spotkania oraz wprowadzenia elementów aktywizujących uczestników można posłużyć się warsztatem połączonym z wykorzystaniem techniki piramidy ex post. Technika ta opiera swoje podstawy na czterech zasadniczych pytaniach dotyczących przebiegu całego projektu:

• Co zrobiliśmy dobrze?
• Co zrobiliśmy źle?
• Jakich rekomendacji udzielić na przyszłość?
• Komu, kiedy i jak powinniśmy przekazać te informacje?

Pytania te stanowią punkt wyjścia do przeanalizowania projektu względem dziesięciu obszarów projektu stanowiących części składowe piramidy ex post:

Rysunek 1. Piramida ex post
Źródło: H. Kerzner, Project Management Best Practices on Implementation, John Wiley & Sons, 2003, s. 302

Analiza realizacji celów projektu przebiega w osi pionowej, od wierzchołka do podstawy. Gdy przedmiotem oceny są wskaźniki realizacji projektu (ang. project measures), kierujemy się w odwrotnym kierunku - z dołu na górę.

Podstawa piramidy, jej najniższy poziom, analizuje produkty projektu (deliverables) w odniesieniu do założonego czasu, kosztów, jakości i zakresu projektu.

Tabela 6. Piramida ex post - poziom pierwszy

Czas:	Koszt:	Jakość:	Zakres:
Czy projekt zakończył się na czas? Czy szacunki dotyczące czasu realizacji zadań, etapów, całego projektu były realne? Czy zadania były realizowane terminowo, a kamienie milowe osiągane zgodnie z wymaganiami? Czy poziom szczegółowości harmonogramu był odpowiedni? Czy harmonogram pomagał kontrolować postęp prac?	Czy projekt zrealizował założony budżet? Czy szacunki koszów były rzetelne? Czy nasze wyceny kosztów powinny być uaktualnione? Czy koszty projektu były śledzone? Czy wystąpiły ryzyka powodujące odchylenia od założonych kosztów? Czy sposób finansowania projektu był adekwatny do jego specyfiki?	Czy rozpoznano wymagania jakościowe w stosunku do projektu? Czy zarządzając projektem brano pod uwagę procesy zapewnienia jakości? Czy projekt spełnił wymagania klienta? Czy produkty projektu były testowane pod kątem zgodności z wymaganiami klienta? Czy wymagania projektu zmieniały się w trakcie jego trwania?	Czy cele projektu były jasne i zrozumiałe? Czy zakres projektu był dobrze określony? Czy produkty projektu (planowane prace projektowe) obejmowały cały zakres projektu? Czy zakres projektu ulegał zmianie w trakcie jego trwania? Czy zakres projektu został zrealizowany?

Źródło: H. Kerzner, op.cit, s. 301-302

Drugie piętro piramidy analizuje trzy obszary wsparcia organizacji dla projektu:

• wsparcie funkcjonalne - relacje na linii projekt - funkcje,
• wsparcie wyższego kierownictwa - zaangażowanie komitetu sterującego, sponsora projektu itp.,
• metodologia - czyli zakres wsparcia metodycznego, z którego mógł korzystać zespół projektowy w trakcie realizacji projektu.

Tabela 7. Piramida ex post - poziom drugi

Wsparcie funkcjonalne	Metodyka	Wsparcie wyższego kierownictwa
Czy kierownicy funkcjonalni znali sens i znaczenie projektu, w którym uczestniczyli? Czy personel delegowany do projektu z linii był wystarczająco doświadczony? Czy jakość innych przyznanych zasobów była dobra? Czy otrzymano ich wystarczającą ilość? Czy zasoby dostarczono zgodnie z harmonogramem? Czy kierownicy funkcjonalni chętnie współpracowali z zespołem projektowym?	Czy zespół projektowy posługiwał się metodyką zarządzania projektami? Czy wytyczne metodyki były pomocne w realizacji projektu? Czy zestaw narzędzi metodyki był adekwatny do specyfiki projektu? Czy zespół projektowy korzystał z dodatkowych narzędzi nieprzewidzianych w metodyce? Czy metodyka obejmowała najważniejsze obszary problemowe w projekcie?	Czy wyższe kierownictwo zaangażowało się w realizację projektu? Czy było pomocne? Czy delegowało uprawnienia decyzyjne? Czy pomagało rozwiązywać konflikty między projektem a linią? Czy projekt miał dostateczny priorytet? Czy częstotliwość spotkań z komitetem sterującym była odpowiednia? Czy członkowie komitetu sterującego dobrze wypełniali swoje role?

Źródło: H. Kerzner, op.cit., s. 303

Trzecim poziomem piramidy jest analiza projektu z punktu widzenia korzyści dla klienta oraz wartości dla organizacji realizującej projekt. Przykładowe pytania z trzeciego poziomu piramidy są przedstawione w tabeli 8.

Tabela 8. Piramida ex post - trzeci poziom

Satysfakcja klienta	Perspektywa biznesowa
Czy klient jest zadowolony z relacji ceny, jakości i wartości projektu? Czy produkty projektu zostały dostarczone na czas? Czy projekt przyniósł wartość dodaną dla klienta? Czy klient wymaga dodatkowego wsparcia lub innych działań pomocniczych? Czy współpraca z klientem przebiegała prawidłowo?	Czy projekt zrealizował swoje uzasadnienie biznesowe? Czy projekt dał organizacji możliwość wzrostu? Czy istnieje możliwość dalszej współpracy z klientem? Czy wdrożenie projektu nie zakłóciło procesów organizacji? Co organizacja zyskała lub straciła przez realizację projektu?

Źródło: H. Kerzner, op.cit., s. 303

Ostatnim, czwartym poziomem piramidy ex post jest poziom strategiczny (misja). Analiza doświadczeń projektowych, z punktu widzenia strategii, powinna odpowiedzieć między innymi na następujące pytania (tabela 9).

Tabela 9. Piramida ex post - poziom czwarty

Misja

Czy projekt wniósł wkład w realizację strategii organizacji? Czy podejmując decyzję o realizacji projektu brano pod uwagę jego związek ze strategią organizacji? Czy ponownie podjęto by decyzję o realizacji projektu? Czy stan, w jakim znajduje się organizacja po realizacji projektu, jest stanem oczekiwanym i pożądanym?

Źródło: H. Kerzner, op.cit., s. 303

Technika piramidy ex post jest wartościowym narzędziem wspierającym gromadzenie doświadczeń projektowych. Jej zastosowanie w spotkaniu podsumowującym projekt pozwala w uporządkowany sposób spojrzeć na projekt z różnych punktów widzenia.

Wnioski końcowe

W efekcie przeprowadzenia wstępnych analiz dokumentacji projektowej, uporządkowania rejestrów doświadczeń projektowych oraz realizacji spotkania podsumowującego projekt, zespół projektowy dysponuje bardzo dużym ładunkiem wiedzy i doświadczeń powstałych w następstwie realizacji projektu. Co więcej, dużą część z tej wiedzy udało się przekształcić z wiedzy ukrytej - pozostającej wyłącznie w umysłach pracowników, w wiedzę jawną - zidentyfikowaną, wyodrębnioną i zapisaną np. w notatkach z przebiegu spotkania i LLL.

Dalsze kroki dotyczące obróbki pozyskanej wiedzy powinny obejmować:

• przeprowadzenie oceny zebranych doświadczeń w celu wyboru najbardziej wartościowych,
• przygotowanie wniosków i uogólnionych zaleceń na podstawie zgromadzonego materiału,
• przygotowanie pisemnego raportu doświadczeń projektowych,
• zachowanie i rozpowszechnienie najbardziej wartościowych doświadczeń projektowych jako najlepszych praktyk (best practices) oraz włączenie ich do firmowego standardu zarządzania projektami.

Gromadzenie doświadczeń projektowych stanowi jeden z najlepszych sposobów nauki i ciągłego doskonalenia zarządzania projektami. Jest to nauka na bazie praktycznych przypadków, realizowana przez osoby bezpośrednio w nie zaangażowane.

Warto odwołać się w tym miejscu do mistrza W.E. Deminga i koła doskonalenia jakości PDCA (plan-do-check-act). Gromadzenie doświadczeń projektowych doskonale wpisuje się w dwa ostatnie etapy cyklu. Analiza doświadczeń i technika spotkań podsumowujących projekt pozwala uzyskać informacje na temat przebiegu procesów zarządczych w projektach (check), a realizacja wniosków i konkluzji z spotkania zapewnia wdrożenie nowego, lepszego sposobu postępowania (act).

W dzisiejszych czasach organizacje coraz częściej konkurują ze sobą nie tylko wielkością i potencjałem organizacji, ale przede wszystkim sprawnością i szybkością działania (tempem opracowywania i wdrażania nowych produktów, przeprowadzania fuzji i przejęć, zmian technologicznych i organizacyjnych). Globalna gospodarka pełna jest przykładów Goliatów pokonywanych przez zwinnych Dawidów. Ciągłe doskonalenie się i rozwijanie sprawności w realizacji projektów, bardzo silnie wspierane zorganizowanym podejściem do uczenia się w projektach, umożliwia zdobycie i utrzymanie wysokiej pozycji firmy w tym wyścigu.

Bibliografia

• A Leaders Guide To After Action Review (TC 25-20), Department of the Army, 1993.
• H. Kerzner, Project Management Best Practices on Implementation, John Wiley & Sons, 2003.
• Kompendium wiedzy o zarządzaniu projektami, Project Management Institute, MT&DC, Warszawa 2006.
• D.J. Vetock, Lessons learned: A History of US Army Lessons Learning, US Army Military History Institute, 1988.
• P. Wyrozębski, Zarządzanie wiedzą w projektach - przedmiot i specyfika, Letnia Szkoła Zarządzania, TNOiK, Toruń 2008.

Netografia

• After Action Reviews, http://www.nwlink.com
• Army Lessons Learned Centerhttp://armyapp.dnd.ca.
• Center for Army Lessons, http://call.army.mil.
• FCW, Army Lessons Learned, www.fcw.com.
• J. Madden, 100 Lessons Learned for Project Managers, NASA, Academy of Program/Project & Engineering Leadership, http://appel.nasa.gov.
• http://www.maxwideman.com.
• Software Selection Lessons Learned, Technology Group International, 2004, [online], www.techgroupintl.com.