Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00073 006625 13598419 na godz. na dobę w sumie
Zarządzanie projektami IT. Przewodnik po metodykach - książka
Zarządzanie projektami IT. Przewodnik po metodykach - książka
Autor: Liczba stron: 360
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-1804-X Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).

Przewodnik po metodykach, które musisz poznać!

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:

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: Książka zawiera również:
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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³aœciwe zaplanowanie i doprowadzenie do koñca du¿ego projektu informatycznego nie jest rzecz¹ ³atw¹. Czêsto dzia³anie takie wymaga wspó³pracy wielu ludzi, zespo³ów, a nawet ca³ych firm, precyzyjnego okreœlenia celów i struktury produktu koñcowego, jak równie¿ œrodków i czasu niezbêdnych do realizacji projektu. W zale¿noœci od jego przeznaczenia oraz specyfiki projekt taki zmusza do wdro¿enia odpowiedniego planu dzia³ania, obejmuj¹cego wszystkie etapy, metody oraz techniki, pozwalaj¹ce doprowadziæ do satysfakcjonuj¹cego wszystkich fina³u prac. W³aœnie temu s³u¿y wybór konkretnej metodyki, zapewniaj¹cej sensowny podzia³ zadañ oraz zakresu odpowiedzialnoœci poszczególnych osób i p³ynne przechodzenie miêdzy kolejnymi etapami projektu. Przekrojowy opis takich metodyk, stosowanych w bran¿y IT, znajdziesz w³aœnie na kartach ksi¹¿ki, któr¹ trzymasz w rêkach. „Zarz¹dzanie projektami IT. Przewodnik po metodykach” to poradnik dla wszystkich tych, którzy chcieliby dowiedzieæ siê, czym ró¿ni¹ siê kompleksowe podejœcia do rozwi¹zywania konkretnych problemów i jak dobraæ metodykê odpowiedni¹ dla ich w³asnych projektów. Oprócz ogólnych wskazañ oraz starannie opracowanych opisów kolejnych etapów dzia³ania, technik czy procesów znajdziesz tu tak¿e: • przyk³adowe realizacje projektów IT wed³ug konkretnych metodyk, • praktyczne wskazówki i rady, • wywiady z osobami wykorzystuj¹cymi na co dzieñ te rozwi¹zania. Ca³oœæ urozmaicaj¹ sentencje „Wujka dobra rada”, podkreœlaj¹ce najistotniejsze aspekty prezentowanych zagadnieñ, oraz przejrzyste, czêsto humorystyczne ilustracje. Czytaj¹c tê ksi¹¿kê, poznasz: • metodyki zarz¹dcze – Prince2 oraz PMBoK4 • metodyki wytwórcze – RUP i MSF • metodyki adaptacyjne – eXtreme Programming i SCRUM • metodyki organizacyjne – CMMI, Six Sigma, ITIL lub COBIT • kilka przyk³adów sposobów ³¹czenia tych metodyk Spis treści Wstęp .............................................................................................. 7 Część I Metodyki zarządcze a praktyka ..................................... 11 Rozdział 1. PRoject IN Controlled Environment — Prince2 ................................ 13 Szczypta historii ............................................................................................................. 13 Procesy ........................................................................................................................... 14 Komponenty ................................................................................................................... 17 Techniki .......................................................................................................................... 21 Zarządzanie dokumentacją ............................................................................................. 24 Dostosowywanie do potrzeb organizacji ........................................................................ 25 Certyfikacja .................................................................................................................... 25 Podsumowanie ................................................................................................................ 26 Rozmowa z... .................................................................................................................. 27 Rozdział 2. Project Management Body of Knowledge — PMBoK ....................... 31 Szczypta historii ............................................................................................................. 31 Obszary wiedzy .............................................................................................................. 33 Procesy i techniki ........................................................................................................... 39 Dostosowanie do potrzeb organizacji ............................................................................. 66 Certyfikacja .................................................................................................................... 66 Podsumowanie ................................................................................................................ 67 Część II Metodyki wytwórcze a praktyka ................................... 69 Rozdział 3. Rational Unified Process (RUP) ...................................................... 73 Szczypta historii ............................................................................................................. 73 Proces ............................................................................................................................. 74 Dyscypliny RUP ............................................................................................................. 76 Abecadło metodyki RUP ................................................................................................ 79 Adaptacja RUP do potrzeb organizacji ........................................................................... 80 Podsumowanie RUP ....................................................................................................... 81 Rozmowa z... .................................................................................................................. 82 Przykład Prince2 i RUP — BlogSerwis .......................................................................... 85 4 Zarządzanie projektami IT. Przewodnik po metodykach Rozdział 4. Microsoft Solution Framework (MSF) ............................................ 105 Szczypta historii ........................................................................................................... 105 Proces ........................................................................................................................... 106 Model zespołu .............................................................................................................. 107 Faza Wizji ..................................................................................................................... 108 Faza Planowania ........................................................................................................... 109 Faza Konstrukcji ........................................................................................................... 112 Faza Stabilizacji ............................................................................................................ 116 Faza Wdrożenia ............................................................................................................ 120 MSF MOF ................................................................................................................. 121 Trójkąt negocjacyjny .................................................................................................... 123 Dyscypliny zarządcze ................................................................................................... 125 Certyfikacja .................................................................................................................. 126 Podsumowanie — MSF a RUP .................................................................................... 126 Rozdział 5. Przykład PMBoK i MSF — wdrożenie systemu BI ........................... 129 Część III Metodyki adaptacyjne a praktyka ............................... 177 Rozdział 6. eXtreme Programming .................................................................. 179 Szczypta historii ........................................................................................................... 179 Role .............................................................................................................................. 180 Proces ........................................................................................................................... 180 Wdrożenie .................................................................................................................... 186 Rozdział 7. Scrum .......................................................................................... 189 Szczypta historii ........................................................................................................... 190 Role .............................................................................................................................. 190 Proces ........................................................................................................................... 191 Podsumowanie .............................................................................................................. 196 Rozmowa z... ................................................................................................................ 197 Rozdział 8. Joel o oprogramowaniu ................................................................. 205 Rozdział 9. Przykład — Scrum BlogSerwis ...................................................... 209 Część IV Metodyki organizacyjne a praktyka ............................. 223 Rozdział 10. Capability Maturity Model Integration (CMMI) .............................. 225 Szczypta historii ........................................................................................................... 226 Poziomy CMMI ............................................................................................................ 228 Procesy ......................................................................................................................... 229 Podsumowanie .............................................................................................................. 235 Rozdział 11. Six Sigma .................................................................................... 239 Szczypta historii ........................................................................................................... 240 Wdrożenie .................................................................................................................... 241 Certyfikacja .................................................................................................................. 245 Podsumowanie .............................................................................................................. 245 Rozdział 12. Information Technology Infrastructure Library (ITIL) ....................... 247 Szczypta historii ........................................................................................................... 247 Role .............................................................................................................................. 249 Procesy ......................................................................................................................... 251 Wdrożenie .................................................................................................................... 254 Spis treści 5 Certyfikacja .................................................................................................................. 256 Podsumowanie .............................................................................................................. 257 Rozmowa z... ................................................................................................................ 258 Rozdział 13. Control Objectives for Information and related Technology (COBIT) 263 Szczypta historii ........................................................................................................... 264 Role .............................................................................................................................. 265 Procesy ......................................................................................................................... 266 Certyfikacja .................................................................................................................. 273 Podsumowanie .............................................................................................................. 274 Część V Rozwiązania kombinowane ......................................... 275 Podsumowanie ............................................................................. 281 Dodatki ..................................................................................... 283 Dodatek A Lista wszystkich procesów PMBoK ............................................... 285 Dodatek B Specyfikacja dyscyplin RUP z Rational Method Composer (RMC) ... 321 Dodatek C Lista wszystkich procesów ITIL ..................................................... 325 Dodatek D Lista wszystkich procesów COBIT ................................................. 331 Spis rysunków .............................................................................. 335 Spis tabel .................................................................................... 337 Źródła .......................................................................................... 339 Skorowidz .................................................................................... 343 Rozdział 2. Project Management Body of Knowledge — PMBoK Podejście PMBoK jest często przedstawiane jako „metodyka PMI”, czyli metodyka organizacji Project Management Institute zrzeszającej specjalistów z dziedziny zarzą- dzania projektami. PMBoK koncentruje się na zebraniu i przedstawieniu dobrych praktyk związanych z zarządzaniem projektami w ramach zdefiniowanych obszarów wiedzy. W pewnym sensie PMBoK jest podejściem konkurencyjnym w stosunku do Prince2 i ze względu na nieco większą swobodę implementacji jest częściej stosowany przez duże korporacje z sektora prywatnego. Dodatkowo PMBoK wkracza w obszary, których Prince2 nie obejmuje, takie jak zarządzanie zasobami ludzkimi oraz zaopatrzeniem. PMBoK w wersji czwartej definiuje pięć grup procesów, takich jak procesy rozpoczęcia, planowania, realizacji, kontroli i zakończenia. Każdy z tych procesów należy również do jednego z dziewięciu obszarów wiedzy, takich jak zarządzanie integralnością pro- jektu, zakresem, czasem, kosztami, jakością, zasobami ludzkimi, komunikacją, ryzykiem i zaopatrzeniem. Szczypta historii Organizacja PMI powstała w USA w 1969 roku jako organizacja non profit zrzeszająca profesjonalistów różnych specjalności w celu wyspecyfikowania standardowych prak- tyk zarządczych. W 1987 roku opublikowana została pierwsza edycja PMBoK, która była rezultatem prac wykonanych we wczesnych latach 80. W roku 1998 American National Standards Institute (ANSI) zaakceptował to rozwiązanie jako narodowy standard zarzą- dzania projektami, a Institute of Electrical and Electronics Engineers (IEEE) zaadaptował 32 Część I ♦ Metodyki zarządcze a praktyka to podejście jako standard 14901. 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. (cid:141) Lepsze zarządzanie interesariuszami, które pojawia się już w grupie procesów rozpoczęcia jako nowy proces o nazwie „10.1. Identyfikacja interesariuszy”. (cid:141) 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). (cid:141) 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. (cid:141) 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. (cid:141) 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). (cid:141) Uporządkowaniu uległo nazewnictwo wszystkich procesów oraz ich numeracja, która bazuje już wyłącznie na numerach rozdziałów i podrozdziałów. 1 Standard IEEE Std 1490-1998 został zaktualizowany w 2004 (!) roku do IEEE Std 1490-2003. Rozdział 2. ♦ 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 wiedzy2, 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: (cid:141) kwestie związane z uruchomieniem projektu (np. zdobycie mandatu na realizację projektu) — 4.1, (cid:141) przygotowanie planu zarządzania projektem — 4.2, (cid:141) zarządzanie bieżącymi pracami projektowymi — 4.3, (cid:141) kontrolę prac projektowych i zintegrowane zarządzanie zmianą — 4.4, 4.5, (cid:141) zamknięcie projektu — 4.6. Integracja to codzienne wybory miejsca koncentracji zasobów i wysiłku, wyprzedzenie możliwych kłopotów i zarządzanie nimi, zanim staną się krytyczne. — Integrować się! Integrować — rzecze Najlepszy Kierownik Projektu. 2 Numery obszarów wiedzy są związane z numerami rozdziałów w oficjalnych podręcznikach PMBoK. 34 Część I ♦ 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: (cid:141) definicji zakresu projektu wraz z strukturą wytwarzanych produktów (ang. Work Breakdown Structure) — 5.1, 5.2, 5.3, (cid:141) sformalizowanych mechanizmów weryfikacji i kontroli zakresu projektu — 5.4, 5.5. Ten obszar wiedzy PMBoK łączy w sobie tematy, którymi zajmują się procesy Zarzą- dzanie Zakresem Etapu (ZE) i Zarządzanie Wytwarzaniem Produktów (WP) w Prince2. Inżynierowie z firmy produkującej auta otrzymali plany nowego, eksportowego modelu auta i w trakcie analizy zauważyli wymóg konieczności zamontowania tylnych szyb odpornych na prędkość 50 km/h! 50 km/h? Przecież na biegu wstecznym auto nigdy nie osiągnie takiej prędkości! Zgodnie stwierdzono więc, że w celu redukcji kosztów zamon- towane zostaną inne szyby o gorszych parametrach. Inżynierowie pracowali w pocie czoła przez wiele długich miesięcy i to niejeden raz po godzinach. Jak każdy projekt, ten też miał swoje dobre i złe chwile, ale w końcu udało się skonstruować pierwszy prototyp, który pomyślnie przeszedł pierwszą serię testów terenowych. Podjęto decyzję o uruchomieniu produkcji i wyprodukowano pierwszą setkę pięknych, czerwonych, lśniących nowych aut; chłopcy pana Stefana przez cały dzień pole- rowali je na parkingu firmowym. Z powodzeniem zamknięto projekt i wypłacono premie, a po tygodniu zadzwonił telefon z zagranicy… — Co wyście zrobili!!!! — Nowe auta. — Wszystkie tylnie szyby powybijane! Co my teraz mamy zrobić? — Jak to powybijane!? — Właśnie ściągnęliśmy je z lawety kolejowej! Będziemy musieli jakoś załatwić tę sprawę u nas, lokalnie… klienci czekają… — Zaraz, zaraz… Transport kolejowy!? — Tak! Przecież pisaliśmy, że tylnie szyby mają wytrzymywać szybkość 50km/h. — No właśnie. Po co? — Po co ???!!! Przecież te auta są ustawiane na wagonach tylną szybą do przodu!!! Wystarczyło TYLKO wykonać to, co zapisaliśmy! Hrrrr… Rozdział 2. ♦ 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ń: (cid:141) zdefiniowanie zbioru planowanych działań — 6.1, (cid:141) 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, (cid:141) oszacowanie potrzeb zasobowych i czasu trwania poszczególnych działań — 6.3, 6.4, (cid:141) 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: (cid:141) szacowanie — 7.1, (cid:141) zaplanowanie (stworzenie bazowej wersji budżetu) — 7.2, (cid:141) 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ą: (cid:141) zaplanowanie sposobu zapewniania odpowiedniej jakości w projekcie — 8.1, (cid:141) wdrożenie tego planu poprzez systematyczne wykonanie rutynowych czynności — 8.2, (cid:141) kontrolę mechanizmów zapewnienia jakości — 8.3. Obszar wiedzy Zasoby ludzkie (rozdział 9.) Ten obszar wiedzy opisuje szereg dobrych praktyk związanych z zarządzaniem ludźmi postrzeganymi jako pojedyncze osoby i zespoły. Oznacza to: 36 Część I ♦ Metodyki zarządcze a praktyka (cid:141) zaplanowanie potrzeb zasobowych — 9.1, (cid:141) 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’ego3. 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. (cid:141) R1 — pracownik o niskich kompetencjach, który na swoim koncie nie ma większych sukcesów i dlatego nie jest zmotywowany do pracy. (cid:141) R2 — pracownik o niskich kompetencjach, który nie może samodzielnie wykonywać zadań, ale jest bardzo zmotywowany do ich wykonania. (cid:141) 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. (cid:141) 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). (cid:141) S1 — instruowanie to „suche” przekazanie małych, cząstkowych zadań do wykonania i rozliczenie z ich wykonania. (cid:141) S2 — konsultowanie to również przekazanie zadań, ale skoncentrowane na utrzymaniu wysokiej motywacji pracownika. (cid:141) S3 — wspieranie koncentruje się na właściwym zmotywowaniu pracownika, który sam wie, jakie zadania należy wykonać. (cid:141) S4 — delegowanie to styl, w którym pracownik wie, co należy zrobić, i jest zmotywowany do samodzielnego podjęcia odpowiedzialności. Technika przywództwa sytuacyjnego koncentruje się na właściwym dopasowaniu poziomu gotowości do stylu przywództwa, ponieważ nie można jednej miary przykładać do wszyst- kich osób. Jak łatwo się domyślić, delegowanie złożonych zadań pracownikom o niskich 3 http://polish.joelonsoftware.com/Articles/Interviewing.html Rozdział 2. ♦ 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: (cid:141) identyfikację kluczowych interesariuszy w trakcie inicjacji projektu — 10.2, (cid:141) stworzenie planu komunikacji z interesariuszami projektu — 10.2, 38 Część I ♦ Metodyki zarządcze a praktyka (cid:141) właściwą dystrybucję informacji i zarządzanie interesariuszami — 10.3, 10.4, (cid:141) 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 Cherreta4 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 WebEx5, GoToMeeting, MS Office Live Meeting (poprzednio PlaceWare) lub Adobe Connect (poprzednio Breeze). Obszar wiedzy Ryzyko (rozdział 11.) W tym obszarze zarządzanie ryzykiem projektowym odbywa się przy użyciu rejestru ryzyk. Działania te polegają na: 4 Na podstawie ankiety „Jakich systemów EPM używasz?” uruchomionej przez Pierra-Jeana Cherreta w serwisie społecznościowym Plaxo. 5 O skali tego rynku niech świadczy zakup, jakiego dokonało Cisco 15 marca 2007 roku, które za „drobne” 3,2 miliarda dolarów przejęło firmę WebEx. Rozdział 2. ♦ Project Management Body of Knowledge — PMBoK 39 (cid:141) stworzeniu planu zarządzania ryzykiem — 11.1, (cid:141) identyfikacji, analizie i planowaniu odpowiedzi na ryzyka — 11.2, 11.3, 11.4, 11.5, (cid:141) 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: (cid:141) planowanie dostaw — 12.1, (cid:141) realizacja dostaw — 12.2, (cid:141) kontrola sposobu i stopnia realizacji dostaw — 12.3, (cid:141) 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ów7 i każdy z nich będzie zarządzany przez PMBoK oddzielnie. W szczególnym przypadku, gdy dwa etapy zachodzą na siebie, 6 G. Knopp, Stalingrad, Świat Książki, Warszawa 2007, s.150. 7 Formalnie, w nomenklaturze PMBoK „etap” nazywa się „fazą”. 40 Rysunek 6. Architektura grup procesów PMBoK Część I ♦ Metodyki zarządcze a praktyka 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). POPRZEDNIE ETAPY ETAP I – PROTOTYP ROZWIAZANIA PROCESY INICJACJI PROCESY PLANISTYCZNE PROCESY KONTROLI PROCESY REALIZACJI ETAP II – KOMERCYJNE ROZWIĄZANIE PROCESY INICJACJI PROCESY PLANISTYCZNE PROCESY ZAMKNIĘCIA PROCESY KONTROLI PROCESY REALIZACJI KOLEJNE ETAPY PROCESY ZAMKNIĘCIA Rysunek 7. Współbieżność grup procesów PMBoK W Prince2 etapy powinny być wykonywane sekwencyjnie. Można zastosować analo- giczne podejście, ale taki wariant nie jest opisywany przez oficjalną dokumentację APM Group. Poniżej zawarty został opis wszystkich grup procesów, ogólny opis każdego procesu oraz najbardziej interesujące techniki. Załącznik A — Lista wszystkich procesów PMBoK — zawiera szczegółowy opis wszystkich procesów. Procesy inicjacji według PMBoK to wszelkie operacje związane z uruchomieniem projektu. Rozdział 2. ♦ Project Management Body of Knowledge — PMBoK 41 (cid:141) 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ą. (cid:141) 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: (cid:141) utrzymanie satysfakcji (ang. Keep Satisfied) — dedykowany osobom o wysokim wpływie, ale niskim zainteresowaniu, (cid:141) bliska współpraca (ang. Manage Closely) — dedykowany osobom o wysokim wpływie i wysokim zainteresowaniu, (cid:141) stałe informowanie (ang. Keep Informed) — dedykowany osobom o niskim wpływie i wysokim zainteresowaniu, (cid:141) 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. (cid:141) 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. (cid:141) 5.1. Zbieranie wymagań — udokumentowanie wymagań interesariuszy w kontekście realizacji celów projektowych. (cid:141) 5.2. Definiowanie zakresu projektu — ustalenie, co projekt ma zrealizować. (cid:141) 5.3. Utworzenie struktury pakietów roboczych, WBS (ang. Work Breakdown Structure) — definicja struktury pakietów roboczych, analogicznie do sposobu zaprezentowanego w Prince2. (cid:141) 6.1. Zdefiniowanie czynności — przejście od pakietów roboczych do listy zadań do wykonania (czynności). (cid:141) 6.2. Szeregowanie czynności — zazwyczaj pewne zadania muszą być wykonane w pewnej konkretnej kolejności. Rezultatem tego procesu jest pierwsza wersja harmonogramu. (cid:141) 6.3. Szacowanie zasobów czynności — zarezerwowanie odpowiednich zasobów (osób i sprzętu) niezbędnych do realizacji projektu. 42 Część I ♦ Metodyki zarządcze a praktyka (cid:141) 6.4. Szacowanie czasu trwania czynności — długość trwania poszczególnych zadań. (cid:141) 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. (cid:141) 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). (cid:141) 7.2. Zatwierdzenie budżetu — bazowy plan kosztów jest wdrażany równolegle z zakończeniem prac nad harmonogramem (6.5). (cid:141) 8.1. Planowanie jakości — przygotowanie planu zarządzania jakością wytwarzanych przez projekt produktów i samego sposobu realizacji projektu. (cid:141) 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. (cid:141) 10.2. Planowanie komunikacji — zdefiniowanie mechanizmów przekazywania informacji pomiędzy kierownikiem projektu a interesariuszami. (cid:141) 11.1. Planowanie zarządzania ryzykiem — zdefiniowanie procedur zarządzania ryzykiem. (cid:141) 11.2. Identyfikacja ryzyka — określenie wejściowej listy ryzyk, które zostały wykryte przez zespół projektowy lub osoby spoza tego zespołu. (cid:141) 11.3. Jakościowa analiza ryzyka — analiza merytoryczna poszczególnych ryzyk. (cid:141) 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. (cid:141) 11.5. Planowanie reakcji na ryzyko — podejmowanie decyzji związanych z ryzykami. (cid:141) 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 (cid:141) Metoda Diagramów Następstw (ang. Precedence Diagramming Method) opisuje najbardziej popularny sposób wiązania ze sobą czynności w takich pakietach jak MS Project. Definiuje czynności jako węzły, które są ze sobą połączone strzałkami. Relacja pomiędzy zadaniami może być następująca. Rozdział 2. ♦ Project Management Body of Knowledge — PMBoK 43 Koniec-do-Początku: poprzednik musi zakończyć się, zanim zacznie się następnik (naj- częściej wykorzystywany mechanizm łączenia zadań). Przykład — proces sądowy musi dobiec końca, zanim zacznie się wykonanie wyroku (rysunek 8). Rysunek 8. Relacja pomiędzy zadaniami Koniec- do-Początku Oto inne, rzadziej stosowane typy relacji. Koniec-do-Końca: poprzednik musi zakończyć się, zanim skończy się następnik (bardzo rzadko wykorzystywany mechanizm). Przykład — proces sądowy musi się skończyć, zanim skończy się tymczasowe zatrzymanie (rysunek 9). Rysunek 9. Relacja pomiędzy zadaniami Koniec-do-Końca Początek-do-Początku: poprzednik musi się rozpocząć, zanim zacznie się następnik (bardzo rzadko wykorzystywany mechanizm). Przykład — działalność przestępcza musi się rozpocząć, zanim zacznie się proces sądowy (rysunek 10). Rysunek 10. Relacja pomiędzy zadaniami Początek-do-Początku Początek-do-Końca: poprzednik musi się zacząć, zanim następnik się zakończy (bardzo rzadko wykorzystywany mechanizm). Przykład — proces sądowy musi się zacząć, zanim nastąpi przedawnienie (rysunek 11). 44 Rysunek 11. Relacja pomiędzy zadaniami Początek-do-Końca Część I ♦ Metodyki zarządcze a praktyka 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. (cid:141) Technika analizy zależności (ang. Dependency Determination) wyjaśnia charakter zależności pomiędzy czynnościami. I tak mamy: (cid:141) zależności wymagane — związane z naturą pracy do wykonania, (cid:141) zależności rozważne — związane z tradycją, najlepszymi praktykami, czyli logiczne, (cid:141) 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. (cid:141) 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). (cid:141) Szablony harmonogramu sieciowego (ang. Schedule Network Templates) — są to szablony harmonogramów wykorzystywane wtedy, kiedy w ramach projektu mają zostać dostarczone identyczne lub bardzo podobne produkty, takie jak piętra wieżowca. Rozdział 2. ♦ 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. (cid:141) 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. (cid:141) 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. (cid:141) 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. (cid:141) Równoważenie zasobów (ang. Resource leveling) to technika, która zakłada duże ograniczenie w dostępności do zasobów. Przykładowo przy użyciu tego samego zasobu może realizować równocześnie dwa różne projekty, określona pula zasobów może być dostępna tylko pomiędzy konkretnymi datami na określoną długość. Tego typu ograniczenia mogą powodować znaczące zmiany w harmonogramie. Jeżeli np. okazuje się, że mamy osiem osób do długoterminowej dyspozycji, a wykres zaangażowania wygląda tak jak 46 Część I ♦ Metodyki zarządcze a praktyka Prawo Parkinsona8 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ń. Ilość zasobów Wymagania nadmiarowe Poziom dostępnych zasobów 11 10 9 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 (cid:141) Analiza scenariuszy „co, jeśli” — w przypadku kilku wariantów realizacji projektu analizowane są konsekwencje każdego z nich. (cid:141) Kompresja harmonogramu to metoda skracania ścieżki krytycznej bez zmiany zakresu projektu. Wykorzystuje się do tego poniższe techniki. (cid:141) Kruszenie (ang. crashing) to technika, która analizuje koszty względem harmonogramu i próbuje uzyskać jak największą kompresję zadań za jak 8 Praca rozszerza się wprost proporcjonalnie do czasu wyznaczonego do jej wykonania (oryg. ang.: Work expands as to fill the time available for its completion). Rozdział 2. ♦ 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. (cid:141) 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. (cid:141) 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 (cid:141) „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. (cid:141) 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łosowaniu9. (cid:141) Technika delficka (ang. The Delphi Technique) — grupa ekspertów odpowiada na ankiety i udostępnia informację zwrotną, która umożliwia doprecyzowanie problemu. W następnej rundzie eksperci otrzymują kolejną propozycję rozwiązania problemu wraz z listą anonimowych uwag i uzasadnień. Eksperci udzielają wtedy kolejnej serii odpowiedzi. Tego typu technika może zostać zastosowana do rozwiązania kluczowych problemów biznesowych lub projektowych. 9 http://www.joe.org/joe/2007february/iw1.shtml 48 Część I ♦ 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Ę (cid:141) 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. (cid:141) 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. (cid:141) 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ć. (cid:141) Diagram relacji (ang. interrelationship diagram) to diagram relacji przyczynowo-skutkowych. Należy sformułować problem oraz kwestie z nim związane, a następnie zdefiniować związek przyczyna-skutek pomiędzy kwestiami Rozdział 2. ♦ 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ę problemu10 (rysunek 16). 10 http://web2.concordia.ca/Quality/tools/17interdiagram.pdf 50 Część I ♦ Metodyki zarządcze a praktyka Rysunek 15. Przykład analizy pola siły Rysunek 16. Przykład diagramu relacji: Dlaczego nie wykorzystujemy procesów rozwiązywanie problemów? Rozdział 2. ♦ Project Management Body of Knowledge — PMBoK 51 (cid:141) Diagramy macierzowe (ang. matrix diagrams) — porównywanie dwóch lub więcej grup pomysłó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. Przykład diagramu macierzowego (cid:141) Diagramy przepływów (ang. Flowcharts) to graficzna reprezentacja procesu wizualizująca czynności, punkty decyzyjne oraz kolejność procesowania. Takie podejście ma ułatwić możliwość wykrycia błędów lub przewidzenia, gdzie mogą potencjalnie wystąpić. (cid:141) Matryce priorytetyzacyjne (ang. Prioritization matrices) — na bazie arkuszy Excela lub tablic „w kratkę” należy wypisać w rzędach kryteria decyzyjne, a w kolumnach — możliwe opcje rozwiązania problemu. W każde z pól wewnątrz takiej tabeli trzeba wpisać siłę rozwiązania względem każdego z kryteriów. Dodatkowo możliwe jest uwzględnienie wagi każdego z kryteriów decyzyjnych. Następnie wystarczy wyliczyć sumę dla każdej opcji, aby wybrać najlepszą z nich11. Przykładowe zastosowanie tej techniki zostało zaprezentowane w tabeli 1. Tabela 1. Przykład matrycy priorytetyzacyjnej Waga (1 – 10) A. Zakup gotowego rozwiązania B. Samodzielne stworzenie własnego rozwiązania C. Zlecenie wykonania rozwiązania 1. Koszt 2. Czas wykonania 3. Wewnętrzne kompetencje Suma 8 5 4 (maks. 170) 10 10 0 130 6 4 10 108 8 6 3 106 11 http://www.maqin.org/brownbag/PrioritizationMatrixNov05.pdf
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zarządzanie projektami IT. Przewodnik po metodykach
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: