Bill Gates powiedział kiedyś „Nie ma nic złego w świętowaniu sukcesu, ale ważniejsze jest wyciągnięcie nauki z porażki”. W zarządzaniu projektami mamy do czynienia z jednym i drugim, a zwrot „lessons learned” znajdziesz w każdej metodyce zarządzania projektami.
PRINCE2®
Jednym z pryncypiów, na których opiera się metodyka PRINCE2®, jest korzystanie z doświadczeń (ang. learn from experience). PRINCE2® mówi wprost, że w każdym projekcie należy poszukiwać i korzystać z doświadczeń wyniesionych z innych projektów:
- podczas inicjowania projektu powinno się przeglądnąć doświadczenia z porzednich podobnych projektów i wziąć je pod rozwagę podczas przygotowywania planu projektu – w odniesieniu do jakości, do przygotowanych estymat, do identyfikowania ryzyk w projekcie i planowania odpowiedzi na ryzyka,
- w czasie trwania projektu doświadczenia powinny być na bieżąco zbierane i wykorzystywane,
- oraz na końcu projektu, kiedy to powinniśmy nasze doświadczenia przekazać do kolejnych projektów realizowanych przez organizację.
Wszystkie doświadczenia powinny być zbierane w dzienniku doświadczeń (ang. lessons log) i w raporcie doświadczeń (ang. lessons report). Dziennik doświadczeń jest nieformalnym dokumentem, w którym zapisywane są doświadczenia z poprzednich projektów i z projektu aktualnie realizowanego. Można w nim znaleźć takie informacje, jak: opis konkretnego zdarzenia i skutki, jakie spowodowało, przyczyny tego zdarzenia i rekomendacje. Drugi dokument – raport doświadczeń – powstaje na końcu etapu/na końcu projektu i zawiera zestaw doświadczeń, które zostaną przekazane do kolejnych projektów. Jak się zapewne domyślasz, jest to dokument formalny i wymaga zatwierdzenia.
PMBOK
Już na samym wstępie PMBOK zwraca uwagę, że na projekt wpływają rozmaite czynniki zewnętrzne (ang. enterprise environmental factors, EFFs) i wewnętrzne (ang. organizational process assets, OPAs). Na liście OPAs znajduje się repozytorium wniosków wyciągniętych z poprzednich projektów (ang. lessons learned repository) .
W PMBOK6 wprowadzono proces Manage Project Knowledge. Jednym z wyników tego procesu jest rejestr, w którym zapisywane są aktualne doświadczenia (ang. lessons learned register). Na koniec projektu/fazy projektu lekcje zapisane w tym rejestrze są przenoszone do repozytorium w OPAs.
Wspomniany rejestr doświadczeń jest elementem większości procesów zdefiniowanych w PMBOK:
- pozwala czerpać z zapisanych w nim doświadczeń podczas realizacji danego procesu,
- wymaga uaktualnienia o nowe lekcje wyniesione z realizacji danego procesu.
SCRUM
Poruszając temat zbierania doświadczeń, nie sposób nie wspomnieć o SCRUM, w którym filarami są inspekcja i adaptacja – zarówno procesu, jak i rezultatów projektu realizowanego scrumowo. W rezultacie na bieżąco odbywa się zbieranie doświadczeń, wyciąganie wniosków i wdrażanie rekomendacji.
Fundamenty te są realizowane poprzez codzienne spotkania (ang. daily stand-ups) oraz poprzez spotkania, które mają miejsce na końcu każdego sprintu: przegląd sprintu i retrospekcja sprintu.
Każdego dnia zespół deweloperski spotyka się na kilkanaście minut. W tym czasie każdy z członków zespołu odpowiada na pytania (jedna z form, w jakich można przeprowadzić to spotkanie):
- co osiągnął od ostatniego spotkania,
- czym zamierza się zajmować do czasu kolejnego spotkania,
- jakie trudności pojawiły się na jego drodze do osiągnięcia tych celów.
Celem przeglądu sprintu jest weryfikacja cech, jakie zostały dostarczone w ramach sprintu. Wnioski wyciągnięte podczas przeglądu sprintu wyznaczają rozwój produktu w kolejnych sprintach.
Z kolei celem retrospekcji jest weryfikacja procesu. Jest wiele różnych podejść do przeprowadzenia tego spotkania, ale cel jest jeden – zdecydować o tym:
- co kontynuować, bo jest dobre/bo działa dobrze,
- z czego zrezygnować, bo nie działa
- i co poprawić/jakie nowe działania wprowadzić.
Rekomendacje, jakie powstaną w ramach restrospekcji, są wdrażane w kolejnym sprincie.
Podsumowanie
Jak widzisz, niezależnie do tego, w jaki sposób realizowany jest projekt – czy klasycznie czy zwinnie, zbieranie tzw. lessons learned i korzystanie z nich powinno być aktywnością każdej osoby zaangażowanej w projekt. Najlepiej codzienną aktywnością, choć jak wynika z mojego doświadczenia – najlepiej tutaj wypada SCRUM, bo podejście to wymusza na zespole pewne zachowania i refleksję.
Już miałam opublikować ten artykuł, kiedy pomyślałam, że przecież Bill Gates mówił też o sukcesie. Z ciekawości sprawdziłam i w PMBOK słowo „celebrate” pojawia się tylko dwa razy. Przypadek?
