Jak raportować stan projektu?

Luźny wpis, w którym poruszę temat raportowania stanu projektu. Zachęcam do przeczytania wszystkich, którzy takie raporty piszą, a przede wszystkim tych, którzy je czytają :). Odpowiem dlaczego pytanie „ile procent projektu mamy ukończone?” może zakłamywać rzeczywistość i dawać złudne poczucie bezpieczeństwa. Pokażę również bardziej skuteczną metodę raportowania stanu projektu.

Gdy stawiałem pierwsze kroki jako PM, prowadziłem pewien projekt, w którym miałem przesyłać klientowi tygodniowe raporty. Raport ten miał odpowiadać na pytanie „ile procent projektu jest ukończone?”. Prowadziłem skrupulatnie wszystkie dane w excelu, analizowałem zadania z JIRY – więc nie sprawiało mi problemu, żeby przygotować taki raport w ~10-20m. Po kilku tygodniach opracowałem pewien wzór raportu, który składał się z wypisanych modułów, każdy z procentowym ukończeniem oraz średnią arytmetyczną punktów procentowych wszystkich modułów. Projekt był rozłożony na czynniki pierwsze, mój wykładowca ze statystyki byłby ze mnie dumny. Takiego samego sposobu raportowania oczekiwałem od swoich managerów modułów – zarządzali większymi modułami w tym projekcie i wysyłali mi statystyki, które ja agregowałem w jeden zbiorczy raport. Przez pierwszych kilka tygodni stopień zaawansowania w projekcie rósł – wykresy robiły się coraz bardziej zielone (stopień ukończenia powiększał się). Faktyczny postęp według mnie nie postępował tak szybko, byliśmy zgodnie z planem, mimo że statystyki pokazywały, że mamy pewną rezerwę czasową. Analizując tę historię dzisiaj, w tym momencie powinno włączyć mi się żółte światło ostrzegawcze. Z każdym tygodniem postęp ukończenia wzrastał o mniejszą ilość punktów procentowych, mimo, że zespół nie zwalniał tempa. Nie wiedziałem dlaczego tak się dzieje, byłem uśpiony złudnym poczuciem bezpieczeństwa, bo „przecież robimy progres, konsekwentnie do przodu”. Przyczyniło się to do tego, że o wiele za późno odkryłem „wąskie gardło” w projekcie, które powodowało brak znaczącego postępu (oprócz tego w statystykach).

Wiedziałem jak manipulować statystykami by były korzystniejsze lub przeciwnie. To nie było niezgodne z prawdą, to była różna interpretacja danych. Manipulację statystykami poprzez subiektywną interpretację zauważamy codziennie w różnego rodzaju sondażach i badaniach. To tak jakbym się zapytał swojej rodziny czy znają adres wedlugplanu.pl, a następnie zinterpretował ten wynik: „100% Polaków zna adres wedlugplanu.pl”. Mógłbym pójść dalej i powiedzieć o wszystkich ludziach na świecie. Czytający nie ma informacji, które są istotne do interpretacji – ile osób było ankietowanych i jakie to były osoby 🙂 Jaskrawy przykład, ale mam nadzieję, że widzisz analogię. Dokładnie to samo się dzieje w raportach, które opisywałem powyżej.

Z perspektywy czasu wiem, co było złe. Zła była skala pomiaru zaawansowania projektu. Mierzyliśmy stopień ukończenia na podstawie zamkniętych zadań. Zobrazuję to na przykładzie:

#1 task (1h)
#2 task (1h)
#3 task (4h)
#4 task (4h)

Gdy zamkniemy #1 task, #2 task, według statystyki będziemy mieć 50% ukończenia projektu, więksi realiści powiedzą, że to jest 20% (2h z 10h). Jeśli mamy wiedzę (którą nabyliśmy w trakcie trwania projektu), że #3 lub #4 task się opóźnią, faktyczny stan ukończenia projektu będzie nawet niższy niż 20%.

Projekt był mierzony według złej skali. Równie dobrze można by było podać liczbę napisanych linii kodu lub ilość kWh, jakie zużyły nasze komputery do pracy. To również był jaskrawy przykład. Skala pomiaru została narzucona na mnie, ja natomiast sukcesywnie narzuciłem ją w dół. Managerzy modułów podali ją dalej. W efekcie wszyscy chcieli zamknąć jak największą liczbę zadań (co nie jest równoznaczne z postępem w projekcie). Zamykane były krótkie proste zadania, dzięki którym statystyki rosły. Nikt nie skupiał się na robieniu faktycznego postępu, głównym celem był postęp „na papierze”. Błędne koło.

Pójdźmy dalej i zastanówmy się, dlaczego ludzie pytają „ile procent projektu mamy ukończone?” – dlaczego pytają akurat w ten sposób. Odpowiedzią jest ich założenie, które jest błędne: „to, że ukończyłem w 1h 50% oznacza, że całość ukończę w 2h”. Otóż nie. To jaką mieliśmy przeszłość, nie determinuje przyszłości. Pewnie znacie przykłady projektów, w których ostatnie 10% zakresu trwało 50% czasu projektu 🙂 – ja znam. Jeśli wygrasz w sobotę czwórkę w lotto, to nie znaczy, że tydzień później twoja wygrana się powtórzy – nie budżetuj tego 😉 Pewnie słyszałeś o prawach Murphy’ego i wiesz czym są. Murphy uderzy gdy się nie będziesz tego spodziewał, czyli w najmniej oczekiwanym momencie. Kluczowy zasób w projekcie zachoruje, gdy będzie miał najwięcej do zrobienia, będzie awaria elektryczności w biurze przez tydzień lub cokolwiek innego. Nie zakładaj pewności na niepewność, że Murphy nie zapuka do twojego projektu.

PS: do nas ostatnio zapukał Murphy w postaci ataku na naszego providera internetu. Skutek był taki, że do firewalla dostawcy internetu trafiły nasze adresy API, co uniemożliwiało pracę z biura.

Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯

Jak raportować stan projektu?

Goldratt, twierdził, że wszystkie rozwiązania problemów są tak naprawdę żenująco proste. Zgadzam się z tym, tak jest też w tej sytuacji. Wystarczy, że będziemy monitorować ilość dni, jaka została do ukończenia projektu. Pytanie więc powinno brzmieć „za ile dni ukończymy projekt?„. Co z tego, że mielibyśmy 90% projektu, jeśli kolejne 10% będziemy robić pół roku – to nic nie znaczy. Natomiast każdego interesuje kiedy ukończymy projekt i jak to ma się względem pierwotnie zaplanowanego deadline. Nie mówię, że to pytanie jest panaceum na idealne raportowanie, pamiętajmy, że Murphy może przyjść o każdej porze. Uważam, że takie pytanie nie wprowadza złej skali pomiaru zaawansowania projektu, więcej mówi o tym, gdzie tak naprawdę jesteśmy. Dla wszystkich, którzy lubią procenty możemy pytań „za ile dni będzie 100%?” 😉

Podczas luźnych dygresji (jednej z wielu 😉 ) dyskutowaliśmy w pracy nad raportowaniem stanu projektu przełożonym. Jedna z osób (pozdrawiam Pawła), opowiedziała jak w jego poprzedniej pracy wyglądały takie sprawozdania. Składały się z narysowanej na kartce jednej z trzech „minek” – 🙂 😐 :(. Minka uśmiechnięta znaczyła, że jest ok, a nawet lepiej, minka druga, że zgodnie z planem, minka smutna sygnalizowała opóźnienie. Na początku wydawało mi się to śmieszne, jednak po głębszym zastanowieniu uznałem, że taki sposób raportowania jest bardziej miarodajny niż statystyki, które opisywałem na początku wpisu. Wnioskiem jest to, że forma raportu jest mało istotna, natomiast ogromne znaczenie ma skala jaka mierzymy pomiar, nawet jeśli wyrażamy to w postaci minki :).