+48 512 364 075

WBS – podstawy obsługi

Marcin Żmigrodzki

WBS (work breakdown structure), a po Polsku SPP (struktura podziału prac), to nic innego jak lista produktów, które zamierzamy dostarczyć w projekcie i jednocześnie podstawowe narzędzie komunikacji zespołu projektowego.   –Grupuje on w logiczny sposób elementy projektu i definiuje oraz porządkuje całkowity zakres projektu.

Dobrą metaforą jest stwierdzenie, że po pierwsze WBS jest jak koszyk z zakupami.

Nie ważne, ile czasu poświęciliśmy na zakupy i ile nas kosztowały, ważne co mamy w koszyku po projekcie. Na etapie planowania WBS nie analizujemy, w którym momencie, co będzie dostarczane, ile będzie kosztować, kto to wykona, jakie pojawią się ryzyka.
Massawa - szkolenie z zarządzania projektami

WBS tworzy się, dekomponując cele projektu na coraz mniejsze elementy zakresu, mając jednocześnie w głowie koncepcję realizacji projektu. Na przykład: celem projektu jest uruchomienie witryny firmowej, ale założono w koncepcji, że zostanie ona zintegrowana z wewnętrznym portalem intranetowym, aby wszyscy pracownicy mogli edytować treści. To implikuje dostarczenie poniższych produktów (dobrą praktyką jest definiowanie produktów w trybie dokonanym):

  1. Uruchomiony portal internetowy
  2. Skonfigurowane konta pracowników
  3. Przeszkoleni pracownicy
  4. Opublikowane treści

W kolejnym kroku rozbijamy każdy z produktów na mniejsze. Na przykład:

  1. Uruchomiony portal internetowy
    1. Zaprogramowane nowe moduły
    2. Skonfigorwane serwery
    3. Przetestowany portal
    4. Opublikowany portal
  2. Skonfigurowane konta pracowników
    1. Skonfigurowane konta w intranecie
    2. Skonfigurowane konta w internecie
  3. Przeszkoleni pracownicy
    1. Przeszkoleni administratorzy
    2. Przeszkoleni redaktorzy
  4. Opublikowane treści
    1. Opublikowane treści z działu marketingu
    2. Opublikowane treści z działu produktów
    3. Opublikowane treści z działu technologii
    4. Opublikowane treści z działu ogólne

Drugą interesującą metaforą jest porównanie WBS do drzewa: pień to cały projekt, gałęzie to produkty, a liście to pakiety robocze, które musimy wykonać, aby dostarczyć dany produkt. Takie podziały można ponawiać wielokrotnie, aż do momentu, gdy możemy jednoznacznie przypisać odpowiedzialnego, da się wiarygodnie oszacować koszt i czas potrzebny na wykonanie, nie ma nieporozumień co do zawartości danego produktu.

Do tak skonstruowanego WBS można w takim razie dopisać liście, czyli pakiety robocze prowadzące do dostarczenia produktów, np.:

  1. Uruchomiony portal internetowy
    1. Zaprogramowane nowe moduły
      1. Zebranie wymagań funkcjonalnych
      2. Specyfikacja zmian
      3. Rewizje specyfikacji
      4. Programowanie
        1. grupy dyskusyjnej
        2. bloczków strony głównej
        3. ankiet
      5. Testy
      6. Testy akceptacyjne

Kryteriów podziału produktów i pakietów roboczych w ramach WBS może być wiele, np.:

  • Produkty (rezultaty),
  • Funkcje,
  • Fazy projektu,
  • Miejsce realizacji,
  • Zespół realizacyjny.

Wszystko zależy od logiki projektu i potrzeb informacyjnych jego uczestników.

Dobrze ułożony WBS powinien spełniać szereg kryteriów jakościowych:

  • zrozumiałość – pakiety prac powinny być łatwo opisywalne i łatwe do zrozumienia, WBS służy przede wszystkim komunikacji,
  • zarządzalność – do poszczególnych pakietów prac da się przypisać osoby odpowiedzialne za ich wykonanie (wykonawców) oraz osoby podejmujące decyzję,
  • możliwość oszacowania terminów / kosztów – istnieje możliwość oszacowania wykonania każdego pakietu prac w zakresie terminu oraz kosztów,
  • niezależność – pakiety prac powinny być łatwo rozróżnialne od innych, ta sama praca nie może być zawarta w dwóch pakietach,
  • możliwość integracji – pakiety prac powinny być możliwe do zagregowania (w zakresie kosztów, technologii, logiki),
  • uzasadnienie – każdy pakiet musi być powiązany z celami projektu,
  • możliwość pomiaru – pakiety prac powinny umożliwiać dokonanie pomiaru wykonania prac, które reprezentują,
  • adaptowalność – pakiety prac powinny być odpowiednio elastycznie skonstruowane tak, aby możliwa był modyfikacja WBS (dodanie nowego pakietu lub eliminacja pakietu).

Krzywa bólu

Koszt zmian zakresu rośnie w czasie. Dużo niższy jest na etapie inicjacji, niż na etapie tworzenia koncepcji, niż na etapie realizacji, a już olbrzymi na etapie testów użytkownika i eksploatacji. Wystarczy wyobrazić sobie, ile kosztuje przesunięcie domu o 2 metry na etapie wytyczania działki budowlanej, a ile na etapie kładzenia kafelków na balkonach.

Tak samo jest w projektach informatycznych, organizacyjnych, szkoleniowych i innych. Zmiana algorytmu na etapie zbierania wymagań kosztuje wielokrotnie mniej, niż na etapie odbioru użytkownika. Wdrożenie innej struktury organizacyjnej jest dużo prostsze na etapie rysowania pierwszych diagramów, niż na etapie rekrutacji i wdrażania nowych pracowników.

 

krzywa bóluDobrze wyraża to tzw. krzywa bólu. Pokazuje ona dwa wykresy:

  • projekt dobrze zaplanowany – na planowanie trzeba poświęcić wysiłek, niekiedy prowadzi to do konfliktów, szczególnie gdy występuje presja klienta lub sponsora na szybsze rozpoczęcie prac. Bowiem planowanie zajmuje czas, ale później w trakcie realizacji stokrotnie sie zwróci, pozwalając uniknąć wielu błędów, jak nierealny harmonogram, niewykonalna koncepcja, ryzyka zabijające projekt, czy niska jakość.
  • projekt źle zaplanowany – gdy nie poświęcimy czasu na precyzyjne planowanie, możemy na starcie odnieść wrażenie, że projekt rusza bardzo sprawnie: ludzie od razu zabrali się za robotę, pojawia się zaangażowanie, na horyzoncie majaczą pierwsze rezultaty. Jednak z czasem zaczyna się okazywać, że ów horyzont coraz sprawniej… zaczyna uciekać, piętrzące się zmiany, konflikty, problemy z dotrzymaniem terminów i innych zobowiązań powodują systematyczny wzrost bólu. Sumarycznie projekt, który ruszył „zbyt gładko” kosztuje nas więcej energii i emocji, niż ten, który okupiliśmy zwiększonym wysiłkiem na początku.

Możliwość komentowania jest wyłączona.

Kontakt
Interesują Cię nasze szkolenia? Skontaktuj się z nami: tel.:+48 512 364 075 e-mail: szkolenia@octigo.pl Formularz kontaktowy

Biuletyn

 

Chcesz wiedzieć, o czym piszemy na blogu, co nas fascynuje, co nowego dzieje się w Octigo? Zapisz się na nasz biuletyn.

Wypełniając powyższy formularz, zgadzam się na przetwarzanie podanych danych do celów marketingowych przez firmę Octigo sp. z o.o. Twój e-mail będzie przechowywany wyłącznie w naszej bazie, w każdej chwili możesz wycofać zgodę na przetwarzanie Twoich danych, Twój e-mail nie jest udostępniany innym podmiotom, wysyłamy biuletyn e-mailowy nie częściej niż 1-2 razy w miesiącu.

 
 
Profil na Google+ PMI, PMBOK, PMP, PgMP are registered mark of the Project Management Institute, Inc.