W poprzednim artykule (Strefa PMI, nr 31, s. 34-35) przedstawiłem Wam studium przypadku – przedsięwzięcie realizowane w 7 obszarach przez zespoły z różnym podejściem do organizacji pracy. Projekt miał też kilku dostawców zaangażowanych w realizację wybranych zadań i obszarów. W ramach artykułu zadałem pytanie: w jaki sposób i kiedy powinien zostać zorganizowany proces zbierania wniosków z doświadczeń? Poprosiłem też czytelników Strefy PMI o przesłanie swoich pomysłów na sposób podejścia do zbierania wniosków z doświadczeń w projekcie.
Bardzo dziękuję za wszystkie nadesłane pomysły. Do najciekawszych propozycji zaliczyć można:
- Wykorzystanie wewnętrznego Agile Coacha do przeprowadzenia spotkań w każdym z obszarów projektu, a następnie stworzenie wspólnej listy zadań do realizacji.
- Zorganizowanie osobnych spotkań z dostawcami, wewnętrznym zespołem IT oraz zespołami biznesowymi, aby następnie zapewnić wymianę wiedzy pomiędzy uczestnikami projektu.
- Zorganizowanie wspólnej konferencji dla wszystkich uczestników projektu, gdzie w ramach poszczególnych warsztatów i spotkań odbędzie się zbieranie wniosków wraz z prezentacją ich dla uczestników konferencji.
- Raportowanie wniosków z doświadczeń do Komitetu Sterującego w celu zapewnienia ich wdrożenia poza projektem
- Mnie osobiście bardzo spodobał się pomysł praktyczny, aby nie zbierać wniosków, bo i tak nikt ich nie wykorzysta.
I ten ostatni punkt jest tutaj bardzo ważny – jeżeli zbieramy wnioski do spełnienia wymogu PMO lub po prostu nauczono nas, że warto taki rejestr mieć, ale nie będzie woli lub zaplanowanego czasu na wykorzystanie tej wiedzy, to nie warto tego robić. Wnioski z doświadczeń, aby miały wartość, muszą być wykorzystane, tzn. przynajmniej musi zostać przekazana wiedza o nich do odpowiednich osób. I tutaj prosty przykład: firma realizująca projekty budowlane i remontowe miała wiele wyzwań związanych z przekraczaniem budżetów projektów. Na dużych projektach średnie przekroczenie budżetu (w stosunku do zakładanych kosztów wewnętrznych) wynosiło ponad 30%. Natomiast w małym projekcie zdarzyła się sytuacja, że nie zostały doprecyzowane wymagania z klientem odnośnie specyfikacji na wymienianą w oddziale firmy windę. Finalne koszty tego projektu przekroczyły zakładany budżet o 100%. O tym projekcie i jego opóźnieniu wiedzieli wszyscy w firmie, dlatego mówimy, że negatywne wnioski z doświadczeń zostały pocztą pantoflową dostarczone do wszystkich pracowników firmy i póki nie zmieni się kadra, to wydarzenie to zostanie w pamięci. Natomiast wyzwaniem oczywiście było to, że nikt nie wyciągał wniosków i nie wdrażał usprawnień w realizacji dużych projektów.
Skupmy się teraz na zrozumieniu podejścia do wniosków z doświadczeń. Dobrą analogią będzie tu podejście w dużym projekcie do zarządzania ryzykami. Jeżeli zrobicie warsztaty z różnymi zespołami w ramach projektu w celu identyfikacji ryzyk, otrzymacie długą listę potencjalnych szans i zagrożeń. Czy wszystkie te ryzyka powinny być przekierowane do kierownika projektu, do sponsora czy komitetu sterującego? Czy w rejestrze ryzyk powinniśmy wpisywać tylko ważne tematy? Czy dla wszystkich ryzyk będziemy wykonywać działania zapobiegające? Odpowiedź na wszystkie pytania brzmi: nie. Musimy tak zaplanować proces, aby ryzyka w zależności od skali i znaczenia trafiły na odpowiedni poziom projektu i tam zostały zaadresowane. Podobnie sytuacja wyglądać będzie z wnioskami z doświadczeń. Mogą one dotyczyć drobnych usprawnień w pracy jednego zespołu, aż po zmiany organizacyjne, które muszą zostać wdrożone osobnym projektem. Natomiast musimy pamiętać, że proces zarządzania wnioskami z doświadczeń, aby był skuteczny, musi dotyczyć zmian w samym projekcie, ale również zmian, które wdrożymy w organizacji.
Prostym przykładem może być tu problem z księgowaniem kosztów zespołu utrzymania IT na projekty, który miałem w jednym przedsięwzięciu. Brak jasnych zasad i kontroli dniówek zespołu utrzymania spowodował, że do projektu zostały doliczone dodatkowe koszty. Z punktu widzenia projektu została zrobiona korekta i temat można by było zamknąć, ale ponieważ zależało mi na trwałym rozwiązaniu, dlatego temat ten musiał zostać wyjaśniony i rozwiązany na poziomie całej organizacji (ponieważ podobny problem występował co jakiś czas również w innych projektach).
Spójrzmy jeszcze na jeden aspekt tego tematu: czy kierownik projektu powinien dalej zajmować się takim tematem na poziomie organizacji? Zdecydowanie nie, tutaj jest właśnie miejsce dla PMO, które na podstawie wniosków z doświadczeń z projektów powinno decydować, które tematy wymagają zaopiekowania i wdrożenia na poziomie całej organizacji.
Fot. Free-Photos from PixabayWróćmy teraz do naszego przykładu. Obszary projektu posłużyły do zaplanowania osobnych spotkań dotyczących wniosków z doświadczeń w każdym z nich. Istotnym aspektem przy planowaniu spotkań była bezpośrednia współpraca osób w ramach projektu bez względu na fakt, czy osoby te występują również w innych zespołach. Ważniejszy dla nas był zespół pracujący wspólnie niż podział na etapy i produkty projektu. Przy planowaniu nie miał też znaczenia rodzaj ani poziom zastosowanej metodyki prowadzenia zespołu, natomiast poziom ten był podstawą do przygotowania się do współpracy z danym zespołem i zastosowanym nazewnictwem (w niektórych zespołach bez słowa retro moderator nie miałby wejścia).
Ważnym elementem całego zadania był moderator. Ze względu na skomplikowanie systemu, stosowane w projekcie słownictwo oraz pewną zamkniętość w grupie, zdecydowano się na wyznaczenie jednej osoby z wewnątrz projektu jako moderatora spotkań dotyczących zbierania wniosków z doświadczeń. W ten sposób chcieliśmy zapewnić spójność procesu oraz zapewnić osobę merytoryczną, która będzie w stanie (znając projekt) grupować wnioski na poziomie całego projektu.
Ze względu na różny moment zamknięcia poszczególnych modułów projektu spotkania dotyczące wniosków z doświadczeń odbywały się w różnych datach, ale wszystkie zostały zorganizowane w okresie 4 miesięcy.
Mieliśmy spójne podejście i jednego moderatora, mogliśmy więc zebrać wszystkie wnioski w jeden rejestr i przeanalizować na poziomie całego projektu. Najważniejsze uwagi zostały zgłoszone do Sponsora i Komitetu Sterującego, a po ich akceptacji do PMO w organizacji.
Ważnym aspektem wdrożonego procesu było też skategoryzowanie wniosków i udostępnienie ich dla zespołu projektowego (w postaci dostępu do rejestru oraz dedykowanego spotkania).
Podsumowanie
W ramach podsumowania wniosków z doświadczeń z zastosowania procesu zarządzania wnioskami z doświadczeń, do najważniejszych elementów zaliczyć można:
- Wyznaczenie moderatora z wewnątrz projektu znającego specyfikę i słownictwo bardzo ułatwiło pracę podczas warsztatów. Zachęcam do zapytania zespołu projektowego, czy nie ma chętnych osób do takiej roli, bo w praktyce okazuje się, że nie znamy wszystkich kompetencji naszego zespołu projektowego.
- Omawianie efektów pierwszych warsztatów spowodowało, że łatwiej było zachęcić kolejne zespoły do sesji wniosków z doświadczeń.
- Okazało się, że sesje zbierania wniosków z doświadczeń stały się trochę „odmianą” i czymś nowym dla zespołu, dlatego prowadzenie ich w miłej atmosferze pozwoliło spojrzeć z boku na wyzwania i problemy, które były w projekcie.
Poświęcenie czasu na przekazanie wniosków z doświadczeń do organizacji przynosi wymierne korzyści. Nie bójmy się takiej inwestycji, na pewno będzie to z korzyścią dla bieżących i przyszłych projektów.
Ekspert w zakresie zarządzania projektami, portfelem projektów i PMO. Specjalizuje się w obszarze usprawnień organizacji poprzez wdrożenie zarządzania portfelem projektów i PMO oraz w obszarze rozwoju kierowników projektów. Od 2003 roku związany z PMI®, gdzie pełnił m.in. funkcję Prezesa Oddziału Polskiego. Z centralą PMI® w USA związany od 2010 roku – obecnie pracuje w Komitecie do Spraw Certyfikacji (CGC). Od 2010 roku prezes firmy WHITECOM Project Experience specjalizującej się w szkoleniach, ustawianiu PMO oraz zarządzaniu projektami i portfelem projektów. Współautor książki PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji.