biznes i ekonomia zarzadzanie projektami it przewodnik po metodykach adam koszlajda ebook

background image

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

background image

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

background image

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

background image

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

background image

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

á

background image

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.

background image

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.

background image

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…

background image

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:

background image

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

background image

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,

background image

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.

background image

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

ą

”.

background image

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.

background image

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.

background image

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.

background image

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

background image

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.

background image

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

background image

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

).

background image

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

background image

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

background image

Czytaj dalej...

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


Wyszukiwarka

Podobne podstrony:
Zarzadzanie projektami IT Przewodnik po metodykach proinf
biznes i ekonomia zarzadzanie projektami z wykorzystaniem darmowego oprogramowania piotr wroblewski
biznes i ekonomia zarzadzanie lancuchem dostaw podstawy wydanie ii michael hugos ebook
biznes i ekonomia homo corporaticus czyli przewodnik przetrwania w korporacji joanna krysinska ebook
biznes i ekonomia newconnect nowa szansa na duze zyski adam jagielnicki ebook
Zarzadzanie Projektem IT
Zarządzanie projektami IT w przedsiębiorstwie
Kopia biznes plan-zarzadzanie projektem, Zarządzanie studia licencjackie, zarządzanie projektemi
Zarzadzanie projektami IT Wydanie III zarit3
Zarzadzanie projektami IT Wydanie III zarit3

więcej podobnych podstron