Wyobraź sobie projekt migracji systemu ERP. Osiemnaście miesięcy, czterdzieści osób zaangażowanych po stronie klienta, trzy zewnętrzne firmy, budżet liczony w milionach. I jeden harmonogram w Excelu, gdzie kolumna G zawiera daty opisane po prostu jako „milestone”. Nie wiadomo, co dokładnie ma być gotowe. Nie wiadomo, kto to odbiera. Nie wiadomo, co się stanie, jeśli data minie bez efektu. Po roku kierownik projektu raportuje zarządowi zielone statusy, bo wszystkie milestony są technicznie zaliczone, tyle że nikt nie sprawdził, czy cokolwiek działa.
Tak wygląda kamień milowy w wydaniu dekoracyjnym.
Samo słowo pochodzi ze starożytnych dróg rzymskich, gdzie co milę wbijano kamień z informacją o odległości do Rzymu. To nie był cel ani nagroda. To był punkt orientacyjny, który mówił: jesteś tu, a nie tam, gdzie myślałeś. W zarządzaniu projektami ta logika jakoś po drodze zginęła.
Co milestone naprawdę znaczy w dokumentach, które wszyscy mają na półce
PMBOK Guide definiuje milestone jako zdarzenie o zerowym czasie trwania, które oznacza istotny punkt lub osiągnięcie w projekcie. Zero czasu trwania to ważny szczegół, bo od razu odróżnia kamień milowy od zadania. Nie jest to blok pracy, który można przesuwać i dzielić. To stan: albo osiągnięty, albo nie.
PRINCE2 podchodzi do tego inaczej. Zamiast mówić wprost o milestone’ach, mówi o granicach etapów zarządzania, czyli managing a stage boundary. Każde przejście między etapami to punkt, w którym Project Board aktywnie decyduje, czy projekt idzie dalej, czy nie. To nie jest formalność. To mechanizm kontrolny, gdzie sponsor projektu musi potwierdzić, że nadal istnieje uzasadnienie biznesowe. Jeśli go nie ma, projekt powinien zostać zatrzymany. W praktyce, jak wszyscy wiemy, rzadko tak się dzieje, ale sama architektura PRINCE2 zakłada, że kamień milowy ma realną moc decyzyjną.
W Scrumie sprawa jest trochę bardziej skomplikowana, bo framework z założenia unika długoterminowych harmonogramów. Sprint Review co dwa tygodnie albo co miesiąc jest jednak w pewnym sensie mini-milestone’m: zespół pokazuje przyrost, interesariusze decydują, co dalej. Scrum Guide Schwabera i Sutherlanda z 2020 roku nie używa słowa milestone, ale logika punktu weryfikacji jest wpisana w samą strukturę sprintu.
Dlaczego milestone sypie się na styku z harmonogramem
Podstawowy problem z kamieniami milowymi polega na tym, że są mylone z terminami. Termin to data, do której coś ma być zrobione. Kamień milowy to stwierdzenie faktu: to zostało zrobione. Różnica jest pozornie kosmetyczna, ale w praktyce powoduje zupełnie inne zachowanie zespołów.
Douglas Hofstadter w swojej książce „Gödel, Escher, Bach” z 1979 roku sformułował prawo, które od tamtej pory krąży po każdej retrospekcji po fakapie: wszystko trwa dłużej niż zakładasz, nawet jeśli uwzględnisz prawo Hofstadtera. To samozwrotne sformułowanie jest trochę zabawne, ale w kontekście milestone’ów oznacza coś konkretnego. Jeśli kamień milowy jest przywiązany do daty w harmonogramie, a nie do definicji gotowości, to pod presją czasu ludzie zaczynają zaliczać kamienie, zamiast osiągać je. Data mija, status zmienia się na zielony, a produkt nadal nie działa.
Fred Brooks w „The Mythical Man-Month” z 1975 roku opisał ten mechanizm z perspektywy opóźnień w projektach programistycznych. Jego obserwacja, że projekty spóźniają się po jednym dniu na raz, a nie od razu o kilka miesięcy, dotyczy właśnie milestone’ów. Każdy z nich jest trochę spóźniony, każde opóźnienie jest racjonalizowane jako do nadrobienia, aż w którymś momencie okazuje się, że projekt jest sześć miesięcy za harmonogramem i nikt nie potrafi powiedzieć, kiedy to się stało.
Warto przy tym zajrzeć do artykułu o tym, co Scrum obiecuje, a czego nie dostarcza, bo problem z fałszywymi milestone’ami jest tam opisany w innym, ale bardzo pokrewnym kontekście.
Milestone jako punkt decyzji, nie dekoracja w Jirze
Najlepiej działające kamienie milowe, jakie widziałem w projektach IT, mają kilka wspólnych cech. Po pierwsze, są sformułowane jako stan, nie jako aktywność. Nie „przeprowadzenie testów akceptacyjnych”, tylko „testy akceptacyjne zakończone, lista błędów krytycznych: zero”. Po drugie, mają wskazanego właściciela, który potwierdza osiągnięcie. Nie kierownik projektu, tylko osoba, która faktycznie może ocenić, czy efekt jest realny. Po trzecie, ich nieosiągnięcie uruchamia konkretną procedurę, nie tylko zmianę koloru w Jirze.
Standish Group w swoich raportach CHAOS od lat dokumentuje, że większość projektów IT nie dostarcza tego, co obiecuje w terminie i budżecie. Kamień milowy zamieniony w dekorację jest jednym z mechanizmów, przez które projekty gubią kontakt z rzeczywistością. Nie jedynym, ale wyjątkowo skutecznym.
Jeśli zastanawiasz się, czy twoje kamienie milowe są prawdziwe czy dekoracyjne, jest prosty test. Zadaj pytanie: co się stanie, jeśli ten milestone nie zostanie osiągnięty w terminie. Jeśli odpowiedź brzmi „przesuniemy datę i zaktualizujemy harmonogram”, to masz dekorację. Jeśli odpowiedź brzmi „eskalacja do sponsora projektu, analiza wpływu na budżet i zakres, decyzja o kontynuacji”, to masz narzędzie. A to dość spora różnica, nawet jeśli obydwie wersje wyglądają identycznie w Jirze.
I jeszcze jedno: jeśli projekt ma więcej niż dwadzieścia kamieni milowych rozłożonych równomiernie co dwa tygodnie, to raczej nie ma kamieni milowych. Ma harmonogram zadań z lepszą nazwą. To też jest wybór, ale warto wiedzieć, że się go robi.
Źródła
- Brooks F.P., „The Mythical Man-Month”, Addison-Wesley, 1975.
- Hofstadter D., „Gödel, Escher, Bach: An Eternal Golden Braid”, Basic Books, 1979.
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, 2020.
- Project Management Institute, „A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, PMI, aktualizowany cyklicznie.
- AXELOS, „Managing Successful Projects with PRINCE2”, The Stationery Office, aktualizowany cyklicznie.
- Standish Group, „CHAOS Report”, Standish Group International, wydania cykliczne.
Zdjęcie: useche360 / Pixabay
