Zarz¹dzanie projektami IT.
Przewodnik po metodykach
Autor: Adam Koszlajda
ISBN: 978-83-246-1804-0
Format: 158u235, stron: 360
Przewodnik po metodykach, które musisz poznaæ!
• Jak wybraæ metodê dzia³ania odpowiedni¹ dla konkretnych projektów i
organizacji?
• Co pozwala skutecznie zrealizowaæ stworzone plany dzia³ania?
• Gdzie szukaæ wiedzy tajemnej z zakresu metodyk zarz¹dczych, wytwórczych
i organizacyjnych?
W³aœciwe zaplanowanie i doprowadzenie do koñca du¿ego projektu informatycznego
nie jest rzecz¹ ³atw¹. Czêsto dzia³anie takie wymaga wspó³pracy wielu ludzi, zespo³ów,
a nawet ca³ych firm, precyzyjnego okreœlenia celów i struktury produktu koñcowego,
jak równie¿ œrodków i czasu niezbêdnych do realizacji projektu. W zale¿noœci od jego
przeznaczenia oraz specyfiki projekt taki zmusza do wdro¿enia odpowiedniego planu
dzia³ania, obejmuj¹cego wszystkie etapy, metody oraz techniki, pozwalaj¹ce doprowadziæ
do satysfakcjonuj¹cego wszystkich fina³u prac. W³aœnie temu s³u¿y wybór konkretnej
metodyki, zapewniaj¹cej sensowny podzia³ zadañ oraz zakresu odpowiedzialnoœci
poszczególnych osób i p³ynne przechodzenie miêdzy kolejnymi etapami projektu.
Przekrojowy opis takich metodyk, stosowanych w bran¿y IT, znajdziesz w³aœnie na
kartach ksi¹¿ki, któr¹ trzymasz w rêkach.
„Zarz¹dzanie projektami IT. Przewodnik po metodykach” to poradnik dla wszystkich
tych, którzy chcieliby dowiedzieæ siê, czym ró¿ni¹ siê kompleksowe podejœcia do
rozwi¹zywania konkretnych problemów i jak dobraæ metodykê odpowiedni¹ dla ich
w³asnych projektów. Oprócz ogólnych wskazañ oraz starannie opracowanych opisów
kolejnych etapów dzia³ania, technik czy procesów znajdziesz tu tak¿e:
• przyk³adowe realizacje projektów IT wed³ug konkretnych metodyk,
• praktyczne wskazówki i rady,
• wywiady z osobami wykorzystuj¹cymi na co dzieñ te rozwi¹zania.
Ca³oœæ urozmaicaj¹ sentencje „Wujka dobra rada”, podkreœlaj¹ce najistotniejsze aspekty
prezentowanych zagadnieñ, oraz przejrzyste, czêsto humorystyczne ilustracje. Czytaj¹c
tê ksi¹¿kê, poznasz:
• metodyki zarz¹dcze – Prince2 oraz PMBoK4
• metodyki wytwórcze – RUP i MSF
• metodyki adaptacyjne – eXtreme Programming i SCRUM
• metodyki organizacyjne – CMMI, Six Sigma, ITIL lub COBIT
• kilka przyk³adów sposobów ³¹czenia tych metodyk
Spis treĈci
Wst
öp .............................................................................................. 7
Cz
öĈè I
Metodyki zarz
ñdcze a praktyka ..................................... 11
Rozdzia
ä 1. PRoject IN Controlled Environment — Prince2 ................................ 13
Szczypta historii ............................................................................................................. 13
Procesy ........................................................................................................................... 14
Komponenty ................................................................................................................... 17
Techniki .......................................................................................................................... 21
Zarządzanie 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 wytwórcze a praktyka ................................... 69
Rozdzia
ä 3. Rational Unified Process (RUP) ...................................................... 73
Szczypta historii ............................................................................................................. 73
Proces ............................................................................................................................. 74
Dyscypliny RUP ............................................................................................................. 76
Abecadáo metodyki RUP ................................................................................................ 79
Adaptacja RUP do potrzeb organizacji ........................................................................... 80
Podsumowanie RUP ....................................................................................................... 81
Rozmowa z... .................................................................................................................. 82
Przykáad Prince2 i RUP — BlogSerwis .......................................................................... 85
4
Zarz
ñdzanie projektami IT. Przewodnik po metodykach
Rozdzia
ä 4. Microsoft Solution Framework (MSF) ............................................ 105
Szczypta historii ........................................................................................................... 105
Proces ........................................................................................................................... 106
Model zespoáu .............................................................................................................. 107
Faza Wizji ..................................................................................................................... 108
Faza Planowania ........................................................................................................... 109
Faza Konstrukcji ........................................................................................................... 112
Faza Stabilizacji ............................................................................................................ 116
Faza WdroĪenia ............................................................................................................ 120
MSF > MOF ................................................................................................................. 121
Trójkąt negocjacyjny .................................................................................................... 123
Dyscypliny zarządcze ................................................................................................... 125
Certyfikacja .................................................................................................................. 126
Podsumowanie — MSF a RUP .................................................................................... 126
Rozdzia
ä 5. Przykäad PMBoK i MSF — wdroĔenie systemu BI ........................... 129
Cz
öĈè III Metodyki adaptacyjne a praktyka ............................... 177
Rozdzia
ä 6. eXtreme Programming .................................................................. 179
Szczypta historii ........................................................................................................... 179
Role .............................................................................................................................. 180
Proces ........................................................................................................................... 180
WdroĪenie .................................................................................................................... 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. Przykäad — 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
WdroĪenie .................................................................................................................... 241
Certyfikacja .................................................................................................................. 245
Podsumowanie .............................................................................................................. 245
Rozdzia
ä 12. Information Technology Infrastructure Library (ITIL) ....................... 247
Szczypta historii ........................................................................................................... 247
Role .............................................................................................................................. 249
Procesy ......................................................................................................................... 251
WdroĪenie .................................................................................................................... 254
Spis tre
Ĉci
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 Rozwiñzania kombinowane ......................................... 275
Podsumowanie ............................................................................. 281
Dodatki ..................................................................................... 283
Dodatek A Lista wszystkich procesów PMBoK ............................................... 285
Dodatek B Specyfikacja dyscyplin RUP z Rational Method Composer (RMC) ... 321
Dodatek C Lista wszystkich procesów ITIL ..................................................... 325
Dodatek D Lista wszystkich procesów COBIT ................................................. 331
Spis rysunków .............................................................................. 335
Spis tabel .................................................................................... 337
đródäa .......................................................................................... 339
Skorowidz .................................................................................... 343
Rozdziaä 2.
Project Management
Body of Knowledge
— PMBoK
Podej
Ğ
cie PMBoK jest cz
Ċ
sto przedstawiane jako „metodyka PMI”, czyli metodyka
organizacji Project Management Institute zrzeszaj
ą
cej specjalistów z dziedziny zarz
ą
-
dzania projektami. PMBoK koncentruje si
Ċ
na zebraniu i przedstawieniu dobrych praktyk
zwi
ą
zanych z zarz
ą
dzaniem projektami w ramach zdefiniowanych obszarów wiedzy.
W pewnym sensie PMBoK jest podej
Ğ
ciem konkurencyjnym w stosunku do Prince2
i ze wzgl
Ċ
du na nieco wi
Ċ
ksz
ą
swobod
Ċ
implementacji jest cz
ĊĞ
ciej stosowany przez
du
Ī
e korporacje z sektora prywatnego. Dodatkowo PMBoK wkracza w obszary, których
Prince2 nie obejmuje, takie jak zarz
ą
dzanie zasobami ludzkimi oraz zaopatrzeniem.
PMBoK w wersji czwartej definiuje pi
Ċü
grup procesów, takich jak procesy rozpocz
Ċ
cia,
planowania, realizacji, kontroli i zako
Ĕ
czenia. Ka
Ī
dy z tych procesów nale
Ī
y równie
Ī
do jednego z dziewi
Ċ
ciu obszarów wiedzy, takich jak zarz
ą
dzanie integralno
Ğ
ci
ą
pro-
jektu, zakresem, czasem, kosztami, jako
Ğ
ci
ą
, zasobami ludzkimi, komunikacj
ą
, ryzykiem
i zaopatrzeniem.
Szczypta historii
Organizacja PMI powsta
á
a w USA w 1969 roku jako organizacja non profit zrzeszaj
ą
ca
profesjonalistów ró
Ī
nych specjalno
Ğ
ci w celu wyspecyfikowania standardowych prak-
tyk zarz
ą
dczych. W 1987 roku opublikowana zosta
á
a pierwsza edycja PMBoK, która by
á
a
rezultatem prac wykonanych we wczesnych latach 80. W roku 1998 American National
Standards Institute (ANSI) zaakceptowa
á
to rozwi
ą
zanie jako narodowy standard zarz
ą
-
dzania projektami, a Institute of Electrical and Electronics Engineers (IEEE) zaadaptowa
á
32
Cz
öĈè I i Metodyki zarzñdcze a praktyka
to podej
Ğ
cie jako standard 1490
1
. Od tej pory, co oko
á
o 4 lata pojawiaj
ą
si
Ċ
kolejne
aktualizacje tej metodyki ( w latach 1996, 2000 i 2004). Ostatnia, czwarta edycja ujrza
á
a
Ğ
wiat
á
o dzienne 31 grudnia 2008 roku.
Wersja czwarta nie zawiera rewolucyjnych zmian w stosunku do wersji trzeciej, ale
mo
Ī
na zauwa
Ī
y
ü
kilka pozytywnych zmian ewolucyjnych. Oto one.
Lepsze zarz
ą
dzanie interesariuszami, które pojawia si
Ċ
ju
Ī
w grupie procesów
rozpocz
Ċ
cia jako nowy proces o nazwie „10.1. Identyfikacja interesariuszy”.
Z grupy procesów rozpocz
Ċ
cia znikn
ąá
proces „4.3. Opracowanie wst
Ċ
pnego
zakresu projektu” (ang.
Develop preliminary scope statement
). Pokrywa
á
si
Ċ
on z procesem „5.1. Planowanie zarz
ą
dzania zakresem projektu”, który
w PMBoK4 nazywa si
Ċ
ju
Ī
„5.1. Planowanie zarz
ą
dzania zakresem projektu”.
Nie jest to tylko zmiana nazwy, ale przejaw bardziej dojrza
á
ego podej
Ğ
cia
do zarz
ą
dzania wymaganiami projektowymi. Pojawia si
Ċ
tu ciekawa technika
„Matrycy
Ğ
ledzenia wymaga
Ĕ
” (ang.
Requirements Traceability Matrix
).
Unifikacja pewnych elementów przekazywanych pomi
Ċ
dzy procesami.
Przyk
á
adowo pojawia si
Ċ
jeden, kluczowy plan zarz
ą
dzani projektem zamiast
oddzielnych planów do zarz
ą
dzania poszczególnymi obszarami wiedzy (np. plan
zarz
ą
dzania zakresem, harmonogramem, kosztem itd.). Analogicznie pojawi
á
o
si
Ċ
bardziej ogólne
Īą
danie zmiany, które zawiera w sobie rekomendowane
dzia
á
ania naprawcze, prewencyjne i napraw
Ċ
defektów. Tego typu podej
Ğ
cie
jest o wiele bardziej praktyczne i umo
Ī
liwia wi
Ċ
ksz
ą
swobod
Ċ
w implementacji
tych mechanizmów.
Znacznemu uproszczeniu i generalizacji uleg
á
obszar wiedzy dostaw. PMBoK4
przyj
ąá
tutaj nowy model
Planowanie>Wykonanie>Administrowanie>
ZamkniĊcie
. Dodatkowo wyspecyfikowane zosta
á
y nowe podtypy kontraktów
o ustalonej cenie. Nie wiadomo jednak, czy na polskim rynku b
Ċ
d
ą
one mia
á
y
znaczenie praktyczne.
Technika Uzyskanej Warto
Ğ
ci (ang.
Earned Value Technique
— EVT), która
by
á
a cz
ĊĞ
ci
ą
techniki „analizy miar wydajno
Ğ
ciowych” w procesie „7.3. Kontrola
kosztów”, sta
á
a si
Ċ
pe
á
noprawn
ą
technik
ą
Zarz
ą
dzania Uzyskan
ą
Warto
Ğ
ci
ą
(ang.
Earned Value Management
— EVM). Technika ta uleg
á
a równie
Ī
pewnemu
rozwini
Ċ
ciu i pojawi
á
si
Ċ
nowy „indeks wydajno
Ğ
ci niezb
Ċ
dnej do zako
Ĕ
czenia
projektu” (ang.
To-Complete Performance Index
— TCPI).
Uporz
ą
dkowaniu uleg
á
o nazewnictwo wszystkich procesów oraz ich numeracja,
która bazuje ju
Ī
wy
áą
cznie na numerach rozdzia
á
ów i podrozdzia
á
ów.
1
Standard IEEE Std 1490-1998 zosta
á
zaktualizowany w 2004 (!) roku do IEEE Std 1490-2003.
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
33
Obszary wiedzy
PMBoK sk
á
ada si
Ċ
z czterdziestu dwóch procesów, z których ka
Ī
dy przynale
Ī
y do jednej
z pi
Ċ
ciu grup procesów i jednego z dziewi
Ċ
ciu obszarów wiedzy. Ka
Ī
dy z procesów
posiada numer g
á
ówny od 4. do 12., który wskazuje okre
Ğ
lony obszar wiedzy
2
, i poboczny
numer porz
ą
dkowy (np. proces 5.2 wskazuje drugi proces z obszaru wiedzy o nazwie
„Zakres” opisanego w 5. rozdziale). Oto poszczególne obszary wiedzy.
Obszar wiedzy
Integracja (rozdzia
ä 4.)
Ten obszar wiedzy jest odpowiedzialny za ogólne, wysokopoziomowe kwestie zarz
ą
dcze
zwi
ą
zane z realizacj
ą
projektu informatycznego, a szczególnie za:
kwestie zwi
ą
zane z uruchomieniem projektu (np. zdobycie mandatu na realizacj
Ċ
projektu) — 4.1,
przygotowanie planu zarz
ą
dzania projektem — 4.2,
zarz
ą
dzanie bie
Īą
cymi pracami projektowymi — 4.3,
kontrol
Ċ
prac projektowych i zintegrowane zarz
ą
dzanie zmian
ą
— 4.4, 4.5,
zamkni
Ċ
cie projektu — 4.6.
Integracja to codzienne wybory miejsca koncentracji zasobów i wysi
á
ku, wyprzedzenie
mo
Ī
liwych k
á
opotów i zarz
ą
dzanie nimi, zanim stan
ą
si
Ċ
krytyczne.
— Integrowaè siö! Integrowaè — rzecze Najlepszy Kierownik Projektu.
2
Numery obszarów wiedzy s
ą
zwi
ą
zane z numerami rozdzia
á
ów w oficjalnych podr
Ċ
cznikach PMBoK.
34
Cz
öĈè I i Metodyki zarzñdcze a praktyka
Obszar wiedzy
Zakres (rozdzia
ä 5.)
Ten obszar wiedzy skupia si
Ċ
na zarz
ą
dzaniu zakresem funkcjonalno
Ğ
ci projektu, a szcze-
gólnie na tworzeniu:
definicji zakresu projektu wraz z struktur
ą
wytwarzanych produktów (ang.
Work
Breakdown Structure
) — 5.1, 5.2, 5.3,
sformalizowanych mechanizmów weryfikacji i kontroli zakresu projektu
— 5.4, 5.5.
Ten obszar wiedzy PMBoK
áą
czy w sobie tematy, którymi zajmuj
ą
si
Ċ
procesy Zarz
ą
-
dzanie Zakresem Etapu (ZE) i Zarz
ą
dzanie Wytwarzaniem Produktów (WP) w Prince2.
In
Ī
ynierowie z firmy produkuj
ą
cej auta otrzymali plany nowego, eksportowego modelu
auta i w trakcie analizy zauwa
Ī
yli wymóg konieczno
Ğ
ci zamontowania tylnych szyb
odpornych na pr
Ċ
dko
Ğü
50 km/h! 50 km/h? Przecie
Ī
na biegu wstecznym auto nigdy nie
osi
ą
gnie takiej pr
Ċ
dko
Ğ
ci! Zgodnie stwierdzono wi
Ċ
c,
Ī
e w celu redukcji kosztów zamon-
towane zostan
ą
inne szyby o gorszych parametrach.
In
Ī
ynierowie pracowali w pocie czo
á
a przez wiele d
á
ugich miesi
Ċ
cy i to niejeden raz po
godzinach. Jak ka
Ī
dy projekt, ten te
Ī
mia
á
swoje dobre i z
á
e chwile, ale w ko
Ĕ
cu uda
á
o
si
Ċ
skonstruowa
ü
pierwszy prototyp, który pomy
Ğ
lnie przeszed
á
pierwsz
ą
seri
Ċ
testów
terenowych. Podj
Ċ
to decyzj
Ċ
o uruchomieniu produkcji i wyprodukowano pierwsz
ą
setk
Ċ
pi
Ċ
knych, czerwonych, l
Ğ
ni
ą
cych nowych aut; ch
á
opcy pana Stefana przez ca
á
y dzie
Ĕ
pole-
rowali je na parkingu firmowym. Z powodzeniem zamkni
Ċ
to projekt i wyp
á
acono premie,
a po tygodniu zadzwoni
á
telefon z zagranicy…
— Co wy
Ğ
cie zrobili!!!!
— Nowe auta.
— Wszystkie tylnie szyby powybijane! Co my teraz mamy zrobi
ü
?
— Jak to powybijane!?
— W
á
a
Ğ
nie
Ğ
ci
ą
gn
Ċ
li
Ğ
my je z lawety kolejowej! B
Ċ
dziemy musieli jako
Ğ
za
á
atwi
ü
t
Ċ
spraw
Ċ
u nas, lokalnie… klienci czekaj
ą
…
— Zaraz, zaraz… Transport kolejowy!?
— Tak! Przecie
Ī
pisali
Ğ
my,
Ī
e tylnie szyby maj
ą
wytrzymywa
ü
szybko
Ğü
50km/h.
— No w
á
a
Ğ
nie. Po co?
— Po co ???!!! Przecie
Ī
te auta s
ą
ustawiane na wagonach tyln
ą
szyb
ą
do przodu!!! Wystarczy
á
o TYLKO wykona
ü
to, co zapisali
Ğ
my! Hrrrr…
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
35
Obszar wiedzy
Czas (rozdzia
ä 6.)
Ten obszar wiedzy to wszystkie dzia
á
ania zwi
ą
zane z wykonaniem projektu w za
á
o
Ī
onym
terminie, o ile zmianie nie uleg
á
y przyj
Ċ
te za
á
o
Ī
enia oraz zakres. Szczegó
á
owo przyjmuje
on prost
ą
sekwencj
Ċ
zdarze
Ĕ
:
zdefiniowanie zbioru planowanych dzia
á
a
Ĕ
— 6.1,
ustanowienie wzajemnych zale
Ī
no
Ğ
ci czasowych pomi
Ċ
dzy tymi dzia
á
aniami
(co musi by
ü
zrobione najpierw, a co potem, jakie dzia
á
ania mog
ą
by
ü
wykonywane równocze
Ğ
nie) — 6.2,
oszacowanie potrzeb zasobowych i czasu trwania poszczególnych dzia
á
a
Ĕ
— 6.3, 6.4,
stworzenie harmonogramu projektu oraz jego kontrola — 6.5, 6.6.
Wszystkie te procesy z wyj
ą
tkiem ostatniego nale
Īą
do grupy procesów planistycznych.
Obszar wiedzy
Koszt (rozdzia
ä 7.)
Projekt informatyczny jest inwestycj
ą
, czyli kosztami, które w d
á
u
Ī
szej perspektywie maj
ą
przynie
Ğü
organizacji zysk. Aby projekt zako
Ĕ
czy
á
si
Ċ
powodzeniem, konieczne jest
w
á
a
Ğ
ciwie zarz
ą
dzanie bud
Ī
etem, czyli:
szacowanie — 7.1,
zaplanowanie (stworzenie bazowej wersji bud
Ī
etu) — 7.2,
kontrola — 7.3.
Wszystkie te procesy z wyj
ą
tkiem ostatniego nale
Īą
do grupy procesów planistycznych.
Obszar wiedzy
Jako
Ĉè (rozdziaä 8.)
PMBoK proponuje nast
Ċ
puj
ą
ce procesy w celu zapewnienia w
á
a
Ğ
ciwego zarz
ą
dzania
jako
Ğ
ci
ą
:
zaplanowanie sposobu zapewniania odpowiedniej jako
Ğ
ci w projekcie — 8.1,
wdro
Ī
enie tego planu poprzez systematyczne wykonanie rutynowych
czynno
Ğ
ci — 8.2,
kontrol
Ċ
mechanizmów zapewnienia jako
Ğ
ci — 8.3.
Obszar wiedzy
Zasoby ludzkie (rozdzia
ä 9.)
Ten obszar wiedzy opisuje szereg dobrych praktyk zwi
ą
zanych z zarz
ą
dzaniem lud
Ĩ
mi
postrzeganymi jako pojedyncze osoby i zespo
á
y. Oznacza to:
36
Cz
öĈè I i Metodyki zarzñdcze a praktyka
zaplanowanie potrzeb zasobowych — 9.1,
procesy tworzenia zespo
á
ów ludzkich, ich rozwój i zarz
ą
dzanie nimi — 9.2,
9.3, 9.4.
Rekrutacja w
á
a
Ğ
ciwych osób to jeden z najwa
Ī
niejszych i najtrudniejszych procesów
w trakcie przygotowania do uruchamiania projektu. Jednym z ciekawszych artyku
á
ów
na ten temat jest przet
á
umaczony na j
Ċ
zyk polski
Partyzancki poradnik rekrutacji
Joela
Spolsky’ego
3
. Jego g
á
ównym przes
á
aniem jest rada, by rekrutowa
ü tylko i wyáącznie
osoby
bystre i realizuj
ą
ce cele.
Przy okazji „tematyki kadrowej” warto równie
Ī
nadmieni
ü
o niezwi
ą
zanym z PMBoK
„procesie efektywno
Ğ
ci zespo
á
owej” Kena Blancharda, który opisuje cztery poziomy goto-
wo
Ğ
ci pracowników.
R1 — pracownik o niskich kompetencjach, który na swoim koncie nie ma
wi
Ċ
kszych sukcesów i dlatego nie jest zmotywowany do pracy.
R2 — pracownik o niskich kompetencjach, który nie mo
Ī
e samodzielnie
wykonywa
ü
zada
Ĕ
, ale jest bardzo zmotywowany do ich wykonania.
R3 — pracownik o du
Ī
ych kompetencjach, który mo
Ī
e samodzielnie wykona
ü
zadania, ale brakuje mu motywacji z powodu braku we w
á
asne si
á
y lub znudzenia.
R4 — pracownik o wysokich kompetencjach i ch
Ċ
ciach, który potrafi i chce
samodzielnie wykonywa
ü
zadania.
Ken Blanchard opisuje równie
Ī
cztery style przywództwa (rysunek 4).
S1 —
instruowanie
to „suche” przekazanie ma
á
ych, cz
ą
stkowych zada
Ĕ
do wykonania i rozliczenie z ich wykonania.
S2 —
konsultowanie
to równie
Ī
przekazanie zada
Ĕ
, ale skoncentrowane
na utrzymaniu wysokiej motywacji pracownika.
S3 —
wspieranie
koncentruje si
Ċ
na w
á
a
Ğ
ciwym zmotywowaniu pracownika,
który sam wie, jakie zadania nale
Ī
y wykona
ü
.
S4 —
delegowanie
to styl, w którym pracownik wie, co nale
Ī
y zrobi
ü
, i jest
zmotywowany do samodzielnego podj
Ċ
cia odpowiedzialno
Ğ
ci.
Technika przywództwa sytuacyjnego koncentruje si
Ċ
na w
á
a
Ğ
ciwym dopasowaniu poziomu
gotowo
Ğ
ci do stylu przywództwa, poniewa
Ī
nie mo
Ī
na jednej miary przyk
á
ada
ü
do wszyst-
kich osób. Jak
á
atwo si
Ċ
domy
Ğ
li
ü
, delegowanie z
á
o
Ī
onych zada
Ĕ
pracownikom o niskich
3
http://polish.joelonsoftware.com/Articles/Interviewing.html
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
37
Rysunek 4.
Model przywództwa
zespoáowego
Kena Blancharda
ħ
ród
á
o:
Blanchard International Polska - http://www.blanchard.pl
kompetencjach doprowadzi do katastrofy, a szczegó
á
owe instruowanie do
Ğ
wiadczonych
pracowników demotywuje ich do pracy. Model ten koncentruje si
Ċ
równie
Ī
na rozwoju
ka
Ī
dego pracownika i zwi
Ċ
kszeniu jego poziomu gotowo
Ğ
ci.
Obszar wiedzy
Komunikacja (rozdzia
ä 10.)
Ten obszar wiedzy koncentruje si
Ċ
na zapewnieniu w
á
a
Ğ
ciwej komunikacji z interesariu-
szami projektu. Szczegó
á
owo oznacza to:
identyfikacj
Ċ
kluczowych interesariuszy w trakcie inicjacji projektu — 10.2,
stworzenie planu komunikacji z interesariuszami projektu — 10.2,
38
Cz
öĈè I i Metodyki zarzñdcze a praktyka
w
á
a
Ğ
ciw
ą
dystrybucj
Ċ
informacji i zarz
ą
dzanie interesariuszami — 10.3, 10.4,
przygotowanie i dystrybucj
Ċ
kontrolnych raportów wydajno
Ğ
ciowych — 10.5.
Nale
Ī
y zauwa
Ī
y
ü
,
Ī
e w dzisiejszych czasach dobra komunikacja nie jest mo
Ī
liwa bez
w
á
a
Ğ
ciwych systemów informatycznych. Bardzo wskazane jest posiadanie komplekso-
wego rozwi
ą
zania intranetowego, które umo
Ī
liwi wspó
á
dzielenie wiedzy projektowej
wewn
ą
trz firmy (ang.
Enterprise Project Management
). Ka
Ī
da z firm wybiera system
wed
á
ug w
á
asnych potrzeb, a popularno
Ğü
poszczególnych rozwi
ą
za
Ĕ
jest do
Ğü
rozproszona,
co zobrazowano na rysunku 5.
Rysunek 5.
Wynik ankiety
„Jakich systemów
EPM uĪywasz?”
Pierra-Jeana
Cherreta
4
Inn
ą
ciekaw
ą
alternatyw
ą
dla rozwi
ą
za
Ĕ
tego typu jest firmowe wiki rozwijane na bazie
rozwi
ą
za
Ĕ
darmowych, takich jak MediaWiki, na której bazuje Wikipedia, lub rozwi
ą
za
Ĕ
odp
á
atnych, np. Confluence.
W rozproszonych zespo
á
ach warto dodatkowo zainwestowa
ü
w narz
Ċ
dzia wspó
á
pracy
zdalnej (ang.
collaboration tools
), takie jak WebEx
5
, GoToMeeting, MS Office Live
Meeting (poprzednio PlaceWare) lub Adobe Connect (poprzednio Breeze).
Obszar wiedzy
Ryzyko (rozdzia
ä 11.)
W tym obszarze zarz
ą
dzanie ryzykiem projektowym odbywa si
Ċ
przy u
Ī
yciu rejestru
ryzyk. Dzia
á
ania te polegaj
ą
na:
4
Na podstawie ankiety „Jakich systemów EPM u
Ī
ywasz?” uruchomionej przez Pierra-Jeana Cherreta
w serwisie spo
á
eczno
Ğ
ciowym Plaxo.
5
O skali tego rynku niech
Ğ
wiadczy zakup, jakiego dokona
á
o Cisco 15 marca 2007 roku, które za „drobne”
3,2 miliarda dolarów przej
Ċá
o firm
Ċ
WebEx.
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
39
stworzeniu planu zarz
ą
dzania 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 wyj
ą
tkiem ostatniego nale
Īą
do grupy procesów planistycznych.
Obszar wiedzy
Dostawa (rozdzia
ä 12.)
Dostawa to zakup lub zdobycie produktów i us
á
ug spoza zespo
á
u projektowego. Zarz
ą
-
dzanie 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 raportów na temat kiepskiego zaopatrzenia jest
relacja kpt. Behra z 6. armii, który wspomina swoj
ą
wizytacj
Ċ
wojsk rumu
Ĕ
skich w Sta-
lingradzie:
„Ci biedacy tkwili w
Ğ
niegu z bardzo marnym wyposa
Ī
eniem, niektórzy bez koców,
ze starymi karabinami, które przypomina
á
y czasy Napoleona. Zaopatrzenie
u nich by
á
o bardzo z
á
e, ale na ty
á
ach oficerowie rozpierali si
Ċ
przy nakrytych
bia
á
ymi obrusami sto
á
ach, pili wino i nie odmawiali sobie niczego. Na miejscu
tych rumu
Ĕ
skich
Ī
o
á
nierzy te
Ī
nie mia
á
bym ochoty z entuzjazmem stawa
ü
do walki za Hitlera i po
Ğ
wi
Ċ
ca
ü
w
á
asne
Ī
ycie”
6
.
Procesy i techniki
Ka
Ī
dy z procesów, oprócz przynale
Ī
no
Ğ
ci do obszaru wiedzy, nale
Ī
y do jednej z 5 g
á
ów-
nych grup procesów. Wzajemna zale
Ī
no
Ğü
tych grup jest stosunkowo prosta (rysunek 6).
Jeden projekt mo
Ī
e sk
á
ada
ü
si
Ċ
z wielu etapów
7
i ka
Ī
dy z nich b
Ċ
dzie zarz
ą
dzany przez
PMBoK oddzielnie. W szczególnym przypadku, gdy dwa etapy zachodz
ą
na siebie,
6
G. Knopp,
Stalingrad
,
ĝ
wiat Ksi
ąĪ
ki, Warszawa 2007, s.150.
7
Formalnie, w nomenklaturze PMBoK „etap” nazywa si
Ċ
„faz
ą
”.
40
Cz
öĈè I i Metodyki zarzñdcze a praktyka
Rysunek 6.
Architektura grup
procesów PMBoK
mo
Ī
emy mie
ü
do czynienia z sytuacj
ą
, gdy równocze
Ğ
nie uruchomione s
ą
procesy z ró
Ī
-
nych grup. Metodyka przewiduje sytuacj
Ċ
, gdy faza pierwsza operuje na procesach
zamkni
Ċ
cia, a równocze
Ğ
nie faza druga jest w okresie inicjacji (rysunek 7).
PROCESY
INICJACJI
PROCESY
PLANISTYCZNE
PROCESY
REALIZACJI
PROCESY
KONTROLI
PROCESY
ZAMKNIĉCIA
ETAP II – KOMERCYJNE ROZWIĄZANIE
POPRZEDNIE
ETAPY
KOLEJNE
ETAPY
PROCESY
INICJACJI
PROCESY
PLANISTYCZNE
PROCESY
REALIZACJI
PROCESY
KONTROLI
PROCESY
ZAMKNIĉCIA
ETAP I – PROTOTYP ROZWIAZANIA
Rysunek 7. WspóábieĪnoĞü grup procesów PMBoK
W Prince2 etapy powinny by
ü
wykonywane sekwencyjnie. Mo
Ī
na zastosowa
ü
analo-
giczne podej
Ğ
cie, ale taki wariant nie jest opisywany przez oficjaln
ą
dokumentacj
Ċ
APM Group.
Poni
Ī
ej zawarty zosta
á
opis wszystkich grup procesów, ogólny opis ka
Ī
dego procesu
oraz najbardziej interesuj
ą
ce techniki. Za
áą
cznik A — Lista wszystkich procesów
PMBoK — zawiera szczegó
á
owy opis wszystkich procesów.
Procesy inicjacji wedáug PMBoK
to wszelkie operacje zwi
ą
zane z uruchomieniem
projektu.
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
41
4.1. Przygotowanie dokumentu otwarcia — proces jest wymagany w ka
Ī
dym
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 polegaj
ą
ca na zasi
Ċ
gni
Ċ
ciu os
ą
du eksperta,
który mo
Ī
e 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, które maj
ą
wp
á
yw na projekt. Tworzony
jest rejestr tych osób i organizacji oraz wykorzystywana technika analizy
interesariuszy pod k
ą
tem najlepszego szablonu komunikacji. Istniej
ą
cztery takie
szablony:
utrzymanie satysfakcji (ang.
Keep Satisfied
) — dedykowany osobom
o wysokim wp
á
ywie, ale niskim zainteresowaniu,
bliska wspó
á
praca (ang.
Manage Closely
) — dedykowany osobom
o wysokim wp
á
ywie i wysokim zainteresowaniu,
sta
á
e informowanie (ang.
Keep Informed
) — dedykowany osobom o niskim
wp
á
ywie i wysokim zainteresowaniu,
monitorowanie (ang.
Monitor
) — dedykowany osobom o niskim wp
á
ywie
i niskim zainteresowaniu.
Jest to proces analogiczny do procesu uruchamiania projektu (Przygotowanie Za
á
o
Ī
e
Ĕ
Projektu (PP)) z metodyki Prince2.
Procesy planistyczne wedáug PMBoK
to uszczegó
á
owienie zaakceptowanych ram pro-
jektowych i szereg taktycznych odpowiedzi na temat sposobu realizacji zada
Ĕ
, którego
wynikiem jest kompletny, szczegó
á
owy plan prac. W sk
á
ad tej grupy procesów wchodz
ą
procesy z ró
Ī
nych obszarów wiedzy.
4.2. Opracowanie planu zarz
ą
dzania projektem — g
á
ówny proces planistyczny,
w ramach którego kierownik projektu uruchamia i zamyka wszystkie pozosta
á
e
procesy z tej grupy.
5.1. Zbieranie wymaga
Ĕ
— udokumentowanie wymaga
Ĕ
interesariuszy
w kontek
Ğ
cie realizacji celów projektowych.
5.2. Definiowanie zakresu projektu — ustalenie, co projekt ma zrealizowa
ü
.
5.3. Utworzenie struktury pakietów roboczych, WBS (ang.
Work Breakdown
Structure
) — definicja struktury pakietów roboczych, analogicznie do sposobu
zaprezentowanego w Prince2.
6.1. Zdefiniowanie czynno
Ğ
ci — przej
Ğ
cie od pakietów roboczych do listy zada
Ĕ
do wykonania (czynno
Ğ
ci).
6.2. Szeregowanie czynno
Ğ
ci — zazwyczaj pewne zadania musz
ą
by
ü
wykonane
w pewnej konkretnej kolejno
Ğ
ci. Rezultatem tego procesu jest pierwsza wersja
harmonogramu.
6.3. Szacowanie zasobów czynno
Ğ
ci — zarezerwowanie odpowiednich zasobów
(osób i sprz
Ċ
tu) niezb
Ċ
dnych do realizacji projektu.
42
Cz
öĈè I i Metodyki zarzñdcze a praktyka
6.4. Szacowanie czasu trwania czynno
Ğ
ci — d
á
ugo
Ğü
trwania poszczególnych
zada
Ĕ
.
6.5. Opracowanie harmonogramu — proces, który zamyka dzia
á
ania wykonane
w procesach od 6.1 do 6.4 i daje w rezultacie bazowy harmonogram projektu.
7.1. Szacowanie kosztów — dane finansowe s
á
u
Īą
ce do oceny kosztu ca
á
ego
projektu, przygotowywane na bazie pakietów roboczych (5.3) i listy
czynno
Ğ
ci (6.1).
7.2. Zatwierdzenie bud
Ī
etu — bazowy plan kosztów jest wdra
Ī
any równolegle
z zako
Ĕ
czeniem prac nad harmonogramem (6.5).
8.1. Planowanie jako
Ğ
ci — przygotowanie planu zarz
ą
dzania jako
Ğ
ci
ą
wytwarzanych przez projekt produktów i samego sposobu realizacji projektu.
9.1. Planowanie zasobów ludzkich — zdefiniowanie odpowiedzialno
Ğ
ci
poszczególnych cz
á
onków zespo
á
u oraz ustalenie, kto, do kogo i kiedy raportuje
w obr
Ċ
bie zespo
á
u projektowego.
10.2. Planowanie komunikacji — zdefiniowanie mechanizmów przekazywania
informacji pomi
Ċ
dzy kierownikiem projektu a interesariuszami.
11.1. Planowanie zarz
ą
dzania ryzykiem — zdefiniowanie procedur zarz
ą
dzania
ryzykiem.
11.2. Identyfikacja ryzyka — okre
Ğ
lenie wej
Ğ
ciowej listy ryzyk, które zosta
á
y
wykryte przez zespó
á
projektowy lub osoby spoza tego zespo
á
u.
11.3. Jako
Ğ
ciowa analiza ryzyka — analiza merytoryczna poszczególnych ryzyk.
11.4. Ilo
Ğ
ciowa analiza ryzyka — prze
á
o
Ī
enie wiedzy na temat ryzyka na warto
Ğ
ci
liczbowe w takich obszarach jak prawdopodobie
Ĕ
stwo wyst
Ċ
powania lub wp
á
yw
na projekt.
11.5. Planowanie reakcji na ryzyko — podejmowanie decyzji zwi
ą
zanych
z ryzykami.
12.1. Planowanie zaopatrzenia — co, kiedy i jak powinno zosta
ü
zakupione
lub uzyskane, w
áą
cznie z podj
Ċ
ciem decyzji typu „zrobi
ü
, czy kupi
ü
”.
Procesy planistyczne z PMBoK zawieraj
ą
w sobie mechanizmy analogiczne do pro-
cesów planowania (PL), inicjowania projektu (IP) i zarz
ą
dzania zakresem etapu (ZE)
z metodyki Prince2, ale w obszarach zwi
ą
zanych z zarz
ą
dzaniem zasobami ludzkimi
oraz zaopatrzeniem PMBoK wyra
Ĩ
nie wykracza poza ramy Prince2.
Ka
Ī
dy z wymienionych powy
Ī
ej procesów zawiera pewn
ą
grup
Ċ
sugerowanych technik.
Wszystkie s
ą
wyliczone w za
áą
czniku A, ale cz
ĊĞü
z nich jest szczególnie interesuj
ą
ca….
Techniki związane z procesem 6.2. Szeregowanie czynnoĞci
Metoda Diagramów NastĊpstw
(ang.
Precedence Diagramming Method
)
opisuje najbardziej popularny sposób wi
ą
zania ze sob
ą
czynno
Ğ
ci w takich
pakietach jak MS Project. Definiuje czynno
Ğ
ci jako w
Ċ
z
á
y, które s
ą
ze sob
ą
po
áą
czone strza
á
kami. Relacja pomi
Ċ
dzy zadaniami mo
Ī
e by
ü
nast
Ċ
puj
ą
ca.
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
43
Koniec-do-Pocz
ą
tku: poprzednik musi zako
Ĕ
czy
ü
si
Ċ
, zanim zacznie si
Ċ
nast
Ċ
pnik (naj-
cz
ĊĞ
ciej wykorzystywany mechanizm
áą
czenia zada
Ĕ
). Przyk
á
ad — proces s
ą
dowy musi
dobiec ko
Ĕ
ca, zanim zacznie si
Ċ
wykonanie wyroku (rysunek 8).
Rysunek 8.
Relacja pomiĊdzy
zadaniami Koniec-
do-Początku
Oto inne, rzadziej stosowane typy relacji.
Koniec-do-Ko
Ĕ
ca: poprzednik musi zako
Ĕ
czy
ü
si
Ċ
, zanim sko
Ĕ
czy si
Ċ
nast
Ċ
pnik (bardzo
rzadko wykorzystywany mechanizm). Przyk
á
ad — proces s
ą
dowy musi si
Ċ
sko
Ĕ
czy
ü
,
zanim sko
Ĕ
czy si
Ċ
tymczasowe zatrzymanie (rysunek 9).
Rysunek 9. Relacja pomiĊdzy zadaniami Koniec-do-KoĔca
Pocz
ą
tek-do-Pocz
ą
tku: poprzednik musi si
Ċ
rozpocz
ąü
, zanim zacznie si
Ċ
nast
Ċ
pnik
(bardzo rzadko wykorzystywany mechanizm). Przyk
á
ad — dzia
á
alno
Ğü
przest
Ċ
pcza
musi si
Ċ
rozpocz
ąü
, zanim zacznie si
Ċ
proces s
ą
dowy (rysunek 10).
Rysunek 10. Relacja pomiĊdzy zadaniami Początek-do-Początku
Pocz
ą
tek-do-Ko
Ĕ
ca: poprzednik musi si
Ċ
zacz
ąü
, zanim nast
Ċ
pnik si
Ċ
zako
Ĕ
czy (bardzo
rzadko wykorzystywany mechanizm). Przyk
á
ad — proces s
ą
dowy musi si
Ċ
zacz
ąü
, zanim
nast
ą
pi przedawnienie (rysunek 11).
44
Cz
öĈè I i Metodyki zarzñdcze a praktyka
Rysunek 11.
Relacja pomiĊdzy
zadaniami
Początek-do-KoĔca
W praktyce zale
Ī
no
Ğ
ci pomi
Ċ
dzy zadaniami dokumentuje si
Ċ
zazwyczaj za pomoc
ą
wykresów Gantta z wykorzystaniem aplikacji typu MS Project lub w arkuszu Excel.
W obu przypadkach, je
Ī
eli zachodzi konieczno
Ğü
wi
ą
zania ze sob
ą
zada
Ĕ
, najcz
ĊĞ
ciej sto-
suje si
Ċ
relacje typu Koniec-do-Pocz
ą
tku, czyli w kolumnie Poprzednik zaznacza si
Ċ
konkretne zadania.
Technika analizy zaleĪnoĞci
(ang.
Dependency Determination
) wyja
Ğ
nia
charakter zale
Ī
no
Ğ
ci pomi
Ċ
dzy czynno
Ğ
ciami. I tak mamy:
zale
Ī
no
Ğ
ci wymagane — zwi
ą
zane z natur
ą
pracy do wykonania,
zale
Ī
no
Ğ
ci rozwa
Ī
ne — zwi
ą
zane z tradycj
ą
, najlepszymi praktykami,
czyli logiczne,
zale
Ī
no
Ğ
ci zewn
Ċ
trzne — zwi
ą
zane ze stanami lub produktami, które musz
ą
zosta
ü
osi
ą
gni
Ċ
te, dostarczone poza projektem. Zale
Ī
no
Ğ
ci te powinny by
ü
elementem rejestru ryzyk.
Technika przyspieszeĔ i opóĨnieĔ
(ang.
Applying Leads and Lags
) wi
ąĪ
e dwie
czynno
Ğ
ci na zasadzie „Rozpocz
ąü
zadanie B na X jednostek czasu, zanim
zako
Ĕ
czy si
Ċ
zadanie A” (przyspieszenie) lub „Zadanie B mo
Ī
e si
Ċ
rozpocz
ąü
na X jednostek czasu po zako
Ĕ
czeniu zadania A” (opó
Ĩ
nienie).
MS Project posiada tego typu funkcjonalno
Ğü
; jest to parametr o nazwie „Zw
á
oka” przy
definiowaniu poprzedników zadania. Na rysunku 12. przedstawione jest zadanie B,
które ma zacz
ąü
si
Ċ
na jeden dzie
Ĕ
przed zako
Ĕ
czeniem zadania A. Parametr „Zw
á
oka”
w MS Project mo
Ī
e przybiera
ü
warto
Ğü
dodatni
ą
(opó
Ĩ
nienie) lub ujemn
ą
(przyspieszenie).
Szablony harmonogramu sieciowego
(ang.
Schedule Network Templates)
— s
ą
to szablony harmonogramów wykorzystywane wtedy, kiedy w ramach
projektu maj
ą
zosta
ü
dostarczone identyczne lub bardzo podobne produkty,
takie jak pi
Ċ
tra wie
Ī
owca.
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
45
Rysunek 12. Przyspieszenia i opóĨnienia zadaĔ w MS Project
Techniki związane z procesem 3.5. Opracowanie harmonogramu
Oprócz standardowych rozwi
ą
za
Ĕ
, takich jak wykres Gantta, PMBoK opisuje nast
Ċ
pu-
j
ą
ce techniki.
Analiza sieciowa harmonogramu
zawiera wszystkie techniki zwi
ą
zane
z tworzeniem harmonogramu projektu, takie jak metoda
Ğ
cie
Ī
ki krytycznej,
metoda
á
a
Ĕ
cucha krytycznego, analiza „co je
Ğ
li” i równowa
Ī
enie zasobów.
G
á
ównym celem jest oszacowanie wcze
Ğ
niejszych oraz pó
Ĩ
niejszych dat
rozpocz
Ċ
cia i zako
Ĕ
czenia czynno
Ğ
ci projektowych.
Metoda ĞcieĪki krytycznej
(ang.
Critical path method
) dla ka
Ī
dej czynno
Ğ
ci
szacuje optymistyczn
ą
(wcze
Ğ
niejsz
ą
) i pesymistyczn
ą
(pó
Ĩ
niejsz
ą
) dat
Ċ
rozpocz
Ċ
cia i zako
Ĕ
czenia. Szacunki te wykonane s
ą
bez uwzgl
Ċ
dnienia ogranicze
Ĕ
zasobowych. Nast
Ċ
pnie analizowane s
ą
wzajemne zale
Ī
no
Ğ
ci mi
Ċ
dzy
czynno
Ğ
ciami. W rezultacie otrzymujemy informacj
Ċ
o tym, w jakich granicach
mo
Ī
emy przesuwa
ü
wykonanie poszczególnych czynno
Ğ
ci. Brak takiej swobody
w stosunku do serii zada
Ĕ
okre
Ğ
lany jest mianem
Ğ
cie
Ī
ki krytycznej. Harmonogram
mo
Ī
e mie
ü
kilka
Ğ
cie
Ī
ek krytycznych. Metoda ma na celu takie przemodelowanie
planu, aby uzyska
ü
maksymalnie du
Īą
swobod
Ċ
jego wykonania.
Metoda áaĔcucha krytycznego
(ang.
Critical chain method
) przyjmuje
za punkt wyj
Ğ
cia zdefiniowane
Ğ
cie
Ī
ki krytyczne. Uzupe
á
nia plany o ograniczenia
zasobowe i tak zmodyfikowane
Ğ
cie
Ī
ki krytyczne uzyskuj
ą
miano
á
a
Ĕ
cucha
krytycznego. W ramach tego procesu na ko
Ĕ
cu ca
á
ego projektu dodawane
s
ą
dodatkowe bufory czasu (ang.
the project buffer
), które maj
ą
zabezpieczy
ü
projekt przed przekroczeniem terminów ko
Ĕ
cowych. Dodatkowo do
á
a
Ĕ
cuchów
zada
Ĕ
o najwi
Ċ
kszej niepewno
Ğ
ci dodawane s
ą
równie
Ī
dodatkowe bufory czasu
(ang.
the feeding buffer)
. Wykorzystuj
ą
c t
Ċ
metod
Ċ
, nale
Ī
y w trakcie realizacji
projektu koncentrowa
ü
si
Ċ
na w
á
a
Ğ
ciwym stosowaniu buforów.
RównowaĪenie zasobów
(ang.
Resource leveling
) to technika, która zak
á
ada du
Ī
e
ograniczenie w dost
Ċ
pno
Ğ
ci do zasobów. Przyk
á
adowo przy u
Ī
yciu tego samego
zasobu mo
Ī
e realizowa
ü
równocze
Ğ
nie dwa ró
Ī
ne projekty, okre
Ğ
lona pula
zasobów mo
Ī
e by
ü
dost
Ċ
pna tylko pomi
Ċ
dzy konkretnymi datami na
okre
Ğ
lon
ą
d
á
ugo
Ğü
. Tego typu ograniczenia mog
ą
powodowa
ü
znacz
ą
ce
zmiany w harmonogramie. Je
Ī
eli np. okazuje si
Ċ
,
Ī
e mamy osiem osób
do d
á
ugoterminowej dyspozycji, a wykres zaanga
Ī
owania wygl
ą
da tak jak
46
Cz
öĈè I i Metodyki zarzñdcze a praktyka
Prawo Parkinsona
8
mówi,
Ī
e praca zawsze rozrasta si
Ċ
w taki sposób, aby zape
á
ni
ü
ca
á
y
zaplanowany na ni
ą
czas. W zwi
ą
zku z tym, nie ma sensu dodawa
ü
kolejnych buforów
do ka
Ī
dej czynno
Ğ
ci, gdy
Ī
z pewno
Ğ
ci
ą
zostan
ą
zu
Ī
yte. Warto doda
ü
pewne bufory
„na czarn
ą
godzin
Ċ
” na ko
Ĕ
cu projektu poza konkretnymi zadaniami jako swoist
ą
rezerw
Ċ
strategiczn
ą
. Warto równie
Ī
motywowa
ü
zespó
á
do ich niewykorzystywania (np. premie).
na rysunku 13, to plany musz
ą
zosta
ü
tak przeprojektowane, aby zrównowa
Ī
y
ü
wykorzystanie zasobów. Takie zmiany musz
ą
zosta
ü
wykonane nawet wtedy,
je
Ğ
li spowoduje to wyd
á
u
Ī
enie realizacji pewnych zada
Ĕ
.
Wymagania nadmiarowe
Ilo
Ğü
zasobów
11
10
9
Poziom dost
Ċ
pnych zasobów
8
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10
Tygodnie
Rysunek 13. Mechanizm równowaĪenia zasobów
Analiza scenariuszy „co, jeĞli
” — w przypadku kilku wariantów realizacji
projektu analizowane s
ą
konsekwencje ka
Ī
dego z nich.
Kompresja harmonogramu
to metoda skracania
Ğ
cie
Ī
ki krytycznej bez zmiany
zakresu projektu. Wykorzystuje si
Ċ
do tego poni
Ī
sze techniki.
Kruszenie (ang.
crashing
) to technika, która analizuje koszty wzgl
Ċ
dem
harmonogramu i próbuje uzyska
ü
jak najwi
Ċ
ksz
ą
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. i Project Management Body of Knowledge — PMBoK
47
najni
Ī
sz
ą
cen
Ċ
. Przyk
á
adowe sposoby stosowania tej techniki to nadgodziny,
dodatkowe zasoby lub premie za realizacj
Ċ
zada
Ĕ
na
Ğ
cie
Ī
ce krytycznej.
Technika ta nie zawsze tworzy rzeczywist
ą
alternatyw
Ċ
i mo
Ī
e powodowa
ü
zwi
Ċ
kszone ryzyko projektowe.
Szybkie
Ğ
ledzenie (ang.
Fast tracking
) to ca
á
kowite lub cz
ĊĞ
ciowe
zrównoleglenie czynno
Ğ
ci, które normalnie by
á
yby wykonywane sekwencyjne.
Zrównoleglenie czynno
Ğ
ci powoduje konieczno
Ğü
ich ko
Ĕ
cowej integracji.
Jest to pewien dodatkowy koszt i ryzyko, które nale
Ī
y wzi
ąü
pod uwag
Ċ
przy
okazji podejmowania tego typu decyzji.
Oprogramowanie do zarz
ą
dzania projektami (np. MS Project).
Techniki wspierające podejmowanie decyzji, stosowane m.in. w procesach 5.1.
Zbieranie wymagaĔ i 8.1. Planowanie jakoĞci
„Burza mózgów”
(ang.
Brainstorming
) to swobodna dyskusja ca
á
ego zespo
á
u
na kluczowe tematy projektowe, gdzie ka
Ī
dy ma równe prawo g
á
osu i g
á
ow
Ċ
otwart
ą
na nieszablonowe pomys
á
y. W trakcie tych sesji nie ma „g
á
upich
pomys
á
ów”.
Rano po kawie, gdy umys
á Ğ
wie
Ī
y, zabieramy cz
á
onkinie i cz
á
onków zespo
á
u do salki
konferencyjnej lub na spacer. Otwieramy tabliczk
Ċ
czekolady, paczk
Ċ
z p
ą
czkami lub
k
á
adziemy na stó
á
bilety do teatru i pytamy, jak rozwi
ą
za
ü
problem komiwoja
Ī
era, cho
ü
by
i w najbardziej oryginalny sposób… Pozostaje jedynie pobudza
ü
umys
á
y do twórczej
dyskusji, ruga
ü
osoby, które dyskwalifikuj
ą
cudze idee, i sumiennie notowa
ü
najlepsze
pomys
á
y.
Technika grupy nominalnej
(ang.
Nominal group technique
) to „uczesana”
wersja burzy mózgów, w której zebrana grupa jest zaznajomiona z problemem
i samodzielnie zapisuje propozycje jego rozwi
ą
zania. Po spisaniu pomys
á
ów
ka
Ī
da osoba przedstawia swoje rozwi
ą
zanie reszcie zespo
á
u, a nast
Ċ
pnie wszyscy
dyskutuj
ą
ze sob
ą
, wyja
Ğ
niaj
ą
c i rozwijaj
ą
c warianty. Ostatecznie decyzja jest
podejmowana w demokratycznym g
á
osowaniu
9
.
Technika delficka
(ang.
The Delphi Technique
) — grupa ekspertów
odpowiada na ankiety i udost
Ċ
pnia informacj
Ċ
zwrotn
ą
, która umo
Ī
liwia
doprecyzowanie problemu. W nast
Ċ
pnej rundzie eksperci otrzymuj
ą
kolejn
ą
propozycj
Ċ
rozwi
ą
zania problemu wraz z list
ą
anonimowych uwag
i uzasadnie
Ĕ
. Eksperci udzielaj
ą
wtedy kolejnej serii odpowiedzi. Tego typu
technika mo
Ī
e zosta
ü
zastosowana do rozwi
ą
zania kluczowych problemów
biznesowych lub projektowych.
9
http://www.joe.org/joe/2007february/iw1.shtml
48
Cz
öĈè I i Metodyki zarzñdcze a praktyka
Wujek Dobra Rada — odcinek 3. „W zespole si
äa”
CO DWIE GãOWY, TO NIE JEDNA — DEMOKRATYCZNY SPOSÓB PODEJMOWANIA DECYZJI
ZWIõKSZA ZAANGAēOWANIE CZãONKÓW ZESPOãU I ICH MOTYWACJõ
Mapa pomysáów
(ang.
Idea/mind mapping
) to technika podobna do diagramów
pokrewie
Ĕ
stwa, która polega na umieszczeniu wszystkich pomys
á
ów na jednej
mapie, po to aby odnale
Ĩü
ich wzajemne ró
Ī
nice i cz
ĊĞ
ci wspólne.
Diagramy pokrewieĔstwa
(ang.
Affinity diagram
) — metoda wymy
Ğ
lona
w latach 60. ubieg
á
ego wieku przez japo
Ĕ
skiego antropologa Jiro Kawakit
Ċ
.
Jest to tablica, na której za pomoc
ą Ī
ó
á
tych karteczek wypisujemy wszystkie
kwestie, grupujemy je, okre
Ğ
lamy mi
Ċ
dzy nimi relacje, nadajemy im priorytety
i czynimy stosowne ustalenia na przysz
á
o
Ğü
, tak jak zaprezentowano
na rysunku 14.
Analiza pola siáy
(ang.
force field analysis
) to analiza si
á
dzia
á
aj
ą
cych
na projekt, szczególnie u
Ī
yteczna przy podejmowaniu kluczowych decyzji;
jest to specjalizowana metoda analizy „za i przeciw”. Bazuj
ą
c na konkretnym
projekcie, planie czy rozwi
ą
zaniu, nale
Ī
y okre
Ğ
li
ü
si
á
y dzia
á
aj
ą
ce na jego korzy
Ğü
i niekorzy
Ğü
oraz zdefiniowa
ü
ocen
Ċ
ka
Ī
dej z si
á
(rysunek 15).
Za pomoc
ą
takiego podej
Ğ
cia mo
Ī
na podj
ąü
bardziej trafn
ą
decyzj
Ċ
i zdefiniowa
ü
, jakie
si
á
y nale
Ī
y wzmocni
ü
, a jakie os
á
abi
ü
.
Diagram relacji
(ang.
interrelationship diagram
) to diagram relacji
przyczynowo-skutkowych. Nale
Ī
y sformu
á
owa
ü
problem oraz kwestie z nim
zwi
ą
zane, a nast
Ċ
pnie zdefiniowa
ü
zwi
ą
zek przyczyna-skutek pomi
Ċ
dzy kwestiami
Rozdzia
ä 2. i Project Management Body of Knowledge — PMBoK
49
Wspólne ustalenie tematu
Zapisanie i zrozumienie
faktów
Pogrupowanie
podobnych faktów
Zatytu
á
owanie grup faktów
U
á
o
Ī
enie grup i pokazanie
wzajemnych relacji
G
á
osowanie
nad najistotniejsz
ą
kwesti
ą
wy
Ī
szego poziomu
i konkluzja
Rysunek 14. Przykáad powstania diagramu pokrewieĔstwa
i zaprezentowa
ü
go, rysuj
ą
c strza
á
ki. W przypadku relacji s
á
abej strza
á
ka powinna
by
ü
przerywana, a w przypadku relacji silnej — ci
ą
g
á
a. Du
Ī
a liczba strza
á
ek
wychodz
ą
cych wskazuje g
á
ówn
ą
przyczyn
Ċ
problemu
10
(rysunek 16).
10
http://web2.concordia.ca/Quality/tools/17interdiagram.pdf