Czy Twoje projekty mają skalę Chińskiego Muru?
Sprawdź jak możemy pomóc Ci nimi zarządzać!

Choć od pojawienia się w dniu 31 grudnia 2008 nowej wersji PMBOK® Guide upłynęło już 1.5 roku, to - zwłaszcza od kierowników projektów znających wersję 2004 - nadal spotykam się z pytaniami nt. różnic między tymi edycjami. Duże, istotne,  może rewolucyjne?

Od razu powiem, ze zmiany nie są olbrzymie, lecz jednak dość zasadnicze. Zanim przejdę do szczegółów, na początek kilka zdań o charakterze wprowadzonych zmian. Zmiany z jednej strony mają charakter zmian uspójnieniowych, z drugiej zmian wyjaśniających. Są też oczywiście zmiany dotyczące zawartości. Przykładem zmian spójnościowych jest zmodyfikowany zapis kroków procesów - obecnie w języku angielskim w układzie czasownik - rzeczownik, jak na przykład "Opracuj harmonogram". Drobiazg, lecz naprawdę cieszy! Przykładem zmiany wyjaśniającej jest uproszczenie "bytów" należących do pojęcia "żądanie zmiany". Obecnie jest tylko jedno "change request" , obejmujące działania korygujące, działania zapobiegawcze i naprawy defektów, a nie 4-ry odrębne pojęcia. Inne zmiany tego typu to precyzyjne odróżnienie planu zarządzania projektem i jego elementów składowych od tzw. dokumentów projektowych (ang. project documents), obejmujących wszystkie pozostałe, tj. nie wchodzące do planu zarządzania projektem, informacje, wspomagające kierownika projektu. Jeśli więc ktoś z Was lubi porządek i jasne klasyfikacje - ja należę do takich osób - to i tą zmianę przyjmie z zadowoleniem.

Najważniejsze są oczywiście zmiany i uzupełnienia zawartości o to, czego ewidentnie brakowało oraz usunięcie elementów najmniej sprawdzających się w praktyce. Po pierwsze pojawiły się dwa nowe procesy, których naprawdę brakowało: zbieranie wymagań (ang. collect requirements) oraz identyfikacja interesariuszy (ang. identify stakeholders). Zniknął natomiast proces planowanie zakresu (ang. plan scope), oraz proces: Opracowanie wstępnej deklaracji zakresu, którego wyjściem była - jak pewnie pamiętacie - tajemnicza: wstępna deklaracja zakresu (ang. preliminary scope statement). Ja w żadnym projekcie nie zastosowałem takiego dokumentu, wy pewnie też - teraz więc problem mamy rozwiązany z pomocą brzytwy Ockhama. Zniknięcie planowania zakresu, którego wyjściem był plan zarządzania zakresem także uważam za bardzo rozsądną zmianę. Pozwoliło to bowiem na wprowadzenie spójnego podejścia do planów zarządzania: zakresem, czasem i kosztem. Wg Edycji 2008 wszystkie te plany są tworzone w ramach procesu: Opracowanie planu zarządzania projektem; żaden z nich nie stanowi też wyjścia z procesów zarządzania zakresem, czasem i kosztem. Teraz jest więc jednolicie, prosto i - wg mnie - bardzo praktycznie.

Kolejna upraszczająca i niezwykle praktyczna zmiana dotyczy zarządzania zamówieniami.  Zamiast 6-ciu procesów, w tym takiego "dziwoląga", jak oczekiwanie na odpowiedź dostawcy (ang. request seller responses), gdzie naprawdę nie działo się nic, poza odebraniem oferty od dostawcy, mamy 4-ry procesy. Dwa procesy planistyczne zostały połączone w jeden: planowanie zamówień (ang. plan procurements), a dwa procesy dotyczące wyboru dostawcy, także zostały połączone w jeden: przeprowadzenie zamówień (ang. conduct procurements). I tu brzytwę Ockhama zastosowano z bardzo pozytywnym skutkiem.

Inna modyfikacja zawartości, choć także o charakterze porządkującym, to doprecyzowanie zawartości Karty projektu (ang. Project Charter) oraz Deklaracji zakresu projektu (ang. Project Scope Statement). Jest więc teraz jasne, co wg PMBOK® Guide zawierają oba te dokumenty, czym się różnią i w czym są podobne.
Edycja 2008 więcej miejsca poświęca zagadnieniom "miękkim" (ang. soft skills). Przejawem tego jest m.in. rozbudowanie dwóch procesów zarządzania zasobami ludzkimi: rozwijania zespołu projektowego (ang. develop project team) oraz zarządzanie zespołem projektowym (ang. manage project team) o wymienione explicite etapy rozwoju zespołu oraz metody rozwiązywania konfliktu. Ponadto w nowym załączniku (Appendix G) zwięźle opisane są umiejętności interpersonalne (ang. interpersonal skills).

Są oczywiście i takie zmiany, które uważam za dyskusyjne i kontrowersyjne. Należy do nich przesunięcie procesów: zarządzanie zespołem projektowym (ang. Manage project team) oraz zarządzanie oczekiwaniami interesariuszy (ang. manage stakeholder’s expectations) z grupy procesów monitorowania i kontroli do grupy procesów: realizacja. Wg mnie te procesy znajdują się w obu tych grupach procesów - dotyczą i realizacji i kontroli oraz monitorowania, stąd też trudność z ich precyzyjnym sklasyfikowaniem. Także jeśli spojrzycie na listę wyjść (ang. output) z obu tych procesów i porównacie z wyjściami procesów znajdujących się w grupie procesów monitorowanie & controlling, to natychmiast odkryjecie ich olbrzymie podobieństwo. Są one bowiem niemal takie same, co oznacza, ze typowe wyjścia procesu kontrolnego są w Edycji 2008 dla tych dwóch procesów umieszczone w grupie procesów realizacji. Tym razem zabrakło więc tej spójności, która tak chwaliłem w odniesieniu do innych modyfikacji w Edycji 2008.

I na koniec kilka mniejszych modyfikacji:

• Edycja 2008 mocno podkreśla odróżnienie organizacji realizującej projekt (ang. performing organization) od organizacji zamawiającej projekt (ang. requesting organization) oraz fakt, że zarządzanie projektem wymaga znajomości decydentów w organizacji
• W Edycji 2008 zarządzanie projektem jest umieszczone w kontekście zarządzania portfelem projektów oraz zarządzania programem
• Czynniki środowiskowe przedsiębiorstwa (ang. Enterprise environmental factors) oraz zasoby procesów organizacyjnych (ang. Organizational process assets) są opisane tylko raz we wstępnej części (odpowiednio w rozdziale 1-szym i 2-gim); przy opisie poszczególnych procesów stanowią tylko wejścia i wyjścia, uzupełnione konkretnymi przykładami
• Potrójne ograniczenie (ang. triple constraint) z  wcześniejszych wersji jest zastąpione ograniczeniami projektowymi, obejmującymi: zakres, harmonogram, budżet, jakość, zasoby i ryzyko
• Usuniecie techniki diagramowania strzałkowego (ang. Activity-on-Arrow - AOA) z listy narzędzi stosowanych do budowy diagramu projektu.

Podsumowując: zmiany nie są rewolucyjne, lecz ewolucyjne, upraszczające kilka kwestii i dające spójność w innych. Jeśli znacie Edycję 2004, to naprawdę szybko i sprawnie przestawicie się na Edycję 2008.  A biorąc pod uwagę że w 2012 czeka nas nowa edycja, powiedziałbym: tak trzymać.