Zarzdzanie projektami IT.

Przewodnik po metodykach
Autor: Adam Koszlajda
ISBN: 978-83-246-1804-0
Format: 158235, stron: 360

Przewodnik po metodykach, ktre musisz pozna!

Jak wybra metod dziaania odpowiedni dla konkretnych projektw i
organizacji?
Co pozwala skutecznie zrealizowa stworzone plany dziaania?
Gdzie szuka wiedzy tajemnej z zakresu metodyk zarzdczych, wytwrczych
i organizacyjnych?
Waciwe zaplanowanie i doprowadzenie do koca duego projektu informatycznego
nie jest rzecz atw. Czsto dziaanie takie wymaga wsppracy wielu ludzi, zespow,
a nawet caych firm, precyzyjnego okrelenia celw i struktury produktu kocowego,
jak rwnie rodkw i czasu niezbdnych do realizacji projektu. W zalenoci od jego
przeznaczenia oraz specyfiki projekt taki zmusza do wdroenia odpowiedniego planu
dziaania, obejmujcego wszystkie etapy, metody oraz techniki, pozwalajce doprowadzi
do satysfakcjonujcego wszystkich finau prac. Wanie temu suy wybr konkretnej
metodyki, zapewniajcej sensowny podzia zada oraz zakresu odpowiedzialnoci
poszczeglnych osb i pynne przechodzenie midzy kolejnymi etapami projektu.
Przekrojowy opis takich metodyk, stosowanych w brany IT, znajdziesz wanie na
kartach ksiki, ktr trzymasz w rkach.
Zarzdzanie projektami IT. Przewodnik po metodykach to poradnik dla wszystkich
tych, ktrzy chcieliby dowiedzie si, czym rni si kompleksowe podejcia do
rozwizywania konkretnych problemw i jak dobra metodyk odpowiedni dla ich
wasnych projektw. Oprcz oglnych wskaza oraz starannie opracowanych opisw
kolejnych etapw dziaania, technik czy procesw znajdziesz tu take:
przykadowe realizacje projektw IT wedug konkretnych metodyk,
praktyczne wskazwki i rady,
wywiady z osobami wykorzystujcymi na co dzie te rozwizania.
Cao urozmaicaj sentencje Wujka dobra rada, podkrelajce najistotniejsze aspekty
prezentowanych zagadnie, oraz przejrzyste, czsto humorystyczne ilustracje. Czytajc
t ksik, poznasz:
metodyki zarzdcze Prince2 oraz PMBoK4
metodyki wytwrcze RUP i MSF
metodyki adaptacyjne eXtreme Programming i SCRUM
metodyki organizacyjne CMMI, Six Sigma, ITIL lub COBIT
kilka przykadw sposobw czenia tych metodyk

Spis treci
Wstp .............................................................................................. 7

Cz I

Metodyki zarzdcze a praktyka ..................................... 11

Rozdzia 1. PRoject IN Controlled Environment Prince2 ................................ 13

Szczypta historii ............................................................................................................. 13
Procesy ........................................................................................................................... 14
Komponenty ................................................................................................................... 17
Techniki .......................................................................................................................... 21
Zarzdzanie dokumentacj ............................................................................................. 24
Dostosowywanie do potrzeb organizacji ........................................................................ 25
Certyfikacja .................................................................................................................... 25
Podsumowanie ................................................................................................................ 26
Rozmowa z... .................................................................................................................. 27

Rozdzia 2. Project Management Body of Knowledge PMBoK ....................... 31

Szczypta historii ............................................................................................................. 31
Obszary wiedzy .............................................................................................................. 33
Procesy i techniki ........................................................................................................... 39
Dostosowanie do potrzeb organizacji ............................................................................. 66
Certyfikacja .................................................................................................................... 66
Podsumowanie ................................................................................................................ 67

Cz II

Metodyki wytwrcze a praktyka ................................... 69

Rozdzia 3. Rational Unified Process (RUP) ...................................................... 73

Szczypta historii ............................................................................................................. 73
Proces ............................................................................................................................. 74
Dyscypliny RUP ............................................................................................................. 76
Abecado metodyki RUP ................................................................................................ 79
Adaptacja RUP do potrzeb organizacji ........................................................................... 80
Podsumowanie RUP ....................................................................................................... 81
Rozmowa z... .................................................................................................................. 82
Przykad Prince2 i RUP BlogSerwis .......................................................................... 85

Zarzdzanie projektami IT. Przewodnik po metodykach

Rozdzia 4. Microsoft Solution Framework (MSF) ............................................ 105

Szczypta historii ........................................................................................................... 105
Proces ........................................................................................................................... 106
Model zespou .............................................................................................................. 107
Faza Wizji ..................................................................................................................... 108
Faza Planowania ........................................................................................................... 109
Faza Konstrukcji ........................................................................................................... 112
Faza Stabilizacji ............................................................................................................ 116
Faza Wdroenia ............................................................................................................ 120
MSF > MOF ................................................................................................................. 121
Trjkt negocjacyjny .................................................................................................... 123
Dyscypliny zarzdcze ................................................................................................... 125
Certyfikacja .................................................................................................................. 126
Podsumowanie MSF a RUP .................................................................................... 126

Rozdzia 5. Przykad PMBoK i MSF wdroenie systemu BI ........................... 129

Cz III Metodyki adaptacyjne a praktyka ............................... 177

Rozdzia 6. eXtreme Programming .................................................................. 179
Szczypta historii ........................................................................................................... 179
Role .............................................................................................................................. 180
Proces ........................................................................................................................... 180
Wdroenie .................................................................................................................... 186

Rozdzia 7. Scrum .......................................................................................... 189

Szczypta historii ........................................................................................................... 190
Role .............................................................................................................................. 190
Proces ........................................................................................................................... 191
Podsumowanie .............................................................................................................. 196
Rozmowa z... ................................................................................................................ 197

Rozdzia 8. Joel o oprogramowaniu ................................................................. 205

Rozdzia 9. Przykad Scrum BlogSerwis ...................................................... 209

Cz IV Metodyki organizacyjne a praktyka ............................. 223

Rozdzia 10. Capability Maturity Model Integration (CMMI) .............................. 225
Szczypta historii ........................................................................................................... 226
Poziomy CMMI ............................................................................................................ 228
Procesy ......................................................................................................................... 229
Podsumowanie .............................................................................................................. 235

Rozdzia 11. Six Sigma .................................................................................... 239

Szczypta historii ........................................................................................................... 240
Wdroenie .................................................................................................................... 241
Certyfikacja .................................................................................................................. 245
Podsumowanie .............................................................................................................. 245

Rozdzia 12. Information Technology Infrastructure Library (ITIL) ....................... 247

Szczypta historii ........................................................................................................... 247
Role .............................................................................................................................. 249
Procesy ......................................................................................................................... 251
Wdroenie .................................................................................................................... 254

Spis treci

5
Certyfikacja .................................................................................................................. 256
Podsumowanie .............................................................................................................. 257
Rozmowa z... ................................................................................................................ 258

Rozdzia 13. Control Objectives for Information and related Technology (COBIT) 263
Szczypta historii ........................................................................................................... 264
Role .............................................................................................................................. 265
Procesy ......................................................................................................................... 266
Certyfikacja .................................................................................................................. 273
Podsumowanie .............................................................................................................. 274

Cz V

Rozwizania kombinowane ......................................... 275

Podsumowanie ............................................................................. 281

Dodatki ..................................................................................... 283

Dodatek A Lista wszystkich procesw PMBoK ............................................... 285
Dodatek B Specyfikacja dyscyplin RUP z Rational Method Composer (RMC) ... 321
Dodatek C Lista wszystkich procesw ITIL ..................................................... 325
Dodatek D Lista wszystkich procesw COBIT ................................................. 331
Spis rysunkw .............................................................................. 335
Spis tabel .................................................................................... 337
rda .......................................................................................... 339
Skorowidz .................................................................................... 343

Rozdzia 2.

Project Management
Body of Knowledge
PMBoK
Podejcie PMBoK jest czsto przedstawiane jako metodyka PMI, czyli metodyka
organizacji Project Management Institute zrzeszajcej specjalistw z dziedziny zarzdzania projektami. PMBoK koncentruje si na zebraniu i przedstawieniu dobrych praktyk
zwizanych z zarzdzaniem projektami w ramach zdefiniowanych obszarw wiedzy.
W pewnym sensie PMBoK jest podejciem konkurencyjnym w stosunku do Prince2
i ze wzgldu na nieco wiksz swobod implementacji jest czciej stosowany przez
due korporacje z sektora prywatnego. Dodatkowo PMBoK wkracza w obszary, ktrych
Prince2 nie obejmuje, takie jak zarzdzanie zasobami ludzkimi oraz zaopatrzeniem.
PMBoK w wersji czwartej definiuje pi grup procesw, takich jak procesy rozpoczcia,
planowania, realizacji, kontroli i zakoczenia. Kady z tych procesw naley rwnie
do jednego z dziewiciu obszarw wiedzy, takich jak zarzdzanie integralnoci projektu, zakresem, czasem, kosztami, jakoci, zasobami ludzkimi, komunikacj, ryzykiem
i zaopatrzeniem.

Szczypta historii
Organizacja PMI powstaa w USA w 1969 roku jako organizacja non profit zrzeszajca
profesjonalistw rnych specjalnoci w celu wyspecyfikowania standardowych praktyk zarzdczych. W 1987 roku opublikowana zostaa pierwsza edycja PMBoK, ktra bya
rezultatem prac wykonanych we wczesnych latach 80. W roku 1998 American National
Standards Institute (ANSI) zaakceptowa to rozwizanie jako narodowy standard zarzdzania projektami, a Institute of Electrical and Electronics Engineers (IEEE) zaadaptowa

32

Cz I Metodyki zarzdcze a praktyka

to podejcie jako standard 14901. Od tej pory, co okoo 4 lata pojawiaj si kolejne
aktualizacje tej metodyki ( w latach 1996, 2000 i 2004). Ostatnia, czwarta edycja ujrzaa
wiato dzienne 31 grudnia 2008 roku.
Wersja czwarta nie zawiera rewolucyjnych zmian w stosunku do wersji trzeciej, ale
mona zauway kilka pozytywnych zmian ewolucyjnych. Oto one.
Lepsze zarzdzanie interesariuszami, ktre pojawia si ju w grupie procesw
rozpoczcia jako nowy proces o nazwie 10.1. Identyfikacja interesariuszy.
Z grupy procesw rozpoczcia znikn proces 4.3. Opracowanie wstpnego
zakresu projektu (ang. Develop preliminary scope statement). Pokrywa si
on z procesem 5.1. Planowanie zarzdzania zakresem projektu, ktry
w PMBoK4 nazywa si ju 5.1. Planowanie zarzdzania zakresem projektu.
Nie jest to tylko zmiana nazwy, ale przejaw bardziej dojrzaego podejcia
do zarzdzania wymaganiami projektowymi. Pojawia si tu ciekawa technika
Matrycy ledzenia wymaga (ang. Requirements Traceability Matrix).
Unifikacja pewnych elementw przekazywanych pomidzy procesami.
Przykadowo pojawia si jeden, kluczowy plan zarzdzani projektem zamiast
oddzielnych planw do zarzdzania poszczeglnymi obszarami wiedzy (np. plan
zarzdzania zakresem, harmonogramem, kosztem itd.). Analogicznie pojawio
si bardziej oglne danie zmiany, ktre zawiera w sobie rekomendowane
dziaania naprawcze, prewencyjne i napraw defektw. Tego typu podejcie
jest o wiele bardziej praktyczne i umoliwia wiksz swobod w implementacji
tych mechanizmw.
Znacznemu uproszczeniu i generalizacji uleg obszar wiedzy dostaw. PMBoK4
przyj tutaj nowy model Planowanie>Wykonanie>Administrowanie>
Zamknicie. Dodatkowo wyspecyfikowane zostay nowe podtypy kontraktw
o ustalonej cenie. Nie wiadomo jednak, czy na polskim rynku bd one miay
znaczenie praktyczne.
Technika Uzyskanej Wartoci (ang. Earned Value Technique EVT), ktra
bya czci techniki analizy miar wydajnociowych w procesie 7.3. Kontrola
kosztw, staa si penoprawn technik Zarzdzania Uzyskan Wartoci
(ang. Earned Value Management EVM). Technika ta ulega rwnie pewnemu
rozwiniciu i pojawi si nowy indeks wydajnoci niezbdnej do zakoczenia
projektu (ang. To-Complete Performance Index TCPI).
Uporzdkowaniu ulego nazewnictwo wszystkich procesw oraz ich numeracja,
ktra bazuje ju wycznie na numerach rozdziaw i podrozdziaw.

Standard IEEE Std 1490-1998 zosta zaktualizowany w 2004 (!) roku do IEEE Std 1490-2003.

Rozdzia 2. Project Management Body of Knowledge PMBoK

33

Obszary wiedzy
PMBoK skada si z czterdziestu dwch procesw, z ktrych kady przynaley do jednej
z piciu grup procesw i jednego z dziewiciu obszarw wiedzy. Kady z procesw
posiada numer gwny od 4. do 12., ktry wskazuje okrelony obszar wiedzy2, i poboczny
numer porzdkowy (np. proces 5.2 wskazuje drugi proces z obszaru wiedzy o nazwie
Zakres opisanego w 5. rozdziale). Oto poszczeglne obszary wiedzy.

Obszar wiedzy
Integracja (rozdzia 4.)
Ten obszar wiedzy jest odpowiedzialny za oglne, wysokopoziomowe kwestie zarzdcze
zwizane z realizacj projektu informatycznego, a szczeglnie za:
kwestie zwizane z uruchomieniem projektu (np. zdobycie mandatu na realizacj
projektu) 4.1,
przygotowanie planu zarzdzania projektem 4.2,
zarzdzanie biecymi pracami projektowymi 4.3,
kontrol prac projektowych i zintegrowane zarzdzanie zmian 4.4, 4.5,
zamknicie projektu 4.6.
Integracja to codzienne wybory miejsca koncentracji zasobw i wysiku, wyprzedzenie
moliwych kopotw i zarzdzanie nimi, zanim stan si krytyczne.

Integrowa si! Integrowa rzecze Najlepszy Kierownik Projektu.

Numery obszarw wiedzy s zwizane z numerami rozdziaw w oficjalnych podrcznikach PMBoK.

Cz I Metodyki zarzdcze a praktyka

34

Obszar wiedzy
Zakres (rozdzia 5.)
Ten obszar wiedzy skupia si na zarzdzaniu zakresem funkcjonalnoci projektu, a szczeglnie na tworzeniu:
definicji zakresu projektu wraz z struktur wytwarzanych produktw (ang. Work
Breakdown Structure) 5.1, 5.2, 5.3,
sformalizowanych mechanizmw weryfikacji i kontroli zakresu projektu
5.4, 5.5.
Ten obszar wiedzy PMBoK czy w sobie tematy, ktrymi zajmuj si procesy Zarzdzanie Zakresem Etapu (ZE) i Zarzdzanie Wytwarzaniem Produktw (WP) w Prince2.

Inynierowie z firmy produkujcej auta otrzymali plany nowego, eksportowego modelu

auta i w trakcie analizy zauwayli wymg koniecznoci zamontowania tylnych szyb
odpornych na prdko 50 km/h! 50 km/h? Przecie na biegu wstecznym auto nigdy nie
osignie takiej prdkoci! Zgodnie stwierdzono wic, e w celu redukcji kosztw zamontowane zostan inne szyby o gorszych parametrach.
Inynierowie pracowali w pocie czoa przez wiele dugich miesicy i to niejeden raz po
godzinach. Jak kady projekt, ten te mia swoje dobre i ze chwile, ale w kocu udao
si skonstruowa pierwszy prototyp, ktry pomylnie przeszed pierwsz seri testw
terenowych. Podjto decyzj o uruchomieniu produkcji i wyprodukowano pierwsz setk
piknych, czerwonych, lnicych nowych aut; chopcy pana Stefana przez cay dzie polerowali je na parkingu firmowym. Z powodzeniem zamknito projekt i wypacono premie,
a po tygodniu zadzwoni telefon z zagranicy
Co wycie zrobili!!!!
Nowe auta.
Wszystkie tylnie szyby powybijane! Co my teraz mamy zrobi?
Jak to powybijane!?
Wanie cignlimy je z lawety kolejowej! Bdziemy musieli jako zaatwi
t spraw u nas, lokalnie klienci czekaj
Zaraz, zaraz Transport kolejowy!?
Tak! Przecie pisalimy, e tylnie szyby maj wytrzymywa szybko 50km/h.
No wanie. Po co?
Po co ???!!! Przecie te auta s ustawiane na wagonach tyln szyb
do przodu!!! Wystarczyo TYLKO wykona to, co zapisalimy! Hrrrr

Rozdzia 2. Project Management Body of Knowledge PMBoK

35

Obszar wiedzy
Czas (rozdzia 6.)
Ten obszar wiedzy to wszystkie dziaania zwizane z wykonaniem projektu w zaoonym
terminie, o ile zmianie nie ulegy przyjte zaoenia oraz zakres. Szczegowo przyjmuje
on prost sekwencj zdarze:
zdefiniowanie zbioru planowanych dziaa 6.1,
ustanowienie wzajemnych zalenoci czasowych pomidzy tymi dziaaniami
(co musi by zrobione najpierw, a co potem, jakie dziaania mog by
wykonywane rwnoczenie) 6.2,
oszacowanie potrzeb zasobowych i czasu trwania poszczeglnych dziaa
6.3, 6.4,
stworzenie harmonogramu projektu oraz jego kontrola 6.5, 6.6.
Wszystkie te procesy z wyjtkiem ostatniego nale do grupy procesw planistycznych.

Obszar wiedzy
Koszt (rozdzia 7.)
Projekt informatyczny jest inwestycj, czyli kosztami, ktre w duszej perspektywie maj
przynie organizacji zysk. Aby projekt zakoczy si powodzeniem, konieczne jest
waciwie zarzdzanie budetem, czyli:
szacowanie 7.1,
zaplanowanie (stworzenie bazowej wersji budetu) 7.2,
kontrola 7.3.
Wszystkie te procesy z wyjtkiem ostatniego nale do grupy procesw planistycznych.

Obszar wiedzy
Jako (rozdzia 8.)
PMBoK proponuje nastpujce procesy w celu zapewnienia waciwego zarzdzania
jakoci:
zaplanowanie sposobu zapewniania odpowiedniej jakoci w projekcie 8.1,
wdroenie tego planu poprzez systematyczne wykonanie rutynowych
czynnoci 8.2,
kontrol mechanizmw zapewnienia jakoci 8.3.

Obszar wiedzy
Zasoby ludzkie (rozdzia 9.)
Ten obszar wiedzy opisuje szereg dobrych praktyk zwizanych z zarzdzaniem ludmi
postrzeganymi jako pojedyncze osoby i zespoy. Oznacza to:

36

Cz I Metodyki zarzdcze a praktyka

zaplanowanie potrzeb zasobowych 9.1,

procesy tworzenia zespow ludzkich, ich rozwj i zarzdzanie nimi 9.2,
9.3, 9.4.

Rekrutacja waciwych osb to jeden z najwaniejszych i najtrudniejszych procesw

w trakcie przygotowania do uruchamiania projektu. Jednym z ciekawszych artykuw
na ten temat jest przetumaczony na jzyk polski Partyzancki poradnik rekrutacji Joela
Spolskyego3. Jego gwnym przesaniem jest rada, by rekrutowa tylko i wycznie osoby
bystre i realizujce cele.

Przy okazji tematyki kadrowej warto rwnie nadmieni o niezwizanym z PMBoK

procesie efektywnoci zespoowej Kena Blancharda, ktry opisuje cztery poziomy gotowoci pracownikw.
R1 pracownik o niskich kompetencjach, ktry na swoim koncie nie ma
wikszych sukcesw i dlatego nie jest zmotywowany do pracy.
R2 pracownik o niskich kompetencjach, ktry nie moe samodzielnie
wykonywa zada, ale jest bardzo zmotywowany do ich wykonania.
R3 pracownik o duych kompetencjach, ktry moe samodzielnie wykona
zadania, ale brakuje mu motywacji z powodu braku we wasne siy lub znudzenia.
R4 pracownik o wysokich kompetencjach i chciach, ktry potrafi i chce
samodzielnie wykonywa zadania.
Ken Blanchard opisuje rwnie cztery style przywdztwa (rysunek 4).
S1 instruowanie to suche przekazanie maych, czstkowych zada
do wykonania i rozliczenie z ich wykonania.
S2 konsultowanie to rwnie przekazanie zada, ale skoncentrowane
na utrzymaniu wysokiej motywacji pracownika.
S3 wspieranie koncentruje si na waciwym zmotywowaniu pracownika,
ktry sam wie, jakie zadania naley wykona.
S4 delegowanie to styl, w ktrym pracownik wie, co naley zrobi, i jest
zmotywowany do samodzielnego podjcia odpowiedzialnoci.
Technika przywdztwa sytuacyjnego koncentruje si na waciwym dopasowaniu poziomu
gotowoci do stylu przywdztwa, poniewa nie mona jednej miary przykada do wszystkich osb. Jak atwo si domyli, delegowanie zoonych zada pracownikom o niskich

http://polish.joelonsoftware.com/Articles/Interviewing.html

Rozdzia 2. Project Management Body of Knowledge PMBoK

37

Rysunek 4.
Model przywdztwa
zespoowego
Kena Blancharda

rdo: Blanchard International Polska - http://www.blanchard.pl

kompetencjach doprowadzi do katastrofy, a szczegowe instruowanie dowiadczonych

pracownikw demotywuje ich do pracy. Model ten koncentruje si rwnie na rozwoju
kadego pracownika i zwikszeniu jego poziomu gotowoci.

Obszar wiedzy
Komunikacja (rozdzia 10.)
Ten obszar wiedzy koncentruje si na zapewnieniu waciwej komunikacji z interesariuszami projektu. Szczegowo oznacza to:
identyfikacj kluczowych interesariuszy w trakcie inicjacji projektu 10.2,
stworzenie planu komunikacji z interesariuszami projektu 10.2,

Cz I Metodyki zarzdcze a praktyka

38

waciw dystrybucj informacji i zarzdzanie interesariuszami 10.3, 10.4,

przygotowanie i dystrybucj kontrolnych raportw wydajnociowych 10.5.

Naley zauway, e w dzisiejszych czasach dobra komunikacja nie jest moliwa bez
waciwych systemw informatycznych. Bardzo wskazane jest posiadanie kompleksowego rozwizania intranetowego, ktre umoliwi wspdzielenie wiedzy projektowej
wewntrz firmy (ang. Enterprise Project Management). Kada z firm wybiera system
wedug wasnych potrzeb, a popularno poszczeglnych rozwiza jest do rozproszona,
co zobrazowano na rysunku 5.
Rysunek 5.
Wynik ankiety
Jakich systemw
EPM uywasz?
Pierra-Jeana
4
Cherreta

Inn ciekaw alternatyw dla rozwiza tego typu jest firmowe wiki rozwijane na bazie
rozwiza darmowych, takich jak MediaWiki, na ktrej bazuje Wikipedia, lub rozwiza
odpatnych, np. Confluence.
W rozproszonych zespoach warto dodatkowo zainwestowa w narzdzia wsppracy
zdalnej (ang. collaboration tools), takie jak WebEx5, GoToMeeting, MS Office Live
Meeting (poprzednio PlaceWare) lub Adobe Connect (poprzednio Breeze).

Obszar wiedzy
Ryzyko (rozdzia 11.)
W tym obszarze zarzdzanie ryzykiem projektowym odbywa si przy uyciu rejestru
ryzyk. Dziaania te polegaj na:
4

Na podstawie ankiety Jakich systemw EPM uywasz? uruchomionej przez Pierra-Jeana Cherreta
w serwisie spoecznociowym Plaxo.

O skali tego rynku niech wiadczy zakup, jakiego dokonao Cisco 15 marca 2007 roku, ktre za drobne
3,2 miliarda dolarw przejo firm WebEx.

Rozdzia 2. Project Management Body of Knowledge PMBoK

39

stworzeniu planu zarzdzania ryzykiem 11.1,

identyfikacji, analizie i planowaniu odpowiedzi na ryzyka 11.2, 11.3, 11.4, 11.5,
monitorowaniu i kontrolowaniu ryzyk projektowych 11.6.
Wszystkie te procesy z wyjtkiem ostatniego nale do grupy procesw planistycznych.

Obszar wiedzy
Dostawa (rozdzia 12.)
Dostawa to zakup lub zdobycie produktw i usug spoza zespou projektowego. Zarzdzanie dostaw to:
planowanie dostaw 12.1,
realizacja dostaw 12.2,
kontrola sposobu i stopnia realizacji dostaw 12.3,
zamykanie procesu dostawczego 12.4.

Jednym z najbardziej rozpaczliwych raportw na temat kiepskiego zaopatrzenia jest

relacja kpt. Behra z 6. armii, ktry wspomina swoj wizytacj wojsk rumuskich w Stalingradzie:
Ci biedacy tkwili w niegu z bardzo marnym wyposaeniem, niektrzy bez kocw,
ze starymi karabinami, ktre przypominay czasy Napoleona. Zaopatrzenie
u nich byo bardzo ze, ale na tyach oficerowie rozpierali si przy nakrytych
biaymi obrusami stoach, pili wino i nie odmawiali sobie niczego. Na miejscu
tych rumuskich onierzy te nie miabym ochoty z entuzjazmem stawa
do walki za Hitlera i powica wasne ycie6.

Procesy i techniki
Kady z procesw, oprcz przynalenoci do obszaru wiedzy, naley do jednej z 5 gwnych grup procesw. Wzajemna zaleno tych grup jest stosunkowo prosta (rysunek 6).
Jeden projekt moe skada si z wielu etapw7 i kady z nich bdzie zarzdzany przez
PMBoK oddzielnie. W szczeglnym przypadku, gdy dwa etapy zachodz na siebie,

G. Knopp, Stalingrad, wiat Ksiki, Warszawa 2007, s.150.

Formalnie, w nomenklaturze PMBoK etap nazywa si faz.

Cz I Metodyki zarzdcze a praktyka

40
Rysunek 6.
Architektura grup
procesw PMBoK

moemy mie do czynienia z sytuacj, gdy rwnoczenie uruchomione s procesy z rnych grup. Metodyka przewiduje sytuacj, gdy faza pierwsza operuje na procesach
zamknicia, a rwnoczenie faza druga jest w okresie inicjacji (rysunek 7).
POPRZEDNIE
ETAPY

ETAP I PROTOTYP ROZWIAZANIA

PROCESY
INICJACJI

PROCESY
PLANISTYCZNE

PROCESY
KONTROLI

PROCESY
REALIZACJI

ETAP II KOMERCYJNE ROZWIZANIE

PROCESY
INICJACJI

PROCESY
PLANISTYCZNE

PROCESY
ZAMKNICIA
PROCESY
KONTROLI

PROCESY
REALIZACJI

KOLEJNE
ETAPY

PROCESY
ZAMKNICIA

Rysunek 7. Wspbieno grup procesw PMBoK

W Prince2 etapy powinny by wykonywane sekwencyjnie. Mona zastosowa analogiczne podejcie, ale taki wariant nie jest opisywany przez oficjaln dokumentacj
APM Group.
Poniej zawarty zosta opis wszystkich grup procesw, oglny opis kadego procesu
oraz najbardziej interesujce techniki. Zacznik A Lista wszystkich procesw
PMBoK zawiera szczegowy opis wszystkich procesw.
Procesy inicjacji wedug PMBoK to wszelkie operacje zwizane z uruchomieniem
projektu.

Rozdzia 2. Project Management Body of Knowledge PMBoK

41

4.1. Przygotowanie dokumentu otwarcia proces jest wymagany w kadym

projekcie i inicjowany przez przekazanie dokumentu zakresu planowanych prac
(ang. Project Statement of Work) i (lub) konkretnej umowy. W stosunku do tego
procesu sugerowana jest technika polegajca na zasigniciu osdu eksperta,
ktry moe by pracownikiem danej organizacji, konsultantem, przedstawicielem
klienta, inn osob albo organizacj.
10.1. Identyfikacja interesariuszy w ramach tego procesu identyfikowane
s wszystkie osoby lub organizacje, ktre maj wpyw na projekt. Tworzony
jest rejestr tych osb i organizacji oraz wykorzystywana technika analizy
interesariuszy pod ktem najlepszego szablonu komunikacji. Istniej cztery takie
szablony:
utrzymanie satysfakcji (ang. Keep Satisfied) dedykowany osobom
o wysokim wpywie, ale niskim zainteresowaniu,
bliska wsppraca (ang. Manage Closely) dedykowany osobom
o wysokim wpywie i wysokim zainteresowaniu,
stae informowanie (ang. Keep Informed) dedykowany osobom o niskim
wpywie i wysokim zainteresowaniu,
monitorowanie (ang. Monitor) dedykowany osobom o niskim wpywie
i niskim zainteresowaniu.
Jest to proces analogiczny do procesu uruchamiania projektu (Przygotowanie Zaoe
Projektu (PP)) z metodyki Prince2.
Procesy planistyczne wedug PMBoK to uszczegowienie zaakceptowanych ram projektowych i szereg taktycznych odpowiedzi na temat sposobu realizacji zada, ktrego
wynikiem jest kompletny, szczegowy plan prac. W skad tej grupy procesw wchodz
procesy z rnych obszarw wiedzy.
4.2. Opracowanie planu zarzdzania projektem gwny proces planistyczny,
w ramach ktrego kierownik projektu uruchamia i zamyka wszystkie pozostae
procesy z tej grupy.
5.1. Zbieranie wymaga udokumentowanie wymaga interesariuszy
w kontekcie realizacji celw projektowych.
5.2. Definiowanie zakresu projektu ustalenie, co projekt ma zrealizowa.
5.3. Utworzenie struktury pakietw roboczych, WBS (ang. Work Breakdown
Structure) definicja struktury pakietw roboczych, analogicznie do sposobu
zaprezentowanego w Prince2.
6.1. Zdefiniowanie czynnoci przejcie od pakietw roboczych do listy zada
do wykonania (czynnoci).
6.2. Szeregowanie czynnoci zazwyczaj pewne zadania musz by wykonane
w pewnej konkretnej kolejnoci. Rezultatem tego procesu jest pierwsza wersja
harmonogramu.
6.3. Szacowanie zasobw czynnoci zarezerwowanie odpowiednich zasobw
(osb i sprztu) niezbdnych do realizacji projektu.

42

Cz I Metodyki zarzdcze a praktyka

6.4. Szacowanie czasu trwania czynnoci dugo trwania poszczeglnych

zada.
6.5. Opracowanie harmonogramu proces, ktry zamyka dziaania wykonane
w procesach od 6.1 do 6.4 i daje w rezultacie bazowy harmonogram projektu.
7.1. Szacowanie kosztw dane finansowe suce do oceny kosztu caego
projektu, przygotowywane na bazie pakietw roboczych (5.3) i listy
czynnoci (6.1).
7.2. Zatwierdzenie budetu bazowy plan kosztw jest wdraany rwnolegle
z zakoczeniem prac nad harmonogramem (6.5).
8.1. Planowanie jakoci przygotowanie planu zarzdzania jakoci
wytwarzanych przez projekt produktw i samego sposobu realizacji projektu.
9.1. Planowanie zasobw ludzkich zdefiniowanie odpowiedzialnoci
poszczeglnych czonkw zespou oraz ustalenie, kto, do kogo i kiedy raportuje
w obrbie zespou projektowego.
10.2. Planowanie komunikacji zdefiniowanie mechanizmw przekazywania
informacji pomidzy kierownikiem projektu a interesariuszami.
11.1. Planowanie zarzdzania ryzykiem zdefiniowanie procedur zarzdzania
ryzykiem.
11.2. Identyfikacja ryzyka okrelenie wejciowej listy ryzyk, ktre zostay
wykryte przez zesp projektowy lub osoby spoza tego zespou.
11.3. Jakociowa analiza ryzyka analiza merytoryczna poszczeglnych ryzyk.
11.4. Ilociowa analiza ryzyka przeoenie wiedzy na temat ryzyka na wartoci
liczbowe w takich obszarach jak prawdopodobiestwo wystpowania lub wpyw
na projekt.
11.5. Planowanie reakcji na ryzyko podejmowanie decyzji zwizanych
z ryzykami.
12.1. Planowanie zaopatrzenia co, kiedy i jak powinno zosta zakupione
lub uzyskane, wcznie z podjciem decyzji typu zrobi, czy kupi.
Procesy planistyczne z PMBoK zawieraj w sobie mechanizmy analogiczne do procesw planowania (PL), inicjowania projektu (IP) i zarzdzania zakresem etapu (ZE)
z metodyki Prince2, ale w obszarach zwizanych z zarzdzaniem zasobami ludzkimi
oraz zaopatrzeniem PMBoK wyranie wykracza poza ramy Prince2.
Kady z wymienionych powyej procesw zawiera pewn grup sugerowanych technik.
Wszystkie s wyliczone w zaczniku A, ale cz z nich jest szczeglnie interesujca.
Techniki zwizane z procesem 6.2. Szeregowanie czynnoci
Metoda Diagramw Nastpstw (ang. Precedence Diagramming Method)
opisuje najbardziej popularny sposb wizania ze sob czynnoci w takich
pakietach jak MS Project. Definiuje czynnoci jako wzy, ktre s ze sob
poczone strzakami. Relacja pomidzy zadaniami moe by nastpujca.

Rozdzia 2. Project Management Body of Knowledge PMBoK

43

Koniec-do-Pocztku: poprzednik musi zakoczy si, zanim zacznie si nastpnik (najczciej wykorzystywany mechanizm czenia zada). Przykad proces sdowy musi
dobiec koca, zanim zacznie si wykonanie wyroku (rysunek 8).
Rysunek 8.
Relacja pomidzy
zadaniami Koniecdo-Pocztku

Oto inne, rzadziej stosowane typy relacji.

Koniec-do-Koca: poprzednik musi zakoczy si, zanim skoczy si nastpnik (bardzo
rzadko wykorzystywany mechanizm). Przykad proces sdowy musi si skoczy,
zanim skoczy si tymczasowe zatrzymanie (rysunek 9).

Rysunek 9. Relacja pomidzy zadaniami Koniec-do-Koca

Pocztek-do-Pocztku: poprzednik musi si rozpocz, zanim zacznie si nastpnik

(bardzo rzadko wykorzystywany mechanizm). Przykad dziaalno przestpcza
musi si rozpocz, zanim zacznie si proces sdowy (rysunek 10).

Rysunek 10. Relacja pomidzy zadaniami Pocztek-do-Pocztku

Pocztek-do-Koca: poprzednik musi si zacz, zanim nastpnik si zakoczy (bardzo

rzadko wykorzystywany mechanizm). Przykad proces sdowy musi si zacz, zanim
nastpi przedawnienie (rysunek 11).

Cz I Metodyki zarzdcze a praktyka

44
Rysunek 11.
Relacja pomidzy
zadaniami
Pocztek-do-Koca

W praktyce zalenoci pomidzy zadaniami dokumentuje si zazwyczaj za pomoc

wykresw Gantta z wykorzystaniem aplikacji typu MS Project lub w arkuszu Excel.
W obu przypadkach, jeeli zachodzi konieczno wizania ze sob zada, najczciej stosuje si relacje typu Koniec-do-Pocztku, czyli w kolumnie Poprzednik zaznacza si
konkretne zadania.
Technika analizy zalenoci (ang. Dependency Determination) wyjania
charakter zalenoci pomidzy czynnociami. I tak mamy:
zalenoci wymagane zwizane z natur pracy do wykonania,
zalenoci rozwane zwizane z tradycj, najlepszymi praktykami,
czyli logiczne,
zalenoci zewntrzne zwizane ze stanami lub produktami, ktre musz
zosta osignite, dostarczone poza projektem. Zalenoci te powinny by
elementem rejestru ryzyk.
Technika przyspiesze i opnie (ang. Applying Leads and Lags) wie dwie
czynnoci na zasadzie Rozpocz zadanie B na X jednostek czasu, zanim
zakoczy si zadanie A (przyspieszenie) lub Zadanie B moe si rozpocz
na X jednostek czasu po zakoczeniu zadania A (opnienie).

MS Project posiada tego typu funkcjonalno; jest to parametr o nazwie Zwoka przy
definiowaniu poprzednikw zadania. Na rysunku 12. przedstawione jest zadanie B,
ktre ma zacz si na jeden dzie przed zakoczeniem zadania A. Parametr Zwoka
w MS Project moe przybiera warto dodatni (opnienie) lub ujemn (przyspieszenie).

Szablony harmonogramu sieciowego (ang. Schedule Network Templates)

s to szablony harmonogramw wykorzystywane wtedy, kiedy w ramach
projektu maj zosta dostarczone identyczne lub bardzo podobne produkty,
takie jak pitra wieowca.

Rozdzia 2. Project Management Body of Knowledge PMBoK

45

Rysunek 12. Przyspieszenia i opnienia zada w MS Project

Techniki zwizane z procesem 3.5. Opracowanie harmonogramu

Oprcz standardowych rozwiza, takich jak wykres Gantta, PMBoK opisuje nastpujce techniki.
Analiza sieciowa harmonogramu zawiera wszystkie techniki zwizane
z tworzeniem harmonogramu projektu, takie jak metoda cieki krytycznej,
metoda acucha krytycznego, analiza co jeli i rwnowaenie zasobw.
Gwnym celem jest oszacowanie wczeniejszych oraz pniejszych dat
rozpoczcia i zakoczenia czynnoci projektowych.
Metoda cieki krytycznej (ang. Critical path method) dla kadej czynnoci
szacuje optymistyczn (wczeniejsz) i pesymistyczn (pniejsz) dat
rozpoczcia i zakoczenia. Szacunki te wykonane s bez uwzgldnienia ogranicze
zasobowych. Nastpnie analizowane s wzajemne zalenoci midzy
czynnociami. W rezultacie otrzymujemy informacj o tym, w jakich granicach
moemy przesuwa wykonanie poszczeglnych czynnoci. Brak takiej swobody
w stosunku do serii zada okrelany jest mianem cieki krytycznej. Harmonogram
moe mie kilka cieek krytycznych. Metoda ma na celu takie przemodelowanie
planu, aby uzyska maksymalnie du swobod jego wykonania.
Metoda acucha krytycznego (ang. Critical chain method) przyjmuje
za punkt wyjcia zdefiniowane cieki krytyczne. Uzupenia plany o ograniczenia
zasobowe i tak zmodyfikowane cieki krytyczne uzyskuj miano acucha
krytycznego. W ramach tego procesu na kocu caego projektu dodawane
s dodatkowe bufory czasu (ang. the project buffer), ktre maj zabezpieczy
projekt przed przekroczeniem terminw kocowych. Dodatkowo do acuchw
zada o najwikszej niepewnoci dodawane s rwnie dodatkowe bufory czasu
(ang. the feeding buffer). Wykorzystujc t metod, naley w trakcie realizacji
projektu koncentrowa si na waciwym stosowaniu buforw.
Rwnowaenie zasobw (ang. Resource leveling) to technika, ktra zakada due
ograniczenie w dostpnoci do zasobw. Przykadowo przy uyciu tego samego
zasobu moe realizowa rwnoczenie dwa rne projekty, okrelona pula
zasobw moe by dostpna tylko pomidzy konkretnymi datami na
okrelon dugo. Tego typu ograniczenia mog powodowa znaczce
zmiany w harmonogramie. Jeeli np. okazuje si, e mamy osiem osb
do dugoterminowej dyspozycji, a wykres zaangaowania wyglda tak jak

Cz I Metodyki zarzdcze a praktyka

46

Prawo Parkinsona8 mwi, e praca zawsze rozrasta si w taki sposb, aby zapeni cay
zaplanowany na ni czas. W zwizku z tym, nie ma sensu dodawa kolejnych buforw
do kadej czynnoci, gdy z pewnoci zostan zuyte. Warto doda pewne bufory
na czarn godzin na kocu projektu poza konkretnymi zadaniami jako swoist rezerw
strategiczn. Warto rwnie motywowa zesp do ich niewykorzystywania (np. premie).
na rysunku 13, to plany musz zosta tak przeprojektowane, aby zrwnoway
wykorzystanie zasobw. Takie zmiany musz zosta wykonane nawet wtedy,
jeli spowoduje to wyduenie realizacji pewnych zada.
Wymagania nadmiarowe
Ilo zasobw
11
10
9

Poziom dostpnych zasobw

8
7
6
5
4
3
2
1
1

10

Tygodnie
Rysunek 13. Mechanizm rwnowaenia zasobw

Analiza scenariuszy co, jeli w przypadku kilku wariantw realizacji

projektu analizowane s konsekwencje kadego z nich.
Kompresja harmonogramu to metoda skracania cieki krytycznej bez zmiany
zakresu projektu. Wykorzystuje si do tego ponisze techniki.
Kruszenie (ang. crashing) to technika, ktra analizuje koszty wzgldem
harmonogramu i prbuje uzyska jak najwiksz kompresj zada za jak
8

Praca rozszerza si wprost proporcjonalnie do czasu wyznaczonego do jej wykonania (oryg. ang.: Work
expands as to fill the time available for its completion).

Rozdzia 2. Project Management Body of Knowledge PMBoK

47

najnisz cen. Przykadowe sposoby stosowania tej techniki to nadgodziny,

dodatkowe zasoby lub premie za realizacj zada na ciece krytycznej.
Technika ta nie zawsze tworzy rzeczywist alternatyw i moe powodowa
zwikszone ryzyko projektowe.
Szybkie ledzenie (ang. Fast tracking) to cakowite lub czciowe
zrwnoleglenie czynnoci, ktre normalnie byyby wykonywane sekwencyjne.
Zrwnoleglenie czynnoci powoduje konieczno ich kocowej integracji.
Jest to pewien dodatkowy koszt i ryzyko, ktre naley wzi pod uwag przy
okazji podejmowania tego typu decyzji.
Oprogramowanie do zarzdzania projektami (np. MS Project).
Techniki wspierajce podejmowanie decyzji, stosowane m.in. w procesach 5.1.
Zbieranie wymaga i 8.1. Planowanie jakoci
Burza mzgw (ang. Brainstorming) to swobodna dyskusja caego zespou
na kluczowe tematy projektowe, gdzie kady ma rwne prawo gosu i gow
otwart na nieszablonowe pomysy. W trakcie tych sesji nie ma gupich
pomysw.

Rano po kawie, gdy umys wiey, zabieramy czonkinie i czonkw zespou do salki
konferencyjnej lub na spacer. Otwieramy tabliczk czekolady, paczk z pczkami lub
kadziemy na st bilety do teatru i pytamy, jak rozwiza problem komiwojaera, choby
i w najbardziej oryginalny sposb Pozostaje jedynie pobudza umysy do twrczej
dyskusji, ruga osoby, ktre dyskwalifikuj cudze idee, i sumiennie notowa najlepsze
pomysy.

Technika grupy nominalnej (ang. Nominal group technique) to uczesana

wersja burzy mzgw, w ktrej zebrana grupa jest zaznajomiona z problemem
i samodzielnie zapisuje propozycje jego rozwizania. Po spisaniu pomysw
kada osoba przedstawia swoje rozwizanie reszcie zespou, a nastpnie wszyscy
dyskutuj ze sob, wyjaniajc i rozwijajc warianty. Ostatecznie decyzja jest
podejmowana w demokratycznym gosowaniu9.
Technika delficka (ang. The Delphi Technique) grupa ekspertw
odpowiada na ankiety i udostpnia informacj zwrotn, ktra umoliwia
doprecyzowanie problemu. W nastpnej rundzie eksperci otrzymuj kolejn
propozycj rozwizania problemu wraz z list anonimowych uwag
i uzasadnie. Eksperci udzielaj wtedy kolejnej serii odpowiedzi. Tego typu
technika moe zosta zastosowana do rozwizania kluczowych problemw
biznesowych lub projektowych.

http://www.joe.org/joe/2007february/iw1.shtml

48

Cz I Metodyki zarzdcze a praktyka

Wujek Dobra Rada odcinek 3. W zespole sia

CO DWIE GOWY, TO NIE JEDNA DEMOKRATYCZNY SPOSB PODEJMOWANIA DECYZJI

ZWIKSZA ZAANGAOWANIE CZONKW ZESPOU I ICH MOTYWACJ

Mapa pomysw (ang. Idea/mind mapping) to technika podobna do diagramw

pokrewiestwa, ktra polega na umieszczeniu wszystkich pomysw na jednej
mapie, po to aby odnale ich wzajemne rnice i czci wsplne.
Diagramy pokrewiestwa (ang. Affinity diagram) metoda wymylona
w latach 60. ubiegego wieku przez japoskiego antropologa Jiro Kawakit.
Jest to tablica, na ktrej za pomoc tych karteczek wypisujemy wszystkie
kwestie, grupujemy je, okrelamy midzy nimi relacje, nadajemy im priorytety
i czynimy stosowne ustalenia na przyszo, tak jak zaprezentowano
na rysunku 14.
Analiza pola siy (ang. force field analysis) to analiza si dziaajcych
na projekt, szczeglnie uyteczna przy podejmowaniu kluczowych decyzji;
jest to specjalizowana metoda analizy za i przeciw. Bazujc na konkretnym
projekcie, planie czy rozwizaniu, naley okreli siy dziaajce na jego korzy
i niekorzy oraz zdefiniowa ocen kadej z si (rysunek 15).
Za pomoc takiego podejcia mona podj bardziej trafn decyzj i zdefiniowa, jakie
siy naley wzmocni, a jakie osabi.
Diagram relacji (ang. interrelationship diagram) to diagram relacji
przyczynowo-skutkowych. Naley sformuowa problem oraz kwestie z nim
zwizane, a nastpnie zdefiniowa zwizek przyczyna-skutek pomidzy kwestiami

Rozdzia 2. Project Management Body of Knowledge PMBoK

Wsplne ustalenie tematu

Zapisanie i zrozumienie
faktw

Pogrupowanie
podobnych faktw

Zatytuowanie grup faktw

Uoenie grup i pokazanie

wzajemnych relacji

Gosowanie
nad najistotniejsz kwesti
wyszego poziomu
i konkluzja

Rysunek 14. Przykad powstania diagramu pokrewiestwa

i zaprezentowa go, rysujc strzaki. W przypadku relacji sabej strzaka powinna

by przerywana, a w przypadku relacji silnej ciga. Dua liczba strzaek
wychodzcych wskazuje gwn przyczyn problemu10 (rysunek 16).

10

http://web2.concordia.ca/Quality/tools/17interdiagram.pdf

49

50

Cz I Metodyki zarzdcze a praktyka

Rysunek 15. Przykad analizy pola siy

Rysunek 16. Przykad diagramu relacji: Dlaczego nie wykorzystujemy procesw rozwizywanie
problemw?

Rozdzia 2. Project Management Body of Knowledge PMBoK

51

Diagramy macierzowe (ang. matrix diagrams) porwnywanie dwch

lub wicej grup pomysw, okrelanie wzajemnych zalenoci i podejmowanie
decyzji na bazie arkuszy Excela lub tablic w kratk. Sposb moe by
wykorzystywany np. do zdefiniowania diagramu encji w bazie danych
(rysunek 17).
Rysunek 17.
Przykad
diagramu
macierzowego

Diagramy przepyww (ang. Flowcharts) to graficzna reprezentacja procesu

wizualizujca czynnoci, punkty decyzyjne oraz kolejno procesowania. Takie
podejcie ma uatwi moliwo wykrycia bdw lub przewidzenia, gdzie
mog potencjalnie wystpi.
Matryce priorytetyzacyjne (ang. Prioritization matrices) na bazie arkuszy
Excela lub tablic w kratk naley wypisa w rzdach kryteria decyzyjne,
a w kolumnach moliwe opcje rozwizania problemu. W kade z pl wewntrz
takiej tabeli trzeba wpisa si rozwizania wzgldem kadego z kryteriw.
Dodatkowo moliwe jest uwzgldnienie wagi kadego z kryteriw decyzyjnych.
Nastpnie wystarczy wyliczy sum dla kadej opcji, aby wybra najlepsz
z nich11. Przykadowe zastosowanie tej techniki zostao zaprezentowane
w tabeli 1.
Tabela 1. Przykad matrycy priorytetyzacyjnej
Waga
(1 10)

A. Zakup
gotowego
rozwizania

B. Samodzielne
stworzenie
wasnego
rozwizania

C. Zlecenie
wykonania
rozwizania

1. Koszt

10

2. Czas wykonania

10

3. Wewntrzne kompetencje

10

130

108

106

Suma

11

(maks. 170)

http://www.maqin.org/brownbag/PrioritizationMatrixNov05.pdf