Wyobraź sobie projekt wdrożenia systemu ERP w średniej firmie produkcyjnej. Kierownik projektu przygotował harmonogram w MS Project, podzielił zadania na sprinty, rozpisał spotkania statusowe co dwa tygodnie. Po sześciu miesiącach okazało się, że nikt nie uwzględnił migracji danych ze starego systemu. Nie było tego w budżecie. Nie było w harmonogramie. Było natomiast w zakresie projektu od samego początku – tylko nikt nie zadał sobie trudu, żeby to zobaczyć przed podpisaniem kontraktu.
Work Breakdown Structure to narzędzie, które miało temu zapobiegać. WBS to hierarchiczna dekompozycja zakresu projektu zorientowana na produkty końcowe, a nie na działania. PMBOK Guide definiuje ją jako deliverable-oriented hierarchical decomposition of the work to be executed by the project team. Kluczowe słowo: deliverable. Nie czynność, nie zadanie, nie aktywność – produkt, który ktoś musi odebrać i zatwierdzić.
Skąd się wzięła ta hierarchia
WBS nie urodziła się w startupie. Jej korzenie sięgają przemysłu zbrojeniowego i programów kosmicznych z przełomu lat 50. i 60. ubiegłego wieku. Departament Obrony Stanów Zjednoczonych sformalizował podejście w standardzie MIL-STD-881, który do dziś reguluje sposób przygotowywania WBS dla projektów obronnych. NASA rozwinęła własne podejście w kilku edycjach WBS Handbook, stosowanych przy projektach obejmujących zarówno sprzęt, jak i oprogramowanie oraz dane. Kiedy w latach 90. PMI zaczął wydawać kolejne edycje PMBOK Guide, WBS trafiła do mainstreamu zarządzania projektami jako jeden z centralnych elementów planowania zakresu.
Ciekawostka: zanim trafiłeś na to narzędzie w jakimkolwiek kursie certyfikacyjnym PMP czy PRINCE2, ktoś z NASA używał go do planowania misji, gdzie błąd pominięcia jednego komponentu oznaczał katastrofę dosłownie. W IT rzadko są takie stawki, ale logika jest ta sama.
Reguła 100% – prosta zasada, którą trudno przestrzegać
Sercem WBS jest reguła 100%. Mówi ona, że struktura musi reprezentować całość zakresu projektu – ani mniej, ani więcej. Każdy element nadrzędny musi być sumą wszystkich elementów podrzędnych, a cała WBS musi pokrywać 100% pracy zdefiniowanej w zakresie. Żadna praca spoza zatwierdzonego zakresu nie powinna się w niej pojawić, żadna praca z zakresu nie może zostać pominięta.
W praktyce wygląda to tak: jeśli projekt obejmuje trzy komponenty – aplikację webową, integrację z zewnętrznym API i dokumentację techniczną – to suma pracy na tych trzech gałęziach musi dać 100% całego projektu. Jeśli gdzieś “ginie” migracja danych albo szkolenie użytkowników, to nie jest problem harmonogramu. To jest problem WBS, która nie odzwierciedla pełnego zakresu.
Właśnie tu pojawia się scope creep w swojej najgroźniejszej postaci. Nie wtedy, gdy ktoś jawnie dokłada wymagania w trakcie projektu, ale wtedy, gdy pewna część pracy nigdy nie była widoczna w strukturze i nagle materializuje się jako “dodatkowy zakres” w trzecim kwartale realizacji.
Work package – gdzie teoria spotyka rzeczywistość
WBS dekomponujesz do poziomu work packages, czyli paczek pracy, dla których możesz już sensownie oszacować koszt i czas. Powyżej work package w hierarchii siedzi control account – punkt, w którym zakres, harmonogram i budżet są zintegrowane i gdzie mierzy się postęp metodą earned value.
Tutaj zaczyna się trochę filozofia. Jak głęboko zejść z dekompozycją? Klasyczna odpowiedź z literatury projektowej brzmi: do momentu, gdy element jest wystarczająco mały, żeby przypisać go jednej osobie lub jednemu zespołowi i żeby można było go kontrolować w rozsądnym oknie czasowym. Zbyt płytka WBS pozostawia za dużo niewidocznej pracy. Zbyt głęboka tworzy administracyjny moloch, który nikt nie utrzymuje aktualnym.
Wyobraźmy sobie 15-osobowy zespół, który buduje platformę SaaS dla klienta z sektora finansowego. Jeśli WBS ma 4 poziomy i 200 elementów dla projektu trwającego 9 miesięcy, to statystycznie każdy liść drzewa oznacza mniej niż tydzień pracy jednej osoby. Aktualizowanie tego w Jira staje się projektem samym w sobie. Z kolei WBS spłaszczona do 2 poziomów dla projektu tej skali raczej nie zidentyfikuje luk zakresu, bo zbyt wiele kryje się pod każdym węzłem.
WBS a Scrum – narzędzia, które nie lubią jednej rozmowy
Kiedy wdrażanie Scruma przestaje być rozwiązaniem, a zaczyna być problemem, często widać to właśnie w podejściu do zakresu. Scrum Guide nie przewiduje WBS jako artefaktu. Product Backlog to lista uporządkowanych elementów, nie hierarchiczna dekompozycja deliverables. To zupełnie inne myślenie o zakresie.
Ale te dwa podejścia niekoniecznie muszą się wykluczać. Przy dużych kontraktach fixed-price, gdzie zakres trzeba zdefiniować przed podpisaniem umowy, WBS na poziomie 2–3 poziomów dostarcza tej definicji. Sprinty i backlog zarządzają pracą wewnątrz work packages. Organizacje pracujące w SAFe Framework też używają podobnej logiki – PI Planning operuje na feature’ach i story, ale te muszą gdzieś wynikać z uzgodnionego zakresu programu.
Zarządzanie usługami IT, szczególnie gdy patrzysz na to przez pryzmat ciągłości operacyjnej, też ma swoje odpowiedniki myślenia dekompozycyjnego – tyle że tam bardziej chodzi o mapowanie usług i zależności niż o jednorazową strukturę projektu.
Kiedy WBS naprawdę pomaga
WBS jest przydatna w co najmniej trzech sytuacjach, które dobrze znam z audytów powdrożeniowych. Pierwsza: projekt realizowany przez kilka firm lub zewnętrznych dostawców naraz, gdzie granice odpowiedzialności muszą być zdefiniowane zanim ktokolwiek napisze pierwszą linię kodu. Druga: kontrakt z klientem, który będzie rozliczał zakres element po elemencie i który może odmówić płatności za “nieuzgodniony” deliverable. Trzecia: projekt na tyle złożony, że bez formalnej dekompozycji kierownik projektu nie jest w stanie powiedzieć, ile pracy faktycznie pozostało.
Jeśli żaden z tych warunków nie zachodzi, WBS w pełnej formie może być narzucaniem procedury tam, gdzie wystarczyłoby coś prostszego. Najlepsi project managerowie, których spotkałem, budowali WBS wtedy, gdy pomagała im myśleć o zakresie – nie dlatego, że metodologia tego wymagała.
Pytanie, które warto sobie zadać przed kolejnym projektem: czy twoja definicja zakresu jest na tyle kompletna, że gdybyś jutro dał ją nowemu PM-owi, odgadłby co ma zostać dostarczone bez zadania ani jednego pytania?
Zrodla
- Project Management Institute, “A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, PMI, kolejne edycje od 1996.
- Norman E.S., Brotherton S.A., Fried R.T., “Work Breakdown Structures: The Foundation for Project Management Excellence”, Wiley, 2008.
- Fleming J.F., Poole K.W., “NASA Work Breakdown Structure (WBS) Handbook”, NASA STI Repository, 2016.
- MIL-STD-881, “Work Breakdown Structures for Defense Materiel Items”, Department of Defense, kolejne wersje od 1968.
- PMI, “Practice Standard for Work Breakdown Structures”, Project Management Institute, wydanie drugie, 2006.
Zdjęcie: Nigel Hoare / Unsplash
