Pracując w branży, w której kryteria sukcesu jeszcze wciąż mierzone są odchyleniami od parametrów trójkąta projektowego (Standisch Group w niedawno opublikowanym „Chaos Report” zmienia definicję sukcesu projektu mówiąc, że decyduje o nim wartość, jaką projekt dostarcza klientowi w postaci rezultatów biznesowych), jakiś czas temu postanowiłam się przyjrzeć liczbom na swoim podwórku. Co więcej – postanowiłam tymi liczbami podzielić się z zespołem rozpoczynającego się właśnie projektu, którego byłam project managerem. Liczby były pretekstem i prowokacją do dyskusji. Chciałam, abyśmy wspólnie zdiagnozowali, jakie są przyczyny porażek w projektach, a także wypracowali kryteria sukcesu. Celem jaki chciałam zrealizować przy okazji było to, abyśmy przy tym:
- nauczyli się wyciągać wnioski z niepowodzeń,
- utrwalali dobre praktyki, czyli coś, co się sprawdza i działa,
- byli otwarci na wzajemny feedback i pewną transparentność.
Przedstawiłam 4 zakończone projekty, w których pokazałam planowaną vs wypracowaną ilość roboczogodzin oraz planowany vs rzeczywisty termin wdrożenia. Nie odnosiłam się do jakości, ponieważ kryteria w tych projektach nie zostały zdefiniowane w sposób mierzalny, a także nie patrzyłam na zakres – dla każdego z projektów założeniem była jego pełna realizacja (wymagania zdefiniowane w dokumentacji).
Liczby były dość okrutne – brutalnie przekroczone czasy realizacji, a co tym idzie – terminy.
Zadałam pytanie:
– Dlaczego tak się dzieje?
Poprosiłam każdego z uczestników spotkania o to, aby zapisywał przyczyny porażek w projektach na karteczkach samoprzylepnych (1 przyczyna = 1 karteczka). Następnie karteczki te nakleiliśmy na tablicy, grupując je według przyczyny.
Odpowiedzi były momentami oczywiste, ale dobrze, że zostały wypowiedziane – nie zawsze to, co oczywiste jest uświadomione. Czasem były zaskakujące – na co dzień o pewnych sprawach nie myślimy. Nie doceniamy lub nie zauważamy spraw tych poza metodycznych, które mają znaczenie dla (nie-) powodzenia projektu.
Powstała następująca lista:
- Niekompletna dokumentacja, wiele “białych plam”, nieprecyzyjne wymagania (również po stronie klienta), w efekcie czas na programowanie konsumowany na ustalenia
- Zbyt optymistyczne planowanie
- Niedoszacowanie czasu pracy przez project managera / team leadera
- Zadania oszacowane na podstawie niekompletnych informacji
- Zadania oszacowane przez osoby o różnym poziomie kompetencji i doświadczenia
- Niedoszacowany projekt na etapie sprzedaży
- Zbyt niskie wyceny
- Brak niektórych funkcji / modułów w wycenie
- Brak kluczowych zasobów do realizacji i / lub zmiany w zespole
- “Przerzucanie” programistów między projektami
- Oczekiwanie na dostępność określonych zasobów
- Wdrażanie się kolejnych programistów
- Opóźnienia ze strony klienta w przekazywaniu niezbędnych materiałów
- Specyfika pracy z klientem, np. brak zaangażowania klienta
- Wprowadzane do projektu zmiany
- Nowe, nieznane technologie
W odpowiedzi na zdefiniowane problemy postanowiliśmy wypracować konkretne rozwiązania na poczet naszego nowego projektu. Inaczej mówiąc, zastanawialiśmy się:
– Co my, jako zespół, możemy zrobić?
W rezultacie powstała lista propozycji, które finalnie przekuliśmy na nasz projektowy kontrakt (o kontrakcie jako narzędziu pracy z zespołem już wkrótce przeczytasz na blogu).
- Każdy z członków zespołu zwrócił uwagę na to, jak ważny i zarazem zaniedbany jest aspekt komunikacji w zespole – wszyscy byli zgodni co do tego, że sprawna komunikacja leży u podstaw sukcesu projektu.
- Ważne jest również zapewnienie niezbędnych narzędzi do komunikacji z osobami pracującymi w innych lokalizacjach.
- Planowanie działań z wyprzedzeniem – zespół zasugerował, że chciałby znać plan długofalowy – jest to ważne dla realizowania celów długoterminowych, a nie ograniczania się tylko do realizacji bieżących zadań.
- Konieczne konsultowanie zmian z zespołem – aby zapobiec przyjęciu do realizacji zmiany, której wprowadzenie może mieć opłakane skutki dla systemu, należy wcześniej omówić ją z zespołem z uwzględnieniem ryzyk oraz narzutów czasowych, jakie ze sobą niesie.
- Zespół zastrzegł, że chce posiadać komplet informacji do przygotowania rzetelnej wyceny czasochłonności prac, co jest zrozumiałe w obliczu tego, że zespół za realizację zadań w określonym czasie jest odpowiedzialny.
- Agregowanie dokumentacji oraz informacji w jednym miejscu – dokumentacja powinna być aktualna, dostępna, ustalenia nie mogą być rozproszone w rożnych plikach.
- Zespół domagał się, aby priorytety w projekcie zostały ustalone i były znane – w sytuacji kiedy pojawiają się blokery uniemożliwiające realizację bieżących zadań zespół, kierując się priorytetami, może podjąć inne zadanie.
- Zaangażowanie klienta do weryfikacji postępów prac w projekcie zostało wskazane jako kluczowe dla powodzenia projektu – bez informacji zwrotnej od klienta nie wiemy, czy to, co robimy, zmierza we właściwym kierunku.
- Postulat skierowany do projekt managera to skrócenie czasu oczekiwania na informacje – zbyt długie oczekiwanie na odpowiedź staje się blokerem dla kontynuowania prac – ten punkt dla mnie stał się priorytetowy.
- Zespół podkreślił korzyści płynące z pracy w jednej lokalizacji, a nawet w jednym pomieszczeniu, co mobilizuje mnie jako project managera, do spełnienia tego warunku (nie zawsze łatwe i nie zawsze możliwe).
Mimowolnie wykonałam z zespołem tzw. “lessons learned”:
- Rozpoznaj błędy
- Zobacz co działa
- Wyciągnij wnioski
- Udokumentuj to
- Podziel się wiedzą
Jak widać zespół postawił na komunikację i planowanie. Wypracował reguły współpracy wewnątrz siebie. Umówiliśmy się na wzajemne przestrzeganie tego, co wspólnie ustaliliśmy. Nie jest to gwarantem sukcesu – taki nie istnieje w przedsięwzięciu, w którego cykl życia wpisane są ryzyka, niepewność i zmiany. W przedsięwzięciu, którego losy zależne są nie tylko od starań zespołu, a coraz częściej od metodyki, na którą zespół nie ma wpływu. No właśnie…
Dziś już wiemy, że Agile jest odpowiedzią na większość wymienionych wyżej bolączek (o tym też pisze Standish Group we wspomnianym już raporcie), jednak transformacja metodyk w organizacjach dopiero się zaczyna lub właśnie trwa. Jedną nogą lub czasem jeszcze dwiema wciąż jesteśmy w waterfall’u, w który nie są wpisane transparentność i doskonalenie się. Tu środek ciężkości przesuwa się w stronę project managera, którego zadaniem jest odrobić lekcję z zespołem.
Niezależnie od problemów, które dręczą projekt, warto zadać na forum zespołu te 2 pytania – to taka waterfall’owa retrospektywa. Warto rozmawiać. A potem najważniejsza jest konsekwencja, egzekwowanie i wzajemna mobilizacja. A także pamiętanie – projekty trwają dłużej niż pamięć o pewnych sprawach, zwłaszcza tych, które są dla nas niewygodne, bo czegoś od nas wymagają.
