plik


ÿþZarz¹dzanie projektami IT. Przewodnik po metodykach Autor: Adam Koszlajda ISBN: 978-83-246-1804-0 Format: 158´ð235, 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³aSciwe 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 okreSlenia celów i struktury produktu koñcowego, jak równie¿ Srodków i czasu niezbêdnych do realizacji projektu. W zale¿noSci 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³aSnie temu s³u¿y wybór konkretnej metodyki, zapewniaj¹cej sensowny podzia³ zadañ oraz zakresu odpowiedzialnoSci poszczególnych osób i p³ynne przechodzenie miêdzy kolejnymi etapami projektu. Przekrojowy opis takich metodyk, stosowanych w bran¿y IT, znajdziesz w³aSnie 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 podejScia 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³oSæ urozmaicaj¹ sentencje  Wujka dobra rada , podkreSlaj¹ce najistotniejsze aspekty prezentowanych zagadnieñ, oraz przejrzyste, czêsto humorystyczne ilustracje. Czytaj¹c tê ksi¹¿kê, poznasz: " metodyki zarz¹dcze  Prince2 oraz PMBoK4 " metodyki wytwórcze  RUP i MSF " metodyki adaptacyjne  eXtreme Programming i SCRUM " metodyki organizacyjne  CMMI, Six Sigma, ITIL lub COBIT " kilka przyk³adów sposobów ³¹czenia tych metodyk Spis tre[ci Wstp .............................................................................................. 7 Cz[ I Metodyki zarzdcze a praktyka ..................................... 11 RozdziaB 1. PRoject IN Controlled Environment  Prince2 ................................ 13 Szczypta historii ............................................................................................................. 13 Procesy ........................................................................................................................... 14 Komponenty ................................................................................................................... 17 Techniki .......................................................................................................................... 21 Zarzdzanie dokumentacj ............................................................................................. 24 Dostosowywanie do potrzeb organizacji ........................................................................ 25 Certyfikacja .................................................................................................................... 25 Podsumowanie ................................................................................................................ 26 Rozmowa z... .................................................................................................................. 27 RozdziaB 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 RozdziaB 3. Rational Unified Process (RUP) ...................................................... 73 Szczypta historii ............................................................................................................. 73 Proces ............................................................................................................................. 74 Dyscypliny RUP ............................................................................................................. 76 AbecadBo metodyki RUP ................................................................................................ 79 Adaptacja RUP do potrzeb organizacji ........................................................................... 80 Podsumowanie RUP ....................................................................................................... 81 Rozmowa z... .................................................................................................................. 82 PrzykBad Prince2 i RUP  BlogSerwis .......................................................................... 85 4 Zarzdzanie projektami IT. Przewodnik po metodykach RozdziaB 4. Microsoft Solution Framework (MSF) ............................................ 105 Szczypta historii ........................................................................................................... 105 Proces ........................................................................................................................... 106 Model zespoBu .............................................................................................................. 107 Faza Wizji ..................................................................................................................... 108 Faza Planowania ........................................................................................................... 109 Faza Konstrukcji ........................................................................................................... 112 Faza Stabilizacji ............................................................................................................ 116 Faza Wdro|enia ............................................................................................................ 120 MSF > MOF ................................................................................................................. 121 Trójkt negocjacyjny .................................................................................................... 123 Dyscypliny zarzdcze ................................................................................................... 125 Certyfikacja .................................................................................................................. 126 Podsumowanie  MSF a RUP .................................................................................... 126 RozdziaB 5. PrzykBad PMBoK i MSF  wdro|enie systemu BI ........................... 129 Cz[ III Metodyki adaptacyjne a praktyka ............................... 177 RozdziaB 6. eXtreme Programming .................................................................. 179 Szczypta historii ........................................................................................................... 179 Role .............................................................................................................................. 180 Proces ........................................................................................................................... 180 Wdro|enie .................................................................................................................... 186 RozdziaB 7. Scrum .......................................................................................... 189 Szczypta historii ........................................................................................................... 190 Role .............................................................................................................................. 190 Proces ........................................................................................................................... 191 Podsumowanie .............................................................................................................. 196 Rozmowa z... ................................................................................................................ 197 RozdziaB 8. Joel o oprogramowaniu ................................................................. 205 RozdziaB 9. PrzykBad  Scrum BlogSerwis ...................................................... 209 Cz[ IV Metodyki organizacyjne a praktyka ............................. 223 RozdziaB 10. Capability Maturity Model Integration (CMMI) .............................. 225 Szczypta historii ........................................................................................................... 226 Poziomy CMMI ............................................................................................................ 228 Procesy ......................................................................................................................... 229 Podsumowanie .............................................................................................................. 235 RozdziaB 11. Six Sigma .................................................................................... 239 Szczypta historii ........................................................................................................... 240 Wdro|enie .................................................................................................................... 241 Certyfikacja .................................................................................................................. 245 Podsumowanie .............................................................................................................. 245 RozdziaB 12. Information Technology Infrastructure Library (ITIL) ....................... 247 Szczypta historii ........................................................................................................... 247 Role .............................................................................................................................. 249 Procesy ......................................................................................................................... 251 Wdro|enie .................................................................................................................... 254 Spis tre[ci 5 Certyfikacja .................................................................................................................. 256 Podsumowanie .............................................................................................................. 257 Rozmowa z... ................................................................................................................ 258 RozdziaB 13. Control Objectives for Information and related Technology (COBIT) 263 Szczypta historii ........................................................................................................... 264 Role .............................................................................................................................. 265 Procesy ......................................................................................................................... 266 Certyfikacja .................................................................................................................. 273 Podsumowanie .............................................................................................................. 274 Cz[ V Rozwizania kombinowane ......................................... 275 Podsumowanie ............................................................................. 281 Dodatki ..................................................................................... 283 Dodatek A Lista wszystkich 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 yródBa .......................................................................................... 339 Skorowidz .................................................................................... 343 RozdziaB 2. Project Management Body of Knowledge  PMBoK Podej[cie PMBoK jest czsto przedstawiane jako  metodyka PMI , czyli metodyka organizacji Project Management Institute zrzeszajcej specjalistów z dziedziny zarz- dzania projektami. PMBoK koncentruje si na zebraniu i przedstawieniu dobrych praktyk zwizanych z zarzdzaniem projektami w ramach zdefiniowanych obszarów wiedzy. W pewnym sensie PMBoK jest podej[ciem konkurencyjnym w stosunku do Prince2 i ze wzgldu na nieco wiksz 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 zarzdzanie zasobami ludzkimi oraz zaopatrzeniem. PMBoK w wersji czwartej definiuje pi grup procesów, takich jak procesy rozpoczcia, planowania, realizacji, kontroli i zakoDczenia. Ka|dy z tych procesów nale|y równie| do jednego z dziewiciu obszarów wiedzy, takich jak zarzdzanie integralno[ci pro- jektu, zakresem, czasem, kosztami, jako[ci, zasobami ludzkimi, komunikacj, ryzykiem i zaopatrzeniem. Szczypta historii Organizacja PMI powstaBa w USA w 1969 roku jako organizacja non profit zrzeszajca profesjonalistów ró|nych specjalno[ci w celu wyspecyfikowania standardowych prak- tyk zarzdczych. W 1987 roku opublikowana zostaBa pierwsza edycja PMBoK, która byBa rezultatem prac wykonanych we wczesnych latach 80. W roku 1998 American National Standards Institute (ANSI) zaakceptowaB to rozwizanie jako narodowy standard zarz- dzania projektami, a Institute of Electrical and Electronics Engineers (IEEE) zaadaptowaB 32 Cz[ I f& Metodyki zarzdcze a praktyka to podej[cie jako standard 14901. Od tej pory, co okoBo 4 lata pojawiaj si kolejne aktualizacje tej metodyki ( w latach 1996, 2000 i 2004). Ostatnia, czwarta edycja ujrzaBa [wiatBo 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 zarzdzanie interesariuszami, które pojawia si ju| w grupie procesów rozpoczcia jako nowy proces o nazwie  10.1. Identyfikacja interesariuszy . Z grupy procesów rozpoczcia zniknB proces  4.3. Opracowanie wstpnego zakresu projektu (ang. Develop preliminary scope statement). PokrywaB si on z procesem  5.1. Planowanie zarzdzania zakresem projektu , który w PMBoK4 nazywa si ju|  5.1. Planowanie zarzdzania zakresem projektu . Nie jest to tylko zmiana nazwy, ale przejaw bardziej dojrzaBego podej[cia do zarzdzania wymaganiami projektowymi. Pojawia si tu ciekawa technika  Matrycy [ledzenia wymagaD (ang. Requirements Traceability Matrix). Unifikacja pewnych elementów przekazywanych pomidzy procesami. PrzykBadowo pojawia si jeden, kluczowy plan zarzdzani projektem zamiast oddzielnych planów do zarzdzania poszczególnymi obszarami wiedzy (np. plan zarzdzania zakresem, harmonogramem, kosztem itd.). Analogicznie pojawiBo si bardziej ogólne |danie zmiany, które zawiera w sobie rekomendowane dziaBania naprawcze, prewencyjne i napraw defektów. Tego typu podej[cie jest o wiele bardziej praktyczne i umo|liwia wiksz swobod w implementacji tych mechanizmów. Znacznemu uproszczeniu i generalizacji ulegB obszar wiedzy dostaw. PMBoK4 przyjB tutaj nowy model Planowanie>Wykonanie>Administrowanie> Zamknicie. Dodatkowo wyspecyfikowane zostaBy nowe podtypy kontraktów o ustalonej cenie. Nie wiadomo jednak, czy na polskim rynku bd one miaBy znaczenie praktyczne. Technika Uzyskanej Warto[ci (ang. Earned Value Technique  EVT), która byBa cz[ci techniki  analizy miar wydajno[ciowych w procesie  7.3. Kontrola kosztów , staBa si peBnoprawn technik Zarzdzania Uzyskan Warto[ci (ang. Earned Value Management  EVM). Technika ta ulegBa równie| pewnemu rozwiniciu i pojawiB si nowy  indeks wydajno[ci niezbdnej do zakoDczenia projektu (ang. To-Complete Performance Index  TCPI). Uporzdkowaniu ulegBo nazewnictwo wszystkich procesów oraz ich numeracja, która bazuje ju| wyBcznie na numerach rozdziaBów i podrozdziaBów. 1 Standard IEEE Std 1490-1998 zostaB zaktualizowany w 2004 (!) roku do IEEE Std 1490-2003. RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 33 Obszary wiedzy PMBoK skBada si z czterdziestu dwóch procesów, z których ka|dy przynale|y do jednej z piciu grup procesów i jednego z dziewiciu obszarów wiedzy. Ka|dy z procesów posiada numer gBówny od 4. do 12., który wskazuje okre[lony obszar wiedzy2, i poboczny numer porzdkowy (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 (rozdziaB 4.) Ten obszar wiedzy jest odpowiedzialny za ogólne, wysokopoziomowe kwestie zarzdcze zwizane z realizacj projektu informatycznego, a szczególnie za: kwestie zwizane z uruchomieniem projektu (np. zdobycie mandatu na realizacj projektu)  4.1, przygotowanie planu zarzdzania projektem  4.2, zarzdzanie bie|cymi pracami projektowymi  4.3, kontrol prac projektowych i zintegrowane zarzdzanie zmian  4.4, 4.5, zamknicie projektu  4.6. Integracja to codzienne wybory miejsca koncentracji zasobów i wysiBku, wyprzedzenie mo|liwych kBopotów i zarzdzanie nimi, zanim stan si krytyczne.  Integrowa si! Integrowa  rzecze Najlepszy Kierownik Projektu. 2 Numery obszarów wiedzy s zwizane z numerami rozdziaBów w oficjalnych podrcznikach PMBoK. 34 Cz[ I f& Metodyki zarzdcze a praktyka Obszar wiedzy Zakres (rozdziaB 5.) Ten obszar wiedzy skupia si na zarzdzaniu 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 Bczy w sobie tematy, którymi zajmuj si procesy Zarz- dzanie Zakresem Etapu (ZE) i Zarzdzanie Wytwarzaniem Produktów (WP) w Prince2. In|ynierowie z firmy produkujcej auta otrzymali plany nowego, eksportowego modelu auta i w trakcie analizy zauwa|yli wymóg konieczno[ci zamontowania tylnych szyb odpornych na prdko[ 50 km/h! 50 km/h? Przecie| na biegu wstecznym auto nigdy nie osignie takiej prdko[ci! Zgodnie stwierdzono wic, |e w celu redukcji kosztów zamon- towane zostan inne szyby o gorszych parametrach. In|ynierowie pracowali w pocie czoBa przez wiele dBugich miesicy i to niejeden raz po godzinach. Jak ka|dy projekt, ten te| miaB swoje dobre i zBe chwile, ale w koDcu udaBo si skonstruowa pierwszy prototyp, który pomy[lnie przeszedB pierwsz seri testów terenowych. Podjto decyzj o uruchomieniu produkcji i wyprodukowano pierwsz setk piknych, czerwonych, l[nicych nowych aut; chBopcy pana Stefana przez caBy dzieD pole- rowali je na parkingu firmowym. Z powodzeniem zamknito projekt i wypBacono premie, a po tygodniu zadzwoniB telefon z zagranicy&  Co wy[cie zrobili!!!!  Nowe auta.  Wszystkie tylnie szyby powybijane! Co my teraz mamy zrobi?  Jak to powybijane!?  WBa[nie [cignli[my je z lawety kolejowej! Bdziemy musieli jako[ zaBatwi t spraw u nas, lokalnie& klienci czekaj&  Zaraz, zaraz& Transport kolejowy!?  Tak! Przecie| pisali[my, |e tylnie szyby maj wytrzymywa szybko[ 50km/h.  No wBa[nie. Po co?  Po co ???!!! Przecie| te auta s ustawiane na wagonach tyln szyb do przodu!!! WystarczyBo TYLKO wykona to, co zapisali[my! Hrrrr& RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 35 Obszar wiedzy Czas (rozdziaB 6.) Ten obszar wiedzy to wszystkie dziaBania zwizane z wykonaniem projektu w zaBo|onym terminie, o ile zmianie nie ulegBy przyjte zaBo|enia oraz zakres. SzczegóBowo przyjmuje on prost sekwencj zdarzeD: zdefiniowanie zbioru planowanych dziaBaD  6.1, ustanowienie wzajemnych zale|no[ci czasowych pomidzy tymi dziaBaniami (co musi by zrobione najpierw, a co potem, jakie dziaBania mog by wykonywane równocze[nie)  6.2, oszacowanie potrzeb zasobowych i czasu trwania poszczególnych dziaBaD  6.3, 6.4, stworzenie harmonogramu projektu oraz jego kontrola  6.5, 6.6. Wszystkie te procesy z wyjtkiem ostatniego nale| do grupy procesów planistycznych. Obszar wiedzy Koszt (rozdziaB 7.) Projekt informatyczny jest inwestycj, czyli kosztami, które w dBu|szej perspektywie maj przynie[ organizacji zysk. Aby projekt zakoDczyB si powodzeniem, konieczne jest wBa[ciwie zarzdzanie bud|etem, czyli: szacowanie  7.1, zaplanowanie (stworzenie bazowej wersji bud|etu)  7.2, kontrola  7.3. Wszystkie te procesy z wyjtkiem ostatniego nale| do grupy procesów planistycznych. Obszar wiedzy Jako[ (rozdziaB 8.) PMBoK proponuje nastpujce procesy w celu zapewnienia wBa[ciwego zarzdzania 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 (rozdziaB 9.) Ten obszar wiedzy opisuje szereg dobrych praktyk zwizanych z zarzdzaniem ludzmi postrzeganymi jako pojedyncze osoby i zespoBy. Oznacza to: 36 Cz[ I f& Metodyki zarzdcze a praktyka zaplanowanie potrzeb zasobowych  9.1, procesy tworzenia zespoBów ludzkich, ich rozwój i zarzdzanie nimi  9.2, 9.3, 9.4. Rekrutacja wBa[ciwych osób to jeden z najwa|niejszych i najtrudniejszych procesów w trakcie przygotowania do uruchamiania projektu. Jednym z ciekawszych artykuBów na ten temat jest przetBumaczony na jzyk polski Partyzancki poradnik rekrutacji Joela Spolsky ego3. Jego gBównym przesBaniem jest rada, by rekrutowa tylko i wyBcznie osoby bystre i realizujce cele. Przy okazji  tematyki kadrowej warto równie| nadmieni o niezwizanym z PMBoK  procesie efektywno[ci zespoBowej Kena Blancharda, który opisuje cztery poziomy goto- wo[ci pracowników. R1  pracownik o niskich kompetencjach, który na swoim koncie nie ma wikszych sukcesów i dlatego nie jest zmotywowany do pracy. R2  pracownik o niskich kompetencjach, który nie mo|e samodzielnie wykonywa zadaD, 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 wBasne siBy lub znudzenia. R4  pracownik o wysokich kompetencjach i chciach, który potrafi i chce samodzielnie wykonywa zadania. Ken Blanchard opisuje równie| cztery style przywództwa (rysunek 4). S1  instruowanie to  suche przekazanie maBych, czstkowych zadaD do wykonania i rozliczenie z ich wykonania. S2  konsultowanie to równie| przekazanie zadaD, ale skoncentrowane na utrzymaniu wysokiej motywacji pracownika. S3  wspieranie koncentruje si na wBa[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 podjcia odpowiedzialno[ci. Technika przywództwa sytuacyjnego koncentruje si na wBa[ciwym dopasowaniu poziomu gotowo[ci do stylu przywództwa, poniewa| nie mo|na jednej miary przykBada do wszyst- kich osób. Jak Batwo si domy[li, delegowanie zBo|onych zadaD pracownikom o niskich 3 http://polish.joelonsoftware.com/Articles/Interviewing.html RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 37 Rysunek 4. Model przywództwa zespoBowego Kena Blancharda yródBo: Blanchard International Polska - http://www.blanchard.pl kompetencjach doprowadzi do katastrofy, a szczegóBowe instruowanie do[wiadczonych pracowników demotywuje ich do pracy. Model ten koncentruje si równie| na rozwoju ka|dego pracownika i zwikszeniu jego poziomu gotowo[ci. Obszar wiedzy Komunikacja (rozdziaB 10.) Ten obszar wiedzy koncentruje si na zapewnieniu wBa[ciwej komunikacji z interesariu- szami projektu. SzczegóBowo oznacza to: identyfikacj kluczowych interesariuszy w trakcie inicjacji projektu  10.2, stworzenie planu komunikacji z interesariuszami projektu  10.2, 38 Cz[ I f& Metodyki zarzdcze a praktyka wBa[ciw dystrybucj informacji i zarzdzanie 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 wBa[ciwych systemów informatycznych. Bardzo wskazane jest posiadanie komplekso- wego rozwizania intranetowego, które umo|liwi wspóBdzielenie wiedzy projektowej wewntrz firmy (ang. Enterprise Project Management). Ka|da z firm wybiera system wedBug wBasnych potrzeb, a popularno[ poszczególnych rozwizaD jest do[ rozproszona, co zobrazowano na rysunku 5. Rysunek 5. Wynik ankiety  Jakich systemów EPM u|ywasz? Pierra-Jeana Cherreta4 Inn ciekaw alternatyw dla rozwizaD tego typu jest firmowe wiki rozwijane na bazie rozwizaD darmowych, takich jak MediaWiki, na której bazuje Wikipedia, lub rozwizaD odpBatnych, np. Confluence. W rozproszonych zespoBach warto dodatkowo zainwestowa w narzdzia wspóBpracy zdalnej (ang. collaboration tools), takie jak WebEx5, GoToMeeting, MS Office Live Meeting (poprzednio PlaceWare) lub Adobe Connect (poprzednio Breeze). Obszar wiedzy Ryzyko (rozdziaB 11.) W tym obszarze zarzdzanie ryzykiem projektowym odbywa si przy u|yciu rejestru ryzyk. DziaBania te polegaj na: 4 Na podstawie ankiety  Jakich systemów EPM u|ywasz? uruchomionej przez Pierra-Jeana Cherreta w serwisie spoBeczno[ciowym Plaxo. 5 O skali tego rynku niech [wiadczy zakup, jakiego dokonaBo Cisco 15 marca 2007 roku, które za  drobne 3,2 miliarda dolarów przejBo firm WebEx. RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 39 stworzeniu planu zarzdzania ryzykiem  11.1, identyfikacji, analizie i planowaniu odpowiedzi na ryzyka  11.2, 11.3, 11.4, 11.5, monitorowaniu i kontrolowaniu ryzyk projektowych  11.6. Wszystkie te procesy z wyjtkiem ostatniego nale| do grupy procesów planistycznych. Obszar wiedzy Dostawa (rozdziaB 12.) Dostawa to zakup lub zdobycie produktów i usBug spoza zespoBu 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 rumuDskich w Sta- lingradzie:  Ci biedacy tkwili w [niegu z bardzo marnym wyposa|eniem, niektórzy bez koców, ze starymi karabinami, które przypominaBy czasy Napoleona. Zaopatrzenie u nich byBo bardzo zBe, ale na tyBach oficerowie rozpierali si przy nakrytych biaBymi obrusami stoBach, pili wino i nie odmawiali sobie niczego. Na miejscu tych rumuDskich |oBnierzy te| nie miaBbym ochoty z entuzjazmem stawa do walki za Hitlera i po[wica wBasne |ycie 6. Procesy i techniki Ka|dy z procesów, oprócz przynale|no[ci do obszaru wiedzy, nale|y do jednej z 5 gBów- nych grup procesów. Wzajemna zale|no[ tych grup jest stosunkowo prosta (rysunek 6). Jeden projekt mo|e skBada si z wielu etapów7 i ka|dy z nich bdzie zarzdzany przez PMBoK oddzielnie. W szczególnym przypadku, gdy dwa etapy zachodz na siebie, 6 G. Knopp, Stalingrad, Zwiat Ksi|ki, Warszawa 2007, s.150. 7 Formalnie, w nomenklaturze PMBoK  etap nazywa si  faz . 40 Cz[ I f& Metodyki zarzdcze 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 zamknicia, a równocze[nie faza druga jest w okresie inicjacji (rysunek 7). POPRZEDNIE ETAPY ETAP I  PROTOTYP ROZWIAZANIA PROCESY PROCESY INICJACJI PLANISTYCZNE ETAP II  KOMERCYJNE ROZWIZANIE PROCESY PROCESY KONTROLI REALIZACJI PROCESY PROCESY INICJACJI PLANISTYCZNE PROCESY ZAMKNICIA PROCESY PROCESY KOLEJNE KONTROLI REALIZACJI ETAPY PROCESY ZAMKNICIA Rysunek 7. WspóBbie|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 zostaB opis wszystkich grup procesów, ogólny opis ka|dego procesu oraz najbardziej interesujce techniki. ZaBcznik A  Lista wszystkich procesów PMBoK  zawiera szczegóBowy opis wszystkich procesów. Procesy inicjacji wedBug PMBoK to wszelkie operacje zwizane z uruchomieniem projektu. RozdziaB 2. f& 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 polegajca na zasigniciu osdu 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 wpByw na projekt. Tworzony jest rejestr tych osób i organizacji oraz wykorzystywana technika analizy interesariuszy pod ktem najlepszego szablonu komunikacji. Istniej cztery takie szablony: utrzymanie satysfakcji (ang. Keep Satisfied)  dedykowany osobom o wysokim wpBywie, ale niskim zainteresowaniu, bliska wspóBpraca (ang. Manage Closely)  dedykowany osobom o wysokim wpBywie i wysokim zainteresowaniu, staBe informowanie (ang. Keep Informed)  dedykowany osobom o niskim wpBywie i wysokim zainteresowaniu, monitorowanie (ang. Monitor)  dedykowany osobom o niskim wpBywie i niskim zainteresowaniu. Jest to proces analogiczny do procesu uruchamiania projektu (Przygotowanie ZaBo|eD Projektu (PP)) z metodyki Prince2. Procesy planistyczne wedBug PMBoK to uszczegóBowienie zaakceptowanych ram pro- jektowych i szereg taktycznych odpowiedzi na temat sposobu realizacji zadaD, którego wynikiem jest kompletny, szczegóBowy plan prac. W skBad tej grupy procesów wchodz procesy z ró|nych obszarów wiedzy. 4.2. Opracowanie planu zarzdzania projektem  gBówny proces planistyczny, w ramach którego kierownik projektu uruchamia i zamyka wszystkie pozostaBe procesy z tej grupy. 5.1. Zbieranie wymagaD  udokumentowanie wymagaD 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 zadaD 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 sprztu) niezbdnych do realizacji projektu. 42 Cz[ I f& Metodyki zarzdcze a praktyka 6.4. Szacowanie czasu trwania czynno[ci  dBugo[ trwania poszczególnych zadaD. 6.5. Opracowanie harmonogramu  proces, który zamyka dziaBania wykonane w procesach od 6.1 do 6.4 i daje w rezultacie bazowy harmonogram projektu. 7.1. Szacowanie kosztów  dane finansowe sBu|ce do oceny kosztu caBego 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 zakoDczeniem prac nad harmonogramem (6.5). 8.1. Planowanie jako[ci  przygotowanie planu zarzdzania jako[ci wytwarzanych przez projekt produktów i samego sposobu realizacji projektu. 9.1. Planowanie zasobów ludzkich  zdefiniowanie odpowiedzialno[ci poszczególnych czBonków zespoBu oraz ustalenie, kto, do kogo i kiedy raportuje w obrbie zespoBu projektowego. 10.2. Planowanie komunikacji  zdefiniowanie mechanizmów przekazywania informacji pomidzy kierownikiem projektu a interesariuszami. 11.1. Planowanie zarzdzania ryzykiem  zdefiniowanie procedur zarzdzania ryzykiem. 11.2. Identyfikacja ryzyka  okre[lenie wej[ciowej listy ryzyk, które zostaBy wykryte przez zespóB projektowy lub osoby spoza tego zespoBu. 11.3. Jako[ciowa analiza ryzyka  analiza merytoryczna poszczególnych ryzyk. 11.4. Ilo[ciowa analiza ryzyka  przeBo|enie wiedzy na temat ryzyka na warto[ci liczbowe w takich obszarach jak prawdopodobieDstwo wystpowania lub wpByw na projekt. 11.5. Planowanie reakcji na ryzyko  podejmowanie decyzji zwizanych z ryzykami. 12.1. Planowanie zaopatrzenia  co, kiedy i jak powinno zosta zakupione lub uzyskane, wBcznie z podjciem decyzji typu  zrobi, czy kupi . Procesy planistyczne z PMBoK zawieraj w sobie mechanizmy analogiczne do pro- cesów planowania (PL), inicjowania projektu (IP) i zarzdzania zakresem etapu (ZE) z metodyki Prince2, ale w obszarach zwizanych z zarzdzaniem zasobami ludzkimi oraz zaopatrzeniem PMBoK wyraznie wykracza poza ramy Prince2. Ka|dy z wymienionych powy|ej procesów zawiera pewn grup sugerowanych technik. Wszystkie s wyliczone w zaBczniku A, ale cz[ z nich jest szczególnie interesujca& . Techniki zwizane z procesem 6.2. Szeregowanie czynno[ci Metoda Diagramów Nastpstw (ang. Precedence Diagramming Method) opisuje najbardziej popularny sposób wizania ze sob czynno[ci w takich pakietach jak MS Project. Definiuje czynno[ci jako wzBy, które s ze sob poBczone strzaBkami. Relacja pomidzy zadaniami mo|e by nastpujca. RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 43 Koniec-do-Pocztku: poprzednik musi zakoDczy si, zanim zacznie si nastpnik (naj- cz[ciej wykorzystywany mechanizm Bczenia zadaD). PrzykBad  proces sdowy musi dobiec koDca, zanim zacznie si wykonanie wyroku (rysunek 8). Rysunek 8. Relacja pomidzy zadaniami Koniec- do-Pocztku Oto inne, rzadziej stosowane typy relacji. Koniec-do-KoDca: poprzednik musi zakoDczy si, zanim skoDczy si nastpnik (bardzo rzadko wykorzystywany mechanizm). PrzykBad  proces sdowy musi si skoDczy, zanim skoDczy si tymczasowe zatrzymanie (rysunek 9). Rysunek 9. Relacja pomidzy zadaniami Koniec-do-KoDca Pocztek-do-Pocztku: poprzednik musi si rozpocz, zanim zacznie si nastpnik (bardzo rzadko wykorzystywany mechanizm). PrzykBad  dziaBalno[ przestpcza musi si rozpocz, zanim zacznie si proces sdowy (rysunek 10). Rysunek 10. Relacja pomidzy zadaniami Pocztek-do-Pocztku Pocztek-do-KoDca: poprzednik musi si zacz, zanim nastpnik si zakoDczy (bardzo rzadko wykorzystywany mechanizm). PrzykBad  proces sdowy musi si zacz, zanim nastpi przedawnienie (rysunek 11). 44 Cz[ I f& Metodyki zarzdcze a praktyka Rysunek 11. Relacja pomidzy zadaniami Pocztek-do-KoDca W praktyce zale|no[ci pomidzy 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[ wizania ze sob zadaD, najcz[ciej sto- suje si relacje typu Koniec-do-Pocztku, czyli w kolumnie Poprzednik zaznacza si konkretne zadania. Technika analizy zale|no[ci (ang. Dependency Determination) wyja[nia charakter zale|no[ci pomidzy czynno[ciami. I tak mamy: zale|no[ci wymagane  zwizane z natur pracy do wykonania, zale|no[ci rozwa|ne  zwizane z tradycj, najlepszymi praktykami, czyli logiczne, zale|no[ci zewntrzne  zwizane ze stanami lub produktami, które musz zosta osignite, dostarczone poza projektem. Zale|no[ci te powinny by elementem rejestru ryzyk. Technika przyspieszeD i opóznieD (ang. Applying Leads and Lags) wi|e dwie czynno[ci na zasadzie  Rozpocz zadanie B na X jednostek czasu, zanim zakoDczy si zadanie A (przyspieszenie) lub  Zadanie B mo|e si rozpocz na X jednostek czasu po zakoDczeniu zadania A (opóznienie). MS Project posiada tego typu funkcjonalno[; jest to parametr o nazwie  ZwBoka przy definiowaniu poprzedników zadania. Na rysunku 12. przedstawione jest zadanie B, które ma zacz si na jeden dzieD przed zakoDczeniem zadania A. Parametr  ZwBoka w MS Project mo|e przybiera warto[ dodatni (opóznienie) 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 pitra wie|owca. RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 45 Rysunek 12. Przyspieszenia i opóznienia zadaD w MS Project Techniki zwizane z procesem 3.5. Opracowanie harmonogramu Oprócz standardowych rozwizaD, takich jak wykres Gantta, PMBoK opisuje nastpu- jce techniki. Analiza sieciowa harmonogramu zawiera wszystkie techniki zwizane z tworzeniem harmonogramu projektu, takie jak metoda [cie|ki krytycznej, metoda BaDcucha krytycznego, analiza  co je[li i równowa|enie zasobów. GBównym celem jest oszacowanie wcze[niejszych oraz pózniejszych dat rozpoczcia i zakoDczenia czynno[ci projektowych. Metoda [cie|ki krytycznej (ang. Critical path method) dla ka|dej czynno[ci szacuje optymistyczn (wcze[niejsz) i pesymistyczn (pózniejsz) dat rozpoczcia i zakoDczenia. Szacunki te wykonane s bez uwzgldnienia ograniczeD zasobowych. Nastpnie analizowane s wzajemne zale|no[ci midzy 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 zadaD 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 BaDcucha krytycznego (ang. Critical chain method) przyjmuje za punkt wyj[cia zdefiniowane [cie|ki krytyczne. UzupeBnia plany o ograniczenia zasobowe i tak zmodyfikowane [cie|ki krytyczne uzyskuj miano BaDcucha krytycznego. W ramach tego procesu na koDcu caBego projektu dodawane s dodatkowe bufory czasu (ang. the project buffer), które maj zabezpieczy projekt przed przekroczeniem terminów koDcowych. Dodatkowo do BaDcuchów zadaD o najwikszej niepewno[ci dodawane s równie| dodatkowe bufory czasu (ang. the feeding buffer). Wykorzystujc t metod, nale|y w trakcie realizacji projektu koncentrowa si na wBa[ciwym stosowaniu buforów. Równowa|enie zasobów (ang. Resource leveling) to technika, która zakBada du|e ograniczenie w dostpno[ci do zasobów. PrzykBadowo przy u|yciu tego samego zasobu mo|e realizowa równocze[nie dwa ró|ne projekty, okre[lona pula zasobów mo|e by dostpna tylko pomidzy konkretnymi datami na okre[lon dBugo[. Tego typu ograniczenia mog powodowa znaczce zmiany w harmonogramie. Je|eli np. okazuje si, |e mamy osiem osób do dBugoterminowej dyspozycji, a wykres zaanga|owania wyglda tak jak 46 Cz[ I f& Metodyki zarzdcze a praktyka Prawo Parkinsona8 mówi, |e praca zawsze rozrasta si w taki sposób, aby zapeBni caBy zaplanowany na ni czas. W zwizku 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 koDcu projektu poza konkretnymi zadaniami jako swoist rezerw strategiczn. Warto równie| motywowa zespóB 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 wydBu|enie realizacji pewnych zadaD. Wymagania nadmiarowe Ilo[ zasobów 11 10 9 Poziom dostpnych 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 wzgldem harmonogramu i próbuje uzyska jak najwiksz kompresj zadaD 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). RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 47 najni|sz cen. PrzykBadowe sposoby stosowania tej techniki to nadgodziny, dodatkowe zasoby lub premie za realizacj zadaD na [cie|ce krytycznej. Technika ta nie zawsze tworzy rzeczywist alternatyw i mo|e powodowa zwikszone ryzyko projektowe. Szybkie [ledzenie (ang. Fast tracking) to caBkowite lub cz[ciowe zrównoleglenie czynno[ci, które normalnie byByby wykonywane sekwencyjne. Zrównoleglenie czynno[ci powoduje konieczno[ ich koDcowej integracji. Jest to pewien dodatkowy koszt i ryzyko, które nale|y wzi pod uwag przy okazji podejmowania tego typu decyzji. Oprogramowanie do zarzdzania projektami (np. MS Project). Techniki wspierajce podejmowanie decyzji, stosowane m.in. w procesach 5.1. Zbieranie wymagaD i 8.1. Planowanie jako[ci  Burza mózgów (ang. Brainstorming) to swobodna dyskusja caBego zespoBu na kluczowe tematy projektowe, gdzie ka|dy ma równe prawo gBosu i gBow otwart na nieszablonowe pomysBy. W trakcie tych sesji nie ma  gBupich pomysBów . Rano po kawie, gdy umysB [wie|y, zabieramy czBonkinie i czBonków zespoBu do salki konferencyjnej lub na spacer. Otwieramy tabliczk czekolady, paczk z pczkami lub kBadziemy na stóB bilety do teatru i pytamy, jak rozwiza problem komiwoja|era, choby i w najbardziej oryginalny sposób& Pozostaje jedynie pobudza umysBy do twórczej dyskusji, ruga osoby, które dyskwalifikuj cudze idee, i sumiennie notowa najlepsze pomysBy. 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 rozwizania. Po spisaniu pomysBów ka|da osoba przedstawia swoje rozwizanie reszcie zespoBu, a nastpnie wszyscy dyskutuj ze sob, wyja[niajc i rozwijajc warianty. Ostatecznie decyzja jest podejmowana w demokratycznym gBosowaniu9. Technika delficka (ang. The Delphi Technique)  grupa ekspertów odpowiada na ankiety i udostpnia informacj zwrotn, która umo|liwia doprecyzowanie problemu. W nastpnej rundzie eksperci otrzymuj kolejn propozycj rozwizania problemu wraz z list anonimowych uwag i uzasadnieD. Eksperci udzielaj wtedy kolejnej serii odpowiedzi. Tego typu technika mo|e zosta zastosowana do rozwizania kluczowych problemów biznesowych lub projektowych. 9 http://www.joe.org/joe/2007february/iw1.shtml 48 Cz[ I f& Metodyki zarzdcze a praktyka Wujek Dobra Rada  odcinek 3.  W zespole siBa CO DWIE GAOWY, TO NIE JEDNA  DEMOKRATYCZNY SPOSÓB PODEJMOWANIA DECYZJI ZWIKSZA ZAANGA{OWANIE CZAONKÓW ZESPOAU I ICH MOTYWACJ Mapa pomysBów (ang. Idea/mind mapping) to technika podobna do diagramów pokrewieDstwa, która polega na umieszczeniu wszystkich pomysBów na jednej mapie, po to aby odnalez ich wzajemne ró|nice i cz[ci wspólne. Diagramy pokrewieDstwa (ang. Affinity diagram)  metoda wymy[lona w latach 60. ubiegBego wieku przez japoDskiego antropologa Jiro Kawakit. Jest to tablica, na której za pomoc |óBtych karteczek wypisujemy wszystkie kwestie, grupujemy je, okre[lamy midzy nimi relacje, nadajemy im priorytety i czynimy stosowne ustalenia na przyszBo[, tak jak zaprezentowano na rysunku 14. Analiza pola siBy (ang. force field analysis) to analiza siB dziaBajcych na projekt, szczególnie u|yteczna przy podejmowaniu kluczowych decyzji; jest to specjalizowana metoda analizy  za i przeciw . Bazujc na konkretnym projekcie, planie czy rozwizaniu, nale|y okre[li siBy dziaBajce na jego korzy[ i niekorzy[ oraz zdefiniowa ocen ka|dej z siB (rysunek 15). Za pomoc takiego podej[cia mo|na podj bardziej trafn decyzj i zdefiniowa, jakie siBy nale|y wzmocni, a jakie osBabi. Diagram relacji (ang. interrelationship diagram) to diagram relacji przyczynowo-skutkowych. Nale|y sformuBowa problem oraz kwestie z nim zwizane, a nastpnie zdefiniowa zwizek przyczyna-skutek pomidzy kwestiami RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 49 Wspólne ustalenie tematu Zapisanie i zrozumienie faktów Pogrupowanie podobnych faktów ZatytuBowanie grup faktów UBo|enie grup i pokazanie wzajemnych relacji GBosowanie nad najistotniejsz kwesti wy|szego poziomu i konkluzja Rysunek 14. PrzykBad powstania diagramu pokrewieDstwa i zaprezentowa go, rysujc strzaBki. W przypadku relacji sBabej strzaBka powinna by przerywana, a w przypadku relacji silnej  cigBa. Du|a liczba strzaBek wychodzcych wskazuje gBówn przyczyn problemu10 (rysunek 16). 10 http://web2.concordia.ca/Quality/tools/17interdiagram.pdf 50 Cz[ I f& Metodyki zarzdcze a praktyka Rysunek 15. PrzykBad analizy pola siBy Rysunek 16. PrzykBad diagramu relacji: Dlaczego nie wykorzystujemy procesów rozwizywanie problemów? RozdziaB 2. f& Project Management Body of Knowledge  PMBoK 51 Diagramy macierzowe (ang. matrix diagrams)  porównywanie dwóch lub wicej grup pomysBów, okre[lanie wzajemnych zale|no[ci i podejmowanie decyzji na bazie arkuszy Excela lub tablic  w kratk . Sposób mo|e by wykorzystywany np. do zdefiniowania diagramu encji w bazie danych (rysunek 17). Rysunek 17. PrzykBad diagramu macierzowego Diagramy przepBywów (ang. Flowcharts) to graficzna reprezentacja procesu wizualizujca czynno[ci, punkty decyzyjne oraz kolejno[ procesowania. Takie podej[cie ma uBatwi mo|liwo[ wykrycia bBdów lub przewidzenia, gdzie mog potencjalnie wystpi. Matryce priorytetyzacyjne (ang. Prioritization matrices)  na bazie arkuszy Excela lub tablic  w kratk nale|y wypisa w rzdach kryteria decyzyjne, a w kolumnach  mo|liwe opcje rozwizania problemu. W ka|de z pól wewntrz takiej tabeli trzeba wpisa siB rozwizania wzgldem ka|dego z kryteriów. Dodatkowo mo|liwe jest uwzgldnienie wagi ka|dego z kryteriów decyzyjnych. Nastpnie wystarczy wyliczy sum dla ka|dej opcji, aby wybra najlepsz z nich11. PrzykBadowe zastosowanie tej techniki zostaBo zaprezentowane w tabeli 1. Tabela 1. PrzykBad matrycy priorytetyzacyjnej B. Samodzielne A. Zakup C. Zlecenie Waga stworzenie gotowego wykonania (1  10) wBasnego rozwizania rozwizania rozwizania 1. Koszt 8 10 6 8 2. Czas wykonania 5 10 4 6 3. Wewntrzne kompetencje 4 0 10 3 Suma (maks. 170) 130 108 106 11 http://www.maqin.org/brownbag/PrioritizationMatrixNov05.pdf

Wyszukiwarka

Podobne podstrony:
Zarzadzanie projektami IT zarzit
Zarzadzanie projektami IT Wydanie III zarit3
Metodyka zarzÄ…dzanie projektami PMI
zarzadzanie projektami krok po kroku edgard demo
Zastosowanie metody PCM w zarzÄ…dzaniu projektami

więcej podobnych podstron