plik

Spis treĈci

Wst

öp .............................................................................................. 7

öĈè 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

öĈè 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

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

öĈè 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

öĈè 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

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

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

pro-

jektu, zakresem, czasem, kosztami, jako

, zasobami ludzkimi, komunikacj

, ryzykiem

i zaopatrzeniem.

Szczypta historii

Organizacja PMI powsta

a w USA w 1969 roku jako organizacja non profit zrzeszaj

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

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

öĈè I i Metodyki zarzñdcze a praktyka

to podej

cie jako standard 1490

. Od tej pory, co oko

o 4 lata pojawiaj

kolejne

aktualizacje tej metodyki ( w latach 1996, 2000 i 2004). Ostatnia, czwarta edycja ujrza

wiat

o dzienne 31 grudnia 2008 roku.

Wersja czwarta nie zawiera rewolucyjnych zmian w stosunku do wersji trzeciej, ale

na zauwa

kilka pozytywnych zmian ewolucyjnych. Oto one.

Lepsze zarz

dzanie interesariuszami, które pojawia si

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

on z procesem „5.1. Planowanie zarz

dzania zakresem projektu”, który

w PMBoK4 nazywa si

„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

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

one mia

znaczenie praktyczne.

Technika Uzyskanej Warto

ci (ang.

Earned Value Technique

— EVT), która

a cz

ĊĞ

techniki „analizy miar wydajno

ciowych” w procesie „7.3. Kontrola

kosztów”, sta

a si

noprawn

technik

Zarz

dzania Uzyskan

Warto

(ang.

Earned Value Management

— EVM). Technika ta uleg

a równie

pewnemu

rozwini

ciu i pojawi

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

áą

cznie na numerach rozdzia

ów i podrozdzia

ów.

Standard IEEE Std 1490-1998 zosta

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

Rozdzia

ä 2. i Project Management Body of Knowledge — PMBoK

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

, 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

liwych k

opotów i zarz

dzanie nimi, zanim stan

krytyczne.

— Integrowaè siö! Integrowaè — rzecze Najlepszy Kierownik Projektu.

Numery obszarów wiedzy s

zwi

zane z numerami rozdzia

ów w oficjalnych podr

cznikach PMBoK.

öĈè 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

procesy Zarz

dzanie Zakresem Etapu (ZE) i Zarz

dzanie Wytwarzaniem Produktów (WP) w Prince2.

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

e w celu redukcji kosztów zamon-

towane zostan

inne szyby o gorszych parametrach.

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

skonstruowa

pierwszy prototyp, który pomy

lnie przeszed

pierwsz

seri

testów

terenowych. Podj

to decyzj

o uruchomieniu produkcji i wyprodukowano pierwsz

setk

knych, czerwonych, l

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

nie

my je z lawety kolejowej! B

dziemy musieli jako

atwi

spraw

u nas, lokalnie… klienci czekaj

…

— Zaraz, zaraz… Transport kolejowy!?
— Tak! Przecie

pisali

my,

e tylnie szyby maj

wytrzymywa

szybko

Ğü

50km/h.

— No w

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

Obszar wiedzy
Czas (rozdzia

ä 6.)

Ten obszar wiedzy to wszystkie dzia

ania zwi

zane z wykonaniem projektu w za

onym

terminie, o ile zmianie nie uleg

y przyj

te za

enia oraz zakres. Szczegó

owo przyjmuje

on prost

sekwencj

zdarze

zdefiniowanie zbioru planowanych dzia

— 6.1,

ustanowienie wzajemnych zale

ci czasowych pomi

dzy tymi dzia

aniami

(co musi by

zrobione najpierw, a co potem, jakie dzia

ania mog

wykonywane równocze

nie) — 6.2,

oszacowanie potrzeb zasobowych i czasu trwania poszczególnych dzia

— 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

szej perspektywie maj

przynie

Ğü

organizacji zysk. Aby projekt zako

czy

powodzeniem, konieczne jest

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

ciwego zarz

dzania

jako

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

postrzeganymi jako pojedyncze osoby i zespo

y. Oznacza to:

öĈè 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

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

. 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-

ci pracowników.

R1 — pracownik o niskich kompetencjach, który na swoim koncie nie ma

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

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

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

, delegowanie z

onych zada

pracownikom o niskich

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

öĈè I i Metodyki zarzñdcze a praktyka

ciw

dystrybucj

informacji i zarz

dzanie interesariuszami — 10.3, 10.4,

przygotowanie i dystrybucj

kontrolnych raportów wydajno

ciowych — 10.5.

Nale

y zauwa

e w dzisiejszych czasach dobra komunikacja nie jest mo

liwa bez

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

jest do

Ğü

rozproszona,

co zobrazowano na rysunku 5.

Rysunek 5.
Wynik ankiety
„Jakich systemów
EPM uĪywasz?”
Pierra-Jeana
Cherreta

Inn

ciekaw

alternatyw

dla rozwi

tego typu jest firmowe wiki rozwijane na bazie

rozwi

darmowych, takich jak MediaWiki, na której bazuje Wikipedia, lub rozwi

odp

atnych, np. Confluence.

W rozproszonych zespo

ach warto dodatkowo zainwestowa

w narz

dzia wspó

pracy

zdalnej (ang.

collaboration tools

), takie jak WebEx

, 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:

Na podstawie ankiety „Jakich systemów EPM u

ywasz?” uruchomionej przez Pierra-Jeana Cherreta

w serwisie spo

eczno

ciowym Plaxo.

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

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

nierzy te

nie mia

bym ochoty z entuzjazmem stawa

do walki za Hitlera i po

asne

ycie”

Procesy i techniki

dy z procesów, oprócz przynale

ci do obszaru wiedzy, nale

y do jednej z 5 g

ów-

nych grup procesów. Wzajemna zale

Ğü

tych grup jest stosunkowo prosta (rysunek 6).

Jeden projekt mo

e sk

ada

z wielu etapów

i ka

dy z nich b

dzie zarz

dzany przez

PMBoK oddzielnie. W szczególnym przypadku, gdy dwa etapy zachodz

na siebie,

G. Knopp,

Stalingrad

wiat Ksi

ąĪ

ki, Warszawa 2007, s.150.

Formalnie, w nomenklaturze PMBoK „etap” nazywa si

„faz

”.

öĈè I i Metodyki zarzñdcze a praktyka

Rysunek 6.
Architektura grup
procesów PMBoK

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

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

wszystkie osoby lub organizacje, które maj

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

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

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

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

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.

öĈè 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

Īą

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

wytwarzanych przez projekt produktów i samego sposobu realizacji projektu.

9.1. Planowanie zasobów ludzkich — zdefiniowanie odpowiedzialno

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

wykryte przez zespó

projektowy lub osoby spoza tego zespo

11.3. Jako

ciowa analiza ryzyka — analiza merytoryczna poszczególnych ryzyk.

11.4. Ilo

ciowa analiza ryzyka — prze

enie wiedzy na temat ryzyka na warto

liczbowe w takich obszarach jak prawdopodobie

stwo wyst

powania lub wp

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.

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

y, które s

ze sob

áą

czone strza

kami. Relacja pomi

dzy zadaniami mo

e by

nast

puj

ca.

Rozdzia

ä 2. i Project Management Body of Knowledge — PMBoK

Koniec-do-Pocz

tku: poprzednik musi zako

czy

, zanim zacznie si

nast

pnik (naj-

ĊĞ

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

, 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).

öĈè I i Metodyki zarzñdcze a praktyka

Rysunek 11.
Relacja pomiĊdzy
zadaniami
Początek-do-KoĔca

W praktyce zale

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

Ğü

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

ci pomi

dzy czynno

ciami. I tak mamy:

zale

ci wymagane — zwi

zane z natur

pracy do wykonania,

zale

ci rozwa

ne — zwi

zane z tradycj

, najlepszymi praktykami,

czyli logiczne,

zale

ci zewn

trzne — zwi

zane ze stanami lub produktami, które musz

zosta

osi

gni

te, dostarczone poza projektem. Zale

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

ąü

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

Rysunek 12. Przyspieszenia i opóĨnienia zadaĔ w MS Project

Techniki związane z procesem 3.5. Opracowanie harmonogramu

Oprócz standardowych rozwi

, takich jak wykres Gantta, PMBoK opisuje nast

pu-

ce techniki.

Analiza sieciowa harmonogramu

zawiera wszystkie techniki zwi

zane

z tworzeniem harmonogramu projektu, takie jak metoda

cie

ki krytycznej,

metoda

cucha krytycznego, analiza „co je

li” i równowa

enie zasobów.

ó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

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

ci mi

dzy

czynno

ciami. W rezultacie otrzymujemy informacj

o tym, w jakich granicach

emy przesuwa

wykonanie poszczególnych czynno

ci. Brak takiej swobody

w stosunku do serii zada

okre

lany jest mianem

cie

ki krytycznej. Harmonogram

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

cucha

krytycznego. W ramach tego procesu na ko

cu ca

ego projektu dodawane

dodatkowe bufory czasu (ang.

the project buffer

), które maj

zabezpieczy

projekt przed przekroczeniem terminów ko

cowych. Dodatkowo do

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

na w

ciwym stosowaniu buforów.

RównowaĪenie zasobów

(ang.

Resource leveling

) to technika, która zak

ada du

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

ugo

Ğü

. Tego typu ograniczenia mog

powodowa

znacz

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

öĈè I i Metodyki zarzñdcze a praktyka

Prawo Parkinsona

mówi,

e praca zawsze rozrasta si

w taki sposób, aby zape

zaplanowany na ni

czas. W zwi

zku z tym, nie ma sensu dodawa

kolejnych buforów

do ka

dej czynno

ci, gdy

z pewno

zostan

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

wykorzystanie zasobów. Takie zmiany musz

zosta

wykonane nawet wtedy,

li spowoduje to wyd

enie realizacji pewnych zada

Wymagania nadmiarowe

Ilo

Ğü

zasobów
11
10

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

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

najni

cen

. Przyk

adowe sposoby stosowania tej techniki to nadgodziny,

dodatkowe zasoby lub premie za realizacj

zada

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

na kluczowe tematy projektowe, gdzie ka

dy ma równe prawo g

osu i g

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

adziemy na stó

bilety do teatru i pytamy, jak rozwi

problem komiwoja

era, cho

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

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

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

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.

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

öĈè 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

Ğü

, tak jak zaprezentowano

na rysunku 14.

Analiza pola siáy

(ang.

force field analysis

) to analiza si

dzia

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

y dzia

ce na jego korzy

Ğü

i niekorzy

Ğü

oraz zdefiniowa

ocen

dej z si

(rysunek 15).

Za pomoc

takiego podej

cia mo

na podj

ąü

bardziej trafn

decyzj

i zdefiniowa

, jakie

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

Czytaj dalej...

Rozdzia

ä 2. i Project Management Body of Knowledge — PMBoK

Wspólne ustalenie tematu

Zapisanie i zrozumienie

faktów

Pogrupowanie

podobnych faktów

Zatytu

owanie grup faktów

enie grup i pokazanie

wzajemnych relacji

osowanie

nad najistotniejsz

kwesti

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

przerywana, a w przypadku relacji silnej — ci

a. Du

a liczba strza

wychodz

cych wskazuje g

ówn

przyczyn

problemu

(rysunek 16).

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