W 2019 siedziałem na audycie powdrożeniowym projektu ERP w firmie produkcyjnej. Zespół liczył 12 osób, budżet przekroczył 2 miliony, a termin został przekroczony o 8 miesięcy. Kierownik projektu, facet z certyfikatem PMP i piętnastoma latami doświadczenia, pokazywał mi swoją strukturę podziału pracy. Wyglądała jak diagram z podręcznika. Poziomy, hierarchia, numery WBS. Problem? Brakowało w niej trzech modułów, które faktycznie wdrożyli, a dwa inne były zduplikowane pod różnymi nazwami.
Zapytałem go o regułę 100%. Spojrzał na mnie jak na idiotę.
Co to właściwie jest ta reguła 100%
Project Management Institute, organizacja stojąca za PMBOK Guide, definiuje regułę tak: suma pracy na poziomie dzieci musi równać się 100% pracy reprezentowanej przez rodzica. Brzmi prosto, ale w praktyce to znacznie więcej niż matematyka.
Reguła 100% mówi, że Work Breakdown Structure musi zawierać całą pracę określoną przez zakres projektu. Całą. Nie 95%, nie 103%, tylko dokładnie 100%. Wszystkie deliverables, wewnętrzne, zewnętrzne, interim. Jeśli coś jest w zakresie, musi być w WBS. Jeśli czegoś nie ma w zakresie, nie może być w WBS.
W tym samym audycie okazało się, że zespół pracował nad integracją z systemem CRM, której nie było w pierwotnym zakresie ani w WBS. Ktoś dorzucił ją “po drodze”, bo wydawała się oczywista. Pół roku roboty, 200 tysięcy złotych, zero w dokumentacji projektowej.
Dlaczego to w ogóle ma znaczenie
Firma logistyczna, 2021, wdrożenie TMS. Project manager zbudował WBS na podstawie harmonogramu z Jiry. Wyglądało sensownie: planowanie, konfiguracja, testy, wdrożenie. Na retrospekcji po fakapie okazało się, że nikt nie uwzględnił migracji danych z trzech starych systemów. To nie było zadanie w Jirze, więc nie trafiło do WBS. Migracja zjadła 4 miesiące i wymusiła przeprojektowanie połowy integracji.
Reguła 100% działa jak suma kontrolna. Jeśli twój WBS nie zawiera wszystkich deliverables, tracisz kontrolę nad zakresem. Scope creep zaczyna się dokładnie w momencie, gdy ktoś mówi “a, to tylko mała rzecz, nie musimy tego formalizować”.
Z drugiej strony, jeśli WBS zawiera pracę spoza zakresu, finansujesz coś, czego sponsor nie zamawiał. W standardach PMI jest to równie poważne naruszenie jak brak elementów.
Jak to działa na każdym poziomie
Hierarchia w WBS to nie ozdoba. Poziom 1: projekt. Poziom 2: główne fazy lub deliverables. Poziom 3: mniejsze komponenty. I tak dalej, aż do work packages, najmniejszych jednostek, które można przypisać, oszacować, śledzić.
Na każdym z tych poziomów obowiązuje reguła 100%. Jeśli masz fazę “Design” i podzieliłeś ją na wireframes, prototypy i finalne makiety, te trzy elementy muszą składać się na 100% pracy designu. Jeśli brakuje user research albo testów użyteczności, naruszasz regułę.
Widziałem projekt, gdzie poziom 2 zawierał: Backend, Frontend, Mobile, DevOps, Testing. Wyglądało kompletnie. Dopóki ktoś nie zapytał: a dokumentacja? A szkolenia? A przygotowanie środowiska produkcyjnego? Wszystko to było “gdzieś tam”, ale nie w WBS. Efekt: nikt tego nie kosztował, nie zaplanował, nie przypisał.
Co się dzieje, gdy regułę ignorujesz
Startup technologiczny, rok pierwszy działalności, MVP produktu SaaS. Zespół 8 osób, 6 miesięcy na delivery. Zrobili WBS na podstawie backlogu produktowego. Backlog zawierał features. WBS zawierał features. Nikt nie pomyślał o infrastrukturze, CI/CD, dokumentacji API, polityce prywatności, compliance z RODO.
Po 5 miesiącach produkt był gotowy technicznie, ale nie dało się go wypuścić. Brakowało wszystkiego, co nie było kodem. Kolejne 3 miesiące poszły na dopychanie rzeczy, które nigdy nie trafiły do WBS, więc nikt ich nie oszacował ani nie zaplanował.
PMI w Practice Standard for Work Breakdown Structures pisze wprost: WBS, który nie spełnia reguły 100%, nie nadaje się do użytku. Nie da się na jego podstawie policzyć budżetu, bo brakuje elementów. Nie da się śledzić postępu, bo część pracy jest niewidzialna. Nie da się zrobić analizy ryzyka, bo ryzyko związane z tym, czego nie widzisz, wynosi zawsze 100%.
Kiedy reguła przestaje wystarczać
Reguła 100% mówi “co” musi być w WBS, ale nie mówi “jak” to podzielić. Możesz mieć WBS, który spełnia regułę i nadal jest bezużyteczny, bo poziom szczegółowości jest zły. Work package, który trwa 6 tygodni, to za dużo. Work package, który trwa 2 godziny, to za mało.
W praktyce stosuje się regułę 8/80: work package nie powinien wymagać mniej niż 8 godzin ani więcej niż 80 godzin pracy. To nie jest standard PMI, to empiryczna zasada, która się sprawdza. Ale najpierw musisz spełnić regułę 100%, inaczej 8/80 nie ma sensu.
Widziałem też projekty, gdzie WBS zawierał wszystko, ale było to podzielone tak dziwnie, że nikt nie wiedział, co do czego należy. Integracja API była częścią backendu, ale też częścią testów, ale też częścią dokumentacji. Technicznie 100% było pokryte. Praktycznie nikt nie wiedział, kto za co odpowiada.
Źródła
- Project Management Institute, “Practice Standard for Work Breakdown Structures”, 2nd Edition, PMI, 2006.
- Project Management Institute, “A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, 6th Edition, PMI, 2017.
- Project Management Institute, “The ABC basics of the WBS”, PMI Library, pmi.org.
Zdjęcie: RDNE Stock project / Pexels
