PRINCE 2

Skuteczne Zarz dzanie Projektami

Office of Government Commerce

London: TSO

Opublikowano na podstawie zezwolenia wydanego przez Office of Government Commerce (OGC), dziaajcego w imieniu urzdu: Controller of Her Majestys Stationery Office. Crown Copyright 2006 Jest to produkt brytyjskiego wydawnictwa rzdowego (crown copyrigt) wprowadzajcy warto dodan, ktrego wykorzystywanie wymaga uzyskania licencji (Click-Use Licence) dotyczcej materiaw wydawanych przez HMSO wprowadzajcych warto dodan. Podania o zgod na wykorzystanie, reprodukowanie lub publikowanie materiaw zawartych w niniejszej ksi ce powinny by przesane na adres: HMSO, Licensing Division, St Clements House, 216 Colegate, Norwich, NR3 1BQ, Tel No: (01603) 621000; Fax No: (01603) 723000, E-mail: hmsolicensing@cabinet-office.x.gsi.gov.uk mo na rwnie wypeni formularz zamieszczony na stronie internetowej HMSO: http://www.hmso.gov.uk/copyright/licences/valueadded/appform.htm . HMSO, w porozumieniu z OGC, przygotuje wwczas licencj dla produktw o wartoci dodanej (Value Added Licence), opart na standardowych warunkach dostosowanych do szczeglnych wymaga skadajcego podanie, wraz z warunkami patnoci. Pierwsze wydanie tumaczenia na jzyk polski z roku 2006, na podstawie ostatecznej wersji PRINCE2 Pocketbook wydanej w roku 2005 (trzecie wydanie z roku 2005, trzeci dodruk z poprawkami z roku 2005) i Managing Successful Projects with PRINCE2 wydanej w roku 2005 (czwarte wydania, drugi dodruk z poprawkami z roku 2005). Logo OGC jest zarejestrowanym znakiem handlowym nale cym do Office of Government Commerce. PRINCE jest zarejestrowanym znakiem handlowym oraz zarejestrowanym znakiem handlowym stowarzyszenia, nale cym do Office of Government Commerce i zarejestrowanym w U.S. Patent and Trademark Office. Logo PRINCE2 Cityscape jest zarejestrowanym znakiem handlowym nale cym do Office of Government Commerce, zarejestrowanym w U.S. Patent and Trademark Office. PRINCE2 jest zarejestrowanym znakiem handlowym nale cym do Office of Government Commerce. ISBN 0 11 330946 5 Wydrukowano w: XXXXX First published in the English language by The Stationery Office (TSO). This translation of Managing Successful Projects with PRINCE2 is published by permission of OGC and the controller of HMSO, who accept no responsibility of the accuracy of this translation. Wspdziaajc z OGC oraz HMSO, The APM Group Limited (APMG) jest organizacj certyfikujc PRICE2 oraz oficjalnym dystrybutorem certyfikowanych tumacze Managing Successful Projects with PRINCE2 i PRINCE2 Pocketbook. W celu uzyskania dodatkowych informacji o sposobie zamwienia tej ksi ki prosz skontaktowa si z biurem APM Group w Wielkiej Brytanii.

APM GROUP LTD

Sword House, Totteridge Road, High Wycombe, Bucks. HP13 6DG United Kingdom Tel: 0044 1494 452450 Fax: 0044 1494 459559 e-mail: info@apmgroup.co.uk

PODZI KOWANIA

Pierwotny projekt wraz z kolejnymi wersjami PRINCE2 by dzieem konsorcjum Du- Berry WS Atkins and Penzer Allen - wykonanym w ramach umowy z hing dawn ( Central CCTA Computer and Telecommunications ). Skadamy podzikowania Agency Parity Consulting za pomoc w wykonaniu projektu oraz kolejnych wersji modelu PRINCE2. Szczeglne podzikowania ze strony OGC nale si wszystkim czonkom -iczcego ponad 150 indywidualnych konsultantw oraz organizacji l Zespou PRINCE2 User Review Panel, a tak e wielu innym uczestnikom projektu, ktrzy nie szczdzili nieodpatnie czasu na wkad w postaci pomysw i uwag, czynionych pod- przegldw jakoci. czas OGC kontynuowao prace nad rozwojem i ulepszeniem definicji i sposobu prezentacji w niniejszym podrczniku. OGC skada ponadto podzikowania PRINCE2 nastpujcym osobom i podmiotom za ich wkad i cige wsparcie dla metodyki PRINCE2 we wszystkich stadiach jej rozwoju: Mike Allen Department of Education and Employment Dick Bennett Duhig Berry Colin Bentley Hampshire Consultants Alan Berry Duhig Berry Ken Bradley SPOCE Graham Connellan Independent Consultant Brian Coombes The Projects Group Jeremy Cox Parity Consulting Alan Ferguson AFA Rob Herson Parity Consulting Mike Kirk Promit Tony Levene Quality Projects Tim Lulham DHL Systems Patrick Mayfield Pearce Mayfield Associates Nick Morgan Xansa (formerly Duhig Berry) Ian Santry Civil Service College Alison Thurlbeck Methodica Ben van der Wijngaart Tanner James Management Consultants ii i Training

PRINCE2

PODZIKOWANIA

Mark van Onna Pink Barry Wall Vega Division Peter Weaver PWA Consultancy

OGC skada wreszcie podzikowania nastpujcym osobom i organizacjom za ich wkad i pomoc w przygotowywaniu niniejszego poprawionego wydania podrcznika PRINCE2. Komitet c Steruj y Przewodniczcy Anne-Marie Byrne, OGC Gwny U ytkownik Eddie Borup, The Best Practice User Group Gwny Dostawca Richard Pharro, APM Group Ltd and Janine Evens, TSO

Kierownik Projektu Janine Evens, TSO

Zesp Projektu Colin Bentley, Emma Jones, David Atkinson, Alan Ferguson

Nadzr Projektu The Best Practice User Group pod kierunkiem: Chrisa Churchouse

Podzi kowania dla twrcw wydania polskiego

APMG ma przyjemno podzikowa: Romanowi Bratkowi, Andrzejowi Golikowi (redakcja), Jackowi Grniakowi, Leszkowi Kocickiemu, Piotrowi Kotelnickiemu, Cezaremu Paprockiemu, i Patrycji Wolskiej, pracownikom Centrum Rozwiza Mened erskich SA, za Ich zaanga owan wspprac podczas tumaczenia tego podrcznika. Wiesawowi Kosieradzkiemu z P2ware Sp. z o.o., za Jego istotn wspprac podczas nadzoru jakoci tumaczenia. Bo ennie Kleczewskiej i Annie Smolnik, za Ich wspprac podczas korekty jzykowej tumaczenia .

iv

PRZEDMOWA DO WYDANIA ANGIELSKIEGO

Stopie, w jakim w dzisiejszych czasach wikszo organizacji dowiadcza zmian, nie precedensu. Zmiany stay si sposobem na ycie organizacji, ktre by ma przetrwa, musz osign wiksz sprawno i przynosi wiksz warto, a tak e sta si skuteczniejszymi i bardziej konkurencyjnymi. Zarzdzanie ryzykiem, nierozerwalnie zwi- z wprowadzaniem zmian oraz innowacji, jest niezbdne dla osignicia zanym sukcesu przez projekt. Projekty grupuj zasoby, umiejtnoci, technologi i pomysy, by zrealizowa cele biznesowe i przynie korzyci. Dobre zarzdzanie projektem przyczynia si do zapewnienia, e zagro enia s waciwie identyfikowane i zarzdzane, a cele i korzyci s osi- w ramach bud etu, terminowo i z zgodnie z wy magan gane jakoci. PRINCE2 jest postrzegana jako midzynarodowy produkt wiatowej klasy, a jednocze- standardow metodyk zarzdzania projektami - nie tylko dlatego, e jest nie jest odzwierciedleniem wielu lat najlepszych praktyk w dziedzinie zarzdzania projektami elastyczne oraz adaptowalne podejcie, odpowiednie dla wszystkich i umo liwia projek-Jest to metodyka zarzdzania projektami, zaprojektowana jako platforma tw. obejmujca szerokie spektrum dyscyplin wiedzy i dziaa potrzebnych w trakcie prowadzenia projektu. PRINCE2 koncentruje si na Uzasadnieniu Biznesowym, ktre opisuje przyczyny uruchomienia projektu i stanowi jego biznesow legitymacj. Uzasadnieniekieruje przebiegiem wszystkich procesw zarzdczych projektu, od Biznesowe wstp- przygotowania nego do pomylnego zakoczenia. Wiele organizacji wykorzystuje umiejtnoci i usugi zewntrznych dostawcw wsppracujcych z zasobami wewntrznymi, by zwikszy szanse na sukces projektu. PRINCE2 zapewnia mechanizmy wykorzystania tych zasobw, umo liwiajc zespoowi integracj i efektywn wspprac w projekcie. Sukces, ktry osigna metodyka PRINCE2 zarwno w sektorze publicznym, jak i prywatnym, uatwia mi zar ekomendowanie Pastwu stosowanego przez ni podejcia. Jestem przekonany, e PRINCE2 pomo e Pastwu w realizacji lepszych projektw i osiganiu sukcesw! w

Peter Fanning Zas pca Dyrektora dza ceg t j OfficeZarz of Government o Commerce

PRZEDMOWA DO WYDANIA POLSKIEGO

Konieczno skutecznego zarzdzania zmian, pilna potrzeba skutecznego wdra ania strategii rozwoju, tempo i charakter przemian w Polsce s to niektre z wielu czynnikw warunkujcych niezbdno implementacji w polskich instytucjach, przedsibiorstwach oraz w caej administracji publicznej skutecznej metodyki zarzdzania projektami. Projekty zapewniaj dostarczenie na szczebel operacyjny materialnych lub niematerialnych produktw (rezultatw) niezbdnych do urzeczywistnienia zaplanowanej zmiany i zatwierdzonej do wdra ania strategii. Realizacj tych przedsiwzi mo na prowadzi intuicyjnie, lub tam, gdzie jest to mo liwe, wspomaga si wiedz, dowiadczeniem i dorobkiem innych organizacji. PRINCE2 poprzez swoj dojrzao, uniwersalno i otwarto stanowi najlepszy przykad uwzgldnienia oglnowiatowego bogatego dorobku wielu firm i zespow w zakresie zarzdzania projektami. Opisana w tym podrczniku metodyka stanowi mo e przeom w procesach modernizacji pastwa polskiego, ukierunkowujc je na zarzdzanie poprzez rezultaty. Mo e ona pomc w budowie uniwersalnego jzyka komunikacji midzy administracj centraln, lokaln, samorzdow i gospodark. Metodyka ta mo e sta si istotnym elementem budowy nowoczesnej, sprawnej, produktywnej i przejrzystej kultury i organizacji pracy. Docelowo mo e ona by pomocna w budowie adu publicznego i korporacyjnego w Polsce. Polskie wydanie podrcznika PRINCE2 umo liwia czytelnikom bezporedni dostp do stale aktualizowanej wiedzy, jak niesie za sob ta metodyka oraz pozwoli polskim mened erom z jednej strony udoskonali zarzdzane przez nich przedsiwzicia, z drugiej za umo liwi wniesienie polskich dowiadcze do wielkiej, wiatowej spoecznoci u ytkownikw PRINCE2. Mamy nadziej, e osoby zachcone lektur tego podrcznika sign po inne pozycje dorobku OGC w dziedzinie zarzdzania, takie jak Skuteczne Zarzdzanie Programami (MSP - Managing Successful Programmes) oraz Zarzdzanie Ryzykiem (M_o_R - Management of Risk). Zesp tumaczcy.

vi

WSTP DO WYDANIA POLSKIEGO

W tumaczeniu zastosowano si do regu przyjtych przez angielskiego wydawc, cho czciowo opisanych przez niego w rozdziale tylko 3.3. Przyjto, e nazwy wszystkich produktw zarzdczych PRINCE2, wy mienione wodatku A, traktowane s jak nazwy wasne, a wszystkie czony nazwy pisane s D du- literami, np. Uzasadnienie Biznesowe, Plan Projektu ymi itd. Tak pisowni przyjto rwnie dla nazw standar dowych rl wymienionych w Dodat- np. Kierownik Projektu, Komitet Sterujcy ku B, itd. Natomiast jeli chodzi o nazwy innych produktw, ktre cho nie wystpuj w Dodatku stanowi elementy charakterystyczne metodyki u ywane w praktyce, to A, ale tylko pierwsza litera nazwy produktu pisana jest du liter - np. Zalecenie zamknicia projektu, Ocena kocowa etapu itp. Z kolei nazwy procesw i podprocesw rwnie traktowane jako nazwy wasne pi- s du ymi literami i pochylonym drukiem (kursyw). Po ka dej nazwie sane procesu lub podprocesu wystpuje w nawiasach dwuliterowy skrt nazwy procesu gwnego. Skrt nazwy dla podprocesu zawiera ponadto kolejny numer podprocesu w ramach pro- gwnego, np.: cesu Przygotowanie (PP) dla procesu gwnego i Projektu Mianowanie Przewodnic cego i Kierownika (PP1) oraz z Organizowanie Zespou Projektu dzania (PP2). Zarz Projektem Wszelkie nazwy rozdziaw podrcznika, ktre przywouje si w tekcie, pisane s du iter i pismem pochylonym, a towarzyszy im tekst Rozdzia nn lub Dodatek l nn, nn oznacza numer rozdziau / dodatku wg spisu treci, np. Rozdzia gdzie Zar 6 z dzanie Strategiczne Projektem; Dodatek A Zarysy Opisw . tytuach rozdziaw dotyczcych procesw, komponentw i technik Produktw W metodyki PRINCE2 poza nazw polsk podano te , mniejsz czcionk jej orygina angielski. W gwce ka dej strony znajduje si nazwa rozdziau, przy czym na stronie nieparzystej jest to nazwa polska, a stronie parzystej angielska. w Sowniku terminw PRINCE2 or az w Dodatkach A i B podano polskie Podobnie i angielskie odpowiedniki prezentowanych nazw. W porwnaniu z wersj angielsk dodano sownik polsko-angielski i angielskopolski podstawowych terminw metodyki PRINCE2. Ilekro u ywa si samodzielnie sowa PRINCE2, nale y rozumie okreleniem fraz metodyka PRI NCE2. Wszystkie tumacza. przypisy dolne pochodz od pod tym

vii

PRINCE2

WSTP DO WYDANIA POLSKIEGO

Podrcznik nie mgby powsta bez bezinteresownego zaanga owania bardzo wielu osb. Cay zesp doo y wszelkich stara podczas tumaczenia, sprawdzenia tekstu oraz w okresie przygotowania podrcznika do druku, aby zapewni najwy sz jego jako.e wiele nazw i okrele dotychczas nie miao swoich odpowiednikw w Jednak jzyku a inne miay r ne odpowiedniki lokalne, powstae w firmach, ktre polskim, stosoway PRINCE2 wykorzystujc podrcznik w jzyku metodyk angielskim. Podjlimy prb lokalizacji i ujednolicenia terminw stosowanych przez metodyk PRINCE2, w czym wydatnie pomogli nam suchacze kursw wprowadzajcych i warsztatw PRINCE2. Wszyscy oni w pewnej mierze wsptworzyli to tumaczenie. Wszelkie uwagi i propozycje dotyczce tumaczenia prosimy kierowa na adres: Group Ltd na adres poczty APM translationfeedback@apmgroup.co.u elektronicznej: k

v i ii

SPIS TRE CI

Podzikowania............................................................................................................................................ iii Podzikowania dla twrcw wydania polskiego .................................................................................... iv Przedmowa do wydania angielskiego.......................................................................................................... v Przedmowa do wydania polskiego.............................................................................................................. vi Wstp do wydania polskiego ..................................................................................................................... vii 1. Wprowadzenie ............................................................................................................................... 1 1.1. Dlaczego nale y stosowa metodyk zarzdzania projektami? ................................................ 1 1.2. Korzyci wynikajce ze stosowania PRINCE2 ........................................................................ 2 1.3. Wsparcie dla metodyki PRINCE2 ............................................................................................ 4 1.4. Struktura podrcznika ............................................................................................................... 4 1.5. Wskazwki dla korzystajcych z podrcznika.......................................................................... 5 1.6. Terminologia PRINCE2 ........................................................................................................... 6 2. Wprowadzenie do PRINCE2......................................................................................................... 7 2.1. Czym jest projekt? .................................................................................................................... 7 2.2. Zakres PRINCE2...................................................................................................................... 8 2.3. Kontekst stosowania PRINCE2 ................................................................................................ 9 2.4. Oglny zarys PRINCE2.......................................................................................................... 12 2.5. Procesy.................................................................................................................................... 13 2.6. Komponenty ........................................................................................................................... 18 2.7. Techniki PRINCE2................................................................................................................. 19 2.8. Powizania procesw i komponentw.................................................................................... 20 3. Wprowadzenie do procesw........................................................................................................ 23 3.1. Poziomy zarzdzania .............................................................................................................. 23 3.2. Struktura opisu procesw........................................................................................................ 24 3.3. Symbole u yte w tekcie i diagramach................................................................................... 25 4. Przygotowanie Projektu (PP) (Starting Up a Project - SU) ..................................................... 27 4.1. Podstawowe zasady................................................................................................................ 27 4.2. Kontekst.................................................................................................................................. 28 4.3. Opis procesu ........................................................................................................................... 29 4.4. Mianowanie Przewodniczcego i Kierownika Projektu (PP1) ............................................... 31 4.5. Organizowanie Zespou Zarzdzania Projektem (PP2) .......................................................... 33 4.6. Mianowanie Czonkw Zespou Zarzdzania Projektem (PP3) ............................................. 38 4.7. Przygotowanie Zao e Projektu (PP4) .................................................................................. 40 4.8. Okrelenie Formuy Realizacji Projektu (PP5) ....................................................................... 44 4.9. Planowanie Etapu Inicjowania (PP6)...................................................................................... 47 5. Inicjowanie Projektu (IP) ( Initiating a Project - IP) ................................................................ 51 5.1. Podstawowe zasady................................................................................................................ 51 5.2. Kontekst.................................................................................................................................. 52 5.3. Opis procesu ........................................................................................................................... 52 5.4. Planowanie Jakoci (IP1)........................................................................................................ 54 5.5. Planowanie Projektu (IP2) ...................................................................................................... 58 5.6. Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka (IP3) ................................................ 62 5.7. Ustanowienie Elementw Sterowania (IP4) ........................................................................... 66 5.8. Ustanowienie Systemu Dokumentacji (IP5) ........................................................................... 70 5.9. Zestawienie Dokumentu Inicjujcego Projekt (IP6) ............................................................... 72 6. Zarzdzanie Strategiczne Projektem (ZS) (Directing a Project - DP) ........................................ 77 6.1. Podstawowe zasady................................................................................................................ 77 6.2. Kontekst.................................................................................................................................. 78 6.3. Opis procesu ........................................................................................................................... 79

ix

PRINCE2
6.4. 6.5. 6.6. 6.7. 6.8.

SPIS TRECI

Zezwolenie na Zainicjowanie Projektu (ZS1)......................................................................... 82 Zezwolenie na Realizacj Projektu (ZS2) ............................................................................... 85 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego (ZS3)............................. 91 Podejmowanie Decyzji Doranych (ZS4................................................................................ 96 Zatwierdzenie Zamknicia Projektu (ZS5) ........................................................................... 101 7. Sterowanie Etapem (SE) (Controlling a Stage - CS) .............................................................. 105 7.1. Podstawowe zasady .............................................................................................................. 105 7.2. Kontekst ................................................................................................................................ 106 7.3. Opis procesu ......................................................................................................................... 106 7.4. Zgoda na Wykonanie Grupy Zada (SE1)............................................................................ 109 7.5. Ocena Postpw (SE2).......................................................................................................... 113 7.6. Rejestrowanie Zagadnie Projektowych (SE3)..................................................................... 116 7.7. Analizowanie Zagadnie Projektowych (SE4) ..................................................................... 119 7.8. Przegld Stanu Etapu (SE5).................................................................................................. 122 7.9. Raportowanie Okresowe (SE6)............................................................................................. 127 7.10. Podejmowanie Dziaa Korygujcych (SE7)........................................................................ 129 7.11. Przekazywanie Zagadnie Projektowych (SE8) ................................................................... 132 7.12. Odbir Wykonanej Grupy Zada (SE9)................................................................................ 137 8. Zarzdzanie Wytwarzaniem Produktw (WP) (Managing Product Delivery - MP) ................. 141 8.1. Podstawowe zasady .............................................................................................................. 141 8.2. Kontekst ................................................................................................................................ 141 8.3. Opis procesu ......................................................................................................................... 142 8.4. Przyjmowanie Grupy Zada do Wykonania (WP1).............................................................. 143 8.5. Wykonywanie Grupy Zada (WP2)...................................................................................... 146 8.6. Oddanie Wykonanej Grupy Zada (WP3)............................................................................ 149 9. Zarzdzanie Zakresem Etapu (ZE) (Managing Stage Boundaries - SB) ................................. 153 9.1. Podstawowe zasady .............................................................................................................. 153 9.2. Kontekst ................................................................................................................................ 153 9.3. Opis procesu ......................................................................................................................... 154 9.4. Planowanie Etapu (ZE1) ....................................................................................................... 155 9.5. Uaktualnienie Planu Projektu (ZE2) ..................................................................................... 158 9.6. Uaktualnienie Uzasadnienia Biznesowego (ZE3)................................................................. 161 9.7. Uaktualnienie Rejestru Ryzyka (ZE4) .................................................................................. 163 9.8. Raportowanie Koca Etapu (ZE5)........................................................................................ 165 9.9. Opracowanie Planu Nadzwyczajnego (ZE6) ........................................................................ 168 10. Zamykanie Projektu (ZP) (Closing a Project - CP) ................................................................ 173 10.1. Podstawowe zasady .............................................................................................................. 173 10.2. Kontekst ................................................................................................................................ 174 10.3. Opis procesu ......................................................................................................................... 174 10.4. Przygotowanie Projektu do Zamknicia (ZP1) ..................................................................... 176 10.5. Okrelenie Dziaa Nastpczych (ZP2) ................................................................................ 180 10.6. Przegld Oceniajcy Projekt (ZP3) ....................................................................................... 184 11. Planowanie (PL) (Planning - PL) ........................................................................................... 189 11.1. Podstawowe zasady .............................................................................................................. 189 11.2. Kontekst ................................................................................................................................ 190 11.3. Opis procesu ......................................................................................................................... 191 11.4. Projektowanie Planu (PL1) ................................................................................................... 192 11.5. Okrelenie i Analizowanie Produktw (PL2) ....................................................................... 196 11.6. Okrelenie Dziaa i Wspzale noci (PL3)........................................................................ 198 11.7. Szacowanie (PL4) ................................................................................................................. 202 11.8. Harmonogramowanie (PL5) ................................................................................................. 205 11.9. Analizowanie Zagro e (PL6) .............................................................................................. 210 11.10. Kompletowanie Planu (PL7)................................................................................................. 213 12. Wprowadzenie Do komponentw metodyki PRINCE2 ........................................................... 217 13. Uzasadnienie Biznesowe Business Case .................................................................................. 219 13.1. Czym jest Uzasadnienie Biznesowe?.................................................................................... 219 13.2. Co powinno zawiera Uzasadnienie Biznesowe? ................................................................. 220 13.3. Opracowanie Uzasadnienia Biznesowego ............................................................................ 222 13.4. cie ka rozwoju Uzasadnienia Biznesowego ....................................................................... 223 14. Organizacja Organisation ....................................................................................................... 225

PRINCE2
14.1. 14.2. 14.3. 15. 15.1. 15.2. 15.3. 15.4. 15.5. 16. 16.1. 16.2. 16.3. 16.4. 16.5. 16.6. 17. 17.1. 17.2. 17.3. 17.4. 17.5. 17.6. 17.7. 17.8. 18. 18.1. 18.2. 18.3. 18.4. 18.5. 19. 19.1. 19.2. 19.3. 19.4. 19.5. 19.6. 19.7. 20. 20.1. 20.2. 20.3. 20.4. 20.5. 21. 22. 22.1. 22.2. 22.3. 22.4. 22.5. 22.6. 22.7. 22.8. 22.9. 23. 23.1. 24. 24.1.

SPIS TRECI

Oglne omwienie................................................................................................................ 225 Zesp zarzdzania projektem w PRINCE2.......................................................................... 230 Wsparcie Projektu................................................................................................................. 241 Plany Plans ............................................................................................................................. 243 Korzyci z planowania.......................................................................................................... 243 Czym jest plan?..................................................................................................................... 244 Jakie s elementy planu?....................................................................................................... 244 Podejcie PRINCE2.............................................................................................................. 246 Poziomy planw ................................................................................................................... 246 Elementy sterowania Controls ................................................................................................ 251 Cel sterowania ...................................................................................................................... 251 Przegld elementw sterowania............................................................................................ 252 Przygotowanie Projektu (PP)................................................................................................ 255 Kontrola postpw................................................................................................................ 258 Kontrolowane zamykanie ..................................................................................................... 271 Etapy..................................................................................................................................... 273 Zarzdzanie ryzykiem Management of risk ............................................................................ 279 Czym jest zarzdzanie ryzykiem?......................................................................................... 279 Zasady traktowania ryzyka ................................................................................................... 280 Cykl zarzdzania ryzykiem................................................................................................... 282 Profil ryzyka ......................................................................................................................... 288 Bud etowanie na potrzeby zarzdzania ryzykiem ................................................................ 289 Odwzorowanie zarzdzania ryzykiem na procesy PRINCE2 .............................................. 289 Wzajemne zale noci............................................................................................................ 292 Dalsze rozwa ania o zarzdzaniu ryzykiem ......................................................................... 293 Jako w rodowisku projektu Quality in a project environment ........................................... 295 Cel......................................................................................................................................... 295 Czym jest jako? ................................................................................................................. 295 Zarzdzanie jakoci............................................................................................................. 296 Droga do jakoci ................................................................................................................... 296 Realizacja prac dotyczcych jakoci projektu ...................................................................... 304 Zarzdzanie konfiguracj Configuration management ........................................................... 307 Cel......................................................................................................................................... 307 Definicja ............................................................................................................................... 307 Obiekt odniesienia ................................................................................................................ 309 Zarzdzanie konfiguracj...................................................................................................... 310 Metoda zarzdzania konfiguracj ......................................................................................... 312 Zarzdzanie konfiguracj a sterowanie zmianami ................................................................ 315 Zarzdzanie konfiguracj a Biuro Wsparcia Projektw........................................................ 315 Sterowanie zmianami Change control .................................................................................... 317 Cel......................................................................................................................................... 317 Zarzdzanie Zagadnieniami Projektowymi .......................................................................... 318 Poziomy uprawnie do wprowadzania zmian ...................................................................... 319 Integralno zmian................................................................................................................ 320 Zarzdzanie zmianami a Zarzdzanie konfiguracj.............................................................. 321 Wprowadzenie do technik ......................................................................................................... 323 Planowanie oparte na produktach (Product-based planning) ................................................. 325 Cztery produkty planowania opartego na produktach .......................................................... 325 Korzyci z planowania opartego na produktach ................................................................... 325 Sporzdzanie Opisu Produktu dla produktu kocowego...................................................... 326 Tworzenie Diagramu Struktury Produktw (DSP) ............................................................... 326 Sporzdzanie Opisu Produktu............................................................................................... 333 Sporzdzanie Diagramu Nastpstwa Produktw .................................................................. 335 Przykad planowania opartego na produktach ...................................................................... 336 Inne przykady...................................................................................................................... 339 Wytyczne do opracowania planu opartego na produktach.................................................... 343 Technika sterowanie zmianami (Change control technique) .................................................. 347 Kroki w sterowaniu zmianami .............................................................................................. 347 Technika przegld jakoci (Quality review technique) ........................................................... 351 Czym jest przegld jakoci? ................................................................................................. 351

xi

PRINCE2

SPIS TRECI

24.2. Korzyci z przegldu jakoci ................................................................................................ 351 24.3. Kontekst ................................................................................................................................ 351 24.4. Opis techniki Przegld jakoci .............................................................................................. 352 Leksykon terminw PRINCE2 Glossary ............................................................................................ 363 Dodatek A Zarysy Opisw Produktw Appendix A: Product Descriptions Outlines ....................... 375 A.1. Kryteria Akceptacji Acceptance Criteria.................................................................................. 376 A.2. Uzasadnienie Biznesowe Business Case................................................................................ 377 A.3. Raport z Punktu Kontrolnego Checkpoint Report.................................................................... 378 A.4. Plan Komunikacji Communication Plan.................................................................................. 379 A.5. Zapis Obiektu Konfiguracji Configuration Item Record ........................................................... 380 A.6. Plan Zarzdzania Konfiguracj Configuration Management Plan ............................................. 381 A.7. Oczekiwania jakociowe klienta Customers quality expectations........................................... 382 A.8. Dziennik Daily Log ................................................................................................................ 383 A.9. Raport Kocowy Projektu End Project Report ........................................................................ 384 A.10. Raport Kocowy Etapu End Stage Report.............................................................................. 385 A.11. Plan Nadzwyczajny Exception Plan ........................................................................................ 386 A.12. Raport o Istotnych Odchyleniach Exception Report................................................................ 387 A.13. Zalecenia Dziaa Nastpczych Follow-on Action Recommendations .............................. 388 A.14. Raport Okresowy Highlight Report.......................................................................................... 389 A.15. Rejestr Zagadnie Issue Log .................................................................................................. 390 A.16. Rejestr Dowiadcze Lessons Learned Log ........................................................................... 391 A.17. Raport o Dowiadczeniach Lessons Learned Report .............................................................. 392 A.18. Odstpstwo Off-Specification ............................................................................................... 393 A.19. Plan Przegldu Poprojektowego Post-Project Review Plan...................................................... 394 A.20. Diagram Struktury Produktw Product Breakdown Structure................................................... 395 A.21. Lista Kontrolna Produktw Product Checklist......................................................................... 396 A.22. Opis Produktu Product Description .......................................................................................... 397 A.23. Diagram Nastpstwa Produktw Product Flow Diagram.......................................................... 399 A.24. Zestawienie Statusu Produktw Product Status Account ......................................................... 400 A.25. Formua Realizacji Projektu Project Approach........................................................................ 401 A.26. Zao enia Projektu Project Brief.............................................................................................. 402 A.27. Dokument Inicjujcy Projekt (DIP) Project Initiation Document (PID) ...................................... 404 A.28. Zagadnienie Projektowe Project Issue.................................................................................... 407 A.29. Zlecenie Przygotowania Projektu Project Mandate............................................................... 408 A.30. Plan Projektu Project Plan ..................................................................................................... 410 A.31. Plan Jakoci Projektu Project Quality Plan.............................................................................. 412 A.32. Rejestr Jakoci Quality Log..................................................................................................... 413 A.33. Wniosek o Wprowadzenie Zmiany Request for Change......................................................... 414 A.34. Rejestr Ryzyka Risk Log ........................................................................................................ 415 A.35. Plan Etapu Stage Plan ............................................................................................................ 417 A.36. Grupa Zada Work Package ................................................................................................... 419 Dodatek B Role w Zespole zarzdzania projektem Appendix B: Project management team roles 421 B.1. Komitet Sterujcy Project Board............................................................................................. 421 B.2. Przewodniczcy Executive ..................................................................................................... 423 B.3. Gwny U ytkownik Senior User........................................................................................... 424 B.4. Gwny Dostawca Senior Supplier.......................................................................................... 425 B.5. Kierownik Projektu Project Manager ...................................................................................... 426 B.6. Kierownik Zespou Team Manager......................................................................................... 428 B.7. Nadzr Projektu Project Assurance ......................................................................................... 429 B.8. Wsparcie Projektu Project Support ......................................................................................... 430 B.9. Bibliotekarz Konfiguracji Configuration Librarian.................................................................... 431 B.10. Biuro Wsparcia Projektu (BWP) Project Suport Office (PSO).................................................. 432 Dodatek C Kategorie ryzyka Appendix C: Risk categories ............................................................ 433 Dodatek D Sprawdzian zgodnoci z PRINCE2 Appendix D: PRINCE2 healthcheck .................... 437 Dodatek E Zarzdzanie dokumentacj projektu Appendix E: Project document management ...... 445 E.1. Dokumentacja projektu......................................................................................................... 445 E.2. Dokumentacja etapw........................................................................................................... 446 E.3. Dokumentacja jakoci ........................................................................................................... 446 Sownik Polsko Angielski terminw PRINCE2................................................................................ 449

xii

PRINCE2

SPIS TRECI

Nazwy procesw i podprocesw ......................................................................................................... 449 Nazwy rl w zespole zarzdzania projektem (wg Dodatku B) ............................................................ 450 Komponenty PRINCE2 ................................................................................................................... 451 Produkty zarzdcze PRINCE2 (wg dodatku A)............................................................................... 451 Pozostae okrelenia............................................................................................................................. 452 English Polish Dictionary PRINCE2 terms ................................................................................... 457 PRINCE2 process and sub-process names....................................................................................... 457 Project management team roles (Appendix B) .................................................................................... 459 PRINCE2 Components .................................................................................................................... 459 PRINCE2 management products descriptions (Appendix A).......................................................... 459 Others................................................................................................................................................... 461 Dodatkowe informacje............................................................................................................................. 464 Poradniki najlepszych praktyk OGC ................................................................................................... 464 PRINCE2 akredytacje i egzaminy kwalifikacyjne ........................................................................... 464 The Best Practice User Group.............................................................................................................. 465

x ii i

1.

W PR OWAD ZE NI E

PRINCE (akronim utworzony na podstawie angielskiej PR ojects IN C ontr nazwy: Environments Projekty w sterowalnych rodowiskach) jest strukturaln olled metodyk efektywnego zarzdzania Zostaa ona po raz pierwszy wprowadzona projektami. przez CCTA (ang.: Central Computer and Telecommunications w 1989 r. Agency). opracowano na bazie PROMPTII, metodyki zar zdzania projektami PRINCE stworzo- Simpact Systems Ltd w 1975 r. PROMPTII zostaa zaadaptowana nej przez przez w 1979 r. jako standard do stosowania we wszystkich rzdowych projektach CCTA dotyczcych systemw informatycznych. W rzdowych projektach metodyka PRINCE PROMPTII w roku 1989. zastpia Metodyka bya cigle rozwijana przez CCTA (obecnie Office of Government Commer-1996 roku przedstawiono PRINCE2 jako odpowied na zgaszane przez u ce) i w ytkownikw zapotrzebowanie na ulepszone wytyczne do zarzdzania wszelkimi rodzajami projektw, a nie tylko tymi, ktre dotycz systemw informatycznych. PRINCE2na dowiadczeniach pyncych z projektw oraz dowiadczeniach oparto kierownikwzespow projektowych, ktrzy wnieli swj wkad, jedni wynikajcy projektw i z openionych bdw lub przeocze, a inni z ich p sukcesw. Metodyka PRINCE2 jest de stosowanym szeroko przez agendy standardem Wielkiej Brytanii, bdc jednoczenie powszechnie uznawana i facto, rzdowe w stosowana w sektorze prywatnym zarwno w Wielkiej Brytanii, jak i w skali midzynarodowej.

1.1.

Dlaczego nale y stosowa projektami?

metodyk

zarz

dzania

Niepowodzenia projektw s zbyt powszechne informacje o niektrych z nich dostaj pierwsze strony gazet, ale o wikszoci szybko si zapomina. Powodw si na niepo- jest du o i s one r nej natury. To niektre z wodze najczstszych: niedostateczna waga przykadana do sprawdzania, czy projekt posiada sensowne i igle c aktualne Uzasadnienie Biznesowe; niedostateczna waga przykadana do jakoci zarwno na pocztku, jak i w trakcie realizacji projektu; niewystarczajce zdefiniowanie wymaganych rezultatw, prowadzce do nieporo- na temat tego, co projekt ma zumie osign; brak porozumienia z interesariuszami i zainteresowanymi stronami, prowadzcy do dostarczania produktw, ktre nie s tym, czego oczekiwa klient; nieodpowiednie okrelenie oraz brak akceptacji rl i obowizkw w zarzdzaniu prowadzce do braku kierownictwa i podejmowania zych projektem, decyzji; niedokadne oszacowanie czasu trwania i kosztw, prowadzce do tego, e projekty trwaj du ej i kosztuj dro ej ni oczekiwano; 1

INTRODUCTION

PRINCE2

nieodpowiednie planowanie i koordynacja zasobw, prowadzce do przygotowania zych harmonogramw; nie do precyzyjny pomiar postpw oraz brak kontroli nad nimi, w wyniku czego informacja o rzeczywistym stanie projektu pozostaje nieujawniona a do momentu, ju gdy jest zbyt pno; brak kontroli jakoci, skutkujcy dostarczeniem produktw, ktre nie s akcepto- wrcz nie nadaj si do u walne lub ycia. Bez metodycznego zarzdzania projektami zleceniodawcy projektu, zar zdzajcy nim ci, ktrzy w nim pracuj, bd mieli r ne wyobra enia o tym, jak sprawy oraz powinny by zorganizowane i kiedy r ne aspekty projektu powinny by zaatwione. Zaintere-nie bd pewni, jakie s ich obowizki, jakie posiadaj uprawnienia i za co sowani odpowiadaj, a w rezultacie czsto wystpi zamt w otoczeniu projektu. Bez metodycznego zarzdzania projektem, rzadko koczy si on w terminie i w granicach dopuszczalnych kosztw - twierdzenie to odnosi si szczeglnie do du ych projektw. Dobra metodyka zarzdzania projektem poprowadzi projekt za porednictwem zestawu kontrolowanego, dobrze zarzdzanego, przejrzystego zbioru dziaa prowadzcych do osignicia po danych rezultatw. W PRINCE2 stosuje si zasady dobrego zarzdzania projektem, co pozwala unikn wy ej okrelonych problemw i przez to pomaga odnie sukces. Te zasady zwracaj uwag na to, projektom e: projekt jest procesem o ograniczonym czasie trwania, z okrelonym pocztkiem i kocem; projekty, aby zakoczyy si sukcesem, musz by zarzdzane; w celu osignicia prawdziwego zaanga owania w projekt, wszystkie strony musz jasno co do tego, dlaczego projekt jest potrzebny, co zamierza si za mie jego pomoc osign, jak ten rezultat ma by uzyskany oraz jakie s zwizane z tym obowizki.

1.2.

Korzy ci wynikaj ce ze stosowania PRINCE2

Organizacje staj si coraz bardziej wiadome mo liwoci, jakie daje zastosowanie podejcia projektowego do sposobu wprowadzania zmiany biznesowej, s wiadome korzyci, ktre mo e przynie jedna, wsplna, strukturalna metodyka zarzdzania projektami, ktra: jest powtarzalna; mo e by nauczana; jest budowana na dowiadczeniach; zapewnia, e ka dy wie, czego oczekiwa, gdzie, jak i kiedy; wczenie ostrzega o mo liwych problemach; bdc pro-aktywn, nie reaktywn, jest tak e zdolna do dostosowania si do na- nieoczekiwanych wydar ze. gych,

PRINCE2

WPROWADZENIE

Projekty mog istnie samodzielnie, mog mie zwizki z innymi projektami lub mog czci wikszego programu. PRINCE2 nadaje si do stosowania we by wszystkich tych sytuacjach, umo liwiajc organizacji: kontrolowane zarzdzanie zmian w kategoriach inwestycji i zwrotu z inwestycji; aktywne zaanga owanie u ytkownikw i inter esariuszy od pocztku do koca projektu, zapewniajce, e produkt(-y) speni(-) wymagania biznesowe, funkcjonalne, rodowiskowe, serwisowe i zarzdcze; podejcie, ktre odr nia zarzdzanie projektem od wytwarzania pr oduktu(w), czemu podejcie zarzdcze jest takie samo zarwno wtedy, gdy celem dziki pro- jest zbudowanie statku, jak i wtedy, gdy chodzi o wdro enie nowych jektu zasad pracy. PRINCE2 zapewnia korzyci kierownikom i dyrektorom projektu oraz organizacji poprzez kontrolowane u ycie zasobw i umo liwienie skuteczniejszego zarzdzania ryzykiem. Metodyka PRINCE2 obejmuje ugruntowane i sprawdzone najlepsze praktyki zarzdzania projektami. Jest powszechnie uznawana i rozumiana, dziki czemu zapewnia wsplny jzyk wszystkim uczestnikom projektu. PRINCE2 zachca do formalnego przydzielenia obowizkw w projekcie i koncentruje co projekt ma dostarczy, dlaczego, kiedy i si na tym, komu. Stosowanie metodyki PRINCE2 zapewnia projektom: kontrolowane i zorganizowane rozpoczcie, realizacj i zakoczenie; regularne przegldy postpw w odniesieniu do planu i Uzasadnienia Biznesowego; elastycznie ustanawiane punkty decyzyjne; automatyczne sterowanie zarzdcze wszelkimi odchyleniami od planu; zaanga owanie kierownictwa oraz interesariuszy we waciwych momentach podczas trwania projektu; dobre kanay komunikacyjne pomidzy zespoem zarzdzania projektem a reszt organizacji ; uzgodnienie wymaganej jakoci na pocztku projektu oraz cige monitorowanie jej zgodnoci z tymi wymaganiami. Kierownicy Projektw, stosujc PRINCE2, mog: ustali specyfikacj wymaga jako warunek wstpny dla rozpoczcia projektu; stosowa zdefiniowan struktur dla delegacji, zwierzchnictwa i komunikacji; dzieli projekt na etapy, atwiejsze do zarzdzania i dokadniejszego zaplanowania; mie pewno , e przydzielenie zasobw przez kierownictwo jest czci zgody na kontynuacj prac; dostarcza regularne, ale zwize r aporty zarzdcze; ograniczy spotkania z kierownictwem i interesariuszami d o minimum, obejmujcego wszystkie momenty istotne dla projektu. 3

INTRODUCTION

PRINCE2

Osoby, ktre bd bezporednio zwizane z u ytkowaniem produktw lub wykorzystywaniem rezultatw projektu, mog: uczestniczy w caym procesie podejmowania decyzji, dotyczcych projektu; jeli to niezbdne, w peni anga owa si w bie ce prace; uczestniczy w kontrolowaniu jakoci w trakcie projektu; mie pewno, e ich wymagania s nale ycie speniane. Wy szemu kierownictwu projektu PRINCE2 proponuje koncepcj zarzdzania odchy- , co oznacza, e kierownictwo zatwierdza plan, a nastpnie pozwala leniami Kierownikowi Projektu samodzielnie realizowa go, do momentu pojawienia si prognozy wystpienia istotnych odchyle od planu. Kierownicy wy szego szczebla s w peni informowani o stanie projektu za pomoc raportw, bez potrzeby uczestniczenia w czstych, zabierajcych czas . spotkaniach

1.3.

Wsparcie dla metodyki PRINCE2

Wielu dostawcw oferuje szkolenia, doradztwo, narzdzia i usugi w zakresie metodyki PRINCE2, zapewniajc wiadczenie na konkurencyjnych zasadach usug wspierajcychwe wdra aniu i stosowaniu tej organizacje metodyki. Zorganizowano midzynarodowy program akredytacji dla trenerw i konsultantw, zapewniajcy organizacjom wysok jako i jednolity poziom usug. Okrelono kwalifikacje zawodowe w zakresie PRINCE2, co pozwala ocenia kandydatw pod wzgldem znajomoci metodyki i umiejtnoci jej stosowania w scenariuszach projektowych. Dodatkowo, istnieje aktywna grupa u ytkownikw powicajcych si wspieraniu, promo- oraz cji ulepszaniu metodyki.

1.4.

Struktura podr

cznika

Podrcznik skada si z piciu gwnych czci, co ilustruje Rysunek 1.1. Wprowadzeni przedstawia podstawowe zasady obowizujce w zarzdzaniu e oraz opis projektami ich ujcia stosowany przez PRINCE2. Przedstawiono te , w jaki sposb metodyka PRINCE2 jest zgodna z odpowiednimi zagadnieniami oglnego zarzdzania programem . Cz dotyczca Proces opisuje model procesowy PRINCE2, wyjaniajc, co nale w y zrobi, aby poprzez zebranie razem i zastosowanie tych zasad, zarzdza projektemprowadzcy do sukcesu. w sposb Cz dotyczca Komponentw zawiera objanienie i opis gwnych elementw zarzdzania projektami, takich jak organizacja i sterowanie, oraz sposobu, w jaki s one w- do PRINCE2. Komponenty te stanowi surowiec dla dobrego zarzdzania czone projektami, wczajc w to zarzdzanie jakoci i zarzdzanie ryzykiem. Cz dotyczca Techni zawiera omwienie kilku technik zarzdzania projektami, k cyficznych dla PRINCE2. spe-

PRINCE2

WPROWADZENIE

Wprowadzenie

Procesy

Komponenty

Techniki

Dodatki

Rysunek 1.1. podrcznika

Struktura

Dodatk zawieraj zarysy opisw produktw zarzdczych PRINCE2, opisy rl, i pytania umo liwiajce organizacjom stosujcym PRINCE2 autodiagnoz, kategorie ryzyka oraz sugerowany system gromadzenia doku mentw zarzdczych. Dodatkowo zamieszczono leksykon u ywanych terminw.

1.5.

Wskazwki dla korzystaj

cych z podr

cznika

Podrcznik jest przeznaczony dla osb, ktre bd uczestniczyy w projekcie zarzdza- PRINCE2 lub dla chccych zrozumie, jak PRINCE2 wspiera proces nym wg zarzdzania projektem. Grupa ta obejmuje kierownikw wy szych szczebli, odpowiedzialnych za oglne kierowanie projektem, Kierownikw Projektw, audytorw projektw, personel nadzoru jakoci oraz czonkw zespou projektowego. Dodatkowo kierownicy liniowi pracownikw zatrudnionych w projektach mog odnie korzyci z lektury Roz- 2 Wprowadzenie do PRINCE2 , w ktrym znajd wskazwki, jak ocenia dziau zaangaowanie swoich podwadnych w pracach zespou projektowego. Podrcznik opracowano z zamiarem dostarczenia czytelnikowi kompletnej informacji o metodyce PRINCE2. Jako taki w caoci stanowi podstawow lektur dla wszystkich Kierownikw Projektw. Jednak, wymienione poni ej fragmenty zaleca si szczeglnie konkretnym grupom: Kierownicy Projektw, ktrzy pierwszy raz stykaj si z PRINCE2, powinni: przeczyta i przyswoi Rozdzia Wprowadzenie do PRINCE2 , aby doceni 2 caociowe podejcie PRINCE2 do powoywania projektu i zarzdzania nim; wykorzysta opisy procesw zamieszczone w Proces , jako podpodrozdzialeplanowania projektu i decydowania o potrzebnych y staw dla zasobach; przeczyta i przyswoi Komponenty w celu zaznajomienia podrozdzia si z relacjami pomidzy komponentami a procesami. 5

INTRODUCTION

PRINCE2

Kierownicy Projektw, ktrzy s ju zaznajomieni z PRINCE2, powinni uwa nie przeczyta i zrozumie model procesowy, opisany w Proces , by dopodrozdziale y ceni zmiany akcentw i podejcie procesowe. Kierownicy wy szych szczebli, ktrzy bd zaanga owani w projekt na poziomie Sterujcego, powinni doceni PRINCE2 i znaczenie swoich rl w Komitetu projekcie dziki przestudiowaniu Wprowadzeni (1 i 2), Uzasadnieni rozdziaw:(13), Organizacj e opisu Biznesow (14) oraz Strategiczne e dzani e a procesu Zarz e Projekte (6). m Kierownicy programw, w ktrych wystpuj projekty zarzdzane zgodnie z PRINCE2, powinni zyska zrozumienie podejcia, ktre PRINCE2 stosuje do powoywania projektu i zarzdzania nim.

1.6.

Terminologia PRINCE2

Wymienione ni ej pojcia s najwa niejsze dla zrozumienia PRINCE2 i wszystkie si tak e leksykoni . Czytelnicy powinni je sobie przyswoi, aby znajduj w zapobiec wszelkim mo liwyme nieporozumieniom podczas stosowania PRINCE2. Uzasadnienie Biznesowe jest u ywane do sprecyzowania informacji ustanowienie, kontynuacj uzasadniajcych lub przerwanie projektu. Odpowiada na pytanie: Dlaczego powinien by zrealizowany?. Jest przegldane i uaktualniane podczas ten projekt trwa- projektu nia w kluczowych jego momentach. Klien oznacza osob lub grup osb, ktra zlecia prace i bdzie korzystaa z r t kocowych projektu. ezultatw Produkt oznacza wszystko, co projekt ma wytworzy lub zmieni, zarwno wytwory materialne, jak i niematerialne+. Rezultaty projektw mog si r ni pomidzy sob ogromnie; mog to by obiekty fizyczne, takie jak budynki i maszyny, ale mog to by elementy niematerialne, takie jak zmiana kulturowa czy zmiana pogldw te spoecznych. Program zmiany. oznacza korzystne zbir projektw, ktre razem przynosz organizacji

Dostawca oznacza osob lub grup osb, ktra dostarcza projektowi specjalistycznych zasobw i umiejtnoci lub dostarcza towary i usugi w celu wytworzenia r ezultatu projektu, jakiego wymagaj klient i u ytkownik(cy). U ytkownik oznacza osob lub grup osb, ktra bdzie u ytkowaa lub stosowaa produkt kocowy. W niektrych sytuacjach klientem i u ytkownikiem mo e by ta sa- gr upa osb. ma

2.
2.1.
PRINCE2 jako:

W PR OWAD ZE NI E DO P R IN CE 2

Czym jest projekt?

definiuje projekt kszej proliczby

rodowisko dcze stworzone w celu dostarczenia jednego lub zarz wi duktw biznesowych zgodnie z lonym Uzasadnieniem okre Biznesowym. Inna mo projektu: liwa definicja

Organizacja powoana okre zdefiniowanych wynikw wykorzystaniu uprzednio lonych okre zasobw.

na lony czas, w celu wytworzenia unikatowych i lub wcze rezultatw w ustalonym czasie, przy

nie j

PRINCE2 dodatkowo przyjmuje, e odpowiedzialni za projekt mog nie posiada dowiadcze wsplnej pracy w przeszoci nad wytworzeniem podobnego zestawu wyni- lub rezultatw dla danego klienta. Dlatego niezbdne jest dobre kw zorganizowanie koordynacji pracujcych nad projektem oraz istnieje potrzeba zrozumiaego dla wszyst-stron okrelenia podziau obowizkw midzy wykonujcych prace, kich zarzdzajcych projektem i sponsorujcych go. Projekt zarzdzany wedug PRINCE2 posiada nastpujce cechy: okrelony i skoczony cykl ycia; zdefiniowane i mierzalne produkty biznesowe; odpowiedni zestaw dziaa su cych uzyskaniu produktw biznesowych; okrelon ilo zasobw; struktur organizacyjn z okrelonymi zakresami obowizkw, su c zarzdzaniu projektem . Ka dy projekt jest realizowany w swoistym kontekcie biznesowym. Projekt mo e by odosobniony, mo e by jednym z szeregu powizanych ze sob projektw lub mo etanowi cz programu lub strategii s firmy. Projekt ze swojej natury jest struktur powoan na okrelony czas, utworzon dla osignicia wyspecyfikowanych korzyci lub celw biznesowych. Po wykonaniu tej pracy projekt jest rozwizywany. Projekt ma cykl ycia, ktry jest okr elony pr zez cig kolejnych dziaa prowadzcychzenia pr oduktu kocowego. Okrelenia okres do wytwor u ywa si do ycia produktu. Tych dwch okrele nie nale y opisania ycia myli.

AN INTRODUCTION TO PRINCE2

PRINCE2

Rysunek 2.1 pokazuje, e okres ycia mo e si zacz od wstpnej idei produktu i po przejciu poprzez faz eksploatacji, skoczy si ostateczn lub pomysu likwidacj kiedy osignie on kres swej u produktu, ytecznoci. Cykl ycia obejmuje zadania od specyfikowania i projektowania projektu jego testowania i przekazania do produktu, a do eksploatacji. obejmuje cykl PRINCE2 ycia projektu oraz pewne przygotowania przedprojektowe.
Pomys Studium Zlecenie przygotowania projektu

Specyfikacja Okres ycia produktu Cykl ycia Konstruowanie Wykonanie Testowanie Przekazanie projektu

Ocena warto Eksploatacja Zomowanie

ci

Rysunek 2.1. projektu

Okres

ycia produktu i cykl

ycia

2.2.

Zakres PRINCE2

Rysunek 2.2 pokazuje, jak PRINCE2 plasuje si w rodowisku biznesu i projektu. Nie intencj twrcw metodyki PRINCE2 objcie wszystkich zagadnie zwizanych byo zarzdzaniem projektami. W zale noci od typu projektu i rodowiska, w firmie mog potrzebne r ne techniki i narzdzia zarzdzania projektem. Niektre aspekty by zarzdzania projektami s dobrze ujte w istniejcych ju i sprawdzonych metodach i tego wzgldu wyczono je z PRINCE2. S to na przykad: z techniki kierowania ludmi, takie jak uprawnie i obowizkw oraz przewodzenie zespoowi; motywowanie, delegowanie

oglne techniki planowania jak wykresy Gantta lub analiza cie ki krytycznej; tworzenie i zarzdzanie firmowym systemem jakoci oraz mechanizmami zapewnienia jakoci; techniki kontroli bud etowej oraz analizy wartoci wypracowanej. PRINCE2 obejmuje zarzdzanie projektem i zarzdzanie zasobami zaanga owanymi w wykonywanie prac. Nie obejmuje jednak technik specjalistycznych zwizanych z wytwarzaniem produktw. Jest to zadanie innych metod, chocia PRINCE2 musi wspdziaa z nimi, by umo liwi dopyw informacji niezbdnych do zarzdzania projektem, na przykad w takich obszarach jak szacowanie.

PRINCE2

WPROWADZENIE DO PRINCE2

Chocia metodyka PRINCE2 koncentruje si na projekcie, jej stosowanie rozpoczyna jego rozpoczciem, tak aby mg on zosta uruchomiony w sposb si przed zorgani- i kontrolowany. zowany Innym, czsto krytycznym obszarem projektu s zakupy. PRINCE2 zakada, e projekt jest realizowany w kontekcie jakiego kontraktu. Sam proces przygotowania i zawierania umw nie jest wczony do metodyki. Przygotowywanie umw i zakupy same w sobie s dziaaniami specjalistycznymi (podobnie jak tworzenie programw kompute- i dlatego mog by zarzdzane za pomoc metodyki PRINCE2. Je eli rowych) przygo- umw zaopatrzeniowych lub kontraktu musi by wykonane we wczesnych towanie eta- projektu, mo e to powodowa konieczno zmian w Komitecie pach Sterujcymczciach zespou zarzdzania projektem z chwil zakoczenia tych i innych etapw. Na przykad, mo e by wskazane wczenie do Komitetu Sterujcego przedstawiciela dziau zakupw (w roli Gwnego Dostawcy) wy szego szczebla jako osoby odpowiedzialnej za zaopatrzenie i reprezentujcej interesy dostawcw do momentu wyonienia dostawcw. waciwych

Misja Strategia Misja Programy Strategia Programy Projekt Operacje Projekt Operacje
dzia Narz Oczekiwania dzia Narz ci Korzy Techniki Oczekiwania Techniki Ludzie ci Korzy Ludzie

PRINCE2 PRINCE2 dzanie Zarz

dzanie Zarz konfiguracj konfiguracj

Biznes Biznes

Rysunek 2.2. biznesem

Zwizek PRINCE2 z projektami i

Sprawy przygotowywania kontraktw i umw zaopatrzeniowych zwikszaj jeszcze znaczenie kompletnego i dokadnego Dokumentu Inicjujcego Projekt bardziej (DIP), musi by zgodny z treci kontraktu(-w). Chocia metodyka PRINCE2 ktry zawiera rl opisy w 1 , to ich przeksztacenie na formalne zakresy obowizkw dla projekcie projektu bdzie wymagao szczeglnej uwagi, np. w takich przypadkach konkretnego jak Nadzr Projektu, zatwierdzanie Opisw Produktw czy przypisywanie zagro eniom wacicieli .

2.3.

Kontekst stosowania PRINCE2

Metodyka PRINCE2 mo e by stosowana w projektach wszelkiego typu i w dowolnych rodowiskach. Zawiera ona kompletny zestaw poj i procesw, dotyczcych zarzdzania projektem, ktr y stanowi niezbdne minimum zapewniajce waciwy przebieg pro1

Patrz: Dodatek B Role w zespole zarz dzania projektem przypis tumacza.

AN INTRODUCTION TO PRINCE2

PRINCE2

jektu i zarzdzanie nim. Jednak sposb, w jaki PRINCE2 zastosuje si w poszczeglnych projektach, bdzie si znacznie zmienia i takie dostosowanie metodyki, by odpowiadaa warunkom konkretnego projektu, ma krytyczne znaczenie dla jej skutecznego u ycia. Projekty realizowane wedug metodyki PRINCE2 s zawsze zorientowane na dostar- okrelonych produktw, zgodnie z ustalonym Uzasadnieniem czanie Biznesowym.u mo liwia sformuowanie i utrzymywanie definicji korzyci PRINCE2 biznesowychw wyniku projektu, ktre s jego si napdow. Korzyci te s osiganych przedsta- Uzasadnieniu Biznesowym. Mog one przyj r ne wione w formy: korzyci finansowych, w postaci dodatkowych zyskw lub uniknitych kosztw; korzyci strategicznych, poprzez dostarczenie sposobu dochodzenia do jednegocelw z strategicznych organizacji; korzyci prawnych, poprzez spenienie jakiego bezwzgldnego wymagania narzuconego przez dyrekcj lub organ regulacyjny. Od pocztku do koca projektu zarzdzanego wedug PRINCE2, Uzasadnienie Biznesowe jest przegldane, a postp projektu jest mierzony wzgldem uaktualnianych ocze- osignicia zdefiniowanych korzyci. W trakcie projektu czsto wystpuj mo kiwa -iwoci pojawienia si nowych korzyci, ktre mog podnie warto produktu l lub znaczco wpyn na inny projekt. Jednak wszelkie odchylenia od pierwotnego Uzasadnienia Biznesowego musz by kontrolowane przez Komitet Sterujcy. W ka dym projekcie wystpuj interesariusze, zainteresowani projektem i jego produk- ktrych nale tami, do : klienci, ktrzy zlecili prace i bd czerpali korzyci z jego kocowych rezultatw; u ytkownicy, ktrzy bd u ywali lub eksploatowali produkt kocowy. Klientem i u ytkownikiem mo e by ta sama grupa osb; dostawcy, ktrzy dostarczaj na potrzeby projektu specjalistyczne zasoby i/lub umiejtnoci, albo dostarczaj towary i usugi; poddostawcy, ktrzy dostarczaj towary lub usugi dostawcom. rodowisko klient-dostawca zakada, e istnieje klient, ktry sporzdzi specyfikacj podanego produktu, wykorzysta produkty kocowe i (w wikszoci przypadkw) zapaci za projekt, oraz dostawca (wiodcy), ktry zapewni zasoby i umiejtnoci do wytwo- tego produktu. PRINCE2 stworzono przyjmujc, e te dwie strony rzenia pochodz z oddzielnie zarzdzanych, a zwykle z dwch niezale nych podmiotw gospodarczych. gdy, jak to si czsto zdarza, obie W przypadku - klient i dostawca strony wsplny zarzd, wpynie to na skad zespou zarzdzania maj projektem. Niezale nie od skadu tego zespou, klient powinien zawsze uczestniczy w wytwarzaniu i weryfikacji produktw w caym projekcie. Projekt ma to do siebie, e realizuje si go w celu wprowadzenia zmiany, a przyszo trudniejsza do przewidzenia ni rutynowa dziaalno. W trakcie jest zawsze projektu specyfikacja produktw nieuchronnie bdzie podlegaa zmianom. Zmiany te musz by sterowane, poniewa mog atwo zniszczy szanse projektu na sukces. Sterowanie wi e si z kontrol wer sji - zagadnieniem, ktre w PRINCE2 obejmuje zmianami Zarzdzanie konfiguracj. Zarzdzanie konfiguracj jest podstawow czci sterowania 10

PRINCE2

WPROWADZENIE DO PRINCE2

projektem i skupia si na sterowaniu dostarczanymi produktami, ktre jest mo liwe posiadaniu wiedzy, gdzie si one znajduj w ka dym momencie, jaki jest ich dziki sta- kto nad nimi pracuje i ktra wersja jest tus, ostatni. W dodatku, projekty mog by du e i skomplikowane oraz mog mie do czynienia lub niezwykymi czynnikami. Z tego wzgldu ryzyko jest wa nym z nowymi elementem, ktry musi by brany pod uwag w trakcie zarzdzania projektem, a PRINCE2 wcza zarzdzanie ryzykiem w swoje procesy. Niezale nie od natury i wielkoci projektu, PRINCE2 wymaga Etapu inicjowania, ktr ybejmuje planowanie i definiowanie projektu. Etap inicjowania umo liwia o dokonanie kierowniczego przegldu przed podjciem jakichkolwiek zobowiza dotyczcych pniejszych etapw i zwizanych z nimi kosztw oraz zasobw. Wok projektu bdzie wiele oglniejszych spraw. Bdzie to wymagao stosowania in- metodyk i sposobw podejcia, takich jak zarzdzanie programami. PRINCE2 nych jest ukierunkowana na obszar poredni pomidzy tymi oglnymi, bardziej strategicznymi a technikami specjalistycznymi potrzebnymi do wytworzenia pr zagadnieniami, oduktw specjalistycznych. Tylko nieliczne projekty mog by zrealizowane w caoci w odizolowaniu od innych Projekty zarzdzane wedug PRINCE2 mog istnie jako cz programu, prac. przyczyniajc si do osignicia korzyci, wynikajcych z wikszej zmiany organizacyjnej. programu, wyniki jednego projektu mog by wykorzystane przez W kontekcie inne projekty jako wkad. Mo liwe s inne zale noci midzy projektami, takie jak wsplne W PRINCE2 kadzie si silny nacisk na okrelenie produktw, ktre zasoby. projekt jest zobowizany dostarczy, i w ten sposb ustanawia solidn podstaw do okrelenia zakresu projektu. Studium wykonalno ci

W pewnych sytuacjach mo e by wymagane opracowanie studium wykonalnoci w celu zbadania istniejcej sytuacji i okrelenia wariantw dalszego postpowania. W przypadku stosowania PRINCE2 optymalnym podejciem byoby potraktowanie stu- wykonalnoci jako osobnego i niezale nego dium projektu. Rysunek 2.3 ilustruje wzgldnie prosty cykl ycia projektu, majcego na celu przygo- studium wykon alnoci. Projekt taki ma jeden Plan Projektu, jedno towanie Uzasadnienie Biznesowe, jeden zbir zagro e (ryzyko) i jeden produkt kocowy rekomenda- z mo liwych do zalecenia wariantw mo e si ogromnie r ni od cj. Ka dy pozosta- wzgldem kosztw i terminw. Ka dy wariant bdzie mie oddzielny ych pod Plan Projektu, Uzasadnienie Biznesowe i zbir zagro e (ryzyko), ale na zakoczenie pro- studium wykonalnoci jest tylko jedna rekomendacja. Realizowany zgodnie jektu z etodyk PRINCE2 projekt opiera si na uzyskanych na zakoczenie Etapu m inicjowania: jednoznacznej definicji pr oduktu kocowego, Planie Projektu i bud ecie. Gdyby wykonalnoci byo czci projektu realizowanego zgodnie z PRINCE2 studium wyko- przed wypracowaniem rekomendowanego rozwizania, wtedy nie byoby mo nywan -iwe podanie jasnego okrelenia produktu kocowego pr ojektu przed kocem jego l Eta-inicjowania, gdy okrelenie to zale aoby od wariantu wybranego w trakcie pu studium wykonalnoci. Waciwy wariant powinien by wic wybrany w odrbnym projekcie,

11

AN INTRODUCTION TO PRINCE2 ktrego przedmiotem jest przygotowanie studium wykonalnoci umo liwiajc temu drugiemu projektowi przejcie do pracy z jasnym zestawem informacji projektowej.
Przedstawienie Zdefiniowanie Przedstawienie Zdefiniowanie rekomendacji wariantw problemu Badania Przygotowanie rekomendacji wariantw problemu Badania Przygotowanie

PRINCE2

Rysunek 2.3. Studium wykonalnoci

Cykl

ycia projektu przygotowujcego

2.4.

Oglny zarys PRINCE2

PRINCE2 jest strukturaln metodyk zarzdzania projektami opart na dowiadczeniach pyncych z analiz wynikw uzyskanych przez Kierownikw Projektw, ktrzy swj wkad, jedni wynikajcy z popenionych bdw lub przeocze, a inni wnieli ynikajcy z ich sukcesw. w PRINCE2 prezentuje podejcie do zarzdzania projektami oparte na procesach. Procesy dziaania zarzdcze, ktre powinny by wykonywane w trakcie projektu. definiuj Dodatkowo PRINCE2 opisuje kilka komponentw, ktre maj zastosowanie w ramach stosownych dziaa. Rysunek 2.4 przedstawia te komponenty, rozmieszczone wok gw-modelu procesowego. nego
Sterowanie zmianami
dz rz Za a ni e S tr a te g ic z ne P roj e k t e m dz rz Za a ni e S tr a te g ic z ne P roj e k t e m

Uzasadnienie biznesowe

ZS 4 ZS 4 Z S2 ZS 3 Z S5 Z S1 Z S1 Z S2 ZS 3 Z S5
dz rz Za a ni e dz k rzre Za a ni es e m Za Za a pu s e m Et k re Et a pu Za c y k S t m g ot ni Ini e jowa owa Pr zyrowaan ieeni e Za mjowa owa S t e pe k ttu Ini zyrowau ni Pr a jegkotan ieeni e p Etroje P roj y k Proc e m p a e Etroje P rojpe k ttu Pro je km u dz rz Za a ni e dz rz Za a ni er Wy no P la twawaza n ie m nie Wy twakrtnie ie m n P rodu wazaw P la no P rodu k t w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 2.4. Procesy i komponenty PRINCE2

12

PRINCE2

WPROWADZENIE DO PRINCE2

2.5.

Procesy

Model procesowy PRINCE2, Rysunek 2.5, skada si z omiu oddzielnych procesw zarzdczych, obejmujcych dziaania od wprowadzenia projektu na waciwe tory, poprzez sterowanie i zarzdzanie postpami projektu, a do jego zamknicia. Wsplny proces Planowani (PL) jest wykorzystywany przez cztery inne e procesy. Ka dy projekt zarzdzany wedug PRINCE2 musi w jakiej formie uwzgldni ka dy tych procesw. Jednak e kluczem do pomylnego zastosowania modelu z procesowego jest jego dopasowanie do potrzeb konkretnego projektu. W odniesieniu do ka dego pro- powinno by postawione pytanie: W jakim stopniu dany proces powinien by cesu zastosowany w tym konkretnym projekcie?.
Zarz dzanie Strategiczne Projektem

ZS4 ZS1 ZS2 ZS3 ZS5

Zarz dzanie Zakresem Etapu

Przygotowanie Projektu

Inicjowanie Projektu

Sterowanie Etapem

Zamykanie Projektu

Planowanie

Zarz dzanie Wytwarzaniem Produktw

Rysunek 2.5. Model procesowy PRINCE2

2.5.1.

Przygotowanie Projektu (PP)

(Starting Up a Project SU)

Jest to pierwszy, przedprojektowy, proces PRINCE2 skonstr uowany w celu zagwaran- e bd spenione wszystkie warunki wstpne niezbdne do zainicjowania towania, projektu. Zakada on istnienie Zlecenia Przygotowania ktre w oglnych Projektu, katego- Proces ten riach okrela powody podjcia projektu oraz wymagany produkt. powinien krtki. by bardzo Prace objte procesem koncentruj si wok szeciu spraw: organizacja zespou zarzdzania projektem oraz w zakresie, jaki bdzie mo liwy, wyznaczenie jego czonkw; Zao enia Projektu; Formua Realizacji rozwizania) ;

Projektu (oglne

okrelenie

sposobu

dostarczenia

13

AN INTRODUCTION TO PRINCE2 Oczekiwania klienta; Rejestr Ryzyka; jakociowe

PRINCE2

Plan Etapu inicjowania. W tym procesie zakada si te wykorzy- podczas stywa caego projektu.

Dziennik, ktry Kierownik Projektu bdzie

Zarz dzanie Strategiczne Projektem (Directing a Project DP) (ZS) Proces Zar dzanie Strategiczne (ZS) przebiega od rozpoczcia z Projektem (PP) a procesu Przygotowanie do zamknicia Projektu projektu. Proces jest adresowany do Komitetu Sterujcego - grupy osb podejmujcych decyzje reprezentujcych biznes, u ytkownikw i dostawcw (Komitet Sterujcy zarzdcze, jest dokadnie opisany w Rozdziale 14 Organizacj ). Komitet Sterujcy zarzdza a odchyleniami, monitoruje projekt wykorzystujc istotnymi i ster uje projektem raporty wykorzy- pewn stujc liczb punktw decyzyjnych. Procesy kluczowe dla Komitetu Sterujcego dotycz piciu gwnych obszarw: zezwolenia na zainicjowanie projektu (rozpoczcie projektu na waciwej podstawie); zezwolenia na realizacj projektu (przegld Dokumentu Inicjujcego Projekt upewnienia si, e anga owanie w projekt powa nych rodkw w celu inwestycyj- ma nych sens); ustalenia zakresw etapw (anga owanie dalszych zasobw po sprawdzeniu dotychczasowych rezultatw) ; wydawania decyzji doranych ( monitorowanie postpw, udzielanie rad i wytycznych, reagowanie na powa ne zagro enia dla planu lub korzyci); zamknicia projektu (zatwierdzenie rezultatw projektu i doprowadzenie projektu do kontrolowanego zamknicia).

2.5.2.

Inicjowanie Projektu (Initiating a Project IP) (IP) Zadania procesu Inicjowanie (IP) Projektu to: okrelenie, jak zostanie osignita wymagana jako produktw; zaplanowanie projektu i okrelenie jego kosztu; przegld Uzasadnienia Biznesowego i potwierdzenie, e jest ono akceptowalne; upewnienie si, e po uwzgldnieniu ryzyka, inwestowanie czasu i wysiku potrzebnego na realizacj projektu jest uzasadnione; umo liwienie Ko mitetowi Sterujcemu i zachcenie go do wzicia na siebie roli waciciela projektu oraz wyra enia zgody na przydzia zasobw dla nastpnego etapu; dostarczenie planu odniesienia (planu bazowego) niezbdnego w procesie podejmowania decyzji w trakcie caego ycia projektu.

2.5.3.

14

PRINCE2

WPROWADZENIE DO PRINCE2

Gwnym produktem tego procesu jest Dokument Inicjujcy Projekt, ktry udziela odpowiedzi na istotne dla projektu pytania: Co?, Dlaczego?, Kto?, Kiedy? i Jak?. W tym pr ocesie s tworzone tak e tr zy inne, niewypenione, produkty zarzdcze, goto- u ycia w trakcie projektu. S we do to: Rejestr Jakoci; Rejestr Zagadnie; Rejestr Dowiadcze. Innym wymaganym produktem tego (nastpnego). ment pochodzi z Zar dzanie procesu koniec Etapu pod Etapuz inicjowania. procesu jest Plan Etapu Ten dokuZakresem (ZE), ktry jest uruchamiany
(Managing Stage Boundaries SB)

2.5.4.

Zarz dzanie Zakresem Etapu (ZE)

Proces dostarcza informacji, na podstawie ktrych Komitet Sterujcy bdzie podejmowa kluczowe decyzje o ty m, czy kontynuowa projekt, czy nie. Celem tego procesu jest: wykazanie Komitetowi Sterujcemu, e wszystkie produkty zaplanowane do wykonania w Planie (bie cego) Etapu zostay wykonane zgodnie z nim; dostarczenie informacji potrzebnych Komitetowi Sterujcemu do oceny dalszej zasadnoci projektu; dostarczenie Komitetowi Sterujcemu wszelkich innych informacji potrzebnych do zatwierdzenia zakoczenia bie cego etapu i wydania zezwolenia na rozpoczcie etapu wraz ze wskazaniem wartoci nastpnego tolerancji; rejestracja wynikw lub dowiadcze, ktr e mog by pomocne w nastpnych etapach projektu i/lub w innych projektach. Produktami procesu s: Raport Kocowy Etapu, przekazywany Komitetowi Sterujcemu przez Kierownika Projektu, zawierajcy informacje o osigniciach etapu; aktualne dane o realizacji Planu Etapu (bie cego), pokazujce osignite rezultaty odniesione do pierwotnego Planu Etapu; propozycja Planu Etapu lub Planu Nadzwyczajnego, ktr (nastpnego) przedstawia si do akceptacji; skorygowany Plan Projektu; uaktualniony Rejestr ktry wraz z Uzasadnieniem Biznesowym i Ryzyka, jest wykorzystywanyPlanem Ko mitet Sterujcy podczas oceny Projektu przez zasadnoci kontynuowania projektu; uaktualnione Uzasadnienie Biznesowe; Rejestr Dowiadcze, uaktualniony zapisami wszelkich dowiadcze koczcego si etapu; wszelkie propozycje zmian struktury lub obsady zespou zarzdzania projektem. 15

AN INTRODUCTION TO PRINCE2

PRINCE2

W trakcie planowania kolejnego etapu mog by rwnie opracowane Plany Zespow, pomc w zdefiniowaniu pr ac, ktre maj by wykonane w czasie tego o ile mog etapu. Tworzenie Planw Zespow nie jest obowizkowe.

2.5.5.

Sterowanie Etapem (SE)

(Controlling a Stage CS)

Projekt mo e mie wiele etapw. Proces ten obejmuje dziaania Kierownika Projektu, monitorowania i sterowania, zwizane z przydzielaniem zada, dotyczce zagwaranto-etap przebiega zgodnie z planem, oraz reagowaniem na nieoczekiwane waniem, e zdarzenia. Proces obejmujc bie ce zarzdzanie projektem, jest istot pracy Kierownika Projektu. W trakcie etapu wystpuje cykl dziaa, na ktry skadaj si: udzielanie zgody na wykonanie prac; zbieranie informacji o postpach; ledzenie zmian; przegldanie stanu etapu; raportowanie ; podejmowanie koniecznych dziaa kor ygujcych. Ten proces obejmuje powy sze dziaania wraz z cigymi pracami zwizanymi z zarzdzaniem ryzykiem i zagadnieniami projektowymi. Produktami procesu powstajcymi trakcie etapu cyklicznie w s: Grupy Zada; Raporty Okresowe - regularne krtkie sprawozdania Kierownika Projektu z post- prac, pw przedstawiane Komitetowi Sterujcemu; Zagadnienia Projektowe (wraz z uaktualnionym Rejestrem Zagadnie); uaktualniony Rejestr Ryzyka; regularnie uaktualniany Plan Etapu. Mo e tak e zaistnie potrzeba opracowania Raportu o Istotnych Odchyleniach.

2.5.6.

Zarz dzanie Wytwarzaniem Produktw (WP)

(Managing Product Delivery MP)

Celem tego pr ocesu jest zagwarantowanie, e zaplanowane produkty s wytwarzane i dostarczane przez projekt, poprzez: negocjowanie przez Kierownika Zespou z Kierownikiem Projektu szczegw Grup Zada; upewnienie si, e przydzielona zespoowi praca nad produktami zostaa faktycznie uzgodniona i wydano zgod na jej wykonanie; zagwarantowanie, e praca spenia okrelone w Grupie Zada wymagania dotyczce punktw styku z otoczeniem; upewnienie si, e praca zostaa wykonana;

16

PRINCE2

WPROWADZENIE DO PRINCE2

regularne ocenianie postpw prac i ich prognoz; upewnienie si, e wykonane produkty speniaj kryteria jakoci; uzyskanie zatwierdzenia dla wykonanych produktw. Produkty wytworzone lub uaktualniane w ramach tego procesu to: Plany Zespow; uaktualnienia Rejestru dajce Kierownikowi Projektu obraz realizacji Jakoci, prac dotyczcych jakoci; Zagadnienia Projektowe; uaktualnienia Rejestru Ryzyka; Raporty z Punktw Kontrolnych - regularne raporty o postpach prac, przekazy- Zespow. wane Kierownikowi Projektu przez Kierownikw Zamykanie Projektu (ZP)
(Closing a Project CP)

2.5.7.

Celem pr ocesu jest kontrolowane zamknicie projektu. Proces obejmuje prace wykonywane przez Kierownika Projektu w zwizku z zamykaniem projektu: albo w momencie osignicia zaplanowanego koca prac projektu, albo w momencie przedwczesnego jego zamknicia. Wikszo tych prac ma na celu przygotowanie materiaw dla Komitetu Sterujcego w celu uzyskania potwierdzenia, e rojekt p mo e zosta zamknity. Z tego wanie powodu cele procesu Zamykanie (ZP) s Projektu nastpujce: sprawdzenie, w jakim stopniu zadania lub cele, ustanowione w Dokumencie I nicjujcym Projekt, zostay zrealizowane; ocena, w jakim zakresie wszystkie oczekiwane produkty zostay przekazane i zaakceptowane przez ; klienta potwierdzenie, e uzgodniono rozwizania dotyczce utrzymania i eksploatacji (je- jest to waciwe), wcznie z odpowiednimi li szkoleniami; przygotowanie zalece w sprawie przyszych prac (Zalecenia Dziaa Nastp- ; czych) zebranie dowiadcze z projektu i przygotowanie Raportu o Dowiadczeniach; przygotowanie Raportu Kocowego Projektu; archiwizowanie dokumentacji projektu; przygotowanie Planu Przegldu Poprojektowego; przygotowanie dla Komitetu Sterujcego pisma powiadamiajcego organizacj, dla ktrej projekt jest wykonywany, o zamiarze rozwizania zespou projektowego zasobw (Powiadomienie o zamykaniu i zwolnienia \r "zamknieprojektu). cie_projektu"

17

AN INTRODUCTION TO PRINCE2

PRINCE2

2.5.8.

Planowanie (PL)

(Planning PL)

Planowani (PL) jest procesem powtarzalnym i odgrywa wa n rol w innych e procesach, a gwnie w nastpujcych: Planowanie Etapu (PP6) ; Inicjowania Planowanie (IP2) ; Projektu Planowanie (ZE1) ; Etapu Uaktualnienie Planu (ZE2) ; Projektu Przyjmowanie Grupy do (WP1) ; Zada Wykonania Opracowanie Planu (ZE6) . Nadzwyczajnego Oprcz planu, produktami procesu s: Lista Kontrolna Produktw, czyli tabela zawierajca spis wszystkich produktw, by wytworzone w wyn iku zaplanowanych prac, z miejscem na ktre maj plano- i faktyczne daty przekazania produktw, przegldw jakoci oraz wane zatwierdzenia produktw; uaktualniony Rejestr Ryzyka, z odnotowanymi wszelkimi zmianami stanu ryzyka, wynikajcymi z rezultatw pr ac planistycznych.

2.6.

Komponenty

Ka dy z komponentw jest dokadniej opisany w Komponenty 2 , pokazujcej, czci jak konkretny komponent wpywa na zarzdzanie projektem i dostarczajcej wskazwek, kiedy i jak nale y si do tych kwestii odwoywa.
Uzasadnienie biznesowe Istnienie opacalnego uzasadnienia biznesowego jest najwa niejszym warunkiem sterujcym dla projektu zarzdzanego wedug PRINCE2. Uzasadnienie biznesowe jest weryfikowane przez Komitet Sterujcy przed rozpoczciem projektu oraz w ka dym wa niejszym punkcie decyzyjnym w trakcie jego realizacji. Projekt powinien by przerwany, je eli z jakichkolwiek powodw uzasadnienie biznesowe przestao by realne.

Organizacja

PRINCE2 okrela struktur zespou zarzdzania projektem oraz zakresy obowizkw i relacje midzy wszystkimi rolami wystpujcymi w projekcie. W zale noci od wielkoci i zo onoci projektu, role te mog by czone przez jedn osob lub przydzielone kilku osobom. PRINCE2 proponuje szereg poziomw planw, ktre mog by dopasowane do wielkoci i potrzeb projektu, oraz podejcie do planowania oparte w wikszym stopniu na produktach ni na dziaaniach.

Plany

Rozdziay 12 do 20 przypis tumacza.

18

PRINCE2

WPROWADZENIE DO PRINCE2

Elementy sterowania

PRINCE2 zapewnia zestaw elementw sterowania, ktre uatwiaj dopyw informacji niezbdnych do podejmowania kluczowych decyzji, pozwalajc organizacji uprzedza ewentualne problemy i podejmowa decyzje su ce rozwizywaniu problemw. Elementy sterowania dla naczelnego kierownictwa s oparte na koncepcji zarzdzania odchyleniami, to znaczy, e zatwierdza ono plan, a nastpnie pozwala kierownikowi go realizowa a do momentu, w ktrym pojawi si prognoza wystpienia istotnych odchyle od planu. W celu zapewnienia solidnej kontroli zarzdczej projekt jest dzielony na etapy, co jest sposobem okrelenia punktw, w ktrych dokonuje si przegldu projektu i anga uje zasoby. (Stosowanie etapw pomaga rwnie zmniejszy ilo prac, jakie Kierownik Projektu w danej chwili musi szczegowo zaplanowa).

Zarz dzanie ryzykiem

Ryzyko jest gwnym czynnikiem, ktry powinien by brany pod uwag w trakcie ycia projektu. PRINCE2 okrela kluczowe momenty, w ktrych zagro enia powinny by przegldane, zarysowuje sposb podejcia do analizy i zarzdzania ryzykiem oraz ledzi te zagro enia w trakcie wszystkich procesw. PRINCE2 uznaje znaczenie jakoci i zawiera nastawione na jako podejcie do procesw zarzdczych i wytwrczych. Rozpoczyna si ono od okrelenia oczekiwa jakociowych klienta, ktre nastpnie wykorzystuje si, ustalajc standardy i metody kontroli jakoci oraz sprawdzajc ich stosowanie. ledzenie skadnikw produktu kocowego i ich kolejnych wersji nazywa si zarzdzaniem konfiguracj. Dostpnych jest wiele metod zarzdzania konfiguracj. PRINCE2 definiuje niezbdne rozwizania i wymagania informacyjne dla metody zarzdzania konfiguracj oraz sposoby powizania tej metody z innymi komponentami i technikami. PRINCE2 podkrela potrzeb sterowania zmianami. Jest ono realizowane za pomoc techniki Sterowanie zmianami oraz poprzez wyszczeglnienie procesw, w ktrych wychwytuje si zmiany, analizuje je i steruje nimi.

Jako w rodowisku projektu

Zarz dzanie konfiguracj

Sterowanie zmianami

2.7.

Techniki PRINCE2

PRINCE2 oferuje tylko kilka technik, pozostawiajc ich wybr u ytkownikom metody- nie od warunkw projektu. Jednak w celu wsparcia prezentowanej ki, zale metodyki, podrcznik przedstawia szczegy trzech technik: Planowanie oparte na niniejszy produktach, Sterowanie zmianami or az Przegld jakoci. PRINCE2 umo liwia rozpoczcie prac planistycznych w oparciu o produkty. Wprowa- struktur planowania, ktr mo na zastosowa w projektach dowolnego dza tak e typu. Obejmuje ona: ustalenie, jakie produkty s wymagane; okrelenie wygldu (formatu) i zawar toci ka dego produktu; ustalenie kolejnoci, w jakiej poszczeglne produkty powinny by wytworzone.

19

AN INTRODUCTION TO PRINCE2

PRINCE2

W ramach techniki Planowanie oparte na definiuje si tak e produktach standardy jakoci, ktrym powinien odpowiada ka dy z produktw. Ka dy projekt wymaga techniki su cej do sterowania zmianami. Or ganizacjom, ktre dotychczas nie posiadaj odpowiedniej techniki, PRINCE2 proponuje technik Sterowanie zmianami. PRINCE2 opisuje tak e specyficzn technik Przegld , ktra jest jakoci szczeglnie odpowiednia do testowania jakoci produktw bdcych dokumentami, cho jej zasady by stosowane do wszelkich form testowania i przegldw mog jakoci.

2.8.

Powi zania procesw i komponentw

Czsto trudno jest pocztkujcym u ytkownikom PRINCE2 zrozumie gwne relacje i zwizki midzy procesami, komponentami i technikami. Ch odzi gwnie o odpowiedzi na nastpujce pytania: W ktrych procesach s wykorzystywane komponenty?, Gdzie jest stosowana dana technika?. 2.6 Rysunek obrazuje te powizania.

20

PRINCE2

WPROWADZENIE DO PRINCE2

Elementy Sterowania

Przygotowanie Projektu

Jako w rodowisku projektu Zarz dzanie ryzykiem Organizacja Uzasadnienie biznesowe

Inicjowanie Projektu

Plany Jako w rodowisku projektu Zarz dzanie ryzykiem Uzasadnienie biznesowe Elementy sterowania Zarz dzanie konfiguracj Sterowanie zmianami

Sterowanie Etapem

Elementy sterowania Sterowanie zmianami Zarz dzanie konfiguracj Uzasadnienie biznesowe

Przegl d jako ci

Sterowanie zmianami

Zarz dzanie ryzykiem Jako w rodowisku projektu

Sterowanie zmianami Jako w rodowisku projektu

Zarz dzanie W ytwarzaniem Produktw

Elementy sterowania Plany Zarz dzanie ryzykiem

Zarz dzanie Zakresem Etapu

Plany Jako w rodowisku projektu Uzasadnienie biznesowe Zarz dzanie ryzykiem Elementy sterowania Organizacja

Zamykanie Projektu
Legenda = Techniki = Komponenty = Procesy

Elementy sterowania Zarz dzanie konfiguracj Uzasadnienie biznesowe Zarz dzanie ryzykiem Sterowanie zamianami

Planowanie oparte na produktach

Rysunek 2.6. procesach

U ycie komponentw i technik metodyki PRINCE2 w

21

3.
3.1.

W PR OWAD ZE NI E DO P R OCE S W

Poziomy zarz

dzania

Zarzdzanie projektem rzadko jest wystarczajco oczywiste, by by prosty m, liniowym W kontekcie PRINCE2 wyr nia si cztery poziomy zarzdzania, ktre procesem. na- wzi pod uwag ( patrz Rysunek 3.1). le y
dzanie Zarz dzanie Zarz firm firm lub programem lub programem

dzanie Zarz dzanie Zarz Strategiczne Strategiczne Projektem Projektem

Sterowanie Sterowanie Etapem Etapem

dzanie Zarz dzanie Zarz Wytwarzaniem Wytwarzaniem Produktw Produktw

Rysunek 3.1. zarzdzania

Cztery

poziomy

Te poziomy zarzdzania maj odbicie w modelu procesowym PRINCE2. Na najwy szym poziomie przedstawiono zarzdzanie firm lub programem. Cho nie jest on czci metodyki zarzdzania projektami jako takiego, ten wysoki po- zarzdzania jest istotny, poniewa czsto ustala kontekst biznesowy dla ziom jednego lub wielu projektw. W samym projekcie najwy szym poziomem zarzdzania jest Zarzdzanie Strategiczne (zadanie Komitetu Sterujcego). Jest to poziom Projektem podejmowania kluczowych decyzji i wyznaczania kier unkw dziaania. Na nastpnym poziomie, jakim jest Sterowanie Etapem, du o wysiku zarzdczego pochania codzienne planowanie oraz sterowanie realizacj. Zajmuje si tym gwnie Kierownik Projektu. Najni szy poziom zarzdzania to Zarzdzanie Wytwarzaniem Produktw, realizowane przez Kierownikw Zespow.

23

INTRODUCTION TO PROCESSES

PRINCE2

Istniej dwa gwne sposoby wzajemnego oddziaywania tych poziomw. Procesy wy szego poziomu steruj procesami poziomu ni szego. Na przykad w Sterowaniu Etapem powstaj Grupy Zada, ktre okrelaj zakres prac dla Zarzdzania Wytwarzaniem Produktw. Produkty procesw ni szego poziomu stanowi wejcia, ktre umo liwiaj proce-wy szego poziomu efektywny przebieg. Na przykad Sterowanie Etapem som dostarcza istotnych informacji planistycznych i kontrolnych, umo liwiajcych efek- prowadzenie dziaa Zarzdzania Strategicznego Pr tywne ojektem.

3.2.

Struktura opisu procesw

Ka dy z procesw PRINCE2 opisano stosujc nastpujcy format i struktur .

3.2.1.

Podstawowe zasady

Pod tym nagwkiem rozwa ane s nastpujce pytania: Dlaczego wprowadzono ten proces? Co zamierza si osign za jego pomoc w kategoriach zarzdzania projektem? Dlaczego ten proces ma fundamentalne znaczenie dla dobrego zarzdzania projek-i stanowi minimum wymaga tem PRINCE2? Kontekst

3.2.2.

W tak zatytuowanych podrozdziaach opisuje si ka dy z procesw w kontekcie in- procesw oraz dziaa przebiegajcych poza zakresem PRINCE2. Ka dy z nych opisw kontekstowych wspomagany jest diagramem kontekstowym, pokazujcym podstawoweinformacji wchodzce do procesu i wychodzce z strumienie niego.

3.2.3.

Opis procesu

Podrozdziay tak zatytuowane opisuj proces poprzez wyjanienie jego celw oraz 3 sposobu, w jaki proces realizuje podstawowe . Tu opisane s kroki zasady postpowania podczas realizacji procesu. Nie prbowano nawet uo y tych krokw w cile okrelonej kolejnoci, gdy taka sztywna i niezmienna kolejno rzadko wystpuje. Jednak e zostay one wymienione liwie w mo logicznej kolejnoci.

3.2.4.

Skalowalno

Ka dy projekt realizowany wedug PRINCE2 musi u y w jakiej formie wszystkich procesw metodyki. Jednak kluczem do po mylnego stosowania PRINCE2 jest jej dostosowanie 4 . W odniesieniu do ka dego procesu nale y zada pytanie: W jakim stopniu ten proces powinien by zastosowany w tym projekcie?.
3 4

Zarzdzania projektami przypis tumacza. Do wymogw konkretnego projektu przypis tumacza.

24

PRINCE2

WPROWADZENIE DO PROCESW

Dla ka dego z gwnych procesw PRINCE2 umieszczono podrozdzia opisujcy wymagajce rozwa enia podczas dostosowywania procesu, by odpowiada czynniki on potrzebom projektu.

3.2.5.

Odpowiedzialno

W tych podrozdziaach wskazano, kto powinien by odpowiedzialny za pomylny prze- procesu i do czyich obowizkw powinno nale e zarzdzanie nim. Dotyczy bieg to jedynie podprocesw, bo to na tym poziomie decyduje si o zakresie obowizkw. Wymagania informacyjne Te podrozdziay zawieraj tabele z wa nymi informacjami wymaganymi dla podprocesu, aby mg on funkcjonowa i osiga swoje cele. Niektre z tych informacji, jak pla- i raporty, bd produktami, inne bd miay charakter ny decyzji. Kryt eria oceny ci jako W tych podrozdziaach uwypukla si gwne zagadnienia, od ktrych bdzie zale a ostateczny sukces lub niepowodzenie procesu.

3.2.6.

3.2.7.

3.2.8.

Wskazwki i rady

Podrozdziay tak zatytuowane dostarczaj porad na temat stosowania PRI NCE2 w konkretnych warunkach oraz wskazuj, w jaki sposb PRINCE2 mo e by zastoso- praktyce. Nie oczekuje si, e bd one definitywnym przewodnikiem. wana w Zaleca si, by te podrozdziay byy wsparte wykorzystaniem najlepszych praktyk i sposobw waciwego dla ka dego rodowiska projektowego, ktre stosuje PRI podejcia NCE2. ze swojej natury s bardzo zr nicowane. rodowiska, w ktrych Projekty funkcjonuj, rwnie bardzo si r n. Procesy PRINCE2 okrelaj oczekiwane wymagania dla ogromnej wikszoci projektw w wikszoci rodowisk.

3.3.

Symbole u yte w tek

cie i diagramach

Poni sze symbole s u ywane w r nych typach diagramw, znajdujcych si w rozdziaach powiconych procesom.
Repozytorium (miejsce przechowywania) dla wszystkich tworzonych produktw zarzdczych, ktre mog by u ywane w kilku innych procesach. Dokumentacja Zarz dcza

Symbol oznaczajcy archiwizowanie dokumentacji projektowej.

Oznaczenie osb lub gremiw innych ni role zdefiniowane przez metodyk PRINCE2, takich np. jak kierownictwo firmy lub programu.

25

4.
Stworzenie zespou Stworzenie zespou cego dzaj zarz cego dzaj zarz projektem projektem Zdefiniowanie Zdefiniowanie celw projektu celw projektu

P RZY GOTOWA NI E P ROJ E KTU ( PP )

(STARTING UP A PROJECT - SU)

Ustalenie sposobu, Ustalenie sposobu, w jaki uzyska si w jaki uzyska si zanie rozwi zanie rozwi

Zarys Zarys Uzasadnienia Biznesowego Uzasadnienia Biznesowego (ryzyka) i zagro e (ryzyka) i zagro e

Planowanie prac wymaganych Planowanie prac wymaganych do przygotowania Planu Projektu oraz do przygotowania Planu Projektu oraz Elementw sterowania Elementw sterowania Komitetu i uzyskania zezwolenia i uzyskania zezwolenia Komitetu cie cego na projektu Steruj rozpocz cie cego na projektu Steruj rozpocz

Rysunek 4.1. Projektu

Zarys procesu Przygotowanie

4.1.

Podstawowe zasady

Aby uruchomi prace zmierzajce do przygotowania projektu, musi wystpi istotna potrzeba biznesowa. Co wicej, zanim rozpoczn si jakiekolwiek prace lub za- uje si zasoby, nale y odpowiedzie na podstawowe pytanie: Czy mamy anga zasadny i wart zaanga owania projekt?. Na to pytanie trzeba odpowiedzie rzetelnie, by upewni si, e zaanga owane zasoby nie zostan zmarnowane. W projekcie niczego nie mo na rozpoczyna, zanim nie zostan okrelone obo- i obsadzone kluczowe role. Kto musi wystartowa projekt i wizki podj pierwsze decyzje. Do podjcia racjonalnej decyzji o zezwoleniu na r ealizacj projektu potrzebne s pewne podstawowe infor macje.

27

STARTING UP A PROJECT (SU)

PRINCE2

Przed rozpoczciem Etapu inicjowania, Plan Etapu inicjowania musi by przedoony do zatwierdzenia.

4.2.

Kontekst

Jest to pierwszy proces w ramach PRINCE2. Projekt rozpocznie si dopiero po wyko- tego procesu i zezwoleniu przez Komitet Sterujcy na rozpoczcie naniu zainicjowania kategoriach procesw prowadzi on do uruchomienia projektu. W Zezwole podprocesu nie na Zainicjowanie (ZS1). Projektu Projekt mo na identyfikowa na wiele sposobw, a zatem infor macje dostpne dla ze- zarzdzania projektem w czasie przygotowywania projektu mog by bardzo r spou - e. Czynnikiem uruchamiajcym proces jest Zlecenie Przygotowania n Jest ono Projektu. wystawiane przez kierownictwo firmy lub programu. Dopuszcza si, zazwyczaj aby Zlecenie Przygotowania Projektu miao dowoln form, poczwszy od ustnego polecenia, a po kompletne Zao enia Projektu. Proces zakada istnienie informacji wyjaniajcych powody, dla ktrych projekt ma by realizowany, oraz opisujcych oczekiwany wynik projektu. Temu zbiorowi infor macji nazw Zlecenie Przygotowania Projektu, by unikn mylenia z bardziej nadano rygory- okrelonymi zbiorami informacji wytwar zanych w ramach PRINCE2. stycznie Proces Przygotowanie (PP) w odniesieniu do czasu trwania caego projektu Projektu powinien trwa krtko.

Z le c en i e Prz yg o to w a n i a j e kt u Pro

PP Przygotowanie Projektu
PP1 Mi a n ow a n i e zew o d n i c z c e g o Pr i K i er o w n i ka o je k tu Pr PP2 O rg a n iz o w an i e es p o Z u ar z dz an i Z Pro j e a m kte PP3 Mi a n o w an i e z o n k C w es p o Z u ar z d za ni Z Pr o je a tem k

Z S1ezw o le n i e n Z a ai n i cj o w a n Z ie oj e k tu Pr

PP4 Pr zyg o to w a n i e Z a o e Pr o je k tu

PP 5 O k rel e n ie F o rm u y ea l iz ac j i R Pr o j ek tu

PP6 Pl a n ow an i e Eta p u I n ic j o w an i a

PL Pl a no w a n i e

Rysunek Projektu

4.2.

Przygotowanie

28

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

4.3.

Opis procesu

Prace objte procesem s skoncentrowane wok wykonania siedmiu elementw: zorganizowanie i mianowanie zespou zarzdzania ; projektem zapewnienie, e informacje wymagane dla opracowania Zao e Projektu s dostpne; ustalenie Formuy Realizacji Projektu; ustalenie jakociowych oczekiwa klienta; przygotowanie zarysu Uzasadnienia Biznesowego; zao enie Rejestru Ryzyka; opracowanie Planu Etapu inicjowania. Celem procesu jest umo liwienie kontrolowanego startu (rozpoczcia) projektu poprzez zapewnienie, e: istniej wszystkie wadze projektu, konieczne do jego rozpoczcia; s dostpne wystarczajce informacje potrzebne do sformalizowania warunkw odniesienia dla projektu; wyznaczone s osoby, ktre podejm prace potrzebne podczas Etapu inicjowania projektu i/lub obejm w nim wa ne role kier ownicze; prace potrzebne do zainicjowania projektu zostay zaplanowane; organizacja, w ktrej bdzie dziaa zesp projektowy, jest poinformowana o istnieniu nowego projektu i wynikajcych z niego implikacjach. Proces rozpoczyna si od otrzymania z zewntrznego rda opisu problemu lub okazji, projekt musi odpowiednio r ozwiza lub wykorzysta. Nazwa Zlecenie ktre Przygo- Projektu jest u ywana na okrelenie dowolnej informacji, ktra wyzwala towania dzia- zwizane z projektem i ktra mo e stanowi zarwno studium wykonalnoci, ania jak i odrczn notatk na kawaku papieru. Im jako informacji zawartych w Zleceniu Przygotowania Projektu bdzie bli sza wzorcowi opisanemu w zarysie Opisu Produktu dla Zlecenia Przygotowania Projektu (patrz: Dodatek A), tym atwiejszy bdzie proces Przygotowanie (PP). Projektu Dodatkowym elementem, ktry pomo e zarwno w przygotowaniu Planu Etapu inicjo- ,jak i Planu Projektu jest Formua Realizacji Projektu, objaniajca sposb, w wania jaki si zamierza wytworzy kocowe produkty. Gdy projekt jest czci programu, to program powinien dostarczy Zao enia Pr ojektu i Formu Realizacji Projektu oraz wyznaczy niektrych, je eli nie wszystkich, czon- Komitetu Sterujcego, eliminujc tym samym znaczn cz prac kw wymaganych w tym procesie. Mimo e model procesu wskazuje na dwie rwnolege grupy podprocesw, jedn zwi- z organizowaniem zespou zarzdzania projektem ( PP2 i PP3), a drug zan zwizan z uzgodnieniem wymaga dla projektu oraz Formuy Realizacji Projektu (PP4 i PP5), to praktyce wystpi du a wspzale no midzy tymi dwoma obszarami pracy. w Wa-

29

STARTING UP A PROJECT (SU)

PRINCE2

runkuje j wiedza o naturze przedsiwziecia oraz poziom uzgodnie dotyczcych struk- i skadu zespou zarzdzania tury projektem. Or ganizacja, w ktrej bd prowadzone prace, jest informowana o zbli ajcym si projekcie oraz zgaszane s do niej proby o odpowiednie wsparcie logistyczne potrzebne zainicjowania do projektu.

4.3.1.

Skalowalno

R ne sposoby podejcia stosowane do tego procesu nale zwykle do trzech kategorii: projekt jest przedsiwziciem samodzielnym i bd realizowane wszystkie kroki tego procesu. W takiej sytuacji nie ma wikszego problemu z tym, ktre kroki naley wykona; projekt jest czci programu. Program przekaza dokumentacj, ktra stanowi kompletne Zao enia Projektu, albo nawet Dokument Inicjujcy Pr Skad ojekt. Komitetu Sterujcego mo e ju by okrelony, a Formua Realizacji Projektu Ryzyka s zarzdzane na poziomie programu. Innymi sowy, caa i Rejestr praca zwizana z Przygotowaniem (PP) i wikszo dziaa inicjujcych Projektu s ju wykonane. W takim przypadkuprojekt zadaniem tego procesu jest jedynie spraw- czy trzeba wykona jakie dodatkowe prace zwizane z produktami dzenie, przygotowawczymi oraz czy dostarczone informacje s nadal prawidowe i aktualne; trzeci mo liwoci jest bardzo may projekt. W takich przypadkach proces mo e y prowadzony w sposb niesformalizowany, mo liwe e zajmie on kilka b minut. Kierownik Projektu powinien wystrzega si jednak pokusy, aby pomin ten pro-cakowicie. ces

Wskazwki i rady
Nie zawsze bdzie waciwe lub mo liwe wyznaczenie caego zespou zarzdzania projektem przed rozpoczciem Etapu inicjowania. Jednak powinni zosta wyznaczeni przynajmniej Przewodniczcy i Kierownik Projektu, tak aby mo na byo przygotowa wkad w inicjowanie i podj niezbdne decyzje. Nale y przejrze Raporty o Dowiadczeniach z podobnych projektw, by wykorzysta zawarte tam informacje do przygotowania Zao e Projektu i jego realizacji. Jeli Formua Realizacji Projektu nie zostaa okrelona w Zleceniu Przygotowania Projektu bd oka e si trudna do okrelenia, nale y zastanowi si, czy nie nale y ukierunkowa projektu na przygotowanie studium wykonalnoci, ktre okreli odpowiedni Formu Realizacji Projektu. Po przygotowaniu, studium wykonalnoci stanowi bdzie doskonae Zlecenie Przygotowania Projektu dla gwnego projektu.

30

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

4.4.

Mianowanie Przewodnicz (PP1)

cego i Kierownika Projektu

Kierownictwo firmy lub programu

Zlecenie Przygotowania Projektu

PP1 M ianowanie Przewodnicz i Kierownika Projektu

cego

Uzgodniony zakres obowi zk w Przewodnicz cego

Uzgodniony zakres obowi zk w Kierownika Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 4.3. Projektu

Mianowanie Przewodniczcego i Kierownika

4.4.1.

Podstawowe zasady zrealizowa w projekcie, niezbdnych potrzeba decydenta i kogo, kto

Aby cokolwiek rozpocznie planowanie dziaa.

4.4.2.

Kontekst

Zanim bdzie mo na r ozpocz inicjowanie projektu, musi powsta plan prac inicjuj- Mianowanie Przewodniczcego i Kierownika Projektu jest warunkiem cych. wstpnym rozpoczcia tych prac.

4.4.3.

Opis procesu

Podproces ma na celu: wskazanie Przewodniczcego spord interesariuszy projektu; wskazanie Kierownika najbardziej odpowiedniego dla danego Projektu projektu; potwierdzenie dostpnoci wybranych osb, uzyskanie akceptacji na penienie przez nich tych rl oraz na zaanga owanie si w ich wypenienie; mianowanie wybranych osb do penienia uzgodnionych rl. Warunkiem wstpnym pierwszego podprocesu jest istnienie i dostpno Zlecenia Przygotowania Poniewa proces poprzedza cay projekt, jego przebieg mo Projektu. e

31

STARTING UP A PROJECT (SU)

PRINCE2

by bardzo r ny w zale noci od jakoci informacji zawartych w Zleceniu Przygotowania Projektu. W tym podprocesie wystpi nastpujce kroki: potwierdzi kluczowe elementy Zlecenia Przygotowania Projektu; uzupeni brakujce informacje; wytypowa kandydatw do rl Przewodniczcego i Kierownika Projektu; ustali obowizki dla ka dej z ; rl mianowa Przewodniczcego; mianowa Kierownika Projektu; uzgodnienie nominacji poprzez zaaprobowanie zakresw obowizkw zarwnokierownictwo firmy lub programu oraz osoby przez nominowane. Zlecenie Przygotowania Projektu powinno oglnie wskazywa rodzaj projektu, jego wielko, zo ono oraz wra liwo na zmiany polityczne i biznesowe. Te infor macje pomocne w przedstawieniu waciwych kandydatw do roli Kierownika bd Projektu. Zlecenie Przygotowania Projektu mo e zawiera zarys Planu wynikajcy Projektu, z wczeniejszych prac. Mo e to da wyobra enie o ramach czasowych projektu, co jest u yteczne przy potwierdzaniu dostpnoci osb do penienia wspomnianych wy ej rl. Zarysy opisw rl Przewodniczcego i Kierownika Projektu, zawarte w Dodatku Rol B w zespole dzania , powinny su y jako podstawa do dyskusji e zarz Przewodniczcym projektem a Kierownikiem midzy w sprawie dopasowania i uzgodnienia Projektu ich rl.

4.4.4.

Odpowiedzialno

Odpowiedzialno za ten podproces spoczywa na kierownictwie firmy lub programu.

4.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu

Tabela 4.1. PP1

Informacja Objanienie

zarzdcza

Wykorzystanie

Zlecenie Przygotowania Projektu Wejcie/Uaktualnienie Impuls wyzwalajcy projekt. Uzgodnione zakresy obowizkw Przewodniczcego i Kierownika Projektu Mianowanie Przewodniczcego i Kierownika Projektu Wyjcie Podstawa do przyjcia funkcji przez Przewodniczcego i Kierownika Projektu. Wyjcie Uzgodnione zakresy obowizkw.

32

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

4.4.6.

Kryt eria oceny ci jako Je eli projekt jest czci programu, czy kierownictwo programu bdzie peni jakie role w Komitecie Sterujcym? Czy osoba zaproponowana na Przewodniczcego posiada uprawnienia w zakresie i funkcjonalnym, konieczne do nale ytego wspier ania pr finansw ojektu? Czy sprawdzono dostpno potrzebnych osb w przewidywanym czasie trwania by zagwarantowa, e bd one dostpne dla projektu tak dugo, jak projektu, jest to wymagane? Czy jest prawdopodobne, e kandydaci do rl zmieni w najbli szej przyszoci prac, co wyczyoby ich z projektu? Je eli tak, to czy wzito t informacj pod uwag, dokonujc nominacji? Czy mianowane osoby posiadaj umiejtnoci i wiedz potrzebne do podjcia swoich zada?

Wskazwki i rady
Wwczas gdy wielko lub znaczenie projektu to usprawiedliwiaj, uzgodnione opisy zakresw obowizkw powinny by potwierdzone przez osob lub osoby przyjmujce role, a tam, gdzie to ma uzasadnienie, rwnie przez ich kierownictwo liniowe. Powinny by one w posiadaniu zainteresowanych osb, a podpisane kopie nale y przechowywa w dokumentacji projektu. Dla projektw maych lub obarczonych niewielkim ryzykiem przygotowywanie formalnych opisw zakresw obowizkw mo e nie by waciwe, niemniej jednak osoby zainteresowane powinny przeczyta i zrozumie zakresy obowizkw zawarte w opisach rl. Jeli projekt jest czci programu, kierownictwo programu wyznaczy Przewodniczcego oraz mo e wpyn na mianowanie Kierownika Projektu. Mianowanie pozostaych czonkw Komitetu Sterujcego mo e by pozostawione Przewodniczcemu.

4.5.
4.5.1.

Organizowanie Zespou Zarz

Podstawowe zasady

dzania Projektem (PP2)

Do terminowego podejmowania decyzji w projekcie potrzebni s waciwi ludzie, posiadajcy odpowiedni wadz, obowizki i wiedz. Zesp zarzdzania projektem musi odzwierciedla interesy wszystkich stron, bd w ktre uczestniczyy, w tym interesy biznesu, u ytkownika i nim dostawcy. Zarzdzanie projektem wymaga zasobw i okrelonego zestawu umiejtnoci, kt-powinny by dostpne w zespole zarzdzania pr re ojektem.

33

STARTING UP A PROJECT (SU)

PRINCE2

Wa ne jest, by powici wystarczajco du o uwagi wszystkim dziaaniom zwi- z zarzdzaniem projektem, tak aby aden z istotnych aspektw nie zanym zosta przeoczony. Wa ne jest tak e zapewnienie dostpnoci wszystkich umiejtnoci do realizacji projektu. Wszystkie role okrelone w potrzebnych komponencie musz by w jaki sposb wypeniane w ka dym Organizacj a projekcie. Kontekst

4.5.2.

Po wytypowaniu Przewodniczcego i Kierownika Projektu kolejn czynnoci jest przeanalizowanie wielkoci projektu, jego zo onoci oraz obszarw, na ktre wpywa rezultat projektu, a nastpnie na tej podstawie zorganizowanie zespou kocowy zarzdzania projektem z waciw reprezentacj u dostawcy oraz ytkownika, Wsparciem Projektu. W praktyce jest normalne, e ten podproces wraz z nastpnym Mianowanie Czonkw Zespou dzania (PP3) - bd si w znacznym stopniu Zarz Projektem nakaday.
Kierownictwo firmy lub programu

Zlecenie Przygotowania Projektu

Zakres obowi zkw Przewodnicz cego i Kierownika Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Struktura zespou zarz dzania projektem

PP2 Organizowanie Zespou Zarz dzania Projektem

Propozycje zakresw obowi zkw

PP3 Mianowanie Czonkw Zespou Zarz dzania Projektem

Rysunek 4.4. Projektem

Organizowanie

Zespou

Zarzdzania

4.5.3.

Opis procesu

Podproces ma na celu: zaprojektowanie struktury zespou zarzdzania projektem odpowiedniej do wielko- rodzaju projektu oraz grup, ktrych on ci i dotyczy; wytypowanie kandydatw do penienia ka dej z rl w celu zbudowania rekomendowanego zespou zarzdzania projektem; okrelenie obowizkw i wymaganych umiejtnoci dla ka dej z rl; jeli projekt jest czci progr amu, kierownictwo progr amu ma obowizek ustano- odpowiedniego Komitetu Sterujcego. Jeli tego dokona, wikszej wienia czci tego podprocesu nie trzeba realizowa. Program mo e jednak e pozostawi mia34

PRINCE2 nowanie pozostaej Przewodniczcemu. czci Komitetu

PRZYGOTOWANIE PROJEKTU (PP) Sterujcego wyznaczonemu

Struktura zespou zarzdzania projektem wedug PRINCE2, opisana w komponencie (Rozdzia 14) i w Dodatku B Role Organizacj w zespole dzania a zarz winna by wykorzystana jako podstawa tego podprocesu. Istniej projektemkroki, pewne ktre by wykonane: musz wytypowanie kandydatw do rl w Komitecie Sterujcym i opracowanie opisw obowizkw dla ka dego z nich; zakresw

, po-

ustalenie, czy czonkowie Komitetu Sterujcego zamierzaj delegowa pewne czynnoci zwizane z ich obowizkami nadzoru. Pomo e to Kierownikowi Projektu doradzi, jak zaprojektowa role zwizane z nadzorem, oraz wybra kandydatw do ich penienia. Ta sprawa mo e wymaga ponownego rozwa enia po obsadzeniu pozostaych rl w Komitecie Sterujcym; rozwa enie, czy bd potrzebne odrbne osoby jako Kierownicy czy te Zespow, Kierownik Projektu bdzie peni t rol Ostateczna decyzja w tej osobicie. sprawie nie powinna by podejmowana a do zaplanowania ka dego z etapw; przeanalizowanie opisu roli Kierownika Projektu i zaproponowanie niezbdnej dla tego projektu roli Wsparcia Projektu. Lista kontrolna potencjalnych obowizkw Wsparcia Projektu jest przedstawiona w Dodatku Role w zespole dzani B zarz a projekte ; m przyporzdkowanie nazwisk kandydatw do wszystkich wytypowanych rl. Proponowana organizacja powinna okrela, czy ka da z rl bdzie przydzielona jed-osobie, czy te bdzie peniona przez kilka osb lub poczona z inn rol. nej Na- rwnie okreli czas i nakad pracy potrzebne do penienia danej le y roli; wskazanie, kto powinien zatwierdzi nominacje do zespou zarzdzania projektem w nastpnym podprocesie (PP3). Do zrealizowania tego podprocesu mo e by konieczne wykorzystanie informacji zawartych w Zao eniach Projektu i Formule Realizacji Projektu.

4.5.4.

Odpowiedzialno

Przewodniczcy i Kierownik Projektu odpowiadaj wsplnie za opracowan propozycj. Przewodniczcy ponosi w szczeglnoci odpowiedzialno za propozycj skadu Komitetu Sterujcego.

35

STARTING UP A PROJECT (SU)

PRINCE2

4.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Opisuj uzgodnione zakresy obowizkw w celu uniknicia luk lub zachodzenia ich na siebie.

Tabela 4.2. PP2 Informacja Objanienie

Uzgodnione zakresy obowizkw Przewodniczcego i Kierownika Projektu

Zlecenie Przygotowania Projektu Wejcie Wskazuje prawdopodobne interesy u ytkownika i klienta. Struktura zespou zarzdzania projektem Proponowane opisy zakresw obowizkw pozostaych czonkw zespou zarzdzania projektem Wyjcie Stanowi podstaw do uzgodnie z wytypowanymi osobami i naczelnym kierownictwem. Wyjcie Gotowe do przedyskutowania i zatwierdzenia w podprocesie PP3.

4.5.6.

Kryteria oceny ci jako Czy speniono wymagania, istniejcych u klienta i dostawcy, systemw nadzoru jakoci oraz audytu wewntrznego? Czy projekt organizacji jest adekwatny do przewidywanych cakowitych kosztw, i wagi znaczenia projektu? Czy proponowani czonkowie Komitetu Sterujcego mog si zaanga owawymaganym od nich w stopniu? Czy wszystkie role i obowizki zostay pr zydzielone? Je eli nie, to czy wyczenia s uzasadnione? Czy propozycja przydziela role i obowizki tym osobom, ktre maj wymaganczas i upr awnienia, by je wiedz, wypenia? Czy w zespole zarzdzania projektem s reprezentowani waciwi interesariusze? Jak powinien by zaadaptowany model organizacji PRINCE2, gdy klient lub dostawca u ywaj metod albo technologii, wymagajcych zastosowania specjalnych organizacji modeli oraz kontroli? Czy struktura zespou zarzdzania projektem jest dopasowana do struktury zarz- programem i czy j dzania wspiera? Jeli projekt jest czci programu, to czy powinna istnie reprezentacja programu w Komitecie Sterujcym lub w innych czciach zespou zarzdzania projektem? Czy wszystkie role nadzoru i wsparcia projektu s dopasowane do funkcji oglnego nadzoru i wsparcia programu lub strategii?

36

PRINCE2 Wskazwki i rady

PRZYGOTOWANIE PROJEKTU (PP)

Je eli projekt jest czci programu, kierownictwo programu mo e chcie mianowa wszystkich czonkw Komitetu Sterujcego lub pozostawi to Przewodniczcemu. W tym drugim przypadku Przewodniczcy powinien uzyska od kierownictwa programu potwierdzenie akceptowalnoci swoich propozycji. Nale y rozwa y interesy u ytkownika i su b eksploatacji, na ktre bdzie mia wpyw produkt(-y) projektu, pod ktem ich reprezentacji w Komitecie Sterujcym. Komitet Sterujcy jest organem decyzyjnym, a nie grup dyskusyjn. Z tego powodu nie jest dobrym pomysem pozwoli na nadmierny rozrost Komitetu Sterujcego. W optymalnej sytuacji nie powinien on liczy powy ej 36 osb, nawet dla du ych projektw. Nie zawsze jest mo liwe ograniczenie go do tej wielkoci, ale czsto mo na utworzy na przykad odrbn grup u ytkownikw, ktra wyznaczy jednego ze swoich czonkw, by dziaa w Komitecie Sterujcym jako Gwny U ytkownik. Chocia wa ne jest, aby uwzgldni wszystkie omwione elementy, czsto nie ma mo liwoci zapewnienia kompletnej informacji niezbdnej do dokonania wszystkich nominacji w trakcie przygotowywania projektu, a zatem nieraz wystpi potrzeba uzupenienia niektrych nominacji w trakcie Etapu inicjowania lub na pocztku kolejnego etapu. Zapewnienie waciwej reprezentacji u ytkownikw i/lub klientw podczas testowania jakoci nale y do obowizkw Gwnego U ytkownika. Powinno to by wzite pod uwag, gdy rozwa a si mo liwo delegowania przez Gwnego U ytkownika jego obowizkw dotyczcych nadzoru. Wa ne jest zapewnienie, by nie wystpoway opnienia w acuchu decyzyjnym klienta lub dostawcy, mogce niekorzystnie wpywa na projekt. Powinno to by wzite pod uwag szczeglnie przy obsadzaniu rl w Komitecie Sterujcym. Czonek Komitetu Sterujcego nie powinien delegowa swojej roli. Zwykle prowadzi to do sytuacji takich, e zastpca nie posiada uprawnie niezbdnych do podejmowania potrzebnych decyzji. Tam, gdzie projekt finansuje strona trzecia, mo e si okaza konieczne wiksze zaanga owanie finansujcego w zarzdzanie projektem. Role w Komitecie Sterujcym powinny odzwierciedla ten stan rzeczy, ale powinny tak e podkrela znaczenie roli u ytkownika dla okrelania, co jest potrzebne, a tak e do monitorowania projektu, by zapewni, e rozwizanie zaspokoi te potrzeby. Jeli projekt jest czci programu, omawiany podproces mo e by u yty do zaprojektowania kanaw komunikacyjnych pomidzy projektem a programem. Mo e to oznacza bezporedni obecno reprezentantw programu w zespole zarzdzania projektem. Jeli w tym czasie nie mo na wskaza dostawcy choby ze wzgldu na Formu Realizacji Projektu, ktra zakada procedur przetargow we wczesnych etapach projektu nale y rozwa y przejciowe powierzenie roli Gwnego Dostawcy przedstawicielowi dziau zaopatrzenia lub zakupw. Jeli wystpuje wielu dostawcw np. w du ym projekcie budowlanym - nale y rozway powoanie grupy dostawcw, ktra wybierze swego przedstawiciela do roli Gwnego Dostawcy, by reprezentowa ich punkt widzenia w Komitecie Sterujcym.

37

STARTING UP A PROJECT (SU)

PRINCE2

4.6.

Mianowanie Czonkw Zespou Zarz (PP3)

Podstawowe zasady

dzania Projektem

4.6.1.

Istot dobrze prowadzonego projektu jest, eby ka da osoba zaanga owana w zarzdzanie projektem rozumiaa i akceptowaa: kto odpowiada, przed kim i za co; kto ma obowizki i jakie; jakie s drogi raportowania i komunikacji; role i obowizki powinny by uzgodnione z zainteresowanymi i przez nich zaakceptowane; od momentu dopasowania rl nie powinno by luk w podziale obowizkw; kto powinien by bezspor nie odpowiedzialny za konkretny aspekt zarzdzania. Kontekst

4.6.2.

Przygotowany w podprocesie (PP2) model zespou zarzdzania projektem powinien by w bie cym podprocesie przedyskutowany i uzgodniony z wytypowanymi osobami.
Struktura zespou zarz dzania projektem

Dokumentacja Dokumentacja zarz dcza zarz dcza

Uzgodnione zakresy obowi

zkw

PP3 Mianowanie Czonk w Zespou Zarz dzania Proje ktem

PP2 Organizowanie Zespou Zarz dzania Proje ktem

Propozycja zakresw obowi

zkw

Rysunek 4.5. Projektem

Mianowanie Czonkw Zespou Zarzdzania

4.6.3.

Opis procesu

Podproces ma na celu: mianowanie osb wytypowanych do: Komitetu Sterujcego; Nadzoru Projektu (tam, gdzie jest to waciwe) Wsparcia Projektu (tam, gdzie jest to waciwe); kierowania zespoem (wykonawczym); ;

38

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

zapewnienie, e mianowane osoby rozumiej swoje r ole oraz obowizki zwizane z zarzdzaniem i wspieraniem projektu; zapewnienie, e mianowane osoby aktywnie zaanga uj si w wypenianie swoich rl i obowizkw;

potwierdzenie drg raportowania i ko munikacji oraz doczenie ich do informacji gdy zarzdczej, wpynie to na Plan Komunikacji. Te cele s osigane podczas konsultacji i dyskusji ze wszystkimi zainteresowanymi jest to konieczne, z ich przeo osobami, a je eli onymi. Po ostatecznym uzgodnieniu z czonkami Komitetu Sterujcego ich rl, pomysy doty- delegowania ich obowizkw Nadzoru Projektu mog odbiega od czce pierwotnego modelu zespou zarzdzania projektem. Mo e to prowadzi do jego przemodelowania nominacji lub modyfikacji i kolejnej rundy rl. Ka da definicja roli w PRINCE2 powinna by dostosowana do konkretnego rodowiska i osoby. Osoba, ktrej to dotyczy, powinna podpisa uzgodniony zakres obowizkw.dokumentu powinny by w posiadaniu tej osoby i Kierownika Pr Kopie tego ojektu. W stosunku do osb wyznaczonych do Nadzoru Projektu lub Wsparcia Projektu, Kierownik Projektu powinien upewni si, w jakim stopniu bd one dostpne dla projektu.

4.6.4.

Odpowiedzialno

Za nominacje odpowiada Przewodniczcy, wspierany przez Kierownika Projektu, maj- gos doradczy. W celu okrelenia odpowiedniego personelu i wynegocjowania cego je- dostpnoci, Przewodniczcy musi si kontaktowa z kierownictwem firmy lub go programu.

4.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Okrelenie planowanego rozdziau rl, z poprawkami, jeli byy konieczne. Wejcie Wskazany i zatwierdzony zesp zarzdzania projektem. Wyjcie Role dopasowane do projektu oraz do osb.

Tabela 4.3. PP3 Informacja Objanienie

Struktura zespou zarzdzania projektem Propozycje zakresw obowizkw Uzgodnione zakresy obowizkw

4.6.6.

Kryt eria oceny ci jako Czy ostateczne uzgodnienie opisw rl spowodowao dotychczasowych obowizkw, ktra ma wpyw na obowizki innych osb?

tak

zmian

Czy wszystkie wyznaczone osoby zrozumiay i zaakceptoway przedstawione za- swych obowizkw? kresy

39

STARTING UP A PROJECT (SU)

PRINCE2

Czy wyznaczone osoby maj odpowiednie kwalifikacje do realizacji swych zada? Czy otrzymay waciwe przeszkolenie, aby peni przydzielone role? Czy maj wystarczajco du o czasu, do penienia swoich rl?

Wskazwki i rady
Nale y przemyle, w jaki sposb bd realizowane r ne procesy pomocnicze, takie np. jak zarzdzanie Zagadnieniami Projektowymi. Klient lub dostawca mo e mie ju istniejce wasne Biuro Wsparcia Projektu, z ktrego mo na pozyska cz lub cae ustalone Wsparcie Projektu. Je eli projekt jest czci programu, ktry posiada swoje wsparcie programu, to nale y przemyle, w jaki sposb projekt bdzie wsppracowa z programem.

4.7.
4.7.1.

Prz ygotowanie Zao e

Podstawowe zasady

Projektu (PP4)

Przed przystpieniem do dalszych prac Komitet Ster ujcy musi si upewni, czy projekt jest wart realizacji. Projekt powinien wystartowa, posiadajc wiarygodn definicj wymaga i oczekiwa, by zagwarantowa, e jest oparty na spjnych i odpowiednich informacjach. Nawet wwczas, gdy projekt jest czci programu i program dostarczy Zao enia Pro- dokument ten mo e si szybko zdezaktualizowa i dlatego bdzie jektu, wymaga sprawdzenia przed przystpieniem do dalszych czynnoci.

4.7.2.

Kontekst

Zewntrznym sygnaem wyzwalajcym prace nad projektem jest Zlecenie Przygotowa- Omawiany podproces sprawdza jego zawarto w celu upewnienia si, nia Projektu. eest ono nadal aktualne i rozbudowuje je, jeli jest to konieczne, w Zao enia j Projektu. Jeli projekt jest czci programu, program mo e wytworzy Zao enia Pr ojektu, ograniczajc tym samym zakres prac w tym podprocesie. Zesp zarzdzania projektem powinien dokona walidacji dostarczonych Zao e Projektu, co mo e doprowadzi do koniecznoci rozbudowania niektrych zawartych w nim stwierdze. Je eli Zao enia Projektu s dostarczane przez program, to kierownictwo programu musi wyrazi zgod na wszelkie zmiany (np. wpyw na ograniczenia, takie jak terminy dostaw). Tego typu zmiany wy magayby analizy wpywu na poziomie programu i mog skutkowa zapisa-w Rejestrach Ryzyka programu i mi projektu.

40

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

Kierownictwo firmy lub programu

Zlecenie Przygotowania Projektu

Za o enia Projektu Rejestr Ryzyka Dziennik

PP4 Przygotowanie Zao e Projektu

Zlecenie Przygotowania Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 4.6. Przygotowanie Zao e Projektu

4.7.3.

Opis procesu

Podproces ma na celu: przygotowanie formalnych wymaga dotyczcych projektu; ustalenie oczekiwa jakociowych klienta; ustalenie Kryteriw Akceptacji dla pr ojektu; rozpoczcie rejestracji wszelkich zagro e, na ktre nara ony jest projekt; przygotowanie zarysu Uzasadnienia Biznesowego, opartego na informacjach zawartych w Zleceniu Przygotowania Projektu. Zlecenie Przygotowania Projektu mo e nie by kompletne ani dokadne. Omawiany prowadzi do trwaego okrelenia wymaga dotyczcych projektu w podproces formie Projektu. Zao e Zao enia Projektu powinny zawiera zagr egowane informacje o co powinno by tym, zrobione, dlaczego (korzyci, ktre maj by kto powinien by zaanga oosignite), zostanie wany w proces oraz jak i gdzie on Celem Zao e Projektu zrealizowany. jest umo liwienie Komitetowi Sterujcemu podjcia decyzji, czy istnieje wystarczajce uzasadnienie, by zagwarantowa wydatki zaproponowane w Planie Etapu inicjowania.zawartoci Zao e Projektu, przedstawionym w Dodatku W zarysie Zarysy A opisw produkt , wymieniono potrzebne do tego celu w informacje. Oczekiwania jakociowe klienta powinny by uzgodnione ju na tym wczesnym etapie. one na wszystkie fazy wytwarzania produktu, a w ten sposb rwnie na Wpyn czas trwania i koszt. Okrelenie oczekiwa jakociowych klienta powinno pochodzi jego od spoecznoci klientw-u ytkownikw, pod przewodnictwem Gwnego U ytkownika, Przewodniczcego i innych interesariuszy. (Patrz: Rozdzia Jak w rodowisk 18 o u projekt , gdzie zawarte s dodatkowe u informacje). 41

STARTING UP A PROJECT (SU)

PRINCE2

Wymagania u ytkownika powinny by uszer egowane wedug wa noci. Pniej, je eli problemy spowoduj konieczno ponownego rozwa enia zakresu projektu, fundusze mog by skier owane na te elementy, ktre obiecuj najwy sz stop zwrotu. Czci wy maga projektu powinny by Kryteria Akceptacji, ktrych zawarto infor macyjn przedstawiono w Dodatku A Zarysy opisw . Bazuj one na oczekiwaniach produktw jakociowych klienta. Zawar to Zao e Projektu powinna by omwiona ze wszystkimi interesariuszami. Poziom szczegowoci wymagany dla ka dego elementu Zao e Projektu bdzie si zmienia w zale noci od warunkw projektu. Jednak e ka dy z tych elementw powinien by rozwa ony, nawet je eli wynikiem tych rozwa a bdzie stwierdzenie, e dany element nie jest potrzebny. Uzasadnienie Biznesowe bdzie doprecyzowywane jako cz Dokumentu Inicjujcego Projekt i dalej uzupeniane w trakcie caego projektu. Jednak e pierwotne uzasadnieniezrozumiae i powinno by podane w Zleceniu Przygotowania Projektu, musi by albo opracowane w trakcie omawianego podpr ocesu i umieszczone w dokumencie Zao enia Projektu (szczegy patrz: Rozdzia Uzasadnienie ). 13 biznesowe Oczekiwania jakociowe klienta i Kryteria Akceptacji bd tak e wykorzystane podczasinicjowania do przygotowania Planu Jakoci Pr Etapu ojektu. PRI NCE2 sugeruje, aby Kierownik Projektu prowadzi Dziennik - nieformalny zapis wszelkich wydarze, ustale i zada zwizanych z monitorowaniem. Bdzie on potrzebny podczas caego projektu, dobrym po mysem jest wic, by zao y go wanie trakcie w tego podprocesu. W trakcie realizacji omawianego podprocesu mog si ujawni r nego rodzaju zagro- (czynniki ryzyka) i z tego te powodu Rejestr Ryzyka powinien by zao ony enia tak wczenie, jak tylko jest to praktyczne, aby umo liwi przechowywanie szczegw dotyczcych wszelkich zagro e, ich analizy i podejmowanych dziaa.

4.7.4.

Odpowiedzialno

Za przygotowanie Zao e Projektu ostatecznie odpowiada .W praktyPrzewodniczcy ce wiele zwizanych z tym prac bdzie wykonywa Kierownik Projektu lub kto z personelu wyznaczonego do Wsparcia Pr ojektu. Osoba, ktrej Przewodniczcy delegowa swoje obowizki nadzoru projektu, powinna dokona przegldu zarysu Uzasadnienia Biznesowego i Rejestru Ryzyka.

42

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

4.7.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 4.4. PP4 Informacja Objanienie

Dziennik Wyjcie Prowadzone przez Kierownika Projektu nieformalne zapisy na temat dziaa, decyzji, wydarze oraz prac do wykonania. Rejestr Ryzyka Wyjcie Do zapisywania zagro e cznie z wszelkimi odnotowanymi w Zleceniu Przygotowania Projektu lub w Zao eniach Projektu. Zao enia Projektu Wyjcie Przedkadane Komitetowi Sterujcemu jako cz uzasadnienia dla rozpoczcia Etapu inicjowania. Zlecenie Przygotowania Projektu Wejcie Zewntrzny sygna startowy ze strony kierownictwa firmy lub programu zawierajcy przyczyny powoania projektu.

4.7.6.

Kryt eria oceny ci jako Czy Zao enia Projektu zawieraj wszystkie wymagane informacje? Czy informacje zawarte w r nych czciach Zao e Projektu s spjne? Czy wasno projektu jest waciwie okrelona? Czy istniej jakie potencjalne mo liwoci zakwestionowania zawartoci Zao e Projektu przez czonkw Komitetu Sterujcego? Czy Zao enia Projektu s odpowiednie, by podj decyzj o zezwoleniu na zainicjowanie projektu? Je eli projekt jest jednym z ogniw acucha powizanych projektw, czy tre Za- e Projektu jest dopasowana do wczeniejszych o projektw?

Wskazwki i rady Przed przedstawieniem Zao e Projektu do formalnego zatwierdzenia nale y je om- w trakcie nieformalnych spotka z ka dym czonkiem Komitetu wi Sterujcego. Nale y sprbowa ustali, czy s jakie konflikty interesw midzy stronami projektu. Dla maych projektw Zao enia Projektu nie musz by przygotowywane w for mie osobnego dokumentu. Waciwsze mo e by przygotowanie od razu zarysu Dokumentu Projekt, ktry bdzie pniej udoskonalany. W takim przypadku Inicjujcego procesy Przygotowanie (PP) i Inicjowanie (IP) mog by poczone w jeden Projektu Projektu proces.

43

STARTING UP A PROJECT (SU)

PRINCE2

Zao enia Projektu powinny by dokumentem krtkim i sporzdzonym na takim poziomie oglnoci, jaki jest zgodny z decyzjami, ktre musz by podjte w podprocesie Zezwolenie na Zainicjowanie (ZS1). Projektu

4.8.
4.8.1.

Okre lenie Formuy Realizacji Projektu (PP5)

Podstawowe zasady

Zanim mo na bdzie wykona jakiekolwiek prace planistyczne, nale y podj decyzje sposb, w jaki bdzie realizowany projekt. Dla przykadu, czy mo liwa ustalajce jest realizacja przez: kupienie rozwizania gotowego z pki; wykonanie na miar; wytworzenie we wasnym zakr esie; zlecenie stronom tr zecim; oparcie si na istniejcym produkcie; zbudowanie go od podstaw; wykorzystanie okrelonych technologii. Nale y si rwnie upewni, e proponowany sposb wykonania prac jest zgodny z praktykami i wytyczny mi uzgodnionymi klientem a dostawc, i nie nara midzy aden a w sposb projektu na niebezpieczestwo.

4.8.2.

Kontekst

Dla przygotowania okrelonej Formuy Realizacji Projektu podproces czerpie informacje z Zao e Projektu or az z r nych rde nale cych do klienta i dostawcy. Formua Realizacji Projektu zostanie wykorzystana w trakcie budowy Planu Jakoci i Planu Projektu w kolejnym procesie metodyki PRINCE2, ktrym Projektu Inicjo jest wanie (IP). Projektu
Rejestr Ryzyka Zao enia Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

PP5 Okre lenie Formuy Realizacji Projektu

Formua Realizacji Projektu

Rysunek 4.7. Projektu

Okrelenie Formuy Realizacji

44

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP) Opis procesu

4.8.3.

Celami podprocesu s: zdecydowanie, jak nale y realizowa prace w projekcie; zidentyfikowanie wszelkich ogranicze, dotyczcych sposobu wykonywania prac terminw lub dostarczenia okrelonych produktw; okrelenie umiejtnoci wymaganych do wykonania prac. Dla osignicia tych celw nale y podj szer eg krokw, to znaczy: ustali, a je eli to konieczne, doprecyzowa, w jaki sposb podejdzie si do reali- prac, w oparciu o oglne wytyczne zawarte w Zleceniu Przygotowania zacji Projektu i/lub w Zao eniach ,a w szczeglnoci w tych ich sekcjach, w Projektu ktrych definiuje si projekt i przedstawia Uzasadnienie Biznesowe. zidentyfikowa wszelkie ograniczenia dotyczce czasu, pienidzy, jakoci oraz wykorzystania lub dostpnoci zasobw; ustali wszelkie standardy klienta lub dostawcy, ktre powinny by zastosowane do produktw lub dziaa w pr ojekcie; zgromadzi wszelkie owiadczenia klienta lub dostawcy, dotyczce najlepszych praktyk, ktre mogyby by zastosowane do produktw lub dziaa w projekcie; zidentyfikowa ograniczenia zwizane z bezpieczestwem, ktre powinno si uwzgldni podczas wytwarzania i dugookresowej eksploatacji produktw projektu; okreli kilka mo liwych sposobw dostarczenia produktw projektu; zidentyfikowa wszelkie implikacje, wynikajce z potrzeb eksploatacji oraz utrzy- produktw, ktre mog mie wpyw na wybr opcji realizacji mania projektu; rozpozna wszelkie strategie korporacyjne lub deklaracje kierunkowe, ktre mog wpyw na realizacj produktw i dziaania w mie projekcie; umieci projekt w kontekcie innych zwizanych z projektem prac lub inicjatyw firmowych, w celu ustalenia wszelkich zewntrznych uzale nie i warunkw wstpnych; rozpozna aktualne tendencje dokonywania wyboru rozwiza w sektorach prze- objtych projektem i obszary umiejtnoci specjalistycznych, anga mysu owane do projektu; okreli oglne znaczenie wynikw projektu dla biznesu oraz aktualn ocen ryzyka biznesowego; rozpatrzy, jak gotowy produkt mo e by wprowadzony do u ytku; okreli potrzeby szkoleniowe personelu u ytkownika; oceni mo liwe warianty realizacji projektu z wykorzystaniem ustalonych kryteriw i parametrw; wybra najwaciwszy wariant.

45

STARTING UP A PROJECT (SU)

PRINCE2

4.8.4.

Odpowiedzialno

Za zrealizowanie podprocesu odpowiada Kierownik Projektu. Jednak e praca ta powin- wykonana przez osoby posiadajce kwalifikacje specjalistyczne w obszar na by ach zwizanych z projektem, zwykle z udziaem osb penicych role Wsparcia Projektu i Nadzoru Projektu, pod oglnym kierownictwem Gwnego Dostawcy.

4.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 4.5. PP5 Informacja Objanienie

Zao enia Projektu Wejcie Produkt zawiera informacje, na podstawie ktrych podejmowane s decyzje w tym podprocesie. Rejestr Ryzyka Wejcie Zidentyfikowane zagro enia (ryzyko) mogce wpyn na Formu Realizacji Projektu. Formua Realizacji Projektu Wyjcie Stanowi cz opisu Planu Projektu w Dokumencie Inicjujcym Projekt oraz jest wejciem do podprocesu Planowanie Jakoci (IP1) i procesu Planowanie (PL) .

4.8.6.

Kryteria oceny ci jako Czy wybrana Formua Realizacji Projektu maksymalizuje szans odniesienia sukcesu przez projekt? Czy w trakcie wyboru Formuy Realizacji Projektu wzito pod uwag zagadnienia eksploatacj i utrzymaniem produktw, aby zapewni najwiksze zwizane z szanse zrealizowania korzyci? Czy, przyjmujc wybran Formu Realizacji Projektu, uwzgldniono ryzyko zwizane z tym, e zrealizowanie projektu ma krytyczne znaczenie dla sukcesu lub firmy e ryzyko jest wysokie? Alternatywnie - czy nie pominito jakiej okazji do eksperymentowania i potencjalnego zdobycia dowiadcze na przyszo w projekcie o niskim ryzyku i/lub niekrytycznym znaczeniu? Czy dla wszystkich rozwa anych wariantw Formuy Realizacji Projektu zidenty- i oceniono ryzyko tak, e w rezultacie wybrano najwaciwszy z fikowano nich? Czy istnieje potrzeba wczenia zewntrznych zasobw? Je eli tak, to czy ma to jakikolwiek wpyw na sposb pracy?

Wskazwki i rady
Ten podproces bdzie r nie stosowany w r nych rodowiskach i jako taki musi by prowadzony w sposb przemylany. Zakres zagadnie bdzie kracowo odmienny, zale nie od natury projektu i rodowiska firmowego. Przykadowo, nale y rozwa y:

46

PRINCE2
Jaki jest dostpny zakres technik konstrukcyjnych?

PRZYGOTOWANIE PROJEKTU (PP)

Czy wymagane skadniki lub specjalistyczne kwalifikacje powinny by zakupione, czy te mog by zapewnione we wasnym zakresie? Czy nale y zastosowa istniejce sprawdzone i przetestowane metody, czy te w projekcie powinno si eksperymentowa z nowymi, przodujcymi technikami? W jakim zakresie decyzje powinny by pozostawione zewntrznemu dostawcy? Jak du y nacisk nale y poo y na dostosowanie si do standardw klienta?

Je eli projekt wytwarza produkt, ktry ma zastpi produkt istniejcy, nale y sprawdzi, czy taka zamiana mo e mie wpyw na wybr Formuy Realizacji Projektu. Mo e si zdarzy, e nie o wszystkim mo na zdecydowa w tej fazie i bd konieczne dalsze rozszerzenia oraz doprecyzowania w trakcie projektu. Porozumienie midzy Kierownikiem Projektu a Komitetem Sterujcym, dotyczce strategii technicznej i jakociowej projektu, mo e wymaga uwzgldnienia wszelkich planowanych zmian dostawcw w trakcie projektu.

4.9.
4.9.1.

Planowanie Etapu Inicjowania (PP6)

Podstawowe zasady

Inicjowanie projektu i przygotowanie Planu Projektu wymag a czasu i zu ywa zasoby. Ta praca powinna by zaplanowana i zatwierdzona, jak ka da inna praca w projekcie. Nale y sprawdzi, czy inicjowanie projektu jest uzasadnione i czy nie odbywa si chaotycznie.

4.9.2.

Kontekst

Po sprawdzeniu, e w podprocesie Przygotowanie Zao Projekt (PP4) u zdefiniowano, co projekt ma wykona, i podano euzasadnienie koniecznoci realizacji, Komitet Sterujcy potrzebuje wiedzy na temat nakadw na pr zygotowanie Dokumentu Inicjujcego Projekt.

47

STARTING UP A PROJECT (SU)

PRINCE2

Plan Etapu inicjowania

ZS1 Zezwolenie na Zainicjowanie Projektu

Formua Realizacji Projektu Zao enia Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rejestr Ryzyk a

PP6 Planowanie Etapu Inicjowania

PL Planowanie

Rysunek 4.8. Inicjowania

Planowanie

Etapu

4.9.3.

Opis procesu

Celami tego podprocesu s: opracowanie planu (Plan Etapu inicjowania), obejmujcego wytworzenie Doku- Inicjujcego Projekt ( ktry zawiera Plan mentu Projektu); ustalenie zasad raportowania i kontroli dla Etapu inicjowania. Doku ment Inicjujcy Projekt jest rozszerzeniem i doprecyzowaniem Zao e Projektu z dodaniem szczegw dotyczcych zespou zarzdzania projektem oraz Planu Projektu i Rejestru Ryzyka. Plan Etapu inicjowania powinien uwzgldni wyszukanie i przygotowanie wymaganych dodatkowych informacji oraz przeksztacenie Zao e Projektu do postaci wymaganej od Dokumentu Inicjujcego Projekt. W porwnaniu z prawdopodobnymi kosztami caego projektu, Etap inicjowania powinien by krtki i niekosztowny. Struktura etapw projektu zostanie okrelona w trakcie Etapu Na zakoinicjowania. czenie Etapu inicjowania Komitet Sterujcy bdzie si spodziewa, e poza Dokumentem Inicjujcym Projekt, otrzyma te szczegowy Planu Etapu (nastpnego), poniewa zakres jego faktycznego zaanga owania bdzie dotyczy tylko nastpnego etapu projektu. Je eli projekt jest czci programu, to termin zakoczenia Etapu inicjowania powinien by uzgodniony z terminem zapisanym w planie programu. Plan Etapu inicjowania e kierownictwu programu sygna o oczekiwaniach w stosunku do przeka e tak progra-potrzebie przygotowania si do przegldu Dokumentu Inicjujcego mu i Projekt. Do przygotowania Planw Etapw bdzie wykorzystywany wsplny Planowani proces e (PL).

48

PRINCE2

PRZYGOTOWANIE PROJEKTU (PP)

4.9.4.

Odpowiedzialno

Za zaplanowanie Etapu inicjowania odpowiada Kierownik Projektu. Osoby wyznaczone do roli Nadzoru Projektu i Wsparcia Projektu bd go w tym wspomagay. W szczeglnoci kto, kto odpowiada za nadzr biznesowy, powinien okreli w Planie Etapu inicjowania, w jaki sposb zostan sprawdzone Uzasadnienie Biznesowe i ocena ryzyka.

4.9.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Opisuje sposb przeprowadzenia prac w projekcie. Mo e mie wpyw na prawdopodobny zakres prac do wykonania w trakcie inicjowania projektu.

Tabela 4.6. PP6 Informacja Objanienie

Formua Realizacji Projektu

Zao enia Projektu Wejcie Szczegy prac do wykonania w projekcie (wraz z wczeniej wykonanymi pracami planistycznymi) s zawarte w Zao eniach Projektu i pomog okreli rozmiary Etapu inicjowania. Rejestr Ryzyka Uaktualnienie Jest uaktualniany nowymi zagro eniami. Plan Etapu inicjowania Wyjcie Produkt niezbdny do uzyskania zgody na zainicjowanie projektu. Plan Etapu inicjowania powinien by nieformalnie przedyskutowany z Komitetem Sterujcym.

4.9.6.

Kryt eria oceny ci jako Czy Plan Etapu inicjowania pokazuje, e s dostpne zasoby wystarczajce do pomocy Kierownikowi Projektu w przygotowaniu ka dego z elementw Doku mentu Inicjujcego Projekt i Planu Etapu (nastpnego)? Czy zosta ustalony odpowiedni poziom raportowania zarzdczego, jakiego wymaga wielko lub poziom ryzyka Etapu inicjowania? Czy Plan Etapu inicjowania pokazuje, jak bdzie wytworzony ka dy z elementw Dokumentu Inicjujcego Pr ojekt? Czy przedstawiono Komitetowi Sterujcemu wystarczajce informacje do podjcia o rozpoczciu lub nierozpoczynaniu decyzji projektu? Czy osoby odpowiedzialne za Nadzr Projektu wskazay, ktre z elementw proponowanego Dokumentu Inicjujcego Projekt chc sprawdzi, w jaki sposb u yciem jakich i z zasobw?

49

STARTING UP A PROJECT (SU) Wskazwki i rady

PRINCE2

Czsto Etap inicjowania jest krtki. Jeli komunikacja z Komitetem Sterujcym jest wystarczajco czsta, organizowanie formalnego raportowania nie bdzie konieczne. O ile zawsze jest wa ne, by ka d prac zaplanowa przed jej rozpoczciem, o tyle dla niektrych maych i niezbyt ryzykownych projektw mo e nie by konieczne budowanie formalnego planu dla Etapu inicjowania. Rozmiar prac przygotowawczych i inicjujcych, nawet dla du ych i zo onych projektw, zale y od tego, jakie zwizane z nimi prace wykonano wczeniej.

50

5.

I NI C JOWAN IE PR OJE K TU (I P )
(INITIATING A PROJECT - IP)

Rozwini cie Uzasadnienia Biznesowego Ponowna ocena ryzyka

Planowanie projektu

Zaplanowanie sposobu osi gni cia wymaganej jako ci produktu

Okre lenie sposobu kontroli produktw

Przygotowanie do uzyskania zezwolenia na realizacj projektu

Ustalenie niezb dnych elementw sterowania projektem

Rysunek 5.1. Projektu

Zarys procesu Inicjowanie

5.1.

Podstawowe zasady

W udanych projektach zauwa a si stosowanie nastpujcych zasad: projekt jest procesem realizowanym w ograniczonym czasie, ma swj okrelony pocztek i koniec; wszystkie zainteresowane strony, po to aby mogy si prawdziwie zaanga owa w projekt, musz mie jasno: co zamierza si osign, dlaczego jest to potrzeb- ten rezultat ma by osignity oraz jakie s ich ne, jak obowizki; waciwie zarzdzane projekty maj wiksz szans na osignicie sukcesu. Przestrzeganie tych zasad zapewni, e projekt bdzie mie dobrze okrelony zakres i bdzie skutecznie zarzdzany a do jego zakoczenia.

51

INITIATING A PROJECT (IP)

PRINCE2

5.2.

Kontekst

Inicjowanie (IP) ma na celu stworzenie podstaw do spenienia wy ej Projektu opisanych zasad. Proces ten nastpuje po przedprojektowym Przygotowanie procesie Jest t (PP). ur uchamiany przez Zezwolenie na ProjekZainicjowanie u podproces Projektu Projekt (ZS2) (ZS1), prowadzi do podprocesu Zezwolenie na i ur Realizacj u Planu uchamia proces Za proces Planowani (PL), w ktrym przygotowuje si oraz e Projektu, (ZE), w ktrym przygotowywany jest Plan Etapu r dzanie Zakresem z Etapu (nastpnego) . Inicjowanie projektu powinno by zawsze pierwszym etapem w ka dym projekcie prowadzonym wedug PRINCE2.
IP
IP1 P l an owa ni e a k oci J

Inicjowanie Projektu
I P2 Pl a nowa ni e oj e kt u Pr IP3 D opr e cy z owa ni e U za s a dni e ni a i zn es owe B go R y zy i ka

ZS1 Ze zwo le ni e na i ni cj ow an Za ie oj e kt u Pr IP4 U s ta now i en ie l em ent w E S te ro wa ni a

PL P l an owa ni e

I P5 U s ta nowi e ni e s te m u Sy D ok um e nta c ji

IP6 Ze s ta wi e ni e D ok um e ntu c j uj c e go I ni P roj e k t

ZS 2 Ze z wol e ni e na R e al i z ac j P ro je k tu

ZE Za r z dza ni e Za k re s e m Et a pu

Rysunek Projektu

5.2.

Inicjowanie

5.3.

Opis procesu

Celem procesu Inicjowanie (IP) jest sporzdzenie swoistego Projektu kontraktu, w formie Dokumentu Inicjujcego Projekt, midzy Komitetem Sterujcym a Kierownikiem Projektu, tak by osign jednakowe rozumienie nastpujcych kwestii: powody, dla ktrych projekt jest realizowany; gwne produkty, ktre projekt ma do starczy; jak, kiedy i po jakim koszcie mog by one dostarczone; zakres prac, ktre maj by wykonane; ograniczenia odnoszce si do produktw, ktre maj by dostarczone; ograniczenia dotyczce projektu; kto bdzie zaanga owany w podejmowanie decyzji w projekcie; jak bdzie osignita jako wymagana w projekcie; na jakie zagro enia projekt jest nara ony; 52

PRINCE2

INICJOWANIE PROJEKTU (IP)

jak projekt bdzie sterowany; kogo nale y informowa o postpach projektu, jak i kiedy; jakiego dalszego zaanga owania zasobw potrzebuje Kierownik Projektu (Plan Etapu nastpnego). Powy sze informacje mog by uzgodnione nieformalnie, jeli tak zechc Komitet Ste- i Kierownik Projektu. Jednak e niezale nie od tego, jak niewielki jest pr rujcy 5 i uzyojekt, Kierownik Projektu powinien zawsze dokumentowa poczynione uzgodnienia Komitetu Sterujcego, nawet je eli jest to pojedyncza osoba. ska podpisy Zapamitane ustne uzgodnienia mog r ni si po kilku tygodniach, a nawet po przez ludzi kilku dniach. Z formalnego punku Inicjowanie (IP) ma na widzenia Projektu celu: udokumentowanie i potwierdzenie, e istnieje akceptowalne Uzasadnienie Biznesowe dla projektu; zapewnienie, poprzez utworzenie Dokumentu Inicjujcego Projekt, solidnych i uzgodnionych podstaw projektu jeszcze przed rozpoczciem prac; przekonanie Ko mitetu Sterujcego do przyjcia odpowiedzialnoci za projekt liwienie mu i umo tego; umo liwienie i przekonanie Komitetu Sterujcego do: podjcia decyzji o tym, czy projekt jest uzasadniony; uzgodnienia zaanga owania zasobw do realizacji nastpnego etapu projektu; dostarczenie odniesienia dla procesw decyzyjnych, wymaganych w trakcie projektu; zapewnienie, dziki przeprowadzeniu inicjowania projektu w sposb zorganizowa- owanie czasu i wysiku wymaganych przez projekt bdzie ny, e zaanga dokonane z uwzgldnieniem zagro mdr ze, e. Skalowalno

5.3.1.

Jak to stwierdzono na pocztku Rozdziau Przygotowanie (PP , ilo pracy 4 Projektu koniecznej do przeprowadzenia omawianego procesu mo e by mniejsza, ) je eli pr ojekt czci programu. W skrajnym przypadku Dokument Inicjujcy Projekt mo e jest by ju gotowy i potrzebne bdzie jedynie Planu Etapu (nastpnego) przygotowanie wersji waciwych rejestrw i kartotek. oraz pocztkowych Niezale nie od tego, Kierownik nadal ma obowizek zapewnienia, eby wszystkie dostarczone przez Projektu program dotyczce inicjowania projektu byy kompletne i jakociowo produkty zadowalajce. Dla maych projektw, udokumentowanie odpowiedzi udzielonych na pytania zawarte w kluczowych kryteriach oceny Przygotowanie Zao Projekt (PP4) podprocesu okaza wystarczajce do zrealizowania Etapu inicjowania (oczywicie e u mo e si wraz Planem Projektu i Planem Etapu (nastpnego), ktre w maym projekcie o jednym eta- realizacyjnym - mog by jednym i tym samym planem). Mo liwe jest pie uzgodnienie Sterujcym, e obydwa pr z Komitetem Przygotowanie (PP) i Inicjowa ocesy nie ( IP) bd poczone. W takim Projektu przypadku formalny przebieg Ze Projektu procesu 5

Np. w Dzienniku przypis tumacza.

53

INITIATING A PROJECT (IP) zwolenie na Zainicjowanie Projektu uzgodnienie midzy Kierownikiem Sterujcym. Wskazwki i rady
Z powodu wzrastajcej szczegowoci informacji, ktre wychodz na jaw w trakcie tego procesu, i wynikajcego z nich lepszego zrozumienia, inicjowanie projektu jest zwykle szeregiem powtrze (iteracji) dziaa, przerywanych adresowanymi do czonkw Komitetu Sterujcego probami o opini. Je eli projekt jest od samego pocztku dobrze zdefiniowany i zaplanowany, inicjowanie mo e by bardzo szybkim zadaniem, polegajcym na zatwierdzeniu wykonanych prac i przejciu odpowiedzialnoci. Dla projektu, ktry jest czci programu, nale y w Planie Komunikacji (cz Dokumentu Inicjujcego Projekt) ustali linie komunikacji i struktur raportowania midzy projektem a programem. Jeli projekt posiada interesariuszy, ktrzy nie s reprezentowani w Komitecie Sterujcym, jest uzasadnione sprawdzenie z nimi Dokumentu Inicjujcego Projekt przed jego formalnym przedstawieniem Komitetowi Sterujcemu. Nale y sign do wczeniejszych Raportw o Dowiadczeniach, gdzie mo na znale przydatne wskazwki i informacje.

PRINCE2 (ZS1) mo e by zastpiony nieformalne Projektu a Komitetem przez

5.4.
5.4.1.

Planowanie Jako
Podstawowe zasady

ci (IP1)

Kluczowym czynnikiem sukcesu projektu jest osignicie spenienia przez jego wynik oczekiwa jakociowych klienta oraz Kryteriw Akceptacji. Stanie si tak tylko wtedy,te oczekiwania zostan sprecyzowane i uzgodnione na pocztku projektu, wraz kiedy ze standardami, ktre maj by u yte, oraz metodami oceny spenienia tych ustale przez kocowy. produkt

5.4.2.

Kontekst

Podproces bazuje na Formule Realizacji Projektu okrelonej w PP5 i opisuje, jak jako zostanie osignita w kolejnych procesach planowania.

54

PRINCE2

INICJOWANIE PROJEKTU (IP)

Standardy jako

ci

Zao enia Projektu Formua Realizacji Projektu Struktura zespou zarz Zakresy obowi zkw dzania projektem

Dokumentacja Dokumentacja zarz dcza zarz dcza

IP1 Planowanie Jako ci

Rejestr Jako ci Plan Jako ci Projektu

Rysunek 5.3. Planowanie Jakoci

5.4.3.

Opis procesu

Celem podprocesu jest okrelenie jakoci wymaganej od produktw projektu i zaplanowanie sposobu podejcia do jakoci (Plan Jakoci poprzez: Projektu) ustalenie systemu jakoci, ktry bdzie przyjty przez projekt oraz jak zostanie zorganizowany Nadzr Projektu; uzgodnienie oczekiwa jakociowych klienta; ucilenie Kryteriw projektu Akceptacji ; ustalenie podejcia, jakie bdzie stosowane w projekcie do sterowania zmianami. W celu osignicia powy szych celw nale y podj szereg r nych krokw: ustali powizania z wszelkimi funkcjami nadzoru jakoci w firmie i/lub programie aby wszystkie dziaania dotyczce jakoci w projekcie wspieray i i zapewni, byy wspierane przez te funkcje. Mo e to obejmowa przypisanie roli nadzoru jakoci w projekcie (jako czci roli Nadzoru ; Projektu) ustali, czy klient posiada system zarzdzania jakoci, ktry powinien by zastosowany w pracach projektu; ustali, czy dostawca ma system zarzdzania jakoci, ktry powinien by zastosowany w pracach projektu; okreli, jaka kombinacja standardw klienta i dostawcy bdzie zastosowana; ustali wszelkie potrzeby nadzoru jakoci dotyczce pr oduktw zarzdczych i dzia- projekcie, w szczeglnoci speniajc wymagania systemu zarzdzania a w jakoci, tam gdzie maj one zastosowanie; ustali rodki, za pomoc ktrych bdzie zmierzone powodzenie wykonania produktu kocowego projektu, i uporzdkowa je wedug ich istotnoci;

55

INITIATING A PROJECT (IP)

PRINCE2

okreli obowizki zwizane z jakoci zarwno wewntrz projektu, jak i poza nim; okreli procedury i techniki kontroli jakoci, ktre bd wykorzystane podczas realizacji projektu; stworzy Plan Zarzdzania Konfiguracj i procedury sterowania zmianami, obejmujce: obowizki; procedury; bud et zmian; dokumentacj ; zebra wszystkie powy sze elementy i zestawi je w Plan Jakoci Projektu; zao y Rejestr Jakoci do przechowywania szczegw planowanych i faktycznych kontroli jakoci. Bdzie on uzupeniany w miar powstawania kolejnych Pla- Etapu i Planw Zespow. nw

Dalsze informacje dotyczce tych aspektw znajduj si w rozdziaach: Jak 18 w rodowisku 19 Zar dzanie ; i 20 Sterowanie .o projektu; z konfiguracj zmianami Jeli projekt jest czci progr przekazane z programu Zlecenie amu, Przygotowania Projektu lub Zao enia Projektu mog zawiera stwierdzenia dotyczce planowania jakoci. Stworz one podstaw Planu Jakoci Projektu. Jeli s jakiekolwiek niespjnoci midzy opracowanym Planem Jakoci Projektu a tym, co jest zawarte w Zleceniu Przygotowania Projektu lub Zao eniach Projektu, musz by one rozstrzygnite z kierownictwem programu. Jeli projekt bdzie wykorzystywa standardy, ktre ju s udokumentowane, to Planie Jakoci Projektu wystarczy zamieci odwoanie do nich, a w udokumentowa jedynie ewentualne zmiany.

5.4.4.

Odpowiedzialno

Za podproces odpowiada Kierownik wspierany pr zez osoby penice Projektu, obowizki Nadzoru Projektu, w szczeglnoci te zwizane z nadzorem biznesowym. Jeli w organizacji istnieje wydzielona funkcja nadzoru jakoci, prace w tym podprocesie wykonane w cisej koordynacji z osobami penicymi t musz by funkcj.

56

PRINCE2

INICJOWANIE PROJEKTU (IP)

5.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 5.1. IP1 Informacja Objanienie

Zao enia Projektu Wejcie Dokument powinien zawiera Oczekiwania jakociowe klienta i Kryteria Akceptacji. Standardy jakoci Wejcie Standardy, z ktrymi projekt musi by zgodny. Formua Realizacji Projektu Wejcie Ustalenie najbardziej odpowiedniego podejcia do jakoci. Nale y wiedzie, jak bd realizowane prace w projekcie, poniewa ma to podstawowy wpyw na metody i zasoby, ktre zostan u yte. Wejcie / Aktualizacja Ustalenie obowizkw zwizanych z jakoci i dodanie ich do istniejcych ju zakresw obowizkw jeli jest waciwe.

Struktura zespou zarzdzania projektem i zakresy obowizkw

Plan Jakoci Projektu Wyjcie Zawiera rezultaty podprocesu Planowanie Jakoci (IP1), wcznie z doprecyzowanymi i rozwinitymi (na ile to mo liwe) Kryteriami Akceptacji; bdzie jednym z elementw Dokumentu Inicjujcego Projekt, ktry jest rezultatem podprocesu Zestawienie Dokumentu Inicjujcego Projekt (IP6). Rejestr Jakoci Wyjcie Utworzony i gotowy do rejestracji wszystkich szczegw kontroli jakoci.

5.4.6.

Kryt eria oceny ci jako Czy wszystkie standardy jakoci zwizane z obszarem oddziaywania projektu zostay zidentyfikowane i rozwa one? Czy klient narzuci w stosunku do kocowego produktu jakie Kryteria Akceptacji, ktre wymagaj prac zwizanych z jakoci, wykraczajcych poza zwyke oczekiwania? Czy uwzgldniono wszystkie, i tylko te, standardy, ktre s waciwe do skutecz-wytworzenia kocowego pr oduktu nego projektu? Czy w wietle wybranych standardw podejcie do zapewnienia jakoci w projek- waciwe? cie jest Czy kryteria jakoci s mierzalne lub mo liwe do oceny za pomoc przyjtych mechanizmw kontroli jakoci? Czy metody sterowania zmianami i zapewnienia jakoci s odpowiednie do skalionoci projektu oraz ryzyka na ktre jest nara zo ony?

57

INITIATING A PROJECT (IP)

PRINCE2

Jak zostanie zrealizowany nadzr jakoci w projekcie, je eli Kierownik Projektu ma nie kwalifikacji technicznych?

Wskazwki i rady
Wiele informacji omawianych w tym rozdziale, takich jak standardy i funkcje, zwizane z zapewnieniem jakoci, mo e by wczeniej sformuowanych i udokumentowanych Zazwyczaj wystarcza wtedy odwoanie si w Planie Jakoci Projektu do tej dokumentacji wraz z jasnym wskazaniem i omwieniem wszelkich odchyle od zawartych w niej standardw. Jednak e pozostaa zawarto Planu Jakoci Projektu musi by jednoznacznie okrelona. Plan Jakoci Projektu musi uwzgldni wszelkie planowane w trakcie projektu zmiany dostawcw, gdy mog mie oni r ne standardy jakoci.
6

5.5.
5.5.1.

Planowanie Projektu (IP2)

Podstawowe zasady

Przed zaanga owaniem si w istotne wydatki na projekt, nale y ustali potrzeby, dotyczce zasobw i Taka informacja, zawarta w Planie jest terminw.na byo oceni Uzasadnienie Biznesowe i aby Komitet Sterujcy potrzebna Projektu, aby mo mg sterowa projektem .

5.5.2.

Kontekst

Ten podproces wykorzystuje wsplny Planowani (PL) do sporzdzenia proces e z Planu Planu Projektu. Uwzgldnia on implikacje wynikajce Jakoci Projektu, pochodzce z podprocesw Planowanie (IP1) i Okr c lenie Formuy Realizacji Jako i e Projektu (PP5). Plan Projektu staje si gwnym elementem Dokumentu Inicjujcego Projekt.

Przez organizacj lub program, ktrych czci jest projekt przypis tumacza.

58

PRINCE2

INICJOWANIE PROJEKTU (IP)

Zao enia Projektu Formua Realizacji Projektu Plan Jako ci Projektu Rejestr Ryzyka

Dokumentacja Dokumentacja zarz dcza zarz dcza

IP2 Planowanie Projektu

Plan Projektu

PL Planowanie

Rysunek Projektu

5.4.

Planowanie

5.5.3.

Opis procesu

Podproces ma na celu: doprowadzenie do zrozumienia, na mo liwie wysokim poziomie oglnoci, caoci prac, ktre maj by wk rtce podjte, poprzez: wskazanie i tam, gdzie to jest mo liwe, zdefiniowanie gwnych pr oduktw projektu ; wskazanie gwnych dziaa, ktre musz by podjte w celu dostarczenia produktw; ocen gwnych zagro e projektu i zaproponowanie rodkw zaradczych, tak to przedstawiono w Rozdziale jak Zar dzanie ; 17 z ryzykiem oszacowanie niezbdnych nakadw; oszacowanie, jakie s osigalne terminy realizacji przy uwzgldnieniu ograni-dla projektu i wszystkich kluczowych kamieni cze milowych; oszacowanie cakowitego zapotrzebowania na zasoby or az kosztw; okrelenie kluczowych punktw decyzyjnych i kluczowych przegldw oraz wszelkich implikacji, wynikajcych dla nich z przyjtej w projekcie Formuy Projektu. Na tej podstawie nale y podj decyzj, gdzie powinny Realizacji by granice etapw zarzdczych projektu (patrz Rozdzia Elementy ); 16 sterowania wykorzystanie Planowani (PL) do przygotowania Planu procesu e Projektu. Przyjta Formua Realizacji (patrz PP5) wpynie na sposb testowania, na Projektuilo prac wytwrczych i na inne czynniki powizane z przebiegiem etapw, rodzaj i jak choby to, czy przewiduje si du y udzia prac zwizanych z zakupami. Konieczne jest rwnie podjcie decyzji o standardach planowania, ktre bd wykorzystywane w obejmujcych projekcie, : narzdzia i techniki; zawarto i sposb prezentacji planw; 59

INITIATING A PROJECT (IP) zastosowanie albo odrzucenie standardw korporacyjnych lub bran owych. Poniewa podproces ten jest zasadniczo procesem planowania, poszczeglne kroki, ktre trzeba podj, objanione zostay w Rozdziale Planowanie . 11 (PL) Bud et zmian

PRINCE2

W ramach Planowanie (IP2) wskazane jest rozwa enie liczby podprocesu wnioskw Projektu spodziewanych o zmian celw lub specyfikacji, ktre mog by zgoszone projektu. Je eli przewiduje si mo liwo wystpienia wielu zmian, w trakcie Kierownik Projektu powinien zasugerowa Komitetowi Sterujcemu stworzenie wydzielonego w celu pokrycia ich ewentualnych kosztw. Pozwoli to unikn bud etu zmian sytuacji, Przewodniczcy jest ka dorazowo proszony o zwracanie si do kier w ktrej ownictwa programu o zwikszenie bud etu projektu, w celu pokrycia kosztw firmy lub takich zmian. Bud et rezerwowy W tym momencie ryzyko dotyczce projektu - zagro enia albo dodatkowe szanse powinno ju by przeanalizowane podczas Analizowanie Zagro (PL6). podprocesu jest znaczne, a plany rezerwowe zostay przygotowane, Kierownik e Jeli ryzyko Projektu zasugerowa Komitetowi Sterujcemu, e nale y przyj bud et powinien rezerwowy, na pokrycie kosztw wprowadzania w ycie tych planw w p rzypadku zmaterializowania si zwizanego z nimi zagr o enia.

5.5.4.

Odpowiedzialno

Za podproces odpowiada Kierownik wspomagany przez osoby penice Projektu, Projektu (gdzie istnieje) oraz przez innych czonkw zespou zarzdzania rol Wsparcia projektem, i wspierany wskazwkami osb penicych obowizki Nadzoru Projektu, ktre e sprawdzaj rezultaty tak dziaa.

5.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Dostarcza wyjanienia, jakie metody zostan zastosowane do wykonania prac i stanowi kluczowy wkad do procesu Planowanie (PL).

Tabela 5.2. IP2 Informacja Objanienie

Formua Realizacji Projektu

Zao enia Projektu Wejcie Ten dokument zawiera podstawowe informacje o projekcie. Informacji tych u ywa si w omawianym procesie jako punktu wyjcia do rozpoczcia procesu Planowanie (PL).

60

PRINCE2

INICJOWANIE PROJEKTU (IP)

Informacja Objanienie

zarzdcza

Wykorzystanie

Plan Jakoci Projektu Wejcie Ten produkt jest niezbdny, poniewa na wykonywane prace, potrzebne na nie czas i zasoby, bdzie wpywaa wymagana jako oraz standardy jakoci i metody, ktre maj by zastosowane. Rejestr Ryzyka Aktualizacja Zagro enia, zidentyfikowane w Rejestrze Ryzyka, mog wpywa na Plan Projektu, i odwrotnie, Plan Projektu mo e sam w sobie generowa nowe zagro enia lub zmienia dotychczasowe. Plan Projektu Wyjcie Jest to kocowy produkt, ktrego wytworzenie jest podstawowym powodem realizacji tego podprocesu.

5.5.6.

Kryt eria oceny ci jako Czy w Planie Projektu istnieje rwnowaga midzy jego szczegowoci z jednej strony, a zwizoci, czynica go zrozumiaym, z i kompletnoci, drugiej? Czy wszystkie istotne czci Zao e Projektu maj swoje odbicie w Planie Projektu? Czy poziom szczegowoci Planu Projektu jest odpowiedni, biorc pod uwag: czas trwania projektu; poziom niepewnoci dotyczcej kocowych produktw; zo ono projektu, rozumian na przykad jako liczba zale noci w porw-z liczb produktw, liczba zaanga owanych wydziaw lub naniu grup; ryzyko dla firmy i biznesu. Czy Plan Projektu jest wspierany przez inne elementy Dokumentu Inicjujcego Projekt? Czy poziom jego szczegowoci jest wystarczajcy, by wesprze opracowanie Dokumentu Inicjujcego Projekt? Czy Plan Projektu jest w stanie wspomc decyzje, ktre maj by podjte w podprocesie Zezwolenie na Projekt (ZS2)? Realizacj u Czy Plan Pr ojektu jest wystarczajco zwarty, by by faktycznie wykorzystywany przez czonkw Komitetu Sterujcego? Czy Plan Projektu jest zgodny z planami fir my i/lub programu?

Wskazwki i rady
Nale y si upewni, e Zao enia Projektu s waciwie rozumiane, poniewa powinny one stanowi podstaw, na ktrej bdzie wykonane planowanie. Zrozumienie, w jaki sposb maj by osignite korzyci biznesowe, mo e wpywa na to, jak powinien przebiega projekt. Uzyskanie ostatecznej wersji Planu Projektu czsto bdzie wymagao przygotowania zarysu tego planu, a nastpnie przygotowania szczegowego Planu Etapu nastpne-

61

INITIATING A PROJECT (IP)

go (dla ktrego impulsem sprawczym jest podproces Zestawienie Dokumentu Inicjujcego Projekt (IP6)) i dopiero na podstawie zgromadzonych w ten sposb informacji mo liwe bdzie doprecyzowanie Planu Projektu. Wystpuje potrzeba oceny scenariusza zagro e, wynikajcych z samego Planu Projektu. Jeli projekt jest czci programu, mo e by konieczne wczenie do planu pozycji : wynikajcych z interakcji midzy programem a projektem, np. okresowe audyty dla zapewnienia zgodnoci; narady dotyczce programu; zaanga owanie projektu w zarzdzaniu ryzykiem i sterowaniu zmianami na poziomie programu.

PRINCE2

5.6.

Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka (IP3)

Podstawowe zasady

5.6.1.

W trakcie ustanawiania projektu, a w szczeglnoci w trakcie jego realizacji, jest niezwykle atwo skoncentrowa si na c jest robione ja to ma by robione, tym, o i jednoczenie ignorujc dlaczeg trzeba to zrobi. k Uzasadnienie Biznesowe zagadnienie, o tym, dlaczeg pr ace s wykonywane i z tego powodu stanowi o mwi wanie o rozstrzygajcy element projektu. Wa ne jest rwnie , aby przewidzie wszelkie zagro enia, na jakie projekt mo e by ony, tak by podj odpowiednie dziaania, majce na celu uporanie si z nara nimi.

5.6.2.

Kontekst

Podproces korzysta z zarysu Uzasadnienia Biznesowego znajdujcego siZao eniach Projektu, a wymagania dotyczce zasobw czerpie z Planu Projektu. w Na podstawie dziaania podejmowane w podprocesie umo liwiaj doprecyzowanie tej Uzasadnienia Biznesowego, ktre jest nastpnie wczane do Dokumentu I nicjujcego Pro- W podprocesie uaktualnia si rwnie jekt. Rejestr Ryzyka poprzez uszczegowienie zagro e zidentyfikowanych w trakcie przygotowania Zao e jak Projektu, dodanie oceny ryzyka dla wszelkich zagr o e ujawnionych pniej.
Zao enia Projektu Formua Realizacji Projektu Rejestr Ryzyka Plan Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

IP3 Doprecyzowanie Uzasadnienia Biznesowego i Ryz yka

Uzasadnienie Biznesowe

Rysunek 5.5. Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka

62

PRINCE2

INICJOWANIE PROJEKTU (IP) Opis procesu

5.6.3.

W podprocesie dokonuje si doprecyzowania Uzasadnienia Biznesowego, a jednocze- e doj tak e do ujawnienia dodatkowych zagro nie mo e. Podproces ma na celu: doprecyzowanie Uzasadnienia Biznesowego w wietle tego, co jest w danym momencie wiadome o projekcie; wskazanie, jak ma by zmierzone osignicie ka dej z korzyci; dodanie do Rejestru Ryzyka dodatkowych problemw lub zagro e stwierdzonych w trakcie tego procesu; modyfikacj Planu Projektu poprzez uwzgldnienie wszelkich dziaa dotyczcych zarzdzania ryzykiem. Dla osignicia powy szych celw nale y podj szereg krokw. W odniesieniu do Uzasadnienia Biznesowego: sprawdzi, czy cele programu, firmy lub cele strategiczne, do ktrych nawizuje s w wietle informacji pozyskanych do tej pory w projekt, Inicjowani procesie (IP) e Projekt nadal prawdopodobne do ; u osignicia sprawdzi, czy ostatnie wydarzenia w otoczeniu projektu wpyny na jakiekolwiek wyspecyfikowane korzyci w Uzasadnieniu , zawartym w Zao eniach Biznesowym Projektu ; ustali, czy uwidoczniy si jakie dodatkowe korzyci biznesowe; przeszacowa, jeli to konieczne, dotychczasowe korzyci biznesowe oraz zidenty- wszelkie niepo dane efekty fikowa uboczne; ustali, jak bdzie zmierzone osignicie ka dej z deklarowanych korzyci i zapisa to na potrzeby pniejszego Planu Przegldu Poprojektowego; zapewni, eby zarejestrowano war toci miar bie cej sytuacji w obszar ze deklarowanych korzyci, po to, by mo na byo przeprowadzi waciwe porwnanie uzyskanych efektw podczas przegldu poprojektowego; wyliczy i/lub doprecyzowa pozycje kosztowe na podstawie Planu Projektu i aktualnych informacji o prawdopodobnych parametrach eksploatacyjnych i serwisowych produktw projektu; doprecyzowa lub obliczy uzasadnienie finansowe projektu, i tam gdzie jest to celowe, zweryfikowa ocen opacalnoci inwestycji; podsumowa inne warianty realizacji projektu rozwa ane w ramach podprocesu Okr lenie Formuy Realizacji (PP5). e Projektu W odniesieniu do Rejestru Ryz yka: zidentyfikowa zagro enia, ktre mog wpyn na projekt; oszacowa prawdopodobiestwo zmaterializowania si poszczeglnych zagro e; oszacowa wpyw zagro enia, je eli ono si zmaterializuje; 63

INITIATING A PROJECT (IP)

PRINCE2

przygotowa odpowiednie plany rezerwowe do wczenia ich do Planu Projektu; sprawdzi, w przypadku gdy projekt jest czci programu, czy kierownictwo programu chce by informowane o wszelkich dodatkowo zidentyfikowanych zagro eniach; sprawdzi, czy Biznesowym wymaga aktualizacji. zestawienie kluczowych zagro e w Uzasadnieniu

W odniesieniu do Planu Projektu: oceni koszt dziaa zapobiegawczych i planw rezerwowych w kontekcie ich wartoci dla redukcji ryzyka; doda powy sze informacje do Planu Projektu i/lub Planu Etapu (nastpnego). (Uwaga: bdzie to wymagao kolejnej iteracji Planowanie podprocesu (IP2) i prawdopodobnie ponownego przegldu elementw Projektu Uzasadnienia Biznesowego.) Gdy ujawnione ryzyko jest znaczne, Komitet Ster ujcy mo e wymaga Kierownika modyfikacji Projektu planw poprzez: uwzgldnienie w nich odpowiednich dziaa zapobiegawczych, okrelenie w bud ecie rodkw na te dziaania i/lub przygotowanie planu rezerwowego, od

dodanie bud etu na ten plan rezerwowy, do wykorzystania tylko wtedy, gdy zagro- zmaterializuje enie si. W celu podjcia ostatecznej decyzji o zasadnoci projektu, nale y porwna uzgodnione korzyci ze zidentyfikowanymi kosztami i zagro Je eli wymienione wy eniami. wska na konieczno dokonania ej kroki ktr e mogyby mie istotny wpyw zmian, na by poinformowany o tym Uzasadnienie Biznesowe, Komitet Sterujcy powinien tak wczenie, jak to jest mo liwe, gdy mo e by konieczne przekazanie tego Zagadnienia Projektowego na poziom kierownictwa firmy lub programu.

5.6.4.

Odpowiedzialno

ma

Za podproces odpowiada Kierownik wspomagany tam, gdzie to Projektu, zastosowanie, przez osoby penice r ol Wsparcia Projektu, i kierujcy si wskazwkami osb penicych obowizki Nadzoru Projektu. Kierownik Projektu powinien nieformalnie przedyskutowa Uzasadnienie Biznesowe i zagro enia z Komitetem Sterujcym pr zed umieszczeniem w Dokumencie Inicjujcym ich Projekt.

64

PRINCE2

INICJOWANIE PROJEKTU (IP)

5.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 5.3. IP3 Informacja Objanienie

Zao enia Projektu Wejcie Dokument zawiera sformuowane na wysokim poziomie oglnoci opisy przewidywanych korzyci biznesowych i zagro e, tak jak to okrelono w podprocesie Przygotowanie Projektu (PP). Formua Realizacji Projektu Wejcie Zawiera informacje o sposobie, w jaki maj by przeprowadzone prace, i mo e dostarczy danych zarwno dla Uzasadnienia Biznesowego, jak i do analizy zagro e.

Rejestr Ryzyka Aktualizacja Dodanie nowo zidentyfikowanych zagro e. Zmodyfikowanie szczegw zagro e, ktre ulegy zmianie. Plan Projektu Aktualizacja Uaktualnienie o istotne dodatkowe dziaania i zapotrzebowanie na zasoby, su ce przeciwdziaaniu nara eniu projektu na ryzyko. Uzasadnienie Biznesowe Aktualizacja Zaczerpnite z Zao e Projektu i uaktualnione o najnowsze (bardziej szczegowe) informacje.

5.6.6.

Kryt eria oceny ci jako Czy koszty uniknicia zagro enia s mniejsze od kosztw wynikajcych z jego zmaterializowania si? Czy uzasadniona jest deklaracja kor zyci biznesowych, ktre mog by uzyskane przewidywanemu dziki wynikowi kocowemu projektu? Czy przeprowadzono analiz wra liwoci Uzasadnienia Biznesowego? Czy przedstawiona informacja ma form zrozu mia dla Komitetu Sterujcego? Czy s przygotowane plany, wedug ktrych u ytkownik produktu zrealizuje korzyci? Czy Uzasadnienie obowizuj- w cymi firmie? Biznesowe przygotowano zgodnie ze standardami

Wskazwki i rady
Ka de zagro enie mo e generowa kolejne zagro enia w acuchu przyczynowo -skutkowym. Kierownik Projektu musi podj decyzj, w ktrym miejscu i czy w ogle nale y ten acuch przerwa, aby mc zarzdza ryzykiem.

65

INITIATING A PROJECT (IP)

Mo e by wskazane u ycie modelu profilu ryzyka dla przedstawienia Komitetowi Sterujcemu zestawienia zagro e udokumentowanych w Rejestrze Ryzyka. Jeli projekt jest czci programu, nale y u ywa mechanizmu monitorowania ryzyka stosowanego w programie, chyba e istniej uzasadnione przyczyny, aby tak nie postpi. Sensowne mo e by prowadzenie na poziomie programu obsugi Rejestrw Ryzyka wszystkich projektw. Zwykle finansowanie projektu zapewnia klient, ale s sytuacje, kiedy to dostawca w caoci lub w czci finansuje projekt (np. inicjatywa prywatnej fundacji lub partnerstwo prywatno-publiczne). Mo e to da klientowi mniejsze prawa do interweniowania lub kontroli projektu i mo e ograniczy mo liwo klienta domagania si uwzgldnienia dziaa su cych unikniciu lub redukcji ryzyka. Klient i dostawca maj prawdopodobnie r ne Uzasadnienia Biznesowe
7

PRINCE2

Nale y wzi pod uwag warunki patnoci dla dostawcw. Patnoci mog by przekazywane regularnie w trakcie caego projektu, w odstpach ustalanych wedug dostawy okrelonych produktw, lub dokonywane w formie jednej patnoci na kocu projektu. Zmierzenie stopnia osignicia korzyci biznesowych wymaga czsto, i to ramach projektu, ustalenia stanu odniesienia. Z chwil wdro enia nowego produktu do eksploatacji, sytuacja ulega zmianie, co uniemo liwia waciwe porwnanie. Wskazane jest usta8 lenie tego stanu odniesienia , zanim projekt wejdzie w ycie.

5.7.
5.7.1.

Ustanowienie Elementw Sterowania (IP4)

Podstawowe zasady

Ka da decyzja dotyczca projektu powinna by podejmowana na czas, przez osob lub grup osb najbardziej odpowiedni do jej podjcia i musi si opiera na dokadnych informacjach. Ten podproces zapewnia, e zostanie stworzony odpowiedni system komunikacji, sterowania i monitorowania.

5.7.2.

Kontekst projektem, na podstawie informacji

Podproces okrela elementy sterowania ustalonych we wczeniejszych podprocesach IP.

7 8

Dotyczce danego projektu przypis tumacza. Tzn. zmierzenie i zarejestrowanie parametrw dotychczasowej sytuacji przypis tumacza.

66

PRINCE2

INICJOWANIE PROJEKTU (IP)

Plan Jako ci Projektu

Dokumentacja Do kumentacja zarz dcza zarz dcza

Rejestr Ryzyka Plan Projektu Zakresy obowi zkw Elementy sterowania projektem Plan Komunikacji

IP4 Ustanowienie Elemen tw Sterowania

Rysunek 5.6. Sterowania

Ustanowienie

Elementw

5.7.3.

Opis procesu

Podproces ma na celu: ustalenie wymaganego przez Komitet Sterujcy zakresu kontroli i raportowania w projekcie, po jego zainicjowaniu; przygotowanie elementw sterowania, ktre s odpowiednie do ryzyka i zo onoci projektu ; ustalenie zakresu bie cego monitorowania, majcego zapewni, e projekt bdzie sterowany w sposb sprawny i skuteczny; wskazanie wszystkich zainteresowanych projektem stron i uzgodnienie ich potrzeb w zakresie komunikacji. Dla osignicia powy szych celw nale y wykona podane ni ej kroki: przyporzdkowa r ne poziomy podejmowania decyzji wymaganych w projekcie do odpowiednich poziomw zarzdzania projektem; ustali wszelkie procedury podejmowania decyzji, ktre mog by waciwe, by e poprzez przystosowanie procedur obowizujcych w ramach mo istniejcychzarzdzania jakoci lub innych standardowych pr ocedur jeli jest systemw to liwe; mo wczy do zakresw obowizkw, tam gdzie jest to waciwe, uprawnienia i obowizki dotyczce podejmowania decyzji; ustali granice etapw zarzdczych w celu zapewnienia waciwego poziomu sterowania; ustali tolerancje dla projektu oraz procedury przekazywania Zagadnie Projektowych na wy szy szczebel zarzdzania (przez Kierownika Zespou do Kierownika Projektu, przez Kierownika Projektu do Komitetu Sterujcego i przez Komitet Sterujcy do kierownictwa firmy lub programu); okreli rozmiar Grup Zada, ktre bd realizowane, w szczeglnoci, gdy wystpuj dostawcy zewntrzni; ustali potrzeby informacyjne zwizane z ka dym z procesw podejmowania decyzji; ustali mechanizmy informacyjne; monitorowania, by zaspokoi te potrzeby

67

INITIATING A PROJECT (IP)

PRINCE2

ustali wymagania dotyczce zasobw potrzebnych do monitorowania i dostarczania informacji; uwzgldni mechanizmy monitorowania w planach i zakresach obowizkw, tam gdzie jest to waciwe; zidentyfikowa wszystkich interesariuszy spoza zespou zarzdzania projektem z nimi ich potr zeby informacyjne oraz informacje, ktrych projekt i uzgodni b- potrzebowa od nich. Zdefiniowa w Planie Komunikacji zawarto dzie wiadomoci, odbiorc i nadawc, metod i czstotliwo dla tych wszystkich wiadomoci zewntrznych; opracowa Plan Komunikacji , o zawartoci przedstawionej w Dodatku A Opisw Produktw ; ustali procedury sprawozdawczych. potrzebne do przygotowania i dystrybucji informacji Zarys y

Jeli projekt jest czci programu, Plan Komunikacji musi okrela sposb przekazy- informacji wania do tego programu.

5.7.4.

Odpowiedzialno

osb

Za podproces odpowiada Kierownik korzystajc z pomocy Projektu, rol Wsparcia Projektu i porad osb penicych penicych Nadzoru obowizki Projektu.

5.7.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 5.4. IP4 Informacja Objanienie

Plan Projektu Aktualizacja Powinien by uaktualniony o dziaania i zasoby potrzebne do monitorowania i sterowania. Rejestr Ryzyka Aktualizacja Poziomy zagro enia bd miay wpyw na skal i dyscyplin dziaa sterujcych. Nowe lub zmienione zagro enia mog by ujawnione jako skutek definiowania dziaa sterujcych i monitorujcych. Nale y tak e przewidzie przygotowanie mechanizmw monitorowania zagro e w miar, jak bd si one rozwijay. Plan Jakoci Projektu Wejcie Osignicie jakoci jest jednym z obszarw, ktry wymaga monitorowania i sterowania. Istnieje zatem potrzeba skoordynowania elementw sterowania projektem z Planem Jakoci Projektu. Plan Komunikacji Wyjcie Okrelenie wszystkich kanaw komunikacji, czstotliwoci, metod i przyczyn kontaktowania si.

68

PRINCE2

INICJOWANIE PROJEKTU (IP)

Informacja Objanienie

zarzdcza

Wykorzystanie

Zakresy obowizkw Aktualizacja Jeli jest to wskazane, nale y wczy do zakresw obowizkw uprawnienia i obowizki dotyczce podejmowania decyzji. Elementy sterowania projektem Wyjcie Bd stanowiy cz Dokumentu Inicjujcego Projekt.

Kryt eria oceny ci jako Czy decyzje s przypisane osobom odpowiednio wyposa onym i upowa nionympodejmowania do tych decyzji? Myl przewodni nastpnych punktw jest uwypuklenie motta Nie za mao, nie za o: du Czy elementy sterowania s odpowiednie dla ryzyka, skali i zo onoci projektu? Czy przyjty poziom sformalizowania jest odpowiedni dla ryzyka, skali i zo ono- projektu? Odnosi si to do takich spraw, jak: raportowanie, procedury ci monito- i zakres obowizkw. rowania Czy wszyscy uczestnicy anga uj si w dostarczanie informacji i dziaaj w opar- nie? ciu o Czy w trakcie przygotowania Planu Komunikacji informa- wszystkich cyjne osb zainteresowanych projektem? Czy tolerancje projektu zostay jasno okrelone? uwzgldniono potrzeby

5.7.6.

Wskazwki i rady
Tworzc elementy sterowania projektu, nale y rozwa y potrzeby komunikacyjne oraz podejmowane decyzje. Nale y upewni si, e poziom sterowania jest waciwy dla projektu. Nale y unika nadmiernej kontroli realizowanej dla samej kontroli. Je eli projekt jest czci programu, nale y upewni si, czy wymagania sprawozdawcze programu bd zaspokajane przez proponowany dla projektu system sterowania. Jeli informacje powinny by przesyane zwrotnie do programu, mo liwym rozwizaniem jest przesyanie przez projekt raportw do osb dziaajcych w programie lub wprowadzenie do projektu przedstawiciela(-i) programu. Zaleca si, by przedstawiciele programu uczestniczyli w szacowaniu wpywu zmian. W trakcie budowy harmonogramu projektu nale y ustali odpowiednie kamienie milowe, takie jak koce etapw czy przygotowanie raportw, do wykorzystania przez program albo inne projekty, w celu umo liwienia wymaganego przez program monitorowania postpw projektu. Nale y prbowa ograniczy zewntrzne wymagania komunikacyjne do kopii raportw istniejcych w projekcie.

69

INITIATING A PROJECT (IP)

W programie ka dy projekt mo e realizowa zarzdzanie zmianami w granicach przekazanych 9 uprawnie.

PRINCE2

5.8.
5.8.1.

Ustanowienie Systemu Dokumentacji (IP5)

Podstawowe zasady

Wa ne jest, by w trakcie realizacji projektu ledzi wszystkie wytwarzane infor macje o projekcie i jego produktach specjalistycznych. Istnieje potrzeba stworzenia mo liwo- zarzdzania r nymi wersjami produktw oraz wyszukiwania informacji ci szybko i niezawodnie. Ustanowienie ju na starcie projektu sensownego i pragmatycznego sy stemu gromadzenia dokumentacji mo e zagodzi te problemy.

5.8.2.

Kontekst

Ten podproces pobiera informacje z Planu Projektu i dodaje struktur systemu gro madzenia dokumentacji do Planu Zarzdzania Konfiguracj. Proponowany system groma- dokumentacji zarzdczej jest przedstawiony w Dodatku dzenia E.
Plan Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Plan Jako Plan Zarz

ci Projektu dzania Konfiguracj

IP5 Ustanowienie Systemu Dokumentacji

Rejestr Zagadnie Rejestr Do wiadcze

Rysunek 5.7. Dokumentacji

Ustanowienie

Systemu

5.8.3.

Opis procesu

Podproces ma na celu: ustanowienie systemu przechowywania i odszukiwania wszystkich informacji z zarzdzaniem projektem, wykonanymi pracami sprawdzajcymi zwizanych jako oraz z samymi produktami, ktry zapewni odpowiednie wsparcie dla zespou projektowego i dla wdro enia zarzdzania zmianami; przydzielenie odpowiedzialnoci za zarzdzanie systemem gromadzenia doku mentacji . Mo e by tak, e system zarzdzania konfiguracj, ktry ma by u yty, zrealizuje po- sze cele dla wybranych lub wszystkich produktw wy projektu.
9

Przez program przypis tumacza.

70

PRINCE2

INICJOWANIE PROJEKTU (IP)

W celu osignicia powy szych celw, nale y podj nastpujce kroki: ustali, jakie informacje bd powstaway w trakcie projektu wymagay przechowywania;

bd

ustali, jakie produkty bd wytwarzane w trakcie projektu i jakie s wymagania zwizane z ich przechowywaniem; ustali, jakie potrzeby zwizane z wyszukiwaniem informacji maj osoby wymienione w Planie Komunikacji; ustanowi systemy gromadzenia dokumentacji, ktre s odpowiednie zarwno dla zidentyfikowanych potrzeb przechowywania, jak i wyszukiwania. W trakcie tego podprocesu zakadane s rwnie Rejestr Zagadnie i Rejestr Dowiadcze.

5.8.4.

Odpowiedzialno

Za podproces odpowiada Kierownik korzystajc z pomocy osb Projektu, rol Wsparcia Projektu i porad osb penicych penicych Nadzoru obowizki . Projektu Jeli projekt jest czci programu, system gromadzenia dokumentacji na poziomie pro- musi by spjny z systemem gromadzenia dokumentacji na poziomie progr jektu amu.

5.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 5.5. IP5 Informacja Objanienie

Plan Projektu Wejcie Zawiera pen informacj o produktach, ktre ma wytworzy projekt. Plan Jakoci Projektu / Plan Zarzdzania Konfiguracj Aktualizacja Uaktualniany o system gromadzenia dokumentacji, stanowicy cz Planu Zarzdzania Konfiguracj.

Rejestr Zagadnie Wyjcie Zao ony i gotowy do rejestrowania Zagadnie Projektowych. Rejestr Dowiadcze Wyjcie Czysty rejestr gotowy do odnotowywania tych aspektw projektu, ktre id dobrze lub le.

5.8.6.

Kryt eria oceny ci jako Czy formalizm i rygory systemu gromadzenia doku mentacji s odpowiednie do skali, ryzyka i zo onoci projektu? Czy system pasuje do kultury firmy? Czy system wyszukiwania dostarczy wszystkich potrzebnych informacji w sposb u yteczny i na czas? dokadny, Czy dokumentacja projektu dostarczy informacji koniecznych do spenienia wy- audytw? maga

71

INITIATING A PROJECT (IP)

PRINCE2

Czy dokumentacja projektu dostarczy zapisw historycznych koniecznych do potwierdzenia dowiadcze z projektu?

Wskazwki i rady
Sensownie zaprojektowane, skomputeryzowane wsparcie pozwala na uniknicie stosowania wielu kopii i zapewnia, e personel ma dostp tylko do ostatnich wersji informacji. Kluczem do sukcesu jest kompletny i jednoznaczny system nazewnictwa i numerowania wersji, z ktrego wynika co najmniej, jaka informacja jest przegldana, a Kierownik Projektu ma pewno, e istnieje niezawodna kontrola wszystkich oryginalnych wersji informacji i produktw. Niezale nie od wykorzystywania dokumentw papierowych lub elektronicznych, nale y opracowa formalny system zarzdzania konfiguracj i wyznaczy Bibliotekarza Konfiguracji, tak jak to przedstawiono w Rozdziale 19 Zarzdzanie konfiguracj. Nale y pamita, e dokumentacja niekoniecznie oznacza dokumentacj sporzdzon na papierze. Dokumentacja projektu mo e obejmowa szeroki zakres mediw i wszystkie one musz by wzite pod uwag. Trzeba zastanowi si, czy nale ycie uwzgldniono wpyw przestrzennego lub geograficznego rozproszenia personelu projektu.

5.9.
5.9.1.

Zestawienie Dokumentu Inicjuj

Podstawowe zasady

cego Projekt (IP6)

Konieczne jest istnienie centralnego miejsca, w ktrym umieszczone bd wszystkie odnoszce si do tego co, dlaczego lub po co, kto, jak, gdzie, kiedy i informacje za ile, w celu uzgodnienia przez gwnych interesariuszy, a nastpnie w celu ukierunkowania i informowania osb zaanga owanych w pr ojekt.

5.9.2.

Kontekst

Podproces pobiera wszystkie informacje z innych podprocesw IP i wytwarza Doku- Inicjujcy Projekt w ramach przygotowa decyzji Komitetu Sterujcego ment dotyczcej zezwolenia na realizacj projektu, podejmowanej w pr Zezwolenie na ocesie Realizac Projekt ( ZS2) . Podproces ten wywouje rwnie proces Zar dzanie j u (ZE), by podsumowa wyniki Etapu inicjowania oraz przygotowa Plan z Zakresem Etap u Etapu (nastpnego) .

72

PRINCE2

INICJOWANIE PROJEKTU (IP)

Dokumentacja Dokumentacja zarz dcza zarz dcza

IP6 Zestawienie Dokumentu Inicjuj cego Projekt

Zao enia Projektu Struktura zespou zarz dzania projektem Zakresy obowi zkw Formua Realizacji Projektu Plan Jako Projektu ci Plan Projektu Uzasadnienie Biznesowe Rejestr Ryzyka Elementy sterowania Plan Komunikacji Tolerancje dla projektu

D okument Inicjuj cy P rojekt

ZS2 Zezwolenie na Realizacj Projektu

ZE Zarz dzanie Zakresem Etapu

Rysunek 5.8. Projekt

Zestawienie Dokumentu Inicjujcego

5.9.3.

Opis procesu

Podproces ma na celu: dostarczenie podstaw do pojcia decyzji w Zezwolenie na podprocesie Realizacj Projekt (ZS2) ; u dostarczenie poziomu odniesienia dla wszystkich innych decyzji zarzdczych, kt- musz by podjte w trakcie re projektu; dostarczenie podstawowej informacji wszystkim, ktrzy musz mie wiedz o projekcie ; przygotowanie Planu Etapu (nastpnego) do zatwierdzenia przez Komitet Sterujcy. Dla osignicia tych celw wa ne jest, aby zrozumie, e informacje bd przechowywane i prezentowane na r ne sposoby i Dokument Inicjujcy Projekt fizycznie mo e ie n by pojedynczym dokumentem. Aby osign powy sze cele, nale y podj nastpujce kroki: wywoa proces Zar dzanie Zakresem (ZE) w celu przygotowania z Etapu Etapu (nastpnego) i zamknicia Etapu Planu inicjowania; zdecydowa, jak najlepiej informacje mog by uo one i przechowywane, aby zrealizowa przedstawione wy ej cele podprocesu dla tego konkretnego projektu; zebra i poczy informacje z poprzednich podprocesw; utworzy struktur organizacyjn projektu na podstawie struktury zespou zarz- projektem i zakr esw obowizkw. Mo e to tak e obj dokoczenie dzania przydzielania rl, ktre nie zostay jeszcze przydzielone podczas podpr ocesw PP2 i PP3; skonstruowa definicj projektu na podstawie zawartoci Zao e Projektu Realizacji Projektu, zmodyfikowanych zapisami w Planie Projektu i Formuy ; przeprowadzi kocowe sprawdzenie krzy owe informacji zawartych w r nych dokumentach, by zapewni, e s one spjne;

73

INITIATING A PROJECT (IP)

PRINCE2

doda wymagane informacje opisowe, wyjaniajce lub uatwiajce korzystanie, opisem przyczyn uruchomienia cznie z projektu; zestawi Dokument Inicjujcy Projekt (DIP); przekaza informacje wymagane dla Zezwolenie na Projek podprocesu Realizacj t (ZS2). u Je eli projekt jest czci programu, kierownictwo programu musi sprawdzi 10 oddziaujcych Dokument Projekt pod ktem wszelkich Inicjujcy na portfel zmian projektw programu. Gdy uzgodni si jakie zmiany, powinno to znale odbicie w portfelu projektw. Je eli zmiany te mog wpyn na inne pr ojekty (np. produkt potr zebny w innym projekcie zostanie wytworzony pniej ni uprzednio zakadano), wtedy trze- poinformowa ba wszystkie projekty programu.

5.9.4.

Odpowiedzialno

Kierownik Projektu odpowiada za wytworzenie tego korzystajc z dokumentu, osb penicych rol Wsparcia Nale y zapewni cise pomocy konsultacje treci Projektu. DIP jest ona z Nadzorem Projektu, w miar jak przygotowywana.

5.9.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 5.6. IP6 Informacja Objanienie

Zao enia Projektu Wejcie Dostarcza informacje dla czci Przyczyny Uruchomienia Projektu i Definicja Projektu Dokumentu Inicjujcego Projekt (DIP). Struktura zespou zarzdzania projektem i zakresy obowizkw Formua Realizacji Projektu Wejcie Informacje dla czci Organizacja projektu DIP. Wejcie W celu wczenia do DIP.

Plan Jakoci Projektu Wejcie W celu wczenia do DIP. Plan Projektu Wejcie W celu wczenia do DIP. Uzasadnienie Biznesowe Wejcie W celu wczenia do DIP.

Rejestr Ryzyka Wejcie W celu wczenia do DIP. Elementy sterowania projektem Wejcie W celu wczenia do DIP.

Plan Komunikacji Wejcie W celu wczenia do DIP.

10

Wprowadzanych do poprzednich ustale zawartych np. w Zleceniu Przygotowania Projektu lub Zaoeniach Projektu przypis tumacza.

74

PRINCE2

INICJOWANIE PROJEKTU (IP)

Informacja Objanienie

zarzdcza

Wykorzystanie

Tolerancje dla projektu Wejcie W celu wczenia do DIP. Dokument Inicjujcy Projekt Wyjcie Kocowy produkt podprocesu Zestawienie Dokumentu Inicjujcego Projekt (IP6) i inicjowania projektu.

5.9.6.

Kryt eria oceny ci jako Czy Dokument Inicjujcy Projekt zaspokoi wszystkie potrzeby informacyjne odbiorcw? Czy atwo jest aktualizowa te czci Dokumentu Inicjujcego Projekt, ktre s dynamiczne? Czy zachowano czciami? spjno informacji midzy wszystkimi

Wskazwki i rady
Nale y si upewni, e prezentacyjne aspekty Dokumentu Inicjujcego Projekt s dobrze przemylane. Po wczeniu wszystkich szczegowych Opisw Produktw i zakresw obowizkw, kompletny dokument mo e mie znaczn objto. Nale y u ywa zacznikw w celu zamieszczenia szczegw i publikowa je tylko na danie. Na przykad, je eli Komitet Sterujcy chce, by Dokument Inicjujcy Projekt by tak krtki, jak to tylko mo liwe, to w DIP mo na umieci jedynie schemat struktury zespou zarzdzania projektem, a zakresy obowizkw przechowywa w dokumentacji kierownictwa projektu. Jeli projekt jest czci programu, Dokument Inicjujcy Projekt powinien by tworzony z uwzgldnieniem potrzeb tego programu. Jednym ze sposobw zagwarantowania tego jest udzia kierownictwa programu w przygotowaniu Dokumentu Inicjujcego Projekt.

75

6.

ZAR Z D ZAN IE S TRATEG IC ZNE P ROJ EK TE M (ZS ) (Directing a Project - DP)

Po tw ie r d ze ni e o rg a n i za cj i p ro j e kt u

U zg o d n ie n i e c e l w r o j ek tu p

Po t wi er d ze n i e p r awi d o ci wo m kn c ia p ro j e k za i tu

Z a twi er d ze n i e p l a n u r zyg o t o wa n ia k o n tr ak tu p a p r o j ek n t

I n fo r mo wan i e n ac ze l n eg o ie r o wn i ctw k a

Z a twi e rd z en i e te g o ko n t ra kt u

Po d e j m o wan i e d ec y zj i o ty cz c yc h g wn y d p ro b l ech m w

Z a twi e rd ze n i e k a d e g o ta p u p ro j e e ktu

Rysunek 6.1. Projektem

Zarys procesu Zarzdzanie Strategiczne

6.1.

Podstawowe zasady

Naczelne kierownictwo, ktre ma uprawnienia i ponosi odpowiedzialno za: okrelenie, czego si wymaga od projektu, zatwierdzenie funduszy dla projektu, zaanga owanie zasobw, utrzymywanie kontaktw z zainteresowanymi stronami zewntrznymi, bdzie zwykle delegowao bie ce obowizki zwizane z zarzdzaniem Kierownikowi Projektu. Jednak e Przewodniczcy musi sprawowa pen kontrol i odpowiada kluczowe za decyzje. Wa ne jest tak e, aby poziomy uprawnie i procesy podejmowania decyzji byy jasno okrelone.

77

DIRECTING A PROJECT (DP)

PRINCE2

6.2.

Kontekst

Proces Zar dzanie Strategiczne (ZS) przebiega od Przygotowani z PP )i trwa a do zamknicia pr ojektu, obejmujc nastpujce Projektem procesu e Projektu ( prace: zezwolenie na zainicjowanie projektu; zapewnienie kierownictwa i sterowania w trakcie caego projektu; utrzymywanie cznoci z kierownictwem firmy czy programu; zatwierdzenie zamknicia projektu. Powy szy zakres prac nie obejmuje bie cych dziaa Kierownika Projektu. Ten proces jest przeznaczony dla poziomu zar zdzania ponad Kierownikiem Projektu, czyli dla Komitetu Sterujcego. Komitet Sterujcy zarzdza odchyleniami. Monitoruje projekt, wykorzystujc raporty i steruje, wykorzystujc niewielk liczb punktw decyzyjnych. Nie powinna wystpowa potrzeba innych narad Komitetu Sterujcego dla oceny postpw. Kier ownik Projektu bdzie informowa Ko mitet Sterujcy o wszelkich sytuacjach nadzwyczajnych. W trakcie realizacji projektu niezbdny jest przepyw informacji od Komitetu Steruj- kierownictwa firmy lub programu. Ta potrzeba i sposb jej zaspokojenia cego do powinny by udokumentowane w Planie Komunikacji, ktry jest czci Dokumentu Inicjujcego Projekt.
Wszelkie zainteresowane strony

ZS

Zarz dzanie Strategiczne Projektem ZS4 Podejmowanie Decyzji Dora nych

Z S1 Z ezwolenie na Z ainicjowanie Projektu

ZS2 Zezwolenie na Realizacj Projektu

ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

ZS5 Zatwierdzenie Zamkni cia Projektu

PP Przygotowanie Projektu

IP Inicjowanie Projektu

SE Sterowanie Etapem

ZE Zarz dzanie Zakresem Etapu

ZP Z amykanie Projektu

Rysunek 6.2. Projektem 78

Zarzdzanie

Strategiczne

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

6.3.

Opis procesu

Proces Zar dzanie Strategiczne (ZS) ma na z Projektem celu: zagwarantowanie ostatecznego sukcesu projektu, ocenianego popr zez: zdolno produktw projektu do dostarczenia korzyci biznesowych wyznaczonych w Uzasadnieniu Biznesowym; wykonanie przedsiwzicia w uzgodnionym czasie i po uzgodnionych kosztach oraz dotrzymanie parametrw jakociowych; zarzdzanie zidentyfikowanymi zagro eniami dla projektu; zapewnienie efektywnego zarzdzania wszystkimi osobami i zasobami zwizanymi z projektem; przydzielanie wymaganych zasobw; podejmowanie decyzji dotyczcych zmian wnioskowanych przez Kierownika Projektu; zapewnienie oglnego kierownictwa i doradztwa; podejmowanie decyzji w sytuacjach nadzwyczajnych; zapewnienie spjnoci projektu i jego produktw z planami biznesowymi firmy lub programu i otoczeniem zewntrznym; zagwarantowanie, e zostan stworzone konieczne mechanizmy komunikacji; ponoszenie odpowiedzialnoci za wiadomoci i informacje o projekcie przekazywane na zewntrz.

Proces obejmuje strategiczne kierowanie projektem w caym jego cyklu ycia. Komitet proaktywnie zarzdza reakcjami projektu na otoczenie zewntrzne. Sterujcy Komitet Sterujcy powinien stosowa zarzdzanie . Czonkowie Komitetu odchyleniamizwykle zajtymi prac czonkami kierownictwaSterujcego s firmy o szerokim zakresie obowizkw i dlatego zapotrzebowanie na ich czas, w ktrym wypeniaj swoje obowizki wobec projektu, powinno by sprowadzone do minimum. Podstawowe z tych obowizkw to: oglne zarzdzanie strategiczne i podejmowanie decyzji; udostpnianie zasobw. Jeli projekt jest czci programu, upowa nienie Komitetu Sterujcego do zarzdzania jest delegowane przez kierownictwo programu. Kiedy wymagane s projektem decyzje wykraczajce poza przyznane uprawnienia, wwczas ich podjcie nale y do kierownictwa programu. Kluczowe dla Komitetu Sterujcego procesy s przewa nie wyzwalane zdarzeniamiuwag jego czonkw na niewielkiej liczbie gwnych punktw i skupiaj decyzyjnych, nieformalnych dyskusji, gdy s potrzebne. Te kluczowe procesy dziel z dodatkiem si na cztery gwne obszary: inicjowanie (uruchamianie projektu na waciwych ; podstawach)

79

DIRECTING A PROJECT (DP)

PRINCE2

ponowne oceny projektu na granicach etapw lub w mo mencie zagro enia istot- odchyleniami (zaanga owanie w dalsze planowane prace po sprawdzeniu nymi dotychczasowych rezultatw) ; decyzje dorane (monitorowanie postpw, udzielanie porad i wytycznych); zamykanie projektu (zatwierdzenie rezultatw i doprowadzenie do kontrolowanego zamknicia, lub przedwczesne zamknicie projektu, gdy Uzasadnienie Biznesowe wa no). stracio sw Skalowalno

6.3.1.

Poniewa ten proces obejmuje dziaania Komitetu Sterujcego i opisuje jego kontrol nad przebiegiem projektu, w rkach Komitetu Sterujcego le y decyzja, jak dalece formalnie czy nieformalnie bdzie chcia si posugiwa swoimi elementami sterowania. lub du ych projektach or az tych, w ktrych wykorzystuje si zewntr W rednich znych dostawcw, zaleca si stosowanie procesu w sposb formalny - z naradami, na pimie iraportami akceptacjami etapw podpisanymi pr zez Komitet Sterujcy. Dla maych projektw, Komitet Sterujcy mo e si zdecydowa na: przyjmowanie niektrych lub wszystkich raportw ustnie; ustn wymian informacji i decyzji zamiast formalnych narad. Nale y jednak dokumentowa wszelkie decyzje, tak aby mogy by przedmiotem audy- pniejszym okresie. Szczeglnie nale y zwrci uwag na r ealizowanie tu w trzech elementw tego procesu: przegld (dokonywany na koniec Etapu inicjowania) sprawdzajcy, czy osignito pene zrozumienie, co powinno by dostarczone przez projekt zaleca si jego udokumentowanie na pimie; ustanowienie tolerancji i pr ocedury obsugi istotnych odchyle; potwierdzenie, na zakoczenie projektu, e dostarczono akceptowalne produkty i nie pozostawiono spraw niezaatwionych. Wskazwki i rady
Komitet Sterujcy zarzdzajc odchyleniami powinien utrzymywa rwnowag pomidzy dwiema skrajnociami - z jednej strony - wtrcaniem si w sprawy projektu, a z drugiej - pozostawieniem Kierownika Projektu samemu sobie, gdy tylko projekt si rozpocznie. Powodzenie tego procesu zale y w du ym stopniu od waciwego zrealizowania podprocesu Ustanowienie Elementw Sterowania (IP4) i z tego te powodu ten wanie podproces wymaga aktywnego udziau Komitetu Sterujcego.

80

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

6.3.2.

Inicjowanie projektu

Kierownictwo firmy lub programu powinno potwierdzi nominacje Komitetu Steruj- pozostaych czonkw zespou zarzdzania projektem. Jest to realizowane cego i w podprocesach Mianowanie cego i Kierownika (PP1) Przewodnicz Projektu (PP3). i Mianowanie Czonkw Zespou dzania Wa ne jest Zarz potwierdzenie przez te osoby chci zaanga owaniaProjektem si w prac, ktra ma by wykonana. Na pocztku Komitet Sterujcy zatwierdza jedynie plan dla Etapu inicjowania, ktry to powinien by relatywnie krtki. Celem Etapu inicjowania jest przygotowanie etap na odpowiednim poziomie oglnoci planu dla caego projektu, udokumentowanie jego Uzasadnienia Biznesowego , przeanalizowanie zwizanych z projektem zagro e podjcie i w stosunku do nich decyzji a tak e zatwierdzenie planu dla zarzdczych, nastpnego etapu. Plan Etapu inicjowania jest przygotowywany w Planowa podprocesie nie Etapu (PP6). Inicjowania Na kocu Etapu inicjowania Komitet Sterujcy musi osign porozumienie, czy kontynuowanie projektu ma wyrany sens biznesowy. Je eli tak i je eli zatwierdzi on Plan Projektu oraz Planu Etapu (nastpnego), wyra a tym samym zgod na kontynuacj prac i przejcie do nastpnego etapu.

6.3.3.

Granice etapw

W trakcie Etapu inicjowania, Komitet Sterujcy i Kierownik Projektu powinni uzgodni projektu podzia na Podzia jest zwykle proponowany przez Kierownika Pr etapy. ojektu i zatwierdzany przez Komitet Sterujcy w trakcie nieformalnych dyskusji, po przygotowaniu propozycji Planu Projektu. W zasadzie Komitet Sterujcy zezwala Kierownikowi Pr ojektu na realizacj w tym sa- czasie tylko jednego etapu. Na koniec ka dego etapu Komitet Sterujcy mym dokonuje stanu caego projektu i zatwierdza Plan Etapu nastpnego tylko wtedy, przegldu gdy uzna, e Uzasadnienie Biznesowe nadal pozostaje w mocy, a projekt dostarczy to, czego od si niego oczekuje. Je eli w trakcie etapu pojawi si powa ne problemy, Kier ownik Projektu musi przygo- Raport o Istotnych Odchyleniach, a wwczas na jego podstawie Komitet towa Steruj- e poleci przygotowanie Planu Nadzwyczajnego, ktry powinien cy mo przywrci kontrol nad etapem (lub projektem). Jest to cz zarzdzania . odchyleniami

6.3.4.

Decyzje dora

ne

Gwnym celem Komitetu Sterujcego jest zapewnienie w trakcie caego projektu ogl- zarzdzania strategicznego i przewodnictwa oraz zapewnienie, e projekt i nego jego produkty pozostan zgodne z planami biznesowymi. Dziaania su ce osigniciu tych celw s formalnie zdefiniowane w ramach Planw ,jednak e Komitet Etapu chcia je monitorowa, otrzymujc od Kierownika Projektu odpowiednie Sterujcy bdzie raporty kluczowych spraw. dotyczce Komitet Sterujcy mo e odczuwa potrzeb udzielenia Kierownikowi Projektu rad i wytycznych lub te mo e wystpi potrzeba zatwierdzenia jakich decyzji, ktre musi e kierownik podj np. w zwizku z potencjalnymi ten problemami. 81

DIRECTING A PROJECT (DP)

PRINCE2

Komitet Sterujcy musi zapewni kierownictwu firmy lub programu informacje zwrot- postpach projektu w trakcie jego ne o realizacji. Komitet Sterujcy musi mie tak e pen wiadomo wszelkich zmian strategii firmy lub otoczenia zewntrznego i uwzgldni oddziaywanie tych zmian, odpowiednio ukierunkowujc Kierownika Projektu.

6.3.5.

Zamkni cie projektu

Projekt koczy si potwierdzeniem Komitetu , e wszystko to, czego Sterujcego oczekiwano, zostao dostarczone na prawidowym poziomie jakoci oraz tam, gdzie ma to zastosowanie, potwierdzeniem, e w aktualnym stanie mo e by u yte, eksploatowane, serwisowane i utrzymywane. Po zakoczeniu projektu mo e si pojawi konieczno zrealizowania dziaa nastp- w odniesieniu do ktrych Komitet Sterujcy musi podj decyzje i skierowa czych, je odpowiednich gremiw. do Mo na uzgodni plan i dat przegldu poprojektowego. Jest to ten moment w przyszo- ktrym bdzie mo na oceni korzyci biznesowe i wyniki uzyskane dziki ci, w kocowym produktom projektu. Wszystkie zdobyte dowiadczenia, ktre mog przynie korzyci innym projektom, s tak e kierowane do waciwego gremium. Na koniec, nale y rozwiza infrastruktur wspierajc projekt. Proces zamykania bdzie zmodyfikowany w sy tuacjach, kiedy projekt jest zamykany przedwczenie. Prawdopodobnie pojawi si tak e i tu dziaania nastpcze, ale nie wszystkie produkty bd wytworzone i niewiele, lub zgoa nic, mo e pozosta do utrzymania. Jest mao prawdopodobne, aby odby si peny przegld poprojektowy, ale przegld Raportu Kocowego Projektu i Raportu o Dowiadczeniach mo e by bardzo dla zrozumienia, dlaczego projekt zosta zamknity przedwczenie, i wa ny wytyczenia najlepszej drogi dalszego postpowania.

6.4.
6.4.1.

Zezwolenie na Zainicjowanie Projektu (ZS1)

Podstawowe zasady anga owa si w znaczce wydatki na projekt przed

Nikt nie powinien sprawdzeniem, czy ma on sens.

6.4.2.

Kontekst

Zezwolenie na Zainicjowanie (ZS1) jest dla Komitetu Sterujcego Projektu pierwszym wa nym dziaaniem. Po zakoczeniu Przygotowanie (PP), procesu musi zdecydowa, czy wyda zezwolenie, aby projekt wkroczy w Etap Projektu Komitet Sterujcy inicjowania. Mo na to zrobi na formalnej naradzie Komitetu Sterujcego. Jednak e Ko- Sterujcy mo e si zdecydowa na podjcie tej decyzji bez formalnej narady, o mitet ile wszyscy jego czonkowie si na to zgodz. 82

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

PP6 Planowanie Etap u Inicjo wania

Plan E ta pu i ni c j owa ni a

Ze zw ol e ni e n a ont yn uac k j

IP Inicjowanie Projektu

Z S1 Z ezwolenie na Z ainicjowanie Projektu

Pl a n E ta pu c j owa ni i ni a Za o e n ia P roj e k tu

Dokumentacja Do kumentacja zarz dcza zarz dcza

Dokumentacja Doku mentacja zarz dcza zarz dcza

R e j e st r R y zy k a Za o e nia P r oje k tu k r e sy obow z kw Za i rmu a R e al i z ac j i Pr oj e k Fo tutr uk tur a ze sp o u za dza ni a S rz m

pr oj ek te

P owi a domi e ni e r oz poc z c i u o pr oj e k tu

Wszystkie zaintereso wane strony

Rysunek 6.3. Projektu

Zezwolenie na Zainicjowanie

6.4.3.
Celem tego zainicjowany poprzez:

Opis procesu podprocesu jest zapewnienie, e projekt zostanie waciwie

formalne potwierdzenie nominacji dla zespou zarzdzania projektem; zatwierdzenie Zao e Projektu; zatwierdzenie planu przygotowania Dokumentu Inicjujcego Projekt; pozyskanie lub zaanga owanie zasobw wymaganych w Planie Etapu inicjowania; wystpienie o niezbdne wspar cie logistyczne poprzez Powiadomienie o rozpo- projektu organizacji, ktra jest gospodarzem projektu (lokalizacja, w czciu ktrej bd prowadzone prace).

Komitet Sterujcy musi zapewni, e podczas Etapu inicjowania bd funkcjonoway odpowiednie mechanizmy raportowania i kontroli. Tak jak dla pniejszych etapw, takdla Etapu inicjowania powinien by ustalony zakres i tolerancji. Komitet Sterujcy odpowiada za pozyskanie zasobw i zapewnienie bazy materialnej, projekt zgodnie z wymaganiami okrelonymi w Planie Etapu wspierajcej inicjowania. Infrastruktura wspierajca mo e obejmowa zakwaterowanie, rodki cznoci, wypo- i wszelkie elementy wykor zystywane przez Wsparcie sa enie Projektu.

6.4.4.

Odpowiedzialno

Odpowiedzialno za podproces spoczywa na Komitecie Sterujcym, ktry posuguje si informacjami i danymi dostarczonymi przez Kierownika Projektu i osoby penice 83

DIRECTING A PROJECT (DP) rol Nadzoru Projektu. Kierownictwo firmy zatwierdzenie Projektu dla Komitetu Zao e Sterujcego. lub programu odpowiada

PRINCE2 za

6.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 6.1. (ZS1) Informacja Objanienie

Rejestr Ryzyka Wejcie Czy s zagro enia, mogce wpyn na decyzj zezwalajc na realizacj Etapu inicjowania? Zakresy obowizkw Wejcie Szczegowe zakresy obowizkw s uzgodnione, zwaszcza te, ktre dotycz czonkw Komitetu Sterujcego. Struktura zespou zarzdzania projektem Formua Realizacji Projektu Wejcie Szczegy przedstawiajce, kto ma by zaanga owany w zarzdzanie projektem. Wejcie Jedna z informacji potrzebnych do podjcia decyzji o rozpoczciu projektu. Czy jest ona zgodna ze strategi firmy lub programu?

Zao enia Projektu Zatwierdzenie Po zatwierdzeniu przez Komitet Sterujcy ten dokument staje si obiektem odniesienia. Plan Etapu inicjowania Zatwierdzenie Plan dla Etapu inicjowania, do zatwierdzenia przez Komitet Sterujcy. Powiadomienie o rozpoczciu projektu Zezwolenie na kontynuacj Wyjcie Formalne poinformowanie tych, ktrzy powinni wiedzie o tym, e projekt si rozpocz. Wyjcie Potwierdzenie dla Kierownika Projektu, e praca okrelona w Planie Etapu inicjowania mo e si rozpocz.

6.4.6.

Kryteria oceny ci jako Czy zapewniono odpowiednie rodki finansowe na zrealizowanie projektu? Czy Zao enia Projektu pokazuj i przekonuj, e projekt jest wartociowy i w ten sposb usprawiedliwiaj zwizan z nim inwestycj? Czy wymagane zewntrzne wsparcie oraz urzdzenia s dostpne i przydzielone? Czy zastosowano najodpowiedniejsze standardy, w szczeglnoci gdy standardy dostawcy si r klienta i ni? Czy obowizki Nadzoru Projektu zostay przydzielone i zaakceptowane? Czy znane zagro enia s akceptowalne w tej fazie projektu?

84

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS) Wskazwki i rady

Komitet Sterujcy powinien oczekiwa, e bdzie szeroko anga owany w trakcie Etapu inicjowania, jako e jest to etap, w ktrym ustanawiana jest infrastruktura projektu fundament jego sukcesu. Poza zapotrzebowaniem na personel wspierajcy Kierownika Projektu, w tym podprocesie trzeba tak e formalnie uzgodni z organizacj macierzyst wymagane wsparcie logistyczne. Mo e to obj zakwaterowanie, sprzt, dostp, kwestie bezpieczestwa, narzdzia i wsparcie administracyjne. Inicjowanie powinno by procesem krtkim i dlatego wystpuje potrzeba czstych, doranych dyskusji midzy Komitetem Sterujcym a Kierownikiem Projektu. Nale y unika spowalniania procesu inicjowania przesadnym formalizowaniem sprawozdawczoci. Jeli projekt finansuje strona trzecia, mo e si okaza konieczne szerokie zaanga owanie finansisty w zarzdzanie projektem. Role w Komitecie Sterujcym powinny to odzwierciedla, ale rwnie uwypukli rol u ytkownika w okrelaniu potrzeb i monitorowaniu projektu w celu zapewnienia, e jego rezultat zaspokoi te potrzeby. Gdy projekt finansuje dostawca, role Przewodniczcego i Gwnego Dostawcy powinny by tak skonstruowane, aby odzwierciedla odpowiedzialno finansow. Jeli projekt jest czci programu, program mo e ju mie przygotowany Dokument Inicjujcy Projekt, skracajc w ten sposb normalny proces inicjowania. W takich przypadkach projekt mo e si rozpocz od procesu Zezwolenie na Realizacj Projektu (ZS2) . Jednak nadal obowizkiem Komitetu Sterujcego jest zagwarantowanie, e wszystkie konieczne kroki omawianego podprocesu zostay zrealizowane i udokumentowane.

6.5.
6.5.1.

Zezwolenie na Realizacj
Podstawowe zasady

Projektu (ZS2)

aden projekt nie powinien zobowizywa do znaczcych wydatkw bez: potwierdzenia pr zez kierownictwo, e projekt ma akceptowalne Uzasadnienie Biznesowe; sprawdzenia, e pasuje on do przyjtej strategii firmy lub programu; oceny i akceptacji znanych zagro e i zwizanego z nimi ryzyka; oszacowania czasu i kosztw; sprawdzenia, czy projekt bdzie odpowiednio sterowany. Mo e by ustanowiony poziom odniesienia, w stosunku do ktrego projekt bdzie oceniany, oraz nale y okreli plan bazowy dla sterowania zmianami.

85

DIRECTING A PROJECT (DP)

PRINCE2

6.5.2.

Kontekst

Podproces ten obejmuje zatwierdzenie Planu Etapu dla etapu, ktry nastpi po inicjo- Zatwierdzony Dokument Inicjujcy Projekt daje sygna do rozpoczcia waniu. nastpnego etapu projektu oraz staje si obiektem odniesienia dla pozostaej czci projektu.
IP6 Zestawienie Dokumentu Inicjuj cego Projekt D okument Inicjuj cy P rojekt
Zezwolenie na kontynuacj

SE1 Zgoda na Wykonanie Grupy Zada

ZS2 Zezwolenie na Realizacj Projektu ZE Zarz dzanie Zakresem Etapu

Plan Etapu (nast pnego) Raport Ko cowy Etapu Wniosek o zezwolenie na kontynuowanie

D okument

Inicjuj cy P rojekt

Plan Etapu (nast pnego)

Dokumentacja Dokumentacja zarz dcza zarz dcza

Informacja o post Zatwierdzony

pach projektu

D okument

Inicjuj cy P rojekt

Wszystkie zainteresowane strony

Rysunek 6.4. Projektu

Zezwolenie na Realizacj

6.5.3.

Opis procesu

Celem podprocesu jest podjcie decyzji, czy kontynuowa projekt. Podstaw jest akceptacja lub odrzucenie Dokumentu Inicjujcego Projekt. Proces decy- najlepiej mo na zrozumie, badajc kluczowe elementy spisu treci zyjny Dokumentu Inicjujcego Projekt (szczegy dotyczce zawartoci tego dokumentu s przedstawione Zarysy w Dodatku A Opisw ) . Dokument Inicjujcy Projekt zawiera wszystkie wa neProduktw informacje o projekcie. Z chwil, gdy Dokument Inicjujcy Projekt zaakceptowany przez Komitet Ster ujcy, staje si on obiektem zostanie odniesienia, ktry zachowuje zapis pierwotnych zamierze projektu. Pniejsze przegldy badajce, by projekt, lub czy odbieg on od swych pocztkowych celw, mog u y jak udany za podstaw pomiarw Dok ument Inicjujcy Projekt. Wa ne jest odnotowanie r nicy pomidzy uznaniem w tym momencie Dokumentu Inicjujcego Projekt za obiekt odniesienia, a kolejnymi uaktualnieniami jego czci dynamicznych (patrz zarys Opisu dla Dokumentu Inicjujcego Projekt). Potr Produktu sytuacji, jaka bya w czasie, kiedy projekt si rozpoczyna. Uczynienie z zebny jest zapis Dokumentu Inicjujcego Projekt obiektu odniesienia daje tak mo liwo. W miar reali- projektu pojawiaj si zdarzenia, ktre mog zmieni sytuacj. Mog zacji wystpi 86

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS) nowe zagro enia, a stare utraci Klient mo e dokona aktualno. zmian w specyfikacji. Mog si zmieni ogr aniczenia dotyczce czasu lub kosztw projektu. Uzasadnienie Biznesowe mo e zyska lub straci na atrakcyjnoci. Te dynamiczne cz- Dokumentu Inicjujcego Projekt musz by uaktualniane, by dawa ci Komitetowi najwie sze informacje, na podstawie ktrych bdzie podejmowa Sterujcemu decyzje o kontynuowaniu projektu. S zatem tworzone ich nowe wersje, ale pierwotna posta jest nadal zachowana. Je eli powstaje konieczno zmiany staych czci Dokumentu Inicjujcego Pr ojekt, takich jak definicja to nale y rozwa y mo liwo zamknicie projektu i projektu,jego rozpoczcie z nowym Dokumentem Inicjujcym ponowne Projekt. Dokument Inicjujcy Projekt powinien zawiera nastpujce elementy: Przyczyny ustanowienia projektu Przedstawione s gwne wydarzenia, z ktrych wynika potrzeba projektu. Definicja projektu Komitet Sterujcy musi si upewni, e cele projektu s nadal osigalne. Pozosta tej sekcji powinny stanowi udoskonalenia Zao e Projektu i Formuy cz Realizacji Projektu. Uzasadnienie Biznesowe Komitet Sterujcy musi potwierdzi, e istnieje odpowiednie i u yteczne Uzasadnienieoraz e pokazuje ono zasadny projekt. Informacje o spodziewanych Biznesowe korzy- oszczdnociach powinny by uzupenione i zatwierdzone przez klienta. ciachi Koszty powinien okreli Kierownik Projektu na podstawie Planu Projektu (patrz Rozdzia 13 Uzasadnienie ). biznesowe Plan Jako ci Projektu

11

Plan Jakoci Projektu musi okrela, w jaki sposb zamierza si w projekcie speni Oczekiwania jakociowe klienta i komu zostay przypisane obowizki zwizane z zapewnieniem jakoci. Komitet Sterujcy musi si upewni, e oczekiwania jakociowe zostay prawidowo przeniesione z Zao e Projektu i e Plan Jakoci Projektu zapewnia ich spenienie. Rejestr Ryzyka Zesp zar zdzania projektem powinien zidentyfikowa wszystkie zagro enia ( patrz 17 Zar dzanie Rozdzia ) dotyczce produktw projektu. Komitet z Sterujcy powinien upewni ryzykiem przeprowadzono oceny ryzyka oraz zaproponowano si, e odpowiednie kroki zaradcze a tam, gdzie jest to waciwe, plany rezerwowe.

11

Tzn. DIP w pierwotnej postaci przypis tumacza.

87

DIRECTING A PROJECT (DP)

PRINCE2

Formua Realizacji Projektu Okrela ona metod, jaka zostanie zastosowana aby zrealizowa cele projektu. Peny na znale w Rozdziale 4.8 opis mo Okr lenie Formuy Realizacji (PP5). e Projektu Plan Projektu Plan Projektu daje oglny pogld na gwne produkty, terminy i koszt projektu. Wszelkie znaczne r nice midzy nim a wczeniejszymi przewidywaniami dotyczcymi pro- (np. poczynionymi jako cz studium wykonalnoci) powinny by jektu przeanalizowane, a Komitet Sterujcy powinien si upewni co do dalszej wa noci i realizowalnoci planu oraz przyczyn tych r nic. Plan Projektu powinien by skoordynowany z odpowiednimi planami strategicznymi i planem zarzdzania programem. Organizacja projektu Wikszo nominacji, je eli nie wszystkie, czonkw zespou zarzdzania projektem by sfinalizowana w powinna Przygotowania (PP). W ty m trakcie by one formalnie potwierdzone, a wszystkie pniejsze nominacje Projektu podprocesie musz wynegocjo- dy czonek zespou powinien wyrazi zgod na przydzielon mu rol wane. Ka (opisa-w Rozdziale 14 Organizacj ) i ta zgoda jest jednym z elementw, ktre no to a Komitet Sterujcy powinien potwierdzi. Elementy sterowania Dokument Inicjujcy Projekt bdzie zawiera szczegy dotyczce elementw sterowa- pozwol Komitetowi Sterujcemu sprawowa ogln kontrol nad nia, ktre projektem.ona kolejne zezwolenia na kontynuacj projektu w wyniku kolejnych Obejmie ocen kocowych etapw, zatwierdzenie tolerancji dla projektu i ka dego etapu realizowanego po zainicjowaniu, oraz szczegowe zasady postpowania, gdy ktry etap przekroczy uzgodnione tolerancje. W DIP powinna si rwnie znale informacja dotyczca czstotliwoci i zawartoci raportw od Kierownika Projektu dla Komitetu Sterujcego, wraz ze szczegami opisujcymi, jak Kierownik Pr ojektu zamierza na bie co stero- projektem. Ko mitet Sterujcy musi si upewni, e te elementy sterowania s wa odpowiednie do natury projektu. Plan Komunikacji Plan powinien uwzgldnia potrzeby informacyjne i zawiera terminy komunikowania Projektu, Komitetu Sterujcego oraz innych zainteresowanych si Kierownika stron, obejmujc dwukierunkow czno midzy tymi podmiotami. Plan Komunikacji powi- zawiera szczegy odnoszce si do wszelkich form wsppracy z nien otoczeniem do kontaktw z kierownictwem firmy lub programu. Obowizkiem projektu oraz Komitetu Sterujcego jest ich zabezpieczenie, i w ramach tego podprocesu, potwierdzenie ich dostpnoci.

6.5.4.

Odpowiedzialno

wejciowych

Za podproces odpowiada Komitet Sterujcy. Wikszo informacji bdzie pochodzi od Kierownika Projektu. 88

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

6.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Zatwierdzenie Zatwierdzenie Planu Etapu (nastpnego) przez Komitet Sterujcy.

Tabela 6.2. ZS2 Informacja Objanienie

Planu Etapu (nastpnego)

Raport Kocowy Etapu Wejcie Raport o wykonaniu Etapu inicjowania. Wniosek o zezwolenie na kontynuowanie Wejcie Wniosek Kierownika Projektu o wyra enie przez Komitet Sterujcy zgody na kontynuacj wedug przedo onego Planu Etapu. Komitet Sterujcy ma uprawnienia do odrzucenia planu. Mo e on poleci ponowne przedo enie poprawionego planu lub zdecydowa o przedwczesnym zamkniciu projektu. Komitet Sterujcy ustala tak e tolerancje dla nastpnego etapu. Zatwierdzenie Po zatwierdzeniu przez Komitet Sterujcy, staje si obiektem odniesienia. Wyjcie Zezwolenie Komitetu Sterujcego na rozpoczcie nastpnego etapu.

Dokument Inicjujcy Projekt Zezwolenie na kontynuacj

Plan Etapu (nastpnego) Wyjcie Zatwierdzony przez Komitet Sterujcy. Informacja o postpach projektu Wyjcie Plan Komunikacji mo e zawiera zobowizanie do zawiadamiania podmiotw zewntrznych o postpach prac.

6.5.6.

Kryt eria oceny ci jako Czy projekt wspomaga strategi firmy i programy? Czy Uzasadnienie Biznesowe jest akceptowalne? Czy zagro eniami mo n a zarzdza i czy s akceptowalne? Czy Kierownik Projektu mo e wykaza, e Plan Projektu jest wykonalny? Czy istnieje pewno, e przez cay czas tr wania projektu wymagane zasoby bd dostpne? Czy r nice si cele wszystkich stron s jasne w mo mencie inicjowania? Czy pr zyjte elementy sterowania pozwol, by r nice si cele wszystkich str on byy osigalne w ka dym mo mencie projektu? Co si stanie, je eli kryteria decyzyjne jednej ze stron wymagaj przerwania pro- podczas gdy inne strony proponuj kontynuowanie go? Czy kryteria jektu, prze- kontraktu, zasady i warunki mog by uzgodnione tak, by uwzgldni rwania po- sze, czy te nale y zastosowa standar dowe warunki jego wy rozwizania? Czy prawidowo dostosowano PRINCE2, by uwzgldni modele organizacji lub kontroli klienta lub dostawcy? 89

DIRECTING A PROJECT (DP) Czy istotne zagro enia i zao enia jasno okrelaj oddziaywanie na klienta i dostawc?

PRINCE2

Czy dostawca mo e lub powinien mie wystarczajc kontrol nad organizacj klienta, aby mo na od niego wymaga ponoszenia jakiegokolwiek ryzyka biznesowego? Czy dla ka dego zagro enia i zao enia okrelono obowizki klienta, zwizane z zarzdzaniem, monitorowaniem i zapobieganiem? Czy w przypadku, gdy ryzyko ze strony dostawcy ma wpyw na Uzasadnienie Biznesowe klienta, jest oczywiste, kto (dostawca lub klient) bdzie zarzdza tym zagro eniem? Je eli w projekcie zao ono patnoci w ratach, to czy okrelono odpowiednio poziom identyfikacji produktw lub przedmiotw dostaw? Czy szczegowy Kry- Akceptacji odzwierciedlaj fakt, e patnoci realizowane s w teria ratach? Jeli finansowanie projektu nie jest okrelone, czy ustalono, w jaki sposb dostaw-e zyska przekonanie, e zakontraktowany zakres ma zapewnione pene ca mo finansowanie?

Wskazwki i rady
Komitet Sterujcy musi mie czas przeznaczony na zapoznanie si i zrozumienie Dokumentu Inicjujcego Projekt oraz przedyskutowanie (z Kierownikiem Projektu i innymi osobami) punktw budzcych wtpliwoci, tak aby podejmowane decyzje byy oparte na rzetelnych informacjach. Proces ten jest atwiejszy, je eli Komitet Sterujcy i Kierownik Projektu blisko ze sob wsppracuj w trakcie inicjowania projektu. Wystpi wtedy niewiele niespodziewanych sytuacji (w ideale nie wystpi one wcale). Struktura organizacyjna projektu musi umo liwia przepyw informacji zarwno do cia podejmujcych decyzje, ktre ju istniej w organizacjach klienta i dostawcy, jak i do powoanych czasowo w celu zapewnienia efektywnego zarzdzania samym projektem. Zwykle bdzie to obowizkiem Komitetu Sterujcego. Mo liwo delegowania obowizkw Nadzoru Projektu mo e pomc w osigniciu wymaganego przepywu informacji. W projektach realizowanych na podstawie ustalonej ceny musi nadal istnie praktyczna mo liwo opacenia przez klienta wy szych kosztw spowodowanych zmianami zakresu prac, wymaganymi przez niego. Gdy dostawca finansuje projekt, wpywa to na organizacj i sterowanie projektem. Nale aby to precyzyjnie odzwierciedli w zakresach obowizkw rl Przewodniczcego i Gwnego Dostawcy. Tam, gdzie istnieje du a rozbie no midzy Uzasadnieniami Biznesowymi klienta i dostawcy, jest mao prawdopodobne, e decyzje i dziaania bd spjne i zgodne. Nale y zadba, aby znajomo i zrozumienie r nic Uzasadnie Biznesowych mogy pomc w osigniciu zgodnych zachowa. Powa ne ograniczenia czasowe bd utrudnia wprowadzenie w projekcie takich relacji pomidzy klientem a dostawc, ktre wymagaj rozlegej, formalnej kontroli i komu-

90

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

nikacji. Nale y przejrze (zrewidowa) standardowe elementy sterowania PRINCE2 i czstotliwo ich stosowania pod ktem wszelkich ogranicze czasowych. Zatwierdzajc Dokument Inicjujcy Projekt, nie nale y zapomina, e Plan Etapu (nastpnego) rwnie wymaga zatwierdzenia. Tam, gdzie bud et projektu nie jest ustalony, zatwierdzenie etapu powinno zawiera gwarancj, e fundusze na dany etap s zapewnione. Nale y dokona wyboru liczby i czasu trwania etapw w taki sposb, aby odzwierciedlay one wszelkie potrzeby wynikajce z koniecznoci zapewnienia dalszego finansowania.

6.6.

Zezwolenie na Realizacj Nadzwyczajnego (ZS3)

Podstawowe zasady

Planu Etapu lub Planu

6.6.1.

Wa ne jest, aby prace etapu rozpoczynay si tylko wtedy, gdy Komitet Sterujcy uzna, e powinny si zacz. Pozwala to unikn problemw kontynuowania projektw tylko dlatego, e nikt nie myli o ich przerwaniu. Aby to umo liwi, projekt powinien by podzielony na atwe do zarzdzania czci na kocu ktrych Komitet Sterujcy musi zdecydowa, czy praca powinna (etapy), by kontynuowana, czy nie. Wa ne jest rwnie , aby wczenie dostrzega problemy i reagowa na nie.

6.6.2.

Kontekst

Podproces ten prowadzi do wyra enia zgody na rozpoczcie realizacji ka dego 12 etapu (z wyjtkiem Etapu inicjowania i etapu ) oraz wszystkich Planw Nadzwypierwszego ktre czajnych, zostan pr zedstawione.

12

Tzn. nastpujcego bezporednio po etapie inicjowania. Zgoda na rozpoczcie etapu pierwszego wyraana jest bowiem w podprocesie ZS2 przypis tumacza.

91

DIRECTING A PROJECT (DP)

PRINCE2

ZE5 Raportowanie Ko ca Etapu

Ra por t K c owy E ta o a n E ta pu pu Pl (na p nego ) stub Pl a n N a dzwy c za j l ny Wni os ek o ze zwol e ni e k onty nuowa ni na e

Po le c e ni e pr ze dwc ze s neg o z am k c i a proj e kt ni u

Z P1 Przygoto wanie Projektu do Z amkni cia

Z S3 Z ezwolenie
Pl a n Pr oje k tu a sa dni e ni e Bi z ne Uz sowe Re j e st r R y zyk a DI P Zm i any w ze sp olerz dz ani a pr oj e k za tem

na Realizacj Planu Etapu

Ze zw ol e ni e na ko nty nuac j

SE1 Zgoda na Wykonanie Grupy Z ada

lub Planu Nadzwyczajnego

Informacja Informacja zarz dcza zarz dcza

Za tw i er dzo ny Pl a n Eta pu st pne go) (na l ub Pl a n N a dzw yc za j ny

I nfor m a cj a o pos t pa ch ac

pr

Wszystkie zainteresowane strony

Rysunek 6.5. Planu

Zezwolenie na Realizacj Planu Etapu lub Nadzwyczajnego

6.6.3.

Opis procesu

Celem podprocesu jest podjcie decyzji, czy nale y zezwoli na realizacj nastpnego etapu i skutkiem tego zaanga owa wymagane zasoby, opierajc si na: obrazie aktualnego stanu projektu; szczegowej prognozie opracowanej dla nastpnego etapu i dotyczcej zaanga owania wymaganych zasobw i wytwarzanych produktw; ponownej ocenie daty prawdopodobnego koca projektu; ponownej ocenie sytuacji pod ktem ryzyka; ponownej ocenie Uzasadnienia Biznesowego spodziewanych korzyci.

i szans

osignicia

Kierownik Projektu zazwyczaj prezentuje aktualny stan projektu wraz z rezultatami poprzedniego etapu porwnanymi z oczekiwaniami. Szczegowa prognoza pochodzi z planu dla nastpnego etapu, o ktrego zatwierdzenie zabiega Kierownik Projektu. Szczegowa prognoza powinna by zgodna z uaktualnionym lub zrewidowanym Planem Projektu. Uaktualnione Plan Projektu i Uzasadnienie Biznesowe s porwnywane z ich wersjami projektu (i z tymi z pocztku bie cego etapu) w celu sprawdzenia, czy z pocztku projekt jest nadal zasadny.

92

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS) Jakiekolwiek zmiany w pierwotnym Uzasadnieniu Biznesowym, okrelonym w Zleceniu Przygotowania Projektu lub Zao eniach Projektu, musz by komunikowane kierownictwu firmy lub programu. Komitet Sterujcy ustala tolerancje dla nastpnego etapu jako element zatwierdzania. Planu Etapu Podproces mo e by rwnie wywoany, gdy prognozuje si, e etap lub projekt wyj- poza ustalone dla niego tolerancje. Wczesne ostrze enie o takiej sytuacji dzie powinno by przekazane Komitetowi Sterujcemu, o ile to mo liwe, za pomoc Raportu Okresowego, a nastpnie Raportu o Istotnych Odchyleniach, ktry jest rozpatrywany w podprocesie Podejmowanie Decyzji nyc (ZS4 ) (patr z Rozdzia 16 Element Dora y sterowani ) . Raport o Istotnych Odchyleniach hwyjania przyczyn odchyle, bie a c sytuacj, mo liwe warianty dziaania, rekomendacj Kierownika Projektu oraz wpyw Projektu, Uzasadnienie Biznesowe i zagro na Plan enia. W przypadku prognozy wyjcia etapu poza jego tolerancje, Komitet Sterujcy mo e poleci Kierownikowi Projektu przygotowanie Planu Nadzwyczajnego, ktry bdzie 13 ). Planowi pod- zatwierdzeniu przez Komitet Sterujcy. (Istniej inne mo lega liwoci Nadzwyczajnemu powinny towarzyszy Plan Uzasadnienie uaktualnione:i Rejestr Ryzyka. Projektu, Biznesowe Je eli przewiduje si, e projekt odchyli si poza granice tolerancji, Komitet Sterujcy musi dokona jego przegldu i zdecydowa, czy spraw przekaza na wy szy poziom zarzdzania. W ramach procesu postpowania z istotnymi odchyleniami, Komitet Sterujcy musi uzyska stamtd wszystkie wymagane decyzje dotyczce potencjalnych odchyle poza granice obszaru tolerancji projektu. Na przykad jeli projekt jest czci programu, kierownictwo progr amu bdzie musiao rozwa y prawdopodobny wpyw odchyle na program i podj odpowiednie dziaanie. Z chwil zatwierdzenia, Plan Nadzwyczajny zastpuje zagro ony plan. Przed zezwoleniem na realizacj Planu Etapu lub Planu Nadzwyczajnego Komitet Ste- musi zadba, by zmiany w otoczeniu firmy, ktre mog wpyn na projekt rujcy lub Uzasadnienie Biznesowe, nie uszy uwadze Kierownika Projektu i byy jego zaatwiane efektywnie. W przypadku gdy Komitet Sterujcy zdecyduje, e projekt ju nie jest zasadny, musi poleci przerwanie i zamknicie projektu w uporzdkowany sposb. Pocignie to za sob uruchomienie przez Kierownika Projektu Zamykanie (ZP). procesu Projektu

6.6.4.

Odpowiedzialno

Komitet Sterujcy w peni odpowiada za ten podproces, opierajc si na informacjach przez Kierownika Projektu. Porad mog udzieli osoby wyznaczone dostarczonych do roli Nadzoru Projektu.

13

Decyzji Komitetu Sterujcego w odpowiedzi na prognoz przekroczenia granic tolerancji etapu, np. Ustpstwo przypis tumacza.

93

DIRECTING A PROJECT (DP)

PRINCE2

6.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Zatwierdzenie Plan, o ktrego akceptacj zwraca si Kierownik Projektu.

Tabela 6.3. (ZS3) Informacja Objanienie

Plan Etapu (nastpnego) lub Plan Nadzwyczajny

Plan Projektu Wejcie Pozwala Komitetowi Sterujcemu dokona przegldu stanu caego projektu. Uzasadnienie Biznesowe Dokument Inicjujcy Projekt Zmiany zespou zarzdzania projektem Wejcie Pozwala Komitetowi Sterujcemu sprawdzi, czy projekt jest wci zasadny. Wejcie Stosowany jako obiekt odniesienia, wzgldem ktrego ocenia si dopuszczalno wszelkich odchyle. Wejcie Pozwala Komitetowi Sterujcemu zatwierdza zmiany nominacji.

Rejestr Ryzyka Wejcie Sprawdzenie, czy zagro enia s wci akceptowalne. Raport Kocowy Etapu Wejcie Raport z wanie zakoczonego etapu. Pomaga w ocenie bie cej sytuacji. Wniosek o zezwolenie na kontynuowanie Zezwolenie na kontynuacj lub polecenie przedwczesnego zamknicia projektu Wejcie Zazwyczaj formularz zatwierdzenia Planu Etapu przedstawiony do podpisania Komitetowi Sterujcemu. Wyjcie Zezwolenie na kontynuacj wedug przedo onego planu. W trakcie inicjowania projektu Komitet Sterujcy decyduje, czy chce by zezwolenia na kontynuacj byy formalne czy nieformalne. Komitet Sterujcy moe odrzuci plan. Mo e poprosi o ponowne przedstawienie planu albo zdecydowa o zamkniciu projektu. Komitet Sterujcy okrela rwnie wartoci tolerancji dla nastpnego etapu; lub Polecenie zamknicia projektu przed jego oczekiwanym kocem wydawane przez Komitet Sterujcy Kierownikowi Projektu. Plan Etapu (nastpnego) lub Plan Nadzwyczajny Informacja o postpie prac Wyjcie Zatwierdzony przez Komitet Sterujcy.

Wyjcie Plan Komunikacji mo e wskazywa na potrzeb powiadomienia zewntrznych gremiw o postpach prac.

94

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

6.6.6.

Kryt eria oceny ci jako Czy dostarczono wszystko, czego oczekiwano od bie cego etapu? Je eli nie, to czy stao si tak za zgod Komitetu Sterujcego? Czy s jasne ustalenia, jakie ma by postpowanie w sprawie tego, czego nie dostarczono? Czy jest to objte Zagadnieniem Projektowym? Czy dostawa jest wczona do Planu Etapu (nastpnego) lub Planu Nadzwyczajnego? Czy projekt jest wci zasadny i czy pozostaje skoncentrowany na tej samej potrzebie biznesowej? Czy zagro enia s nadal akceptowalne? Czy podjte rodki zapobiegawcze s nadal suszne, wczajc w to plany rezerwowe? Czy Komitet Sterujcy chce i mo e zapewni zasoby potrzebne do nastpnego etapu prac? Czy w projektach, ktre maj innego dostawc w ka dym etapie, jest udokumen-uzgodnione przez wszystkich dostawcw, e kluczowe informacje towane i doty- projektu czce bd udostpniane kolejnym dostawcom?

Wskazwki i rady
Prawdopodobnie czonkowie Komitetu Sterujcego s osobami zajtymi. Uzgadnianie terminw dla dokonania ocen kocowych etapw mo e by trudne ze wzgldu na wczeniej ustalone terminy zobowiza czonkw KS. Z tego powodu nale y wprowadzi do kalendarzy decydentw terminy kocowych ocen etapu tak wczenie, jak jest to mo liwe (najlepiej w trakcie poprzedniej oceny kocowej etapu) i zaakceptowa to, e w niektrych przypadkach mog one nie wypa dokadnie na koniec etapu. Oczywicie lepiej jest, gdy zagadnienia zwizane z zakresem etapu s dyskutowane w jakim terminie bliskim koca etapu, zamiast ryzykowa, e nie odbdzie si adna ocena, poniewa wymagane osoby s nieosigalne. Nale y si upewni, e ju na samym pocztku nie wystpi adne niespodzianki; oznacza to, e sytuacja w projekcie powinna by przedyskutowana nieformalnie midzy Kierownikiem Projektu a Komitetem Sterujcym, a wszelkie problemy rozwizane przed przedstawieniem jakiejkolwiek formalnej proby o zezwolenie na nastpny etap. Je eli projekt jest czci programu, mo e by potrzebna staranna koordynacja z kierownictwem programu dla zapewnienia uzyskania na czas zatwierdze z poziomu programu. Mo e pojawi si informacja o zagro eniu, e projekt wyjdzie poza granice swoich tolerancji, mimo e sam etap mieci si w granicach tolerancji etapu. Dla przykadu, mo e to by informacja, e koszt wyposa enia przewidzianego do zakupu za rok przekroczy tolerancj przewidzian dla bud etu projektu. Jest wa ne, aby tego typu Zagadnienia Projektowe byy dyskutowane tak wczenie, jak to jest mo liwe, oraz aby byy traktowane przez Komitet Sterujcy jako istotne odchylenia. Je eli przewiduje si, e projekt w znaczny sposb przekroczy granice tolerancji, lepsze mo e by przerwanie projektu i ponowne jego rozpoczcie oparte na innym Dokumencie Inicjujcym Projekt, odzwierciedlajcym now sytuacj.

95

DIRECTING A PROJECT (DP)

W maych projektach Komitet Sterujcy i Kierownik Projektu mog si zgodzi na nieformaln ocen kocow etapu i zezwolenie na kontynuowanie projektu. Jednak e dokument potwierdzajcy formalne zatwierdzenie i zezwolenie, wydany przez Komitet Sterujcy, warto mie w dokumentacji zarzdczej, szczeglnie jeli pniej wystpi problemy i Kierownik Projektu bdzie pytany, dlaczego rozpoczto etap. Wa ne jest, aby zagwarantowa, e na projekt nie oddziauj negatywnie opnienia w systemach zarzdzania klienta lub dostawcy.

PRINCE2

6.7.
6.7.1.

Podejmowanie Decyzji Dora

Podstawowe zasady

nych (ZS4

Nawet je eli etap pr zebiega zgodnie z planem i w granicach tolerancji, mo e wystpi konsultacji z Komitetem Sterujcym. Okazjami mog by nastpujce potrzeba sytuacje: otrzymywanie regularnych raportw; zwrcenie si o rad w kwestii strategicznej, kiedy mo liwe opcje wymagaj wyjanienia;

potrzeba rozwa enia wpywu zewntrznych zdarze na pr ojekt; rozwizywanie zagadnie zwizanych z zasobami, ktre mogyby oddziaywa na tolerancje ; rozwizywanie obszarw konfliktowych; zmiany organizacyjne w projekcie. Jest rwnie mo liwe, e w trakcie etapu Komitet Sterujcy sam zechce przekaza Kierownikowi Projektu informacje o zdarzeniach zewntrznych i zmianach swoich wa- wymaga lub przekaza informacj zewntrznym zainteresowanym snych stronom.

6.7.2.

Kontekst

Ten podproces mo e by potrzebny w dowolnym momencie projektu. Mo e by wyzwalany zdarzeniem zewntrznym lub informacj albo okolicznociami zaistniay miprojekcie. w

96

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

Wszystkie zainteresowane strony

Informacje ze rde zewn trznych

Raporty zarz

dcze

SE6 Raportowanie Okresowe

Polecenie przedwczesnego Raporty Okresowe zamkni cia projektu

ZP Z amykanie Projektu

ZS4 Podejmowanie Decyzji Dora nych SE8 Przekazywanie Zagadnie Projektowych

Raport o Istotnych Odchyleniach

Pro ba o Plan Nadzwyczajny

Pro ba o rad

Decyzj e Komitetu Steruj

SE8 Przekazywanie Z agadnie Projektowych

cego

Przygotowanie Projektu (PP) Inicjowanie Projektu (IP) Sterowanie Etapem (SE) dzanie Z arz Zakresem Etapu (ZE) Z amykanie Projektu (ZP)

Plan Komunikacji Zalecenia Komitetu Steruj cego Nowe Zagadnienia Projektowe

Dokumentacja Dokumentacja zarz dcza zarz dcza

SE3 Rejestrowanie Z agadnie Projektowych

Rysunek 6.6. Podejmowanie Decyzji Doranych

6.7.3.

Opis procesu

Komitet Sterucy ma za cel: zapewnienie, e projekt pozostaje skoncentrowany na zbiorze celw biznesowych i ma nadal uzasadnienie w kategoriach biznesowych; zapewnienie, e etap postpuje zgodnie z planem; zapewnienie, e zmiany w rodowisku firmy lub programu, ktre mog wpyn na projekt, s komunikowane Kierownikowi Projektu i e s podejmowane odpowiednie dziaania; zapewnienie, e do projektu dostarczane s informacje o zewntrznych zdarze- ktre mog mie na niego niach, wpyw; 97

DIRECTING A PROJECT (DP)

PRINCE2

podejmowanie, le cych poza uprawnieniami Kierownika Projektu, decyzji dotyczcych Zagadnie Projektowych i Raportw o Istotnych Odchyleniach,; powiadamianie Kierownika Projektu o zmianach w skadzie Komitetu Sterujcego; informowanie kierownictwa firmy lub programu i innych zainteresowanych stron o postpach projektu. Te cele powinny by realizowane przez Komitet Sterujcy, bez potrzeby inger owania w projekt poza elementami sterowania i raportami uzgodnionymi z Kierownikiem Projektu. Komitet Sterujcy powinien otrzymywa regularne Raporty Okresowe od Kierownika czstotliwoci uzgodnion dla bie cego Projektu z etapu. Komitet Sterujcy powinien zagwarantowa, e wszelkie sytuacje zwizane z powa - ymi zagro eniami s wystarczajco regularnie monitorowane, by utrzyma zagro n enia kontrol. Za pomoc Raportu o Istotnych Odchyleniach, Kierownik Projektu pod powi- przedstawi Komitetowi Sterujcemu te sytuacje, dla ktrych przewiduje, e nien etap cay projekt wyjdzie poza swoje lub tolerancje. Mog zaistnie sytuacje, kiedy Komitet Sterujcy dokona, w granicach delegowanych mu uprawnie, nastpujcych wyborw: zleci Kierownikowi Projektu przygotowanie Planu Nadzwyczajnego dla pozostaej czci etapu, odzwierciedlajcego now sytuacj (patrz: Opracowani podproces e Planu (ZE6)); Nadzwyczajnego zredukuje zakres etapu lub oczekiwa w stosunku do projektu w celu przywrcenia tolerancji, wykorzystujc do tego sterowanie zmianami (patr z: go w granice pod- Opracowanie proces Planu (ZE6)); Nadzwyczajnego przerwie projekt (patrz Przygotowanie Projektu do ci (ZP1)). podproces: Zamkni a Mog pojawi si Zagadnienia Projektowe, w odniesieniu do ktrych Kierownik Pro- bdzie potrzebowa wytycznych. Komitet Sterujcy przekazuje swoje jektu zalecenia, biorc pod uwag wpyw rozwa anego Zagadnienia Projektowego na Uzasadnieniei zagro enia. Zagadnienia Projektowe obejmuj wszystkie zgoszone Biznesowe pyta- Wnioski o Wprowadzenie Zmiany i Odstpstwa. Poniewa mog one nia, oznacza stosunku do uzgodnionego Dokumentu Inicjujcego Pr ojekt, to funkcj zmiany w Komitetu Sterujcego jest zatwierdzenie lub odrzucenie wszelkich zmian. Wprowadzanie zaakceptowanych zmian mo e wymaga dodatkowego czasu i/lub funduszy. Je eli Zagadnienie Projektowe wykracza poza uprawnienia Komitetu Sterujcego, ma obowizek uzyskania decyzji od kierownictwa firmy lub on programu. Komitet Sterujcy ma obowizek pozyskania wszelkich dodatkowych lub zmienionych zasobw, ktre wynikaj z uzgodnie dokonanych z Kierownikiem Projektu, w zwizku zgoszonymi ze Zagadnieniami Projektowymi. Komitet Sterujcy musi zapewni, e wydarzenia zewntrzne, ktre mog wpyn na projekt, s odpowiednio monitorowane i postpuje si z nimi skutecznie. Ka da nowa informacja uzyskana ze rde zewntrznych powinna by przekazana Kierownikowi Projektu w celu wniesienia Zagadnienia Projektowego.

98

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS) Plan Komunikacji mo e zawiera szczegy dotyczce zewntrznych zainteresowanych stron, takich np. jak kierownictwo programu, ktre powinny otrzymywa z okrelon od Komitetu Sterujcego informacje dotyczce spraw projektu (lub s czstoci zobowizane dostarcza je Komitetowi Sterujcemu). Komitet Sterujcy musi sam uwia- sobie takie wymagania oraz to jak, kiedy i przez kogo taka informacja ma domi by przekazana, albo odbierana. Mo liwe s sytuacje, kiedy skad Komitetu Sterujcego musi by zmieniony. Mo e to nastpi z powodu zmiany pracy przez aktualnego czonka komitetu lub pojawi si dodatkowi klienci lub dostawcy, ktrzy wymagaj swojej reprezentacji w Komitecie Sterujcym. Obowizkiem Komitetu Sterujcego jest powiadomienie o tym Kierownika Projektu. Komitet Sterujcy musi w takich przypadkach uzgodni zakres obowizkw z owymi czonkami. n

6.7.4.

Odpowiedzialno

Odpowiedzialno za podproces ponosi Komitet Sterujcy. Mo e delegowa niektre dziaa osobom, ktre peni obowizki Nadzoru z tych Projektu.

6.7.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 6.4. ZS4 Informacja Objanienie

Raport Okresowy Wejcie Regularne informacje o postpach otrzymywane od Kierownika Projektu. Raport o Istotnych Odchyleniach Wejcie Wczesne ostrze enie o odchyleniu. Mo e wyzwoli przygotowanie Planu Nadzwyczajnego.

Proba o rad Wejcie Sytuacje, w ktrych potrzebna jest decyzja le ca poza uprawnieniami Kierownika Projektu. Plan Komunikacji Wejcie Szczegy dotyczce zainteresowanych stron. Informacje ze rde zewntrznych Wejcie Zbir informacji, majcych zwizek z projektem, pochodzcych ze rde zewntrznych. Wyjcie Informacja o postpach projektu dla odbiorcw zewntrznych.

Raporty dla kierownictwa firmy lub programu Zalecenia Komitetu Sterujcego

Wyjcie Wskazwka i instrukcja dla Kierownika Projektu, bdca nastpstwem proby o rad lub wynikajca z informacji od kierownictwa firmy lub programu.

99

DIRECTING A PROJECT (DP)

PRINCE2

Informacja Objanienie
Proba o Plan Nadzwyczajny

zarzdcza

Wykorzystanie
Wyjcie Proba bdca reakcj na informacj wejciow przedstawion wy ej, w szczeglnoci na Raport o Istotnych Odchyleniach. Wyjcie Mo liwe zamknicie projektu przed jego oczekiwanym kocem.

Polecenie przedwczesnego zamknicia projektu Nowe Zagadnienia Projektowe

Wyjcie Informacja od Komitetu Sterujcego, lub z zewntrznych rde za jego porednictwem, ktra mo e by powodem wniesienia nowych Zagadnie Projektowych w podprocesie Rejestrowanie Zagadnie Projektowych (SE3)

6.7.6.

Kryteria oceny ci jako Czy Kierownik Projektu wie, jak si kontaktowa z czonkami Ko mitetu Ster ujce- w go przypadku wystpienia problemw? Czy czonkowie Komitetu maj wiado mo potrzeby szybkiej Sterujcego reakcji na wniesione Zagadnienia Projektowe? Czy czonkowie Komitetu Sterujcego s zobowizani do bezzwocznego zapoznawania si z Raportami Okresowymi i reagowania na nie we waciwym czasie?

Wskazwki i rady
S projekty tak dynamiczne, e wystpi w nich wiele Wnioskw o Wprowadzenie Zmiany. Komitet Sterujcy i Kierownik Projektu powinni uzgodni obowizki Komisji ds. zmian, procedury i - w miar mo liwoci - osobny bud et (bud et zmian) na ich zaatwianie. Spodziewane zmiany zewntrzne, ktre mog stanowi zagro enie dla projektu, powinny by dokumentowane w Rejestrze Ryzyka. Komitet Sterujcy mo e delegowa swoim czonkom obowizek monitorowania okrelonych zewntrznych rde potencjalnych oddziaywa na projekt. Gwnym obowizkiem ka dego z czonkw Komitetu Sterujcego bdzie monitorowanie okrelonego obszaru, na ktry projekt mo e by wra liwy na przykad, zmiany stp procentowych. Kierownik Projektu mo e zabiega o wytyczne Komitetu Sterujcego, je eli jakie zagro enia zmaterializuj si. Jeli projekt jest czci programu, a ma nastpi zmiana w skadzie Komitetu Sterujcego, nale y stara si o rad i akceptacj kierownictwa programu.

1 00

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS)

6.8.
6.8.1.

Zatwierdzenie Zamkni
Podstawowe zasady

cia Projektu (ZS5)

Wymagane jest formalne przekazanie ostatecznemu u ytkownikowi produktw pr ojektu i odpowiedzialnoci za nie. Dla wikszoci kocowych produktw musi by stworzone niezawodne rodowisko eksploatacyjne i serwisowe. Nale y podj wszelkie wysiki, aby przekaza wszystkie dowiadczenia, ktre zdobyto dziki projektowi.

6.8.2.

Kontekst

Podproces ten jest wyzwalany na sygna dany przez Kierownika wykonujProjektu, cego dziaania i wytwarzajcego produkty zarzdcze Zamykanie (ZP). procesu ostatnia praca wykonywana przez Komitet Sterujcy Projektu jego Jest to pr zed rozwizaniem.
Akceptacja su b eksploatacji

ZP1 Przygotowanie Projektu do Zamkni cia

i utrzymania oraz akceptacja klienta Zalecenie zamkni cia projektu

ZP2 Okre lenie Dziaa Nast pczych

Zalecenia Dziaa Nast pczych Plan Przegl du Poprojektowego

ZP3 Przegl d Oceniaj cy Projekt

Raport o Do wiadczeniach Raport Ko Projektu cowy

ZS5 Zatwierdzenie Zamkni cia Projektu

Powiadomienie o zamykaniu projektu Zalecenia Dziaa Nast pczych Plan Przegl du Poprojektowego Raport o Do wiadczeniach Raport Ko cowy Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

DIP Plan Kom unikacji

Wszystkie zainteresowane strony

Rysunek 6.7. Projektu

Zatwierdzenie Zamknicia

101

DIRECTING A PROJECT (DP)

PRINCE2

6.8.3.

Opis procesu

Projekt powinien by zamknity w sposb uporzdkowany. Ten podproces ma na celu: zagwarantowanie, e projekt ma jasno okrelony koniec i zorganizowane przekazanie odpowiedzialnoci grupie, ktra bdzie produkty eksploatowa, serwisowa i utrzymywa; zwolnienie zasobw dostarczonych na potrzeby projektu; uzyskanie formalnego potwierdzenia od klienta, e Kryteria ustalone na Akceptacji zostay pocztku nale ycie spenione; przekazanie pod uwag odpowiednich organw wszelkich zmian, ktrych nie ono, i wszelkich zdobytych w projekcie dowiadcze osobom mogcym wdro najlepiej z nich skorzysta; ustalenie metody sprawdzenia w przyszoci, czy projekt przynis oczekiwane korzyci;

zawiadomienie wszystkich zainteresowanych stron o zamkniciu projektu. Dla osignicia tych celw nale y zrealizowa nastpujce kroki: zapewni, e wszystkie wykonane produkty zostay zaakceptowane przez klienta lub s objte zatwierdzonymi Ustpstwami (je eli miay miejsce jakiekolwiekmog one ustpstwa, by uwzgldnione tak e w Zaleceniach Dziaa Nastpczych) ; tam, gdzie to ma zastosowanie, zapewni, e powstae zmiany w biznesie s wspierane i trwae; zapewni, eby Zalecenia Dziaa Nastpczych zostay prawidowo zapisane i eby waciwe gremia miay wiadomo odpowiedzialnoci za ich dalsze prowadzenie. Zalecenia powinny wymienia wszystkie dziaania nastpcze, wynikajce z projek- Zagadnienia Projektowe, ktre zostay sklasyfikowane przez Komitet tu, te Sterujcy jako oczekujce, oraz wszystkie propozycje nowych prac wynikajce z projektu. Zalecenia musz by skierowane do waciwych odbiorcw. Mog by przekazane do wdro enia zespoowi utrzymania albo mog trafi do kierownictwa programu lub grupy odpowiedzialnej za strategi do rozwa enia jako samoistne projekty; tam, gdzie to ma zastosowanie, zapewni przekazanie produktw i metody zarz- konfiguracj odpowiedniej grupie utrzymania, w celu umo liwienia dzania dalszego zarzdzania konfiguracj; zatwierdzi Raport o Dowiadczeniach do rozpowszechnienia. W trakcie projektuzdoby szereg dowiadcze dotyczcych mocnych i sabych stron mo na stosowanych procesw, procedur, technik i narzdzi kiedy byy u ywane, jak i przez ko- Je eli istnieje cokolwiek, co mo goby przynie korzyci innym projektom go. realizowanym w ramach firmy, Komitet Sterujcy ma obowizek zapewnienia, e ta informacja zostanie przekazana odpowiednim osobom, np. tym, ktre odpowiadajzapewnienie za jakoci; zatwierdzi tre Raportu Kocowego Projektu w celu rozprowadzenia go do wszystkich zainteresowanych stron - np. do kierownictwa firmy lub programu;

1 02

PRINCE2 ZARZDZANIE STRATEGICZNE PROJEKTEM (ZS) przygotowa Powiadomienie o zamykaniu . Komitet Sterujcy projektu powiadamia tych, ktrzy udostpnili projektowi wspierajc infrastruktur i zasoby, e og by one wycofane. Powinno ono wskazywa ostateczny termin m rozliczenia obci kosztw ajcych projekt; opracowa i rozprowadzi Plan Przegldu Poprojektowego. Odpowiedzialno wspierany przez osoby penice

6.8.4.

Za podproces odpowiada obowizki Nadzoru Projektu.

Komitet Sterujcy,

Na Przewodniczcym spoczywa obowizek zapewnienia, by osoba, ktra bdzie przeprowadzaa przegld poprojektowy, zostaa do tego waciwie pr zygotowana i eby przekazano tej osobie odpowiedzialno za jego zorganizowanie. Jeli projekt jest czci programu, mo e by konieczne uzyskanie zatwierdzenia zamknicia projektu przez kierownictwo programu. Kierownictwo programu mo e te chcie zarzdzi przekazaniem jakich prac, bdcych nastpstwem projektu.

6.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie U ywany jako obiekt odniesienia, w stosunku do ktrego ocenia si, jak daleko projekt odbieg od pierwotnych ustale. Dostarcza tak e niektrych informacji, su cych jako punkt odniesienia, wzgldem ktrego oceniane jest powodzenie projektu.

Tabela 6.5. (ZS5) Informacja Objanienie

Dokument Inicjujcy Projekt

Plan Komunikacji Wejcie U ywany do identyfikacji wszystkich adresatw informacji o zamkniciu projektu. Akceptacja su b eksploatacji i utrzymania Akceptacja klienta Zalecenie zamknicia projektu Wejcie Potwierdzenie, e kocowy produkt mo e by u ywany i utrzymywany. Wejcie Potwierdzenie, e klient akceptuje produkty. Wejcie Zapewnienie ze strony Kierownika Projektu, e sprzt, wsparcie i zasoby mog by wycofane z projektu.

Raport Kocowy Projektu Zatwierdzenie Zawiera wicej informacji umo liwiajcych ocen powodzenia projektu. Zatwierdzony do rozprowadzenia do wszystkich zainteresowanych stron. Zalecenia Dziaa Nastpczych Zatwierdzenie Zalecenia dotyczce wszystkich Zagadnie Projektowych sklasyfikowanych jako oczekujce i innych przyszych dziaa.

103

DIRECTING A PROJECT (DP)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie
Zatwierdzenie Proponowany plan oceny osignicia korzyci z projektu. Zatwierdzony przez Komitet Sterujcy do przekazania osobom odpowiedzialnym za jego wykonanie. Zatwierdzenie Zdobyte w projekcie dowiadczenia, ktrych przekazanie do innych projektw mo e by u yteczne. Wyjcie Powiadomienie wszystkich zainteresowanych stron, e sprzt, wsparcie i zasoby mog by wycofane z projektu.

Plan Przegldu Poprojektowego

Raport o Dowiadczeniach Powiadomienie o zamykaniu projektu

6.8.6.

Kryteria oceny ci jako Czy rezultaty i produkty zostay zaakceptowane i nie s ju zale ne od prac bdcych czci projektu? Czy organizacja jest gotowa do wspierania, utrzy mywania i dalszego rozwoju rodowiska i dostarczonych produktw? Czy klienci s zadowoleni z rezultatw i produktw? Czy wszystkie istotne wymagania kierownictwa programu zostay spenione?

Wskazwki i rady
Nale y przekaza wyrazy uznania zespoom i poszczeglnym osobom za istotne osignicia i sukces projektu. Nawet je eli nie jest to wymagane, dobrze jest mie pisemne potwierdzenie akceptacji przez te osoby, ktre bd odpowiada za eksploatacj i utrzymywanie dostarczonych produktw. \r "zatwierdzenie_zamkn_Proj"

1 04

7.
W y daw a ni e z gody oz poc z ci e pr ac na r

S TE RO WA NI E E TAP E M ( S E)
(CONTROLLING A STAGE - CS)

W y chw y tyw a ni e i r e je s tr owa ni e z a gad ni pr oje k tow y c e h Pot wi e r dza ni e w yk o na n ia pr a c y

Uz y s ki w an ie i nfo rma c j i o pos t pa c h pr a c

A na l i zow an ie od dzi a yw a nia ga dn p roj e k towy c h za ie

D ok ony wa ni e pr ze dw pos pw pra c , dzi a a doty c zgl c y c h j ak o c i , za ga tdni pr oj ek tow y c h i sta n u r y zy k e a

R a por towa n ie K omi te t owi S te ruj o po st p ac h

c em u

P ode j mow a nie dz ia a k or yg cy c h uj Pr z e ka zy w an ie pr obl e mw K omi t et u St er ce g o do uj

Rysunek 7.1. Etapem

Zarys procesu Sterowanie

7.1.

Podstawowe zasady

Po podjciu decyzji o kontynuowaniu prac oraz po przyznaniu zasobw, zesp zarz- projektem musi by skoncentrowany na dostarczeniu wyniku w ramach dzania okrelonych tolerancji. Oznacza to kontrolowane wytwarzanie uzgodnionych produktw: zgodnie z ustalonymi standardami jakoci; w ramach uzgodnionych kosztw, nakadw pracy i czasu; tak, aby ostatecznie osign zdefiniowane korzyci. Aby osign ten sukces pr ojekt musi: skupia uwag kierownictwa na dostarczaniu produktw etapu; koncentrowa na tym celu zasoby wykorzystywane w trakcie etapu; 10 5

CONTROLLING A STAGE (CS) utrzymywa zagro enia pod kontrol; dokonywa przegldw Uzasadnienia Biznesowego;

PRINCE2

14 uzgodniouwa nie monitorowa wszelkie odchylenia od kierunku i produktw starcie etapu, aby unikn pezania zakresu oraz utraty nych na koncentracji.

7.2.

Kontekst

Proces opisuje prac Kierownika Projektu w trakcie bie cego zarzdzania etapem. Rozpoczyna si po zatwierdzeniu Planu Etapu przez Komitet Sterujcy w podprocesie Zezwolenie na Planu lub Planu (ZS3) lub te Realizacj Etapu - po zatwierdzeniu Planu Etapu w ramach Nadzwyczajnego w przypadku pierwszego etapu podprocesu Zezwolenie na Projekt (ZS2). Proces Sterowanie (SE) wykorzystyRealizacj u Etapem wany bdzie w ka dym etapie projektu. Sterowanie (SE) kieruje Zar dzanie Wytwarzaniem Etapem punktami ich procesem z (WP) ; styku s: wyra enie zgody na Produktw Grupy wykonanie wszelkie Zada, wyspecyfikowane raporty, oraz przekazanie potwierdzenia, e Grupa Zada zostaa wykonana w satysfakcjonujcy sposb. Istnieje naturalny porzdek wydarze, zapewniajcy, e wszystkie niezbdne dziaa- prowadzone w sposb regularny. Mimo to zarzdzanie pr ojektem ma nia s charakter i jest deter minowane problemami i wydarzeniami, w miar jak one dorany wystpuj. e cz lub cao procesu Sterowanie Oznacza to, (SE) mo e by rwnie doEtapem brze stosowana w sposb determinowany wydarzeniami, jak i w sposb regularny, powy ej. wspomniany

7.3.

Opis procesu

Proces Sterowanie ( SE) ma na Etapem celu: dostarczenie waciwych produktw; zagwarantowanie, e jako zostanie osignita zgodnie z planem; dostarczenie produktw na czas, w ramach uzgodnionych kosztw i w uzgodnionych granicach tolerancji; prawidowe ukierunkowanie i prowadzenie prac nad produktami; utrzymywanie kontroli nad produktami poprzez Zarzdzanie konfiguracj; waciwe zarzdzanie i wykorzystanie zasobw; uaktualnianie planw danymi o faktycznym wykonaniu, umo liwiajce spr awdzanie postpw w odniesieniu do planu; waciwe obliczanie kosztw wykorzystania zasobw; prawidowe zarzdzanie wszelkimi odchyleniami od Planu Etapu lub Planu Projektu;

14

Opisu Produktw przypis tumacza.

1 06

PRINCE2

STEROWANIE ETAPEM (SE)

informo wanie w por wszystkich zainteresowanych stron o postpach projektu; zagwarantowanie, e projekt zostanie zatrzymany lub bdzie zmieniony jego kieru-jeli pierwotne przyczyny jego ustanowienia zostay uniewa nione przez nek, wydarzenia wewntrzne lub zewntrzne.
ZP Zamykanie Projektu ZS Zarz dzanie Strategiczne Projektem WP Zarz dzanie Wytwarzaniem Produktw

SE
SE7 Podejmowanie Dziaa Koryguj cych SE1 Zgoda na Wykonanie Grupy Zada

Sterowanie Etapem
SE2 Ocena Post pw SE9 Odbir Wykonanej Grupy Zada

SE8 Przekazywanie Zagadnie Projektowych

SE6 Raportowanie Okresowe

SE5 Przegl d Stanu Etapu

SE4 Analizowanie Zagadnie Projektowych

SE3 Rejestrowanie Zagadnie Projektowych

ZS Zarz dzanie Strategiczne Projektem

ZE Zarz dzanie Zakresem Etapu

Rysunek 7.2. Sterowanie Etapem Najwa niejsze dla ostatecznego sukcesu projektu jest bie ce sterowanie prowadzonymi caego etapu bdzie to cykl skadajcy si pracami. W cigu z: wyra enia zgody na wykonanie pracy (SE1); monitorowania informacji o postpach pr acy (SE2 i SE9); wychwytywania Zagadnie Projektowych i ich oceny (SE3 i ; SE4) dokonywania przegldu sytuacji oraz ustalania nowych Grup Zada (SE5); raportowania (SE6); podejmowania koniecznych dziaa korygujcych (SE7). Podprocesy Rejestrowanie Projektowyc (SE3), Analizowanie Zagadnie Przeg d h Zagadnie Projektowyc (SE4), Stanu (SE5) i Przekazywanie Projek h Etapu Zagadnie towyc (SE8) obejmujl dziaania, pozwalajce skierowa uwag Komitetu h Sterujcego 107

CONTROLLING A STAGE (CS)

PRINCE2

na zaobserwowane zmiany, o ktrych przewiduje si, e ich wpyw mo e spowodowa odchylenia wykraczajce poza toler ancje ustalone dla Etapu i/lub Projektu. Inne czynniki, ktre mu sz by brane pod uwag: bie cy etap zawier a zadania oraz wi e si z wydatkowaniem zasobw, ktre byy zaaprobowane przez Komitet Dlatego wa ne jest, aby przekazywa Sterujcy. zwrotne o postpach w odniesieniu do jego informacje oczekiwa; wszystkie indywidualne zadania w ramach etapu powinny uzyska zgod na wykonanie (zalecany format Grupy Zada przedstawiono w Dodatku Zarysy A Opisw ); Produktw prace w projekcie mog by odpowiednio kontrolowane tylko w odniesieniu do planu; jeli projekt ma si zakoczy sukcesem, Kierownik Projektu i Komitet Sterujcy musz szybko reagowa na zmiany i odchylenia od uzgodnionego Planu . Etapu Skalowalno mog by streszczone

7.3.1.

Gwne dziaania procesu nastpujco: przydzieli prac; sprawdza postpy;

zapewni, e uzyskiwana jako jest waciwa z punktu widzenia potrzeb projektu; zapewni, e Zagadnienia Projektowe znajduj si pod kontrol; monitorowa zagro enia; raportowa o postpach; zwraca uwag na odchylenia od planu.

Na tej licie nie znajduje si nic takiego, co mogoby zaniepokoi kierownika maego projektu. Nawet w najmniejszych projektach Kierownik Projektu musi mie wystarcza- czasu, aby zarzdza dziaaniami oraz wykorzystaniem zasobw w jco du o projekcie. Proces zaleca kilka raportw, sugerujc, by byy to raporty na pimie na przykad: Grupy Zada, Raporty Okresowe oraz Raporty o Istotnych Odchyleniach. W maych projektach mo na podj decyzj, e cz lub wszystkie raporty bd skadane ustnie. w takim przypadku Kierownik Projektu musi myle o tym, ktre Nawet wydarzeniazosta zarejestrowane na pimie, na wypadek pniejszych sporw. powinny Czciowym powodem dokumentowania wydarze i decyzji jest zachowanie cigoci, gdyby Kierownik Projektu sta si nagle nieosigalny. Niektre projekty mog nie mie odrbnych Kierownikw Zespow, lecz tylko jeden zesp, ktrego czonkowie podlegaj bezporednio Kierownikowi W Projektu. Kierownikiem Projektu oraz Kierownikiem Zespou bdzie jedna i ta takim przypadku sama osoba, a Grupy Zada bd negocjowane pomidzy Kierownikiem Projektu a poszczeglnymi czonkami Nale y o tym pamita podczas czytania pozostaej zespou. czci tego rozdziau, ktry odnosi si do punktw styku pomidzy Kierownikiem Projektu a ierownikiem Zespou. K

1 08

PRINCE2 Wskazwki i rady

STEROWANIE ETAPEM (SE)

Akcent w tym procesie jest poo ony na procesy i techniki sterowania etapem zarzdczym. Mimo to, w du ej mierze ostateczny sukces projektu bdzie zale a od postpowania z ludmi i od polityki projektu.

7.4.
7.4.1.

Zgoda na Wykonanie Grupy Zada

Podstawowe zasady

(SE1)

Gdyby osoby zaanga owane w projekt same decydoway o czasie rozpoczcia prac, prowadzioby to do chaosu. Musi istnie pewien poziom autonomii w zespole projek- ale w projekcie bdzie istnia szerszy krg zagadnie, ktrych wiadomoci towym, nie na od zespou oczekiwa. Dlatego wa ne jest, aby, w szerokim sensie, prace mo zaczy-si oraz byy kontynuowane za zgod Kierownika nay Projektu.

7.4.2.

Kontekst

Podproces bdzie przebiega stale podczas caego etapu. Styka si on z Za procesem r dzanie Wytwarzaniem (WP) , ktry kieruje wytwarzaniem z Produktw oraz wymaganych produktw, dostarcza danych do aktualizacji planu podczas Ocena Popodprocesu s pw (SE2) . Podobnie, realizacja Podejmowanie Dziaa Korygu cyc t 7) mo e by rdem dodatkowych Grup Zada, albo bdzie wymagaa j podprocesu (SE wprowa- h dzenia modyfikacji do istniejcych Grup Zada.
Li st a K ontr ol na Pr oduk twpis y O bie k tw K onfi gur ac Za j i a n Eta pu l ub P l an N a dzwy cz aj Pl nyej e st r R yz yk a R R ej e st r Za gadni SE1 e ej e st r J ak oci R

WP1
Grupa da Za

Dokumentacja Dokumentacja zarz dcza zarz dcza

Zgoda na Wykonanie Grupy Zada

Przyjmowanie Grupy Zada do Wykonania

Opi s P roduk tu

SE7 Podejmowanie Dziaa Koryguj cych

S ygna do podj

c i a pr ac y Sy gna do podj Ze zwol e ni e na kont ynua c j

ci a pra c y

SE5 Przegl d Stanu Etapu ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

ZS2 Zezwolenie na Realizacj Projektu

Rysunek 7.3. Zgoda na Wykonanie Grupy Zada

109

CONTROLLING A STAGE (CS)

PRINCE2

7.4.3.

Opis procesu

Celem tego podprocesu jest sterowanie prac zespou(-w) poprzez: wydawanie Kierownikom Zespow polece (sygna inicjujcy), by rozpoczli prace; w razie potrzeby, korygowanie tych polece w nastpstwie decyzji kierownictwa. Zbir polece przekazywanych Kierownikowi Zespou nazywa si Grup Zada. Aby osign ten cel, nale y podj r norodne kroki: dokona przegldu Opisw Produktw dla produktw, ktre maj by dostarczone; czy zawieraj one to, co jest wymagane, oraz doda wszelkie sprawdzi, wymagane ograniczenia i obowizki; poinstruowa Kierownikw Zespow oraz przekaza im Grupy Zada wraz z ca odpowiedni dokumentacj i informacjami, cznie z warunkami realizacji obejmujcymi : przewidywane koszty i pracochonno; termin zakoczenia; ustalenia dotyczce raportowania postpw; dane o wszelkich osobach, grupach lub produktach, z ktrymi trzeba si styka wykonywania pracy; w trakcie Opisy Produktw; uaktualni w Zapisach Obiektw Konfiguracji informacj o statusie poprzez zmia- w realizacji dla wszystkich obiektw, ktrych to n na dotyczy; upewni si, e Kierownik Zespou posiada aktualny Plan Zespou, obejmujcy wymagania dotyczce Grupy Zada oraz odpowiednie zasoby do przeprowadzenia prac; zidentyfikowa wszelkie problemy lub zagro enia zwizane z prac oraz wprowadzi konieczne zmiany lub inne rodki, by je obsu y; upewni si, e Kierownik Zespou zobowiza si do zakoczenia prac zgodnie z przedo onymi warunkami realizacji; wyda Kierownikowi Zespou polecenie przystpienia do pracy za pomoc wa- formy Grupy Zada; ciwej

zatwierdzi wpisy dotyczce planowanych przegldw jakoci oraz osb, ktre b- im przewodniczy, dokonane w Rejestrze Jakoci podczas d Plano podprocesu (ZE1). wanie Etapu Praca opisywana w tym omwieniu mo e by wykonywana przez osoby i zasoby wewntrzne, pochodzce z organizacji klienta, przez zewntrznych dostawcw lub jako kombinacja tych dwch rozwiza. Mo e ona obejmowa tak e dostaw produktw lub usug, ktre nie wi si z adnym faktycznym nakadem pracy. Naszkicowane wy ej cele i kroki maj zastosowanie we wszystkich tych okolicznociach. Stopie sformali- Grupy Zada bdzie zale a od sytuacji projektu. Sugerowana zawarto zowania Grupy Zada jest przedstawiona w Dodatku A Zarysy Opisw , wraz z wyjanieProduktw niem ka dej pozycji. 1 10

PRINCE2

STEROWANIE ETAPEM (SE)

Podproces ten musi by realizowany w poczeniu z Przyjmowanie procesem Zada do (WP1). Ich nakadanie si obejmuje Grupy negocjacje z Wykonania Kierownikiem Zespou terminw i innych parametrw. Jeli jest to pierwsza Grupa Zada, uzgodniona z danym Kierownikiem Zespou, nale yokona sprawdzenia, by upewni si, e Kierownik Zespou jest wiadomy d procedur sterowania zmianami w projekcie.

7.4.4.

Odpowiedzialno

Kierownik Projektu odpowiada za ten podproces, korzystajc z pomocy osb, peni- rol cych Wsparcia oraz w porozumieniu z waciwymi Kierownikami Projektu, Zespow. Bibliotekarz Konfiguracji powinien uaktualni Zapisy Obiektw Konfiguracji. Nadzr Projektu mo e chcie potwierdzi, e zaplanowano odpowiednie rozwizania w zakresie kontroli jakoci.

7.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Zezwolenie Komitetu Sterujcego na przystpienie do realizacji etapu.
15

Tabela 7.1. (SE1) Informacja Objanienie

Zezwolenie na kontynuacj

Opis(-y) produktu(-w) Wejcie Opisy wymaganych ce kryteria jakoci.

produktw, zawieraj-

Sygna do podjcia prac Wejcie Informacja z podprocesw Zezwolenie na Realizacj Projektu (ZS2), Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego (ZS3), Podejmowanie Dziaa Korygujcych (SE7) lub Przegld Stanu Etapu (SE5), wymagajca utworzenia nowej lub modyfikacji Grupy Zada. Plan Etapu lub Plan Nadzwyczajny Aktualizacja Plan Etapu mo e wymaga uaktualnienia w wyniku dyskusji midzy Kierownikiem Projektu a Kierownikiem Zespou podczas podprocesu Zgoda na Wykonanie Grupy Zada (SE1) lub te ze wzgldu na zmiany powstae podczas procesu Podejmowanie Dziaa Korygujcych (SE7). Aktualizacja Zmiana statusu wszystkich produktw wyznaczonych jako cz Grupy Zada.

Zapisy Obiektw Konfiguracji

Grupa Zada Wyjcie Formalne przekazanie przez Kierownika Projektu odpowiedzialnoci za prowadzenie wyznaczonych prac oraz dostarczenie produktw, w nastpstwie uzgodnienia z Kierownikiem Zespou.

15

Dla Grupy Zada przypis tumacza.

111

CONTROLLING A STAGE (CS)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie

Rejestr Ryzyka Aktualizacja Uaktualniony po negocjacjach z Kierownikiem Zespou z uwagi na nowe lub zmodyfikowane zagro enia. Rejestr Jakoci Aktualizacja Rejestr Jakoci mo e wymaga aktualizacji w wyniku dyskusji midzy Kierownikiem Projektu a Kierownikiem Zespou, podczas podprocesu Zgoda na Wykonanie Grupy Zada (SE1), uwzgldniajcej wszelkie modyfikacje wpisw dotyczcych planowanych kontroli jakoci. Lista Kontrolna Produktw Aktualizacja Lista Kontrolna Produktw (jeli jest wykorzystywana) mo e wymaga uaktualnienia w wyniku dyskusji midzy Kierownikiem Projektu a Kierownikiem Zespou podczas podprocesu Zgoda na Wykonanie Grupy Zada (SE1) lub z uwagi na zmiany powstae podczas podprocesu Podejmowanie Dziaa Korygujcych (SE7).

Rejestr Zagadnie Aktualizacja Uaktualniony poprzez uwzgldnienie wszelkich dziaa podejmowanych w zwizku z Zagadnieniami Projektowymi.

7.4.6.

Kryteria oceny ci jako Czy Kierownik Zespou dobrze wie, co nale y wytworzy oraz co nale y przed- aby to wytworzy? siwzi, Czy Kierownik Zespou ma wiadomo oczekiwa dotyczcych nakadu pracy, kosztw i terminw zwizanych z realizacj pracy? Czy Kierownik Zespou dobrze wie, jakiej jakoci prac i produktw oczekuje si niego, a tak e czy wie, jak ta jako ma by sprawdzona, zgodnie z od odpowiednimi Opisami Produktw? Czy okrelono procedury sprawdzania jakoci i przydzielono zasoby do ich realizacji? Czy praca jest mo liwa do wykonania na ustalonych warunkach? Czy Kierownik Zespou wykazuje zaanga owanie w kierunku zrealizowania prac? Czy, zgodnie z wymaganiami, uaktualniono Plan Etapu na podstawie powzitychdotyczcych Grupy Zada? uzgodnie Czy powinien by zaplanowany szczeglnie w sprawdzaniu jakoci? jakikolwiek udzia Nadzoru Projektu,

Wskazwki i rady
W prostych projektach o maym ryzyku wydanie zgody na wykonanie Grupy Zada mo e by w uzasadnionym stopniu nieformalne, chocia nale y pomyle o zapisywaniu pracy i wynikw poszczeglnych pracownikw z myl o ich ocenianiu.

1 12

PRINCE2

STEROWANIE ETAPEM (SE)

Jeli zaanga owana jest trzecia strona, wydanie zgody na wykonanie Grupy Zada musi by zawsze formalnie udokumentowane. W idealnej sytuacji Grupa Zada nie powinna si rozciga na wicej ni jeden etap. Jeli istnieje takie niebezpieczestwo, nale y j rozdzieli w taki sposb, aby jej czci porednie weszy do jednego lub drugiego etapu zarzdczego. Jest dobr praktyk, aby osoby, ktre otrzymaj produkty kocowe Grupy Zada, byy wczane do przygotowywania stosownych Opisw Produktw, a szczeglnie kryteriw jakoci. Jeli si to uczyni, inne osoby powinny dokona przegldu Opisw Produktw. Jeli istnieje obowizujcy kontrakt midzy klientem a dostawc, mo e on wpywa na warunki wydawania zgody. Prawdziwa jest tak e sytuacja odwrotna i dlatego tryb wydawania zgody na wykonanie Grupy Zada powinien by rozwa ony podczas przygotowywania kontraktu. Podczas negocjowania pierwszej Grupy Zada z Kierownikiem lub czonkiem zespou, Kierownik Projektu powinien zapewni, eby proces sterowania zmianami by zrozumiany.

7.5.
7.5.1.

Ocena Post

pw (SE2)

Podstawowe zasady

Aby podejmowa wiadome decyzje oraz sprawowa racjonaln kontrol, konieczna jest wiedza o tym, faktyczni si wydarzyo, aby porwna j z tym, czego co e si dziewan , e si wydarzy. Gaszenie po arw oraz rozwizywanie bie cych o problemw mog zdominowa zarzdzanie projektem. Mo e to skutkowa utrat caociowe- celu przez Kierownika Projektu. Istotne jest, aby przeciwdziaa temu go widzenia za- eniu poprzez stay przepyw informacji, ktre zapewni kompletny obraz gro postpw, oraz stosujc do dostarczania tych informacji proste, odporne na zakcenia systemy monitorowania .

spo -

7.5.2.

Kontekst

W podprocesie Ocena pw (SE2) monitoruje si stan wykorzystania Post produktu, zasobw oraz wytwarzanie udokumentowane w Wykonywanie Grupy podprocesie , oraz dokonuje przegldw Rejestru Jakoci, w Zad (WP2) miar jak jest on a uaktualniany zapisami o kontrolach jakoci, przeprowadzanych przez zesp(-oy). Podproces ten otrzymuje rwnie informacje o zakoczonych oraz zatwierdzonych produktach z rocesu Odbir p Wykonanej Zada (SE9) oraz utrzymuje aktualno Planu Grupy Etapu oraz Listy Kontrolnej Produktw, jeli taka jest w u yciu.

113

CONTROLLING A STAGE (CS)

PRINCE2

WP2 Wykonywanie Grupy Zada

R ap ort z Punk tu ontr ol ne K go Pl a n Ze sp o u

SE2 Ocena Post pw

S ta tus G ru py da

Za

SE9 Odbir Wykonanej Grupy Zada

R a por t z P unk tu K ontr ol ne go I n form ac j a o sta ni e e ta pu Z e sta wi e ni e Sta tus u P rodu kt w

Pl a n E ta L i sta K ont rol na pu odu kt Pr w R e j e st r Za ga dni e tw K onfi gur a Za pi s y Obi ek cj i

R ej e s tr J a ko c i

SE5 Przegl d Stanu Etapu Dokumentacja Doku mentacja zarz dcza zarz dcza

Rysunek 7.4. Ocena Postpw

7.5.3.

Opis procesu

Celem podprocesu jest uzyskanie dokadnego i aktualnego obrazu: postpw wykonywanych prac; stanu zasobw. cym Kierownikowi Projektu do zbierania Rozdziale Elementy . Informacje sterowania s Kontrolnego. Mo na tak e zwrci si do Produktw, ktre dostarczy informacji o

Gwnym elementem sterowania, su danych, jest punkt kontrolny opisany w 16 umieszczane w Raporcie z Punktu zarzdzania konfiguracj o Zestawienie Statusu statusie produktw etapu.

Aby osign te cele, nale y podejmowa nastpujce kroki: zebra wszystkie informacje o postpach wszystkich aktualnie podjtych prac; zebra informacje zwrotne o przeprowadzonych ostatnio dziaaniach w zakresie kontroli jakoci; oceni szacowany czas i nakady pracy pozostae do zakoczenia wszelkich prac, ktrych jeszcze nie zakoczono (wczajc w to prace jeszcze nierozpoczte); oceni wykorzystanie zasobw w okresie podlegajcym przegldowi oraz ich dostpno dla pozostaej do wykonania czci etapu (lub projektu); dokonywa, wraz z Kierownikiem(-ami) Zespou(przegldu Planw Zespow), aby ustali, czy prace bd zakoczone w terminie i w ramach bud w, etu; przeglda wpisy do Rejestru Jakoci, sprawdzajc, czy jakie kontrole ulegy opnieniu i jakie s wyniki ostatnich kontroli; uaktualni Plan Etapu o dane dotyczce faktycznego wykonania prac;

1 14

PRINCE2 zidentyfikowa wszelkie sprawy podprocesie Przeg d Stanu (SE5) . l Etapu Odpowiedzialno wymagajce

STEROWANIE ETAPEM (SE) zwrcenia uwagi w

7.5.4.

Kierownik Projektu jest odpowiedzialny za ten podproces, uzyskujc pomoc od osb penicych rol Wsparcia Projektu. Bibliotekarz Konfiguracji mo e dostarczy potrzebne Zestawienie Statusu Produktw. Jeli Kierownik Zespou pracuje dla dostawcy, kt- nie stosuje PRINCE2, Grupa Zada bdzie nadal zawieraa wymagania ry dotyczce przedstawiania Raportw z Punktw Kontrolnych. Nadzr Projektu mo e dokona przegldu uaktualnionego Rejestr u Jakoci.

7.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Przepywy informacji, na pimie lub ustnie, w zale noci od potrzeb formalnych. Informacje powinny obj aktualny stan Grup Zada w odniesieniu do planu.

Tabela 7.2. SE2 Informacja Objanienie

Raporty z Punktw Kontrolnych

Rejestr Jakoci Wejcie Wyniki kontroli jakoci wykonanych prac. Rejestr Zagadnie Aktualizacja Mog wystpi nowe Zagadnienia Projektowe, ktre wpyn na stan etapu lub na odwrt. Status Grupy Zada Wejcie W celu uaktualnienia Planu Etapu. Plan Etapu Aktualizacja Uaktualniony danymi o faktycznej realizacji, prognozach i korektach. Lista Kontrolna Produktw Informacja o stanie etapu Aktualizacja Jeli jest wykorzystywana - uaktualniona danymi o faktycznej realizacji, prognozach i korektach. Wyjcie Zawiera podsumowanie informacji o postpach.

Plan Zespou Wejcie Zestawia prace do wykonania i wszelkie wymagania dotyczce raportowania. Zestawienie Statusu Produktw Zapisy Obiektw Konfiguracji Wyjcie Dostarcza informacji o stanie produktw nalecych do Grupy Zada. Aktualizacja Zmiana statusu wszelkich produktw objtych Grup Zada.

7.5.6.

Kryt eria oceny ci jako Czy poziom i czstotliwo oceny postpw s prawidowe dla etapu i/lub Grupy Zada? Czy informacje s dostarczane w terminie oraz czy s u yteczne i dokadne? 115

CONTROLLING A STAGE (CS) Czy oszacowania obiektywne? prac pozostajcych do wykonania s

PRINCE2

Wskazwki i rady
Postpy powinny by mierzone i raportowane w sposb, ktry jest wystarczajco dokadny i nie zezwala na ich wyolbrzymianie. Pomiar postpw i stanu jest atwiejszy, jeli zbieranie informacji jest zorientowane na produkty, jak w procesie Planowanie (PL) . Aby uzyska dokadny obraz wydatkw w projektach bardziej zo onych lub majcych krytyczne znaczenie, mo na rozwa y wykorzystanie metody wartoci wypracowanej. W zale noci od parametrw projektu, takich jak rozmiar i rozproszenie geograficzne, podproces ten mo e przebiega formalnie lub nieformalnie. Kierownik Projektu mo e organizowa narady w punktach kontrolnych z Kierownikami Zespow, natomiast Kierownicy Zespow mog odbywa swoje wasne narady w punktach kontrolnych ze swoimi zespoami. Informacja o stanie etapu powinna si skada z Raportw z Punktw Kontrolnych, statusu Grupy Zada, Rejestru Jakoci oraz wszelkich innych tego rodzaju informacji lub te by ich streszczeniem. W wielu przypadkach takie informacje bd zapisywane w Dzienniku, szczeglnie w maych projektach.

7.6.
7.6.1.

Rejestrowanie Zagadnie
Podstawowe zasady

Projektowych (SE3)

W trakcie zarzdzania projektem wystpi r ne problemy, pojawi si pytania or az zmiany. Bd one wystpoway przypadkowo i musz by wychwytywane w konsekwentny i niezawodny sposb, tak aby mo na byo waciwie je oceni i nimi zarzdza. Wa ne jest szczeglnie wtedy, gdy rozwizania. tak e, aby Zagadnienia Projektowe nie zostay nie znaleziono dla nich natychmiastowego Kontekst zapomniane,

7.6.2.

Podproces jest ze swej natury ad , poniewa przetwarza on realizowany pytania i zmiany wtedy, kiedy wystpi.szczego-mog pochodzi z hoc wo problemy, Te za szero- zakresu rde zarwno wewntrznych, jak i kiego zewntrznych. Podproces Rejestrowanie Projektowyc (SE3) dostarcza informacji Zagadnie h przekazywanych dalej do podprocesu Analizowanie Projektowyc (SE4). Ten podZagadnie h proces powinien by studiowany w poczeniu z Rozdziaem Sterowanie 20 Rozdziaem 23 Technika zmianami oraz sterowanie . zmianami

1 16

PRINCE2

STEROWANIE ETAPEM (SE)

Podproces ten stanowi punkt wejciowy dla wszystkich zewntrznych bodcw, takich jak zmiany zakresu, powiadomienia o problemach czy zawiadomienia o no- zagro eniach. wych
Wszelkie zainteresowane strony

N owe towe

Za ga dni e nia

P ro je k

Do kumentacja Dokumentacja zarz dcza zarz dcza

Re j e s tr Za ga dni e

SE3 Rejestrowanie Z agadnie Projektowych

U a kt ual n io nye je s tr R Za ga dni e

SE4 Analizo wanie Z agadnie Projektowych

Rysunek 7.5. Projektowych

Rejestrowanie

Zagadnie

7.6.3.

Opis procesu

Podproces ma na celu wychwytywanie, rejestrowanie i kategoryzacj wszystkich Zagadnie Projektowych. Wi si z tym nastpujce kroki: wprowadzenie wszystkich Zagadnie Projektowych do Rejestru Zagadnie, gdy zostan one ujawnione. Sugestie dotyczce wykonania rejestracji znajduj tylko siRozdziale 23 Technika w sterowanie ; zmianami dokonanie oceny, czy Zagadnienie Projektowe jest: Wnioskiem o Wprowadzenie Zmiany; Odstpstwem ; nowym zagro eniem; oglnym zagadnieniem. Wyjanienia na temat rodzajw Zagadnie Projektowych znajduj si w Rozdziale 20 Sterowanie . zmianami Sugerowane struktury zawartoci Zagadnienia Projektowego i Rejestru Zagadnie przedstawiono w Dodatku A Zarysy Opisw . Produktw Ka da istotna informacja zewntrzna otrzymywana od Komitetu Sterujcego (wpr owa- poprzez ZS4) powinna zosta zarejestr owana przez Kierownika Pr ojektu po dzana jej odebraniu jako Zagadnienie Projektowe.

117

CONTROLLING A STAGE (CS)

PRINCE2

7.6.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik chocia osoba penica Projektu, Projektu (Bibliotekarz Konfiguracji) mo e by wyznaczona do dziaania rol Wsparcia jako centrum przyjmowania i dokumentowania Zagadnie Projektowych.

7.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Wszelkie Zagadnienia Projektowe, z dowolnego rda, wnoszone w zwizku z projektem s rejestrowane w Rejestrze Zagadnie wraz z okreleniem ich rodzaju.

Tabela 7.3. SE3 Informacja Objanienie

Nowe Zagadnienia Projektowe

Rejestr Zagadnie Aktualizacja Repozytorium wszystkich Zagadnie Projektowych i ich statusw.

7.6.6.

Kryteria oceny ci jako Czy wszystkie istotne Zagadnienia Projektowe zostay udokumentowane? Czy Zagadnienie Projektowe jest nowe, czy te jest to wczeniejsze Zagadnienie inaczej sformuowane? Czy zostao zidentyfikowane rdo Zagadnienia Projektowego? Czy Zagadnienie Projektowe wpywa na Plan Projektu i na Plan Etapu? Czy Zagadnienie Projektowe jest zapytaniem, na ktre mo na odpowiedzie bez dokonywania zmiany Planu Etapu?

Wskazwki i rady
Czasami Zagadnienie Projektowe jest tak zo one, e lepiej jest podzieli je na kilka mniejszych Zagadnie Projektowych. Jeli projekt jest czci programu, kopia Zagadnienia Projektowego musi zosta przekazana do biura wsparcia programu, by sprawdzi jego wpyw na program jako cao lub na inne projekty w tym programie. Ze wzgldu na pniejsze audyty, nawet gdy Zagadnienie Projektowe jest zwykym pytaniem odnoszcym si do projektu, zaleca si zarejestrowanie zarwno samego pytania, jak i udzielonej odpowiedzi.

1 18

PRINCE2

STEROWANIE ETAPEM (SE)

7.7.
7.7.1.

Analizowanie Zagadnie
Podstawowe zasady

Projektowych (SE4)

Zanim podejmie si decyzj o kierunku dziaania, ka de Zagadnienie Projektowe nale yceni pod ktem jego wpywu i rozwa y dziaania o alternatywne.

7.7.2.

Kontekst

W ramach Rejestrowanie Projektowyc (SE3) rejestruje podprocesu kataloguje Zagadnie h si i Zagadnienia Projektowe. Natomiast ten podproces (SE4) wszystkie Zagadnienia Projektowe,bada ktre jeszcze nie zostay rozwizane. Nale y przejrze otwarte Zagadnienia Projektowe oraz zaleci kierunki dziaa, do rozwa wszystkie enia w podprocesie Przeg d Stanu (SE5). l Etapu
SE3 Rejestrowanie Zagadnie Projektowych
Uaktualniony Rejestr Zagadnie

SE4 Analizowanie Zagadnie Projektowych

Rejestr Ryzyka Rejestr Zagadnie

Uzasadnienie Biznesowe Plan Projektu Plan Etapu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 7.6. Projektowych

Analizowanie

Zagadnie

7.7.3.

Opis procesu

Wstpne badanie Zagadnienia Projektowego powinno by przeprowadzone zaraz po jego zarejestrowaniu. Wszystkie otwarte Zagadnienia Projektowe powinny by przegldane regularnie. Decy- kierunku dziaania nie powinny by podejmowane, dopki na Zagadnienie zje o Projektowe nie spojrzy si w szerszym kontekcie stanu etapu, dostawy produktu oraz post-w odniesieniu do planu. Wyjtkiem od takiej zwoki jest sytuacja, gdy pw Zagadnienie Projektowe wywouje piln potrzeb Chocia wikszo Zagadnie Projekdziaania. towych bdzie bezporednio zwizana z projektem, podproces musi dopuszcza Zagad- Projektowe oddziaujce na otoczenie projektu np. na pr ogram. Takim nienia zagad- nale y nada status zamknite wraz z adnotacj, e zostay przeniesione nieniom do Rejestru Zagadnie programu.

119

CONTROLLING A STAGE (CS)

PRINCE2

W celu przygotowania Zagadnie Projektowych do przegldu, przeprowadzanego w ramach podprocesu Przeg d Stanu (SE5) , nale y podj nastpujce l Etapu kroki: zgromadzi wszystkie istotne informacje o Zagadnieniu Projektowym, czniewpywem na: z jego koszty; terminy ; uzyskanie korzyci i/lub wartoci; zagro enia; spenienie wymaga projektu; sprostanie ustalonym standardom jakoci; przewidzie alternatywne kierunki dziaania; uaktualni Rejestr jeli Zagadnienie Projektowe odnosi si Ryzyka, zidentyfikowanego zagro eniauprzednio lub ujawnia nowe zagro enie; skorygowa, jeli to konieczne, priorytet Zagadnienia Projektowego; zaleci kierunek dziaania. Zalecenie mo e dotyczy kilku Zagadnie Projektowych. Odpowiedzialno

do

7.7.4.

Za podproces jest odpowiedzialny Kierownik Projektu. Od czonkw zespow mo na wymaga dokonania oceny wpywu Zagadnie Projektowych na produkty, pracochonno, koszty, harmonogram i ryzyko, oraz obmylenia alternatywnych kierunkw dzia- Niektre czynnoci administracyjne mo na delegowa osobom penicym a. rol Wsparcia Projektu. Osoby penice obowizki Nadzoru Projektu powinny by wczone w badanie wpywu Zagadnienia Projektowego na produkty, zagro enia oraz Uzasadnienie Biznesowe. Bibliotekarz Konfiguracji, jeli jest mianowany, bdzie odpowiedzialny za prowadzenie Rejestru Zagadnie. To, kto bdzie podejmowa decyzje o dziaaniach z Zagadnieniem Projektowym, zale y od rozstrzygni dokonanych zwizanych pod- procesu Inicjowanie czas (IP) . Kierownik Projektu powinien omwi Projektu szacowan liczb i zakres zmian z Komitetem Sterujcym, ktry rozstrzygnie, czy sam bdzie podejmowa decyzje dotyczce Zagadnie Projektowych, czy te deleguje je Komisji ds. zmian. (Dla uzyskania dalszych informacji na temat poziomw uprawnie patrz Rozdzia 20 Sterowanie ). zmianami

7.7.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Ponowne rozpatrzenie Uzasadnienia Biznesowego w celu oceny wpywu Zagadnienia Projektowego.

Tabela 7.4. SE4 Informacja Objanienie

Uzasadnienie Biznesowe

Plan Etapu Wejcie Jedna z podstaw do analizy wpywu.

1 20

PRINCE2

STEROWANIE ETAPEM (SE)

Plan Projektu Wejcie Sprawdzenie wpywu Zagadnienia Projektowego na projekt. Rejestr Zagadnie Aktualizacja Lista wszystkich nierozstrzygnitych Zagadnie Projektowych i ich statusu, uaktualniona informacjami z analizy wpywu. Rejestr Ryzyka Aktualizacja Istniejce zagro enia, na ktre Zagadnienie Projektowe mo e mie wpyw. Do uaktualnienia, jeli zalecane jest jakiekolwiek dziaanie, ktre bdzie oddziaywa na znane, lub spowoduje nowe zagro enie.

7.7.6.

Kryt eria oceny ci jako Kto najlepiej oceni Zagadnienie Projektowe? Jak pilne jest podjcie decyzji? Czy wiadomo, kiedy decyzja musi by podjta? Czy dla zabezpieczenia najwa niejszych interesw klienta jest potrzebne jakie specjalne dziaanie w trakcie oceny? Czy czas i nakady pracy na ocen Zagadnienia Projektowego zostay wprowadzo-Etapu? ne do Planu W jaki sposb odnone kontrakty traktuj zmiany? Czy istnieje odrbny bud et zmian? Na ktre produkty mogoby wpyn Zagadnienie Projektowe? Kto byby wczony w podjcie jakiego dziaania? Czy istniej alternatywne kierunki dziaania? Jaki byby koszt r ozwizania Zagadnienia Projektowego w kategoriach nakadu pracy i pienidzy? Jaki jest wpyw Zagadnienia Projektowego na Uzasadnienie Biznesowe? Czy wdro enie zmiany zmienioby aktualne cele projektu, ktre wyspecyfikowano w Dokumencie Inicjujcym Projekt? Jaki byby wpyw Zagadnienia Projektowego na pozycje znajdujce si w Rejestrze Ryzyka?

Wskazwki i rady
Analiza wpywu nowego Zagadnienia Projektowego powinna by wykonana po jego przyjciu tak szybko, jak to jest mo liwe. W Planie Etapu nale y uwzgldni czas dla osb z wiedz fachow, konieczn do przeprowadzenia analizy. Przegldy otwartych Zagadnie Projektowych powinny odbywa si regularnie i czsto. Ten podproces oraz Przegld Stanu Etapu (SE5) nie musz by formalnie rozdzielone w maych i rednich projektach, ale gromadzenie informacji lub rozmowa z autorem mogyby by trudne do przeprowadzenia w trakcie przegldu stanu etapu.

121

CONTROLLING A STAGE (CS)

Pilno i waga Zagadnienia Projektowego to nie s te same rzeczy. Pilnymi Zagadnieniami Projektowymi nale y si zaj si od razu. Wa ne Zagadnienia Projektowe naley rozpatrzy wszechstronnie. Nale y oddzieli kwestie banalne tak wczenie, jak tylko jest to mo liwe, aby mc si skoncentrowa na wa nych Zagadnieniach Projektowych. Autorom Zagadnie Projektowych nale y przekazywa informacje zwrotne na temat podjtych dziaa.

PRINCE2

7.8.
7.8.1.

Przegl d Stanu Etapu (SE5)

Podstawowe zasady

Praca Kierownika Projektu mo e zosta atwo zdominowana przez rozwizywanie biecych problemw. Mo e to oznacza, e caociowe postpy nie s regularnie sprawdzane. Jeli projekt nie jest regularnie kontrolowany, istnieje niebezpieczestwo, e ymknie si on spod kontroli. Wymagana jest wic rwnowaga midzy w planowaniem a reagowaniem na bie ce przyszoci wydarzenia. Czsto bdzie si pojawiaa konieczno doczenia nieplanowanych dziaa. Musi by prowadzona regularna kontrola wydarze zewntrznych, ktre mogyby na projekt. wpywa

7.8.2.

Kontekst si informacje zgromadzone w Ocena pw Projektowyc (SE4) oraz podejmuje Post decyzje, si h jakie

W podprocesie czy podprocesach (SE2) i Analizowanie dziaaniaZagadnie y. nale y wdro

Jeli etap oraz projekt mieszcz si w granicach tolerancji, nastpnymi dziaaniami s Raportowanie (SE6) do Komitetu Sterujcego Zgoda na Okresowe (SE1) dla oraz Wykonanie Grupy Zada kolejnych prac. Jeli konieczne s dziaania korygujce, ale przewiduje si, e etap i projekt pozostaj w granicach tolerancji, nastpnym podprocesem Podejmowanie Korygu bdzie (SE 7). Dziaa j cyc h Kierownik Pr ojektu mo e szuka porady w Komitecie na temat Sterujcym Projektowego jakiego powinien Zagadnienia Podejmowanie Korygu cyc (SE 7)), a ( Dziaa projekt mo e wyj poza tolerancje to Przekazywa j h uczyni zawsze, je eli przewiduje, e ( nie Projektowyc (SE8)) . Innym powodem odwoywania -si do Zagadnie byaby ocena, e Zagadnienie Projektowe ma wpyw na polityk h Komitetu Sterujcego zewntrzn w stosunku do projektu.

1 22

PRINCE2

STEROWANIE ETAPEM (SE) Opis procesu

7.8.3.

Podproces zapewnia rodki do dokonywania regularnej oceny stanu etapu. W jego trak- decyduje si, cie czy: nale y zaproponowa dodatkowe Grupy Zada; wymagane planu. s jakie modyfikacje
ZP1 Przygotowanie Projektu do Zamkni cia
Informacja o stanie etapu Powiadomienie

SE6 Raportowanie Okresowe

SE2 Ocena Post pw

o ko czeniu projektu Zestawienie statusu produktw Informacja o stanie etapu Sygna do podj cia

Dziennik

SE5 Przegl d Stanu Etapu

prac Odchylenie od planu

SE1 Zgoda na Wykonanie Grupy Zada

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rejestr Zagadnie Rejestr Ryzyka Plan Etapu Plan Projektu Rejestr Jako Uzasadnienie Biznesowe Lista Kontrolna Produktw Zapisy Obiektw Konfiguracji ci

Powiadomienie o ko czeniu etapu

SE7 Podejmowanie Dziaa Koryguj cych

ZE1 Planowanie Etapu

Zagro enie przekroczeniem tolerancji

Ust pstwo

SE8 Przekazywanie Zagadnie Projektowych

Rysunek 7.7. Przegld stanu etapu Pierwszym celem tego podprocesu jest okresowe spr awdzanie, czy bie cy etap jest utrzymywany w granicach tolerancji ustalonych przez Komitet Sterujcy, poprzez: dokonywanie przegldu postpw w odniesieniu do Planu Etapu i Listy Kontr olnej Produktw - jeli taka jest w u yciu; sprawdzanie Rejestru Jakoci w celu stwierdzenia stanu kontroli jakoci; sprawdzanie Zapisw Obiektw Konfiguracji w celu zagwarantowania, e wszystkie produkty zostay zakoczone jak zapisano i przewidywano; dokonywanie przegldu wykorzystania zasobw oraz ich przyszej dostpnoci; 123

CONTROLLING A STAGE (CS)

PRINCE2

dokonywanie przegldu wpywu Zagadnie Projektowych na przyjty bud et zmian oraz Plan Etapu i Plan Projektu; ustalanie, czy etap wyjdzie poza granice tolerancji; przekazywanie Komitetowi Sterujcemu do rozpatrzenia Zagadnie Projektowych, ktre prawdopodobnie spowoduj przekroczenie tolerancji, Przekazywani poprzez Projektowyc e Zagadni (SE8). e h Jeli dziaanie korygujce jest konieczne, ale przewiduje si, e etap pozostanie tolerancji, mo e by ono podjte przez Kierownika Projektu, tak jak w granicach to przedstawiono w opisie Podejmowanie Korygu cyc (SE7). podprocesu Dziaa j h Drugim celem podprocesu jest dokonanie przegldu stanu projektu, a w szczeglnoci: sprawdzenie, czy Uzasadnienie Biznesowe jest nadal suszne; dokonanie przegldu Rejestru Ryzyka pod ktem mo liwych zmian; ustalenie, czy projekt wyjdzie poza gr anice tolerancji; zapewnienie, e nie wystpuj adne problemy dotyczce jakoci. Aby osign te cele, nale y podj nastpujce dziaania: okreli wszelkie odchylenia pomidzy planem i faktyczn realizacj; sprawdzi, czy nie w przyszoci ma zmian w oczekiwanej dostpnoci zasobw; dokona oceny wszystkich aktualnych zagro e dla Planu Etapu pod ktem ekspo- na ryzyko (stopnia zagro zycji enia); sprawdzi uaktualniony Plan Etapu pod ktem po jawiania si nowych zagro e; sprawdzi wszelkie problemy zwizane z jakoci, przedstawione w Rejestrze Jakoci; dokona przegldu nowych zdarze zewntrznych pod ktem ich wpywu na projekt;

sprawdzi, czy zdarzyo si cokolwiek wewntrz lub na zewntrz projektu, co bdzie miao wpyw na Uzasadnienie Biznesowe; oceni, czy etap bdzie pozostawa w granicach tolerancji; przyj wszelkie Ustpstwa poczynione przez Komitet Sterujcy w odpowiedzi na Raport o Istotnych Odchyleniach i oceni ich wpyw na pniejsze prace; wykorzysta podproces Zgoda na Wykonanie Grupy (SE1), by wyda zgod na wszelkie niezbdneZada prace wy magane przez Plan nowe Etapu. Kierownik Projektu mo e wykorzysta Dziennik do odnotowania ka dego z powy ej wymienionych sprawdze, ktre powinny by przeprowadzone, oraz wielu mniejszych ktre dziaa, s potrzebne po ich przeprowadzeniu.

7.8.4.

Odpowiedzialno

Za podproces odpowiada Kierownik wspomagany przez osoby penice Projektu, Projektu, cznie z Bibliotekarzem Konfiguracji, oraz wykonujce rol Wsparcia obowizki Projektu. Mo e okaza si konieczne skonsultowanie si z czonkami Nadzoru Komite1 24

PRINCE2

STEROWANIE ETAPEM (SE)

tu Sterujcego w celu uzyskania porady, szczeglnie w odniesieniu do Zagadnie Projektowych, niedostatku zasobw lub te zewntrznych wydarze, ktre mog mie wpyw na Uzasadnienie Biznesowe lub Rejestr Ryzyka.

7.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 7.5. SE5 Informacja Objanienie

Rejestr Zagadnie Wejcie Pokazuje aktualn sytuacj wszystkich Zagadnie Projektowych. Mo e by potrzebny jako rdo informacji podczas podejmowania decyzji o odpowiednim postpowaniu z nimi. Rejestr Ryzyka Wejcie Pokazuje aktualne zrozumienie problemw i zagro e dla projektu. Plan Projektu Wejcie Sprawdzenie w celu ustalenia, czy jakikolwiek problem zwizany z etapem (lub potencjalna zmiana) miaby wpyw na Plan Projektu. Lista Kontrolna Produktw Wejcie Jeli jest stosowana, ukazuje rzeczywiste i planowane terminy dostarczenia kluczowych produktw.

Rejestr Jakoci Wejcie Okrela stan kontroli jakoci. Uzasadnienie Biznesowe Zapisy Obiektw Konfiguracji Wejcie Jest ono sprawdzane pod ktem wpywu postpw aktualnego etapu. Wejcie Dostarczaj informacji o aktualnym statusie produktw.

Plan Etapu Wejcie Uaktualniony w procesie Ocena Postpw (SE2), stanowi obiekt odniesienia, w stosunku do ktrego mierzy si postpy oraz przestrzeganie tolerancji dla etapu. Ustpstwo Wejcie Decyzja Komitetu Sterujcego o zaakceptowaniu Zagadnienia Projektowego bez koniecznoci dziaa korygujcych. Odchylenie od planu Wyjcie Informacja, ktra ma by przekazana do procesu Podejmowanie Dziaa Korygujcych (SE7). Zagro enie przekroczeniem tolerancji Informacja o stanie etapu Wyjcie Sygna wyzwalajcy dla Raportu o Istotnych Odchyleniach. Wejcie/Wyjcie Informacja o aktualnych postpach projektu, przekazywana dalej do podprocesu Raportowanie Okresowe (SE6).

125

CONTROLLING A STAGE (CS)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie
Wyjcie Sygna wyzwalajcy podproces Zarzdzanie Zakresem Etapu (ZE) (w odpowiednim czasie bliskim koca etapu). Wyjcie Sygna do rozpoczcia procesu Zamykanie Projektu (ZP) (w odpowiednim czasie blisko koca ostatniego etapu). Wyjcie Sygna wyzwalajcy wydanie nowej Grupy Zada w podprocesie Zgoda na Wykonanie Grupy Zada (SE1).

Powiadomienie o koczeniu etapu Sygna do zamykania projektu Sygna do podjcia pracy

7.8.6.

Kryteria oceny ci jako Czy rozwa ono wszystkie aspekty Projektowych oraz ryzyka?

dotyczce

postpu

prac,

Zagadnie

Czy zostay one tak wywa one, aby wytworzy kompletny obraz aktualnego stanu projektu? Czy wszystkie uzasadnione kierunki dziaa zostay rozwa one podczas podejmo-decyzji o najlepszym sposobie dalszego wania postpowania? Czy projekt oceniono rzetelnie, okrelajc prawdopodobiestwo utrzymania si w granicach tolerancji? Czy oszacowania dotyczce zakoczenia projektu wydaj si uzasadnione w wietle wszystkich dostpnych informacji?

Wskazwki i rady
Chocia podproces ten jest przedstawiony jako niezale ny, by poo y nacisk na wag regularnego sprawdzania postpw, czsto bdzie on przebiega jednoczenie z innymi podprocesami. Na przykad rwnolegle do tego podprocesu mo e by przygotowywany Raport Okresowy (Raportowanie Okresowe (SE6)) , a tak e mo na uruchamia prace do wykonania w nastpnym okresie (Zgoda na Wykonanie Grupy Zada (SE1)) . Przegld Stanu Etapu (SE5) jest podprocesem cyklicznym\iteracyjnym. Stan etapu powinien by regularnie poddawany przegldom - czstotliwo przegldw jest zwizana z dugoci planowanych dziaa oraz potrzeb (z drugiej strony) cisej kontroli. W maych i rednich projektach przegldy mo na dokonywa co tydzie; przegldy w du ych projektach mog by dokonywane co dwa tygodnie lub co miesic. Stan obiektw znajdujcych si na cie ce krytycznej lub blisko niej (patrz: Rozdzia 11 Planowanie (PL)) mo e wymaga czstszego monitorowania ni inne elementy planu. Jeli projekt jest czci programu, ka de nowe lub zmienione zagro enie musi by przekazane do biura wsparcia programu w celu sprawdzenia mo liwego wpywu na inne czci programu.

1 26

PRINCE2

STEROWANIE ETAPEM (SE)

7.9.
7.9.1.

Raportowanie Okresowe (SE6)

Podstawowe zasady

Komitet Sterujcy ponosi cakowit odpowiedzialno za wynik projektu, deleguje za ce zarzdzanie Kierownikowi Projektu. Dobre struktury sprawozdawcze bie sprawiaj, Sterujcy (i inne zainteresowane strony) jest poinformowany i zaanga e Komitet owany.

7.9.2.

Kontekst

W tym podprocesie opracowuje si Raporty Okresowe, ktre s przekazywane Komitetowi Sterujcemu Podejmowanie Decyzji nyc (ZS4 )], zawierajce [patrz: o postpach oraz inne, zdefiniowane w Planie Komunikacji, informacje dla Dora h informacje interesariuszy .

Wiadomo ci dla zainteresowanych stron Raporty Okresowe

SE5 Przegl d Stanu Et apu

Informacja o stanie etapu

SE6 Raportowanie Okresowe

ZS4 Podejmowanie Decyzji Dora nych

Dokumentacja Dokumentacja zarz dcza zarz dcza

Reje str Zagadnie Informacja Reje str Ryzyka o stanie etapu Plan Etapu Reje str Jako ci Plan Komunikacji Lista Kontrolna Produktw Poprzedni Raport Okresowy Raporty z Punktw Kontrolnych

Kopia Raportu Okresowego

Rysunek 7.8. Raportowanie Okresowe

7.9.3.

Opis procesu

Podproces ma na celu: dostarczenie Komitetowi Sterujcemu skrtowej informacji o stanie etapu i projektu, z czstotliwoci okrelon przez Komitet Sterujcy; przekazywanie wszelkich innych informacji wymaganych przez Plan Komunikacji.

127

CONTROLLING A STAGE (CS) Aby osign te cele, nale y podj nastpujce dziaania: zestawi informacje pochodzce z Raportw z dane o wszelkich istotnych korektach Planu Etapu lub (jeli jest , ktre zrealizowano stosowana)(SE 7); podprocesie gu cyc j h okreli aktualne lub potencjalne problemy podprocesie nu (SE5) ; Etapu opracowa Raport Okresowy;

PRINCE2

Punktw Kontrolnych oraz Listy Kontrolnej Produktw w Podejmowanie Dziaa Kory ujawnione w Przeg d l Sta-

przesa Raport Okresowy do Ko mitetu Sterujcego; ustali z Planu Komunikacji innych uzgodnionych odbiorcw Raportu Okresowego oraz przesa go im.

7.9.4.

Odpowiedzialno

do

Za podproces odpowiada Kierownik Projektu, wspo magany przez osoby penice rol Wsparcia Projektu. Nadzr mo e chcie oceni tr e raportw Projektu Komitetu Sterujcego.

7.9.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 7.6. SE6 Informacja Objanienie

Plan Etapu Wejcie Informacje o dostarczonych produktach, tolerancjach oraz stanie harmonogramu i bud etu, wczajc w to odchylenia raportowane z SE2. Lista Kontrolna Produktw Poprzedni Raport Okresowy Wejcie Je eli jest stosowana status zrealizowanych i planowanych dostaw produktw. Wejcie Sprawdzenie, czy wszystkie produkty, ktrych dostarczenie przewidywano, zostay dostarczone i czy sygnalizowane wczeniej problemy zostay rozwizane. Wejcie Informacje o postpach prac od zespou(w). Wejcie/ Wyjcie Informacja o postpach w projekcie w odniesieniu do planu.

Raporty z Punktw Kontrolnych Informacja o stanie etapu

Rejestr Ryzyka Wejcie Informacja, czy jakie zagro enia ulegy zmianie. Rejestr Zagadnie Wejcie Informacje o wszelkich potencjalnych problemach, ktre musz by przedstawione do rozpatrzenia Komitetowi Sterujcemu.

1 28

PRINCE2

STEROWANIE ETAPEM (SE)

Informacja Objanienie

zarzdcza

Wykorzystanie

Rejestr Jakoci Wejcie Status planowanych i przeprowadzonych kontroli jakoci. Plan Komunikacji Wejcie Identyfikacja zainteresowanych stron, ktre mog potrzebowa informacji w tym okresie raportowania. Raport Okresowy Wyjcie Informacje przedstawione w sposb wymagany przez Komitet Sterujcy. Wiadomoci dla zainteresowanych stron Wyjcie Zawarto okrelono w Planie Komunikacji.

7.9.6.

Kryt eria oceny ci jako Czy informacje zostay przygotowane w formie wy maganej przez Komitet Sterujcy? Czy raport jest czstotliwoci? rozsyany z uzgodnion

Wskazwki i rady Raport powinien by tak krtki, jak jest to mo liwe, i zgodny z potrzebami informacyjnymi Komitetu Sterujcego. Sugerowana dugo r aportu to jedna lub dwie strony. W sytuacjach, gdy jaka grupa wsparcia operacyjnego przejmie odpowiedzialno za produkt kocowy, powinna by ona dopisana do listy odbiorcw Raportu Okresowego.

7.10.
7.10.1.

Podejmowanie Dziaa
Podstawowe zasady

Koryguj cych (SE7)

Zmiany i dostosowania w projekcie musz by wykonywane w sposb rozwa ny i racjonalny, nawet wtedy, gdy wydaj si one wystarczajco atwe do zarzdzania, by zmieci je w granicach tolerancji.

7.10.2.

Kontekst

Podproces jest wyzwalany przez ujawnienie odchylenia i wywouje dziaanie koryguj-e by potrzebny wkad ze strony innych czonkw zespou zarzdzania ce. Mo projektem.

129

CONTROLLING A STAGE (CS)

PRINCE2

SE5 Przegl d Stanu Etapu

O dc hy l e ni e od pl a nu

SE7 Podejmowanie Dziaa Koryguj cych

S y gna o po c i a pr ac d dj

SE1 Zgoda na Wykonanie Grupy Zada

Za l e c e ni a mi te tu Ko S te r uj c e go Pr o Re j e s tr Za ga d ni e Re j e s tr Ry zy k a Za p i sy O bi e k tw Kon fi gu ra c ji ba o r ad P l a n E ta pui st a Kont r ol L na r odu k P tw

ZS4 Podejmowanie Decyzji Dora nych

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 7.9. Podejmowanie Dziaa Korygujcych

7.10.3.

Opis procesu

Celem podprocesu jest wybranie oraz (w ramach ogranicze wynikajcych z tolerancji etapu i projektu) wdro enie dziaa, ktre zlikwiduj odchylenia od planu. Mog by wymagane decyzje Komitetu Sterujcego uzyskiwane poprzez uruchomienie podp rocesu Podejmowanie Decyzji nyc (ZS4 ). Kierownik Projektu musi Dora h Komitetu zdecydowa, kiedy zwrci si o rad do Sterujcego. Aby osign te cele, tr zeba wykona szereg r nych krokw. Je eli informacja pochodzi z procesu Analizowanie Projektowyc (SE4) , niektre z nich mogy Zagadnie h ju by zrealizowane. Te kroki to: skompletowanie wszelkich informacji, majcych zwizek z odchyleniem; zidentyfikowanie penego zwizku przyczynowo- skutkowego dla odchylenia; ustalenie potencjalnych sposobw postpowania z odchyleniem; wybranie najwaciwszej opcji; zgromadzenie wszystkich informacji o problemie (mo e on ju by Zagadnieniem oraz wszelkich zalece, w sytuacjach, gdy niezbdne s wytyczne Projektowym) ze strony Komitetu Sterujcego; udostpnienie z biblioteki konfiguracji wszystkich produktw, bdcych obiektami 16 ; odniesieni a uruchomienie dziaa korygujcych (poprzez Zgoda na podproces (SE1)). Wykonanie Grupy Zada Jeli dziaania s niewielkie, a pr oblem mo e zosta rozwizany bez zmiany planu lub modyfikacji Grupy Zada, mo na wykorzysta Dziennik do odnotowania, jakie dziaania trzeba podj, przez kogo i w jakim terminie. Kierownik Projektu mo e nastpnie
16

Aby sprawdzi, czy mo na podj dziaania krygujce, ktre nie powinny dotyczy produktw zatwierdzonych (obiektw odniesienia) przypis tumacza.

1 30

PRINCE2

STEROWANIE ETAPEM (SE)

wykorzysta te zapisy do rozmw z zainteresowanymi osobami oraz dalej postpowa tak, by zapewni podjcie dziaa. Jeli nie odnosi to po danego skutku, mo na podj formalne dziaania, takie jak modyfikacja planu i Grupy Zada, spor bardziej zdzenie o Istotnych Odchyleniach, lub umieci jedynie zapis w nastpnym Raportu Raporcie Okresowym.

7.10.4.

Odpowiedzialno

Odpowiedzialno za podproces ponosi Kierownik Projektu, wspomagany przez osoby rol Nadzoru Projektu oraz Wspar cia Projektu, zasigajc w razie potrzeby penice rad Kierownikw Zespow. Jeli mianowano Bibliotekarza Konfiguracji, osoba ta na udostpni wszelkie powinpotrzebne produkty i uaktualni Zapisy Obiektw Konfiguracji.

7.10.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 7.7. SE7 Informacja Objanienie

Odchylenie od planu Wejcie Problem z planem, ktry wymaga dziaania korygujcego. Zalecenia Komitetu Sterujcego Zapisy Obiektw Konfiguracji Wejcie Odpowied na prob o rad. Aktualizacja Uaktualnione zapisy w celu odnotowania udostpnienia nowych kopii produktw i wprowadzenia wszystkich wymaganych zmian statusu.

Rejestr Zagadnie Aktualizacja Zawiera szczegy dotyczce wszelkich Zagadnie Projektowych, ktre mogyby powodowa odchylenia od planu. Uaktualniany o zmiany statusu spowodowane przez dziaania korygujce. Rejestr Ryzyka Aktualizacja Zmiana zagro enia mo e wymaga dziaania korygujcego. Zagro enia opisane w rejestrze mog wpywa na wybr dziaania. Uaktualniany o wszelkie zmiany statusu spowodowane dziaaniami korygujcymi. Plan Etapu Wejcie Mo e ukaza problem lub szczupo nakadw pracy i czasu dostpnych do rozwizania problemu. Uaktualniany o wszystkie zmiany wywoane dziaaniami korygujcymi. Lista Kontrolna Produktw Wejcie Jeli jest stosowana, mo e ukaza problem lub szczupo nakadw pracy i czasu dostpnych do rozwizania problemu. Uaktualniana o wszystkie zmiany wywoane dziaaniami korygujcymi.

131

CONTROLLING A STAGE (CS)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie

Sygna do podjcia prac Wyjcie Dziaanie korygujce. Proba o rad Wyjcie Proba o rad w sprawie dziaania korygujcego.

7.10.6.

Kryteria oceny ci jako Czy rozwa ono wszystkie sensowne dziaania korygujce? Czy istnieje pewno, e po podjciu dziaania korygujcego, etap i projekt pozo- nadal stan w granicach tolerancji? Czy w peni rozwa ono wpyw na Uzasadnienie Biznesowe i zagr o enia? Czy Plan Etapu zosta tak uaktualniony, by odzwierciedla dziaania korygujce?

Wskazwki i rady
Nale y wystrzega si kumulacyjnego wpywu maych zmian na bud et i koszty. Nale y uwa a na kierunek, w jakim kilka maych zmian mo e poprowadzi projekt.

7.11.
7.11.1.

Przekazywanie Zagadnie
Podstawowe zasady

Projektowych (SE8)

Etap nie powinien wyj poza tolerancje uzgodnione z Komitetem Sterujcym. Kierownik Projektu powinien zawsze przedstawia swoj rekomendacj, przekazuje Zagadnienia Projektowe na wy szy szczebel zarzdzania.

kiedy

7.11.2.

Kontekst

Produkty wyjciowe tego podprocesu mog stanowi wyprzedzajce ostrze enie dla Komitetu Sterujcego o odchyleniu, ktre mo e prowadzi do stworzenia Planu Nadzwyczajnego. Kierownik Projektu mo e tylko wtedy samodzielnie podj dziaanie korygujce lub status , jeli przewiduje, e etap pozostanie w granicach utrzyma ustalonych quo tolerancji przez Komitet .Podproces Przekazywanie Pro Sterujcy (SE8) uruchamia si, gdy adne dziaanie korygujce nie uchronioby Zagadnie jektowyc h etapu lub projektu od wyjcia poza tolerancje. W odpowiedzi na przekazanie zagadnienia na wy szy szczebel, decyzja Komitetu Sterujcego mo e prowadzi do: usunicia problemu, opracowania Planu Nadzwyczajnego, si cele dotyczce kosztw i/lub terminw, zgody na Ustpstwo w ktrym zmieni lub do przedwczesnego zamknicia projektu.

1 32

PRINCE2

STEROWANIE ETAPEM (SE)

ZS4 Podejmowanie Decyzji Dora nych

Raport o Istotnych Odchyleniach Zagro enie przekroczenia tolerancji Sygna do Decyzja Komitetu Steruj cego

SE5 Przegl d Stanu Etapu

Ust pstwo

SE8 Przekazywanie Zagadnie Projektowych

przedwczesnego zamkni cia

ZP1 Przygotowanie Projektu do Zamkni cia

Uzasadnienie Biznesowe Plan Projektu Rejestr Ryzyka DIP Plan Etapu

Raport o Istotnych Odchyleniach Zapisy Obiektw Konfiguracji Rejestr Zagadnie

Pro ba o Plan Nadzwyczajny

ZE6 Opracowanie Planu Nadzwyczajnego

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 7.10. Projektowych

Przekazywanie

Zagadnie

7.11.3.

Opis procesu

Jednym z wa niejszych elementw sterowania, dostpnych Komitetowi Sterujcemu, jest ustalenie tolerancji dla ka dego etapu. (Tolerancje wyczerpujco opisano w Rozdziale 16 Elementy ). Kierownik Projektu posiada uprawnienia sterowania do kontynuowania etapu jedynie wtedy, kiedy przewiduje, e etap pozostanie w granicach Jeli przewiduje, e etap wyjdzie poza te granice (mo liwe, e w tolerancji. wyniku korygujcego), musi zwrci uwag Komitetu Sterujcego na t dziaania sytuacj. Jedn z prawdopodobnych przyczyn odchylenia jest Zagadnienie Projektowe. Zagad- Projektowe jest wyczerpujco opisane w Rozdziale nienie Sterowanie 20 e wystpi jedno lub wicej Zagadnie Projektowych, ktrych rozwizanie zmianami Mo mogoby spowodowa wyjcie etapu (i mo liwe, e caego projektu) poza uzgodnione tolerancje. Innymi przyczynami mog by: ze oszacowanie, zmiana w dostpnoci zasobw, zasoby mniej lub bardziej wydajne, nieplanowane zadania, zadania niepotrzebne oraz konieczno poprawiania wykonanej pracy. Komitet Sterujcy musi podj decyzje, wprowadzenie ktrych zmian (jeli w ogle jakich) mo e zatwierdzi.
17

17

Zalecanego przypis tumacza.

133

CONTROLLING A STAGE (CS) W celu utrzymania nastpujce kroki: skompletowa obj oddziaywanie biznes (w podprocesie pr zez Komitet Sterujcy cakowitej kontroli, nale y podj

PRINCE2

wyniki penej analizy wpywu odchylenia; analiza powinna na wykonawcw prac specjalistycznych, u ytkownikw i Analizowanie Projektowyc (SE4)); Zagadnie h zebra i oceni mo liwe sposoby naprawy lub wycignicia korzyci ze zdar ze pozytywnych (tak e w Analizowanie Projektowyc (SE4)); podprocesie Zagadnie h wybra rekomendowan opcj;

w Raporcie o Istotnych Odchyleniach przedstawi Ko mitetowi Sterujcemu sytuacj, mo liwe opcje i rekomendacj; zatwierdzi przez Komitet Sterujcy propozycj dziaania rekomendowanego przez Kierownika Projektu lub podj inn decyzj [w podpr Podejmowanie ocesie Decyzji nyc (ZS4)]; Dora h uaktualni informacje w Zapisach Obiektw Konfiguracji wszystkich produktw, bdzie miaa wpyw podjta na ktre decyzja. Sugerowan zawarto Raportu o Istotnych Odchyleniach przedstawiono w Dodatku A. W Raporcie o Istotnych Odchyleniach Kierownik Projektu powinien ostrzec Ko mitet Sterujcy o wpywie odchylenia na Plan Projektu, Uzasadnienie Biznesowe oraz na za- enia. Komitetowi Sterujcemu powinny by przedstawione r ne mo liwoci gro postpowania i rekomendacja dalszego kierunku dziaania. Komitet Sterujcy, po rozpatrzeniu (w podprocesie Raportu o Istotnych Odchyleniach, zatwierdzi ten ZS4) raport i zawiadomi Kierownika Projektu o swojej decyzji. Mo e to by proba o przygotowanie Planu Nadzwyczajnego, ktry zastpi plan wymagajcy korekty - zwykle pozosta do wykonania cz bie cego Planu Etapu. Plan Nadzwyczajny, przygotowywany w podprocesie Opracowanie Planu (ZE6), albo doprowadzi do Nadzwyczajnego naprawy sytuacji powodujcej przekroczenie tolerancji, albo zaproponuje zupenie nowe podejcie - z nowymi, waciwymi dla zaistniaej sytuacji ustaleniami, dotyczcymi kosz- czasu, zakresu, korzyci, ryzyka i jakoci, a ponadto z nowymi tolerancjami tw, dla celw. Przed rozpoczciem opracowania Planu Nadzwyczajnego nale y tych zwrci si do Komitetu Sterujcego z prob o rad. We wsppracy z Komitetem Sterujcym nale y przeanalizowa wszelkie bie ce ograniczenia, aby stwierdzi, czy w nowej sytuacji s one nadal aktualne. Inn opcj, ktra wchodzi w gr jako alternatywa dla Planu Nadzwyczajnego, jest usu- problemu (np. odo enie Wniosku o Wprowadzenie nicie . Komitet Zmiany) zdecydowa, by wyrazi zgod na Ustpstwo i kontynuowa prace z Sterujcy mo e te dotychczasowym planem. W takim przypadku odpowiednie dziaania korygujce powinny zosta uruchomione za pomoc Przeg d Stanu (SE5) . Ostateczna podprocesu drastyczna decyzja polegaaby na przedwczesnym zamkniciu l Etapu i bardziej projektu. przypadku Kierownik Projektu powinien uruchomi W tym Przygotowani podproces e Projektu do ci (ZP1). Zamkni a Czciami planu, ktre mog ulec zmianie w reakcji na mo liwo wystpienia istot- odchyle, s: nych koszty; data dostawy;

1 34

PRINCE2 zakres; jako; korzyci;

STEROWANIE ETAPEM (SE)

poziom akceptowanego ryzyka. Szybko jest wa nym czynnikiem w powiadamianiu Komitetu Sterujcego o mo liwoci wystpienia istotnych odchyle. Czsto konieczne bdzie skorygowanie Planu Projektu, co wyjaniono w opisie podprocesu Uaktualnienie Planu (ZE2). Projektu

7.11.4.

Odpowiedzialno

Kierownik Projektu jest odpowiedzialny za przekazywanie Zagadnie Projektowych na szy szczebel zarzdzania. Osoby penice obowizki Nadzoru Projektu wy powinny tak e monitorowa wszelkie sytuacje, ktre mogyby spowodowa odchylenie, oraz powinny na tak spraw zwrci uwag Kierownika Projektu. Bibliotekarz Konfiguracjikoniecznoci powinien uaktualni Zapisy Obiektw w razie Konfiguracji.

7.11.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Sygna wyzwalajcy dla Raportu o Istotnych Odchyleniach. Wejcie Jako obiekt odniesienia pozwala na porwnanie wszelkich zmian z pierwotnymi oczekiwaniami. Wejcie Ostatnia jego wersja pozwala na zbadanie wpywu Zagadnienia Projektowego na Uzasadnienie Biznesowe.

Tabela 7.8. SE8 Informacja Objanienie

Zagro enie przekroczeniem tolerancji Dokument Inicjujcy Projekt Uzasadnienie Biznesowe

Plan Etapu Wejcie Uaktualniony danymi o faktycznym wykonaniu, pokazuje prawdopodobny wpyw rozwa anego odchylenia na etap. Plan Projektu Wejcie Pokazuje stan projektu oraz caociowy efekt jakiegokolwiek odchylenia. Rejestr Zagadnie Wejcie/ aktualizacja Szczegy zmian, ktre mogy spowodowa zagro enie wystpieniem istotnego odchylenia. Po otrzymaniu decyzji Komitetu Sterujcego, nale y zaktualizowa Rejestr Zagadnie o bie cy status.

Rejestr Ryzyka Wejcie Szczegy nara enia na ryzyko, ktre mogo spowodowa przekazanie Zagadnienia Projektowego.

135

CONTROLLING A STAGE (CS)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie
Wejcie/Wyjcie Przeznaczony dla Komitetu Sterujcego opis sytuacji wymagajcej naprawy, jej wpywu, mo liwych dziaa, rekomendacji oraz wpywu rekomendowanego dziaania. Po zatwierdzeniu Raportu o Istotnych Odchyleniach przez Komitet Sterujcy, powinien by zarchiwizowany na potrzeby audytu. Wejcie Mo e to by (zale nie od rodzaju decyzji) proba o Plan Nadzwyczajny, przedwczesne zamknicie projektu, odroczenie proponowanej zmiany lub zgoda na Ustpstwo. Wyjcie Wynik decyzji Komitetu Sterujcego o przedwczesnym zamkniciu projektu Wyjcie Wynik decyzji Komitetu Sterujcego o skierowaniu proby o Plan Nadzwyczajny.

Raport o Istotnych Odchyleniach

Decyzja Komitetu Sterujcego

Sygna do przedwczesnego zamknicia Proba o Plan Nadzwyczajny

Ustpstwo Wyjcie Wynik decyzji Komitetu Sterujcego o zgodzie na zmian ustalonych kryteriw. Zapisy Obiektw Konfiguracji Aktualizacja Takie pozycje jak status mog by uaktualnione oraz dodane odniesienia do odpowiedniego Zagadnienia Projektowego.

7.11.6.

Kryteria oceny ci jako Czy rozpatrzenie Zagadnienia Projektowego le y w kompetencjach zespou zarz- projektem? Jeli nie, to czy zostay udzielone wytyczne, co z nim robi dzania dalej? Czy przewidywane wyniki etapu wychodz poza gr anice tolerancji? Czy w granicach uprawnie Kierownika Projektu istnieje jaka mo liwo powrotu parametrw etapu do obszaru tolerancji bez redukcji jakoci lub zakresu projektu? Czy zostay rozwa one konsekwencje dla Uzasadnienia Biznesowego i zagro e? Czy rozwa ono wszystkie sensowne alternatywy dziaa? Czy zarekomendowano dalszy przebieg dziaa do rozwa enia przez Komitet Sterujcy? Czy skalkulowano wpyw na Plan Projektu?

Wskazwki i rady
Zatwierdzenie Zagadnie Projektowych, w zwizku z ktrymi nale y wykona pewne prace w bie cym etapie, mo e by czynnikiem, ktry wyprowadzi etap poza tolerancje. Komitetowi Sterujcemu nale y uwiadomi tak mo liwo, gdy rozwa a si zgoszone Zagadnienia Projektowe.

1 36

PRINCE2

STEROWANIE ETAPEM (SE)

Potencjalne odchylenia powinny by przewidywane z tak du ym wyprzedzeniem, jak to tylko jest mo liwe, lecz bez podnoszenia faszywych alarmw. Od Kierownika Projektu oczekuje si, e bdzie wpierw prbowa opanowa wszelkie takie sytuacje. Poprzednie Raporty Okresowe mogy by sygnaami ostrzegawczymi o tym, e etap mo e przekroczy swoje granice tolerancji. Jedn z opcji dostpnych Komitetowi Sterujcemu w odpowiedzi na przewidywanie istotnego odchylenia jest wstrzymanie projektu. Jedn z przyczyn istotnego odchylenia mo e by wycofanie si dostawcy z biznesu.

Konieczne jest przeprowadzenie analizy wpywu poszczeglnych opcji przeciwdziaania przewidywanemu odchyleniu. Nale y si stara pozna opini u ytkownika na temat wpywu odchylenia i poszczeglnych opcji na spoeczno u ytkownikw. Nale y si stara pozna opini dostawcy na temat wpywu odchylenia i poszczeglnych opcji na dostawcw. Analiza wpywu na biznes powinna obejmowa Plan Projektu, Uzasadnienie Biznesowe oraz zagro enia. Komitet Sterujcy mo e podj decyzj akceptujc Odstpstwo bez dziaania naprawczego, zmieniajc Odstpstwo w Ustpstwo. Podczas gdy Komitet Sterujcy rozwa a Raport o Istotnych Odchyleniach, Kierownik Projektu musi zdecydowa, w jaki sposb prowadzi dalej etap - jeli jest to mo liwe. Czy s jakie prace, ktre nie bd zmarnowane, niezale nie od tego, jaka byaby decyzja Komitetu Sterujcego? Czy nale y wstrzyma cz, czy te cao prac? Nale y bra pod uwag znaczenie szybkoci powiadomienia Komitetu Sterujcego. Podproces ten mo e by zrealizowany w trzech fazach: krtka informacja, nastpnie informacje dodatkowe, a po nich planowanie zwizane z przewidywanym istotnym odchyleniem.

7.12.
7.12.1.

Odbir Wykonanej Grupy Zada

Podstawowe zasady

(SE9)

Jeli prace zostay przydzielone indywidualnym osobom lub zespoom, musi istnie dopasowane do tego potwierdzenie, e zostay one zakoczone i zaakceptowane.

7.12.2.

Kontekst

W tym podprocesie rejestruje si pomylne zakoczenie i zwrot Grup Zada z podprocesu Oddanie Wykonanej Grupy (WP3). Ta informacja jest nastpnie Zada przekazywana do procesu Ocena pw (SE2). Post

137

CONTROLLING A STAGE (CS)

PRINCE2

Grupa Zada

Dokumentacja Dokumentacja zarz dcza zarz dcza

WP3 Oddanie Wykonanej Grupy Zada

Zapi sy Obiektw Konfiguracji

Rejestr Jako ci

Zatwierdzona Grupa Zada

SE9 Odbir Wykonanej Grupy Zada

Status Grupy Zada

SE2 Ocena Post pw

Rysunek 7.11. Odbir Wykonanej Grupy Zada

7.12.3.

Opis procesu

Istnieje potrzeba potwierdzenia, e Grupa Zada zostaa zadowalajco wykonana. to sprawdzenie, Obejmuje czy: odbiorca produktw zaakceptowa je; wpisy do Rejestru Jakoci s kompletne; odpowiednie zapisy zostay umieszczone w dokumentacji jakoci; produkty zostay przekazane do zarzdzania konfiguracj. Sprawdza si, czy przeprowadzono wszelkie kontrole okrelone jako cz Kryteriw Akceptacji, upewniajc si, e produkty s prawidowe. Zapisy Obiektw Konfiguracji s uaktualniane w celu zmiany statusu na wykonany. Zakoczony i zaakceptowany uznany za obiekt odniesienia (jeli ju tego nie zrobiono w trakcie produkt zostaje podprocesu SE2 w wyniku informacji uzyskanej z Wykonywanie Grupy podprocesu Zada (WP2), gdy produkt przeszed pozytywnie przegld jakoci - dzieje si tak najczciej Grupa Zada zawiera wiele produktw). Jakiekolwiek nastpne zmiany wtedy, gdy produktu musz przej przez procedur sterowania zmianami, ktra jest czci stosowa- metody nej zarzdzania konfiguracj.

7.12.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik wspomagany przez wyznaczoProjektu, ny personel Wsparcia Projektu. Informacji powinien dostarczy Czonek zespou lub Kierownik Zespou odpowiedzialny za wykonanie Gr upy Zada. Bibliotekarz Konfiguracji powinien uaktualni wszystkie waciwe Zapisy Obiektw Konfiguracji.

1 38

PRINCE2

STEROWANIE ETAPEM (SE) Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

7.12.5.

Tabela 7.9. SE9 Informacja Objanienie

Grupa Zada Zatwierdzenie Stwierdzenie przez Kierownika Projektu e Grupa Zada jest kompletna i mo liwa do zaakceptowania. Rejestr Jakoci Wejcie Potwierdzenie kontroli jakoci zakoczonych pozytywnym wynikiem. Zapisy Obiektw Konfiguracji Aktualizacja Zmiana statusu produktu.

Status Grupy Zada Wyjcie Do uaktualnienia Planu Etapu.

7.12.6.

Kryt eria oceny ci jako Czy wszystkie osoby lub zespoy, ktrych praca polega na wykorzystywaniu lub stykaniu si z zakoczon Grup Zada, s zadowolone z produktu(w)? Czy osoby zatwierdzajce produkty s wystarczajco niezale ne od wytwrcw?

Wskazwki i rady
Istnieje cisy zwizek midzy wymaganiami, dla informacji zarzdczej tego podprocesu, a technicznymi wymaganiami jakiejkolwiek metody zarzdzania konfiguracj, wykorzystywanej do odbioru i rejestrowania danych dotyczcych zakoczenia wytwarzania. Metoda zarzdzania konfiguracj przejmie tak e obowizki zwizane z produktem Grupy Zada i bdzie odpowiada za jego przechowywanie patrz Rozdzia 19 Zarzdzanie konfiguracj.

139

8.
Uzgodnienie prac z Kierownikiem Projektu

ZA RZ DZA NI E W YTWA RZAN I EM P ROD UK T W (WP ) (MANAGING PRODUCT DELIVERY - MP)

Zaplanowanie pracy zespou

Nadzorowanie pracy zespou

Raportowanie o jako ci i post pach

Uzyskanie zatwierdzenia uko czonych produktw

Rysunek 8.1. Produktw

Zarys procesu Zarzdzanie Wytwarzaniem

8.1.

Podstawowe zasady

Zar dzanie Wytwarzaniem (WP) umo liwia kontrolowane oddzielenie z Produktw Kierownika Projektu od Kierownika Zespou bd te Kierownika Projektu od wytwarzania/dostawy produktw przez dostawcw, bdcych stron Proces ten wymaga trzeci. nego wdro enia, by unikn nadmiernego rozwa formalizmu.

8.2.

Kontekst

Proces wsppracuje z Sterowanie (SE) oraz mo e wykorzystywa procesem Etapem proces Planowani (PL) do stworzenia Planw Zespow. Strona trzecia mo e nie e stoso14 1

MANAGING A PRODUCT DELIVERY (MP) wa PRINCE2 i dlatego omawiany podproces ustanawia wymagane punkty midzy Kierownikiem Zespou 18 a metodyk PRINCE2, wykorzystywan w projekcie. styku

PRINCE2

W projektach, ktre realizuje tylko jeden zesp, podporzdkowany bezporednio Kierownikowi Projektu, ten czonek zespou, ktry ma wykona prac, bdzie uzgadnia szczegy z Kierownikiem Zasady omawianego procesu bd obowizyway Projektu. nadal, lecz bd stosowane w sposb mniej formalny.
WP WP1 Przyjmowanie Grupy Zada do Wykonania Zarz dzanie Wytwarzaniem Produktw WP2 Wykonywanie Grupy Zada WP3 Oddanie Wykonanej Grupy Zada

PL Planowanie

SE1 Zgoda na Wykonanie Grupy Zada

SE2 Ocena Post pw

SE9 Odbir Wykonanej Grupy Zada

Rysunek 8.2. Produktw

Zarzdzanie

Wytwarzaniem

8.3.

Opis procesu

Proces ma na celu pozwoli Kierownikowi Zespou: uzgodni prac z Kierownikiem Projektu; wykona j; przekaza wykonan prac Kierownikowi Projektu. Uzgodnienie dotyczce wykonania zdefiniowanej pracy jest dzielone na Grupy Zada. zatrudniani s dostawcy zewntrzni, akceptacja Grup Zada bdzie zale na od Jeli warunkw zawartego z nimi kontraktu. Kierownik Zespou zapewnia, eby planowane produkty zostay wytworzone oraz dostarczone przez zesp, poprzez: przyjmowanie i sprawdzanie Grup Zada, na wykonanie ktrych uzyska zgod Kierownika Projektu; zapewnienie, e przydzielone zespoowi prace zwizane z produktami s uzgodnione i realizowane po uzyskaniu na to zgody; zagwarantowanie, e prace bd uwzgldniay wszelkie punkty styku okrelone w Grupie Zada;

18

Ktry mo e stosowa metodyk waciw dla wytwarzania produktu specjalistycznego przypis tumacza.

14 2

PRINCE2 ZARZDZANIE WYTWARZANIEM PRODUKTW (WP) przygotowanie lub zweryfikowanie Planu Zespou dla tych prac; zapewnienie, e prace zostan wykonane; zapewnienie, e postpy prac oraz kontrole jakoci i prognozy s regularnie oceniane; zapewnienie, e wykonane produkty speniaj okrelone dla nich kryteria jakoci; uzyskanie zatwierdzania dla wykonanych produktw. Skalowalno

8.3.1.

Dla maych projektw lub realizowanych przez jeden zesp bezporednio podlegajcy Kierownikowi Projektu, poczenie pomidzy tym procesem a Sterowanie procesem bdzie Etapem (SE) znacznie mniej sformalizowane. Prace wykonywane w trakcie tego procesu mo na podsumowa nastpujco: negocjowanie pracy do wykonania; zaplanowanie jej; nadzorowanie jej wykonywania; ledzenie postpw; raportowanie postpw; sprawdzenie produktw; zarejestrowanie wynikw kontroli jakoci; sterowanie zmianami; uzyskanie zatwierdzenia produktw; przekazanie Kierownikowi Projektu wykonanej Grupy Zada.

8.4.
8.4.1.

Przyjmowanie Grupy Zada

Podstawowe zasady

do Wykonania (WP1)

Podstawow zasad przedstawianego podprocesu jest to, e zanim Grupa Zada zostanie przydzielona zespoowi, nale y uzgodni z Kierownikiem Projektu: co ma by dostarczone; jakie ograniczenia obowizuj; wszelkie punkty styku, o ktrych powinien wiedzie zesp; czy wymagania postawione w Grupie Zada s uzasadnione i czy mog zosta spenione.

8.4.2.

Kontekst a

Podproces jest zarzdczym punktem styku midzy Kierownikiem Zespou Kierownikiem Projektu, wykorzystywanym do przekazania zespoowi pracy do wykonania. 143

MANAGING A PRODUCT DELIVERY (MP)

PRINCE2 na

Dla Kierownika Zespou jest to podproces przeciwlegy do Zgoda podprocesu Grupy (SE1). Podczas trwania projektu te dwa podpr ocesy wystpi Wykonanie Zada wiele razy.

SE1 Zgoda na Wykonanie Grupy Zada

Grupa Zada

WP1 Przyjmowanie Grupy Z ada do Wykonania

Plan Zespou Rejestr Ryzyka Rejestr Jako ci

Dokumentacja Dokumentacja zarz dcza zarz dcza

Uzgodniona Grupa Zada

PL Planowanie

WP2 Wykonywanie Grupy Zada

Rysunek 8.3. Przyjmowanie Grupy Zada do Wykonania

8.4.3.

Opis procesu

Sugerowana zawarto Grupy Zada jest przedstawiona w Dodatku A Zarysy Opisw Produkt . w Kierownik Zespou musi uzgodni Grup Zada z Kierownikiem Projektu. W tym celu y podj nastpujce nale kroki: zawrze jednoznaczne porozumienie z Kierownikiem Projektu, ustalajce co ma by dostarczone ; negocjowa w imieniu zespou z Kierownikiem Projektu ograniczenia, w ramach ktrych prace maj by wykonane; uzgodni tolerancje dla Grupy Zada; zrozumie wymagania dotyczce raportowania; zrozumie, jak i od kogo nale y uzyska zatwierdzenie produktw; zrozumie, w jaki sposb zatwierdzone produkty maj by formalnie przekazane; potwierdzi, w jaki sposb nale y poinformowa Kierownika Projektu o wykonaniu Grupy Zada; wytworzy lub poprawi Plan Zespou, by wykaza, e Grupa Zada mo e by zrealizowana w ramach uzgodnionych ogranicze. Stosowany powszechnie Pla proces nowani (PL), bdzie wykorzystany do modyfikowania lub przygotowania e Zespow; Planw przeprowadzi analiz zagro e, planowanie i przydzielenie zasobw.

14 4

PRINCE2 ZARZDZANIE WYTWARZANIEM PRODUKTW (WP) wprowadzi wszelkie konieczne aktualizacje Rejestru Jakoci - np. okrelenie dodatkowych testerw w wyniku rozmw z Nadzorem Projektu. Grupa Zada powinna zawiera Opis(-y) Produktu(dla wymaganych produktw, w) zawierajce kryteria Plan Etapu i Plan Zespou powinny pokazywa uzgodnione jakoci. ograniczenia, takie jak czas i pracochonno.

8.4.4.

Odpowiedzialno

Kierownik Zespou jest odpowiedzialny za dokonanie uzgodnie z Kierownikiem Projektu. Nadzr Projektu mo e domaga si potwierdzenia, e w Planach Zespow zostay uwzgldnione odpowiednie rozwizania dotyczce kontroli jakoci i personel do ich realizacji .

8.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 8.1. WP1 Informacja Objanienie

Grupa Zada Wejcie Pakiet zo ony przez Kierownika Projektu w podprocesie Zgoda na Wykonanie Grupy Zada (SE1) do uzgodnienia z Kierownikiem Zespou. Mo e by skorygowany w trakcie uzgadniania. Plan Zespou Wyjcie/ Aktualizacja Tworzony jest Plan Zespou albo dodawane s szczegy Grupy Zada do istniejcego ju Planu Zespou.

Rejestr Ryzyka Aktualizacja Kierownik Zespou dodaje do Rejestru Ryzyka wszystkie zagro enia zidentyfikowane w Planie Zespou. Rejestr Jakoci Aktualizacja Uzupeniany o wszelkie dodatkowe informacje dotyczce kontroli jakoci. Uzgodniona Grupa Zada Wyjcie Grupa Zada zaakceptowana przez Kierownika Zespou.

8.4.6.

Kryt eria oceny ci jako Czy odbyy si pene konsultacje w sprawie Grupy Zada midzy Kierownikiema Projektu Kierownikiem Zespou? Czy uwzgldniono czas i koszt prac zwizanych z kontrol jakoci oraz wszelkimi poprawkami, ktre mog by potrzebne? Czy wymagania dotyczce raportowania s uzasadnione? Czy wszelkie wymagania dotyczce punktw styku s mo liwe do spenienia w ramach ogranicze? Czy wszystkie powizania z metod zarzdzania konfiguracj w projekcie s znane zgodne ze sposobem, w jaki produkty bd kontrolowane w oraz zespole? 145

MANAGING A PRODUCT DELIVERY (MP)

PRINCE2

Czy znane s wszystkie wymagane punkty styku z Nadzorem Projektu i czy ustano- punkty wiono styku z zespoem? Czy zidentyfikowano jakie zagro enia oraz sposoby zarzdzania nimi? Jaka jest dostpno zasobw w okresie obejmowanym przez Grup Zada? Jakich kwalifikacji i dowiadczenia wymagaj elementy Grupy Zada? Czy wyznaczona osoba lub zesp zgadzaj si na przydzielone prace? Czy istnieje odpowiedni opis wymaganej jakoci? Czy okrelono wszystkie standardy i techniki, ktre maj by stosowane?

Wskazwki i rady
Jeli w projekcie nie ma Kierownikw Zespow, a Kierownik Projektu przekazuje prace bezporednio czonkom zespou, osoby te mog stosowa ten proces nieformalnie. W maych projektach mo e to by jedynie udokumentowane w Dzienniku. Ten podproces jest dopasowany do podprocesu Zgoda na Wykonanie Grupy Zada (SE1), obydwa powinny by realizowane razem.

8.5.
8.5.1.

Wykonywanie Grupy Zada

Podstawowe zasady

(WP2)

Podstawowe zasady tego podprocesu to: bez wzgldu na rodzaj projektu, zadanie wytworzenia wymaganych pr oduktw musizarzdzane; by podobnie jak praca, Kierownikowi Zespou delegowane jest tak e ledzenie jej przebiegu. Kontekst

8.5.2.

Podproces ten mo e wystpowa na poziomie, ktry nie stosuje PRINCE2, np. kiedy za- owana jest trzecia strona, niestosujca PRINCE2. Dlatego nie istnieje adna anga definicja specyficznych standardw lub procedur, ktre maj by stosowane, lecz tylko sformu- co musi zosta wykonane w celu powizania Kierownika Zespou z owanie, projektem.

14 6

PRINCE2 ZARZDZANIE WYTWARZANIEM PRODUKTW (WP)

WP1 Przyjmowanie Grupy Zada do Wykonania

Uzgodniona Grupa Zada

Raport z Punktu Kontrolnego

SE2 Ocena Post pw

WP2 Wykonywanie Grupy Zada

Dokumentacja Dokumentacja zarz dcza zarz dcza

Plan Zespou Rejestr Jako

ci

Wykonana Grupa Zada

WP3 Oddanie Wykonanej Grupy Zada

Rysunek 8.4. Wykonywanie Grupy Zada

8.5.3.

Opis procesu

Prace w ramach Grupy Zada, ktra posiada zgod na realizacj, musz by monitor owane z dokadnoci potrzebn do zapewnienia Kierownikowi Projektu zwrotnej info rmacji, tak jak to zdefiniowano w uzgodnionej Grupie Zada. Nale y podj wic niezbdne kroki: zarzdza wytwarzaniem wymaganych produktw/usug; wychwyci i zarejestrowa zu yte nakady pracy; okreli status ka dego produktu w Grupie Zada; monitorowa i sterowa zagro eniami, zwizanymi z Grup Zada; oceni wsplnie z wytwrc(-ami) ilo pracy pozostajcej nadal do wykonania; przekazywa Kierownikowi Projektu zwrotn informacj o postpach i statusie w Raportach z Punktw Kontrolnych, w sposb i z czstotliwoci okrelon w Grupie Zada;

zapewni, e wymagane procedury sprawdzenia jakoci s realizowane oraz e pr odukt(-y) spenia(-j) standardy jakoci okrelone w Grupie Zada; uaktualni Rejestr Jakoci szczegami, wynikajcymi ze wszystkich przeprowadzo-kontroli nych jakoci; powiadamia Kierownika Projektu o wszelkich problemach, ktre mog wpyn na uzgodnione dla Grupy Zada wartoci tolerancji (formalnie dokonuje si tego zgaszajc Zagadnienie Projektowe). Dla Kierownika Zespou u yteczne jest wykorzystywanie Dziennika, tak jak to opisano w Rozdziale 16 Elementy . Mo e on by wykor zystany do przypomnienia sterowania Kierownikowi Zespou o kontrolach jakoci, ktrych jeszcze nie przeprowadzono, lub o tych, ktre wykazay zbyt du o bdw lub bdw, ktrych usuwanie trwa zbyt dugo . Planowane zadania znajdujce si na cie ce krytycznej, ktre powinny si rozpocz lub

147

MANAGING A PRODUCT DELIVERY (MP) zakoczy, mog tak e Kierownikowi sprawdzaniu, Zespou o prawidowo. by czy wpisywane do Dziennika, wszystko przebiega Nadzr Projektu lub jego by

PRINCE2 przypomnie

8.5.4.

Odpowiedzialno

Za podproces reprezentanci wezm udzia jakoci.

odpowiada Kierownik Zespou. w wikszoci kontroli

8.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Prace uzgodnione z Kierownikiem Projektu.

Tabela 8.2. WP2 Informacja Objanienie

Uzgodniona Grupa Zada

Plan Zespou Aktualizacja Zapis przydziau zasobw, planowanej i faktycznej pracochonnoci oraz wszelkich potrzebnych modyfikacji, s wykorzystywane do uaktualniania Planu Zespou. Rejestr Jakoci Aktualizacja Szczegy kontroli produktu przeprowadzonych w celu potwierdzenia zgodnoci ze standardami jakoci s dodawane do Rejestru Jakoci. Raporty z Punktw Kontrolnych Wykonana Grupa Zada Wyjcie Raporty o postpach dla Kierownika Projektu z czstotliwoci okrelon w Grupie Zada. Wyjcie Wykonana Grupa Zada.

8.5.6.

Kryteria oceny ci jako Czy praca jest podzielona na wystarczajco mae czci w celu uatwienia wymaganego poziomu kontroli? W jaki sposb bd monitorowane postpy? W jaki sposb bdzie sprawdzany finalny(e) produkt(y)? Czy Plan Zespou zawiera prace zwizane z kontrolowaniem jakoci? Czy istniej pr ocedury rejestrowania i raportowania postpw czonkw zespou na poziomie zgodny m z wymaganiami projektu dotyczcymi raportowania? Czy praca jest wykonywana zgodnie z wymaganiami i ograniczeniami Grupy Zada? Czy postpy s rejestrowane i raportowane z wystarczajc szczegowoci, by mo liwi wczesne ostrzeganie o wszelkich zagro eniach dla u tolerancji? Czy kontrole jakoci zostay przeprowadzone w penym zakresie?

14 8

PRINCE2 ZARZDZANIE WYTWARZANIEM PRODUKTW (WP) Wskazwki i rady

Kierownik Zespou mo e mie potrzeb wczenia dodatkowych informacji do Grupy Zada w celu wskazania metod kontroli wersji lub zarzdzania konfiguracj, ktre zesp ma zastosowa. Musz by wdro one w ycie procedury informowania Kierownika Projektu o aktualnych postpach. Nawet jeli zesp nie stosuje PRINCE2, musi dostarczy Kierownikowi Projektu wymaganych informacji w formacie ustalonym w Grupie Zada. Dlatego byoby sensowne posiada procedury rejestrowania i raportowania, ktre pasuj do tych, stosowanych w projekcie (lub nawet stosowa odpowiednie raporty PRINCE2) .

8.6.
8.6.1.

Oddanie Wykonanej Grupy Zada

Podstawowe zasady

(WP3)

Tak jak Grupa Zada zostaa przyjta do wykonania od Kierownika Projektu, tak powiadomienie o jej zakoczeniu musi wrci do Kierownika Projektu.

8.6.2.

Kontekst

Stosowany w projekcie system zarzdzania konfiguracj mo e obsugiwa oddawanie rzeczywistych produktw Grupy Zada. Istot tego podprocesu jest, e Kierownik Zespo- zapewni, i produkty zostay przekazane prawidowo, oraz zawiadomi u musi Kierownika Projektu, e przekazanie faktycznie nastpio. Ten podproces mo e wyzwoli podproces Zgoda na Wykonanie Grupy (SE1) dla Zada nastpnej Grupy Zada lub mo e czciowo na niego zachodzi.
WP2 Wykonywanie Grupy Zada
Wykonana Grupa Zada

WP3 Oddanie Wykonanej Grupy Zada

Grupa Zada

SE9 Odbir Wykonanej Grupy Zada

Rejestr Jako

ci

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 8.5. Oddanie Wykonanej Grupy Zada

149

MANAGING A PRODUCT DELIVERY (MP)

PRINCE2

8.6.3.

Opis procesu

Podproces skada si z trzech elementw: uzyskanie akceptacji dla wytworzonych produktw; przekazanie wykonanych produktw; powiadomienie Kierownika Projektu o zakoczeniu Grupy Zada. Metoda realizacji wymienionych wy ej elementw powinna by okrelona jako cz na wykonanie Grupy Zada. zgody Akceptacja powinna pochodzi z dwch rde: od osoby lub grupy ustalonej jako odbiorca oraz od Bibliotekarza Konfiguracji. Przed powiadomieniem Kierownika Projektu o wykonaniu, Kierownik Zespou powinien skontrolowa, czy wpisy do Rejestru Jakoci dotyczce produktu (-w) s kompletne.

8.6.4.

Odpowiedzialno odpowiada

Zespou, w powizaniu z Bibliotekarzem

Za podproces Konfiguracji .

Kierownik

8.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Uzgodnione z Kierownikiem Projektu szczegy prac zaktualizowane w oparciu o rzeczywiste dane.

Tabela 8.3. WP3 Informacja Objanienie

Wykonana Grupa Zada

Rejestr Jakoci Wejcie Potwierdzenie zakoczonych sukcesem kontroli jakoci. Grupa Zada Wyjcie Grupa Zada gotowa do zatwierdzenia przez Kierownika Projektu.

8.6.6.

Kryteria oceny ci jako Czy wskazany odbiorca zaakceptowa produkt(y)? Czy przekazanie zostao zakoczone z uwzgldnieniem wszystkich aspektw zarzdzania konfiguracj? Czy wszelkie uzgodnione dane statystyczne s dostpne dla Kierownika Projektu, aby zapisa je w Planie Etapu? Czy wydarzyo si cokolwiek podczas wykonywania Grupy Zada, co byoby warte dodania do Rejestru Dowiadcze?

15 0

PRINCE2 ZARZDZANIE WYTWARZANIEM PRODUKTW (WP) Wskazwki i rady

Jeli Grupa Zada zawiera pewn liczb produktw do wytworzenia, mog one by przekazywane do systemu zarzdzania konfiguracj projektu w miar, jak s zatwierdzane. Mo e to pocign za sob powstanie pewnego przedziau czasu, zanim Kierownik Projektu zostanie zawiadomiony, e caa Grupa Zada zostaa zakoczona. Poziom wymaganego sformalizowania bdzie r ny w zale noci od projektu: formalny, gdy zaanga owane s strony trzecie, nieformalny, gdy Kierownik Projektu zarzdza pracami bezporednio.

151

9.

ZA RZ DZA NI E ZA KR ES E M E TA PU (ZE )
(MANAGING STAGE BOUNDARIES - SB)

Kompletowanie informacji o wykonaniu bie cego etapu

Planowanie nast pnego etapu (albo opracowanie Planu Nadzwyczajnego) i uaktualnienie Planu Projektu

Sprawdzenie, czy zmieniy si Uzasadnienie Biznesowe lub zagro enia

Przygotowanie raportu dla Komitetu Steruj cego

Rysunek 9.1. Etapu

Zarys procesu Zarzdzanie Zakresem

9.1.

Podstawowe zasady

Projekty zarwno du e jak i mae, musz by skoncentrowane na dostarczaniu korzyci biznesowej albo samodzielnie, albo jako cz wikszego programu. Utrzymywanie prawidowej koncentracji projektu powinno by potwierdzane na kocu ka dego etapu. Jeli to konieczne, projekt mo e by inaczej ukierunkowany lub wstrzymany dla jest uniknicia marnowania czasu i pienidzy.

9.2.

Kontekst

Przed kocem ka dego etapu, z wyjtkiem ostatniego, planowany jest nastpny etap wraz z przegldem i uaktualnieniem Uzasadnienia Biznesowego, stanu ryzyka i caego Planu Projektu. Ten podproces, zwykle wywoywany z podprocesu Przeg d Stanu (SE5), l rzystuje Planowani (PL) do opracowania Planu Etapu Etapu lub proces e Nadzwyczajnego, a jego rezultaty uruchamiaj podproces (nastpnego) Komitetu Sterujcego lenie na Planu lub Planu (ZS3). Realizacj Etapu Nadzwyczajnego wykoPlanu Zezwo -

15 3

MANAGING STAGE BOUNDARIES (SB) Kroki tego procesu bd rwnie Nadzwyczajnego.

ZE IP6 Zestawienie Dokumentu Inicjuj cego Projekt

PRINCE2

wykorzystywane podczas opracowywania Planu

Zarz

dzanie Zakresem Etapu ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

ZE5 Raportowanie Ko ca Etapu

SE5 Przegl d Stanu Etapu

ZE1 Planowanie Etapu

ZE2 Uaktualnienie Planu Projektu

ZE3 Uaktualnienie Uzasadnienia Biznesowego

ZS2 Zezwolenie na Realizacj Projektu

SE8 Przekazywanie Zagadnie Projektowych

ZE6 Opracowanie Planu Nadzwyczajnego

ZE4 Uaktualnienie Rejestru Ryzyka

PL Planowanie

Rysunek 9.2 Etapu

Zarzdzanie Zakresem

9.3.

Opis procesu

Proces ma na celu: zapewnienie Komitetu Sterujcego, e wszystkie produkty wykazane w Planie Etapu cego) zostay wytworzone tak, jak zostay (bie zdefiniowane; przygotowanie Planu Etapu (nastpnego); dostarczenie informacji potrzebnej Komitetowi Sterujcemu do oceny dalszej zasadnoci projektu; uzyskanie zezwolenia na rozpoczcie nastpnego etapu wraz z ustaleniem dla niego tolerancji ; zarejestrowanie informacji lub dowiadcze, ktre mog pomc w pniejszych etapach tego projektu i/lub innych projektach. Mo e doj do zmian wr d pracownikw lub kierownictwa, wy magajcych modyfikacji zespou zarzdzania projektem.

15 4

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

Wymagane jest rwnie poddanie przegldowi Planu Jakoci Projektu oraz Formuy Realizacji Projektu dla sprawdzenia, czy wy magaj one zmian lub udoskonalenia. Etap nastpujcy po inicjowaniu jest zwykle zatwier dzany do realizacji w tym samym co Dokument Inicjujcy czasie, Jeli tak, to ten proces wymaga dostosowania Projekt. do takiej sytuacji.

9.3.1.

Skalowalno

Jak wynika z powy szej listy, proces ma prosty cel i mo e by zrealizowany na tyle nieformalnie, na ile Komitet Sterujcy i Kierownik Projektu Rapor towanie uzgodni. mog by nieformalne, jeli Komitet Sterujcy wyrazi na to zgod. Zaleca zatwierdzanie si jednak, aby dokumentowa wa niejsze decyzje, nawet jeli byby to tylko zapis w Dzienniku Kierownika Projektu. Chodzi o: zebranie wynikw aktualnego etapu; zaplanowanie nastpnego etapu; sprawdzenie wpywu na: Plan Projektu; uzasadnienie projektu; zagro enia; raportowanie i zatwierdzenie. dla wystpienie o

9.4.
9.4.1.

Planowanie Etapu (ZE1)

Podstawowe zasady

Planowanie ka dego etapu projektu zapewnia, e: s dostpne szczegy wystarczajce do bie cej kontroli planu; ka dy Plan Etapu zawiera uzgodnione zobowizania ze strony Ko mitetu Ster ujcego Kierownika i Projektu; na pocztku ka dego etapu Komitet Sterujcy jest w peni wiadomy tego, co akceptuje.

9.4.2.

Kontekst

Zbli ajcy si koniec bie cego etapu uruchamia omawiany podproces.

155

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

SE5 Przegl d Stanu Etapu

Powiadomienie o ko czeniu etapu

ZE1 Planowanie Etapu

Plan Etapu (nast pnego)

ZE2 Uaktualnienie Planu Projektu

IP6 Zestawienie Dokumentu Inicjuj cego Projekt

Struktura zespou zarz dzania projektem Rejestr Jako ci Rejestr Ryzyka

Plan Etapu (bie cego) Rejestr Zagadnie Dokument Inicjuj cy Projekt Plan Projektu Plan Jako ci Projektu

PL Planowanie

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rysunek 9.3. Planowanie Etapu

9.4.3.

Opis procesu

Gwnym celem tego podprocesu jest przygotowanie planu dla nastpnego etapu projektu. Oglny plan kolejnego etapu, wyjty z Planu Projektu, jest rozwijany w wystarczajco plan, na podstawie ktrego Kierownik Projektu bdzie mg kontr szczegowy olowa bie ce postpy prac. Planowani (PL) su y do opracowania planu. Proces e Plan powinien obejmowa wszystkie produkty - nie tylko specjalistyczne, ale rwnie zarzdcze. Typowy m produktem zarzdczym mo e by Planu Etapu (nastpnego), ktrego przygotowanie bdzie wy magane pod koniec etapu bie cego. Dziaania i produkty jakoci powinny by rwnie uwzgldnione w dotyczce a Rejestr Jakoci planie,by zaktualizowany w oparciu o nowe informacje. Dziaania w powi- jakoci nien zakresie bd prowadzone w oparciu o standardy okrelone w Planie Jakoci Projektu. Zanim Plan Etapu zostanie przedstawiony Komitetowi nale y skonsultowa z Sterujcemu, Projektu terminy oraz przydzia zasobw penicymi rol Nadzoru w obszarze jakoci. Zwykle to Kierownik Projektu powinien zaproponowa tolerancje dla na podstaetapu, oglnych tolerancji dla projektu oraz stopnia niepewnoci zwizanego z wie dziaaniami i zasobami objtymi Planem Etapu. Nale y tak e okreli struktur zarzdzania nastpnym etapem oraz opracowa nowe lub zmienione zakresy obowizkw.

9.4.4.

Odpowiedzialno

Za podproces jest odpowiedzialny Kierownik Projektu, wspomagany przez osoby peni- Wsparcia Projektu. Osoby penice obowizki Nadzoru Projektu powinny ce rol spraw-plan pod ktem staego spenienia oczekiwa klienta i biznesu. Kierownicy dzi Zespow, ktrzy bd dostarczali produkty w trakcie etapu, zwykle powinni w tym czasiewanie opracowa Plany Zespow i pomc Kierownikowi Projektu w przygotowaniu Planu Etapu.

15 6

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE) Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie
Wejcie Wskazanie wychodzce z podprocesu Przegld Stanu Etapu (SE5), e zbli a si koniec etapu.

9.4.5.

Tabela 9.1. ZE1 Informacja Objanienie

Powiadomienie o koczeniu etapu

Plan Etapu (bie cego) Wejcie Wyniki bie cego etapu mog wpyn na planowanie dziaa nowego etapu. Plan Projektu Wejcie Wskazuje produkty, ktre s wymagane w nastpnym etapie. Dokument Inicjujcy Projekt Wejcie Zawiera informacje o tym, co i dlaczego robi si w projekcie oraz jest dokumentem, ktry okrela warunki realizacji ustalone przez Komitet Sterujcy.

Rejestr Zagadnie Wejcie Mo e zawiera informacje, ktre maj znaczenie dla nastpnego etapu albo Zagadnienia Projektowe wyznaczone do ponownego rozpatrzenia na kocu etapu. Plan Jakoci Projektu Wejcie Dostarcza szczegw o standardach, ktre bd stosowane przy wytwarzaniu produktw i podczas kontroli jakoci. Rejestr Jakoci Aktualizacja Wprowadzane s dane na temat wszelkich planowanych nowych kontroli jakoci. Rejestr Ryzyka Wejcie Bie ce zagro enia mog wpyn na Plan Etapu (nastpnego), ktry sam tak e mo e stwarza lub modyfikowa dotychczasowe zagro enia. Struktura zespou zarzdzania projektem Plan Etapu (nastpnego) Aktualizacja Powinna by zaktualizowana poprzez uwzgldnienie wszelkich zmian niezbdnych w nastpnym etapie. Wyjcie Tworzony z wykorzystaniem procesu Planowanie (PL).

9.4.6.

Kryt eria oceny ci jako Czy gwne produkty wymienione w Planie Projektu dla nastpnego etapu znajduj odbicie w Planie Etapu (nastpnego)? Czy okrelono: u ytkownika, oraz inne zasoby wymagane do klienta produktw? sprawdzenia jakoci Czy zasoby u ywane do sprawdzenia jakoci s zgodne z wymaganiami Planu Jakoci Projektu?

157

MANAGING STAGE BOUNDARIES (SB) Wskazwki i rady

Nale y si upewni, e w Planie Etapu uwzgldniono wszelkie produkty zewntrzne wraz z waciwymi punktami monitorowania tak, by przekona Komitet Sterujcy, e produkty te s zarwno zgodne z planem, jak i z wymaganiami jakociowymi. Nale y sprawdza wszystkie zale noci zewntrzne, by mie pewno, e nie wystpiy adne zmiany zakresu lub ogranicze dotyczcych oczekiwanych od nich produktw. Plan Etapu powinien by przygotowywany rwnolegle ze zwizanymi z nim Planami Zespow. Zapewnienie, e procedury kontroli jakoci s stosowane prawidowo, stanowi wsplny obowizek Gwnego Dostawcy oraz Gwnego U ytkownika. Czy Plan Etapu pokazuje, w jaki sposb ten obowizek bdzie speniony, szczeglnie przez Gwnego U ytkownika? Plan wymaga zaanga owania u ytkownika w sprawdzanie produktw dostarczonych przez dostawc. Je eli projekt jest czci programu, jest mao prawdopodobne, eby zesp programu chcia rejestrowa dane o takim poziomie szczegowoci, z wyjtkiem niektrych zale noci midzy projektami. Plan Projektu jest bardziej waciwym poziomem. Jednak e zarzdzajcy programem mog wymaga posiadania kopii Planu Etapu, by si do niego odwoywa.

PRINCE2

9.5.
9.5.1.

Uaktualnienie Planu Projektu (ZE2)

Podstawowe zasady

Komitet Sterujcy wykorzystuje Plan Projektu w trakcie realizacji projektu do mierzenia W miar, jak etapy s koczone lub szczegowo planowane, Plan postpw. Projektu musi by uaktualniony, aby odzwierciedla najnowsze rozumienie projektu i pozwoli Komitetowi Sterujcemu na skorygowanie swoich oczekiwa.

9.5.2.

Kontekst

Plan Projektu jest uaktualniany informacjami, ktre mog pochodzi z Planu Etapu dla etapu, ktr y si wanie koczy, Planu Etapu (nastpnego)(z podprocesu ZE1) tego oraz dego Planu Nadzwyczajnego (z podprocesu ZE6) wywoanego przez podproces z ka Przekazywanie Projektowyc (SE8). Dane o faktycznym wykonaniu s Zagadnie h a prognoza pobie- trwania i rane z pierwszego z nich, czasu - z dwch ostatnich. kosztw Szczegy dotyczce skor ygowanych kosztw lub terminw zakoczenia s przekazywane do nastpnego - Uaktualnienie Uzasadnienia (ZE3). podprocesu Biznesowego

15 8

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

Z E1 Plan owanie Etapu

P l an E ta puas t pn eg o) (n

Pl a n Na d zwy c za j ny

Z E2 Uaktualnienie Planu Projektu

PL Plan owanie

Z E6 Opracowanie Planu Nadzwyczajnego

Pl a n E ta pu (bi e c e go)

P l a n Pr oj ek t u ormu a R e al i z ac j i Pr oj e k F tu l a n Ja k c i P r oj e k tu P o e j e s tr J a k o i R c R e j e s tr Za ga dn ie

P l a n Eta p una st pne go) ( Plan N a dz wy c za j ny

Doku mentacja Dokumentacja zarz dcza zarz dcza

Rysunek 9.4. Projektu

Uaktualnienie Planu

9.5.3.

Opis procesu

Plan Jakoci Projektu i Formua Realizacji Projektu s ponownie oceniane i precyzowane, aby odda aktualne rozumienie projektu i stworzy podstaw do uaktualnienia Planu Projektu. Plan Projektu jest uaktualniany na bazie faktycznych kosztw i harmonogramu, pocho- z ukoczonego Planu Etapu lub Planu Nadzwyczajnego, nowych szczegw dzcych dziaa i kosztw z Planu Etapu (nastpnego) oraz wszelkiej wiedzy uzyskanej o projek- ostatnia mo e by informacj o zmianach, ktre zostay uzgodnione przez cie. Ta Komitet Sterujcy i ktre bd skutkoway dziaaniami w Planie Etapu (nastpnego). Kierownik Projektu powinien opisa w Raporcie Kocowym Etapu, dlaczego w Planie Projektu zaszy jakiekolwiek zmiany.

9.5.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik wspomagany przez osoby peProjektu, nice rol Wsparcia Projektu, a osoby penice obowizki Nadzoru Projektu sprawdzaj prac. wyniki tych

159

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

9.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 9.2. ZE2 Informacja Objanienie

Plan Etapu (bie cego) Wejcie Wyniki bie cego etapu mog wpywa na planowanie projektu. Plan Etapu (nastpnego) lub Plan Nadzwyczajny Formua Realizacji Projektu Wejcie Dodatkowe szczegy w Planie Etapu lub Planie Nadzwyczajnym mog ujawni potrzeb zmodyfikowania Planu Projektu. Aktualizacja Mogy zaj zdarzenia, ktre spowoduj konieczno modyfikacji formuy realizacji.

Rejestr Zagadnie Aktualizacja Mog istnie Zagadnienia Projektowe, ktre naley rozpatrzy w tym momencie. Plan Jakoci Projektu Aktualizacja Wyniki przeprowadzonych do tej pory kontroli jakoci mog wskaza potrzeb skorygowania Planu Jakoci Projektu. Plan Projektu Aktualizacja Skorygowany w wyniku uwzgldnienia faktycznych rezultatw bie cego etapu i prognoz, wynikajcych z Planu Etapu (nastpnego). Tak e aktualizowany, aby uwzgldni wszelkie zmienione lub dodatkowe produkty usankcjonowane przez Komitet Sterujcy. Rejestr Ryzyka Aktualizacja Zmiany w Planie Projektu mog wpyn na zagro enia.

9.5.6.

Kryteria oceny ci jako Na ile wiarygodne s liczby dotyczce kosztw i harmonogramu dla wanie koczonego etapu (zwaszcza jeli informacje pochodz z Planw Zespow)? W jaki sposb rezultaty etapu oddziaywuj na Plan Projektu? W jaki sposb Plan Etapu (nastpnego) wpywa na Plan Projektu, Uzasadnienie Biznesowe oraz na zagro enia? Czy w ostatnim etapie zostaa ujawniona jakakolwiek inna informacja, ktr a bdzie na pniejsze etapy projektu? wpywa

Wskazwki i rady
Jeli Plan Projektu jest aktualizowany z powodu zmiany zakresu projektu, nale y si upewni, e na potrzeby audytu zachowano lad cie ki midzy przyczyn a skutkiem, np. nale y sprawdzi, czy zmiany te s zarejestrowane jako Zagadnienia Projektowe.

16 0

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

9.6.
9.6.1.

Uaktualnienie Uzasadnienia Biznesowego (ZE3)

Podstawowe zasady

Projekty nie s realizowane w statycznym r odowisku. Zewntrzne w stosunku do pro- otoczenie zmienia si, podobnie jak charakter i ramy czasowe produktw jektu projektu. Uzasadnienie Biznesowe powinno odzwierciedla te zmiany i musi by rewidowane i poprawiane, aby odzwierciedlao aktualny stan otoczenia i projektu.

9.6.2.

Kontekst

Uaktualnianie Uzasadnienia Biznesowego oraz Planu Projektu jest procesem cyklicznym realizowanym w trakcie caego projektu podczas dziaa zwizanych z koczeniem etapu.
Plan Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

Uzasadnienie Biznesowe Rejestr Zagadnie Rejestr Ryzyka

ZE3 Uaktualnienie Uzasadnienia Biznesowego

Rysunek 9.5. Biznesowego

Uaktualnienie

Uzasadnienia

9.6.3.

Opis procesu

Celem podprocesu jest dokonanie ponownego przegldu i skorygowanie, jeli jest to konieczne, kosztw, korzyci, zagro e oraz terminw podanych w Uzasadnieniu Biznesowym. Mogy na nie wpyn wydarzenia wewntrzne lub zewntrzne. R ne czynniki bd wpyway na ten podproces: kocowa data wdro enia projektu moga ulec zmianie (na lepsze lub na gorsze), co e wpyn na niektre lub na wszystkie mo korzyci; 19 , wpywajc w ten sposb na stron mg si zmieni koszt dostarczenia produktu kosztow analizy koszty/korzyci; zatwierdzone zmiany mogy wpyn na produkty, a pr zez to na korzyci; zewntrzne rodowisko firmy lub programu, do ktrego ma by dostarczony produkt, mogo ulec zmianie; sytuacja, dotyczca zewntrznych zasobw lub dostawcw moga ulec zmianie w sposb pozostajcy poza kontrol projektu; Plan Nadzwyczajny mo e spowodowa konieczno ponownego przegldu Uzasadnienia Biznesowego.

19

Finalnego przypis tumacza.

161

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

W trakcie podprocesu tworzy si skorygowan wersj Uzasadnienia Biznesowego. Rejestr Ryzyka i Rejestr Zagadnie, by stwierdzi, czy zmienio si Sprawdza si cokol-co mogoby wpyn na Uzasadnienie Biznesowe. wiek, Nie ma znaczenia, czy zmiany wzmacniaj Uzasadnienie Biznesowe, czy te osabiaj je. Komitet Sterujcy jest zwykle upowa niony do udzielenia zezwolenia na kontynuacj tylko wtedy, gdy projekt pozostaje zasadny (to znaczy, gdy korzyci bd zrealizowane w ramach kosztw i czasu ustalonych w aktualnie obowizujcym Uzasadnieniu Bizne- Jeli koszty i/lub czas trwania projektu bd przekroczone lub gdy stanie si sowym). ja- e korzyci bd znacznie mniejsze ni te, ktre przedstawiono w Uzasadnieniu sne, Biznesowym, Komitet Sterujcy musi posiada skorygowane Uzasadnienie Biznesowe ponownie zatwierdzone przez kierownictwo firmy lub programu.

9.6.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik Projektu, wspomagany przez osoby peni- Wsparcia Projektu. Osoby penice obowizki Nadzoru Projektu powinny ce rol spraw- wyniki tych dzi prac. Uzyskanie korzyci biznesowych to podstawowy obowizek klienta.

9.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 9.3. ZE3 Informacja Objanienie

Plan Projektu Wejcie Czy dokonano jakichkolwiek zmian w Planie Projektu, ktre wpyn na Uzasadnienie Biznesowe? Rejestr Zagadnie Aktualizacja Czy s jakie nowe Zagadnienia Projektowe, ktre osabiaj lub wzmacniaj Uzasadnienie Biznesowe? Czy zmiany w Uzasadnieniu Biznesowym s rdem nowych Zagadnie Projektowych? Uzasadnienie Biznesowe Aktualizacja Skorygowane w celu uwzgldnienia wszelkich zmian w projekcie, ktre mog na nie wpyn.

Rejestr Ryzyka Aktualizacja Czy s jakie nowe zagro enia, ktre osabi Uzasadnienie Biznesowe?

9.6.6.

Kryteria oceny ci jako Czy na zewntrz projektu zdarzyo si co, co wpywa na Uzasadnienie Biznesowe? Czy Plan Projektu zmieni si w taki sposb, e wpywa to na Uzasadnienie Bizne- na przykad w kategoriach cakowitego kosztu lub terminu przekazania sowe wyniku? Czy stao si niemo liwe osignicie niektrych lub wszystkich okrelonych wcze- korzyci? niej

16 2

PRINCE2 Wskazwki i rady

ZARZDZANIE ZAKRESEM ETAPU (ZE)

Przegld Uzasadnienia Biznesowego najlepiej jest zrobi po uaktualnieniu Planu Projektu. Racjonalne jest dokonanie przegldu Uzasadnienia Biznesowego, gdy do nowego Planu Etapu dodano jakiekolwiek dziaania spowodowane reakcj na zagro enia. Te dziaania lub ich koszty mog mie wpyw na Uzasadnienie Biznesowe.

9.7.
9.7.1.

Uaktualnienie Rejestru Ryzyka (ZE4)

Podstawowe zasady

Ryzyko zmienia si podczas ycia projektu. Pojawiaj si nowe zagro enia. Istniejce zagro enia zmieniaj swj status. Nara enie projektu na ryzyko powinno by sprawdzane systematycznie .

9.7.2.

Kontekst

Uaktualnienie Rejestru Ryzyka jest procesem cyklicznym, realizowanym podczas dziaa koczcych etapy w trakcie caego projektu. Jest minimaln liczba przegldu zagro to dugotrwaych lub ryzykownych projektach zagro a W enia musze. by przegldane czciej.
Plan Projektu Plan Etapu / Plan Nadzwyczajny Uzasadnienie Biznesowe

Dokumentacja Dokumentacja zarz dcza zarz dcza

Rejestr Zagadnie Rejestr Ryzyka

ZE4 Uaktualnienie Rejestru Ryzyka

Rysunek 9.6. Ryzyka

Uaktualnienie Rejestru

9.7.3.

Opis procesu

Celem podprocesu jest ponowny przegld i, jeli to konieczne, skorygowanie zagro e znajdujcych si w Rejestrze Ryzyka. Mogy mie bowiem na nie wpyw zdarzenia wewntrzne lub zewntrzne. Ka de zagro enie powinno by zbadane w celu stwierdzenia, czy wzroso, zniko, zmniejszyo si, zmaterializowao si, czy te pozostao takie samo. Plan Etapu (nastpnego) lub Plan Nadzwyczajny mog wprowadzi nowe zagro enia lub zmieni istniejce. Ten podproces powinien wic by prowadzony razem z podprocesami Planowanie (ZE1) oraz Opracowanie Planu (ZE6). Etapu Nadzwyczajnego 163

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

Aktualizacje Planu Projektu i Uzasadnienia Biznesowego mog rwnie zawiera zmia-ktre wpyn na pozycje w Rejestrze Ryzyka. Uaktualnienie Uzasadnienia ny, Biznesowego mogo te spowodowa powstanie nowych Zagadnie Projektowych, ktre z kolei wywoaj nowe zagro enie lub wpyn na zagro enia ju znane. Dalsze zalecenia dotyczce ryzyka znajduj si w Rozdziale 17 Zar dzanie z ryzykiem .

9.7.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik Projektu, wspomagany przez osoby penice rol Wsparcia Projektu, a osoby penice obowizki Nadzoru Projektu powinny sprawdzi wyniki tych prac. Ka de powa ne zagro enie powinno mie waciciela osob jak najlepiej ulokowan, aby obserwowa to zagro enie i czynniki wpywajce na nie. Osoba ta jest czsto czon- zespou zarzdzania projektem, ale nie jest to kiem konieczne.

9.7.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Trzeba si do niego odnie w przypadku, gdy zawiera now informacj dotyczc zagro e.

Tabela 9.4. ZE4 Informacja Objanienie

Uzasadnienie Biznesowe

Plan Projektu Wejcie Przejrzany Plan Projektu mo e dostarczy informacji stanowicych podstaw dla okrelenia wpywu zagro e oraz dziaa zapobiegawczych. Plan Etapu / Plan Nadzwyczajny Wejcie Nowy plan mo e zawiera nowe zagro enia lub zmieni ju istniejce.

Rejestr Zagadnie Aktualizacja Czy powstay jakie nowe Zagadnienia Projektowe, ktre s spowodowane przez nowe zagro enia (lub mog je zmniejszy)? Rejestr Ryzyka Aktualizacja Czy ktra z pozycji ulega zmianie?

9.7.6.

Kryteria oceny ci jako Czy zmienia si sytuacja zwizana z ktrym ze znanych zagro e? Czy zidentyfikowano jakie nowe zagro enia? Czy tam, gdzie to mo liwe, opracowano plany rezerwowe dla wszystkich zag ro e uznanych aktualnie za powa ne?

16 4

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

9.8.
9.8.1.

Raportowanie Ko
Podstawowe zasady

ca Etapu (ZE5)

Raporty o wynikach etapu powinny by przekazywane tym osobom, ktre zapewniy zasoby i zatwierdziy jego realizacj, tak eby przebieg etapu by dobrze znany zespoowi zarzdzania projektem.

9.8.2.

Kontekst

Podproces Raportowanie ca (ZE5) obejmuje przegld wpywu etapu na Ko Etapu Projektu, Uzasadnienie oraz Plan znane zagro na Nastpuje on po Biznesowe wczeniejszych podprocesach Zar dzania enia. Zakresem (ZE) i konsoliduje pochodzce z z Etapu nich informacje w raporcie, ktry jest oceniany przez Komitet Sterujcy w Ze podprocesie zwolenie na Planu lub Planu (ZS3). Realizacj Etapu Nadzwyczajnego
ZE5 Raportowanie Ko ca Etapu
Plan Etapu (bie cego)

Plan Etapu (nast pnego) lub Plan Nadzwyczajny Plan Etapu (bie cego) Rejestr Zagadnie Uzasadnienie Biznesowe Rejestr Ryzyka Rejestr Jako ci

D okumentacja Dokumentacja zarz dcza zarz dcza

Rejestr Do wiadcze Zapisy Obiektw Konfiguracji Plan Komunikacji

Plan Etapu (nast pnego) lub Plan Nadzwyczajny Raport Ko cowy Etapu Wniosek o zezwolenie na kontynuowanie

ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

Rysunek 9.7. Raportowanie Koca Etapu

9.8.3.

Opis procesu

Ten podproces powinien by realizowany tak blisko rzeczywistego koca etapu, jak to tylko mo liwe. Wyniki etapu s prezentowane w Raporcie Kocowym Etapu. Raport ten porwnuje rzeczywiste wyniki etapu z pierwotnym Planem w kategoriach Etapu, zakadanych terminw realizacji i wytworzonych produktw. Skadane jest kosztw, owiad165

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

czenie porwnujce uzyskane wyniki z uzgodnionymi tolerancjami dla Kierownik etapu. prezentuje swoj opini dotyczc dalszej zdolnoci projektu do sprostania Projektu wymogom Planu Projektu i Uzasadnienia Biznesowego oraz dokonuje oglnej oceny ryzyka. Przekazywana jest informacja zwrotna dotyczca zrealizowanych kontroli oraz jakoci ich rezultatw. Przedstawiane jest podsumowanie wszystkich Zagadnie Projektowych otrzymanychetapu oraz tego, co z nimi w trakcie zrobiono. Przeprowadzany jest audyt konfiguracji, aby sprawdzi, czy informacje w Zapisach Konfiguracji s zgodne z rzeczywistym statusem wszystkich produktw Obiektw oraz sprostowa wszelkie rozbie by noci. Je eli raport taki jest spowodowany przez Plan Nadzwyczajny, to jest on wprawdzie zmodyfikowany, ale nadal potrzebny. W takim przypadku Raport Kocowy Etapu opisuje dotychczasowe wyniki bie cego etapu, sytuacj w obszarach tolerancji i Zagadnie Projektowych, a nastpnie streszcza Raport o Istotnych Odchyleniach oraz ustalenia, ktre doprowadziy do sporzdzenia Planu Nadzwyczajnego. Plan Etapu (nastpnego) oraz poprawiony Plan Projektu (jeli doszo do korekty) towa- Raportowi Kocowemu Etapu. Raport okrela wszelkie r nice midzy tymi rzysz pla- w stosunku do poprzednich ich wersji i ocenia wszelkie zmiany sytuacji w nami aspekcie Jeli w opinii Kierownika Projektu projekt jest nadal zasadny, Raportowi ryzyka. Kocowemu Etapu bdzie towarzyszy wniosek o zezwolenie na kontynuowanie i pr zejcie nastpnego do etapu. Wszelkie dowiadczenia zdobyte w trakcie etapu s dodawane do Rejestru Dowiadcze. Wszystkie dowiadczenia z bie cego etapu s streszczone w Raporcie Kocowym Etapu. Sprawdza si Plan Komunikacji i zgodnie z jego wymaganiami opracowuje si i rozsya odpowiednie informacje.

9.8.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik Projektu, wspomagany przez osoby peni- Wsparcia Projektu. Nieformalna aprobata danych i wnioskw zawartych w ce rol raporcie powinna by uzyskana od osb odpowiedzialnych za Nadzr Projektu. Bibliotekarz powinien pomc Nadzorowi Projektu w przeprowadzeniu audytu Konfiguracji konfiguracji .

16 6

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

9.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 9.5. ZE5 Informacja Objanienie

Plan Etapu (bie cego) Wejcie Zawiera informacje o produktach, kosztach i terminach bie cego etapu. Uzasadnienie Biznesowe Wejcie Wykorzystywane do przegldu wkadu, jaki ma bie cy etap w osiganiu korzyci. Rejestr Zagadnie Wejcie Identyfikuje Zagadnienia Projektowe wniesione podczas etapu i raportuje, w jaki sposb z nimi postpiono. Rejestr Ryzyka Wejcie rdo informacji o statusie aktualnych zagroe. Rejestr Jakoci Wejcie rdo informacji o dziaaniach kontroli jakoci i ich wynikach, pochodzcych od osb dokonujcych przegldu jakoci produktw. Plan Komunikacji Aktualizacja Mo e zawiera wymaganie dotyczce wysania w tym momencie informacji do interesariuszy. Mo e wymaga zaktualizowania o nowe strony np. nowych dostawcw, lub nowy Nadzr Projektu Plan Etapu (nastpnego) lub Plan Nadzwyczajny Wecie / Wyjcie Przyszy wpyw na projekt, do wykorzystania w Raporcie Kocowym Etapu.

Rejestr Dowiadcze Aktualizacja Uaktualniony o wszelkie nowe dowiadczenia nabyte podczas tego etapu. Zapisy Obiektw Konfiguracji Aktualizacja Sprawdzane w celu ustalenia, czy wszystkie produkty s zakoczone i zatwierdzone oraz dla upewnienia si, e szczegy, takie np. jak numer wersji, s prawidowe. Uaktualniane w przypadkach, gdy informacja w zapisach nie jest zgodna ze stanem rzeczywistym produktw. Wniosek o zezwolenie na kontynuowanie Wyjcie Mo e by formalny lub nieformalny, w zale noci od ustale w projekcie.

Raport Kocowy Etapu Wyjcie Wykonanie etapu w stosunku do planu.

9.8.6.

Kryt eria oceny ci jako Czy wszystkie produkty wymienione w Planie Etapu wytworzone? Czy wszystkie zostay sprawdzone pod wzgldem jakoci? Czy klient zaakceptowa je wszystkie? Jakie byo faktyczne wykorzystanie zasobw oraz koszty etapu? 167

zostay

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

Ile Zagadnie Projektowych otrzymano w trakcie etapu? Ile zmian zostao zatwierdzonych i wdro onych w trakcie etapu, czciowo lub cakowicie, i jaki by ich wpyw na Plan Etapu? Czy jakie zmiany zostay przeniesione do nastpnego etapu? Czy projekt nadal jest zasadny? Czy nadal przewiduje si, e Plan Projektu pozostanie w granicach tolerancji? Czy zarzdzajc ryzykiem w trakcie tego etapu prawidowo identyfikowano i obsugiwano zagro enia dla projektu? Czy w stosowanych standardach i procedurach znajduj si jakie silne strony, saboci lub przeoczenia, o ktrych powinno by powiadomione firmowe kierownictwo jakoci? Czy w trakcie etapu uzyskano jakie u yteczne wyniki pomiarw, ktre mogyby przynie korzyci dla planowania przyszych etapw lub innych projektw? Czy znaleziono jakie rozbie noci podczas wykonywania audytu konfiguracji? Czy zajto si ich implikacjami oraz czy dokonano odpowiednich wpisw w Rejestrze Dowiadcze?

Wskazwki i rady
Pod ajc za mottem: adnych niespodzianek, Kierownik Projektu powinien nieformalnie uwiadomi Komitetowi Sterujcemu, co bdzie zawarte w Raporcie Kocowym Etapu. Wszystkie problemy, je eli jest to mo liwe, powinny by rozwizane przed prezentacj raportu. Poziom sformalizowania prezentacji Raportu Kocowego Etapu zale y od takich czynnikw, jak wielko projektu oraz yczenia Komitetu Sterujcego. Jeli projekt jest czci programu, biuro wsparcia programu musi sprawdzi Raport Kocowy Etapu, Plan Etapu (nastpnego) i uaktualniony Plan Projektu w celu upewnienia si, e projekt pozostaje w zgodzie z programem.

9.9.
9.9.1.

Opracowanie Planu Nadzwyczajnego (ZE6)

Podstawowe zasady

Uwa a si, e w etapie wystpiy istotne odchylenia, jeli tylko bie ce prognozy dla koca etapu wskazuj, e przekroczy on okrelone dla niego tolerancje. W projekcie dochodzi do istotnego odchylenia, je eli pojawi si prawdopodobiestwo, e cay projekt przekroczy wyznaczone dla niego tolerancje. Jeli przewiduje si, e albo etap, albo projekt przekroczy ustalone granice tolerancji, to traci on od tego mo mentu akceptacj Komitetu Sterujcego. Musi by przedstawiony nowy plan, zastpujcy plan bie cy. 16 8

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE) Kontekst (SE).

9.9.2.

Istotne odchylenie powinno zosta rozpoznane podczas Sterowania procesu Etapem Kierownik Projektu zwrci na to uwag Komitetu Sterujcego za pomoc Raportu ostotnych Odchyleniach. Ko mitet Sterujcy mo e poprosi Kierownika Projektu o I przygotowanie Planu Nadzwyczajnego. Plan Nadzwyczajny bdzie nastpnie przedstawiony Sterujcemu Komitetowi podczas Oceny nadzwyczajnej.
PL Planowanie

Pro ba o Plan Nadzwyczajny

SE8 Przekazywanie Zagadnie Projekto wych

ZE6 Opraco wanie Planu Nadzwyczajnego

Plan Nadzwyczajny

ZE2 Uaktualnienie Planu Projektu

Struktura zespou zarz dzania projektem Rejestr Jako ci

Pro ba o Plan Nadzwyczajny

Dokumentacja Dokumentacja zarz dcza zarz dcza

Raport o Istotnych Odchyleniach Rejestr Zagadnie Rejestr Ryzyka Plan Etapu (bie cego) Plan Projektu Dokument Inicjuj cy Projekt Zestawienie Statusu Produktw Plan Nadzwyczajny

Rysunek 9.8. Opracowanie Planu Nadzwyczajnego

9.9.3.

Opis procesu

Jeli przewiduje si, e etap lub projekt przekrocz tolerancje, uzgodnione z Komitetem podczas aprobowania planu, a sytuacja nie mo e by naprawiona, Sterujcym Kierownik Projektu traci upowa nienie do kontynuowania prac. Plan Nadzwyczajny bdzie mia tak sam struktur, jak inne plany PRINCE2. Plan taki powinien obowizywa od chwili bie cej, do momentu, w ktrym koczy si zastpo-plan. Jeli doszo do odchyle od Planu Projektu, powinien zosta wany opracowany Plan Projektu, uwzgldniajcy dane o faktycznym wykonaniu zrewidowany prac.

169

MANAGING STAGE BOUNDARIES (SB)

PRINCE2

Zapisy Obiektw Konfiguracji wszystkich produktw uwzgldnionych w planie, ktry ma by zastpiony, musz by sprawdzone. Jeli status pokazuje, e pewne prace nie zo- wykonane, powinno si je wprowadzi do Planu Nadzwyczajnego. stay

9.9.4.

Odpowiedzialno

Bibliotekarz Konfiguracji powinien dostarczy Zestawienie Statusu Produktw ujtych w planie, ktry ma by zastpiony. Kierownik Projektu jest odpowiedzialny za przygo- Planw Nadzwyczajnych z pomoc osb penicych rol Wsparcia towanie Projektu. Osoby odpowiedzialne za Nadzr Projektu powinny zweryfikowa plan.

9.9.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 9.6. ZE6 Informacja Objanienie

Plan Etapu (bie cego)

Wejcie Jest to plan, od ktrego wystpio istotne odchylenie i ktry powinien okrela obszar tolerancji oraz wielko tego odchylenia. Mo e by rwnie wykorzystany do ekstrapolacji, co by si wydarzyo, gdyby, mimo odchylenia, pozwoli na kontynuacj prac. Wejcie Zawiera takie elementy, jak rekomendowane dziaanie, ktre wejdzie do Planu Nadzwyczajnego.

Raport o Istotnych Odchyleniach

Rejestr Zagadnie Wejcie Mo e zawiera szczegy dotyczce przyczyn, z powodu ktrych przewiduje si istotne odchylenie projektu lub etapu poza granice tolerancji. Plan sam w sobie mo e powodowa nowe zagro enia lub zmienia istniejce. Rejestr Ryzyka Wejcie Mo e zawiera szczegy dotyczce przyczyn, z powodu ktrych prognozuje si istotne odchylenie projektu lub etapu poza granice tolerancji. Plan Projektu Wejcie Pokazuje produkty, ktre powinny by dostarczone w ramach bie cego etapu. Dokument Inicjujcy Projekt Wejcie Zawiera odpowiedzi na pytania Co realizuje si w projekcie i Dlaczego, i stanowi dokument, ktry okrela wymagania Komitetu Sterujcego dotyczce projektu. Wejcie Zawiera informacje o produktach cigle jeszcze niezakoczonych.

Zestawienie Statusu Produktw

Rejestr Jakoci Aktualizacja Dostarcza danych na temat planowanych nowych kontroli jakoci.

17 0

PRINCE2

ZARZDZANIE ZAKRESEM ETAPU (ZE)

Informacja Objanienie

zarzdcza

Wykorzystanie
Wejcie Jeli w odpowiedzi na Raport o Istotnych Odchyleniach (SE8), Komitet Sterujcy zwrci si z prob o Plan Nadzwyczajny (ZS4), taka proba bdzie przekazana dalej, w ramach procesu SE8, jako sygna do wszczcia niniejszego podprocesu.

Proba o Plan Nadzwyczajny

Plan Nadzwyczajny Wyjcie Produkt tego podprocesu - plan, ktry zastpuje Plan Etapu (bie cego). Struktura zespou zarzdzania projektem Aktualizacja Powinna zosta zaktualizowana z uwzgldnieniem wszelkich zmian, dotyczcych reszty etapu.

9.9.6.

Kryt eria oceny ci jako Czy istotne odchylenie wpyno niekorzystnie na Uzasadnienie Biznesowe projektu? Jakie dodatkowe zagro enia wprowadza zaakceptowana opcja?

Wskazwki i rady
Jeli tolerancje projektu s zagro one, powinno si opracowa skorygowany Plan Projektu. Jeli projekt jest czci programu, biuro wsparcia programu musi sprawdzi Plan Nadzwyczajny w celu upewnienia si, e projekt jest nadal zgodny z programem. Kierownik Projektu powinien by ostro ny, aby nie przecenia wasnej zdolnoci do znalezienia wyjcia w przypadku przewidywanego istotnego odchylenia.

171

10.

ZA M YK AN I E P ROJ EK TU (ZP )
(CLOSING A PROJECT - CP)

Sprawdzenie, czy wszystkie produkty zostay dostarczone i zaaprobowane przez klienta

Udokumentowanie wszelkich p niejszych dziaa , ktre powinny by podj te przez grupy utrzymania i eksploatacji

Zaplanowanie, kiedy i jak nale y oceni osi gni cie oczekiwanych korzy ci

Raportowanie o osi gni ciach projektu

Rysunek 10.1. Projektu

Zarys procesu Zamykanie

10.1.

Podstawowe zasady

Jedn z cech charakteryzujcych projekt jest skoczony czas trwania ma on pocztek Jeli projekt traci t wyr niajc cech, traci cz swej przewagi nad i koniec. podejciem, polegajcym na czysto operacyjnym zarzdzaniu. Jednoznaczne zakoczenie projektu: jest zawsze bardziej skuteczne ni naturalna tendencja do zbaczania w stron u ywania, a nastpnie modyfikowania produktu. Zakoczenie projektu to uznanie przez wszystkich zainteresowanych, e: pierwotne cele zostay osignite; projekt przebieg waciwie; eksploatacja musi przej wytworzone produkty, albo te produkty stan si wejciem do kolejnego projektu lub wikszego programu; pomaga w osigniciu celw biznesowych przez uniknicie strat czasu oraz dostar- ytecznej sposobnoci do zinwentaryzowania osigni i cza u dowiadcze; daje szans zapewnienia, e wszystkie nieosignite cele i niezrealizowane zadania zidentyfikowane, tak by mo na zaj si nimi w zostan przyszoci. 17 3

CLOSING A PROJECT (CP)

PRINCE2

10.2.

Kontekst

Przygotowanie projektu do zamknicia jest zwykle uruchamiane, gdy ostatni etap zbli ai do koca lub gdy stanie si oczywiste, e projekt z jakiego powodu nie jest du s ej zasadny. Wszystkie podprocesy w ramach Zamykanie (ZP) mog by procesu Projektu realizowane rwnolegle lub przynajmniej w znacznym stopniu zachodzc na siebie. podejmowane Prace w Zamykania (ZP) nie stanowi ramach Projektu etapu.
ZP Zamykanie Projektu

ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzw yczajnego

ZP1 Przygotow anie Projektu do Zamkni cia

ZS4 Podejmowanie Decyzji Dora nych

ZP2 Okre lenie Dziaa Nast pczych

ZS5 Zatw ierdzenie Zamkni cia Proje ktu

SE5 Przegl d Stanu Etapu

ZP3 Przegl d Oceniaj cy Projekt

Rysunek Projektu

10.2.

Zamykanie

10.3.

Opis procesu

Podejcie do procesu Zamykanie (ZP) powinno by dopasowane do potrzeb Projektu konkretnego projektu. Przykadowo, jeli projekt jest czci programu lub jednym z serii projektw, mo e to wpywa na stosowanie niektrych fundamentalnych zasad, takich jak podejmowanie dziaa nastpczych. Projekt mo e by wwczas cile zwizany z nastpnym projektem i mg by wanie w ten sposb zaplanowany. Wszystkie wyniki pier wszego projektu przechodz do nastpnego projektu, a w takim przypadku nie ma potrzeby zajmowania si utrzymaniem, warunkami eksploatacji czy innymi dziaaniami nastpczymi . nny przykad: jeli w projekcie wytworzono produkt niematerialny powiedzmy I do17 4

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

prowadzono do zmiany podejcia wwczas cel, jakim jest zapewnienie zorganizowania wsparcia operacyjnego i utrzymania, mo e nie by waciwy. Poni sza lista ilustruje cele Zamykanie (ZP). Zale nie od typu procesuniektre z nich bd wy Projektu projektu tylko magane: zagwarantowanie, e zadania i cele przedstawione w Doku mencie Inicjujcym Pr ojekt zostay zrealizowane; zapewnienie, e wszystkie oczekiwane produkty zostay przekazane i zaakceptowane lub odpowiedni kolejny przez klienta projekt; zapewnienie, e wszystkie Kryteria Akceptacji zostay spenione i uzyskano stosowne potwierdzenie od klienta; zagwarantowanie, e wprowadzono rozwizania organizacyjne potrzebne do utrzy- i eksploatacji produktw projektu (tam, gdzie jest to konieczne) mania ; wnioskowanie o formaln akceptacj produktw przez Komitet Sterujcy; jeli projekt zosta zamknity przedwczenie, udokumentowanie, co zostao osignite, i zalecenie dalszych dziaa; okrelenie wszelkich Zalece Dziaa Nastpczych; zgromadzenie i udokumentowanie dowiadcze z projektu; przygotowanie Raportu Kocowego Projektu; zaplanowanie wymaganych przegldw poprojektowych; przygotowanie zawiadomienia dla organizacji realizujcej projekt o zamiarze rozwizania organizacji projektu oraz uwolnienia zasobw; zorganizowanie bezpiecznego i uporzdkowanego archiwizowania dokumentacji projektu. Proces obejmuje prace Kierownika Projektu majce na celu zamknicie projektu zarwno po doprowadzeniu go do koca, jak i w przypadku przedwczesnego Wikzamknicia. su y przygotowaniu materiaw dla Komitetu Sterujcego, aby uzyska szo prac od niego zgod na zamknicia projektu. Jeli projekt jest zamykany przedwczenie, proces ten musi by dostosowany do faktycznej sytuacji. W tym przypadku trzeba oceni, co na zachowa do wykorzystania w innym projekcie lub jakie prace naprawcze s mo teraz konieczne, aby wypeni wszelkie luki powstae w wyniku anulowania projektu. Dokument Inicjujcy Projekt jest przegldany w celu sprawdzenia faktycznych rezulta- odniesieniu do pierwotnych oczekiwa (lub zmodyfikowanych przez Komitet tw w Sterujcy). Wszystkie zaplanowane produkty powinny zosta zatwierdzone i klientowi dostarczone gotowe do przekazania. Musi by udokumentowane lub by potwierdzenie e wszystkie Kryteria Akceptacji, zdefiniowane na pocztku projektu, przez klienta, zo- spenione. stay Kierownik Projektu przygotowuje Raport Kocowy Projektu, ktry wyczerpujco ocenia faktyczny wynik w porwnaniu z tym, ktry zaplanowano w Dokumencie Inicjujcym Projekt. Na mocy decyzji Komitetu Sterujcego, pewna liczba Zagadnie Projektowych moga pozostawa w zawieszeniu. Mog one prowadzi do nowych projektw lub ulepszenia 175

CLOSING A PROJECT (CP) produktw bie cego projektu podczas ich eksploatacji. Kierownik Projektu porzdkuje je, tworzc odpowiednie Zalecenia Dziaa Nastpczych. Rejestr Dowiadcze, ktry by zapisywany w trakcie projektu, przeksztacany jest obec-w raport i udostpniany zainteresowanym spoza nie projektu. Przygotowuje si do zaakceptowania przez Komitet Sterujcy powiadomienie dla organizacji realizujcej projekt, e wszystkie dostarczone do projektu urzdzenia i zasoby nie bd du ej potrzebne, wskazujc daty ich zwolnienia. Nale y zorganizowa archiwizacj dokumentw zarzdczych, tak by ka dy pniejszy wyszukiwanie mogy by przeprowadzone w wygodny sposb. audyt lub ich Sugerowan zawarto produktw zarzdczych znale A Zarysy w Dodatku Opisw . Produktw opisanych w tym procesie

PRINCE2

mo na

10.3.1.

Skalowalno

zasadnicze elementy tego procesu mog by

Dla maych projektw, przedstawionesposb: w nastpujcy

sprawdzi, czy wszystko zostao dostarczone; sprawdzi, czy produkt zosta zaakceptowany; upewni si, czy nie ma adnych niezaatwionych spraw; zarejestrowa wszelkie Zalecenia Dziaa Nastpczych; przechowa dokumentacj projektu na potrzeby audytu; zwolni zasoby zgodnie z wymaganiami.

Wskazwki i rady
Jeli z Formuy Realizacji Projektu wynika stopniowe oddawanie do u ytku lub wprowadzenie do eksploatacji produktu(-w), warto wwczas rozwa y podjcie pewnych czynnoci podprocesu Zamykanie Projektu, w szczeglnoci: akceptacj przez klienta, akceptacj przez su by operacyjne i utrzymania, przegld niezaatwionych Zagadnie Projektowych i zagro e zwizanych z wdra anymi elementami oraz by mo e przegld Rejestru Dowiadcze. W takim przypadku elementy te bd stanowi cz prac stopniowego wdro enia, ktre mo e zsynchronizowa si z kocem etapu.

10.4.
10.4.1.
Podstawowe projektu:

Przygotowanie Projektu do Zamkni

Podstawowe zasady zasady przygotowania do zamknicia

cia (ZP1)

17 6

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

ka dy projekt powinien zmierza do uporzdkowanego zamk nicia; klient i dostawca powinni zgodzi si, e projekt dostarczy to, czego oczekiwano. te powinny by zdefiniowane na pocztku Oczekiwania projektu; ka dy, kto zapewnia projektowi wsparcie, powinien by uprzedzony o jego zamkniciu, aby mg zaplanowa powrt dostarczonych zasobw; dokumentacja projektu powinna by zachowana jako pomoc w mo liwych audytach przygotowywaniu danych liczbowych dla przyszych lub w oszacowa. 10.4.2. Kontekst Podproces jest zwykle wywoywany z podprocesu Przeg d Stanu (SE5), kiedy l koca ostatniego etapu. Etapu Kierownik Projektu uznaje, e projekt zbli a si do Realizacja (ZP1) jest czci pracy prowadzc do podprocesu Komitetu Sterujcego podprocesu - atwierdzenie Z cia (ZS5). Zamykanie (ZP) przebiega wok Zamkni podprocesw, dla ktrych nie okrela si konkretnej Projektu Projektu trzech kolejnoci. W sytuacjach nadzwyczajnych omawiany podproces mo e by uruchomiony, gdy Komitet Sterujcy poleci Kierownikowi Projektu zamkn projekt przed planowanym kocem.
ZS4 Podejmowanie Decyzji Dora nych
Po l ece n ie p r zed w czes ne g o za mk c ia ni p ro j ek tu

Z al ec en i e za mk c ia niro j ek tu p Po l ece n ie p rze dw c zes n eg o za mkn c ia i ro j ekt u p

ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

ZP1 Przygotowanie Projektu do Zamkni cia

SE5 Przegl d Stanu Etapu

Po w ia d o- ie ni e m o koc zen i u p ro j ekt u

A kce pt acj a p rze z s u by e ksp l o atac j i utr zym an ia A kce pt acj a p rze z k li en ta A ud yt on fi g ur ac k ji

ZS5 Zatwierdzenie Zamkni cia Projektu

Dokumentacja Dokumentacja zarz dcza zarz dcza

D o ku me nt I ni c juc y P ro je kt j a n Ko m un i ka cj Pl i ej es tr Z ag ad n R ie a pi sy O b i ekt w K o nfi g u rac Z ji a n Z d zan i a Ko n fig u ra Pl arz staw i en cje Statu su Pro d uk t Ze i w

Do ku m en tac ja z d cza zar

Rysunek 10.3. Zamknicia

Przygotowanie

Projektu

do

10.4.3.
Podproces celu:

Opis procesu ma na

177

CLOSING A PROJECT (CP)

PRINCE2

zagwarantowanie, e wszystkie produkty projektu zostay zatwierdzone i przekazane klientowi lub u ytkownikowi; potwierdzenie, e dostarczone produkty speniaj wszelkie wymagania dotyczce dziaalnoci operacyjnej i wsparcia, zdefiniowane w specyfikacji klienta (jeli ma to zastosowanie) ; potwierdzenie, e stworzono prawidowe rodowisko eksploatacyjne i utrzymania ma (jeli to zastosowanie); potwierdzenie, e wszystkie Kryteria Akceptacji zostay spenione; skompletowanie i przechowanie wszystkich informacji dotyczcych projektu; przygotowanie zalecenia zamknicia projektu zawierajcego powiadomienie dla wszystkich zaanga owanych organizacji i zainteresowanych stron, e projekt jest gotowy do zamknicia, a urzdzenia i zasoby zwolnione. Kierownik Projektu przygotowuje tre zalecenia zamknicia projektu dla Komitetu Sterujcego po to, by zasoby projektu i usugi wsparcia mogy by zwolnione. Kierownikpowinien sprawdzi w Planie Komunikacji, czy strony zainteresowane Projektu projektem wymagaj przekazania kopii zalecenia zamknicia projektu i dziaa zgodnie z nim. Zalecenie zamknicia projektu musi by zatwierdzone przez Komitet Sterujcy. Zanim nastpi zamknicie projektu, Kierownik Projektu musi upewni si, e osignito i dostarczono wszystkie oczekiwane rezultaty (chyba, e zostanie poinformowany przez Komitet Sterujcy o przedwczesnym zamkniciu . projektu) Dla stwierdzenia, czy zatwierdzono wszystkie produkty, dokonuje si przegldu Zapisw Konfiguracji oraz przeprowadza si audyt konfiguracji. Sprawdza si w Obiektw Planie Zarzdzania Konfiguracj zasady, wedug ktrych bdzie si odbywao przekazanie produktw do u ytku. Gdy produkt musi by wspierany i utrzymywany w czasie eksploatacji, nale y uzyska potwierdzenie w formie akceptacji eksploatacyjnej i utrzymania od osb, ktre bd goyway i wspieray, e otr zymay go w stanie pozwalajcym im na wykonywanie u ich obowizkw. Kierownik Projektu musi przejrze Kryteria Akceptacji wsplnie z klientem, aby otrzy- potwierdzenie, ma e wszystkie one zostay spenione. W celu umo liwienia przyszego audytu dziaa projektu i jego osigni, caa dokumen- powinna tacja by zabezpieczona i Pociga to za sob wa ne zadanie zarchiwizowana. pozbycia si dokumentw nieu ytecznych dla tych, ktrzy mog potrzebowa dostpu do archiwum akt, jak np.: audyt, Biuro Wsparcia Projektu, przyszli Kierownicy Projektwprzygotowania modeli planistycznych) oraz dla tych, ktrzy bd pniej (w celu przeprowadzali przegld poprojektowy. Roztropnie jest, by tak selekcj dokumentw przeprowadzia grupa zo ona z Kierownika Projektu, Nadzoru Projektu oraz Wsparcia Projektu.

10.4.4.

Odpowiedzialno

Za podproces odpowiedzialno ponosi Kierownik Projektu, ktry mo e potrzebowa penicych rol Wsparcia Projektu ( w tym Bibliotekarza Konfiguracji), pomocy osb aby 17 8

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

zgromadzi niezbdne materiay. Kierownik Projektu powinien w tym czasie nieformalnie kontaktowa si z Nadzorem Projektu w celu poznania opinii na temat kompletnoci prac, aby zapewni, e nie bdzie adnych problemw z wyra eniem zgody na zamknicia projektu przez Komitet Sterujcy podczas Zatwierdzenie cia podprocesu Zamkni Projekt (ZS5). u

10.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Zawiera wykaz Kryteriw Akceptacji projektu. Wejcie Sprawdzana jest ich kompletno. Stanowi dane wejciowe do Zestawienia Statusu Produktw. Wejcie Potwierdzenie na podstawie zapisw zarzdzania konfiguracj klienta, e wszystkie produkty s zatwierdzone. Wejcie Ustalenie, w jaki sposb produkty bd przekazane do biblioteki konfiguracji tych, ktrzy bd utrzymywali produkt w czasie jego eksploatacji.

Tabela 10.1. ZP1 Informacja Objanienie

Dokument Inicjujcy Projekt Zapisy Obiektw Konfiguracji Zestawienie Statusu Produktw Plan Zarzdzania Konfiguracj

Audyt konfiguracji Wyjcie Potwierdzenie, e wszystkie produkty zostay zatwierdzone. Rejestr Zagadnie Wejcie Sprawdzenie, czy wszystkie Zagadnienia Projektowe zostay zamknite. Polecenie przedwczesnego zamknicia projektu Powiadomienie o zamykaniu projektu Wejcie Polecenie Komitetu Sterujcego zamknicia projektu przed jego oczekiwanym kocem. Wejcie Sygna pyncy z monitorowania etapu, informujcy o zbli ajcym si planowanym kocu projektu.

Plan Komunikacji Wejcie Zidentyfikowanie wszystkich zainteresowanych stron, ktre powinny by poinformowane. Akceptacja przez klienta Wyjcie Potwierdzenie, e klient akceptuje produkty. Akceptacja przez su by eksploatacji i utrzymania Zalecenie zamknicia projektu Wyjcie Potwierdzenie, e produkt mo e by eksploatowany i obsugiwany. Wyjcie Notatka przedkadana Komitetowi Sterujcemu, stwierdzajca, e projekt jest bliski zamknicia oraz e alokowany sprzt i zasoby nie bd du ej potrzebne. Nale y przejrze Plan Komunikacji w celu ustalenia wszystkich innych adresatw.

179

CLOSING A PROJECT (CP)

PRINCE2

Informacja Objanienie

zarzdcza

Wykorzystanie
Archiwum Zachowuje wa ne i u yteczne dokumenty projektu w celu przyszego wykorzystania przez audytorw lub innych zainteresowanych.

Dokumentacja zarzdcza

10.4.6.

Kryteria oceny ci jako Czy wszystkie produkty wymienione w Dokumencie Inicjujcym Projekt zostay zatwierdzone i dostarczone? Czy zespoy operacyjny i wsparcia zgodziy si formalnie, e s gotowe do zaakcep- przejcia produktw (jeli jest to towania waciwe)? Czy zasoby projektu i usugi wspierajce (jeli jakie zapewniono) nie s ju dalej potrzebne? Czy istniej projektu do zamknicia? jakiekolwiek ustalenia kontraktowe, dotyczce przygotowania

Wskazwki i rady
Nale y sprawdzi w systemie zarzdzania konfiguracj, stosowanym w projekcie do kontroli i rejestrowania statusu produktw, czy wszystkie produkty maj status zakoczone i przekazane. Tam, gdzie produkt kocowy wymaga intensywnego, potencjalnie kosztownego utrzymywania, Kierownik Projektu powinien zapewni podpisanie odpowiedniego kontraktu serwisowego pomidzy zespoem wdra ajcym a u ytkownikami kocowymi. W takich przypadkach waciwe mo e by wczenie takiego kontraktu do produktw projektu. Bdzie to prawdopodobnie oznaczao utworzenie spord czonkw grupy eksploatacyjnej maego zespou, ktry wemie udzia w kocowych etapach projektu, w ramach realizacji podpisanego kontraktu. Grupa wdro eniowa bdzie potrzebowaa penej informacji o produkcie w trakcie jego wytwarzania (patrz: Plan Komunikacji w Dodatku A Zarysy Opisw Produktw), aby zrozumie konsekwencje dla wdro enia i utrzymania produktu oraz dla jego rodowiska pracy.

10.5.
10.5.1.

Okre lenie Dziaa

Podstawowe zasady

Nast pczych (ZP2)

Jeli przy kocu projektu s jakie niezaatwione sprawy, powinny by formalnie udokumentowane i przekazane tym, ktrzy maj uprawnienia i obowizek podjcia waciwych dziaa.

18 0

PRINCE2

ZAMYKANIE PROJEKTU (ZP) Kontekst

10.5.2.

Wikszo danych wejciowych tworz pozycje z Rejestru Zagadnie, ktrych rozpatry-zostao wstrzymane przez Komitet wanie Sterujcy. Wynik jest przedkadany Komitetowi Sterujcemu jako Zalecenia Dziaa Nastpczych.
ZP2 Okre lanie Dziaa Nast pczych
Plan Prze gl du Poprojektowego Zalecenia Dziaa Nast pczych

Dokumentacja Dokumentacja zarz dcza zarz dcza

Uzasadnienie Biznesowe Rejestr Zagadnie Rejestr Ryzyka

ZS5 Zatwierdzenie Zamkni cia Projektu

Rysunek 10.4. Okrelenie Dziaa Nastpczych

10.5.3.

Opis procesu

Podproces ma na celu: sprawdzenie, czy wszystkie Zagadnienia Projektowe i zagro enia zostay zaatwione, lub przeniesione do Zalece Dziaa Nastpczych oraz ustalenie dziaa wymaga- po nych zakoczeniu projektu; udokumentowanie wszelkich Zalece Dziaa Nastpczych; zalecenie terminu i przygotowanie planu dla przegldu lub przegldw poprojektowych uznanych za konieczne. Po zakoczeniu projektu mo e by niezbdne wykonanie pewnej liczby dziaa. Infor- wejciowe bd pochodziy gwnie z tych Zagadnie Projektowych, ktre macje zyskay odroczone, nadany przez Komitet Sterujcy w czasie trwania projektu. status Rejestr mo e zawiera zagro enia, ktre mog wpywa na produkt w czasie jego u Ryzyka ytkowania. Wszelkie niezakoczone prace s dokumentowane w Zaleceniach Dziaa Nastpczych. Wiele produktw projektu powinno by ponownie zbadanych po pewnym okresie u ywania, aby sprawdzi ich jako, efektywno u ytkowania i osignicie korzyci. Sprawdzenie uaktualnionego Uzasadnienia Biznesowego pozwoli na stwierdzenie, czy istniej jakie oczekiwane korzyci biznesowe, ktrych osignicie nie mo e by zmie- zanim produkt nie bdzie u ytkowany przez pewien czas. Je eli tak jest, nale rzone yporzdzi plan dla przegldu poprojektowego, zaproponowa jego termin oraz ok s reli korzyci, ktre maj by w tym czasie zmierzone, jak rwnie pomiary, ktre maj by przeprowadzone. Korzyci te powinny by wczeniej okrelone w Uzasadnieniu Biznesowym.

181

CLOSING A PROJECT (CP)

PRINCE2

Przegld poprojektowy nie jest dziaaniem projektowym, natomiast jest nim stworzenie jego planu. W skrcie, przegld poprojektowy ma oceni osignicie korzyci 20 zadeklarowanych w Uzasadnieniu Biznesowym. Poni sze pytania s : przykadowymi W jakim stopniu pr odukt osign oczekiwane korzyci biznesowe? Czy istnieje identyfikowalny trend wzrostu korzyci biznesowych? Czy u ytkownicy s zadowoleni z produktu? Czy produkt udowadnia, e spenia oczekiwania jakociowe? Czy produkt jest tak dobrze obsugiwany, jak to byo oczekiwane? Czy pracownicy odpowiedzialni za wspieranie produktu s zadowoleni z tego, co otrzymali od projektu w celu pomocy w utrzymaniu produktu? Czy w trakcie wdra ania zaistniay jakie nieoczekiwane problemy? Czy produkt spowodowa nowe problemy? Plan Przegldu Poprojektowego bdzie wykorzystywa informacje zawarte w Uzasadnieniu Biznesowym (patrz: Dodatek Zarysy Opisw ). Powinien wskazywa, A jaki sposb ma by mierzone osignicie korzyci biznesowych. Plan ten Produktw w powinien okreli: korzyci biznesowe, ktrych osignicie ma by mierzone; czas, w ktrym mo e by zmierzone ich osignicie; sposb, w jaki ich osignicie mo e by zmierzone; sytuacj panujc przed dostaw, z ktr osignite korzyci bd porwnane; kto jest potrzebny do przeprowadzenia pomiarw (osoby lub rodzaje umiejtnoci). Odpowiedzialno za ponosi Kierownik

10.5.4.

Odpowiedzialno Projektu.

podproces

20

Dla takiej oceny przypis tumacza.

18 2

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

10.5.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 10.2. ZP2 Informacja Objanienie

Rejestr Zagadnie Wejcie Niezaatwione Zagadnienia Projektowe bd stanowiy podstaw dla sformuowania Zalece Dziaa Nastpczych. Uzasadnienie Biznesowe Wejcie Wska e korzyci biznesowe, ktrych osignicie nie mo e by natychmiast zmierzone, i dlatego bdzie potrzebny przegld poprojektowy.

Rejestr Ryzyka Wejcie Sprawdzenie wszelkich zagro e dla operacyjnego wykorzystania produktu(-w) kocowego(-ych). Plan Przegldu Poprojektowego Zalecenia Dziaa Nastpczych Wyjcie Sugerowany plan dla przegldu poprojektowego do zatwierdzenia przez Komitet Sterujcy. Wyjcie Zalecenia dotyczce dalszych prac, ktre Komitet Sterujcy musi skierowa pod uwag odpowiednich osb.

10.5.6.

Kryt eria oceny ci jako Czy przegld poprojektowy jest potrzebny, by zmierzy osignicie korzyci bizne- i ponownie zbada jako produktw po pewnym okresie ich u sowych ywania? Ile czasu musi upyn zanim te korzyci biznesowe mog by zmierzone? Czy korzyci biznesowe uzyskiwane z projektu s autonomiczne, czy te poczone z rezultatami innych projektw? Ktre z Zagadnie Projektowych o statusie odroczone powinny by zalecone jako dziaania nastpcze dla zespou eksploatacji i utrzy mania? Dla ktrych z Zagadnie Projektowych o statusie odroczone nale y zaleci przeksztacenie ich w Zlecenia Przygotowania Projektu dla potencjalnych projektw podnoszcych warto produktu lub przekazanie ich kierownictwu programu w celu nadania im dalszego biegu?

Wskazwki i rady
Propozycje dotyczce przegldu poprojektowego powinny by nieformalnie przedyskutowane z Komitetem Sterujcym zanim sporzdzi si jakiekolwiek zalecenie, po to, by unikn wszelkich nieporozumie w nastpnym podprocesie - Zatwierdzenie Zamknicia Projektu (ZS5) .

183

CLOSING A PROJECT (CP)

Termin przegldu poprojektowego powinien by ustalony tak wczenie po zamkniciu projektu, jak tylko mo liwe bdzie dokonanie odpowiedniej oceny. Jako produktu moga si wydawa dobra podczas testowania, ale czy jest dalej dobra po pewnym okresie przebywania w rodowisku pracy? Ponadto tam, gdzie na pojawienie si pewnych korzyci trzeba czeka znacznie du ej, warto rozwa y zalecenie Komitetowi Sterujcemu, by byy to tematy innych, pniejszych przegldw poprojektowych. W zale noci od rodzaju produktu mog istnie zagadnienia zwizane z kontraktem do rozwizania dla eksploatacji i utrzymania produktw. Kopia zalecanych dziaa nastpczych zawsze powinna by przekazana do wiadomoci grupie wsparcia operacyjnego. Jeli projekt jest czci programu, zalecenie zamknicia projektu wydane przez Komitet Sterujcy powinno zosta poddane przegldowi przez kierownictwo programu w wietle listy wymaganych dziaa nastpczych. Jeli projekt jest czci programu, dziaania nastpcze powinny by przydzielone przez kierownictwo programu tam, gdzie jest to waciwe.

PRINCE2

10.6.
10.6.1.

Przegl d Oceniaj cy Projekt (ZP3)

Podstawowe zasady

Organizacje odnoszce sukcesy ucz si na swoich dowiadczeniach z projektw. Jest to bardziej prawdopodobne, jeli dowiadczenia te w jaki sposb s zachowywane po zakoczeniu projektu.

10.6.2.

Kontekst

Jest to wewntrzna ocena projektu. Jej celem jest ocena, jak du ym sukcesem czy te po- k zakoczy si projekt, a nie jak udany jest kocowy produkt. Mo na ra przeprowadzi oddzieln, zewntrzn ocen projektu, na przykad przez zesp nadzoru jakoci.
U za s adn ie ni e B i zne s owe umen t I ni cj u c y P r oj ek t D ok j a n J ak c i Pr oj ek t u Pl o ej e s tr Dow i ad cz e R R ej e s tr Ry z yk a R ej e s tr Ja k oci R ej e s tr Zag ad ni e zi e nni D k pi sy Obi e k tw K o nfi gur a Za cj i

Dokumentacja Dokumentacja zarz dcza zarz dcza

Pl a n Pr oj e k tu

ZP3 Przegl d Oceniaj cy Projekt

R a por t K c ow y P roj e k tu o R a por t o D wi a dc ze ni ac o h

ZS5 Zatwierdzenie Zamkni cia Projektu

Rysunek 10.5. Projekt

Przegld Oceniajcy

18 4

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

Wszelkie komentarze zgromadzone w czasie projektu w Rejestrze Dowiadcze s przetwarzane w Raport o Dowiadczeniach. Rejestr jest zakadany na pocztku projektu i uzupeniany w miar postpu prac projektowych o obserwacje, ktre warto zanotowa w celu pomocy przyszym projektom. Powinien on zawiera spostrze enia o zarzdzaniu, oraz specjalistycznych i dotyczcych jakoci, procedurach, produktach i technikach. Podobnie jak poprzednio, rezultaty s przekazywane do podprocesu Komitetu Sterujcego - Zatwierdzenie cia (ZS5) . Zamkni Projektu

10.6.3.

Opis procesu

Podproces ma na celu: uaktualnienie Planu Projektu faktycznymi danymi z etapu kocowego; ocen wynikw projektu w zestawieniu z tym, co zamierzano osign; zbadanie dokumentacji zakoczonego projektu w celu oceny jakoci zarzdzania szczeglnoci zarzdzania jakoci i nim, a w ryzykiem; zidentyfikowanie dowiadcze, ktre wynikaj z projektu i bd wykorzystane przyszych w projektach. Raport Ko cowy Projektu Uaktualniony Plan Projektu pozwala Kierownikowi Projektu na udokumentowanie w Raporcie Kocowym Projektu, jak dobrze przebieg projekt w odniesieniu do Dokumentu Projekt, cznie z pierwotnie planowanymi kosztami, harmonogramem i Inicjujcego tolerancjami . Nie wszystkie korzyci biznesowe zostan osignite do czasu zamknicia projektu. osignicia lub braki, jeli mog by okrelone, powinny zosta Wszelkie wprowadzone Kocowego Projektu. Notatka o korzyciach biznesowych, ktre do Raportu powinny by zmierzone po pewnym czasie operacyjnego wykorzystywania produktu kocowego, jest przekazywana do Okr lenie Nas pczyc (ZP2) w celu wczepodprocesu e Dziaa t h nia do Planu Przegldu Poprojektowego. Raport powinien tak e uwzgldnia wpyw wszelkich zatwierdzonych zmian na pierwot- Projektu i Uzasadnienie Biznesowe. Raport Kocowy Projektu powinien ny Plan zawiera ostateczne dane liczbowe dotyczce zmian dokonanych w trakcie trwania projektu oraz obrazowa cakowity wpyw zatwierdzonych zmian. Wszystkie niezaatwione zmiany powinny by skojarzone z dziaaniami nastpczymi przygotowanymi w podpr ocesie lenie Okr Nas pczyc (ZP2) . Waciwe mo e by tak e podanie danych e Dziaa t h liczbowych o wszystkich wykonanych pracach dotyczcych jakoci. Raport Kocowy Projektu opisuje, w jakim stopniu projekt osign lub - w przypadku przedwczesnego zamknicia - nie osign stawianych przed nim celw. W odr nieniu od niego, Raport o Dowiadczeniach koncentruje si na tym, jak dobrze projekt by zarzdzany oraz jak w projekcie wykorzystano procesy zarzdcze i techniki, tj. PRINCE2, u yte lokalne standardy, a tak e czego si mo na nauczy z tego wdro oraz inne enia. Raport ten bdzie zatwierdzony przez Komitet Sterujcy i przekazany zainteresowanym stronom w ramach Zatwierdzenie cia (ZS5) . podprocesu Zamkni Projektu

185

CLOSING A PROJECT (CP) Raport o Do wiadczeniach

PRINCE2

Rejestr Dowiadcze powinien by utworzony na pocztku projektu. Wpis do rejestru powinien nastpi, gdy zesp zarzdzania projektem zauwa y co, co dotyczy procesw zarzdczych lub specjalistycznych, produktw, technik lub procedur, co albo miao zna- wkad w osignicia projektu, albo spowodowao problem. Dotyczy to czcy osigni caego zespou zarzdzania projektem, powodzenia w skalowaniu, u ycia procesw specjalistycznych oraz ich modelowania i adaptacji, sterowania zmianami oraz wynikw dziedzinie w jakoci. W tym podprocesie powinny zosta zebrane wszystkie notatki i przeksztacone w Raport o Dowiadczeniach, wczajc w to wszelkie spostrze enia z perspektywy czasu, doty- zarzdzania projektem. Celem ma by odpowied na pytanie: Co powinno czce by zrobione inaczej nastpnym razem? Na kocu projektu - w ramach Przygoto procesu Projektu wanie do ci (ZP1) powinien by przeprowadzony audyt Zamkni a konfiguracji, w celu ujawnienia rozbie noci. Stwierdzenie przyczyny powstania odchyle mo e zasadni u dokonanie wpisu do Raportu o Dowiadczeniach. Raport ten jest rwnie repozytorium (zbiorem) wszelkich zebranych w czasie trwania u ytecznych miar i danych liczbowych dotyczcych jakoci, ktre projektu pomog w planowaniu i szacowaniu nastpnych projektw. Istotne jest ustalenie na pocztku projektu, kto powinien otr zyma Raport o Dowiadczeniach i upewni si, e Komitet Sterujcy wie, do kogo powinien on trafi. Nie ma zbyt- sensu przygotowywaniu Raportu o Dowiadczeniach jeli wiadomo, e nie niego b- on wykorzystywany. dzie W razie przedwczesnego zamknicia projektu powody takiego stanu rzeczy powinny zosta udokumentowane w Raporcie o Dowiadczeniach, koncentrujc si na wszelkich przykadach niezastosowania metodyki, bdach w stosowaniu narzdzi specjalistycznych i technik albo personelu, czyli na tym, co spowodowao lub przyczynio si do przedwczesnego zamknicia projektu. Jeli jednak przedwczesne zamknicie zostao spowo- prawidowym u yciem metodyki PRINCE2, np. ujawnieniem, e dalsze dowane prowa- projektu nie ma sensu biznesowego lub e mo e doprowadzi do dzenie przekroczenia tolerancji projektu, powinno to tak e zosta udokumentowane.

10.6.4.

Odpowiedzialno

Projektu, ale

Za podproces cakowit odpowiedzialno ponosi Kierownik dodatkowe mog pochodzi od ka dego, kogo projekt informacje dotyczy.

10.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Pierwotne przedstawienie celw projektu, zakresu i ogranicze.

Tabela 10.3. ZP3 Informacja Objanienie

Dokument Inicjujcy Projekt

18 6

PRINCE2

ZAMYKANIE PROJEKTU (ZP)

Informacja Objanienie

zarzdcza

Wykorzystanie

Rejestr Zagadnie Wejcie Powody Odstpstw mog stanowi lekcj dla przyszych projektw. Rejestr Ryzyka Wejcie Zagro enia, ktre byy brane pod uwag, i to, co si z nimi stao, mog stanowi lekcj dla przyszych projektw. Plan Jakoci Projektu Wejcie Wska e, czy polityka jakoci i procedury byy odpowiednie i poprawnie przedstawione. Rejestr Jakoci Wejcie Dane statystyczne o liczbie wykonanych kontroli jakoci i znalezionych bdach s u yteczne dla funkcji nadzoru jakoci. Zapisy Obiektw Konfiguracji Wejcie Czy istniej jakiekolwiek rozbie noci midzy zapisami a rzeczywistoci? Mog one wskaza jak postpowa z produktami w przysoci.

Rejestr Dowiadcze Wejcie Dokument istniejcy od pocztku projektu, uzupeniany stosownymi wpisami dobrych i zych dowiadcze zdobytych na temat zarzdzania i procedur specjalistycznych, formularzy, innych dokumentw, narzdzi i technik. Plan Projektu Aktualizacja Aktualizowany w oparciu o dane etapu kocowego. Powinien zosta przejrzany przy opracowywaniu Raportu Kocowego Projektu. Mo e rwnie przyda si przy opracowaniu Raportu o Dowiadczeniach. Dziennik Wejcie Mo e zawiera u yteczne informacje, do przeanalizowania w trakcie opracowywania Raportu Kocowego Projektu lub Raportu o Dowiadczeniach. Uzasadnienie Biznesowe Raport o Dowiadczeniach Wejcie Wszelkie osignite ju korzyci powinny znale odbicie w raporcie. Wyjcie Na podstawie Rejestru Dowiadcze opracowuje si raport, ktry bdzie przekazany przez Komitet Sterujcy gremium odpowiedzialnemu za utrzymywanie standardw jakoci. Wyjcie Ocena stopnia, w jakim osignito cele okrelone w Dokumencie Inicjujcym Projekt, a tak e ocena rezultatw zarzdczych projektu.

Raport Kocowy Projektu

10.6.6.

Kryt jako

eria

oceny

ci

Ktre procesy lub procedury zarzdcze funkcjonoway dobrze? W ktrych procesach zarzdczych wystpiy problemy? Czy osignicie wymaganej jakoci byo atwe?

187

CLOSING A PROJECT (CP)

PRINCE2

Ktre procedury dotyczce jakoci funkcjonoway dobrze? Czy byy jakie saboci w procedurach jakoci dla konkretnych rodzajw produktw? Jak dobrze funkcjonoway strategie dotyczce ryzykiem? Czy wystpiy jakie nieprzewidziane zagro enia? Jak dobrze zarzdzano ryzykiem? Czy wykorzystano rezerw? zarzdzania

Czy szkolenia w zakresie zarzdzania, jakoci oraz procesw i procedur dostaw byy odpowiednie? Czy wystpiy rozpoznawalne korzyci, wynikajce z poziomu przeprowadzonych szkole, lub rozpoznawalne problemy, spowodowane brakiem szkole? Jak dobrze funkcjonoway narzdzia wspierajce? Czy mo na byo co zrobi, aby udoskonali poziomy umiejtnoci, zanim waciwa wykonana? praca zostaa Czy jeli zaistniao odchylenie od Dokumentu Inicjujcego to Ko mitet Projekt,jest nadal gotowy zaakceptowa zamknicie rujcy Czy Ste- odchylenia projektu? w Raporcie Kocowym Pr ojektu i Raporcie o Dowiadczeniach? Czy maj odbicie jakie odchylenia znalazy odbicie w Zaleceniach Dziaa Nastpczych - jeli jest to wskazane?

Wskazwki i rady
Nale y skoncentrowa si na kwestiach, ktre mog by wykorzystane w przyszych projektach. Obserwacje dotyczce pozytywnych elementw mog by rwnie u yteczne jak identyfikacja bdw i przeocze. Powinno si, na tyle, na ile jest to sensowne, unika powtarzania zapisu odchyle w Raporcie Kocowym Projektu, Raporcie o Dowiadczeniach oraz Zaleceniach Dziaa Nastpczych tzn. te same odchylenia nie powinny by rejestrowane w kilku miejscach. Nale y rozwa y, czy istniej jakiekolwiek dowiadczenia, dotyczce procedur jakociowych, ktre powinny by przekazane pracownikom nadzoru jakoci. Mog to by saboci w aktualnych standardowych praktykach, nowe wymagania dotyczce testowania jakoci produktw projektu, ktre aktualnie nie s objte standardami lub nowe sposoby . testowania jakoci, ktre zostay w projekcie pioniersko zastosowane Jeli projekt jest czci programu, biuro wsparcia programu powinno dokona przegldu Raportu o Dowiadczeniach pod ktem wykorzystania go w programie lub poszczeglnych projektach programu. Istnieje wielu mo liwych odbiorcw Raportu o Dowiadczeniach. Celem jest identyfikacja grupy, ktra bdzie dystrybuowa raport do innych projektw, nie tylko bie cych, ale rwnie wszelkich innych, ktre mog by rozpoczte w przyszoci. Najlepiej by bya to grupa, ktra jest odpowiedzialna za utrzymywanie standardw zarzdzania projektami. Niektre organizacje posiadaj biuro zarzdzania projektami, inne czyni z tego cz obowizkw grupy nadzoru jakoci. Gdzie indziej mo e to by okrelane jako su by zarzdzania lub centralne Biuro Wsparcia Projektw.

18 8

11.
Wybranie narz dzi planistycznych i metod szacowania

P LA NOWAN IE (P L)
(PLANNING - PL)

Identyfikowanie produktw

Okre lanie zale no pomi dzy produktami

ci

Okre lanie dziaa

Szacowanie pracochonno ci

Budowanie harmonogramu

Ocenianie zagro e

Przygotowanie opisu planu

Rysunek 11.1. Planowanie

Oglny

zarys

procesu

11.1.

Podstawowe zasady

Skuteczne zarzdzanie projektami opiera si na efektywnych pr ocesach planowania i sterowania. Nawet mae projekty wymagaj planowania. Planowanie dostarcza caemu personelowi zaanga owanemu w projekt informacji o tym: co jest wymagane; w jaki sposb zostanie to osignite i przez kogo, z u yciem jakiego specjalistycznego sprztu i zasobw; kiedy to si wydarzy. Proces Planowani (PL) wykorzystuje technik Planowanie oparte na produktach, e n w Rozdziale 22.opisa- to kluczowa technika PRINCE2 i stanowi wszechstronn Jest pod- efektywnego planowania. Technika ta umo liwia Kierownikowi staw Projektu: 18 9

PLANNING (PL)

PRINCE

zdefiniowanie, co projekt musi dostarczy; zapewnienie opisw wymaganych produktw, umiejtnoci potrzebnych do ich wytworzenia oraz wymiernego okrelenia wymaganej jakoci i sposobu sprawdzenia jej osignicia ; obiektywne monitorowanie i kontrolowanie postpw.

11.2.

Kontekst
procesem i odgrywa wa n rol w innych

Planowanie jest powtarzalnym podprocesach, z ktrych gwnymi s:

Planowanie Etapu (PP6); Inicjowania Planowanie (IP2); Projektu Planowanie (ZE1); Etapu Uaktualnienie Planu (ZE2); Projektu Przyjmowani Grupy Zada do (WP1); e Wykonania Opracowanie Planu (ZE6). Nadzwyczajnego Planowanie jest tak e procesem iteracyjnym. W toku planowania bdzie istniaa caa se- ptli przechodzcych przez kroki planowania, w miar jak pojawiaj si ria dodatkowe informacje lub wprowadzane s poprawki.
PP6 Planowanie Etapu Inicjowania

PL Planowanie
PL1 Projektowanie Planu PL2 Okre lenie i Analizowanie Produktw PL3 Okre lenie Dziaa i Wspzale no ci PL4 Szacowanie

IP2 Planowanie Projektu

Powtarza je li trzeba
PL7 PL6 Analizowanie Zagro e PL5 Harmonogramowanie

ZE1 Planowanie Etapu

Kompletowanie Planu

WP1 Przyjmowanie Grupy Zada do Wykonania

ZE2 Uaktualnienie Planu Projektu

ZE6 Opracowanie Planu Nadzwyczajnego

Rysunek 11.2. Planowanie

19 0

PRINCE2

PLANOWANIE(PL)

11.3.

Opis procesu

Za opracowywaniem planw w PRINCE2 stoj nastpujce zasady: plany s konstr uowane poprzez identyfikacj wymaganych produktw, a nastpnie i odpowiednich zasobw koniecznych do ich dziaa dostarczenia; plany powinny obejmowa zarwno potrzeby zarzdcze, jak rwnie produkty klienta; potrzebna jest pewno, e wszystkie dziaania s wczeniej dokadnie przemylane zgodnym z wymaganiami sterowania okrelonymi w Dokumencie i to w stopniu Inicjujcym Pr ojekt. Technika Planowanie oparte na produktach zapewnia pocztek pracom planistycznym i okrela struktur planowania. Obejmuje ona: ustalenie, ktre produkty s potrzebne w tym planie; opisanie tych produktw i ich kryteriw jakoci; ustalenie kolejnoci, w ktrej ka dy z produktw powinien by wytworzony, oraz wszelkich zale noci. Po tych wstpnych krokach, kolejnymi s: identyfikacja dziaa niezbdnych do wytworzenia produktw; podjcie decyzji, kiedy dziaania powinny zosta wykonane i przez kogo; oszacowanie, jak du e nakady pracy zu yje ka de z dziaa; oszacowanie, jak dugo te dziaania bd trway; uzgodnienie, jakie dziaania i zasoby s potrzebne do kontroli jakoci; opracowanie harmonogramu dziaa obrazujcego zale noci czasowe; obliczenie, jakie bd koszty cakowitych nakadw pracy; opracowanie bud etu na podstawie kosztw nakadw pracy powikszonych o koszt wszelkich materiaw i sprztu, ktre trzeba pozyska; oszacowanie zagro e zawartych w samym planie; wskazanie potrzebnych zarzdczych punktw kontrolnych; uzgodnienie wartoci tolerancji dla planu. Kroki, ktre trzeba wykona, s jednakowe dla wszystkich poziomw planu. Zwykle potrzebnych jest kilka iteracji Planowani (PL). procesu e Formua Realizacji Projektu jest warunkiem wstpnym planowania. Powinna ona by okrelona jako cz Przygotowania (PP). Projektu

191

PLANNING (PL)

PRINCE

11.3.1.

Skalowalno

Planowanie jest dziaalnoci podstawow, niezale nie od typu i rozmiaru projektu. Po- szczegowoci zmienia si w zale noci od potrzeb ziom projektu. Lista Kontrolna Produktw jest opcjonalna w projekcie. Dla Komitetu Sterujcego mo e na stanowi dogodniejsze ni wykres Gantta narzdzie, do przegldania postpw o pro- Mo e rwnie by objanieniem informacji zawartych na wykresie jektu. Gantta. Pierwszy z podprocesw Projektowanie (PL1) wykonuje si w projekcie tylko jeden raz. Jeli projekt Planu czci programu, wszystkie decyzje dotyczce jest opracowania planu bd prawdopodobnie podjte na poziomie W maym projekcie mo programu.kwesti zdecydowania o wyborze narzdzia planistycznego (jeli jakie e by to bdzie u yte).

Wskazwki i rady
Plany powinny by u yteczne. Majc wiadomo, kto bdzie odbiorc przygotowanego zestawu planw, trzeba odpowiednio do tego zapewni waciwy poziom ich szczegowoci. Nale y zarezerwowa czas na planowanie, gdy jest to zadanie czasochonne. Planowanie nastpnego etapu powinno si zaczyna pod koniec bie cego etapu. Planowanie krtkich etapw jest atwiejsze i dokadniejsze ni dugich. Wczeniejsze Raporty o Dowiadczeniach s doskonaym rdem informacji i przewodnikiem planowania na wszystkich poziomach, powinno si je wykorzystywa tam, gdzie jest to waciwe. Jeli projekt jest czci programu, personel programu powinien by anga owany w planowanie lub nale y zasiga jego opinii w trakcie planowania, aby zagwarantowa, e wszelkie problemy, ktre maj wpyw na program, znajd rozwizanie. Pomo e to unikn poprawiania planu po jego zaprezentowaniu. Nale y anga owa osoby penice rol Nadzoru Projektu w proponowanie zasobw do kontroli jakoci. Powinno to dotyczy zarwno Planw Zespow, jak i Planw Etapw .

11.4.
11.4.1.

Projektowanie Planu (PL1)

Podstawowe zasady

Plan jest rdzeniem ka dego projektu i jest niezbdny do osignicia jego pomylnego rezultatu. Dobre plany obejmuj wszelkie aspekty projektu, dajc wszystkim, ktrych doty- wsplne zrozumienie prac do cz, wykonania. Projektowanie planu powinno zapewni odpowiednie ujcie wszystkich aspektw projek- ne jest, aby wszyscy zainteresowani mogli atwo zrozumie tu. Wa plan. 19 2

PRINCE2

PLANOWANIE(PL) Kontekst

11.4.2.

Podproces zawiera decyzje o podejciu do planowania i dlatego musi by zastosowany wczenie. Decyzje te musz zosta podjte, zanim bd realizowane w projekcie inne podprocesy procesu Planowani (PL). e W trakcie przedkadania planu do akceptacji, mo e by uzasadnione stosowanie jednego planu dla prezentacji, a bardziej szczegowego formatu dla celw bie cego formatu sterowania. Strategie postpowania z projektem i zapewniania jakoci produktw zostay ju zdefiniowane w podprocesach Okr lenie Formuy Realizacji (PP5) i Planowani e Projektu e Jak (IP1). c o i

11.4.3.

Opis procesu

Nale y dokona wyboru ukadu i sposobu prezentacji planu, narzdzi planowania, metod szacowania, poziomw planu oraz metod monitorowania, ktre maj by u yte w projek- y okreli wszelkich odbiorcw planw i ich uaktualnie. Mo e istnie komr cie. Nale - a na wy szym szczeblu organizacji, ktra konsoliduje wszystkie plany dla k naczelnego kierownictwa, szczeglnie jeli projekt jest czci programu. Ukad i prezentacja Nale y podj decyzj, jak najlepiej zaprezentowa plan okrelonemu audytorium i jak bdzie wykorzystywany. Obejmie to korzystanie z wykresw zamiast opisw on teksto- i bdzie czciowo podporzdkowane standar dom przyjtym w wych projekcie. Narz dzia planistyczne Jedn z pierwszych decyzji jest zidentyfikowanie wszelkich pomocy, dotyczcych planowania i kontroli, ktre maj by zastosowane w projekcie. W organizacji mo e istnie odpowiedni standard lub klient mo e sobie zastrzec stosowanie konkretnego zestawu narzdzi. Wybr narzdzia planowania mo e zale e od stopnia zo onoci projektu. Ww- wybr taki mo e zosta odo ony do czasu realizacji niektrych innych czas procesw planowania. Szacowanie Nale y wybra metod lub metody Ka dy aspekt projektu mo e szacowania. wymaga by wykonane z swojej wasnej metody szacowania. Szacowanie mo e wykorzystaniem: narzdzi informatycznych; grupy dowiadczonych planistw; metod planowania od ogu do szczegu lub od szczegu do ogu; dyskusji z tymi, ktrzy bd wykonywali prac; dowolnej kombinacji wy ej wymienionych sposobw.

193

PLANNING (PL)

PRINCE

Wybrane metody szacowania powinny podlega ocenie, a komentarze na temat ich efektywnoci zamieszcza si na zakoczenie projektu w Raporcie Kocowym Projektu oraz w Raporcie o Dowiadczeniach. Metody szacowania, ktre zastosuje si w planie, mog wpyn na jego konstrukcj, tak decyzje o nich powinny by podjte jako cz projektowania wic planu. Rezerwy Istniej dwie formy rezerw, ktre mo na rozwa y pod ktem ich wczenia do struktury planu projektu bud et zmian i bud et rezerwowy. Nie s one obowizkowe, a ich zastosowanie zale y od okolicznoci.

11.4.4.

Odpowiedzialno

Komitet Sterujcy jest ostatecznie odpowiedzialny za decyzje dotyczce konstr uowania planu, ale w pr aktyce Kierownik Projektu mo e opracowa zalecenia do nieformalnego zatwierdzenia przez Komitet Lokalne standardy mog wzi gr nad Sterujcy. a gdy s zaanga owane str tymi trzecie, oczekuje si zwykle, e decyzjami, ony Kierownicy zastosuj swoje wasne standardy. Osoby penice rol Nadzoru Projektu Zespow maj obowizek sprawdzenia konstrukcji planu.

11.4.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Formua mo e mie wpyw na liczb etapw i wymaganych poziomw planu.

Tabela 11.1. PL1 Informacja Objanienie

Formua Realizacji Projektu

Plan Jakoci Projektu Wejcie Plan Jakoci Projektu bdzie mie wpyw na zawarto planw, poziom szczegowoci oraz potrzeby dotyczce monitorowania. Standardy planistyczne firmy lub programu Zao enia Projektu (lub Dokument Inicjujcy Projekt) Wejcie Mog okrela narzdzia planowania i szacowania oraz metody, ktre maj by zastosowane. Wejcie Zakres prac, ktre maj by zaplanowane.

Konstrukcja planu Wyjcie Przedstawienie podejcia planistycznego, poziomw planu, zestawu narzdzi, ktre maj by zastosowane, oraz gwnych metod monitorowania.

11.4.6.

Kryteria oceny ci jako Jakie metody planowania, szacowania, monitorowania oraz oceny ryzyka bd zastosowane? Jaki zestaw narzdzi powinien zosta zastosowany, aby pomc w planowaniu, szacowaniu, monitorowaniu i ocenie ryzyka?

19 4

PRINCE2

PLANOWANIE(PL)

Jaki stopie szczegowoci dotyczcy produktw, ich tworzenia, kontroli jakoci i monitorowania planu potrzebny jest Kierownikowi Projektu do bie cej kontroli? Jakiego stopnia szczegowoci potrzebuje Komitet Sterujcy: przed zaanga owaniem si w realizacj planu; do monitorowania postpw w stosunku do planu? Ile poziomw planu jest waciwych dla tego projektu? Jaki poziom szczegowoci powinien reprezentowa ka dy z planw? Jak na planach bd uwidocznione wszelkie kontrole jakoci? W jaki sposb zostan przypisane tolerancje? Czy powinien istnie bud et zmian? Jaki poziom produktywnoci powinien by przyjty dla czonkw zespow? W jaki sposb bd przydzielane rezerwy (jeli jest to waciwe)?

Wskazwki i rady
Mo na zmarnowa wiele czasu na opracowywanie bardzo dobrego planu, by osign niewaciwy cel. Stosowanie narzdzi planistycznych nie jest obowizkowe, ale mo e oszczdzi du o czasu, jeli plan ma by regularnie uaktualniany i zmieniany. Dobre narzdzie mo e take su y do potwierdzenia, e wbudowano prawidowe zale noci oraz e nie zostay one zniszczone przez adne uaktualnienia planu. Kierownik Projektu powinien zdecydowa, jaki poziom wydajnoci ma by przyjty dla czonkw zespou projektowego podczas planowania ich pracy. Nikt nie jest w stu procentach wydajny. Szacujcy musi wiedzie, jak potraktowa czas nieplanowany typu rozmowy telefoniczne, nieplanowane narady czy choroby. Uwaga na podwjne liczenie np. dodawanie rezerwy zarwno w czasie szacowania, jak i w czasie harmonogramowania. Mo e by uzasadnione rozwa enie stosowania odmiennych prezentacji planu dla odbiorcw z r nych poziomw. Wikszo pakietw oprogramowania planistycznego oferuje takie mo liwoci. Jeli w projekcie wystpuj podwykonawcy, kopie ich planw mog stanowi cz cakowitego planu. Nale y podj decyzj, czy plany podwykonawcw bd przedstawiane oddzielnie, czy te bd wbudowane w Plan Projektu i/lub Plany Etapw. Nie wszystkie projekty potrzebuj 45-stronicowego planu, ale p kartki papieru rwnie bdzie niewystarczajce dla wikszoci Planw Projektu. Jeli projekt jest czci programu, program mg opracowa jednolite podejcie do planowania projektw. Mo e ono obj standardy (np. dla poziomu planowania) oraz narzdzia. Bdzie to punkt wyjcia do projektowania Planu Projektu. Jakiekolwiek zmiany specyficzne dla projektu powinny zosta uwypuklone i uzyska akceptacj zarzdzajcych programem.

195

PLANNING (PL)

PRINCE

11.5.
11.5.1.

Okre lenie i Analizowanie Produktw (PL2)

Podstawowe zasady

Okrelajc plan w kategoriach produktw, ktre maj by dostarczone, mo na atwiej zarzdza i kontrolowa wytwarzanie, jako oraz przydatno tych produktw. Dodat- poprzez opisanie wymaganych produktw ka dy, kogo to dotyczy, mo e kowo, zobaczy i zrozumie po dany rezultat.

11.5.2.

Kontekst

Jeli w Projektowanie (PL1) podjto decyzj o podejciu do podprocesie Planu konstrukcji planu, omawiany w tym rozdziale podproces jest zazwyczaj punktem wyjcia do opra- planu. cowania

11.5.3.

Opis procesu

Podproces jest podzielony na trzy kroki: zidentyfikowa produkty specjalistyczne i produkty zarzdcze, ktre maj by wytworzone; opisa ka dy z nich w kategoriach wymaga jakociowych oraz zapewni, eby byy w peni zrozumiane i uzgodnione przez wszystkich zainteresowanych one ( wymaga to utworzenia niezbdnych Zapisw Obiektw ; Konfiguracji) uporzdkowa produkty w logicznym porzdku ich wytwarzania. Kroki te opisane s szczegowo w Rozdziale 22 Planowanie oparte na produktach Lista Kontrolna Produktw W oparciu o informacj pochodzc z Diagramu Struktury Produktw mo na sporzdzi Kontrolnej Produktw. W Dodatku A przedstawiono Opis Produktu dla szkic Listy Listy Kontrolnej Produktw. Jest to tabela, ukazujca wszystkie produkty ujte w planie, z miejscami na wpisanie planowanych i rzeczywistych terminw, w ktrych ka dy z nich kluczowe stadia w okresie swojego wytwarzania, takie jak: Gotowy osiga projekt produktu, Przeprowadzona kontrola jakoci czy Produkt zatwierdzony. wstpny To tylko przykadowe zdarzenia w yciu produktu, ktre mog r ni si w zale noci od potrzeb projektu. Planowane terminy osignicia tych stadiw s uzupeniane pod koniec Plano procesu wani (PL) - po ustaleniu harmonogramu oraz uwzgldnieniu dziaa zwizanych z e kiem. ryzyKierownik Projektu wpisuje nastpnie rzeczywiste terminy, w ktrych okreloneproduktu zostao osignite, co mo e stanowi u yteczne uzupenienie stadium Raportu Okresowego. Zastosowanie opcjonalne. Listy Kontrolnej Produktw w projekcie jest

19 6

PRINCE2

PLANOWANIE(PL) Odpowiedzialno

11.5.4.

W odniesieniu do Planu Projektu i Planw Etapw, za realizacj tego podprocesu odpowiedzialny jest Kierownik Projektu. Kierownicy Zespow mog opracowywa Plany Zespow w celu uzgodnienia ich z Kierownikiem Projektu. Nale y przeprowadzi konsultacje z klientem, u ytkownikiem (u oraz specjalistami w celu ytkownikami) zapewnienia, e uwzgldniono wszystkie wymagane produkty. Osoby penice obowizki Nad- Projektu powinny zweryfikowa rezultaty. Bibliotekarz Konfiguracji jest zoru odpowie- za wytworzenie Zapisw Obiektw Konfiguracji dla wszystkich dzialny potrzebnychwedug wymogw Planu Zarzdzania Konfiguracj. produktw,

11.5.5.
Tabela 11.2. PL2 Informacja Objanienie

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Konstrukcja planu Wejcie Definiuje poziom wymaganego planu, narzdzia i techniki szacowania, ktre maj by u yte, oraz podejcie do zmian i przydzielonych rezerw. Plan Jakoci Projektu Wejcie Bdzie przewodnikiem w wyborze i umiejscowieniu dziaa dotyczcych kontroli jakoci. Zawiera tak e Plan Zarzdzania Konfiguracj, ktry okrela produkty wymagajce utworzenia Zapisw Obiektw Konfiguracji. Diagram Struktury Produktw Opisy Produktw/Zapisy Obiektw Konfiguracji Lista Kontrolna Produktw Diagram Nastpstwa Produktw Wyjcie Zestawienie w ukadzie hierarchicznym wszystkich produktw, ktre maj by wytworzone w ramach planu. Wyjcie Opis ka dego produktu oraz jego kryteriw jakoci. Jest to rwnie pocztek tworzenia Zapisw Obiektw Konfiguracji dla produktw. Wyjcie Jeli jest stosowana - wstpna lista gwnych produktw objtych planem. Wyjcie Diagram pokazujcy kolejno, w jakiej produkty powinny by wytwarzane.

11.5.6.

Kryt eria oceny ci jako Czy plan osign uzgodniony poziom szczegowoci? Czy zidentyfikowano zarwno wszystkie produkty zarzdcze, jak specjalistyczne? Czy produkty/dziaania zarzdcze s prawidowo doczone do porzdku prac? Czy plan potrzebuje jakich produktw ze rde zewntrznych? Czy zostay one prawidowo pokazane w porzdku prac? Czy znane czynniki ryzyka zostay zidentyfikowane? Czy zarzdzanie zagro eniami wymaga jakichkolwiek produktw? Czy zostay one prawidowo pokazane w porzdku prac? 197

dodatkowych

PLANNING (PL) Wskazwki i rady

Punkt decyzyjny mo e by zwizany z jednym lub wiksz liczb produktw porednich, na ktrych decyzja bdzie oparta. Lista produktw, ich wymagana kolejno oraz wszystkie opisy powinny by poddane przegldowi jakoci pod wzgldem dokadnoci i kompletnoci. Wymagana jako stanowi kryterium, w odniesieniu do ktrego produkt bdzie akceptowany. Przy pracy w relacjach klient/dostawca, mo e to stanowi podstaw akceptacji projektu. Definicja gwnych produktw kocowych lub rezultatw, wymaganych do zaspokojenia potrzeb biznesowych, powinna by przedstawiona w Dokumencie Inicjujcym Projekt jako cz celw projektu.

PRINCE

11.6.
11.6.1.

Okre lenie Dziaa

Podstawowe zasady

i Wspzale no

ci (PL3)

Proste zidentyfikowanie produktw mo e by niewystarczajce dla celw harmonogramowania i kontroli. Nale y okreli dziaania konieczne do dostarczenia ka dego z produktw, aby uzyska peniejszy obraz planowanej pracochonnoci.

11.6.2.

Kontekst

Podproces jest realizowany po uzgodnieniu Diagramu Nastpstwa Produktw, opracowanego w podprocesie Okr lenie i Analizowanie (PL2). Okrelenie dziaa e Produktw dodatkowe produkty, mo- bdzie skutkowa e ujawni zapotrzebowanie na co powtrzeniem podprocesu PL2. Podobnie jak dla innych podprocesw Planowani (PL), podprocesu Okr e proces lanie i Wspzale (PL3) bdzie realizowany w sposb c e Dziaa dziaania i produkty mog itera- wymagane w odpowiedzi na no i by cyjny. Dodatkowe zidentyfi-zagro enia i dlatego nale y sprawdzi Rejestr kowane Ryzyka.

11.6.3.

Opis procesu

Podproces jest podzielony na trzy kroki, w ktrych nale y: okreli wszystkie dziaania, konieczne dla dostarczenia produktw; ustali wzajemne zale noci pomidzy dziaaniami; zapewni uwzgldnienie zale noci zarwno wewntrznych, jak i zewntrznych w stosunku do projektu. Wszystkie dziaania wymagane do wytworzenia lub zmiany planowanych produktw okrelone. Po sporzdzeniu Diagramu Nastpstwa Produktw, dziaania musz by naja- mo na okreli, wykorzystujc proces transformacji. Transformacja twiej identyfikuje dziaania potrzebne, aby jeden produkt lub zestaw produktw przeksztaci w nastpny 19 8

PRINCE2

PLANOWANIE(PL)

w kolejnoci produkt lub zestaw W zale noci od poziomu produktw. wymaganego w planie, mo e wystpi tylko szczegowoci lub grupa dziaa. jedno dziaanie Dziaania nanie na Diagram Nastpstwa Produktw przy odnonych te mo na produktach.11.3 pokazuje Diagram Nastpstwa Produktw dla zorganizowania Rysunek konferencji z naniesionymi dziaaniami. Rysunek 11.4 podaje list dziaa zwizanych z tym produktem kocowym.
A1
Ustalony temat konferencji

B1 D1 D2 N1 N2
Lista potencjalnych prelegentw Lista wymaga dla lokalizacji konferencji

Ustalony termin konferencji

T1
Opracowany system przyjmowania zgosze

P1
Lista mo liwych lokalizacji

E1 E2 E3
Zaproszenia dla prelegentw

Q1 H1 H2
Okad ki materiaw

F1 F2
Zakontraktowani prelegenci

C1
Informacja o lokalizacjach

J1 J2
Ustalo ny program konferencji

R1 R2
Wybrana i zakontraktowana lokalizacja

Lista adresowa

G1 G2 G3
Wydrukowane slajd y i notatki

U1 U2
Materia informacyjn y wysany poczt

S1 K1 L1 K2
Wydrukowany porz dek dnia

L2
Ankieta oceniaj ca konferencj

S2
Informacja dla prasy

V1
Zgoszenia uczestnictwa

M1
Skompletowany pakiet uczestnika Ostateczna

W1 W2
lista uczestnikw Zakontraktowani na dzie konferencji pracownicy obsugi

Y1

X1

Zorganizowana konferencja

Rysunek 11.3. zorganizowanie

Diagram konferencji

Nastpstwa

Produktw

dla

projektu

199

PLANNING (PL)

PRINCE

produkt u Ustalony temat konferencji A A1 Uzyskaj temat Ustalony termin konferencji B B1 Uzyskaj dat Lista adresowa C C1 Uzyskaj list wysykow -

Produkt ID

ID dziaania

Dziaania zwi zane Dziaania po przedzaj ce

Lista potencjalnych prelegentw D D1 Ustal potencjalnych prelegentw A1 D2 Przygotuj baz danych prelegentw D1 Zaproszenia dla prelegentw E E1 Przygotuj zaproszenia dla prelegentw D2 E2 Skompletuj listy z zaproszeniami E1 E3 Wylij listy z zaproszeniami E2 Zakontraktowani prelegenci F F1 Odbieraj odpowiedzi E3 F2 Potwierd uczestnictwo prelegentw F1 Wydrukowane slajdy i notatki G G1 Przygotuj slajdy F2 G2 U slajdy w porzdku prezentowania G1 G3 Wydrukuj slajdy G2 Okadki materiaw H H1 Zaprojektuj okadki A1 H2 Wydrukuj okadki H1 Ustalony program konferencji J J1 Opracuj wstpna wersj programu F2 J2 Ustal tre programu J1 Wydrukowany porzdek dnia K K1 Ustal porzdek dnia J2 K2 Wydrukuj porzdek dnia K1 Ankieta oceniajca konferencj L L1 Uzgodnij format ankiety uczestnika J2 L2 Wydrukuj ankiet uczestnika L1 Skompletowany pakiet uczestnika M M1 Skompletuj materiay dla uczestnikw H2, G3, K2, L2 Lista wymaga dla lokalizacji konferencji N N1 Przygotuj list wymaga dla lokalizacji B1 N2 Ustal list wymaga dla lokalizacji N1 Lista mo liwych lokalizacji P P1 Sporzd list mo liwych lokalizacji N2 Informacje o lokalizacjach Q Q1 Przeprowad wywiad P1 Wybrana i zakontraktowana lokalizacja R R1 Wybierz lokalizacj Q1 R2 Zakontraktuj lokalizacj R1 Informacja dla prasy S S1 Przygotuj materiay dla prasy J2, R2 S2 Zamie informacje w prasie S1 Opracowany system przyjmowania zgosze U2 Wylij zaproszenia do uczestnikw U1 Zgoszenia uczestnictwa V V1 Zbierz odpowiedzi uczestnikw S2, U2 Ostateczna lista uczestnikw W W1 U list uczestnikw konferencji V1 W2 Zamknij list uczestnikw W1 Zakontraktowani na dzie konferencji pracownicy obsugi X X1 Zatrudnij pracownikw obsugi W2 T T1 Sformuuj warunki uczestnictwa B1

Materia informacyjny wysany poczt U U1 Przygotuj i skompletuj zaproszenia C1, T1

Zorganizowana konferencja Y Y1 Przeprowad konferencj M1, X1

Rysunek 11.4. konferencji

Lista dziaa dla projektu zorganizowanie

Lista dziaa powinna obejmowa zarwno dziaania zarzdcze, dziaania dotyczce kon- jakoci, jak i dziaania potrzebne do wytworzenia produktw troli specjalistycznych. Powinno si rwnie okreli wszelkie ograniczenia.

20 0

PRINCE2

PLANOWANIE(PL)

Ograniczeniami zewntrznymi mog by: dostarczenie wy maganego produktu z innego projektu; oczekiwanie na decyzj kier ownictwa programu. Wszdzie, gdzie to mo liwe, zewntrzne ograniczenia powinny zosta opisane jako uzale nienie od dostpnoci zewntrznego produktu. Ograniczenia wynikajce z zasobw dane zasoby s dostpne dla wykonania pracy?) nie s tutaj brane pod (np.: Czy uwag. to S sprawy dla procesu harmonogramowania. Wrd dziaa powinny znale si rwnie te, ktre wynikaj ze wspdziaania ze stronami zewntrznymi, np. otrzymanie produktu z zewntrznego rda lub przeksztacenie zewntrznych produktw w co, czego wymaga plan.

11.6.4.

Odpowiedzialno

Kierownik Projektu jest odpowiedzialny za podproces w odniesieniu do Planu Projektu Etapw. i Planw Za Plany Zespow odpowiada(-j) Kierownik(-cy) Zespou(w). Powinno istnie wsparcie ze strony wszystkich Kierownikw Zespow, ktrych zespoy maj udzia w realizacji danego planu. Pomocy nale y spodziewa si rwnie ze stronypenicych obowizki Nadzoru Projektu lub Wsparcia Projektu. Sprawdzenie osb wyni- tej pracy jest czci obowizkw osb penicych rol Nadzoru kw Projektu.

11.6.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Produkty i zale noci midzy nimi s podstaw do okrelenia wymaganych dziaa i ich wspzale noci.

Tabela 11.3. PL3 Informacja Objanienie

Diagram Nastpstwa Produktw

Opisy Produktw Wejcie Cz Pochodzenie / rdo w Opisie Produktu mo e zawiera informacje pomocne w okreleniu zale noci. Rejestr Ryzyka Wejcie Z Rejestru Ryzyka mog wynika dziaania monitorujce zagro enia, ktre powinny by dodane do planu. Lista dziaa Wyjcie Wszystkie dziaania wymagane do wytworzenia produktw. Zale noci midzy dziaaniami Wyjcie Wszelkie zale noci pomidzy dziaaniami wymienionymi na powy ej wymienionej licie dziaa.

201

PLANNING (PL)

PRINCE

11.6.6.

Kryteria oceny ci jako Czy jakie dziaania mog by prowadzone rwnolegle? Czy jakie dziaania mog zachodzi na siebie? Czy potrzebne s przerwy pomidzy niektrymi dziaaniami? Czy dziaania przewidziane w zakresie kontroli jakoci s wystarczajce? - to pyta-niekiedy mo e by zbyt szczegowe dla Planu nie Projektu.

Wskazwki i rady
W tej fazie nale y si wystrzega eksplozji dziaa poza poziom szczegowoci odpowiedni dla konkretnego poziomu planu. Nie nale y niczego komplikowa. W razie wtpliwoci, nie nale y dopuszcza do zachodzenia dziaa na siebie.

11.7.
11.7.1.

Szacowanie (PL4)
Podstawowe zasady

Szacowanie nie mo e zagwarantowa dokadnoci, ale dostarcza w pr aktyce obrazu oglnych kosztw i czasu wymag anych do wykonania planu. Oszacowania bd si pewnoci zmieniay, w miar jak wiedza o projekcie bdzie z wzrastaa.

11.7.2.

Kontekst

Szacowanie nastpuje po okreleniu dziaa w podprocesie PL3 oraz poprzedza harmonogramowanie w podprocesie PL5.

11.7.3.

Opis procesu

Jest to podproces iteracyjny (kilkakrotnie powtarzany). Celem jest okrelenie zasobw oraz czasu wymaganego do wykonania ka dego z dziaa. Powinien obejmowa nie tylko osobowe, ale tak e inne potrzebne zasoby zasoby. Poniewa metody szacowania bd si r niy w zale noci od typu projektu i poziomuponi sze wskazwki maj charakter planu, oglny. Plan Projektu bdzie zwykle wymaga szacowania od gry do dou (tzn. wpierw oszaco-dla caego projektu, rozbite nastpnie na etapy normalne dla projektu danego wanie ty- natomiast w Planie Etapu lub Planie Zespou bdzie stosowana metoda z dou do pu), g- (tzn. wpierw oszacowanie dla ka dego produktu, rozbudowywane nastpnie w ry gr i skadajce si na wartoci liczbowe dla caego planu).

20 2

PRINCE2

PLANOWANIE(PL)

W typowym procesie szacowania wyr nia si dwa gwne kr oki: okr lenie rodzajw wymaganych . W zale noci od rodzaju i zo e zasobw onoci projektu mog by wymagane okrelone kwalifikacje. Wymagania mog obejmowa zasoby inne ni osobowe, takie np. jak wyposa enie, pienidze czy delegacje. uzgodnienie definicji rodzajw zasobw. W przypadku personelu Istotne jest powinny obj: wymagane umiejtnoci i poziom(-y) dowiadczenia; informacj, gdzie mo na znale te umiejtnoci, tak by mo liwe byo okrelenie zaanga owania, wymaganego od r nych czci organizacji. oszacowanie ci ka dego z , odniesione do ka dego z pracochonno tej fazie oszacowania bd przybli one i dlatego tymczasowe. Wiar dziaa rodzajw zasob . W w godnoyoszacowa zale y od: stopnia zrozumienia dziaania; poczynionych zao e; rozpoznania produktw (na podstawie Opisw . Produktw) Na podstawie tych informacji mo na oszacowa czas trwania poszczeglnych dziaa i wykorzysta t informacj w Harmonogramowanie (PL5) (lista dziaa procesie dla zorganizowania konferencji oraz ich czasy trwania - patrz: Rysunek 11.5).enia przyjte za podstaw oszacowania, margines bdu oraz stopie ufnoci Zao oszacowa powinny by zapisane w planie. Informacje te pozwol Komitetowi Sterujcemu na wyznaczenie odpowiednich tolerancji. Tolerancje szczegowo opisano w Rozdziale 16 Elementy . Jeli aktualne zrozumienie planu jest niewystarczajce, mo sterowania e zaj potrzeba powtrzenia wczeniejszych podprocesw planowania.

11.7.4.

Odpowiedzialno

Kierownik Projektu jest odpowiedzialny za szacowanie dla Planu Projektu i Planw Eta- Kierownik Zespou bdzie odpowiedzialny za oszacowania dla Planu pw. Zespou. to trudna praca i tam, gdzie to mo liwe, nale y szuka dodatkowej pomocy. Wymaga ona uprzedniego dowiadczenia w przedmiocie planu, jak rwnie treningu w szacowaniu. W tym wanie podprocesie mo e bardzo pomc fachowa wiedza osb penicych rol Wsparcia Projektu.

Jest

11.7.5.
Tabela 11.4. PL4 Informacja Objanienie

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Produkty i dziaania, ktre wymagaj szacowania.

Wszystkie dotychczasowe informacje planistyczne Oszacowania dziaa (pracochonno i czas trwania)

Wyjcie Oszacowane dziaania s przekazywane do podprocesu Harmonogramowanie (PL5).

203

PLANNING (PL)

PRINCE

11.7.6.

Kryteria oceny ci jako Czy szacowanie ma by zrobione w odniesieniu do znanych zasobw, czy oglnych wymaga dotyczcych umiejtnoci i dowiadczenia? Jaki poziom produktywnoci powinien by przyjty dla zasobw? Czy nale y utworzy rezerw na zr nicowane poziomy produktywnoci zasobw? Czy zao ono w oszacowaniu istnienie jakiej infrastruktury wspierajcej? Czy zao- te s udokumentowane w tekcie enia planu? Czy wzito pod uwag produkty kontroli jakoci?
Produkt ID produkt Uzyskaj temat - 0 u ID dziaania Dziaania zwi zane Dziaania po przedzaj ce Czas trwania

Ustalony temat konferencji A A1 Ustalony termin konferencji B B1 Uzyskaj dat - 0 Lista adresowa C C1 Uzyskaj list wysykow - 0 Lista potencjalnych prelegentw D D1 Ustal potencjalnych prelegentw A1 2 D2 Przygotuj baz danych prelegentw Zaproszenia dla prelegentw E E1 Przygotuj zaproszenia dla prelegentw E2 Skompletuj listy z zaproszeniami E1 1 E3 Wylij listy z zaproszeniami E2 1 Zakontraktowani prelegenci F F1 Odbieraj odpowiedzi E3 10 F2 Potwierd uczestnictwo prelegentw Wydrukowane slajdy i notatki G G1 Przygotuj slajdy F2 15 G2 U slajdy w porzdku prezentowania G3 Wydrukuj slajdy G2 1 Okadki materiaw H H1 Zaprojektuj okadki A1 5 H2 Wydrukuj okadki H1 5 Ustalony program konferencji J J1 Opracuj wstpn wersj programu J2 Ustal tre programu J1 1 Wydrukowany porzdek dnia K K1 Ustal porzdek dnia J2 1 K2 Wydrukuj porzdek dnia K1 1 Ankieta oceniajca konferencj L L1 Uzgodnij format ankiety uczestnika L2 Wydrukuj ankiet uczestnika L1 1 Skompletowany pakiet uczestnika M M1 Skompletuj materiay uczestnika H2, G3, K2, L2 2 Lista wymaga dla lokalizacji konferencji N N1 Przygotuj list wymaga dla lokalizacji N2 Ustal list wymaga dla lokalizacji N1 2 Lista mo liwych lokalizacji P P1 Sporzd list mo liwych lokalizacji Zapytania dotyczce lokalizacji Q Q1 Przeprowad wywiad P1 2 Wybrana i zakontraktowana lokalizacja R R1 Wybierz lokalizacj Q1 2 R2 Zakontraktuj lokalizacj R1 2 Informacja dla prasy S S1 Przygotuj materiay dla prasy J2, R2 3 S2 Zamie informacje w prasie S1 1 Opracowany system przyjmowania T T1 Sformuuj warunki uczestnictwa B1 2 zgosze Materia informacyjny wysany poczt U U1 Przygotuj i skompletuj zaproszenia U2 Wylij zaproszenia do uczestnikw Zgoszenia uczestnictwa V V1 Zbierz odpowiedzi uczestnikw S2, U2 20 Ostateczna lista uczestnikw W W1 U list uczestnikw konferencji V1 1 W2 Zamknij list uczestnikw W1 1 Zakontraktowani na dzie konferencji X X1 Zatrudnij pracownikw obsugi W2 1 pracownicy obsugi Zorganizowana konferencja Y Y1 Przeprowad konferencj M1, X1 1

D1 1 D2 1

F1 2

G1 2

F2 5

J2 1

B1 2

N2 1

C1, T1 1 U1 1

Rysunek 11.5. ich

Lista dziaa dla projektu zorganizowanie konferencji wraz z czasem trwania

20 4

PRINCE2

PLANOWANIE(PL)

Wskazwki i rady
Mo na wykorzystywa komputerowe narzdzia do szacowania, opisy tekstowe, tabele, wykresy lub formuy dla rodzaju pracy okrelonego w planie. Narzdzia te zwykle bazuj na informacji o faktycznym czasie wykonania dziaa identycznych lub podobnych do wymaganych przez plan. Wartoci liczbowe mog by w pewnym stopniu dostosowane, tak aby odzwierciedlay cilej rodowisko, do ktrego odnosi si przygotowywany plan. Szacowanie najlepiej wykonuje si w grupie dwch lub trzech osb dowiadczonych zarwno w przedmiocie planu, jak i w szacowaniu. Taka liczba osb pozwoli na wywa enie zbyt du ego optymizmu lub pesymizmu w szacowaniu. Tam, gdzie to mo liwe, szacowanie powinno uwzgldnia dyskusje z osobami, ktre bd odpowiedzialne za wykonanie pracy. W du ych projektach lub trudnych obszarach pracy rozwa nie jest dokonywa oszacowa przynajmniej dwa razy, albo poprzez wykorzystanie dwch r nych podej, albo pozwalajc dwm r nym grupom osb na niezale ne oszacowania. Kiedy zostanie oszacowane zapotrzebowanie na zasoby, mo e si okaza, e ograniczenia dotyczce zasobw nie mog by utrzymane. W takim przypadku, sprawa powinna zosta zreferowana Komitetowi Sterujcemu. W Planie Projektu mo na oczekiwa wikszej niepewnoci ni w Planie Etapu. Plan Etapu ma krtsze ramy czasowe, dotyczce bli szej przyszoci i jest planowany bardziej szczegowo. Nale y wykorzysta Raporty o Dowiadczeniach z wczeniejszych, podobnych projektw. Zrozumienie przyczyn minionych sukcesw i pora ek dziki zapoznaniu si z Raportami o Dowiadczeniach innych produktw, mo e pomc w szacowaniu. Wszelkie zao enia zrobione w trakcie procesu szacowania powinny by udokumentowane w tekcie planu w czci pod tytuem Zao enia. Jeli zao enie odnosi si do zagro enia, wwczas zagro enie to powinno by udokumentowane w Rejestrze Ryzyka.

11.8.
11.8.1.

Harmonogramowanie (PL5)
Podstawowe zasady

Plan tylko wtedy mo e przedstawi realistycznie mo liwo osignicia jego celw, gdy dziaania s zestawione razem w harmonogram, ktry definiuje, kiedy ka de dziaanie bdzie realizowane.

11.8.2.

Kontekst

Harmonogramowanie nastpuje po oszacowaniu czasu trwania ka dego z dziaa, a po nim wykonywana jest ocena ryzyka tkwicych w planie. Harmonogram mo e wymaga 205

PLANNING (PL) ponownego przegldu podczas procesu i ulepszy sposb, w jaki plan realizowany. Planowani e bdzie

PRINCE (PL), po to aby udoskonali

11.8.3.

Opis procesu

Harmonogramowanie ma na celu: dobranie dostpnych zasobw do okrelonych dziaa; sporzdzenie harmonogramu prac zgodnie z okrelon kolejnoci i zale nociami; wyrwnanie wykorzystania zasobw w granicach okrelonych wczeniej zale noci i wszelkich oglnych ogranicze czasowych; zidentyfikowanie przeci enia zasobw przydzielon im prac lub zapotrzebowania zasoby oraz wynegocjowanie z Komitetem Sterujcym na dodatkowe rozwizania tych spraw; obliczenie cakowitego wyliczenie ich kosztu. zapotrzebowania na zasoby osobowe i inne oraz

Istnieje wiele r nych podej do harmonogramowania. Czynnoci te mog by wyko- rcznie albo przy wykorzystaniu komputerowego narzdzia do planowania i nywane kontroli . Typowe kroki harmonogramowania to: narysowanie sieci ; na podstawie listy dziaa oraz czasw ich trwania nale dziaa y narysowa sie dziaa, uwzgldniajc ich wspzale noci, od pierwszego do ostat- dziaania. Sie dziaa dostarcza wa nych informacji, na przykad o tym, niego jaki byby mo liwy cakowity czas realizacji przy zao eniu braku ogranicze zasobw. 11.6 przedstawia sie dziaa wykazanych na licie pokazanej na Rysunek rysunku 11.5. Liczba w rodkowej kolumnie grnego wiersza ka dego prostokta jest czasem dziaania. Liczba w lewej kolumnie grnego wiersza jest jego trwania najwcze- czasem rozpoczcia. Liczba w prawej kolumnie tego wiersza niejszym oznacza najwczeniejszy czas zakoczenia dziaania. Zestaw kolumn na dole ka dego prostokta to odpowiednio - od lewej do prawej - najpniejszy czas r ozpoczcia, zapas oraz najpniejszy czas zakoczenia cakowity dziaania; ocena pn ci ; nale y nastpnie ustali liczb osb, ktre bd dostdo wykonania danej pracy (lub koszt kupienia tych zasobw). Nale y o zasobw dostpne zanotowa szczegowe informacje, na przykad: nazwisko, dowiadczenie, wszystkie procent dostpnoci, daty dostpnoci od - do, czy jest to zasb zewntrzny, czy wewntrzny. W projekcie mog by rwnie potrzebne zasoby inne ni osobowe; ich dostp- e nale y oceni; no tak opracowanie szkicu harmonogramu i przypisanie ; wykorzystujc c odpowiedzialno i wiedz o dostpnoci zasobw oraz informacje z sieci dziaa, przydziela si teraz zasoby do konkretnych dziaa. Zasad jest: przypisuj zasoby wedug wzrastajce- czasu, co znaczy, e pr zydziela si zasoby najpierw do dziaa z go zapasu zero- zapasem czasu (ktre z definicji znajduj si na cie ce krytycznej). wym Dziaania z najwikszym zapasem czasu maj w kolejnoci pr zydzielania zasobw najni szy priorytet . ezultatem bdzie harmonogram, pokazujcy obci enie prac ka dej osoby or R az

20 6

PRINCE2

PLANOWANIE(PL)

wykorzystanie innych zasobw. Czas trwania ka dego z dziaa mo e by dostoso-na podstawie wiedzy o potrzebnym nakadzie pracy zasobu oraz wany dostpnoci zasobw odpowiedniego typu. Harmonogram jest czsto przedstawiany w postaci wykresu Gantta. Rysunek 11.7 ilustruje wykres Gantta dla projektu: zorganizowanie konferencji; wyrwnanie enia ; nale y rozwa y faktyczn dostpno obci wszelkich zasobw i wbudowa zasobw j w plan. Pierwsza alokacja zasobw mo e skutkowa ich nierwnym wykorzystaniem, a na- w pewnych okresach mo e wystpi przeci enie niektrych z nich. W wet takich przypadkach ponownie przypisuje si obowizki, przesuwa si terminy dziaa w granicach zapasw, ktre mog posiada. Czas trwania poszczeglnych dziaa jest zmieniany w stosunku do pier wotnych oszacowa w taki sposb, aby odzwierciedla ograniczenia Wynikiem kocowym tego kroku jest zasobw. ostateczny harmonogram, w ktrym wszystkie dziaania zostay przydzielone zasobom, a wykorzystanie zasobw odpowiada ich dostpnoci; potwierdzenie punktw ; pierwszy, szkicowy harmonogram umo kontrolnych liwia potwierdzenie przez Komitet Sterujcy punktw kontrolnych okrelonych wczeniej (na Diagramie Nastpstwa Produktw - Rysunek . Dziaania zwizane z ko11.3) etapu (np. przygotowywanie Planu Etapu (nastpnego), opracowywanie cem Raportu Kocowego Etapu) powinny by doczone do sieci dziaa i wwczas nale y opracowa nowy harmonogram; obliczenie ci zasobw i ; mo na teraz uj tabelarycznie wielko kosztw obliczy koszt zasobw i inne koszty, w celu wymagania dotyczce zasobw oraz opracowania bud etu. Nale y pamita o przeprowadzaniu konsultacji z planowanego osobami penicymi rol Nadzoru Projektu, gdy mog one sobie yczy dodania konkretnych zasobw do dziaa sprawdzania jakoci.

207

LEGENDA LEGENDAStart najWczeniejszy WS

WS najWczeniejszy Start WS CT WK Trwania Cakowity czas CT WS CT WK Trwania ID Cakowity czas CT najWczeniejszy czas zaKoczenia WK WS CT WK ID najWczeniejszy czas WK PK dziaania zaKoczenia 0 0 CZ identyfikator ID PS 0 ID CZ PK dziaania 000 identyfikator Start ID 20 48 PS 1 25 najPniejszy PS 26 50 49 48 28 25 51 24 50 C1 49 0 0 CZ PKZapas PS 1 25 najPniejszy Start PS 0 Cakowity CZ 50 49 51 48 50 28 49 25 26 24 26 26 C120 48 X1 W2 W1 V1 U2 U1 26 Cakowity CZ 50 51 49 50 48 49 28 26 25 26 26 24 20 48 C11 25 Zapas najPniejszy Koniec PK X1 W2 W1 V1 U2 U1 26 50 51 49 50 48 49 28 48 27 0 28 26 2 27 najPniejszy Koniec PK26 26 X1 W2 W1 V1 U2 U1 26 50 51 49 50 48 49 28 48 27 0 28 26 2 27 cie ka 50 51 49 50 48 49 28 48 27 0 28 26 2 27 Krytyczna cie ka Krytyczna 022 022 T1 022 T1 24 26 24 T1 24 26 24 24 24 26 27 7 24 5 9 9 7 4 5 2 410 2 21 28 0 03 27 11 27 1 28 24 3 27 9 9 7 7 5 5 414 222 000 S2 S1 R2 R1 Q1 P1 N2 N1 B1 11 27 1 28 24 3 27 9 9 7 7 5 5 414 222 000 S2 28 S1 11 R2 R1 24 Q1 22 P1 20 N2 18 N1 17 B1 15 27 13 13 24 0 27 22 20 18 17 15 13 S2 S1 28 R2 R1 24 Q1 22 P1 20 N2 18 N1 17 B1 15 27 13 13 24 0 27 22 20 18 17 15 13 27 13 13 24 0 27 22 20 18 17 15 13 28 24 22 20 18 17 15 51 52 25 26 24 25 23 1 24 18 5 23 51 52 25 26 24 25 23 1 24 18 5 23 Y1 K2 K1 J2 J1 51 52 25 26 24 25 23 1 24 18 5 23 Y1 49 K2 52 K1 24 J2 23 48 J1 0 23 51 48 47 23 18 Y1 49 K2 52 K1 24 J2 23 48 J1 0 23 51 48 47 23 18 51 48 52 47 24 23 23 48 18 0 23 49 25 26 24 1 25 25 26 24 1 25 L2 L1 25 26 24 1 25 L2 L1 23 49 48 47 48 L2 L1 23 49 48 47 48 48 23 49 47 48

36 10 5 5 0 52 38 36 10 5 5 0 52 38 H2 M1 H1 36 10 5 5 0 52 38 H2 M113 49 H139 44 49 44 39 51 H2 M113 49 H139 44 49 44 39 51 49 44 13 49 39 39 44 51

35 6 33 5 18 4 16 3 6 2 5 016 4 10 36 3 11 35 2 215 33 0 02 18 35 33 18 16 6 5 4 10 31 22 00 G3 G2 G1 6 F2 5 F1 4 E3 3 E2 216 E1 036 D21 35 D115 33 A12 18 35 33 18 16 6 5 4 10 31 22 00 G3 6 G2 5 G1 4 49 F2 3 48 F1 216 E3 018 E2 13 46 E1 0 36 D21 35 D115 33 A12 18 48 46 31 16 16 6 6 5 5 4 4 3 3 2 2 000 G3 G2 G1 16 F2 6 F1 5 E3 4 E2 3 E1 2 49 D2 0 48 D113 46 A10 18 48 46 31 16 6 5 4 3 2 00 48 46 16 31 6 16 5 6 4 5 3 4 2 49 3 0 48 2 13 46 0 00 18

PRINCE2

PLANOWANIE(PL)

Rysunek 11.7. (fragment)

Przykad wykresu Gantta

11.8.4.

Odpowiedzialno

Za podproces odpowiedzialny jest Kierownik W przypadku Planw Zespow, Projektu. Projektu mo e wczy do planowania osob odpowiedzialn za prace Kierownik zawarte w planie, np. Kierownika Zespou. Pomocne w tych pracach mog by osoby dzielone do penienia roli WsparciaprzyProjektu.

11.8.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 11.5. PL5 Informacja Objanienie

Oszacowania dziaa Wejcie Analizowane razem z wielkoci zasobw, pozwalaj okreli czas trwania dziaania. Zale noci midzy dziaaniami Wejcie Okrelaj wymagan kolejno prac w harmonogramie.

209

PLANNING (PL)

PRINCE

Informacja Objanienie

zarzdcza

Wykorzystanie

Dostpno zasobw Wejcie Potrzebne s pocztkowe i kocowe daty dostpnoci zasobw oraz ilo czasu, jakim zasoby dysponuj w tym okresie. Harmonogram Wyjcie Lista dziaa i przydzielonych im zasobw oraz terminy, w jakich dziaania bd prowadzone.

11.8.6.

Kryteria oceny ci jako Czy wzito pod uwag wszystkie rodzaje potrzebnych zasobw? Czy zostaa zidentyfikowana cie ka krytyczna? Czy zaplanowano wystarczajce monitorowanie dziaa na cie ce krytycznej? Czy do harmonogramu zostay wczone wszelkie potrzeby szkoleniowe? Czy dostpno zasobw zostaa oceniona realistycznie?

Wskazwki i rady
Na poziomie projektu zasoby nie musz by okrelane z nazwy, ale nale y okreli rodzaje umiejtnoci wymaganych do realizacji dziaania. Dostpno potrzebnych zasobw (wcznie z zasobami wymaganymi dla przegldw jakoci) powinna by uzgodniona z waciwymi kierownikami liniowymi/operacyjnymi. Nale y realistycznie ocenia dostpno zasobw. Nale y przyj rezerwy na urlopy i czas, ktry personel projektu bdzie spdza na dziaaniach pozaprojektowych. redni tydzie pracy, po uwzgldnieniu urlopw, szkole, chorb itp., to tylko 4 dni. Z tych 4 dni przynajmniej poowa dnia bdzie zu yta na inne obowizki, nawet przez personel oddelegowany tylko do projektu - np. na przegldy jakoci w innych projektach, operacyjne zarzdzanie i narady. Zastosowanie macierzy umiejtnoci mo e pomc osobie sporzdzajcej harmonogram przy wykorzystywaniu zasobw wewntrznych. Pozwoli ona zarwno na wskazanie odpowiednich osb, jak i na pokazanie caociowego obrazu dostpnych umiejtnoci przydatnych do pracy nad projektem. Po przedyskutowaniu dostpnoci zasobw z kierownikami operacyjnymi nale y natychmiast udokumentowa osignite porozumienie.

11.9.
11.9.1.

Analizowanie Zagro e
Podstawowe zasady

(PL6)

Zaanga owanie si w realizacj dziaa, bez rozwa enia zagro e z nimi zwizanych jest szukaniem katastrofy. Zagro enia nale y oceni i wprowadzi odpowiednie modyfikacje przebiegu dziaa, aby usun lub zmniejszy wpyw tych zagro e. 21 0

PRINCE2

PLANOWANIE(PL) Kontekst

11.9.2.

Po opracowaniu, plan powinien by nadal traktowany jako wstpny, a do czasu zidenty- zawartych w nim zagro e i ich oceny oraz mo liwej modyfikacji fikowania planu.

11.9.3.

Opis procesu

Analizowanie Zagro (PL6) przebiega rwnolegle z wszystkimi innymi pracami e planistycznymi. Jest to proces iteracyjny, a jego rezultaty mog spowodowa powrt do poprzednich krokw i powtrzenia podprocesu, jeli to konieczne. Omwienie zarzdzania zagro eniami przedstawiono w Rozdziale 17, w czci tego podrcznika powiconej . komponentom Wszelkie zao enia planistyczne stwarzaj zagro enie wynikajce z niepewnoci odpo- na pytanie Czy przyjto waciwe zao wiedzi enia? Ka dy zasb powinien by oceniony z punktu widzenia zwizanego z nim potencjalnego znana jest ilo zasobu? Czy znana jest jako wymaganej pracy oraz ryzyka. Czy zdol- do dotrzymywania terminw? Czy znany jest poziom zaanga owania? Czy no zasobycakowicie bd pod kontr ol Kierownika Tam, gdzie odpowied brzmi Projektu? si zagro enie. rodki zaradcze mog oznacza czstsze i dokadniejsze nie, pojawia monito- do momentu nabrania zaufania do zasobw. Do czasu, a rowanie poziom umiejtnoci zasobu zostanie sprawdzony, mo e by korzystne przydzielanie mu pracy, ktra jest albo atwa do wykonania, albo mniej zagra a harmonogramowi. Ka de dziaanie musi by sprawdzone pod wzgldem ryzyka. Czy jest jaki zapas czasu,te cay harmonogram jest uzale niony od uniknicia polizgu danego czy dziaania? Ka de dziaanie na cie ce krytycznej stanowi zagro enie. rodki zaradcze powinny przynajmniej uwzgldnia czstsze monitorowanie, w celu uzyskania wczesnego ostrzeenia o jakichkolwiek problemach. Informacje planistyczne opracowane do tego punktu procesu powinny by zbadane pod wzgldem zagro e. Ka de zidentyfikowane zagro enie powinno by wpisane do Rejestru Ryzyka. Przykadami zagro e, ktre mog by wbudowane w plan, s: podwykonawca mo e nie dostarczy na czas potrzebnego produktu; produkt, ktry ma dostarczy trzecia strona, mo e by zej jakoci; zasb mo e nie osiga wynikw na oczekiwanym poziomie; konkretny zasb, od ktrego zale y plan, mo e zosta usunity z projektu; czynniki zewntrzne mog spowodowa kryzys; harmonogram jest bardzo napity i uzale niony od terminowego dostarczenia kilku produktw, z ktrych ka dy mo e by opniony.

11.9.4.

Odpowiedzialno

Kierownik Projektu jest odpowiedzialny za analizowanie i monitorowanie zagro e,czym pomagaj mu osoby penice obowizki Nadzoru Projektu. Mog wystpi w za211

PLANNING (PL) gro enia pozostajce poza kontrol Kierownika Projektu. Ich identyfikacja wchodzi w zakres obowizkw Komitetu Sterujcego. Kierownik Projektu powinien przedyskutowa istnienie takich zagro e z Komitetem Sterujcym, aby si upewni, e s one odpowiednio monitor owane. Powinni oni tak e przedyskutowa zagro enia z Kierownikami Zespow oraz ekspertami przedmiotowymi.

PRINCE

11.9.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Wejcie Podstawa oceny ryzyka.

Tabela 11.6. PL6 Informacja Objanienie

Wszystkie dotychczasowe informacje planistyczne

Rejestr Ryzyka Aktualizacja Wszelkie nowe zagro enia powinny by do niego dodane.

11.9.6.

Kryteria oceny ci jako Czy istniej jakie uzale nienia od produktw lub wsparcia ze rde zewntrznych, ktre nie zostay wyszczeglnione jako zagro enia? Czy koszt uniknicia lub redukcji zagro enia zbli a si do kosztu ponoszonego materializacji tego zagro w przypadku enia? Czy rozwa ano cay zakres rodkw postpowania z ka dym zagro eniem? Czy zagro enia s tak du e, e stawiaj pod znakiem zapytania zasadno projektu?

Wskazwki i rady
Istniej r ne metody zarzdzania ryzykiem i metody analizy oraz dostpne narzdzia do pomocy w tych aspektach procesu. Ka demu zagro eniu i ka demu dziaaniu krytycznemu dla projektu nale y przydzieli zasoby, do ktrych kierownictwo ma zaufanie. Nale y monitorowa harmonogram i jako wszystkich zewntrznych produktw, ktre maj by dostarczone, a od ktrych zale jakie dziaania przewidziane w planie. Nale y sprawdzi, czy takie elementy jak urlopy i szkolenia nie maj wpywu na harmonogram. Nale y przygotowa dziaania, ktre bd podejmowane w przypadku choroby pracownika, ktrego nie mo na zastpi. Nale y przeszkoli inne osoby jako zabezpieczenie dla zasobw krytycznych lub rzadkich umiejtnoci. Dodanie dziaa dotyczcych zarzdzania ryzykiem wydu y harmonogram i bdzie wymagao dodatkowych zasobw. Korzyci z zabezpieczenia si przed zagro eniami s wartociowe, ale nale y pamita o kosztach tych dziaa wnoszonych do planu. Jeli projekt jest czci programu, wszelkie zagro enia zidentyfikowane na poziomie programu musz by sprawdzone pod wzgldem ich wpywu na projekt. Tam, gdzie ist-

21 2

PRINCE2

PLANOWANIE(PL)

nieje taki wpyw, zagro enie powinno by wprowadzone do Rejestru Ryzyka tego projektu. Nale y uwa nie sprawdzi, czy dalsza analiza tego zagro enia na poziomie projektu jest potrzebna. Podobnie, ka de zagro enie dla projektu powinno by zbadane pod ktem jego wpywu na program.

11.10. Kompletowanie Planu (PL7)

11.10.1.
Podstawowe zasady

Plan to nie tylko diagram. Plan jest niekompletny, jeli nie zawiera pewnych uzupeniaj- opisowych. Trzeba zdecydowa, w jakiej formie przedstawi plan cych czci Komitetowi Sterujcemu.

11.10.2.

Kontekst

Majc poczucie, e harmonogram i ocena ryzyka wykonane zostay w sposb zadowalajcy, trzeba zo y w cao: plan, oszacowanie kosztw, wymagane elementy kontroli towarzyszce oraz czci opisowe.

11.10.3.

Opis procesu

Cz opisowa powinna by dodana w celu objanienia planu, jego ogranicze, zewntrznych zale noci, przyjtych zao e, zidentyfikowanych zagro e oraz zwiza- nimi dziaa zaradczych. Sugerowane zawartoci czci opisowych Plan nych z Projektu i Plan Etapu podane s w Dodatku A Zarysy Opisw . Produktw W tym mo mencie nale y doda do planu odpowiednie produkty zarzdcze. Opis planu Plan nie bdzie cakowicie zrozumiay bez tekstu objaniajcego: co plan obejmuje (np. konkr etny etap, projekt, konkretne produkty); przyjte podejcie planistyczne; zamierzone podejcie do realizacji planu (np. liczba etapw, wielko Grup Zada); sposb, w jaki plan bdzie monitorowany i kontrolowany; jakie raporty zarzdcze bd przedstawiane; wszelkie przewidywane ograniczenia; zagro enia zwizane z planem oraz podjte dziaania zapobiegawcze; zale noci zewntrzne; poczynione zao enia - cznie z zao eniami planistycznymi; tolerancje, ktre maj by zastosowane; 213

PLANNING (PL)

PRINCE

metody kontr oli jakoci or az zasoby, ktre maj by u yte (Plany Etapw i Plany Zespow).

Element y sterowania planem Niektre czynnoci zwizane z monitorowaniem zagro e mog ju by dodane do pla- ale w tym momencie wystpuje tak e potrzeba dodania do planu wytwarzania nu, wszel-wymaganych produktw zarzdczych, poniewa zu yj one prac i czas. kich Przykadami mog by: Raporty z Punktw Kontrolnych w Planie Zespou, Raporty Okresowe i Raport Kocowy Etapu w Planach Etapw. Graficznym przedstawieniem planu jest zwykle wykres Gantta lub wykr es paskowy. Wikszo pakietw oprogramowania do planowania i kontroli dostarcza raporty w takim formacie. Pakiety zapewniaj tak e raporty o kosztach i wymaganych zasobach, zwykle formie w arkusza kalkulacyjnego. Wikszo materiaw do czci opisowej planu bdzie rozwijana w miar realizowania krokw cyklu planowania. Niektre z nich bd ju znane ze wzgldu poprzednich na spjno ze standardami lokalnymi. Przedziay tolerancji dla planu powinny by uzgodnione z wy szym poziomem zarzdza- noci od takich czynnikw jak wielko, zo ono i ryzyko projektu nale nia. W zale yzgodni granice tolerancji, czyli jaka wielko odchylenia od planowanych u kosztw, zakresu, korzyci biznesowych i dopuszczalnego ryzyka bdzie terminu, dopuszczona, uznane, e doszo do istotnego odchylenia od planu. Tolerancje s zanim zostanie rozwaane peniej w Rozdziale 16 Elementy . sterowania Produkty cyklu planowania powinny by sprawdzone pod wzgldem kompletnoci i sensownoci przez osoby dowiadczone w planowaniu i znajce przedmiot projektu. Plany y poprawi zgodnie z wymaganiami kontroli nale jakoci. Lista Kontrolna Produktw jeli ma by wprowadzona jest w tym podprocesie uzupeniana pobieranymi z planu datami rozpoczcia i koca.

11.10.4.

Odpowiedzialno

Kierownik Projektu jest odpowiedzialny za skompletowanie ka dego planu, korzystajc z pomocy Kierownikw Zespow, gdy jest to celowe, oraz osb penicych rol Wsparcia Projektu, jeli s dostpne. Osoby penice obowizki Nadzoru Projektu mog chcie przejrze plan(-y) oraz jego opis(y).

11.10.5.

Wymagania informacyjne Wymagania informacyjne podprocesu zarzdcza Wykorzystanie

Tabela 11.7. PL7 Informacja Objanienie

Oceniony plan Wejcie Podstawowe produkty kocowego pakietu planistycznego.

21 4

PRINCE2

PLANOWANIE(PL)

Informacja Objanienie

zarzdcza

Wykorzystanie

Lista Kontrolna Produktw Aktualizacja Gdy jest u ywana - daty rozpoczcia i koca dodane do listy. Skompletowany plan do zatwierdzenia Wyjcie Do zatwierdzenia przez nastpny wy szy poziom zarzdzania projektem.

11.10.6.

Kryt eria oceny ci jako Rozwa ajc odpowiednie wartoci tolerancji, jaki jest poziom ufnoci tego planu? Czy podczas ustalania wartoci tolerancji wzito pod uwag zagro enia dla biznesu i ograniczenia? Czy forma prezentacji materiau planu zostaa uzgodniona z Komitetem Sterujcym? Czy narzdzie planistyczne pozwoli uzyska akceptowalne formaty i jako do prezentacji ?

Wskazwki i rady
Plany powinny by proste. Dobr zasad jest umieszczenie wszystkich planw graficzne prezentowanych Komitetowi Sterujcemu na jednym arkuszu papieru. W ten sposb plan jest atwy do przygotowania i czytania, dlatego te jest bardziej prawdopodobne, e bdzie zrozumiany. Wszystko, co nie mo e by przedstawione w ten sposb, powinno by streszczone, a szczegy wczone do ni szego poziomu planu. Podobnie, nie naley u ywa zo onych symboli ani prezentowa planw, ktre wymagaj specjalistycznego wyksztacenia albo zbyt wielu wyjanie, by zostay zrozumiane. Warto rozwa y zastpienie wersji graficznej Planu Projektu List Kontroln Produktw. Nie nale y polega tylko na prezentacji graficznej. W planowaniu niekoniecznie sprawdza si powiedzenie, e obraz zastpuje tysic sw. Chocia wykres Gantta mo e pokaza, co powinno si zdarzy i nastpnie, co si faktycznie zdarzyo, to jednak nie pokazuje, dlaczego to powinno si zdarzy w taki wanie sposb albo dlaczego jaki element odbiega od planu. Opis planu zawiera myl przewodni, ktra do niego doprowadzia, zao enia przyjte podczas przygotowywania planu i zwizane z nim zagro enia. Jest to szczeglnie wa ne przy prezentacji planw do zatwierdzenia. Czytajcy s wtedy w stanie zaakceptowa zarwno plany, jak i zao enia oraz zagro enia za nimi stojce, Pozwala to planujcemu uzyska od kierownictwa zatwierdzenie, oparte na informacjach, oraz ich zaanga owanie w te plany. Jeli ukad raportu uzyskiwanego za pomoc pakietu oprogramowania nie jest zadowalajcy, dane mog by zwykle przeniesione do arkusza kalkulacyjnego lub pakietu graficznego, w ktrym bdzie mo na skonstruowa wymagany ukad prezentacji. Kierownik Projektu, zanim formalnie zaprezentuje Plan Etapu w celu uzyskania zatwierdzenia, powinien nieformalnie przedyskutowa go z Komitetem Sterujcym i osobami mianowanymi do Nadzoru Projektu. Prezentacja planu powinna by dostosowana do suchaczy. W pewnych warunkach moe by konieczne rozbicie planu na dalsze szczegowe obszary do wykorzystania przez zespoy lub pojedyncze osoby.

215

PLANNING (PL)
Nale y si wystrzega opracowania zbyt zo onego planu, zawierajcego wiele szczegw, ktre mo na lepiej przekaza w formie opisowej. Zagmatwany lub zbyt szczegowy plan mo e wyczy uwag czytajcego. Pomocne jest, gdy zao enia s spjne we wszystkich projektach programu.

PRINCE

21 6

12.

W PR OWAD ZE NI E DO K OM P ONE N TW M E TODY K I P RI NC E2

Sterowanie zmianami
d za n Za rz ie St ra t e gi c zn e P roj e kt e m d rz za n ZaS4 ie St ra t e gi c zn e P roj e kt e m Z

Uzasadnienie biznesowe

Z S4 Z S2 ZS 3 Z S5 Z S1 Z S1 Z S2 ZS 3 Z S5
d za n Za rz ie da n zak ie Za rz re s e m Z Z a apre s e m Et k u E t ap u Za m owa wa S er owa ni Int zy y k a ni e Pr ic jgo toni e ni e Za zy y k to ni S roj go t uni e Int a jeowani e Pr ic pekmtauwa ni e er m Et oje k P rojeowa Etroje P roj e kt u Pr a pekmtu oje dz rz Za a nie dz nie Za atw ar Wyrz owaza n ie m P la n ni e Wy n ar nin roduk t P la twowazawe ie m P roduk t w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 12.1. PRINCE2

Model strukturalny metodyki

Jak pokazuje Rysunek 12.1, PRINCE2 obejmuje pewn liczb komponen tw, ktre s ywane w procesach. S to: u Uzasadnienie biznesowe; Organizacja ; Plany; Elementy sterowania; Zarzdzanie ryzykiem; Jako w rodowisku projektu;

Zarzdzanie konfiguracj; Sterowanie zmianami. Nastpne rozdziay podrcznika przedstawiaj istot tych komponentw oraz sposb, w jaki powinny by one u ywane. S tam tak e wskazwki i rady, dotyczce u ycia i dopasowania komponentw, tak by odpowiaday one r norodnym sytuacjom i typom projektw. 21 7

13.
Uzasadnienie Uzasadnienie biznesowe biznesowe
dz rz Za an ie St ra t e gi c zn e P roj e k te m dz rz an ZaS4 ie St ra t e gi c zn e P roj e k te m Z

U ZAS AD NI E NI E B IZN E SO WE
BUSINESS CASE

Sterowanie zmianami

Z S4 Z S2 Z S3 Z S5 Z S1 Z S1 Z S2 Z S3 Z S5
dz rz Za a nie dz k rzre Za a nie s e m Za k re s e m E t a pu E t a pu Z a j owa n S rz rowa n e I t emy k owa P nic yg otani ie ni e Z rojeeowaowa S rz pe ot u n I t amy kt ani e P nic ygkmtun ie ni e ae j Etroje k Proj rowa Etroje Proj pe kt u P rojeekmtu a dz rz Za a ni e dz ni e Za atw a rza n Wyrz owa n ie ie m Pl an Wy tw k n n P an owat ie Plrodu a rzaw ie m P rodu k t w

Zarz dzanie konfiguracj

Cl o si ng a Pro j ec t

Organizacja

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 13.1. struktural-

Komponent Uzasadnienie biznesowe, w modelu nym metodyki PRINCE2

Rozdzia ten przedstawia podejcie do rozwoju Uzasadnienia Biznesowego projektu. zasad PRINCE2 jest uznanie, e Uzasadnienie Biznesowe projektu jest Kluczow jego napdow. si Jeli Uzasadnienie jest niewystarczajce, projekt nie Biznesowe wystartowa. Jeli Uzasadnienie Biznesowe powinien jest suszne w chwili rozpoczcia projektu, trakcie jego trwania zanika, projekt powinien zosta zatrzymany. ale w Uzasadnienie Biznesowe powinno obejmowa ca o zmiany biznesu, a nie skupia si tylko na nym jego elemencie, np. przy kupnie jednowego wyposa enia powinno si bra pod uwag tak e jego wpyw na personel, szkolenie, zmienione procedury, zmiany wynikajce z koniecznoci przygotowania pomieszcze, koszty eksploatacji, relacje ze spoecznoci itd. W PRINCE2 Uzasadnienie Biznesowe okr elane jest na pocztku projektu i aktualizowa- ycie projektu, podlegajc przegldowi przez Komitet Sterujcy w ka ne przez cae dym kluczowym punkcie decyzyjnym, takim jak np. oceny kocowe etapw.

13.1.

Czym jest Uz asadnienie Biznesowe?

Uzasadnienie Biznesowe jest opisem przyczyn i uzasadnieniem podjcia projektu, na szacowanych kosztach projektu, ryzyku oraz spodziewanych opartym korzyciach i oszczdnociach.

21 9

BUSINESS CASE

PRINCE2

Uzasadnienie Biznesowe obejmuje caoksztat zmian w obszarze biznesowym, na ktry projekt oddziauje. Uzasadnienie Biznesowe jest najwa niejszym zbiorem informacji dla projektu. Kie- procesami decyzyjnymi i u ywane jest nieustannie do uzgadniania ruje postpw ze zdefiniowanymi w nim celami/korzyciami projektu biznesowymi. Uzasadnienie Biznesowe powinno by przygotowane zgodnie z wszelkimi istniej-standardami organizacyjnymi oraz z natur projektu. Opracowanie i cymi zatwier- Uzasadnienia Biznesowego w niektrych przypadkach bdzie dzenie wymagao wysiku, gdy np. projekt bdzie mia du y wpyw na organizacj. znacznego Mniejszy wysiek i zaanga owanie bd potrzebne, gdy projekt jest autonomiczny i ma minimalny wpyw na pozostae czci organizacji. Wymagany poziom inwestycji tak e bdzie wpywa na sposb i r ygor opracowywania Uzasadnienia Biznesowego.

13.2.

Co powinno zawiera

Uzasadnienie Biznesowe?

Jest wiele r nych postaci Uzasadnienia Biznesowego. Ka de Uzasadnienie Biznesowe powinno zawiera wystarczajco du o informacji zarzdczych, aby mogo by wykorzy-efektywnie w trakcie caego projektu. W PRINCE2 Uzasadnienie Biznesowe stywane jest wspierane przez inne dokumenty, jak np. Rejestr Ryzyka. Minimalnym wymogiem meto- PRINCE2 jest, aby Uzasadnienie Biznesowe zawierao informacje dyki przedstawione podrozdziaach. S to tytuy rozdziaw spisu treci przedstawionego w poni szych w punkcie Skad zarysu Opisu Produktu Uzasadnienie Biznesowe, przedstawionego w Dodatku A.

13.2.1.

Przyczyny uruchomienia projektu

W tej sekcji wyjania si powody, dla ktrych potrzebny jest kocowy wynik projektu. Ta informacja powinna si znajdowa w Zleceniu Przygotowania Projektu. Jeli nie podano jej tam, ten obszar wymaga dalszych bada w trakcie Przygotowani procesu (PP) prowadzcych do jasnego ustalenia powodw podjcia e Projekt u projektu. Mo liwe wariant y realizacji produktu cowego ko Ta sekcja powinna opisywa w zarysie r ne rozwizania, ktre byy rozwa ane jako liwiajce osignicie wymaganego rezultatu. Nale y wskaza wybrany umo wariant przedstawieniem powodw uzasadniajcych dokonany wybr. Informacja ta wraz z sta- gwarancj, e rozwa ono warianty alternatywne. Zawsze nale y rozwa y nowi wariant niepodejmowania adnych dziaa i jego konsekwencje, czynic z niego punkt odnie- dla innych mo liwych wariantw sienia postpowania.

13.2.2.

13.2.3.

Oczekiwane korzy

ci

Ta sekcja powinna opisywa wszystkie korzyci, ktrych osignicie spodziewane jest dziki wynikom projektu. Ka da z nich powinna by dokadnie opisana w mierzalnych Wa ne jest zdefiniowanie aktualnego statusu ka dej korzyci w sposb kategoriach. ilociowy, aby mc w mierzalny sposb oceni popraw sytuacji po zakoczeniu projektu. zwrci uwag na okrelenie, jak i kiedy mo na przeprowadzi pomiar Nale y poprawy 22 0

PRINCE2

UZASADNIENIE BIZNESOWE

wynikajcej ze zmian. Przewodniczcy odpowiada za zdefiniowanie oczekiwanych korzyci. Negatywny sposb oceny korzyci mo e by u yteczny jako cz oglnego uzasad-projektu. Opisuje si wwczas, co si stanie, jeli projekt nie zostanie nienia wykonany, utrata udziau w rynku, bd du e koszty utrzymania, wysokie kary za np. nastpi niedostosowanie do nowych przepisw prawa.

13.2.4.

Ryzyko

Ta sekcja zawiera zestawienie gwnych zagro e dla projektu, - jeli ktre faktycznie wystpi - mog w sposb istotny wpyn na osignicie planowanych rezultatw. Szczegy opisujce, jak bdzie si zarzdza ryzykiem wynikajcym z tych zagro e, s przedstawione w Rejestrze Ryzyka. Koszty i terminy Te informacje pochodz z Planu Projektu. Jeli Plan Projektu nie zosta jeszcze skomple-mo e by konieczne wstpne oszacowanie kosztw i terminw projektu w towany, Uzasadnieniu Biznesowym i doprecyzowanie ich, gdy Plan Projektu bdzie skompletowany. ci inwestycji Ukazuje rwnowag midzy kosztami wytworzenia, eksploatacji, utrzymania i serwiso-a finansow wartoci korzyci w przecigu jakiego czasu. Okres ten mo e wania, by okrelony poprzez podanie konkretnej liczby lat lub jako czas u ytkowania produktu. Punktem odniesienia dla oceny opacalnoci inwestycji jest wariant niepodejmowania i utrzymania stanu obecnego, tj. odpowied na pytanie: Jaki adnych dziaa bdzie obraz kosztw i korzyci, jeli projekt nie zostanie podjty? - Porwnuje si go obrazem oczekiwanym w wyniku zr ealizowania z projektu. Jeli to mo liwe, korzyci powinny by wyra ane w sposb mierzalny. Na pocztk ulient, u ytkownik lub Przewodniczcy mog okr ela wiele korzyci jako k niewymierne, zadowolony personel. Warto zrobi wysiek i dokadnie przemyle, np. bardziej czy okrelonych korzyci nie mo na wyrazi w sposb bardziej wymierny. Na tak przykad zadowolenie personelu mo na mierzy mniejsz rotacj personelu i/lub skr wiksze ceniem czasu traconego na rozwizywanie stresujcych problemw. Oba mierniki mo na ju wyrazi w kategoriach prawdopodobnego zmniejszenia kosztw.

13.2.5.

13.2.6.

Ocena opacalno

13.2.7.

Ocena oglna

Jest wiele sposobw oszacowania oczekiwanych korzyci oraz oceny opacalnoci inwestycji . p. mo na zastosowa analiz wra liwoci do okrelenia, czy Uzasadnienie N Biznesowe uzale nione od konkretnej korzyci. Jeli tak jest, mo e to wpyn na jest silnie plano- projektu, monitorowanie i dziaania kontrolne oraz zarzdzanie r yzykiem, wanie gdy e zaistnie potrzeba podjcia dziaa w celu ochrony tej mo korzyci.

221

BUSINESS CASE

PRINCE2

Inny przykad polega na zdefiniowaniu trzech perspektyw osigania korzyci, tj.: czego si rzeczywicie oczekuje; co mo na osign, jeli sprawy pjd dobrze; jaki mo e by scenariusz w najgorszym przypadku? Na ostatni z nich mo na wpyn poprzez zwik- kosztw o warto uwzgldniajc niedokadnoci oszacowa, tolerancje i szenie ryzyko. Ta technika jest czasem okrelana mianem analizy GAP (Good Average Poor,dobry redni saby). Analiza GAP pokazuje zwykle, czy przewidywania tzn. korzy- rozsdne lub czy s przesadnie optymistyczne. Wynik tej analizy mo e ci s prowadzi decyzji dotyczcej dalszego prowadzenia projektu, co z kolei mo e do rewizji stanowi do wyznaczenia tolerancji dla podstaw korzyci.

13.3.

Opracowanie Uzasadnienia Biznesowego

Przewodniczcy jest wacicielem Uzasadnienia Biznesowego projektu. Do obowizkw Przewodniczcego nale y zapewnienie, aby cele projektu, koszty, korzyci waciwie dostosowane do strategii biznesowej firmy lub celw itp. byy programu. Przewodniczcy mo e delegowa opracowanie Uzasadnienia Biznesowego Kierow-Projektu. Jednak e dane, na podstawie ktrych uzasadnienie bdzie nikowi rozwija- w du ej mierze dostarczone przez biznes, a odpowiedzialno za ne, bd posiadanie przez projekt precyzyjnego i efektywnego Uzasadnienia Biznesowego spoczywa na Przewodniczcym. W du ych projektach do opracowania zawartoci Uzasadnienia mo e by powoany niewielki zesp ekspertw. W maych Biznesowego projektach przy opracowaniu niezbdnej do sporzdzenia Uzasadnienia informacji e by potrzebna tylko jedna Biznesowego mo osoba. W trakcie przygotowania projektu do opracowania Uzasadnienia Biznesowego wykorzystuje si informacje pochodzce ze Zlecenia Przygotowania Jeli Projektu. jest czci programu, wiele wymaganych informacji powinno by projekt dostp- w ramach dokumentacji przechowywanej na poziomie programu. nych Projekty prowadzone w rodowisku programu mog same nie przynosi korzyci bizneso-Mog one by potrzebne do dostarczenia produktw, ktre stanowi wych. warunki dla innych projektw. Uzasadnienie Biznesowe powinno to wstpne odzwierciedli. Podczas inicjowania Uzasadnienie Biznesowe jest aktualizowane i doprecyzowywane, celem dostarczenia bardziej szczegowych informacji o korzyciach, ryzyku, mo liwych wariantach i kosztach. Od chwili swego skompletowania, Plan Projektu o janiejszy pogld na ryzyko i koszty. Informacje te wykorzystywane s daje du do doprecyzowania oceny opacalnoci inwestycji lub analizy GAP. Szczegowe in- macje o zagro eniach s przechowywane w Rejestrze Ryzyka w celu umo for liwienia formalnego monitorowania zagro e w trakcie projektu. Od Przewodniczcego wymaga si formalnego zatwierdzenia Uzasadnienia Bizne- , co jest zapewnieniem, e wy sze kierownictwo anga uje si w projekt. sowego Zatwierdzenie to stanowi cz formalnego przegldu przeprowadzanego na kocu Inicjowanie procesu (IP). Projektu Podczas ka dego etapu projektu Uzasadnienie Biznesowe podlega przegldom w celu potwierdzenia, e projekt pod a we waciwym kier unku oraz w celu spraw- czy zachowuje ono wa no w aktualnym kontekcie biznesowym. dzenia, Uzasad- Biznesowe wymaga formalnego zarzdzania konfiguracj w celu nienie zapewnie- wszelkie zmiany w rodowisku projektu zostay dokadnie nia, e odzwierciedlone przed weryfikacj Uzasadnienia Biznesowego. Uzasadnienie i zatwierdzone Bizne-

22 2

PRINCE2

UZASADNIENIE BIZNESOWE

sowe pozostaje ywym dokumentem w trakcie projektu, a wszystkie decyzje odnoszce si do postpw projektu podejmowane s z jego wykorzystaniem jako sterownika. Uzasadnienie Biznesowe dostarcza wszystkim interesariuszom podstawowych informacji o projekcie. Plan Komunikacji powinien okrela, jak i kiedy informacje Uzasadnienia Biznesowego maj by przekazywane interesariuszom dotyczce oraz mog oni dostarcza informacji zwrotnej i zgasza zagadnienia dotyczce jak Uzasadnienia Biznesowego . Przy zamykaniu projektu, Uzasadnienie Biznesowe wykorzystywane jest do potwierdzenia, e projekt dostarczy wymagane produkty i e spodziewane korzyci mog by zrealizowane przez biznes w stosownym przedziale czasu. Uzasadnienie Biznesowe stanowi podstaw przygotowania Planu Przegldu Poprojektowego, zapewniajc, by pniejsza ocena, czy zrealizowano zaplanowane korzyci, bya cile powizana z Uzasadnieniem Biznesowym.

13.4.

cie ka rozwoju Uzasadnienia Biznesowego

Zlecenie Przygotowania Projektu powinno zawiera niektre podstawowe elementy Uzasadnienia Biznesowego. W tym czasie wystarczy podanie tylko kilku przyczyn poszuki-rozwizania. Jeli projekt jest czci programu, Zlecenie Przygotowania wania Projektu mo e by jedynie wskazaniem na Uzasadnienie Biznesowe programu. Jeli projekt zosta poprzedzony studium wykonalnoci lub czym , Zlecenie Przygotowania podobnym zawiera kopi Uzasadnienia Biznesowego dla preferowanej Projektu bdzie opcji. W zale noci od tego, jak wiele danych na temat Uzasadnienia biznesowego znalazo si Zleceniu w Przygotowania Projektu, Przygotowanie Zao Projekt (PP4) podproces doprowadzi te informacje do poziomu podstawowego, to znaczy e u powinien takiego, stanowi one wystarczajce uzasadnienie dla Komitetu Sterujcego, umo w ktrym liwiajce mu przeprowadzenie Zezwolenie na Zainicjowanie (ZS1). podprocesu Projektu Doprecyzowywanie Uzasadnienia Biznesowego i (IP3) jest podprocesem, w Ryzyka rym Uzasadnienie Biznesowe uzyskuje swj peny ksztat kt- cz Dokumentu jako Inicju- Projekt. Zawiera ono wwczas najbardziej aktualne informacje zaczerpnite jcego z lanu Projektu o kosztach i czasie wyznaczonym na wykonanie produktu. Jeli nie P uczy- tego wczeniej, to wanie w tym podprocesie zostan zdefiniowane (lub niono zweryfi- wszystkie korzyci biznesowe kowane) - gdziekolwiek to mo - wyra one w katei liwe Komitetowi Sterujcemu do goriach mierzalnych. Jest ono potrzebne przeprowadzenia podprocesu Zezwolenie na Projekt (ZS2), a tak e do przygotowania si Realizacj u do przegldu poprojektowego. W ramach Uaktualnienie Uzasadnienia (ZE3), przed podprocesu dego Raportu Kocowego Etapu i planu kolejnego etapu, Uzasadnienie Biznesowego przygotowaniem ka Biznesowe podlega przegldowi poprzez uwzgldnienie informacji o koczonym etapie pro- i plan nastpnego etapu. Ta zrewidowana wersja Uzasadnienia Biznesowego jektu jest Komitetu Sterujcego gwnym uzasadnieniem decyzji podejmowanej w dla podprocesie Zezwolenie na Planu Etapu lub Planu (ZS3). Realizacj Nadzwyczajnego

223

BUSINESS CASE Jako cz podprocesu Analizowanie Zagadnie Projektowe podlega przegldowi, aby Uzasadnienie Biznesowe .

PRINCE2 Projektowyc (SE4) ka de Zagadnienie okrelih wpyw jaki mo e mie na

Na koniec projektu Uzasadnienie Biznesowe jest podstaw przygotowania du ej czci Przegldu Poprojektowego, przedstawianego przez Kierownika Projektu jako Planu jeden z wynikw podprocesu Okr lenie Nas pczyc (ZP2) . e Dziaa t h Wskazwki i rady
Mo e by po yteczne zorganizowanie seminarium dla interesariuszy, by pomc im zrozumie cele biznesowe i oddziaywanie projektu. Uwzgldnienie w Uzasadnieniu Biznesowym informacji uzyskanych od interesariuszy pomo e osign ich wiksze zaangaowanie si w projekt. Nale y si zastanowi, i to zanim projekt zacznie by realizowany, nad ustaleniem stanu odniesienia dla pomiaru korzyci, tak aby mo na byo porwna z nimi wyniki kolejnych pomiarw dla zademonstrowania, e projekt przynis korzy(-ci).

22 4

14.

OR GA NI ZAC JA
ORGANISATION

Sterowanie zmianami
dz nie Z aarz S tr a te g ic z ne P roje k te m dz nie Z aarz S tr a te g ic z ne P roje k te m

Uzasadnienie biznesowe

Organizacja Z S4 Z S4 Z S2 ZS 3 Z S5 Organizacja ZS 1
ZS 1 Z S2 ZS 3 Z S5
dz rz Za a n ie dz k rzre Za a n ies e m Za k re Et a pu s e m Et a pu Za S ic yg k n an Inrz r owa owee P temjy otani ie ie owa ni Za icr owa ni S rojyg kt un an Inrz jeykmtau ee P temjeowaowie ie k Pro Et P a pe ot ni Pro Et a jee kt u P rojpekmtu dz rz Za a n ie dz rz wa Za atn ie rz a ni e m Wy P la n owa n ie Wy tnwa rzwni e m rod owa a P la uk t n ie P rod uk t w

Zarz dzanie konfiguracj

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 14.1. strukturalnym

Komponent Organizacja, metodyki PRINCE2

modelu

14.1.

Oglne omwienie

Struktura zarzdzania projektami zgodnymi z PRINCE2, opiera si na wystpowaniu rodowiska klient/dostawca. Zakada si istnienie klienta, ktry okreli po dany rezultat,wykorzystywa ten rezultat i prawdopodobnie zapaci za projekt. Zakada si bdzie te istnienie (generalnego) dostawcy, ktry dostarczy zasobw i umiejtnoci, umo liwiajcych wytworzenie tego rezultatu. To zao enie warunkuje sposb organizacji projektu. Klient i dostawca mog stanowi cz tej samej firmy lub by niezale ni jeden od drugiego. Ustanowienie efektywnej struktury organizacyjnej dla projektu decyduje o jego powo- W ka dym projekcie istnieje potrzeba zarzdzania strategicznego, dzeniu. kierowania,komunikowania si. PRINCE2 proponuje podejcie, ktre zapewnia te nadzoru i elemen- wystarczajco elastyczne, by wdro y je w ka dym ty i jest rodowisku. Projekt wymaga struktury organizacyjnej odmiennej od tej, ktr stosuje si w zarzdzaniu operacyjnym firmy. Musi ona by bardziej elastyczna i wymaga szerokiego spektrum umiejtnoci w stosunkowo krtkim czasie. Zwykle projekt anga uje zasoby pochodzce 22 5

ORGANISATION

PRINCE2

z r nych pionw funkcyjnych firmy i wymaga ich wspdziaania. Organizacja projektu mo e czy osoby, ktre pracuj nad projektem w penym wymiarze godzin, z innymi, ktre musz dzieli swj czas midzy projekt i inne obowizki. Kierownik Projektu mo eprawowa s bezporedni kontrol zarzdcz nad czci personelu uczestniczcego w projekcie, ale mo e te musie kierowa personelem, ktry podlega innej strukturze zarzdczej. Struktura zarzdzania tych, ktrych dotyczy rozwizywany problem, bdzie czsto r na struktury tych, ktrzy dostar czaj to rozwizanie. Obie organizacje bd miay r od ne priorytety, bd chroni r ne interesy, ale w jaki sposb bd musiay zjednoczy si ramach wsplnych celw projektu. Szczebel zarzdzania, ktry bdzie w podejmowa decyzje i zobowizania su ce r ealizacji jego interesw, mo e by zbyt zajty, aby an-owa si w sposb cigy w bie ce sprawy projektu. Z kolei projekty, jeli maj ga si powie, wymagaj bie cego zarzdzania.

14.1.1.

Cztery warstwy struktury zarz

dzania projektem

PRINCE2 oddziela zarzdzanie projektem od pr ac wymaganych do wytworzenia produk-i koncentruje tw si na zarzdzaniu. Fundamentaln zasad jest to, e struktura zarzdzania projektem skada si z czterech patrz warstw Rysunek 14.2: zarzdzanie firm lub programem; zarzdzanie strategiczne projektem (Komitet Sterujcy); bie ce zarzdzanie projektem (Kierownik Projektu); zarzdzanie zespoem(-ami) i dostarczanie produktw (Kierownicy Zespow). Pierwsza z tych warstw powouje projekt i okrela oglne ogr aniczenia. Zesp zarzdzania projektem obejmujcy pozostae trzy warstwy, zarzdza projektem i realizuje go w wymiarze technicznym.
Kierownictwo firmy lub programu

Komitet Steruj cy Zesp zarz dzania projektem

Kierownik Projektu

Kierownik Zespou

Rysunek 14.2. projektem 22 6

Cztery warstwy zarzdzania

PRINCE2

ORGANIZACJA Struktura zarz dzania projektem

14.1.2.

PRINCE2 przewiduje struktur zespou zarzdzania projektem, ktra zapewnia: istnienie rl decydentw; mo liwo zarzdzania odchyleniami przez decydentw; mo liwo zarzdzania projektem w penym lub niepenym wymiarze godzin; sterowane delegowanie Kierownikom Zespow niektrych bie cych obowizkw, z zarzdzaniem, gdy jest to zwizanych potrzebne; istnienie rl dla niezale nej kontroli wszystkich aspektw wykonania projektu; wsparcie administracyjne dla Kierownika Projektu i Kierownikw Zespow (jeli jest potrzebne); porozumienie wszystkich zainteresowanych, czym s poszczeglne role w zespole zarzdzania projektem i jakie wi si z nimi obowizki; linie komunikacyjne midzy czonkami zespou zarzdzania projektem. Struktura zarzdzania projektem (Rysunek 14.3) obejmuje role i obowizki, ktre cz w jedno r ne interesy i umiejtnoci wystpujce i potrzebne w projekcie. Aby projekt zakoczy si powodzeniem, wa ne jest zdefiniowanie tych rl na jego starcie. Struktura zarzdzania projektem jest struktur czasow, specjalnie zaprojektowan do zarzdzania projektem a do jego pomylnego zakoczenia, aby speni wymagania zdefiniowane w Zao eniach Projektu. Wyznacza ona kanay komunikacji dla gremiw podejmujcych decyzje i powinny jej towarzyszy opisy stanowisk wyszczeglniajce: obowizki, cele, zakresy uprawnie, relacje, umiejtnoci, wiedz i dowiadczenie, wymaga- wszystkich rl w organizacji ne dla projektu.
Kierownictwo firmy lub programu

Komitet Steruj Gwny ytkownik U Przewodnicz

cy cy Gwny Dostawca
Legenda

Nadzr Projektu

Ze strony klienta Ze strony dostawcy(-w)

Kierownik Projektu Wsparcie Projektu Kierownik Zespou

Obowizki nadzoru Linie wytycznych / rad Linie podlegoci

Rysunek 14.3. projektem

Struktura

zarzdzania

227

ORGANISATION Ka da z rl, ktre przedstawia Rysunek 14.3 posiada towarzyszcy jej opis.

PRINCE2

Aby zapewni elastyczno i sprosta potrzebom r nych rodowisk i projektw o r nej wielkoci, PRINCE2 nie stanowis zarzdczych, ktre maj by definiuje wedug zasady: jedna osoba - jedno stanowisko. PRINCE2 k powierzone osobom rol , ktre definiuje mog by powierzane, sprawowane wsplnie, dzielone lub czone zgodnie z e potr zebami projektu. Wynika to z przyjtej koncepcji, w myl, ktrej pewne obowizki przypisane mog by przeniesione do innej roli lub delegowane, ale nie powinny by danej roli pominite. Jeli jaki obowizek zostaje pominity, nale y wzi pod uwag ryzyko zwizane z takim postpowaniem. Niektre z rl PRINCE2 nie mog by wspdzielone lub delegowane, jeli maj by realizowane skutecznie. Rola Kierownika Projektu nie mo e by peniona przez kilka osb. mo na tak e delegowa decyzyjnych uprawnie Kierownika Projektu lub Nie Komitetu Sterujcego. Nawet wtedy, gdy uprawnienia do penienia roli Nadzoru Projektu zostay delegowane przez czonkw Komitetu Sterujcego innym osobom (patrz: podrozdzia 14.2.4), Komitet Sterujcy cigle jest odpowiedzialny za dziaania nadzorcze. Kultury firm r ni si midzy sob, ale metodyka PRINCE2 mo e by stosowana nieza- od kultury czy struktury organizacyjnej le nie firmy. Wskazwki i rady
Uzgodnienia kontraktowe i handlowe bd czsto wpyway na przedstawion wzorcow organizacj zarzdzania projektem. Struktura organizacyjna projektu powinna zapewnia styk z bardziej trwaymi operacyjnymi lub funkcjonalnymi strukturami zarzdczymi, istniejcymi zarwno w firmach klienta. , jak i dostawcy

14.1.3.

Trzy strony interesw obecne w projekcie

Rysunek 14.4 oddaje struktur i skad Komitetu Sterujcego. Trzy, przedstawione na nim, interesw musz by przez cay czas reprezentowane w Komitecie strony Sterujcym.

Biznes

U ytkownik Dostawca

Rysunek 14.4. projekcie 22 8

Trzy strony interesw wystpujce w

PRINCE2 Biznes

ORGANIZACJA

Produkt(-y) projektu musz zaspokaja jak potrzeb biznesow. Projekt powinien warto adekwatn do poniesionych nakadw finansowych. Zatem powinna przynie istnie reprezentacja punktu widzenia biznesu, aby zapewni, e te dwa warunki wstpne bd spenione, zanim jeszcze dojdzie do zaanga owania si w projekt oraz w trakcie caego okresu jego realizacji. PRINCE2 dokonuje rozr nienia midzy grup interesw wymaganiami tych, ktrzy bd u ywa kocowy(-e) produkt(-y) projektu. biznesu a Ro- Przewodniczcego zdefiniowano tak, by troszczy si on o interesy biznesu l (reprezentujc . klienta) U ytkownik Zawsze wystpi osoba, grupa lub grupy, do ktrych stosowa si bd wszystkie lub niektre z nastpujcych stwierdze: bd u ytkoway kocowy produkt projektu; produkt pozwoli im osign jaki cel; bd wykorzystyway rezultat kocowy biznesowych;

projektu

do

dostarczenia

korzyci

rezultat projektu bdzie mia na nich wpyw. Obecno u ytkownika jest potrzebna do sprecyzowania po danego rezultatu i zapew- e projekt go dostarczy. Dlatego kierownictwo strony u ytkownika powinno nienia, by reprezentowane w Komitecie Sterujcym. Bdzie ono zwykle stanowi cz reprezentacji klienta. Dostawca Wytworzenie produktu kocowego bdzie wymaga zasobw z pewnymi umiejtnociami. Potrzebna jest reprezentacja dostawcy, ktry bdzie dostarcza tych koniecznych umiejtnoci. Do wytworzenia kocowego rezultatu w projekcie mog by wykorzystywane zarwno zespoy pochodzcych z wasnej firmy, jak i zespoy zewntrznego dostawcy. rodowisko klient/dostawca PRINCE2 jest okrelona w kategoriach rodowiska klient/dostawca. Istnieje wiele powiza klienta z dostawc, ktre mog wpyn na organizacj i sterowanie projektem, w szczeglnoci: klient ma wewntrznego dostawc. Nawet w takim przypadku strony mog posia- osobne bud ety, a co za tym idzie potrzebuj osobnych Uzasadnie da Biznesowych; projekty sponsor owane przez jednego klienta, w przeciwiestwie realizowanych dla wielu klientw; projekty realizowane przez jednego dostawc, w przeciwiestwie do tych wieloma dostawcami ; do z

14.1.4.

229

ORGANISATION

PRINCE2

sytuacje, w ktrych w gr wchodzi konsorcjum rwnorzdnych klientw i/lub dostawcw, w przeciwiestwie do tych, ktre wymagaj jednej z dwch form prawnych:

projekty realizowane wasnymi siami (cz rodzimej organizacji); projekty wykorzystujce ko mbinacj dostawcw wewntrznych i zewntrznych. Zarzdzanie strategiczne projektem realizowane przez Komitet Sterujcy musi by odbi- porozumie i decyzji trzech stron interesw, ktre zdefiniowano w ciem podrozdziale niektrych rodowiskach biznesowych mo e by trudno rozwa a 14.1.3. W reprezentacj dostawcy w Komitecie Sterujcym, ale musi istnie wsplna platforma dla decyzji,dotycz wszystkich stron. Rola Gwnego Dostawcy jest niezbdna, jeli ktre Komitet ma dysponowa peni mo liwoci podejmowania Sterujcy decyzji. Czasami mog wystpi kwestie poufnoci lub konfliktw interesw. Przedstawiciele klienta w Komitecie Sterujcym mog nie yczy sobie dyskutowania o wszystkim w obecnoci dostawcy, i na odwrt. Nic nie przeszkadza, aby obie strony odbyway odrbne spotkania dla podjcia wewntrznych decyzji i/lub przedyskutowania swego stanowiska przed spotkaniem z drug stron. Gwnym celem jest uzyskanie otwartej komunikacji i decyzji uzgodnionych przez wszystkie trzy strony, a skad Komitetu Sterujcego, obejmujcy Gwnego Dostawc, jest skuteczn pomoc w osigniciu tego celu. Jeli wystpuj problemy z identyfikacj zewntrznego kontrahenta, ktry mgby peni rol Gwnego Dostawcy (np. projekt obejmuje zakupy, a dostawca nie zosta jeszcze wybrany), kierownik zakupw klienta albo kierownik zarzdzajcy kontraktami mog podj si tej 21 . Ktokolwiek wystpuje w roli Gwnego Dostawcy, musi roli posiada odpowiednie uprawnienia, pozwalajce mu na dysponowanie zasobami dostawcy. W ukadzie klient/dostawca bd zawsze dwa Uzasadnienia Biznesowe: klienta i dostawcy. Jeli nie zaznaczono inaczej, wszelkie odniesienia w tym podrczniku do Uzasadnienia Biznesowego oznaczaj Uzasadnienie Biznesowe klienta.

14.2.

Zesp zarz

dzania projektem w PRINCE2

Poni ej przedstawiono w zarysie zesp zarzdzania projektem. Peny opis ka dej roli znajduje si w Dodatku B Role w zespole dzania . zarz projektem Komitet cy Steruj Komitet Sterujcy reprezentuje na poziomie zarzdczym interesy biznesu, u ytkownika zwizane z projektem. Czonkowie Ko mitetu Sterujcego musz posiada i dostawcy odpowiednie uprawnienia, poniewa s decydentami oraz osobami odpowiedzialnymi za zapewnienie projektowi zasobw, takich jak personel, pienidze i sprzt. Szczebel organizacyjny, z ktrego pochodz osoby potrzebne do penienia tych rl, b- zale a od takich czynnikw jak bud et, zakres i znaczenie projektu. Prowadzi dzie to czsto do tego, e w Komitetach Sterujcych zasiadaj osoby z wy szych szczebli zarz- Ich obowizki zwizane z Komitetem Sterujcym bd dodatkiem do ich dzania. normalnej pracy i z tego powodu istotne jest to, e PRINCE2 oferuje im jako sposb dziaania
21

14.2.1.

Reprezentowania interesw dostawcy przypis tumacza.

23 0

PRINCE2

ORGANIZACJA

zarzdzanie ,zapewniajc regularny dopyw infor macji dotyczcych odchyleniami i wymagajc wsplnego podjcie decyzji przez Komitet Sterujcy sytuacji projektu jedyniekluczowych w punktach projektu. W skadzie Komitetu Sterujcego mo na wyr ni trzy role: Przewodniczcego; Gwnego U ytkownika; Gwnego Dostawcy.

Idealnie byoby, gdyby role te przydzielono osobom, ktre mog pozosta w projekciecay czas jego przez trwania. Komitet Sterujcy mianowany jest przez kierownictwo firmy lub programu, by zapewni ukierunkowanie i zarzdzanie projektem. Ko mitet Sterujcy jest oglne odpowiedzialny za sukces projektu i ma obowizki i uprawnienia, ktre wynikaj z ustale kierownictwa firmy lub programu (pocztkowo zawartych w Zleceniu Przygotowania Projektu). Komitet Sterujcy zatwierdza wszystkie gwne plany i zezwala na jakiekolwiek powa - iejsze odchylenie od n zatwierdzonych Planw Jedynie on jest uprawniony do Etapu. zatwierdzenia wykonania ka dego etapu, jak rwnie zezwolenia na rozpoczcie kolejnego. e potrzebne zasoby s faktycznie przyznane i rozsdza wszelkie konflikty Zapewnia, lub negocjuje rozwizanie wszystkich problemw pomidzy projektem a podmiotami spoza zakresu projektu. Dodatkowo Komitet Sterujcy potwierdza nominacj i obowizki Kierownika Projektu. Komitet Sterujcy jest odpowiedzialny za zapewnienie, e projekt bdzie pod a w kierunku pozwalajcym na dostarczenie produktw o wymaganej jakoci, zgodnie z Uzasadnieniem Biznesowym okrelonym w Dokumencie Inicjujcym Projekt. noci od wielkoci, zo onoci i ryzyka projektu, Komitet Sterujcy mo e W zale zdecy- o przydzieleniu dodatkowych specyficznych zasobw dla niektrych lub dowa wszystkich rl Nadzoru Projektu. Kiedy adne dodatkowe zasoby nie zostan przydzielone, projektu pozostaje w zakresie obowizkw czonkw Komitetu nadzorowanie Sterujcego. Nadzr Projektu jest omwiony w podrozdziale 14.2.4. Komitet Sterujcy jest gosem projektu w kierunku wiata zewntrznego i jest odpowiedzialny za wszelkie publikacje lub inne rozpowszechnianie informacji o projekcie. Komitet cy nie jest demokratyczn , sterowan wi kszo gosw. ci Steruj Przewodnicz cy strukturkluczowym decydentem, bo ponosi jest ksz odpowiedzialnajwi no przed kierownictwem biznesu. Wspomagany jest przez Gwnego U ytkownika i Gwnego Dostawc . Przewodnicz cy

Przewodniczcy ponosi najwiksz odpowiedzialno, wspierany jest przez Gwnego U ytkownika i Gwnego Dostawc. Przewodniczcy jest odpowiedzialny za nastpujce kluczowe aspekty projektu.

231

ORGANISATION

PRINCE2

Opracowanie i cige aktualizowanie Uzasadnienia Biznesowego projektu Nadzorowanie opracowania sensownego Uzasadnienia Biznesowego jest czci zagwarantowania, e cele planowanej przez projekt zmiany pozostaj zgodne z potrzebami biznesowymi oraz zapewnia ustanowienie solidnej podstawy projektu w trakcie jego inicjo- i definiowania. Przewodniczcy powinien by odpowiedzialny za zapewnienie wania finansowania projektu, koniecznego do osignicia wymaganej zmiany biznesowej. Obowizkiem Przewodniczcego, realizowanym w cigu caego czasu trwania projektu, jest zapewnienie, e korzyci biznesowe zostan osignite. Struktura organizacyjna i plany Przewodniczcy zapewnia istnienie spjnej struktury organizacyjnej i logicznego(ych) w) . Wymaga to jego aktywnego zaanga owania si w prac podczas planu(inicjowania projektu. Monitorowanie i kontrolowanie postpw Oznacza to obowizek monitorowania i kontrolowania postpw zmiany biznesowej na poziomie strategicznym (na poziomie operacyjnym jest to obowizek Kierownika Projektu). Kierownik Projektu jest odpowiedzialny za regularne raporty (Raporty Okresowe) dla Pr zewodniczcego (i pozostaych czonkw Komitetu Sterujcego) o przebiegu zmiany biznesowej. Pojawi si nieuniknione Zagadnienia Projektowe, wymagajce rady Przewodniczcego, podjcia przez niego decyzji i kontaktw z gwnymi interesar iuszami. Przekazywanie problemu Jeli jest to konieczne, powa niejsze problemy pojawiajce si w projekcie powinny by waciwym czasie przenoszone na wy szy poziom zarzdczy. Wymagane bd we regu- konsultacje midzy osobami wprowadzajcymi zmian a interesariuszami i larne sponsorami. Przewodniczcy jest odpowiedzialny za zapewnienie, by procesy komunikacji byy efektywne oraz by utrzymywano czno midzy projektem a strategicznym kierownictwem organizacji. Formalne zamknicie Oprcz formalnego zamknicia projektu, nale y upewni si, e zdobyte dowiadczenia zostay udokumentowane. Zamknicie projektu wymaga formalnego potwierdzenia przez Przewodniczcego, e cele i zadania projektu zostay zrealizowane, a zdobyte dowiad-udokumentowane i rozpowszechnione. Do tego momentu niektre czenia spodziewane korzyci mogy ju zosta osignite. Jednak e czynnoci podczas zamykania obejmuj te planowanie przegldu poprojektowego, podczas ktrego zostanie oceniony cay proces osigania zaplanowanych korzyci biznesowych. Przegld poprojektowy Zapewnienie, e zostanie przeprowadzony przegld poprojektowy, ktrego celem jest ustalenie, czy osignito korzyci wymienione w Uzasadnieniu Biznesowym. Przewodni23 2

PRINCE2

ORGANIZACJA

czcy jest odpowiedzialny za zorganizowanie i przewodniczenie tym przegldom oraz za zapewnienie, e skonsultowano si z waciwymi pracownikami i wczono ich w proces przegldu. Wynik jest przekazywany waciwym interesariuszom. Gwny U ytkownik Gwny U ytkownik jest odpowiedzialny za wszelkie produkty dostarczone przez u ytkownika(-w), w szczeglnoci za zapewnienie, e wymagania zostay jasno zdefiniowane i s kompletne, e wytworzone produkty odpowiadaj swemu pr zeznaczeniu, a tak ea monitorowanie tego by dostarczane rozwizanie spenio potrzeby u z ytkownika. Rola ta reprezentuje interesy wszystkich tych, ktrzy bd u ywali kocowego(-ych) produktu(-w) projektu; tych, ktrym produkt pozwoli osign ich cel; tych, ktrzy bd wykorzystywali produkt do dostarczania korzyci biznesowych; lub tych, na ktrych pro- bdzie oddziaywa. Rola Gwnego U ytkownika jest odpowiedzialna jekt za: dostarczenie zasobw u ytkownika; zapewnienie, e projekt wytwarza produkty speniajce wymogi u ytkownika; zapewnienie, by produkty dostarczay korzyci oczekiwanych przez u ytkownika. Penienie roli Gwnego U ytkownika mo e wymaga zaanga owania wicej ni jednej aby zapewni reprezentacj wszystkich interesw u ytkownika. Pr zez wzgld osoby, na efektywno, rola ta nie powinna by dzielona midzy zbyt wiele osb. W Wska sekcji zwki i tego rozdziau przedstawiono uwagi na temat rozwizania problemu rady pretendentw do roli Gwnego U ytkownika. zbyt wielu Gwny Dostawca Gwny Dostawca powinien dostarczy rezultaty wymagane przez Gwnego U ytkownika. Gwny Dostawca jest odpowiedzialny za jako wszystkich produktw dostarczanych przez dostawc(. Czci obowizkw tej roli jest zapewnienie, by w) propozycje dotyczce projektowania i rozwoju produktw byy realistyczne. Gwny Dostawca d yo osignicia rezultatw wymaganych przez Gwnego U ytkownika w ramach d ustalo-kosztw i terminw, za ktre odpowiedzialny jest Przewodniczcy. Rola ta nych reprezentuje interesy osb projektujcych, wytwar zajcych, wspomagajcych, zaopatrujcych Penicy rol Gwnego Dostawcy musi mie uprawnienia do i wdra ajcych. przydzie- pozyskiwania potrzebnych zasobw dostawcy. Gwny Dostawca jest lania lub odpowie- za realizacj Uzasadnienia Biznesowego dostawcy. W niektrych dzialny rodowiskachwspdecydowa o projektach rozwiza specjalistycznych lub mie klient mo e znaczcy gos w tym zakresie razem z dostawcami. Aby zapewni reprezentacj interesw wszystkich dostawcw, mo e wystpi koniecz-zaproponowania penienia roli Gwnego Dostawcy kilku osobom. Majc na no wzgldzie skuteczno, nie powinno si obsadza w tej roli zbyt wielu osb. W Wska sekcji zwki i na kocu tego rozdziau przedstawiono wytyczne, ktre pozwalaj rady problem rozwi- du ej liczby pretendentw do roli Gwnego U za zbyt ytkownika.

233

ORGANISATION Wskazwki i rady

Czonkowie Komitetu Sterujcego maj zwykle bardzo wiele zaj poza projektem. W wikszych projektach istnieje niebezpieczestwo, e jeli nie mianuj oni odrbnych osb do penienia roli Nadzoru Projektu, obowizki Nadzoru Projektu nie zostan wykonane. Jeli obowizki Nadzoru Projektu nie bd przekazane konkretnym osobom, czonkowie Komitetu Sterujcego musz powa nie rozwa y, jak bd wykonywa prace zwizane z nadzorem projektu, kiedy znajd na nie czas i w jakim stopniu bd mogli si z nich wywiza. Role 22 mog by czone, ale nigdy pominite. Zalecane jest unikanie czenia rl Gwnego U ytkownika i Gwnego Dostawcy, jeli istnieje mo liwo wystpienia konfliktu interesw. W Komitecie Sterujcym zasiadaj decydenci. Wa ne jest, aby byli w nim reprezentowani: biznes, u ytkownik i dostawca, bo oni wszyscy powinni anga owa si w projekt. UWAGA: Specjalici ze strony klienta mog by rwnie wczeni w wybr sposobu (formuy) realizacji projektu i jego ukierunkowania, w szczeglnoci w przypadkach, gdy projekt jest czci programu. Zarwno klient, jak i dostawca mog chcie obsadzi rol Nadzoru Projektu swoimi przedstawicielami. W szczeglnoci, klient mo e odczuwa potrzeb niezale nego od dostawcy nadzoru nad specjalistycznymi aspektami projektu. Gwny Dostawca mo e chcie wyznaczy kogo do penienia roli nadzoru biznesowego, monitorujcego Uzasadnienie Biznesowe dostawcy. Liczny Komitet Sterujcy mo e si sta mao sprawny i doprowadzi do wydu enia procesu podejmowania decyzji. Jeli jest zbyt wielu kandydatw do penienia rl w Komitecie Sterujcym, powinno si ich zachci do wyznaczenia rzecznika, ktry bdzie peni dan rol. W szczeglnoci, jeli zbyt wiele osb chce dzieli rol Gwnego U ytkownika, powinno si powoa rad u ytkownikw z jej przewodniczcym. Przewodniczcy rady reprezentuje ich jako Gwny U ytkownik, przedkada radzie sprawozdania i odbiera od niej wskazwki przed naradami Komitetu Sterujcego. Zaanga owanie wielu dostawcw mo e rodzi konieczno wikszej reprezentacji w Komitecie Sterujcym ni jeden Gwny Dostawca. Podobnie jak powy ej, gdy zbyt wielu dostawcw chce mie udzia w penieniu tej roli, nale y rozwa y powoanie forum dostawcw oraz mianowa jego przewodniczcego, ktry bdzie ich reprezentowa w Komitecie Sterujcym. Dostawcy nie powinni, z powodu swej liczebnoci, osign pozycji przygniatajcej reprezentantw biznesu/ u ytkownika. Inne strony interesw mog by zapraszane do uczestnictwa w naradach Komitetu Sterujcego jedynie po to, by su y rad itp., ale nie po to, by bra udzia w podejmowaniu decyzji. Wszyscy czonkowie Komitetu Sterujcego powinni zosta przeszkoleni w zakresie procedur i obowizkw Komitetu Sterujcego.

PRINCE2

22

W Komitecie Sterujcym przypis tumacza.

23 4

PRINCE2

ORGANIZACJA

Jeli projekt jest jednym z szeregu projektw, nale y zdecydowa, kto jest u ytkownikiem. Czy jest nim konkretny u ytkownik kocowy, czy te kolejny projekt z tego szeregu projektw? Nie nale y myli potrzeb organizacji, wynikajcych z chci zarzdzania projektem, z potrzebami mechanizmu komunikowania si. Czonkowie Komitetu Sterujcego powinni zaakceptowa podpisem swe uzgodnione role i obowizki zanim podejm prac. Poziomy uprawnie, ktrych posiadanie jest niezbdne dla czonkw Komitetu Sterujcego, powinny by dopasowane do potrzeb projektu. Jeli projekt jest czci programu, to kierownictwo programu wyznacza Przewodniczcego i ma mo liwo wyznaczenia innych czonkw Komitetu Sterujcego. Alternatywnie, wybr pozostaych czonkw Komitetu Sterujcego mo e by zlecony Przewodniczcemu. W drugim przypadku powinien on konsultowa si z przedstawicielami programu i uzyska zatwierdzenie przez nich swego wyboru. Czasami mo e wystpi brak porozumienia midzy kierownictwem programu a zespoami zarzdzajcymi jego projektami. W celu zapewnienia, by projekt, ktry stanowi cz programu, zachowa kierunek wymagany do osignicia celw programu, czsto okazuje si waciwe, by program posiada reprezentacj w Komitecie Sterujcym projektu. Mo na to osign albo przez wyznaczenie reprezentanta programu do penienia roli w Komitecie Sterujcym, albo przez uczestnictwo reprezentanta kierownictwa programu w naradach Komitetu Sterujcego bez przyjmowania formalnej roli w projekcie. W takich przypadkach decyzje projektu, ktre maj wpyw na program, mog by podejmowane szybciej. Jest bardzo prawdopodobne, e reprezentant programu bdzie zdolny do podjcia decyzji w trakcie narady, co pozwoli unikn oczekiwania zespou zarzdzajcego projektem na konsultacje z kierownictwem programu. Powinno to prowadzi do zmniejszenia opnie lub poprawek wynikajcych z obowizku oczekiwania na rozstrzygajce decyzje.

14.2.2.

Kierownik Projektu

PRINCE2 ustanawia jednoosobowe bie ce zarzdzania projektem, mianowicie Kierow- Projektu, nika z waciwie zdefiniowanym zakresie obowizkw i odpowiedzialnoci. Rysunek 14.5 przedstawia wieloaspektowo roli Kierownika Projektu. Potrzebuje o n takiej struktury organizacyjnej, ktra albo przejmie niektre obowizki zwizane ze wskazanymi na rysunku aspektami projektu, albo zapewni mu w nich wsparcie oraz wes- w innych jeszcze obszarach prze projektu. Kierownik Projektu otrzymuje uprawnienia do bie cego prowadzenia projektu w imie- Komitetu Sterujcego, w ramach niu ustalonych ogranicze. Podstawowym obowizkiem Kierownika Projektu jest zapewnienie, e projekt wytwarza wymagane produkty, w wymaganym standardzie jakoci i w ramach sprecyzowanych ogranicze czasu i kosztw. Kierownik Projektu jest rwnie odpowiedzialny za dostar- przez projekt r ezultatu, ktry umo liwi osignicie korzyci biznesowych, czenie zdefiniowanych w Dokumencie Inicjujcym Projekt.

235

ORGANISATION

PRINCE2

Kierownik Projektu jest odpowiedzialny za przebieg wszystkich procesw PRINCE2, z wyjtkiem Zar dzania Strategicznego (ZS) i przedprojektowego z Projektem cego podprocesu Mianowanie i Kierownika (PP1). Przewodnicz Projektu Kierownik Projektu mo e delegowa odpowiedzialno za Zar dzanie proces z Wytwarzaniem (WP) Kierownikowi(-kom) Zespou(w projektach, w ktrych Produktw w) wykorzystuje si tak Kierownik Projektu jest zwierzchnikiem Kierownikw rol. Zespow oraz Wsparcia Projektu i jest odpowiedzialny za wspprac z Nadzorem Projektu i Komitetem Sterujcym. W rodowisku klient/dostawca Kierownik Projektu pochodzi zwykle z organizacji klien- s projekty, w ktrych Kierownik Projektu pochodzi ze strony dostawcy. W ta, ale takim przypadku klient mo e mianowa dyrektora projektu lub kontrolera, ktry bdzie na co jego cznikiem z Kierownikiem bie Projektu.
Zarzdzanie operacyjne Strategia Finansowanie

Klient

Komunikacja

Praca zespoowa

Kierownik Projektu

Jako

Planowanie Status produktw Monitorowanie Potrzeby u ytkownika Produkt a potrzeby projektu Zmiany

Rysunek 14.5. Projektu Wskazwki i rady

Wieloas pektowo roli Kierownika

Mo e by korzystniejsze zatrudnienie w tej roli osoby o wysokich kwalifikacjach na cz etatu ni mniej wykwalifikowanej na peny etat. Wa ne jest, by pamita, e w tym podrczniku zakada si, i Kierownik Projektu pochodzi z organizacji klienta. Mo liwe jest, by Kierownik Projektu pochodzi od dostawcy w takich przypadkach punkt styku klient/dostawca przechodzi z obszaru Kierownik Projektu/Kierownik Zespou do obszaru Komitet Sterujcy/Kierownik Projektu. Tam, gdzie Kierownik Projektu nie sprawuje bezporedniej zwierzchnoci nad personelem wyznaczonym do pracy nad projektem, istotne jest uzyskanie (i utrzymanie w trakcie

23 6

PRINCE2

ORGANIZACJA

trwania projektu) zezwolenia waciwych kierownikw na zaanga owanie ich personelu w prace projektu. Nale y pamita, e rol Kierownika Projektu jest zarzdzanie prac, a nie jej wykonywanie. Kierownik Projektu musi unika wcigania go w drobne szczegy, co grozioby mu utrat postrzegania caociowego obrazu, to znaczy orientacji w tym, co dzieje si we wszystkich obszarach projektu. R ne typy projektw wymagaj od Kierownika Projektu innych cech. W dopasowywaniu rl Kierownika Projektu i Kierownika Zespou w rodowisku klient/ dostawca nale y wzi pod uwag, czy jest do zaakceptowania sytuacja, w ktrej zasoby klienta bd zarzdzane przez dostawc, lub zasoby dostawcy bd zarzdzane przez przedstawiciela klienta. Jeli sytuacja taka jest dopuszczalna, nale y jednoznacznie podzieli odpowiedzialno za zarzdzanie zasobami ludzkimi - np. ocenianie, awansowanie i szkolenie.

14.2.3.

Kierownik Zespou

Zatrudnienie odrbnej osoby w tej roli jest kwesti wyboru. Kierownik Projektu mo e zna, e korzystnie jest delegowa uprawnienia i odpowiedzialno za planowanie u wytwarzania pewnych produktw i za zarzdzanie zespoem specjalistw, ktrzy te produk- wytworzy. Jest wiele powodw, dla ktrych Kierownik Projektu mo e ty maj zdecy- o zatrudnieniu innej osoby do tej roli. Wr d nich s: wielko projektu, dowa szczeglne kwalifikacje specjalistyczne lub wiedza potrzebna dla wytworzenia pewnych produktw, rozproszenie geograficzne niektrych czonkw zespou oraz preferencje Komitetu Sterujcego. Podstawowym obowizkiem Kierownika Zespou jest zapewnienie wytworzenia okrelonych przez Kierownika Projektu produktw, o odpowiedniej jakoci, w terminie i w ramach kosztw akceptowalnych przez Komitet Sterujcy. Kierownik Zespou podlega Kierownikowi Projektu (przedstawia mu raporty i otrzymuje od niego polecenia). Dodat-Kierownik Zespou mo e pod lega Gwnemu Dostawcy. kowo Jest niezwykle wa ne, aby wszelkie takie powizania byy jednakowo rozumiane i byy udokumentowane w ce-uniknicia konfliktw interesw i wszelkiego podrywania autorytetu Kierownika Pr lu ojektu. Wykorzystanie tej roli powinno by przedyskutowane przez Kierownika Projektu z Ko - itetem Sterujcym oraz, jeli rola jest potrzebna, zaplanowane w ramach m podprocesu Organizowanie Zespou dzania (PP2) lub dla ka dego kolejnego etapu Zarz cz podprocesu Planowanie Projektem (ZE1) . jako Etapu

14.2.4.

Nadzr Projektu

Obsadzenie tej roli jedn lub kilkoma osobami jest kwesti wyboru. Komitet Sterujcy mo e stwierdzi, e korzystne jest delegowanie uprawnie i obowizkw nadzoru projektu innym osobom. Wynika to z faktu, e czonkowie Komitetu Sterujcego nie zajmuj 237

ORGANISATION

PRINCE2

si projektem w penym wymiarze godzin i zdaj si w tym w znacznej mierze na Kierownika Projektu. Cho otrzymuj od niego regularne raporty, mog zadawa sobie pyta-Czy sprawy maj si tak dobrze, jak si nam to mwi?, Czy ukryto jakie nia: problemy przed nami?, Czy rozwizanie bdzie takie, jakie chcemy uzyska?, Czy nagle stwierdzimy, e projekt przekroczy bud et lub jest opniony?, Czy nie Uzasadnienie pozostaje niezmienione?, Czy zamierzone korzyci zostan Biznesowe osignite?. Dostawca i/lub klient mog wprowadzi funkcj nadzor u jakoci z obowizkiem spraw- czy wszystkie elementy projektu dziaaj zgodnie z ich systemami dzania, zarzdzania jakoci. Przytoczone kwestie oznaczaj, e w projekcie istnieje potrzeba monitorowania, nieza- od Kierownika Projektu, wszystkich aspektw dotyczcych wydajnoci i le nie produktw. To dziaanie jest rol Nadzoru Projektu. Ka dy czonek Komitetu Sterujcego odpowiada za mianowanie jednej lub wikszej do roli Nadzoru Projektu odpowiednio do swego obszaru zainteresowania liczby osb iznesu, u ytkownika i dostawcy. Komitet Sterujcy mo e tak e mianowa inne b osoby z wntrza organizacji do obsadzenia okrelonych funkcji w ramach Nadzoru Projektu, np. ownik jakoci w firmie mo e kontrolowa tak e te aspekty projektu, ktre kier dotycz Niektrzy interesariusze szczeglnie zainteresowani projektem, mog zosta jakoci. wyznaczeni przez Komitet Sterujcy do penienia czci lub wszystkich obowizkw zwizanych z rol Nadzoru Projektu. Nie wystarczy jedynie wiara w to, e standardy bd przestrzegane. Nie wystarczy zapewni, e projekt jest dobrze przygotowany i uzasadniony w punkcie wyjcia. Wszyst- elementy powinny by sprawdzane w caym okresie jego trwania jako cz kie te dzia- zapewniajcych, e projekt pozostaje wewntrznie spjny i cigle umo liwia a zaspo- potrzeby biznesowej oraz e adna zmiana w otoczeniu zewntrznym nie kojenie wpyn- celowo. a na jego PRINCE2 ustala funkcje Nadzoru Pr ojektu, zgrywajc je z rol ka dego z czonkw Komitetu Sterujcego. Wszystkie osoby nominowane do penienia roli Nadzoru Projektu musz by niezale ne od Kierownika Projektu i prowadz ten nadzr w imieniu i na rzecz jednego lub kilku czonkw Komitetu Sterujcego. Czonkowie Komitetu Sterujcego s odpowiedzialni za nominacje do roli Nadzoru Pro- ale mog te wzi na siebie cz obowizkw zwizanych z nadzorem. jektu, Jeli obowizki te rozdzielono midzy wiele osb, nale y jednoznacznie ustali, co kto robi. penica rol Nadzoru Projektu mo e by wymieniona w tr akcie projektu na Osoba da- Komitetu Sterujcego. Wykor zystanie dodatkowego personelu do przejcia nie obowizkw Nadzoru Projektu powinno by zaplanowane podczas podprocesu Organizowani e Zespou dzania (PP2) ; w przeciwnym razie wykorzystanie Zarz Projektem zasobw i koszty Nadzoru Projektu mog atwo wymkn si spod kontroli. Ka da osoba wyzna- do roli Nadzoru Projektu podlega czonkowi(-om) Komitetu Sterujcego, czona odpowiedzialnemu(-ym) za to mianowanie. Poniewa Nadzr Projektu musi by niezale ny od Kierownika Projektu, Komitet Sterujcy nie mo e powierzy mu adny ch obowizkw wynikajcych z roli Nadzoru Projektu.

23 8

PRINCE2

ORGANIZACJA

Udzia Nadzoru Projektu w procesach PRINCE2 Nadzr Projektu jest zaanga owany w wikszo podprocesw PRINCE2. Poni sza lista dostarcza przykadw zada Nadzoru Projektu: Przygotowanie Zao Projekt (PP4) - przejrzenie zarysu Uzasadnienia e Biznesowego (Nadzr Projektuu zwizany z Przewodniczcym) oraz pierwszych wpisw w Rejestrze Ryzyka; Okr lenie Formuy Realizacji (PP5) sprawdzenie, czy Formua e Projektu jest prawidowa w sensie technicznym (Nadzr Projektu zwizany Projektu Realizacji z wnym Dostawc) oraz spjna ze strategi korporacyjn lub strategi G programu (Nadzr Projektu zwizany z Przewodniczcym) ; Planowanie Etapu (PP6) - okrelenie w Planie Etapu inicjowania, Inicjowania jak bdzie weryfikowane Uzasadnienie Biznesowe i ocena ryzyka; Planowanie (IP1) - potwierdzenie, e Plan Jakoci Projektu zawiera c Jako i wymagane standardy; Planowanie (IP2) potwierdzenie, e interesy reprezentowanych Projektu Sterujcego znajduj zadowalajce odbicie w Planie czonkw Komitetu Projektu; Doprecyzowanie Uzasadnienia Biznesowego i (IP3) - potwierdzenie wa Ryzyka Uzasadnienia noci Biznesowego (Nadzr Projektu zwizany z Przewodniczcym) si, e wszystkie zagro enia zostay zidentyfikowane i oraz upewnienie przypisano im odpowiednie dziaania i sposb monitorowania; Ustanowienie Elementw (IP4) - potwierdzenie, e zaproponowane 23 eleSterowania menty sterowania dobrze strzeg interesw ich ; Ustanowienie Systemu (IP5) - stwierdzenie kompletnoci i Dokumentacji zaproponowanego adekwatnoci systemu; Zestawienie Dokumentu cego (IP6) konsultacje z Inicjuj Projekt Projektu na temat sposobu przygotowania Kierownikiem i zestawiania Dokumentu Inicjujcego Projekt ; Zar dzanie Strategiczne (ZS) - doradzanie czonkom Komitetu z Projektem Sterujcego; Zgoda na Wykonanie Grupy (SE1) potwier dzenie wymaga Zada kontroli jakoci okrelonych w dotyczcych Grupie Zada; Ocena pw (SE2) - przejrzenie uaktualnionego Rejestru Jakoci oraz Post wychwytywanie opnionych lub opuszczonych kontroli jakoci; Analizowanie Projektowyc (SE4) udzia w analizie ich Zagadnie h oddziaywania; Przeg d Stanu (SE5) - udzia w przegldach stanu l Etapu etapu; Raportowanie (SE6) - przegld Raportu Okresowego przed jego Okresowe przekazaniem dalej; Przekazywanie Projektowyc (SE8) monitorowanie wszelkich Zagadnie h ewentualnych odchyle oraz przedkadanie wszelkich uwag Kierownikowi Projektu;

23

To znaczy czonkw Komitetu Sterujcego przypis tumacza.

239

ORGANISATION

PRINCE2

Przyjmowanie Grupy do (WP1) - potwierdzenie, e w Planie Zada zawarto wystarczajce Wykonania dotyczce kontroli Zespou wymagania jakoci; Wykonywanie Grupy (WP2) - sprawdzenie aktualnoci Rejestru Jakoci Zada prawidowego stosowania oraz standardw jakoci; ewentualny udzia w roli testerw w przegldach jakoci ; Planowanie (ZE1) sprawdzenie, czy zaplanowano przegldy jakoci Etapu proponowanie osborazdo funkcji testerw; Uaktualnienie Planu (ZE2) - weryfikacja oddziaywania ka dej Projektu wprowadzonej do Planu zmiany Projektu; Uaktualnienie Uzasadnienia (ZE3) - weryfikacja oddziaywania ka Biznesowego Uzasadnienie Biznesowe (Nadzr Projektu zwizany z dej zmiany na Przewodniczcym); Uaktualnienie Rejestru Ryzyka w Rejestrze Ryzyka; (ZE4) dokonanych monitorowanie wszelkich zmian

Raportowanie ca (ZE5) uzgodnienie zawartoci Raportu Ko Etapu pr zedEtapujego Kocowego ukoczeniem; Opracowanie Planu (ZE6) - weryfikacja zgodnoci Planu Nadzwyczajnego Nadzwyczajnego z propozycj zawart w Raporcie o Istotnych Odchyleniach oraz wytycz- mi ny Komitetu Sterujcego; Przygotowanie Projektu do ci (ZP1) - konsultacje w sprawie stopnia Zamkni a zrealizowania prac; Okr lenie Nas pczyc (ZP2) - konsultacje w sprawie stopnia realizacji e t h korzyciDziaa uzgodnienie zawartoci Planu Przegldu Poprojektowego przed oraz jego ukoczeniem ; Projektowanie (PL1) - sprawdzenie, czy struktura planu pozwala na Planu budow realistycznych planw; Okr lanie i Analizowanie (PL2) - udzia w przygotowaniu i/lub e sprawdzeniu Produktw Produktu (lub wskazanie, kto powinien w to by wczony) Opisw szcze- w odniesieniu do kryteriw jakoci, metod weryfikacji jakoci oraz osb glnie wyznaczonych do sprawdzenia jakoci; Analizowanie Zagro (PL6) - wsppraca podczas analizowania ryzyka oraz e lania dziaa okrezaradczych; Kompletowanie (PL7) - potwierdzenie, e plan jest kompletny i Planu dokadny, do przed przedo eniem go zatwierdzenia .

Wskazwki i rady
Czonkowie Komitetu Sterujcego mog osobicie wypenia swoj rol Nadzoru Projektu, jeli sobie tego ycz lub jeli maj na to czas. Ogromnie wspomaga zaanga owane Komitetu Sterujcego w projekt, jeli jego czonkowie dadz si przekona do osobistego sprawowania nadzoru projektu. Powstaje jednak pytanie, czy bd mieli potrzebny na to czas i wystarczajce kwalifikacje.

24 0

PRINCE2

ORGANIZACJA

Wymagania w stosunku do Nadzoru Projektu mog si zmienia w zale noci od typu projektu. Jednym z mo liwych przykadw jest potrzeba zapewnienia cigego nadzoru integralnoci projektu z wymogami biznesowymi. Nadzr Projektu monitorowaby nieprzerwanie wa no Uzasadnienia Biznesowego w kontekcie wydarze zewntrznych, zmiany ryzyka projektu, postpy realizacji w porwnaniu z Planem Projektu oraz wpyw ka dej zmiany w specyfikacji na Uzasadnienie Biznesowe. Innym przykadem jest cigy Nadzr Projektu z ramienia klienta, majcy na celu zapewnienie, by projekt zmierza waciwym torem do wytworzenia efektywnego i u ytecznego rozwizania. Trzecim przykadem s zadania nadzoru sprawowanego w imieniu Gwnego Dostawcy, w celu zapewnienia, e s dostpne waciwe standardy, e mog by one stosowane oraz e s one prawidowo stosowane podczas tworzenia produktw. Do zada Nadzoru Projektu mo e tu nale e dopilnowanie, eby pozosta lad rewizyjny wszystkich wykonywanych prac kontroli jakoci. Inne przykady mog obejmowa nadzr bezpieczestwa oraz nadzr, by projekt pozostawa w zgodzie ze strategi oraz wytycznymi programu. Jeli osoba wskazana do wykonywania obowizkw nadzoru bdzie zmieniona w trakcie projektu, nale y zatroszczy si o zapewnienie cigoci pracy wykonywanej przez ni w ramach tej roli. Nie zaleca si czenia obowizkw w ramach roli Nadzoru Projektu, tam gdzie mogyby wystpi potencjalne konflikty interesw. Ka da osoba wyznaczona do roli Nadzoru Projektu powinna by niezale na od Kierownika Projektu. W projektach realizowanych w rodowisku klient/dostawca mo e zaistnie potrzeba oddzielnego obsadzenia roli Nadzoru Projektu, osobami majcymi za zadanie monitorowanie realizacji konkretnych interesw klienta i dostawcy.

14.3.

Wsparcie Projektu

Kierownik Projektu mo e potrzebowa pomocy administracyjnej. Mo e to wynika z ilo- pracy do wykonania lub z obowizku u ycia pewnych narzdzi, do czego ci Kierownik nie posiada wystarczajcych umiejtnoci, np. konieczno zapewnienia Projektu pomo- posugiwaniu si specjalnym oprogramowaniem do planowania i sterowania cy w reali- planu zacj lub do zarzdzania konfiguracj. Formalne mianowanie jednej osoby lub wicej osb do roli Wsparcia Projektu jest obowizkowe. Wynika ono z potrzeb danego projektu i Kierownika Projektu. Wsparcie Pro- mo e by realizowane w formie usug administracyjnych, zapewnienia jektu doradztwa oraz informacji dla jednego lub wikszej liczby powizanych projektw. Wsparcie Pro- mo e dziaa jako repozytorium dowiadcze i danych do szacowania oraz jektu centralne rdo wiedzy i umiejtnoci w takich sprawach, jak specjalistyczne narzdzia wspomagajce i standardy zarzdzania projektami. W mniejszych projektach prace Wsparcia mog by rozdzielane midzy Kierownika Projektu i czonkw Projektu zespou. Jedn szczegln rol Wsparcia Projektu, ktra musi by uwzgldniona, jest Bibliotekarz W zale noci od wielkoci projektu i jego otoczenia mo e zaistnie Konfiguracji. potrze241

ORGANISATION

PRINCE2

ba wyznaczenia kogo do penienia tej roli. Jeli nie dokona si tego, przypadnie ona Kierownikowi Projektu wraz ze wszelkimi innymi zadaniami roli Wsparcia Projektu, ktrezostay nikomu przydzielone. Szczegy tych zada przedstawiaj: Rozdzia nie 19 dzanie r i Dodatek B Role Zespou dzania . z konfiguracj Zarz Projektem Konieczne jest rozdzielenie obowizkw Wsparcia Projektu i Nadzoru Projektu w celu utrzymania niezale noci Nadzoru Projektu. Wskazwki i rady
Fizyczne umiejscowienie personelu projektu mo e stwarza problemy, jeli siedziby w ktrych pracuj poszczeglne osoby s oddalone od siebie. Jeli w ogle jest to mo liwe, nale y wybra do zespou projektowego osoby znajdujce si w jednym miejscu. Jeli nie, to nale y zapewni dostpno odpowiedniej techniki komunikacji oraz przeszkolenie w jej stosowaniu. Tam, gdzie wielko projektw i liczebno personelu to umo liwia, wsplne obszary wsparcia mog by skoncentrowane w Biurze Wsparcia Projektw (BWP) . Pozwala to na stae przypisanie personelu do tego typu pracy i przez to uzyskanie wysokich kwalifikacji. BWP mo e wspiera wszystkie projekty i ustanawia standardy, takie jak u ywanie narzdzi do planowania i sterowania, zarzdzania ryzykiem, raportowania, sterowania zmianami i zarzdzania konfiguracj.

Za -

24 2

15.

P LA NY
PLANS

Sterowanie zmianami
dz an Zarz ie St rat eg icz ne Pr ojekt em dz an Zarz Z S4 ie St rat eg icz ne Pr ojekt em

Uzasadnienie biznesowe

Z S4 Z S1 Z S2 ZS 3 Z S5 Z S1 Z S2 ZS 3 Z S5
dz ani Zarz e dz ani Zarz e Zakresem Zakresem Et apu Et apu Zam owan wani S rz ykan ie I terygot o ie P ni cjo wani e e Zam ykan wani S rzcjo tuo ie I terygot u ie P niojek wani e e E roj owan Prt apem ektu ekt E apem Prt ojek tu P roj ekt u ektu d zan Zar z ie d zan Zar z ie ani Wyt warz Pl anow ani e em Wyt dukt w em P anow ani e Plro warz ani P ro dukt w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 15.1. metodyki

Komponent Plany w modelu strukturalnym PRINCE2

15.1.

Korzy ci z planowania

Efektywne planowanie okrela: czy cele s osigalne; zasoby niezbdne do osignicia celw w ustalonym terminie; dziaania niezbdne do zapewnienia jakoci produktw; problemy i ryzyko zwizane z prb osignicia celw przy zachowaniu okrelonych ogranicze. Inne korzyci z planowania obejmuj: uniknicie chaosu i koniecznoci podejmowania decyzji doranych; pomoc zespoowi zarzdzania w perspektywicznym myleniu; dostarczenie miary umo liwiajcej mierzenie postpw;

24 3

PLANS

PRINCE2

ko munikowanie, poprzez przekazanie planu wszystkim zainteresowanym, co ma by zrobione, jak to ma by zrobione, jaki bdzie podzia obowizkw oraz jak bd monitorowane i kontrolowane postpy; uzyskanie zaanga owania wsppracownikw i odbiorcw; u mo liwienie wyznaczenia celw osobistych. Planowanie nie jest banalnym wiczeniem. Jest niezmiernie wa ne dla powodzenia pro- Plan musi zawiera wystarczajce informacje i szczegy, aby potwierdzi, e jektu. jego cele s osigalne. Istotne jest, by przewidzie czas na dziaalno planistyczn. Ka dy projekt powinien posiada Etap inicjowania, w ktrym przewidziano czas na zidentyfikowanie i uzgodnienie zakresu projektu oraz na zaplanowanie go w kategoriach zarzdzania: przypisania zaso- produktw, dziaa, jakoci i kontroli. Nale y rwnie przewidzie czas na bw, doprecyzowanie Uzasadnienia Biznesowego . Etap inicjowania mo e by formalny lub nie, w zale noci od natury i zo onoci projektu. Dodatkowo, w trakcie Etapu inicjowaniakoniec ka dego kolejnego etapu projektu, z wyczeniem etapu ostatniego, oraz pod powinno si przewidzie czas na szczegowe zaplanowanie nastpnego etapu. Bez efektywnego planowania rezultat zo onych projektw nie mo e by przewidziany zakresu, jakoci, ryzyka, terminowoci i kosztw. Osoby zaanga w kategoriach owane w zapewnienie zasobw nie mog optymalizowa swoich dziaa. Sabo zaplanowane powodem frustracji, marnotrawstwa i projekty s przerbek.

15.2.

Czym jest plan?

Plan jest dokumentem, uo onym zgodnie z okrelonym uprzednio schematem lub metod, opisujcym jak, kiedy, gdzie i pr zez kogo konkretne cele lub zbiory celw maj by osignite. Plan jest konstrukcj wyjaniajc, jak mog by osignite ustalone cele dotyczce produktw, terminw, kosztw i jakoci. Plany stanowi centraln o systemu informacji zarzdczej, ktry jest potrzebny w ka - ym projekcie. Wa ne jest, by przez cay czas trwania projektu utrzymywa d plany zgodnoci w z Uzasadnieniem Biznesowym. Plan wymaga zatwierdzenia i zaanga owania odpowiednich szczebli zespou zarzdzania tj. Komitetu Sterujcego i Kierownika Projektu w przypadku Planu projektem, Projektu i wszystkich Planw Etapw, oraz Kierownika Projektu i Kierownika Zespou w przypadku Planu Zespou.

15.3.

Jakie s elementy planu?

Gdy prosi si o opisanie planu, wiele osb myli tylko o czym w rodzaju wykresu paskowego z podziak czasu. Plan zgodny z PRINCE2 jest pojciem obszerniejszym. Powinien zawiera nastpujce elementy (dla przejrzystoci czynic maksymalny u ytek wykresw, z tabel i diagramw): produkty do wytworzenia;

24 4

PRINCE2 dziaania potrzebne do wytworzenia tych produktw; dziaania potrzebne do potwierdzenia jakoci produktw; zasoby i czas potrzebne odpowiednio na wykonanie wszystkich stosownych dziaa z zarzdzaniem projektem i kontrol jakoci) oraz wszelkie (cznie zapotrzebowa- personel nie na o konkretnych umiejtnociach; wspzale noci midzy dziaaniami; zewntrzne uzale nienia zwizane z dostarczeniem informacji, produktw lub usug; terminy prowadzenia dziaa; punkty, w ktrych bd monitorowane i kontrolowane postpy; uzgodnione tolerancje. Plany Projektu i Plany Etapw powinny uzyska aprobat i zosta zatwierdzone przez Sterujcy. Aprobata ta powinna odnosi si do ostatniej wersji i ka nacisk Komitet na znaczenie planu dla projektu. Plany powinny by prezentowane podobnie jak raporty zarzdcze, tzn. kluczowe informacje powinny by udokumentowane w taki sposb, eby czytelnik mg je zrozumie, zinterpretowa i przedstawi wtpliwoci. Plan Etapu mo e ic przybra dwie formy: sumarycznego planu odpowiedniego do przedstawienia w Komitetowi Sterujcemu (podstawa zezwolenia na realizacj) oraz planu bardziej szczeg- wykorzystywanego do bie cego sterowania realizacj owego, etapu. Zestawienie czynnoci i struktura zapotrzebowania na zasoby musz by wsparte opisem, ktry wyjani czytelnikowi: co obejmuje plan (na przykad konkretny etap, projekt, konkretne pr odukty); przyjt metod planowania; zamierzone podejcie do realizacji planu (np. liczba etapw, rozmiar Grup Zada); jak i przez kogo plan bdzie monitorowany i kontrolowany; jakie raporty zarzdcze bd tworzone; wszelkie ograniczenia zawarte w planie; ryzyko zawarte w planie i wszelkie pojte dziaania zaradcze; zale noci zewntrzne; poczynione zao enia - w tym zao enia planistyczne; przyjte tolerancje; metody kontroli jakoci i zasoby, ktre maj by do tego wykorzystane (Plany Eta- i Plany Zespow). pw Rysunek 15.2 pokazuje elementy planu i ilustruje jak plan mo e by budowany, poczynajc od listy produktw, ktr e maj by wytworzone. Wszelkie warunki wstpne s zidentyfikowane wraz z wymaganiami jakociowymi dla produktw. Te trzy elementy wiod do rozwa enia przyjtych zao e. Nastpne elementy maj na celu zdefiniowanie dziaa wymaganych do wytworzenia produktw. Identyfikuje si zale noci midzy dziaaniami, po czym dodawane s zasoby umo liwiajce wykonanie tych dziaa. Nastpnie r ozwa ane jest ryzyko realizacji planu, a po tym 245

PLANY

PLANS

PRINCE2

docza si punkty kontrolne. Ostatnie dwa kroki mog doprowadzi do dodania dziaa i niezbdnych do ich realizacji zasobw. Na k oniec zostaje obliczony cakowity czas trwania i cakowity koszt projektu.
Produkty Warunki wst pne Wymagania jako ciowe

Zao enia

Dziaania

Zasoby

Zagro enia

Punkty kontrolne

Skorygowane dziaania i zasoby

Czas i koszt

Rysunek 15.2. planu

Elementy

15.4.

Podej cie PRINCE2

Struktura planowania w PRINCE2 pozwala na rozbicie planu na bardziej szczegowe plany ni szego poziomu . Jednak e wszystkie poziomy planw, ktre ilustruje Rysunek t sam ogln str uktur i zawsze przed zatwierdzeniem s konfrontowane 15.3, maj z lanowanymi wymaganiami, w tym dotyczcymi jakoci i korzyci p biznesowych.

15.5.

Poziomy planw

Aby odzwierciedli potrzeby r nych poziomw zarzdzania zaanga owanych w projekt, PRINCE2 proponuje trzy poziomy planw: Plan Projektu, Plan Etapu i Plan Zespou. Wykorzystanie Planw Zespow, patrz Rysunek 15.3, zale y od potrzeb konkretnego projektu. Plany Zespow zostay wyjanione bardziej szczegowo poni ej w tym rozdziale. Plan Etapu mo e by rozo ony na pewn liczb Planw Zespow (gdy przewi- udzia zespow) lub te pakiet Planw Zespow opracowanych przez dziano podwyko- e by wczony do Planu Etapu. nawcw mo Gdy przewiduje si, e tolerancje wyznaczone dla Planu Etapu lub Planu Projektu zostan przekroczone, czsto opracowywany jest Plan Nadzwyczajny, ktry zastpi wczeniej24 6

PRINCE2 szy plan. Jeli przewiduje si, e tolerancje wyznaczone dla Planu Zespou kroczone, nale y zastosowa podobn procedur w kontaktach Kierownikiem a Projektu Kierownikami Zespow.
Plan Programu Plan Projektu

PLANY zostan przemidzy

Plan Etapu

Plan Nadzwyczajny

(Opcjonalnie) Plan Zespou

Rysunek 15.3. Poziomy planw w PRINCE2 Zasadnicza idea stojca za ustanowieniem r nych poziomw planu polega na tym, e imszy jest poziom planu, tym krtsze s jego ramy czasowe i tym wicej zawiera ni on szczegw. Poziomy i liczb planw wymaganych w projekcie okrela si w oparciu o wielkoci i rozmiar wystpujcego ryzyka. Trudnoci w dokadnym oszacowaniu czasu dziaa i wymaga dotyczcych zasobw rosn tym bardziej, im bardziej trwania plan w przyszo. Niezale nie od wystpowania tego problemu, w celu uzyskania siga zezwolenia na kontynuowanie prac, istnieje zawsze potrzeba dostarczenia szacunkowej trwania i kosztw projektu jako oceny czasu caoci. Rzadko jest po dane lub mo liwe szczegowe zaplanowanie caego projektu na jego pocztku. Przyczyny tego wynikaj z: niepewnoci, dotyczcej szczegw pniejszych elementw pracy; zmieniajcego si lub niepewnego otoczenia; czynnikw ryzyka, ktre mog zmieni sytuacj; trudnoci w przewidywaniu dostpnoci zasobw; trudnoci w przewidywaniu warunkw biznesowych. Jednak jeli bie ce elementy pracy maj by kontrolowane, potrzebne s szczegowe plany zawierajce solidne oszacowania dla realnie przewidywalnej przyszoci. Z tych powodw nale y tworzy plany o r nych poziomach zakresu i szczegowoci. Jeli projekt stanowi cz programu, Plan Projektu bdzie istnia w kontekcie planu programu. Plan programu mo e stawia ograniczenia, ktre trzeba wzi pod uwag pod- przygotowywania lub korygowania Planu Projektu . Musi istnie ujednolicenie czas struk- planw projektu i programu, aby zapewni, e projekt jest prowadzony w tury kierunku pozwalajcym zrealizowa cele i produkty programu. W szczeglnoci jest to istotne, gdy Projektu musi by korygowany, aby uwzgldni Zagadnienia Projektowe i zagro Plan enia w miar ich wystpowania.

247

PLANS

PRINCE2 Plan Projektu

15.5.1.

Potrzebny jest oglny obraz caoci projektu. Jest nim Plan Projektu. Stanowi on cz Dokumentu Inicjujcego Projekt. Plan Projektu jest obowizkowym planem w PRINCE2. on Dostarcza Uzasadnieniu Biznesowemu danych o kosztach i jest wykorzystywany przez Komitet Sterujcy jako punkt odniesienia, wzgldem ktrego monitorowane s faktyczne koszty i postpy - etap po etapie. Plan Projektu okrela gwne projektu produkty, zapotrzebowanie na zasoby i cakowity koszt. Identyfikuje tak e gwne punkty kontroli takie jak np. granice etapw. Plan Jakoci Projektu (patrz: Rozdzia projektu, Jak 18 o w rodowisku ) jest dokumentowany oddzielnie w innej czci Dokumentu projektu Inicjujcego Projekt. Z chwil zatwierdzenia Dokumentu Inicjujcego Projekt, pocztkowy Plan Projektu staje obiektem odniesienia (nazywanym tak e planem bazowym) i ukazuje si pierwotny podstawie ktrego projekt zosta zatwierdzony. W miar jak projekt plan, na przechodzi kolejne etapy, pod koniec ka dego z nich przygotowywane s kolejne przez swoje wersje Projektu i staj si one kolejnymi obiektami odniesienia, Planu odzwierciedlajc: poczynione dotd postpy; wszelkie zaakceptowane zmiany warunkw; wszelkie skorygowane prognozy kosztw i/lub czasu trwania caego projektu. Pierwotna i aktualna wersja Planu Projektu stanowi cz informacji wykorzystywanych przez Komitet Sterujcy do monitorowania, jak dalece projekt odchyla si od pierwotnego rozmiaru i zakresu. Jeli wystpuje prawdopodobiestwo, e Plan Projektu przekroczy zatwierdzone toleran-patrz: Rozdzia Elementy cje ( ), informacja o odchyleniu musi by 16 sterowania szemu szczeblowi zarzdzania, aby uzyska przekazana przez Komitet Sterujcy wy decyzj dotyczc dziaania korygujcego.

15.5.2.

Plan Etapu

Dla ka dego etapu okrelonego w Planie Projektu wymagany jest Plan Ka dy Etapu. Plan Etapu jest tworzony pod koniec poprzedniego etapu. Bdzie on dla Kierownika Pro- podstaw do bie cego sterowania. W bardzo maym projekcie, tylko o dwch jektu eta- (Etap inicjowania plus etap realizacji), Kierownik Projektu mo e zdecydowa si pach na umieszczenie w Planie Projektu szczegw waciwych dla Planu Etapu. Plan Etapu podobny jest w swej zawartoci do Planu Projektu, lecz ka dy z elementw by powinien sprowadzony do poziomu szczegowoci umo liwiajcego Kierownikowi Projektu sprawowanie bie cej kontroli jego realizacji. Ocena susznoci zao e i analiza zagro e powinny by przeprowadzone powtrnie dla etapu, gdy mogy one ulec zmianie od czasu, gdy byy rozwa ane wczeniej, albo pr zy bardziej szczegowym roz- zeniu mogy si pojawi nowe zagro enia lub ju zidentyfikowane mogy sta patr si bardziej widoczne. Opracowanie ka dego Planu Etapu jest finalizowane pod koniec poprzedniego etapu jako cz procesu Zar dzanie Zakresem (ZE). Takie podejcie powinno zwiksza Etapu zaufanie do z planu, poniewa :

24 8

PRINCE2 Plan Etapu jest przygotowywany w momencie niezbyt odlegym od czasu, w planowane ktrym wydarzania bd miay miejsce; Plan Etapu obejmuje du o krtszy okres ni Plan Projektu; po zakoczeniu pierwszego etapu, ka dy kolejny Plan Etapu opracowywany jest wykorzystaniem z wiedzy o wynikach etapw wczeniejszych. Plan Zespou

PLANY

15.5.3.

Plany Zespow nie s obowizkowe, a ich potrzeb okrela wielko i zo ono projek- liczba zaanga owanych osb. Bd one czsto potrzebne, jeli istniej tu oraz odrbne zo one z grup o r nych specjalnociach lub z zewntrznych zespoy kontrahentw. Plany te przygotowuje si rwnolegle z Planem Etapu, albo przez podzia dziaa etapu na zadania, za ktre odpowiedzialne bd zespoy, albo przez zebranie planw przygoto- przez ka dy z zespow i zestawienie z nich Planu Etapu. To drugie wanych dziaanie bdzie wystpowao w przypadkach, gdy du e fragmenty prac projektu s zlecane podwykonawcom. Kierownik Zespou przygotowuje Plan Zespou jako wkad do su Zar dzanie podproceZakresem (ZE) albo dokonuje dostosowania istniejcego plan z Etapu u Grupy do jako cz podprocesu Przyjmowanie (WP1). W obu przyZada padkach Plan Zespou bdzie wymaga zatwierdzeniaWykonania przez Kierownika Projektu.

15.5.4.

Plany jako ci etapw i plany jako

ci zespow

Plany Etapw i Plany Zespow powinny zawiera plan jakoci, okrelajcy metod(y), bdzie zastosowana do sprawdzania jakoci ka dego produktu wytworzonego/ ktra zaktualizowanego podczas dziaa objtych oraz zasoby, ktre zostan planem, przeprowadzenia tych kontroli. Osoby penice rol Nadzoru Projektu ze wykorzystane do strony i dostawcy maj tutaj do zrealizowania szereg wa nych zada klienta podczas: identyfikowaniu produktw o kluczowym znaczeniu dla nadzorowanych przez nich interesw ; okreleniu, kto powinien by wczony w sprawdzanie jakoci tych pr oduktw; okreleniu, w jakich punktach rozwoju produktu nale y przeprowadzi sprawdzenie jakoci. Na przykad dla wszelkich przegldw jakoci powinny by podane nazwiska kierownikw przegldu oraz testerw. Terminy i nakady pracy zasobw powinny by pokazane graficznie (zwykle na wykresie paskowym). Plany jakoci etapu i plany na planie jakoci nie s oddzielnymi dokumentami, lecz stanowi integraln cz zespou odpowiednich planw.

15.5.5.

Plan Nadzwyczajny to-

Kiedy przewiduje si, e plan nie zostanie zrealizowany w granicach zatwierdzonych sporzdza si Plan Nadzwyczajny, ktry ma zastpi aktualny plan. lerancji, zwykle Plan Nadzwyczajny jest opracowywany na tym samym poziomie szczegowoci, co plan, bdzie zastpiony. Plan Nadzwyczajny przejmuje dane o wykonaniu ktry aktualnego obejmuje okres do koca zastpowanego planu. Wikszo Planw planu i Nadzwyczaj-

249

PLANS

PRINCE2

nych tworzona jest w celu zastpienia Planu Etapu, ale mo e wystpi potrzeba zastpienia Planu Zespou, a nawet Planu Projektu. Struktura Planu Nadzwyczajnego przedstawiona zostaa w Dodatku Zarysy A. opisw produkt . w Plan Nadzwyczajny, ktry ma zastpi Plan Zespou, wymaga zatwierdzenia przez Kierownika Projektu. Jeli zastpuje si Plan Etapu, wymaga to zatwierdzenia przez Komitet Propozycja zastpienia Planu Projektu z powodu przewidywanego pr Sterujcy. zekroczenia tolerancji dla projektu musi by przedstawiona przez Komitet Sterujcy kierownictwu lub firmy programu Wskazwki i rady
Planujc, atwo jest zapomnie o uwzgldnieniu zasobw potrzebnych do przeprowadzania oceny wpywu wnioskw o zmian. Nawet jeli propozycja zmiany jest w konsekwencji odrzucona, ocena jej bdzie zawsze pochania czas i wysiek, zazwyczaj najbardziej dowiadczonych czonkw zespou. Wa ne jest zidentyfikowanie, za ktre produkty s odpowiedzialni klient i dostawca. Aby zarejestrowa t informacj mo na umieci w Opisie Produktu dodatkow pozycj. Wymagane jest, by plany byy opracowywane na waciwym poziomie szczegowoci w celu uatwienia pniejszej kontroli. Czy plany klienta i dostawcy bd opracowane na tym samym poziomie szczegowoci?

25 0

16.

E LE M E NTY S TE ROWA NI A
CONTROLS

Sterowanie zmianami
dz ani Zarz e St rat eg icz ne Pr ojekt em dz ani Zarz Z S4 e St rat eg icz ne Pr ojekt em

Uzasadnienie biznesowe

Directing a Project

Z S4 Z S1 ZS 2 Z S 3 Z S5 Z S1 ZS 2 Z S 3 Z S5
dz ani Zarz e dz ani Zarz e Zakresem Zakresem Et apu Et apu Zam owan wani S rz ykan ie I terygot o ie P ni cjo wani e e Zam owan S rzcjo I rojek wani P roj ykan E terygot u wani Prt apemu ie P niojekttuo ie e e ekt E rojek u Prt ojekttu P roj ektu apem d zan Zar z ie d zan Zar warz Wytz ie ani Pl anow ani e em Wyt warz ani P anow ani e Plrod ukt w em P rod ukt w

Zarz dzanie konfiguracj

Sta rti n g u p a Pr o je ct

In i ti ati n g a Pro j ec t

Co n tro l l in g a S tag e

M an ag i n g S tag e Bo u n da ri e s

C l os i n g a Pro j ec t

Organizacja

Jako w rodowisku projektu

Man a gi n Pr o g uc t De li v er y d

Plany
P la n n in g

Elementy Elementy sterowania sterowania

Zarz dzanie ryzykiem

Rysunek 16.1. strukturalnym

Komponent Elementy sterowania w modelu metodyki PRINCE2

16.1.

Cel sterowania

Sterowanie obejmuje wszystko to, co dotyczy podejmowania decyzji i jest kluczowe dla zarzdzania projektem. Celem sterowania jest zapewnienie, aby projekt: zachowywa opacalno w rozumieniu swego Uzasadnienia Biznesowego; prowadzi do wytworzenia wymaganych produktw, ktr e speniaj okrelone kryteria jakoci; by prowadzony wedug harmonogramu i zgodnie z planami dotyczcymi zasobw i kosztw.

Rysunek 16.2 przedstawia ptl sterowania, w ktrej czynnoci monitorowania pomagaj sprawdza i raportowa zgodno postpu prac z planem. Czynnoci sterowania mog prowadzi do korekt, ktre trzeba wprowadzi do planu w odpowiedzi na problemy wykryte w czasie monitorowania.

25 1

CONTROLS

PRINCE2

Elementy sterowania zapewniaj, by w stosunku do ka dego poziomu zespou zarzdzania projektem, kolejny wy szy poziom zarzdzania mg: monitorowa postp; porwnywa osignicia z planem; przeglda plany i opcje w kontekcie przyszych sytuacji; wykrywa problemy i identyfikowa zagro enia; inicjowa dziaania korygujce; zezwala na dalsze prace. Elementy sterowania musz tak e obejmowa wychwytywanie informacji o zmianach pochodzcych z zewntrz projektu i podejmowanie koniecznych dziaa.
Planuj

Steruj

Monitoruj

Rysunek 16.2. projekcie

Ptla sterowania w

16.2.

Przegl d elementw sterowania

Sterowanie w projekcie odbywa si na r nych poziomach. Wiele elementw ster owania w PRINCE2 zale y od zdarze, wczajc w to wszystkie dotyczce podejmowania decyzji. Zale ny od zdarze oznacza, e dany element sterowania pojawia si, bo wyst-cile okrelone zdarzenie, np. koniec etapu, skompletowanie Dokumentu pio Inicjujcego Projekt, przygotowanie Planu Nadzwyczajnego. Istniej tak e elementy ster owania od czasu, np. regularne raporty zwrotne o postpach. Na poziomie projektu zale ne stpuje sterowanie wystrategiczne realizowane przez Komitet Sterujcy, ktry otrzymuje od Kierownika Projektu (or az od wszystkich osb wyznaczonych do informacje penienia roli Nadzoru i sprawuje kontrol nad tym, czy projekt jest Projektu) kontynuowany, wstrzymywany, czy te zmienia swj kierunek lub zakres. W obszarze zarzdzania dotyczcym bezporednio Komitetu Sterujcego, PRINCE2 wykorzystuje koncepcj zarzdzania . Oznacza to, e po uzgodnieniu z odchyleniami rownikiem Projektu Planu Etapu i jego Kie,Komitet Sterujcy w trakcie zatwierdzeniu jest sukcesywnie informowany o stanie projektu za etapu pomoc raportw. Nie ma potrzeby zwoywania narad w sprawie postpw prac, chyba e sytuacja istotnie odbiegnie od planu, mimo utrzymywania w trakcie caego projektu, w ramach obowizkw wynikajcych z Nadzoru Projektu, regularnych kontaktw z Kier ownikiem Projektu i pozostay mi 25 2

PRINCE2

ELEMENTY STEROWANIA

czonkami zespou. Komitet Sterujcy oczekuje, e Kierownik Projektu poinformuje go natychmiast, jeli tylko bdzie przewidywa, e dojdzie do istotnego odchylenia od planu. Metodyka PRINCE2 jest przygotowana na wystpienie rozmaitych sytuacji, w ktrych mo e znale si klient i dostawca. Dla wyjanienia - niniejszy podrcznik PRINCE2 napisany zosta przy zao eniu, e projekt bdzie realizowany dla klienta z udziaem jednego (gwnego) dostawcy. Wpywa to nie tylko na organizacj projektu, ale tak e na elementy sterowania. Planowany wynik obejmuje te wymagan jako produktw. Celem jest na tyle wczesne problemw, aby mo liwe byo dokonanie poprawek przy najmniejszych wykrycie kosz- Nale y podj dziaania w odniesieniu do ka dego odchylenia od planu, co do tach. kt- przewiduje si, rego e przekroczy granice tolerancji. Postpy prac kontroluje si w odniesieniu do planu - podejmujc niezbdne dziaania, gdy wymagana jest korekta. Wszystkie poziomy zespou zarzdzania projektem uzyskuj informacj za porednictwem raportw i bie c ocen. Kontrolowane zamykanie projektu zapobiega prowadzeniu projektu w nieskoczono, ale te nie pozwala na jego zakoczenie, zanim Kierownik nie przedstawi Ko Projektu Sterujcemu dowodw, e cele okrelone w Dokumencie Inicjujcym mitetowi Projekt zostay osignite. Elementy sterowania wykorzystywane przez Komitet cy Steruj Gwnymi elementami sterowania dla Komitetu Sterujcego s: Zezwolenie na Zainicjowanie (ZS1) - Czy projekt posiada pene i Projektu mocne podstawy, uzasadniajce przejcie do Etapu inicjowania? Zezwolenie na Projekt (ZS2) Czy projekt powinien by Realizacj uUzasadnienie Biznesowe ? Czy ryzyko jest mo liwe realizowany? Czy posiada akceptowalne do przyjcia ? Ocena kocowa etapu realizowana w Zezwolenie na Plan podprocesie Realizacj u Etapu lub Planu (ZS3) Czy etap zakoczy si Nadzwyczajnego powodzeniem? Czy projekt postpuje we waciwym kierunku? Czy Uzasadnienie Biznesowe jest suszne? Czy zarzdzano ryzykiem? Czy kolejny etap powinien by nadal podjty? Raporty Okresowe - regularne raporty o postpach prac w trakcie ; etapu Raporty o Istotnych Odchyleniach wczesne ostrze enia o ka dej przewidywanej przekroczenia tolerancji Etapu lub Projektu. Komitet Sterujcy mo liwoci wsplnie jakie dziaania nale y podj w reakcji na przewidywane rozwa a, odchylenie; Ocena nadzwyczajna realizowana w Zezwolenie na Etap podprocesie Realizacj u lub Planu (ZS3) - Komitet Sterujcy spotyka si celem Nadzwyczajnego i zatwierdzenia Planuprzegldu Nadzwyczajnego; zamknicie projektu realizowane w Zatwierdzenie cia podprocesie projekt dostarczy wszystkiego, czegoZamkni Projektu (ZS5) - Czy oczekiwano? Czy konieczne s jakie dziaania nastpcze? Jakie dowiadczenia wynikaj z projektu?

253

CONTROLS

PRINCE2

Komitet Sterujcy musi tak e kontrolowa zewntrzne otoczenie i podawa do wiadomoci wszystkich zainteresowanych, takich jak Kierownik Projektu, wszelkie zmiany, ktre wpywaj na projekt. Element y sterowania wykorzystywane przez Kierownika Projektu Kierownik Projektu kontroluje etap na bie co i mo e wprowadza wszelkie korekty, gro przekroczeniem przez etap lub projekt tolerancji wyznaczonych ktre nie przez Komitet Sterujcy, o ile te korekty nie zmieniaj Uzasadnienia Biznesowego. Kierownik jest odpowiedzialny za mon itorowanie postpw prac i mo e by Projektu wspomagany osoby penice rol Wsparcia Projektu, jeli takie zostay w tym przez wyznaczone. Zgoda na wykonanie Grupy Zada jest elementem sterowania, ktrym Kierownik Projektu posuguje si, przydzielajc prac poszczeglnym osobom lub zespoom. Obejmuje to kontrolowanie jakoci, czasu i kosztw oraz okrelenie wymaga dla raportowania i spo- przekazania wykonanej pracy. Te elementy sterowania musz znale sobu odwzorowanie we waciwym Planie Zespou, ktry musi by zatwierdzony przez Kierownika Projektu. Pojedyncze osoby lub zespoy monitoruj postpy prac w trakcie Grupy wykonywania Zada i informuj zwrotnie Kierownika Projektu za pomoc Raportw z Punktw Kontrolnych lub na inne uzgodnione sposoby, takie jak sygnay o zmaterializowaniu si zagro enia, oraz poprzez aktualizowanie Rejestru Grupa Zada powinna zawieJakoci. ra informacj, jakie tolerancje dla zleconych prac zostay uzgodnione midzy 24 . Kierownikiem Projektu a Kierownikiem Zespou Grupa Zada jest podstawowym elementem styku z ka dym zewntrznym dostawc istotny element sterowania wykorzystywany przez Kierownika Projektu i stanowi - bejmujc zwykle (jeli j opracowano) uzgodnienie prac, ktre maj by o wykonane, Opisy Produktw, zasady raportowania i sposb sprawdzenia jakoci. Raport z Punktu Kontrolnego jest raportem o postpach prac, ktry Kierownik Zespou przygotowuje dla Kierownika Projektu, z czstotliwoci ustalon w Grupie Zada. Jest wytwarzany w trakcie on Wykonywanie Grupy (WP2). procesu Zada Kierownik Projektu powinien wprowadzi do Rejestru Jakoci informacje o wszelkich jakoci, uzgodnionych pierwotnie dla Grupy Zada. Kierownik Zespou kontrolach powinien aktualizowa te w miar jak kontrole zostan przeprowadzone. wpisy,zapisw przeprowadzana Weryfika-podczas cja jest Ocena pw (SE2). podprocesu Post Cay personel pr ojektu, cznie z dostawcami zewntrznymi, powinien zosta poinstru- o sposobie owany zgaszania Zagadnie Zgaszanie zagadnie Projektowych. przez czonkw zespou dodatkowo wspomaga Kierownika Projektu w sterowaniu projektem. Rejestr Ryzyka su y Kierownikowi Projektu do monitorowania sytuacji, w ktrej znalaz si etap. Rejestrowanie i analizowanie nowych lub zmienionych zagro e wystpuje podprocesach i stanowi integraln cz elementw sterowania w wielu wykorzystywanych przez Kierownika Projektu.

24

Lub wykonawc przypis tumacza.

25 4

PRINCE2

ELEMENTY STEROWANIA

16.3.

Przygotowanie Projektu (PP)

Przygotowanie projektu jest niezbdne dla waciwego sterowania projektem. Obejmuje ktrych wykonania PRINCE2 wymaga, zanim projekt si rozpocznie. ono prace, Jego zadaniem jest: ustanowienie zespou zarzdzania projektem, aby Komitet i Kierownik Sterujcy mogli podj niezbdne decyzje wstpne zwizane z Projektu projektem; rozwinicie tego, co mo e by uznane za pierwotne Zlecenie Przygotowania Projektu, w Zao enia Projektu; ustalenie Formuy Realizacji Projektu; zaplanowanie Etapu inicjowania. Ustanawianie waciwego zespou zarzdzania projektem o mwione jest w Rozdziale 1 4 rganizacj . O a Etap inicjowania projektu prawdopodobnie bdzie krtki w porwnaniu z innymi etapa- zanim do niego dojdzie, niezbdne jest zezwolenie przez Komitet Sterujcy mi, ale na uruchomienie. Dlatego przygotowanie projektu musi obj przygotowanie planu jego dla Etapu inicjowania, ktry Komitet Sterujcy sprawdzi w celu peniejszego zrozumienia rodzaju wymaganego zaanga owania. Plan musi zawiera list wszelkich elementw sterowania, ktre bd zastosowane, oraz wykaz raportw, ktre Komitet Sterujcy bdzie otrzymywa, tak aby z gry mia pewno, e Etap inicjowania bdzie pod jego kontrol. Poniewa Zlecenie Przygotowania Projektu opracowywane jest poza kontrol projektu, czsto jest zbyt lakoniczne i nie dostarcza wszystkich informacji, ktrych projekt potrzebuje. Przygotowanie (PP) daje Kierownikowi Projektu okazj do rozwinicia Projektu enia Projektu i go ten sposb do przedstawienia jego celw do w pene Zao w zatwierdzenia przez Komitet Sterujcy. Je eli projekt jest czci programu, to program powinien dostarczy kompletne Zao enia Projektu, usuwajc w ten sposb potrzeb opracowania ich w czasie przygotowywania projektu.

16.3.1.

Zezwolenie na Zainicjowanie Projektu (ZS1)

Po zrealizowaniu Przygotowanie (PP) Komitet Sterujcy procesu Projektu jest oficjalnym zatwierdza przejcie do Etapu inicjowania, co pocztkiem projektu. Wymaga to udokumentowanego zezwolenia, udzielonego przez wszystkich czonkw Sterujcego, ktrych dotychczas nominowano. W zale noci od wielkoci Komitetu projektu, stanu ryzyka, znaczenia i rodowiska projektu, zezwolenie to mo e by udzielone na formalnym posiedzeniu lub bez koniecznoci zwoywania go. Po zezwoleniu na uruchomienie Etapu inicjowania, kopia Zao e Projektu powinna zosta pr zesana do wszystkich w tym tak e do gremiw interesariuszy, eksploatacyjne produktu kocowego. Su y to przekazaniu odpowiedzialnych za wsparcie wyprzedzajcej potrzebie przygotowania takiego informacji o wsparcia.

255

CONTROLS

PRINCE2 Inicjowanie projektu

16.3.2.

Celem inicjowania projektu jest zapewnienie, e - zanim jakiekolwiek znaczne zasoby zu ytkowane - wszystkie zaanga owane osoby zostan uzgodni: cele projektu; produkty, ktre maj by dostarczone; przyczyny, dla ktrych realizowany jest projekt; kto jest klientem; kto ma jaki zakres obowizkw i uprawnie; granice projektu i punkty styku ze rodowiskiem zewntrznym; jak zostan osignite cele; jakie zao enia zostay bd mog by poczynione; jakie s gwne zagro enia, mogce przeszkodzi w osigniciu celw projektu; kiedy zostan dostarczone gwne produkty; ile bdzie kosztowa pr ojekt; w jaki sposb bdzie sterowany; sposb podziau projektu na etapy; jak bdzie oceniana akceptowalno produktw projektu. Odpowiedzi na te pytania znajduj si w Dokumencie Inicjujcym Projekt, ktry jest gwnym produktem tego etapu. Proponowany zarys zawartoci Dokumentu Inicjujcego przedstawiony w Dodatku Projekt jest Zarysy opisw A produktw. Innym produktem Etap u inicjowania jest Plan Etapu (nastpnego), tak by w przypadku, gdy Komitet Sterujcy bdzie zadowolony z zawartoci Dokumentu Inicjujcego Projekt, e zezwoli na przejcie do kolejnego etapu bez adnych dalszych mg tak opnie. Po zatwierdzeniu na kocu Etapu inicjowania, Dokument Inicjujcy Projekt staje si obiektem odniesienia. Bdzie on odtd dokumentem referencyjnym, pokazujcym pier- podstaw projektu. Na kocu projektu mo e by porwnany z finalnymi wotn oczeki- i wynikami, aby oceni powodzenie przedsiwzicia i sprawdzi, czy np. waniami wszelkie zmiany Planu Projektu zostay dokonane w sposb kontrolowany. Jest to istotna cz rewizyjnego, wiadczcego o tym, jak projekt by ladu zarzdzany. W trakcie projektu prawdopodobnie wystpi zmiany. Byoby niebezpieczne nie odnotowywa ich oddziaywania oraz nie przekazywa zespoowi zarzdzania projektem aktualnych informacji. Dlatego w miar zachodzenia zmian bd tworzone kolejne wersje najbardziej zmiennych sekcji Dokumentu Inicjujcego Projekt. Kolejne wersje stanowicie ki rewizyjnej, ukazujc wszelkie zmiany informacji zawartych w cz Dokumencie Projekt, kiedy i dlaczego do nich doszo oraz jaki by ich wpyw. Inicjujcym Najbardziej sekcjami Dokumentu Inicjujcego Projekt zmiennymi s: Plan Projektu; Uzasadnienie Biznesowe; Rejestr Ryzyka.

25 6

PRINCE2

ELEMENTY STEROWANIA

Po opracowaniu kolejnych wersji Planu Projektu oraz Uzasadnienia Biznesowego i uznaniu ich za obiekty odniesienia, umieszcza si je w czci zarzdczej doku mentacji projek- dotyczce ich Zapisy Obiektw Konfiguracji aktualizuje si. Odpowiednia tu, a struktura gromadzenia dokumentacji projektu przedstawiona jest w Dodatku systemu Zar dza E z nie projekt . Poniewa Rejestr Ryzyka podlega cigym zmianom, nale dokumentacj u y uwa nie przemyle sposb zarzdzania konfiguracj w jego przypadku. Te zmienne sekcje musz by uaktualniane w trakcie caego projektu przynajmniej na kocu ka dego etapu. Podsumowujc, gwnym celem Dokumentu Inicjujcego Projekt jest zgromadzenie informacji, ktre s odpowiedziami na pytania: Co?, Po co? / Dlaczego?, Kto?, Kie- Gdzie?, Jak? i Za dy?, ile?. Wskazwki i rady
W czci Elementy sterowania projektem Dokumentu Inicjujcego Projekt nale aoby wspomnie o prowadzeniu Rejestru Dowiadcze (patrz: podrozdzia 16.4.5). Uczula to czytelnikw na fakt, e powinien to by dokument wykorzystywany i uzupeniany przez cay cykl ycia projektu. W przeciwnym razie jego wypenienie mo e by pozostawione a do zamknicia projektu, kiedy to wspomnienia niektrych dowiadcze mog si zatrze.

16.3.3.

Podzia na etapy

W zale noci od wielkoci i ryzyka, Komitet Sterujcy powinien zdecydowa o podziale projektu na odpowiedni liczb etapw Zostaje to uzgodnione w zarzdczych. czasie Etapu inicjowania. Przyczyny podziau na etapy omwione s w podrozdziale Eta 16.6 p . y Koniec ka dego etapu stanowi gwny punkt kontrolny dla Komitetu Sterujcego (patrz: podrozdzia 16.4.11 Ocena ko cowa ). Std wybr liczby etapw oraz ich terminarza w cyklu ycia projektu jest etapuny m elementem sterowania dla Komitetu wa Sterujcego. Plan Komunikacji Jedn z czci Dokumentu Inicjujcego Projekt jest Plan Komunikacji. Odgrywa on istotn rol w sterowaniu projektem poprzez zidentyfikowanie, kto powinien otrzymywai kto powinien udziela informacji o projekcie. Sugerowany opis jego informacje zawar-umieszczony jest w Dodatku toci Zarysy opisw . Plan ten A produktw ukazuje: kto bierze udzia w projekcie; kto potrzebuje informacji; jakiej informacji potrzebuje; kiedy jej potrzebuje; format, w ktrym infor macje powinny by przedstawione. 257

16.3.4.

CONTROLS

PRINCE2

Plan Komunikacji powinien obejmowa wy sze kierownictwo lub kierownictwo programu, interesariuszy i inne zainteresowane strony, jak te, ktre bd musiay wspiera produkt w okresie jego eksploatacji.

16.4.

Kontrola post

pw

W czasie trwania projektu istnieje potrzeba zapewnienia, by pozostawa on w zgodzie z oczekiwaniami zdefiniowanymi w Dokumencie Inicjujcym Projekt i w bie co realizowanym Planie Etapu.

16.4.1.

Tolerancja

Tolerancja jest dopuszczalnym odchyleniem od planu, ktre nie wymaga poinformowania o odchyleniu nastpnego, wy szego szczebla zarzdzania. aden projekt nie przebiega w stu procentach zgodnie z planem. Nawet przy dobrym planie pewne rzeczy bd szy wolniej ni przewidywano lub bd kosztoway troch wi- inne rzeczy pjd szybciej lub bd kosztoway nieco mniej. Takie zmiany bd cej; zachodziy zawsze w okresie realizacji planu. Komitet Sterujcy uzgodni plan, nie jest jego zamiarem, aby Kierownik Cho Projektu bez przerwy wraca, mwic: Wydaem nieco wicej, ni zaplanowaem na ten tydzie albo: Jestem o dzie spniony w tym tygodniu. Z drugiej strony, Komitet Sterujcy sobie, by w przypadku, gdy postpy prac odbiegaj znacznie od planu, nie yczy pozosta bez informacji o tym i bez mo liwoci reagowania. Relacje midzy Kierownikiem Pro- a Kierownikiem Zespou wymagaj podobnego poziomu jektu Wobec tego, kontroli. y linia podziau midzy odchyleniami, ktre s dopuszczalne, od tych, gdzie le ktre wymagaj interwencji Komitetu Sterujcego albo Kierownika Projektu? Ta linia podziau nazywana jest tolerancj. Wartoci tolerancji ustalane s w czterech warstwach struktury zarzdzania projektem, w Rozdziale 14 omwionych Organizacj . Tolerancje dla projektu jako caoci s a wyznaczane Komitetowi Sterujcemu przez kierownictwo firmy lub programu w Zleceniu Przygotowania Projektu (lub po ustaleniu ich przez Przewodniczcego czasie w przygotowywania projektu), i wczane do Zao e Na podstawie tak okrelonych Projektu. tolerancji dla projektu, Komitet Sterujcy uzgadnia z Kierownikiem wartoci Projektu dla ka dego etapu, gdy tylko zostanie sporzdzony Plan tolerancje Kierownik Etapu. mo e uzgodni z Kierownikiem Zespou poziomy tolerancji dla Grupy Projektu Zada. Gdy na ktrym szczeblu zarzdzania powstaje przypuszczenie, e uzgodniona tolerancjaprzekroczona, musi on niezwocznie przedo y spraw wy ej, tj. jeli zostanie tolerancja przydzielona przez Kierownika Projektu Kierownikowi Zespou w ramach Grupy Zada prawdopodobnie zostanie przekroczona, Kier ownik Zespou raportuje o tym Kierownikowi Projektu. Kierownik Projektu mo e ustali nowe tolerancje w oparciu o now prognoz, o ile bior one pod uwag ograniczenia, wynikajce z oglnych wartoci tolerancji dla etapu. Jeli przewiduje si, e tolerancje dla etapu zostan przekroczone, Kierownik Projektu musi przedo y spraw Komitetowi Sterujcemu. Komitet Sterujcy mo e ustali nowe tolerancje w oparciu o now prognoz, dopki mieszcz si one w ramach ogra- dla oglnych wartoci tolerancji dotyczcych projektu. Gdy progn ozuje si, e nicze tolerancje dla projektu zostan przekroczone, Komitet Sterujcy musi zwrci si z t

25 8

PRINCE2

ELEMENTY STEROWANIA

spraw do kierownictwa firmy lub programu w celu uzyskania decyzji. Rysunek 16.3 przedstawia ten kaskadowy efekt.
Kierownictwo firmy lub programu Odchylenia od Planu Projektu Komitet Tolerancje dla etapu Steruj cy Odchylenia od Planu Etapu

Tolerancje dla projektu

Kierownik Projektu Tolerancje dla Grupy Zada Kierownik Zespou

Odchylenia od Grupy Zada

Rysunek 16.3. zarz-

Wykorzystanie tolerancji na czterech poziomach struktury dzania projektem

Dwa standardowe parametry projektu, dla ktrych okrela si tolerancje, to: czas 25 ; koszt.

Oddzielne wartoci tolerancji powinny by podane dla czasu i kosztw. Wartoci toleran- musz by takie same dla grnych i dolnych odchyle kosztw lub czasu. cji nie Tolerancja na przykad od +5 % do - 20 % mo e by bardziej realistyczna ni +/10 %. Bardziej realistyczne mo e by okrelenie tolerancji w wartociach bezwzgldnych ni w procen- dziesi dni albo okrelona kwota. Ustalanie tych tolerancji jest tach: np. wykonywane jako cz procesu Planowani (PL). e Rysunek 16.4 ilustruje tolerancje dla planowanych kosztw i czasu, a tak e margines w podejmowaniu decyzji przez Kierownika Projektu lub Kierownika swobody Zespou, wynikajcy z wartoci tych tolerancji. rodkowa linia (OA) wytycza plan. Linie (OB) i OC) ukazuj granice tolerancji kosztw i czasu. Punkt B pokazuje, e projekt mo ( e osztowa nieco wicej, ni przewidywano, i trwa troch du ej. Punkt C pokazuje, k e rojekt mo e kosztowa nieco mniej i trwa troch krcej, ni przewidywano. Jeli p reali- planu zakoczy si wewntrz prostokta wyznaczonego tymi punktami (pole zacja tolerancji), uwa a si, e plan jest zrealizowany w granicach tolerancji. Linia (OD) poka- jak faktycznie przebiegay prace. Chocia obserwuje si odchylenie od planu, to zuje pozostaje ono w granicach tolerancji. Jeli w ktrym momencie realizacji planu, Kierownik Zespou lub Projektu bdzie prognozowa, e koniec linii (OD) znajdzie si poza polem tolerancji, powinien uruchomi specjaln procedur Raport o Istotnych (patrz i Plan Odchyleniac opisane dalej w tym rozdziale), ktra uruchamia h Nadzwyczajny zarzdzanie odchyleniami .
25

Trwania lub osignicia okrelonego stanu przypis tumacza.

259

CONTROLS

PRINCE2

Uwaga: Mo e si zdarzy, e przyspieszone wydatki, w odr nieniu od wydatkw nadmiernych, mog spowodowa, e chwilowo linia D znajdzie si ponad lini B, chocia prognoz na kocu projektu pozostanie ona wewntrz pola tolerancji. W wedug takim przypadku zaleca si Kierownikowi Zespou bd Kierownikowi Projektu zawiadomi wy szy poziom zarzdzania, o tym co si zdarzyo, np. w kolejnym Raporcie z Punktu Kontrolnego lub w Raporcie Okresowym.

Maksimum tolerancji dla kosztu

B Nowa prognoza A Zatwierdzony plan

Koszt

Minimum tolerancji dla kosztu

Czas

Rysunek 16.4. Wykr es tolerancji w ukadzie wsprzdnych czas / koszt Inne typowe przykady tolerancji opisano poni ej. Tolerancja dla zakresu Tolerancja dla zakresu mo e by zastosowana tam, gdzie nie mo na okreli tolerancji czasu, ani dla kosztw. Mo e istnie porozumienie, by nie przekroczy ani dla limitu i pienidzy, dostarczajc zmniejszon funkcjonalno. Przykadami tolerancji czasu dla zakresu mog by: Tak, mo esz otrzyma dom w tym terminie, ale prysznic nie bdzie zamontowany, albo: W tym terminie mo emy zidentyfikowa 90 % adresw wychodzcej poczty. Wymagania w odniesieniu do zakresu projektu powinny by podzielone na istotne i po dane - wanie ta r nica midzy jednymi a drugimi wyznacza tolerancj dla zakresu. Tolerancja dla ryzyka Inne spojrzenie na granice tolerancji stosuje si podczas rozwa ania ryzyka. Czasami 26 , co nale y rozumie w sposb nastpujcy: nazywa si to apetytem na ryzyko ryzyko jest gotw ponie Komitet jak wielkie Mo e si to Sterujcy? zmienia
26

Albo dopuszczalnym ryzykiem lub poziomem akceptacji ryzyka przypis tumacza.

26 0

PRINCE2

ELEMENTY STEROWANIA

w zale noci od kategorii ryzyka, a jest najczciej tak, e tolerancja ryzyka czy si bdzie cile z innymi jego elementami - np. firma majca kopoty finansowe mogaby mie bardzo niewielki margines tolerancji dla ryzyka finansowego, ale pozwoli sobie na tolerancj ryzyka w kategoriach jakoci. Tolerancja dla ryzyka jest czstokro du stosowana jedynie wobec caego projektu, cho mo liwe jest podjcie wikszego lub mniej- ryzyka zwizanego z poszczeglnymi szego produktami. Tolerancja dla korzy ci

Komitet Sterujcy mo e chcie r ozwa y inny aspekt - tolerancj dla tolerancji to ustanowienie granic po obu stronach korzyci. Jak dugo przewiduje si, korzyci. Implikuje e orzyci zmieszcz si w tych granicach, bdzie to przemawia za susznoci k Uzasad- Biznesowego. Tolerancj dla korzyci stosuje si wobec oczekiwanych nienia korzyci, przedstawionych w Uzasadnieniu Biznesowym. Tolerancja dla jako ci

Ostatnim rodzajem tolerancji, ktry chciano by dopuci w projekcie jest jako, ale cza- ogr aniczenia wynikajce z innych rodzajw tolerancji mog to wymc. sem Chodzi o akceptacj Odstpstwa w postaci Ustpstwa. Przykadami tolerancji dla gwnie jakoci mog by: Mo esz otrzyma samochd w ka dym kolorze, pod warunkiem, e bdzie on czarny lub Mo emy odda oprogramowanie w okrelonym terminie, ale jego bdzie du szy. reakcj i

czas

Rezerwa, tolerancja i bud et zmian Istnieje r nica midzy rezerw a tolerancj. W rozumieniu PRINCE2 rezerwa jest to bu- obejmujcy czas i pienidze odo one na wykonanie planu rezerwowego, ktry d et b- realizowany tylko wtedy, gdy zwizane z nim zagro enie rzeczywicie si dzie zmaterializuje. Tolerancja jest wbudowana w plan, by dopuci mae problemy i bdy w szaco- (na plus lub na minus), takie jak te opisane waniu wczeniej. Jak zostao to przedstawione w Planowanie (IP2), ju na podprocesie y rozwa y ustanowienie bud etuProjektu by zapewnipocztku projektu nale zmian, finansowanie zatwierdzonych zmian. Tolerancje, szczeglnie w kategoriach kosztw, nie powinny by mylone z bud etem zmian. Tolerancja nie su y do pokrywania kosztw wtedy, gdy u ytkownicy zmieni zdanie. Jeli w trakcie Etapu inicjowania nie ustanowiono bud etu zmian, swoje zawsze pojawiaa si pokusa, eby wykorzysta tolerancj do pokrycia kosztw bdzie zmiany specyfikacji. Alternatyw mo e by zwrcenie si Kierownika Projektu do Komitetu Sterujcego z prob o przyznanie dodatkowych pienidzy na pokrycie kosztw Mozmian. by e to irytujce i powodowa marnotrawstwo czasu, szczeglnie jeli Przewodniczcy musi si wwczas odwoywa do kierownictwa firmy/programu o przyznanie dodatkowych rodkw.

261

CONTROLS Wskazwki i rady

Jeli tolerancja dla czasu jest wska lub adna, np. gdy produkt kocowy musi by dostarczony do dnia X, Kierownik Projektu bdzie zwykle oczekiwa zwikszenia tolerancji dla jednego lub kilku innych parametrw, takich np. jak koszt (np. Czy bdzie mo na wykorzysta wicej zasobw lub godzin nadliczbowych w celu zapewnienia, e tolerancja dla czasu nie zostanie przekroczona?). Jeli tolerancja dla czasu, kosztw i zakresu jest niewielka lub adna, Kierownik Projektu musi czuwa nad pokus poszczeglnych osb lub zespow, by zaoszczdzi czas przez nieoficjalne obni enie jakoci pracy.

PRINCE2

16.4.2.

Opisy Produktw

Opis ka dego z produktw jest sporzdzany, zanim produkt zostanie wytworzony lub uzyskany, a nawet zanim zostanie to -w celu zapewnienia, zaplanowane poszczeglne osoby wiedziay: dlaczego jest potrzebny; jak bdzie wyglda; skd bdzie pochodzi;

by

jaka bdzie specyfikacja jakoci, zgodnie z ktr musi by zbudowany. Opis Produktu jest dokumentem su cym do sterowania i kontroli. Jest on sporzdzany w trakcie Planowani (PL) i definiuje produkt, standardy, ktre maj zosta u procesu jego wytwarzaniu oraz ye te przy kryteria jakoci, ktre bd zastosowane w celu stwierdze- on zgodny ze swym przeznaczeniem. Ta informacja jest istotna nie tylko nia, e jest dla wytwrcy produktu, bowiem Opis Produktu stanowi tak e wstpn list kontroln dla sprawdzenia jakoci ukoczonego produktu. Gdy produkt zostanie zidentyfikowany w przygotowywanym w tr akcie tworzenia planu Diagramie Struktury Produktw, nale yaszkicowa jego Opis Produktu. Wszystkie strony, ktre bd u ytkoway n ukoczony produkt, powinny wzi udzia w przygotowaniu Opisu Produktu. Zarysy Opisw Produktw dla standardowych produktw zarzdczych PRINCE2 (takich jak plany, raporty, zezwolenia) znajduj si w Dodatku Zarysy Opisw . A Produktw Wszystkie Opisy Produktw musz by zatwierdzone. Formalnie Komitet Sterujcy zatwierdza Opisy Produktw dla gwnych produktw. Jeli role Nadzoru Projektu czonkw Komitetu Sterujcego zostay delegowane, nadzr nad Opisami Produktw mo e y jednym z delegowanych uprawnie. b Odnony Opis Produktu stanowi cz Grupy Zada, przekazywanej jednostce lub zespoowi odpowiedzialnemu za jego W ramach zarzdzania dostawcami wytworzenie. podczas podprocesu Zgoda na Wykonanie Grupy (SE1) - Kierownik uzgad27 Zada Projektuskad Grupy Zada. nia z Kierownikami Zespow Opisy Produktw, ktre wchodz w

27

Lub konkretnymi wykonawcami, jeli nie powoano Zespow przypis tumacza.

26 2

PRINCE2 Wskazwki i rady

ELEMENTY STEROWANIA

Opisy Produktw powinny by napisane przez personel, ktry zna proponowany produkt. U ytkownicy powinni bra udzia w ustalaniu kryteriw jakoci. Opisy Produktw mog nie by potrzebne dla ka dego produktu. Komitet Sterujcy moe zdecydowa, co uwa a za gwne produkty projektu, dla ktrych Opis Produktu jest konieczny.

16.4.3.

Grupa Zada

Wydanie przez Kierownika Projektu zgody na wykonanie Grupy Zada jest sygnaem dla pojedynczej osoby lub zespou do podjcia jakiej czci prac etapu. Wynika z tego, e raca nie mo e by podjta, zanim Kierownik Projektu nie wyda zgody na jej p wykonanie. Praca zostaje przekazana pojedynczej osobie lub Kierownikowi Zespou w formie wza- uzgodnionej Grupy Zada. Bdzie ona zawieraa Opis(-y) Produktu(jemnie ograniw), takie jak czas, koszt czy punkty styku z otoczeniem, wymagania dotyczce czenia, raportowania i przekazania produktu po jego wytworzeniu, oraz wszelk inn dokumentacj konieczne do zrozumienia i wykonania Grupy lub produkty Wydawanie zgody na Zada. wykonanie Grupy Zada jest szczeglnie u yteczne, gdy ma si do czynienia z zewntrznymi wykonawcami lub Dwie uczestniczce w nim strony podwykonawcami. s opisane w podrozdziaach: (przekazu- Zgoda jcy i odbierajcy) na Wykonanie Grupy 7.4 i 8.4 Przyjmowanie Zada (SE1) Grupy do (WP1). Zada Wykonania

16.4.4.

Kontrola jako

ci

Ka dy projekt wymaga procedur i technik do kontroli jakoci wytwarzanych produktw.elementy sterowania jakoci bd si zmienia w zale noci od typu W ideale, produktu a PRINCE2 nie ma ambicji zdefiniowania wszystkich mo liwoci w tym i projektu, zakresie. Zawiera ona jednak oglny sposb sprawdzania jakoci, nazywany przegldem ego skuteczno potwierdzia si w sprawdzaniu jakoci dokumentw. jakoci, ktr (Za- przyjte w przegldzie jakoci stosowa mo na w przypadku ka dego sady produktu). Przegld jakoci jest jedn z metod sprawdzenia jakoci. Jest to zespoowa metoda oceny jakoci produktu poprzez proces przegldu. Jego celem jest sprawdzenie w planowy, nie- ny, kontrolowany i udokumentowany sposb, czy produkt nie zawiera bdw. zale Dokumentacja przegldw od chwili umieszczenia jej w sekcji jakoci w jakoci, dokumentacji projektu, stanowi wiadectwo, e produkt zosta sprawdzony, e wszelkie znalezione bdy zostay skorygowane oraz e wykonanie zaleconych korekt tak e zostao spraw- wiado mo, e produkt zosta sprawdzony i uznany za wolny od bdw, dzone. daje pewniejszy punkt wyjcia dla dalszych dziaa i wykorzystania takiego produktu za podstaw dalszych prac. Przegld jakoci mo e by wykorzystywany do kontroli jakoci - w tym dokumentw zostay opracowane przez specjalistw. Przegld jakoci dostarcza tych, ktre informacji Kierownikowi Projektu o statusie dokumentu. Technika przegldu jakoci zwrotnej jest w peni opisana w Rozdziale 24.

263

CONTROLS

PRINCE2

Przegld jakoci, ktry wpisano jako metod kontroli jakoci produktu w Opisie Produk- si czci Grupy Zada dla takiego tu, staje Powinien zosta uzgodniony produktu. styku midzy Kierownikiem Projektu a Kierownikiem Zespou jako element (SE1/WP1). jakoci Przegldy s czci Wykonywanie Grupy (WP2) , a ich podprocesu zapisywane w Rejestrze Zada szczegy s Jakoci. Istnieje wiele innych typw kontroli jakoci - w zale noci od produktu, ktry ma by testowany. Powinny one by okrelone w Opisie Produktu dla produktu(- w), do ktrego(-ych) si je stosuje. PRINCE2 pozwala na stosowanie ka dego ze sposobw kontroli. Rejestr Jako ci

Zawiera zapisy wszelkich planowanych i przeprowadzonych kontroli Powstaje jakoci. w podprocesie Planowanie (IP1). Pierwszych wpisw, dotyczcych planowac Jako i nych kontroli, dokonuje Kierownik Projektu w ramach Planowanie podprocesu tym Etapu (ZE1). W czasie ka dego z przegldw jakoci powinien ju by kierownik znany i wpisany do tego rejestru. Kierownik Zespou mo e dodawa kolejnych testerw podczas kompletowania Planu Ze- w podprocesie Przyjmowanie spou Grupy do (WP1). Zada Wykonania Nadzr Projektu powinien to potwierdzi i mo e doda kolejnych testerw, majcych zapewni pene uwzgldnienie nadzorowanych interesw. Po przeprowadzeniu kontroli jakoci w Wykonywanie Grupy (WP2) , podprocesie Zespou powinien wprowadzi wyniki kontroli do Rejestru Jakoci. Zapisy Zada Kierownik te sprawdzane w podprocesie s Ocena pw (SE2) i poddawane przegldowi w podPost procesie Przeg d Stanu (SE5). l Etapu Wyczerpujcy opis zalecanej struktury Rejestru Jakoci podany jest w Dodatku Zarys A y Opisw Produktw . Zagadnienia Projektowe i sterowanie zmianami Ka dy projekt musi posiada procedur postpowania ze zmianami. Bez sterowania nie mo na sterowa zmianami projektem. Czci sterowania musi by procedura rozpatrywania nieprzewidzianych odchyle od wymogw sformuowanych w Opisie Produktu. Odchylenia takie pojawiaj si z wielu powodw: zmieniaj si wymagania u ytkownika; zmienia si prawo i specyfikacja produktu musi zosta zrewidowana w celu dostosowania jej do tych zmian; u ytkownik lub dostawca chc zmieni lub doda jakie kryterium akceptacji; w trakcie postpu realizacji wprowadzenie pewnych dodatkowych cech samo si narzuca; zachodz organizacyjne lub biznesowe zmiany, ktre wpywaj na zakres i cele projektu;

16.4.5.

26 4

PRINCE2

ELEMENTY STEROWANIA

dostawca dochodzi do wniosku, e niemo liwe bdzie dostarczenie wszystkiego uzgodnionych kosztw lub w ramach terminu; pojawia si pytanie, czy dostawca umie zrealizowa okrelon cz specyfikacji lub speni kryterium akceptacji; jaki podwykonawca lub powizany inny projekt (dziaanie) nie s w stanie sprosta zaplanowanemu zobowizaniu; zmienia si dostpno zasobw. Poza mo liwociami sterowania odchyleniami nale y tak e zapewni w projekcie mo liwo zgaszania zastrze e i obaw. Wszystkie te elementy wymagaj procedury kontrolu- oraz ich oddziaywanie na projekt. W PRINCE2 z wszelkimi takimi spr jcej je awami postpuje si wedug procedury obsugi Zagadnie Projektowych. Procedura zapewnia nie tylko by wszelkie zastrze enia, problemy, obawy lub sugestie odpowied, ale tak e aby adne dziaanie nie zostao podjte bez wiedzy znalazy odpowiedniego szczebla - wcznie z Komitetem Poza zarzdzania zmianami zapewnia onaSterujcym. punkt wejciowy, w ktrym mog sterowaniem mo liwymi formalny by zgaszane wszelkie zastrze enia i wnioski. Kierownik Zespou powinien zgasza Kierownikowi Projektu wszelkie zaistniae Zagadnienia Projektowe. Procedura obsugi Zagadnie Projektowych rejestruje i obsuguje Zagadnienia Projektowe wnoszone w trakcie projektu. Zapewnia wiedz o statusie wszystkich Zagadnie Projektowych, kontroluje proces ich zaatwiania i zapewnia zgaszajcemu informacj zwrotn o podjtych dziaaniach. Wyjanione jest to bardziej szczegowo w Rozdziale 20 rowanie . zmianami

Ste -

16.4.6.

Rejestr Ryzyka

Zarzdzanie ryzykiem jest wa nym elementem sterowania w czasie tr wania projektu. Prowadzony jest Rejestr Ryzyka, obejmujcy wszystkie zidentyfikowane zagro enia, ich analiz, rodki zaradcze oraz status. Otwiera si go na pocztku projektu i prowadzi a do jego zamknicia. Wszystkie zagro enia s regularnie przegldane. Minimum wy maga zagro enia byy poddane ponownej ocenie na kocu ka dego etapu, chocia to, by powinny by one rwnie przegldane jako element oceny postpw etapu. Ryzyko jest szerzej opisane w Rozdziale Zar dzanie . 17 z ryzykiem

16.4.7.

Punkt kontrolny

Punkt kontrolny jest wyzwalanym czasem elementem sterowania, umo liwiajcym stanu prac zespou. Dotyczy on wszystkich osb wykonujcych pr sprawdzenie ace,realizowany jest przez a Kierownika Mo e to by formalna lub nieformalna Zespou. czstotliwo realizacji powinna by jasno okrelona w Grupie narada, a Zada. Jednym ze specyficznych celw punktu kontrolnego jest sprawdzenie wszystkich aspektw pracy zespou w odniesieniu do planu w celu zapewnienia, e nie bdzie nieprzyjem-

265

CONTROLS

PRINCE2

nych niespodzianek. Po yteczne s pytania: Co nie przebiega zgodnie z planem? i Co prawdopodobnie nie przebiegnie tak, jak zaplanowano? Informacje zebrane w punkcie kontrolnym s rejestrowane w Raporcie z Punktu Kontrol- celu przedstawienia Kierownikowi Projektu. Zbieranie danych mo e by nego w przeprowadzone formalnie lub nieformalnie, w zale noci od projektu lub warunkw pracy zespou. Raporty z Punktw Kontrolnych s zestawiane przez Kierownika Projektu wykorzystywane do oceny postpw prac etapu. Punkty kontrolne powinny i cznie wystpowa czstotliwoci wymagan przez Kierownika Projektu dla utrzymania kontroli nad postpami prac. Mog si one zbiega z potrzeb rozwa enia przez Kierownika Projektu modyfikacji planu. Sugerowana zawarto Raportu z Punktu Kontrolnego jest przedstawiona w Dodatku Aarysy Z Opisw . Produktw Planowanie i modyfikacje planu Plany s do pewnego stopnia oparte na domysach. Dziaania nie zawsze przebiegaj w zaplanowany sposb. Zasoby nie zawsze pracuj tak, jak zao ono. Mog si pojawi niezaplanowane dziaania. Kierownik Projektu musi regularnie porwnywa plan z naj- szymi informacjami i by gotowy do zmiany planu. Brak modyfikacji planu wie lub modyfikacje zbyt rzadkie mog doprowadzi do tego, e bdzie ju za pno, by naprawi powstay stan rzeczy. Istnieje jednak e niebezpieczestwo reakcji zbyt wczesnej lub czstej, odnoszcej si do dziaa niekrytycznych. Drobne odchylenia mog zbyt napra- si same, a Kierownik Projektu mo e spdzi zbyt du o czasu na wi modyfikowaniu na monitorowaniu jego realizacji. Kiedy i jak czsto modyfikowany planu, zamiast b- plan, bdzie zale ao od wielkoci i znaczenia projektu i jest kwesti osdu dzie Kierownika Projektu. Modyfikacje planu, dotyczce zakresu mog by niezbdne, gdy pojawiaj etapu, odchylenia. Wszelkie poprawki do planu, ktre nie wy magaj zatwierdzenia si istotne przez Komitet bd wprowadzane w ramach podprocesu Podejmowanie Dziaa Sterujcy, cyc (SE7) . Korygu j h

16.4.8.

16.4.9.

Raport Okresowy

Raport Okresowy to sporzdzane w okrelonych terminach sprawozdanie Kierownika Projektu dla Komitetu Sterujcego, dotyczce postpu prac etapu. Wszystkie ostatnio przekazane Raporty z Punktw Kontrolnych bd stanowiy wkad do kolejnego Raportu Okresowego. Kierownik Projektu przesya go do Komitetu Sterujcego w trakcie etapu z czstotliwoci podyktowan przez Komitet Sterujcy. Zale y ona od takich czynni-jak czas trwania etapu i postrzegane ryzyko. Zwykle Raport mo e by kw, przesyany co dwa tygodnie lub co miesic. Mo e mie charakter formalny lub nieformalny, w za- noci od decyzji Komitetu le Sterujcego. Komitet Sterujcy powinien zdefiniowa zawarto Raportu Okresowego. W wersji minimalnej powinien zawiera owiadczenie na temat: dokona w raportowanym okresie; dokona oczekiwanych w nastpnym okresie; Zagadnie Projektowych i zagro e oraz sugestii dotyczcych ich rozwizania. 26 6

PRINCE2

ELEMENTY STEROWANIA

Komitet Sterujcy mo e wystpi o udostpnienie kopii Planu Etapu (lub jego czci), ukazujcej w okrelonym momencie czasu rzeczywisty stan prac, okrelony w katego-dziaa i kosztw, oraz poprosi o raporty dotyczce wszelkich innych riach elementw uwa a za wa ne. Jakakolwiek byaby ich zawarto, styl powinien by etapu, ktre zwizy. Zamiast kopii Planu Etapu Komitet Sterujcy mo e preferowa otrzymywanie zaktualizowanej kopii Listy Kontr olnej Produktw, ukazujcej status i wszystkie uaktualnione daty. Zwykle czstotliwo sporzdzania Raportu Okr esowego jest okrelana dla caego projektu w Dokumencie Inicjujcym ale czstotliwo ta mo e by r na dla r Projekt, nych etapw. Na przykad Etap inicjowania - jest zwykle bardzo krtki i Komitet Sterujcy wymaga wwczas adnego Raportu Okresowego, natomiast oczekiwa mo e nie wik- czstotliwoci szej w trakcie etapw pniejszych. Przeznaczeniem Raportu Okresowego jest umo liwienie Komitetowi Sterujcemu zarzdzania pomidzy ocenami kocowymi etapw. Komitet Sterujcy odchyleniami wiadom Planu Etapu, jest ktry si zaanga owa oraz w ktr e uzgodni z tolerancji, Kierownikiem Raporty Okresowe potwierdzaj, e postpy zostay poczynione Projektu.tych tolerancji. Za pomoc tego raportu mo na przekazywa Komitetowi w ramach Steruj- wczesne ostrze enia o wszelkich ewentualnych problemach. Komitet cemu Sterujcy mo e reagowa na wszelkie raportowane problemy w sposb formalny lub nieformalny, od wasnej oceny. w zale noci Komitet Sterujcy mo e wymaga, by kopie Raportu Okresowego byy wysyane do innych zainteresowanych stron. Powinno to by udokumentowane w Planie Komunikacji. Nie wymaga si od Kierownika Projektu oficjalnego przedstawienia Raportu Okresowego na posiedzeniu, ale osoby sprawujce obowizki Nadzoru Projektu mog yczy sobie wgldu w jego tre przed przedo eniem go Komitetowi Sterujcemu. Sugerowan tre Raportu Okresowego zawiera Dodatek A Zarysy Opisw Produktw Wskazwki i rady
Kierownik Projektu mo e u y Raportu Okresowego do przekazania zaniepokojenia sprawami, ktre podlegaj kontroli ktrego z czonkw Komitetu Sterujcego. Poniewa raport jest dostarczany wszystkim czonkom Komitetu Sterujcego. Ten z nich, ktrego dziaania s rdem zaniepokojenia, bdzie czu presj ze strony pozostaych, aby doprowadzi sprawy do waciwego stanu. Gwny U ytkownik ponosi cz odpowiedzialnoci za monitorowanie produktw dostarczanych przez projekt. Mo e to by trudne do przeprowadzenia tam, gdzie oddalony dostawca lub strona trzecia wytwarza lub zakupuje produkt. W monitorowaniu mog pomc Raporty z Punktw Kontrolnych i Raporty Okresowe oraz zaanga owanie u ytkownikw w sprawdzanie jakoci takich produktw. \r "rap_okr1" \r "rap_okr1"

267

CONTROLS

PRINCE2

Raport o Istotnych Odchyleniach Raport o Istotnych Odchyleniach jest - pyncym z jednego poziomu zarzdczego na szy - sygnaem ostrzegawczym o wystpieniu powa nych problemw, wy wymagajcych podjcia decyzji i wskazujcym, Plan Zespou, Etapu lub Projektu mo e wyj e poza ustalone dla niego tolerancje. Mdrym zabezpieczeniem ze strony Kierownika Pro- bdzie udokumentowanie dostarczenia takiego jektu raportu. Istniej sytuacje, w ktrych zagro ona jest tolerancja dla caego projektu, a nie tylko eta- Na przykad, mo e si pojawi informacja, e powa ny wydatek na spr zt, ktry pu. trzeba bdzie ponie du o pniej w ramach projektu, mo e znacznie przekroczy bie ce oszacowania i spowoduje wyjcie projektu poza tolerancje. Raport o Istotnych Odchyleniach opisuje przewidywane odchylenie, przedstawia analiz odchylenia, jak i opcji dotyczcych dalszego postpowania oraz wskazuje zarwno zale- opcj. Sugerowana zawarto Raportu o Istotnych Odchyleniach znajduje can siDodatku A Zarysy w Opisw Komitet Sterujcy rozpatruje wspomn Produktw. Podejmowanie ianyDecyzji Raport jako cz podprocesu nyc (ZS4) . Dora h Jeli Raport o Istotnych Odchyleniach dotyczy przewidywanego przekroczenia tolerancji Przewodniczcy musi natychmiast przekaza t informacj kierownictwu projektu, firmy lub programu. Jeli Raport o Istotnych Odchyleniach jest przygotowywany przez Kierownika Zespou, by przekazany Kierownikowi Projektu jako Zagadnienie Projektowe powinien oraz poddany przegldowi w ramach Analizowanie Projektowyc podprocesu Zagadnie h (SE4). Jeli projekt jest czci programu, sytuacje prowadzce do istotnych odchyle mog wystpi z powodu zmian lub problemw na poziomie progr amu. Przykadami mog by zmiana biznesowa lub spnione dostarczenie nabywanego na zewntrz produktu, ktry wpywa na cay program lub tylko na pojedynczy projekt. Zmiany mo e terminw lub specyfikacji produktw, ktre maj by dostarczone przez projekt, ukoczenia mog czasami zapocztkowa w progr amie efekt domina. Aby unikn mno enia nakadw i zaoszczdzi czas, sytuacje nadzwyczajne, mogce oddziaywa na wicej ni jeden w ramach programu, powinny by koordynowane na poziomie projekt programu.

16.4.10.

16.4.11.

Ocena ko

cowa etapu

Czci uzasadnienia dzielenia projektu na etapy jest to, e Komitet Sterujcy anga uje w jednym momencie tylko w jeden etap. Pod koniec ka dego etapu Komitet si Sterujcy si bacznie projektowi, aby zadecydowa, czy yczy sobie przystpienia przyglda do nastpnego etapu. Ten przegld nazywany jest Ocen kocow etapu. W zale noci od takich czynnikw jak wielko projektu, znaczenie i ryzyko, Ocena kocowa etapu mo e y b formalna lub nieformalna. Niezale nie od sposobu jej przeprowadzenia, Ocena kocowa etapu jest obowizkowym punktem kontroli na kocu ka dego etapu. Zatwierdzane s wwczas dotychczas wyko- prace i udzielane jest zezwolenie na przystpienie do nastpnego nane Etap nie etapu. powinien by uwa any za zakoczony, dopki nie otrzyma formalnego zatwierdzenia. Konkretne cele oceny kocowej etapu to: 26 8

PRINCE2

ELEMENTY STEROWANIA

przegld projektu w odniesieniu do jego Uzasadnienia Biznesowego w celu stwier- czy projekt jest nadal opacalny / dzenia, zasadny; przegld rezultatw etapu w porwnaniu z Planem Etapu; przekonanie Komitetu Sterujcego co do jakoci dostarczonych produktw; ustalenie, e bie cy etap zosta zakoczony w sposb zadowalajcy; sprawdzenie, czy jakie zdar zenie zewntrzne nie zmienio dotychczasowych zaoe poczynionych w projekcie; przeprowadzenie analizy zagro e, przegldu zarzdczego projektu oraz Planu Etapu (nastpnego) i wczenie uzyskanych wynikw do Planu Etapu (nastpnego) i Planu Projektu ; dokonanie przegldu oglnego stanu projektu w odniesieniu do Planu Projektu (kt- teraz ry mg zosta skorygowany); dokonanie przegldu Planu Etapu (nastpnego) w odniesieniu do Planu Projektu; zapewnienie, by zosta ustalony kompletny i spjny stan odniesienia dla nastpnego etapu;

przeprowadzenie przegldu zbioru tolerancji dla nastpnego etapu; zapewnienie, e aspekty specjalistyczne projektu s nadal suszne; zezwolenie na przejcie projektu do nastpnego etapu (jeli Uzasadnienie Biznesowe pozostaje nadal zasadne). Komitet Sterujcy ma prawo odmwi zatwierdzenia Planu Etapu (nastpnego), jeli jest niezadowolony z ktregokolwiek aspektu wymienionego na powy szej Mo e zalicie. od da Kierownika Projektu powtrnego przemylenia Planu Etapu albo (nastpnego) zamknicie projektu bd, jeli rozwizanie problemu przekracza spowodowa jego uprawnienia, przedo y problem kierownictwu firmy lub programu.

16.4.12.

Raport Ko cowy Etapu

Raport Kocowy Etapu jest dokumentem, za po moc ktrego Kierownik Projektu damia Komitet Sterujcy powiao rezultatach etapu. Komitet Sterujcy mo e porwna rezultaty w obszarach produktw, kosztw i terminw z zatwierdzonym Planem Etapu. Raport Kocowy Etapu zawiera wszelkie informacje niezbdne Komitetowi Sterujcemu celw wyznaczonych dla oceny kocowej etapu. Stanowi zapis, ktry mo do realizacji e odlega audytowi w ka dym momencie trwania projektu. Zawiera on p podsumowanie zdarzyo w czasie trwania etapu, stan realizacji Planu Projektu, tego, co si Uzasadnienia i zagro e. Biznesowego

16.4.13.

Ocena nadzwyczajna

Ocena nadzwyczajna dokonywana jest z udziaem Komitetu Sterujcego i Kierownika celu zatwierdzenia Planu Nadzwyczajnego. Jeli jakie obowizki Projektu w nadzoru Sterujcego zostay delegowane, osoby, ktrym d elegowano te obowizki, Komitetu powinny tak e bra w niej udzia. Celem Oceny nadzwyczajnej jest przedstawienie przez Kierownika Komitetowi Sterujcemu Planu Nadzwyczajnego Projektu obejmujcego zmodyfikowany Plan Etapu lub Plan Projektu uzyskanie zezwolenia na jego i realiza269

CONTROLS

PRINCE2

cj. Podobnie jak w przypadku oceny kocowej etapu, ocena nadzwyczajna mo e by formalna bd nieformalna, w zale noci od wielkoci, znaczenia i ryzyka projektu. Struktura Planu Nadzwyczajnego przestawiona zostaa w Dodatku Zarysy A Opisw Produkt . w Ka dy Plan Nadzwyczajny przedstawiony Komitetowi Sterujcemu wywiera wpyw 28 na Uzasadnienie Biznesowe i ryzyko. opcja bdzie rwnie oddziaywa na Zalecana te same elementy. Komitet Sterujcy musi rozwa y obie grupy oddziaywa.

16.4.14.

Dziennik

Dziennik mo e pomc Kierownikowi Projektu w sterowaniu projektem. Jest to zwykle ktrego strony zawieraj punkty wymienione w Dodatku notes, Zarysy Opisw A Produkt . w Zawarto ta mo e by przystosowana przez Kierownika Projektu do wasnych potrzeb lub preferencji. Zapisy mog by wprowadzane w ka dym momencie. Jednym z kluczowych momentw mo e by przegld stanu etapu dokonywany przez Kierownika Projektu. Innym sposobem nabrania nawyku regularnego wprowadzania zapisw mo e by wykonywanie tej czynnoci zawsze na kocu lub na pocztku ka dego tygodnia. Sporzdza- z doku mentw etapu mo e prowadzi do zapisw w Dzienniku. Typowy nie ka dego mi zapisami mog by: sprawdzenie wraz z wacicielem ryzyka aktualnego stanu ryzyka; odnotowanie dziaa znajdujcych si na cie ce krytycznej i sprawdzenie wraz z wykonawc stanu realizowanych prac; odnotowanie produktw, ktre powinny by ukoczone w cigu nastpnych kilku i sprawdzenie ich dni statusu; przegld Rejestru Jakoci pod ktem wszelkich kontroli, ktre s opnione; wynotowanie wszelkich Zagadnie Projektowych, dla ktrych nie przeprowadzono jeszcze analizy oddziaywania; zanotowanie sposobu postpowania z wszelkimi pozostajcymi do zaatwienia punk- ostatniego Raportu Okresowego, ktre powinny spowodowa podjcie tami dziaania przez jednego lub kilku czonkw Komitetu Sterujcego; zapisanie czynnoci, ktre mo na bdzie podj w zwizku z opniajcymi si dziaaniami, zanim zmiana planu bdzie nieunikniona; sprawdzenie statusu tolerancji. Inne zapisy mog wynika z dyskusji z Kierownikami Zespow, czonkami zespow lub czonkami Komitetu Sterujcego, mog tak e dotyczy odbytych rozmw telefonicz- w Planie Komunikacji, skorygowanych Grup Zada nych, zmian itp. Jest rozsdne, gdy Kierownik Projektu ma zawsze pod rk Dziennik. Poleganie wycz- pamici to recepta na nie na katastrof.

28

W Raporcie o Istotnych Odchyleniach przypis tumacza.

27 0

PRINCE2

ELEMENTY STEROWANIA Rejestr Do wiadcze

16.4.15.

Rejestr Dowiadcze zostaje zao ony w Ustanowienie Systemu podprocesie Powinien zawiera zapisy wszelkich dowiadcze - dobrych i zych - ktre Dokumentacj (IP5) . i brano w zeczasie realizacji projektu. Propozycja struktury rejestru przedstawiona zostaa w Dodatku A Zarysy Opisw . Zapisy powinny dotyczy spraw zarwno zarzdczych, jak iProduktw specjalistycznych. Jego cele to: dostarczenie dowiadcze i informacji, ktre mogyby by u yte w przyszoci do udoskonalenia planowania i wydajnoci: w kolejnych etapach projektu; w przyszych projektach; poprawienie oglnych standardw korporacyjnych.

16.5.

Kontrolowane zamykanie

Zanim Komitet wyda zezwolenie na zamknicie projektu (chyba, e Sterujcy projekt zosta przedwczenie zakoczony), skontroluje go, aby upewni si, e: wszystkie uzgodnione produkty zostay dostarczone i zaakceptowane; wprowadzono rozwizania tam, gdzie byo to wskazane, umo liwiajce serwis i utrzymanie produktu w okresie jego eksploatacji; wszelkie u yteczne dane statystyczne lub dowiadczenia dla pniejszych projektw przekazane zostay odpowiednim gremiom; przygotowano plan umo liwiajcy sprawdzenie osignicia korzyci spodziewanych Biznesowym. w Uzasadnieniu By zamkn projekt, Komitet Sterujcy musi potwierdzi na pimie (w ramach dokumentacji zarzdczej projektu) swoj akceptacj, e projekt zosta zakoczony. Jeli to konieczne, owiadczenie mo e by warunkowe, stwierdzajce, e np. produkty zostay dostarczone z niewielkimi usterkami, ktre bd mogy by usunite pniej. Podczas zamykania projektu, powstaj poni ej opisane informacje, ktre prowadz do dziaa sterujcych Komitetu Sterujcego. Powiadomienie o zamykaniu projektu Powiadomienie o zamykaniu projektu uprzedza wszystkich, ktrzy dostarczyli zasobw, usug, e projekt zbli a si ku kocowi. Oficjalnie Kierownik Projektu sprztu lub przed- Komitetowi Sterujcemu zalecenie zamknicia kada Jeli Komitet projektu.si z nim, wydaje powiadomienie o zamykaniu projektu. W Sterujcy mo na zgadza praktyce si porozumie, e bdzie to jeden i ten sam dokument.

16.5.1.

16.5.2.

Raport o Do

wiadczeniach

Raport o Dowiadczeniach powstaje na podstawie Rejestru Dowiadcze, aby rozpowszechnia na u ytek innych projektw, po yteczne dowiadczenia nabyte w trakcie projektu.

271

CONTROLS

PRINCE2

Obejmuje on procesy zarzdcze i specjalistyczne, techniki i narzdzia, uwagi co dziaao a co sprawiao kopoty. Jest u ytecznym elementem ster owania, dobrze, wykorzystywanym jako cz funkcji niezale nego nadzoru jakoci lub podobnej grupy. Proponowana struktura dokumentu jest umieszczona w Dodatku Zarysy Opisw . A Produktw Uwaga: Jeli wa ne dowiadczenia zidentyfikowano we wczeniejszych fazach cyklu y- projektu, a mogyby by one u yteczne dla innych, nie ma przeciwwskaza, aby cia Kierownik Projektu przygotowa poredni Rapor t o ktry byby Dowiadczeniach, zatwier- dzony i rozprowadzony w ramach Podejmowanie Decyzji nyc (ZS4). podprocesu Dora h

16.5.3.

Zalecenia Dziaa

Nast pczych Na

W chwili zamknicia projektu, mo e si okaza, e szeregu czynnoci nie wykonano.mo e by pewna liczba Wnioskw o Wprowadzenie Zmiany, ktre Ko przykad mitet Sterujcy zaakceptowa, ale postanowi nie wdra a ich w czasie trwania projektu; nie wszystkie spodziewane produkty mogy zosta przekazane lub te jest szereg znanych problemw z tym, co dostarczono. Mo e by zidentyfikowane zagro enie, ktre pr awdopodobnie zmaterializuje si dopiero po zakoczeniu projektu, np. ryzyko zwizane z eksploatacj produktu. Zalecenia Dziaa Nastpczych dokumentuj wszelkie sprawy niezakoczone i umo liwiaj Komitetowi Sterujcemu skierowanie ich do osoby lub gremium, ktrych zadaniem jest rozpatrzenie ich pod ktem podjcia niezbdnych dziaa po zakoczeniu projektu.

16.5.4.

Raport Ko cowy Projektu

Raport Kocowy Projektu jest podobny Raportu Kocowego Etapu, tylko do projekt. Sugerowana jego zawarto umieszczona jest w Dodatku obejmuje cay Zarysy A Opisw Produkt . w Raport Kocowy Projektu pokazuje, w jakiej mier ze projekt osign cele przedstawione w Dokumencie Inicjujcym Pr O ile Raport o Dowiadczeniach koncentruje si ojekt. na dobrych i zych elementach standardw zarzdzania i prowadzenia projektu, o tyle ten raport skupia si na dokonaniach zespou zarzdzania projektem w zakresie dostarczania o dobrej jakoci, ktre speniy wymagania bud etu oraz terminowej produktw realizacji. W miar mo liwoci nale y dokona przegldu osigniia korzyci, przewidzianych Biznesowym (wikszo z tych pomiarw bdzie musiaa poczeka w Uzasadnieniu a o przegldu poprojektowego). d Wszelkie zmiany dokonane po zatwierdzeniu Dokumentu Projekt s identyfikowane i ocenia si ich wpyw na Plan Inicjujcego UzasadProjektu, Biznesowe nienie i ryzyko. Raport dostarcza danych liczbowych o Zagadnieniach Projektowych oraz ich oddziay- projekt, a ponadto danych liczbowych dotyczcych jakoci prowadzonych waniu na prac. Jeli projekt jest czci programu, program bdzie wymaga przekazania do niego kopii Raportu Kocowego Projektu. Kierownictwo pr ogramu mo e przekaza szczegy dodatkowych wymaga dotyczcych danych liczbowych oraz informacji, ktrych oczekuje od takiego raportu. Powinno to zosta uwzgldnione w Planie Komunikacji.

27 2

PRINCE2

ELEMENTY STEROWANIA

Po zatwierdzeniu Raportu Kocowego Projektu przez Komitet Sterujcy, mo e on rozpowszechni kopie raportu wrd zainter esowanych, zgodnie z Planem Komunikacji.

16.5.5.

Plan Przegl

du Poprojektowego

Przegld poprojektowy odbywa si poza projektem, tj. po jego zamkniciu. Jego gw- celem jest przegld korzyci biznesowych, osignitych w wyniku nym zastosowania produktw projektu. Wikszo produktw wymaga pewnego okresu u ytkowania, zanim oczekiwane korzyci biznesowe mog by zmierzone. Taki pomiar po pewnym okresie u ytkowania jest czynnoci zwan przegldem popr ojektowym. Podczas zamykania projektu przyjmuje kiedy i jak bdzie zmierzone osignicie korzyci si plan, biznesowych. Wszelkie prace korygujce, zidentyfikowane w przegldzie poprojektowym, zostan wykonane podczas u ytkowania produktu oraz w czasie jego utrzymywania. Przyczyna niektrych problemw mo e le e nie po stronie produktw, ale mo e wynika z organizacji i wymaga takich rozwiza zaradczych, jak powtrne szkolenie. Jeli projekt jest czci programu, mo e po prostu przyczynia si do realizacji korzyci biznesowych na poziomie programu. Sugerowana zawarto Planu Przegldu Poprojektowego przedstawiona jest w Dodatku A Zarysy Opisw . Produktw Komitet Sterujcy powinien zapewni istnienie Planu Przegldu Poprojektowego, a Przewodniczcy jest zobowizany do zagwarantowania, realizacji tego przegldu

16.6.

Etapy

Etapy s czciami projektu oddzielonymi od siebie zarzdczymi punktami decyzyjnymi. Etap jest zbiorem czynnoci i produktw, ktrych dostarczanie jest zarzdzane jako cao. Jako taki, jest on podzbiorem projektu i w kategoriach PRINCE2 jest to cz prac, zarzdza Kierownik Projektu z upowa nienia Komitetu Sterujcego. ktr Zastosowanie etapw w projekcie zarzdzanym wedug PRINCE2 jest obowizkowe; liczba etapw jest zmienna i zale y od potrzeb projektu. Etapy PRINCE2 s czsto okrelane jako etapy zarzdcze w celu odr nienia ich od innego zastosowania terminw etapy lub fazy w niektrych szczeglnych rodowiskach projektowych. Etapy PRINCE2 nastpuje. obejmuj, co

Przegl dy i punkty decyzyjne W ka dym projekcie wystpi kluczowe decyzje, ktrych rezultaty bd wywiera istotny wpyw na strategiczny kierunek i szczegow zawarto projektu. Std, z punktu widzenia Komitetu istnieje potrzeba regularnych przegldw Sterujcego, kierunku i dalszej zasadnoci projektu.

273

CONTROLS

PRINCE2

PRINCE2 wykorzystuje etapy, by wprowadzi te punkty decyzyjne. Decyzje stanowi ocen kocowych etapu, wykonywanych w ramach podprocesu podstaw Zezwolenie na Realizac Planu lub Planu (ZS3). Korzyci, ktre oceny koj Etapu cowe etapu przynosz Nadzwyczajnego s projektowi, nastpujce: dostarczanie projektowi ochrony przeciwpo arowej poprzez zachcenie Komitetu Sterujcego do oceny zasadnoci projektu w ustalonych odstpach czasu, zamiast zezwolenia na to, by przebiega on w sposb niekontrolowany; zapewnienie, by kluczowe decyzje podejmowane byy przed szczegowymi pracami niezbdnymi do ich wdro enia; natura tych decyzji mo e by r noraka i bdzie obejmowa: to, czy anga owa powa ne zasoby, takie jak kapita inwestycyjny; to, jakie jest oddziaywanie gwnych zagro e; wyjanienie uprzednio nieznanych lub le zrozumianych fragmentw ukierunkowania projektu lub produktw; wyjanienie, jakie bdzie oddziaywanie zidentyfikowanego czynnika zewntr znego, jak okres bud etowy firmy lub finalizacja procesu takiego legislacji; przegld ryzykownego projektu w jego kluczowych momentach, gdy pojawiaj si nowe informacje o zagro eniach. Wiele osb syszao o terminach przegld partnerski i przegld kontynuacyjny w pracach projektowych i stawia sobie pytanie, jak maj si one do elementw sterowania PRINCE2. Przegldy partnerskie s specjalnymi przegldami projektu lub ktrego z jego produk- personel z wewntrz firmy i/lub z innych organizacji przeprowadza niezale tw, gdzie n ocen projektu. Celem przegldw partnerskich jest wprowadzenie wie ego spojrzenia i zachcenie do wymiany dowiadcze pomidzy projektami. Przegldy do projektu partnerskie mog by przeprowadzane w ka dym momencie projektu, ale s czsto stosowane w punktach kocowych etapw. Przegld kontynuacyjny jest pojciem czsto u ywanym w zarzdzaniu pr ojektami. Prze- kontynuacyjne s w rzeczywistoci formalnymi ocenami kocowymi etapu, do gldy kt- zaprasza si rych zewntrznych kontrolerw, majcych oceni projekt i zarekomendowa Komitetowi Sterujcemu jego kontynuacj lub przerwanie. Horyzonty planowania Niepewno mo e czsto powodowa, e szczegowe zaplanowanie czynnoci i produktw jest mo liwe tylko dla pewnej ograniczonej czci prac projektu. Reszta prac mo e y zaplanowana jedynie w du ym przybli eniu. Zastosowanie etapw umo liwia b obsu- sytuacji poprzez wprowadzenie dwch r nych, ale powizanych poziomw g tej planu, ktrymi s Plan Etapu i Plan Projektu. Skalowalno

Ka dy projekt prowadzony wedug PRINCE2 powinien zawiera co najmniej dwa etapy. inicjowania jest obowizkowy. Mo e trwa zaledwie kilka godzin, ale istotne Etap jest, upewni si, e istniej solidne podstawy dla realizacji projektu, rozumiane by przez 27 4

PRINCE2

ELEMENTY STEROWANIA

wszystkie zainteresowane strony. May projekt mo e potrzebowa tylko dwch etapw: inicjowania oraz reszty projektu jako etapu Etapu drugiego. Wikszo projektw wymaga rozbicia na dogodniejsze do zarzdzania etapy, by umo -iwi prawidowy poziom planowania i l kontroli.

16.6.1.

Etapy zarz dcze a etapy techniczne

Jedn z metod grupowania prac w etapy jest grupowanie wedug zestaww stosowanych wytwarzanych produktw. W ten sposb powstaj etapy obejmujce technik lub elemen- jak projektowanie, konstruowanie i wdra anie. S to ty takie techniczn - pojcie etapy od wczeniej wprowadzonych etapw e odrbne zar dczyc . z h Etapy techniczne charakteryzuje wykorzystanie okrelonych zestaww specjalistycznych umiejtnoci Etapy zarzdcze odpowiadaj zaanga owaniu zasobw i zezwoleniu na . ycie. Czsto ich rodzaje etapw bd si pokryway; np. tam, gdzie decyzja u oba zarzdcza na wyniku etapu technicznego. Przykadem tego mo e by sytuacja, w jest oparta ktrej wynikiem etapu technicznego jest zestaw wariantw konstrukcji. Jednak e w innych sytuacjach etapy nie bd si pokr yway. Na jeden etap zarzdczy mo e przypada wicej ni jeden etap techniczny. Na przykad, Komitet Sterujcy mo edecydowa o poczeniu w jeden etap zarzdczy wszystkich etapw z technicznych, badana jest potrzeba produktw i tworzona jest specyfikacja. w ktrych Zatwierdzany jeden plan etapu, obejmujcy wszystkie te dziaania i anga ujcy byby wtedy Komitet Sterujcy przed rozpoczciem prac i podczas przegldu kocowego. Dla ryzykownego projektu - np. takiego, ktry jest (technicznie) - jeden dugi etap techniczn innowacyjny y mo e zosta podzielony na kilka etapw zarzdczych. Podejcie PRINCE2 polega na skoncentrowaniu zarzdzania projektem na za etapach , gdy r dczyc to one stanowi podstaw planowania i procesw sterowania z h metodyk. Podejcie przeciwne nara a na ryzyko, e projekt bdzie opisanych przez kierowany przez zespoy specjalistw zamiast przez kier ownictwo klienta. W przypadkach, gdy etapy zarzdcze nie bd si pokryway z etapami technicznymi, prace specjalistyczne powinny zosta rozo one, tak by ich produkty mogy zosta podzielone midzy dwa lub wicej etapy zarzdcze. Rysunek 16.5 i 16.6. pokazuj przykady takiego podziau. Rysunek 16.5 pokazuje cztery etapy zarzdcze z dwoma produktami, ktrych wytwarzanie rozciga si na wicej ni jeden etap zarzdczy.

275

CONTROLS

PRINCE2

Etap 1 Etap 2 Etap 3 Etap 4

S pe c yf i k ac j a Pr oj e k tow a ni e

Wy tw a rz a ni e

Sz k ol e ni e

Pr ze k a za ni e d o e k sp l oa ta c j i

Rysunek 16.5. etapw zarzdczych

Etapy techniczne wykraczajce poza granice

Etap 1 Etap 2 Etap 3 Etap 4 Etap 1 Etap 2 Etap 3 Etap 4

Specyfikacja Specyfikacja Projekt urzadze Projekt Projekt urzadze trznych zewn Projekt konstrukcyjny oglny trznych zewn konstrukcyjny oglny Wytwarzanie Wytwarzanie

Przeszkolony Program Przeszkolony Program personel szkole personel szkole

Przekazanie Przekazanie do eksploatacji do eksploatacji

Rysunek 16.6. etapy

Produkty podzielone na mniejsze, by wpasoway si w zarzdcze

Rysunek 16.6 pokazuje, e projektowanie zostao podzielony na trzy produkty. Projekt przypada teraz na pierwszy etap zarzdczy, projekt szczegowy or az oglny przygotowanie programu szkole stanowi drugi etap zarzdczy, podczas gdy wykonanie projektu zewntrznych zaplanowano w trzecim etapie zarzdczym, wraz z urzdze przygotowa- przeszkolonego niem personelu.

16.6.2.

Jak wyznacza

etapy?

Proces definiowania etapw jest zasadniczo procesem rwnowa enia: 27 6

PRINCE2

ELEMENTY STEROWANIA

jak daleko w przyszo projektu sensownie jest planowa; gdzie w projekcie niezbdne s kluczowe punkty decyzyjne; wielkoci ryzyka zwizanego z projektem; wielu krtkich etapw albo maej liczby etapw dugich. Bdzie to rwnowa enie czynnikw zidentyfikowanych wy ej, z uwzgldnieniem wpywu Planw Zespow. Jednak e Kierownik Projektu bdzie musia pogodzi Plan Etapu ze wszystkimi Planami Jest to omwione w Rozdziale Plan . Zespow. 15 y

16.6.3.

Jak wykorzystywa

etapy?

Podstawowym wykorzystaniem etapw zarzdczych jest ustalenie terminw realizacji podprocesw Zar dzania Zakresem (ZE) oraz powizanego podprocesu Zezwo z Planu Etapu lenie na lub Planu (ZS3). S one wykorzystyRealizacj podejmowania decyzji czy Nadzwyczajnego Etapu wane do kontynuowa projekt, czy nie. Jednym z elementw tego procesu decyzyjnego jest stwierdzenie, czy etap, ktry wanie koca, zakoczy si sukcesem. Mo e to by problematyczne tam, gdzie etap dobieg zarzdczy koczy si w trakcie jednego lub wikszej liczby etapw specjalistycznych, gdy e by trudne ustalenie, czy prace specjalistyczne znajduj si pod kontrol. mo Zalecana przez PRINCE2 technika Planowania opartego na (patrz: Rozdzia jest produktach tutaj nieoceniona, gdy stosujc j, Kierownik Projektu mo e 22) zidentyfikowa szczegowe produkty zwizane z ka dym etapem specjalistycznym, a przez to zidentyfikowa wszystkie produkty, ktre powinny zosta wytworzone w ramach danego etapu zarzdczego. Mo e to by wykorzystane do oceny, czy zakoczono ju etap zarzdczy. Etapy mog by bardzo u yteczne jako sposb na umo liwienie Komitetowi Sterujcemu kontroli ryzykownych Podziay na etapy mog by wstawione wwczas projektw. w tych kluczowych punktach, w ktrych mo na dokona przegldu zagro e, zanim doj- do zaanga owania wikszych sum pienidzy lub dzie Prace te zasobw. Planowanie ukierunkowuje podproces (IP2). Projektu

277

17.

ZA RZ DZA NI E RY ZY KI E M
MANAGEMENT OF RISK

Sterowanie zmianami
dz ani Z arz e St rat eg icz ne P roj ekt em dz ani S4 Z arz e St rat eg icz ne P roj ekt em Z

Uzasadnienie biznesowe

Z S4 Z S1 ZS 2 Z S3 Z S5 Z S1 ZS 2 Z S3 Z S5
d zan Zarz ie d zan Zarz ieem Zakres Zakres em Et ap u Et ap u Zam ow ani S erow to wan Inrz ygo ani e P t icjykan iee ie Zam ekt to S ro ykan wan Inrz ygotu ie e P t icjjekt ani e ie erow Prtap em u E roj ow ani ojek Prtap em E roj ekt P ro jekt u ojek tu dz an Zarz ie dz an ie Zarz w arz ani em Wyt P lan owan ie Wyt w kt ani P rodu arzw em lan owan ie P rodu kt w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu

Plany

Elementy sterowania

Rysunek 17.1. strukturalnym

Komponent Zarzdzanie ryzykiem w modelu PRINCE2

17.1.

Czym jest zarz

dzanie ryzykiem?

Ryzyko jest gwny m czynnikiem, ktry musi by wzity pod uwag w czasie zarzdzania dowolnym projektem. Zarzdzanie projektami musi kontrolowa i ogranicza zagro- jeli projekt ma mie szans enia, powodzenia. Ryzyko mo e by zdefiniowane jako niepewno uzyskania zaplanowanego wyniku (w kontekcie pozytywnym traktowana jako szansa, lub negatywnym widziana jako enie). Podejmowanie ryzyka na pewnym poziomie jest nieuniknione, jeli zagro projekt ma osign swoje cele. Zadaniem zarzdzania ryzykiem jest radzenie sobie z sytuacj nara enia projektu na ry- (tzn. prawdopodobiestwo wystpienia okrelonych zagro e oraz gdy si one zyko urzeczywistni, ich potencjalnych skutkw). Celem jest panowanie nad stopniem tego nara- przez podejmowanie dziaa utrzymujcych ryzyko na akceptowalnym enia wpoziomie sposb efektywny kosztowo.

27 9

MANAGEMENT OF RISK

PRINCE2

Zarzdzanie ryzykiem wymaga: dostpu do wiarygodnych, aktualnych informacji o zagro eniach; procesw podejmowania decyzji, wspieranych ujt w ramy analiz i ocen ryzyka; wdro onych procesw monitorowania zagro e; waciwego wywa enia elementw sterowania, jakie zastosowano, by zarzdzi ryzykiem. (Jest to wyjanione dalej w niniejszym rozdziale - w punkcie Tole 17.2.1 rancja dla ). ryzyka Zarzdzanie ryzykiem na poziomie projektu koncentruje si na utrzymaniu niepo da- wynikw projektu na akceptowalnym minimalnym poziomie. Decyzje nych dotyczce zarzdzania ryzykiem stanowi wa n cz Uzasadnienia Biznesowego. Jeli w projekcie zaanga owani s dostawcy i/lub partnerzy, wa ne jest uzgodnienie wsplnego spoj- na zagro enia i tego, jak bd one rzenia zarzdzane.

17.2.

Zasady traktowania ryzyka

Projekty prowadz do zmiany, a zmianie towarzyszy ryzyko. Zwykle zmiana wprowadza to czsto oznacza u ycie nowych metod lub nowych technologii. Te za postp, a mog jeszcze zwiksza zagro enia. Istniej pewne istotne reguy, ktre w projekcie powinny one, jeli zarzdzanie ryzykiem ma by skuteczne i zachca do innowacji, by wdro ta- jak: kie Komitet Sterujcy wspiera i promuje zarzdzanie ryzykiem, rozumie i akceptuje implikacje dotyczce czasu i zasobw, wynikajce z podejmowania dziaa zaradczych; polityka zarzdzania ryzykiem oraz korzyci ze skutecznego zarzdzania ryzykiem sposb zrozumiay przekazywane caemu s w personelowi; spjne podejcie do zarzdzania ryzykiem jest wbudowane w procesy zarzdzania projektem ; zarzdzanie ryzykiem jest istotnym wkadem w osiganie celw biznesowych; zagro enia wynikajce ze wsppracy z programami i innymi projektami s oceniane i zarzdzane; istnieje jasna struktura dla procesu zarzdzania ryzykiem, ka dy element i poziom identyfikacji ryzyka wpasowuje si w t struktur; jeli projekt jest czci programu, zmiany statusu ktregokolwiek z zagro e dla projektu, ktre rwnoczenie zidentyfikowano jako ryzyko dla programu, musz by sygnalizowane kierownictwu programu albo wyznaczonej osobie zarzdzajcej ryzykiem w programie. Tolerancja dla ryzyka jak

17.2.1.

29 Inn nazw tolerancji dla ryzyka jest apetyt na . Zanim ustali si, ryzyko eniami, Komitet Sterujcy i Kierownik Projektu musz rozwa y poziom postpi z zagro ryzyka,
29

Albo dopuszczalne ryzyko lub poziom akceptacji ryzyka przypis tumacza.

28 0

PRINCE2

ZARZDZANIE RYZYKIEM

jaki s gotowi zaakceptowa. Bdzie si to zmienia w zale noci od wagi przypisywanej zagro eniom. Na przykad, postrzeganie zagro e finansowych oraz poszczeglnym to jakim stopniu zesp projektowy jest gotw podj zwizane z nimi ryzyko, zale w e bdzie od wielu czynnikw, takich jak bud ety, wpyw na pozostae czci programu lub firmy, bd od dodatkowych zagro e, np. zawirowa politycznych. Zesp projektowy gotw na zaakceptowanie stosunkowo du ego ryzyka w pewnych obszarach, mo e by a drzucenie go w innych, np. zagro enie dla ycia i zdrowia. Tolerancja dla ryzyka mo o e iza si z par ametrami innych tolerancji, np. zagro enie dla terminowej realizacji w i/lub ustalonych kosztw, z zagro eniem dla osignicia wymaganej jakoci i zrealizowania zaplanowanego zakresu projektu, z jednoczesnym zachowaniem wymogw Uzasadnienia Biznesowego. Postrzeganie tolerancji dla ryzyka powinno by szczegowo rozpatrywane w celu usta- optymalnej rwnowagi midzy wystpujcym zagro eniem a kosztami i lenia efektywnoci kosztow jego ogr aniczania. Oglna tolerancja organizacji dla nara enia na ryzyko musi by tak e wzita pod uwag, gdy uwzgldnia si poszczeglne zagro enia.

17.2.2.

Obowi zki wynikaj ce z zarz

dzania ryzykiem

Zarzdzanie ryzykiem jest jedn z najwa niejszych czci pracy, wykonywanej przez Komitet Sterujcy i Kierownika Projektu. Obowizkiem Kierownika Projektu jest zapewni, e zagro enia s identyfikowane, rejestrowane i regularnie przegldane. Komitet Sterujcy posiada cztery obowizki: powiadamianie Kierownika Projektu o ka dym zagro eniu zewntrznym dla projektu; podejmowanie decyzji dotyczcych zalecanych przez Kierownika Projektu reakcji zagro na enia; znalezienie rwnowagi midzy poziomem ryzyka a potencjalnymi korzyciami, kt- projekt re zamierza osign; powiadamianie kierownictwa firmy lub programu o wszelkich zagro eniach, ktre wpywaj na zdolno projektu do zrealizowania celw firmy bd programu. Kierownik Projektu modyfikuje plany, by wczy do nich uzgodnione dziaania su ce unikniciu lub zredukowaniu wpywu zagro e na projekt. Analiza zagro e wymaga wkadu ze strony kierownictwa organizacji. Kierownictwo organizacji z kolei jest informowane przez Komitet Sterujcy o rezultatach analizy zagroe. Niezwykle wa na jest komunikacja midzy szczeblem projektu a szczeblem programu . e eli projekt jest czci programu, procedury zarzdzania ryzykiem stosowane w J projekcie musz by spjne i zgodne z podobnymi procedurami programu, chyba e istniej powody, by tak nie byo. Je eli zagro enie zostao wykryte w programie, wa ne wszelkie ktrych ono dotyczy, powinny by wczone w analiz tego zagro enia. projekty, Podob- ocenie ryzyka projektu powinni uczestniczy przedstawiciele nie, w programu. Ryzyko projektu, ktre zagra a terminowemu osigniciu kamieni milowych (punktw kontrolnych) lub celom programu, musi by przekazane kierownictwu programu.

281

MANAGEMENT OF RISK

PRINCE2

Wa ciciel zagro enia Dla ka dego zagro enia nale y wskaza waciciela, ktrym powinna by osoba najlepiej usytuowana, by je obserwowa. Zwykle Kierownik Projektu bdzie proponowa waci- Komitet Sterujcy podejmie odpowiedni decyzj. Czonkowie Komitetu ciela, a Sterujcego mog zosta wyznaczeni na wacicieli zagro e, a w szczeglnoci zagro e pyncych z zewntrz projektu. Przypisanie wasnoci procesu zarzdzania ryzykiem rozumianym jako cao oraz wasnoci r nych jego skadnikw ma od samego pocztku pier wszorzdne znaczenie. Przy ustalaniu, kto jest wacicielem r nych elementw pro- zarzdzania ryzykiem, wa na jest identyfikacja odpowiedzialnoci cesu za: og spr aw dotyczcych ryzyka; ustanawianie polityki wobec ryzyka oraz gotowo zespou projektowego do podjcia r yzyka; r ne elementy procesu zarzdzania ryzykiem, poczynajc od identyfikacji zagro- a e, do podejmowania reakcji na ryzyko i raportowania; wdro enie faktycznych krokw podejmowanych w ramach reakcji na zagro enia; wspzale ne zagro enia, ktre przekraczaj granice organizacyjne, zwizane z procesami biznesowymi, systemami informatycznymi lub innymi projektami. Ostatecznie obowizki wacicielskie procesu zarzdzania ryzykiem le zwykle po stro- Przewodniczcego. Jednak e Przewodniczcy musi zapewni, aby osoby, ktre nie maj wacicielami r nych czci tego procesu, zostay jednoznacznie okrelone, by ich obowizki byy udokumentowane i uzgodnione, tak eby zrozumieli oni swe r norakie role, obowizki i szczegln odpowiedzialno zwizan z zarzdzaniem ryzykiem. Zwykle waciciel zagro enia bdzie mia obowizek monitorowania ka dego przypisa- zagro enia. Jeli waciciel jest czonkiem Komitetu Sterujcego, faktyczne nego mu za- monitorowania mo e by delegowane, ale odpowiedzialno spoczywa bdzie danie da- na wacicielu. Na przykad, Przewodniczcy ponosi ostateczn odpowiedzialno lej za monitorowanie wszelkich zagr o e albo okazji dotyczcych Uzasadnienia Biznesowego, w szczeglnoci zewntrznych, np. zmian w polityce firmy. Zadaniem Kierownika Pro- jest prowadzenie przegldw wszelkich zagro e i sprawdzanie, czy jektu okrelone cznie z monitorowaniem, s wykonywane i odnosz po dany dziaania, skutek. Informacje o zagro eniach na poziomie zespou wykonawczego powinny by przedsta- Raportach z Punktu Kontrolnego. Kierownik Projektu wcza, w jakiej wiane w postaci, informacje o wa niejszych zagro eniach do Raportu Okresowego. Rwnie Raport Ko- Etapu podsumowuje stan cowy ryzyka. Kiedy zagro enie lub okazja faktycznie si zmaterializuj, Kierownik Projektu albo powoduje wszczcie dziaa przewidzianych w planie rezerwowym, albo ma do czynienia z Zagadnieniem ktr e obsuguje w ramach Sterowania zmianami Projektowym, (patrz Rozdzia 20).

17.2.3.

17.3.

Cykl zarz dzania ryzykiem

Ka dy projekt jest poddawany nieustannym zmianom w swoim otoczeniu biznesowymrodowisku. Podobnie cigle zmienia si ryzyko. Priorytety projektu i i dalszym wzgld28 2

PRINCE2

ZARZDZANIE RYZYKIEM

ne wagi zagro e bd si zmienia i zyskiwa lub traci na znaczeniu. Do zao e dotyczcych ryzyka nale y regularnie powraca i ponownie je rozwa a; powinno to mie co najmniej podczas ka dej oceny kocowej miejsce etapu.
Analiza ryzyka Zarz dzanie ryzykiem

Identyfikowanie zagro e

Ocena zagro e

Monitorowanie i raportowanie

Okrelenie mo liwych reakcji na zagro enie

Planowanie dziaa i przydzia zasobw

Wybr reakcji

Rysunek 17.2. ryzykiem

Cykl

zarzdzania

Rysunek 17.2 pokazuje gwne kroki w caym cyklu zarzdzania ryzykiem. Kroki te opi- szczegowo poni ej. sano

17.3.1.

Analiza zagro e

Identyfikowanie zagro e

W kroku tym identyfikowane s potencjalne zagro enia (lub okazje) dla projektu. W Dodatku C Kategorie wymienione s r ne kategorie ryzyka, ktre ryzyka u yteczny punkt startu dla stanowi identyfikacji. Wa ne jest, by nie ocenia prawdopodobiestwa enia w tym wczesnym okresie. Jest to wykonywane w wystpienia zagro uporzdkowany sposb w pniejszym k roku. Prby formuowania ocen podczas sporzdzania listy potencjalnych zagro e mog prowadzi do pospiesznych i nieprawidowych decyzji o wykluczeniu niektrych z nich.

283

MANAGEMENT OF RISK

PRINCE2

Niezwocznie po zidentyfikowaniu, ka de zagro enie wprowadzane jest do Rejestru Ry- .Zawiera on szczegy dotyczce wszystkich zagro e, ich ocen, waciciela i zyka status. Sugerowana zawarto Rejestru Ryzyka podana jest w Dodatku Zarysy A Opisw Produkt . Rejestr Ryzyka jest dla Kierownika Projektu narzdziem sterowania, umo w liwwiajcym- szybki dostp do wiedzy o gwnych zagro eniach, przed ktrymi stoi pro- oraz do informacji, jakie dziaania monitorujce powinny by prowadzone i jekt, przez Mog by w nim zawar te odnoniki do zapisw w Dzienniku kogo. o sprawdzaniu statusu zagro enia lub zwizanych z nim dziaa. Ocena ryzyka Ocena ryzyka zajmuje si okreleniem prawdopodobiestwa wystpienia i stopnia oddziaywania (wpywu) na projekt poszczeglnych zagro e (okazji), uwzgldniajc wszelkie wzajemne zale noci lub inne czynniki, le ce poza natychmiast narzucajcym si zakresem oceny. Prawdopodobiestwo jest oszacowan mo liwoci faktycznego wystpienia okrelonego zdarzenia (cznie z rozwa eniem czstotliwoci, z jak ten wynik mo e si pokaza). Na przykad, powa ne uszkodzenie budynku jest stosunkowo mao prawdopodobne, ale miaoby kolosalne oddziaywanie na cigo biznesu. Przeciwie- wystpujca od czasu do czasu awaria systemu w komputerze stwem jest osobistym, do prawdopodobna, zwykle nie ma powa nego wpywu na biznes. ktra cho Oddziaywanie jest oszacowanym skutkiem lub rezultatem faktycznego zajcia konkretnego zdarzenia. Dobrze jest rozwa a oddziaywanie pod ktem nastpujcych elementw: czasu; kosztw; jakoci; zakresu; korzyci; ludzi/zasobw. Niektre zagro enia, np. ryzyko finansowe, mog by oszacowane w kategoriach liczbo- Inne, jak czarna reklama, mog by ocenione jedynie subiektywnymi wych. sposobami. Potrzebne s zatem pewne ramy, umo liwiajce kwantyfikowanie zagro e, np. jako wysokie, rednie i niskie. Rozwa ajc prawdopodobiestwo wystpienia zagro enia (okazji), istotnym aspektem jest to, kiedy zagro enie (okazja) mo e si zdarzy. Wystpienie niektrych zagro e e by przewidywane jako bardziej odlege w czasie od innych, wic uwaga mo powinna by skupiona raczej na tych bli szych. To przewidywanie jest nazywane bliskoci za- enia ( proximit ). Taka informacja powinna by wpisana do Rejestru gro . y Ryzyka Rezultaty dziaa oceniajcych zagro enie s dokumentowane w Rejestrze Jeli Ryzyka.jest czci progr amu, zagro enie wystpujce w projekcie powinno by projekt analizo-pod ktem wpywu, jaki mogoby wywrze na program, i wane W razie odwrotnie. jakiejkolwiek interakcji zagro enie powinno by wpisane tak e do tego stwierdzenia drugiego Rejestru Ryzyka. 28 4

PRINCE2

ZARZDZANIE RYZYKIEM

Okre lenie mo liwych reakcji na zagro enie U yteczne reakcje na zagro enie dziel si na pi obszernych kategorii, jak pokazuje to Tabela 17.1.

Tabela 17.1. enie

Zapobieganie (prewencja)

U yteczne reakcje na zagro

Usunicie zagro enia zmiana dotychczasowego trybu postpowania, tam gdzie jest to wykonalne, mo e usun zagro enie. Wprowadza si rodki zaradcze, ktre albo wyeliminuj wystpienie zagro enia, albo wyeliminuj jego wpyw na projekt lub biznes.

Redukowanie Zajcie si zagro eniem podejmujc dziaania, pozwalajce w jaki sposb sterowa zagro eniem, tak aby zmniejszy prawdopodobiestwo jego wystpienia albo ograniczy jego oddziaywanie na projekt do akceptowalnego poziomu. Przeniesienie Jest to specjalna forma redukowania ryzyka, gdy zarzdzanie ryzykiem jest przekazane stronie trzeciej, np. za porednictwem polisy ubezpieczeniowej lub klauzuli kary, tak e skutki zagro enia nie stanowi dalej problemu dla powodzenia projektu. Nie ka de ryzyko mo e by przeniesione w taki sposb. Akceptacja Pogodzenie si z istniejcym zagro eniem prawdopodobnie dlatego, e przy rozsdnych kosztach nic nie mo na zrobi dla zagodzenia go, albo dlatego, e prawdopodobiestwo wystpienia i skutki zagro enia s na akceptowalnym poziomie. Tworzenie rezerw Planuje si i organizuje odpowiednie dziaania, aby je uruchomi, kiedy zagro enie si zmaterializuje.

Dla ka dego zagro enia mo na wybra odpowiednie reakcje, wynikajce z jednej lub ze wszystkich powy szych kategorii. Mog nie istnie opacalne dziaania, ktre wyeliminuj zagro enie, i wtedy musi ono by ono zaakceptowane lub nale y ponownie rozpatrzy projektu (sprawdzi, czy nie jest on zbyt r yzykowny), co w rezultacie mo uzasadnienie e oprowadzi d do jego przerwania. Wybr reakcji Proces reagowania powinien obejmowa identyfikacj i ocen kilku wariantw postpo-z zagro eniami oraz przygotowanie i wdro enie planw zarzdzania wania ryzykiem. by uruchamiane dziaania sterujce byy proporcjonalne do zagro enia. Ka Wa ne jest, - e przeciwdziaanie zagro eniu wi e si z kosztami i musi przynie korzy d odpowiedni do poniesionych kosztw reakcji na zagro enie, ktrego dotyczy.

285

MANAGEMENT OF RISK

PRINCE2

Koszt przeciwdziaania

Prawdopodobie stwo wyst pienia i wpyw zmaterializowanego zagro enia

Rysunek 17.3. przeciwdziaania

Rwnowa

enie

zagro

enia

kosztu

Wybr dziaa podejmowanych w zwizku z zagro eniem wi e si z koniecznoci wywa enia wielu spraw. Dla ka dego mo liwego dziaania jest to, po pierwsze, kwestiaenia kosztw podjcia dziaania odniesionych do prawdopodobiestwa i wywa skutkw wynikajcych z dopuszczenia, e zagro enie si zmaterializuje (patrz Rysunek 17.3). Na przykad, jeli organizowany jest festyn charytatywny, to czy warto wykupi ubezpieczenie za 3000 z, gwarantujce zwrot 6000 z w przypadku gdyby festyn zosta odwoany deszczu, czy te , ze wzgldu na to, e festyn odbywa si w lecie, z powodu podejmiemy nie wydamy pienidzy ryzyko i na ubezpieczenie? Zwykle ten wybr jest bardziej zo ony, ni opisany. Jak pokazuje Rysunek 17.4, istnieje wiele czynnikw, ktre nale y wzi pod uwag.
Mo liwe dziaanie 2

Mo liwe dziaanie 1

Koszt/Czas

Mo liwe dziaanie 3

Koszt/Czas Koszt/Czas

Tolerancja ryzyka

Wybr

Tolerancja ryzyka Oddziaywanie na inne cz ci projektu Oddziaywanie na plany

Oddziaywanie na Uzasadnienie Biznesowe

Oddziaywanie na program lub biznes

Rysunek 17.4. enie 28 6

Wybr reakcji na zagro

PRINCE2

ZARZDZANIE RYZYKIEM

Czsto istnieje kilka mo liwych do podjcia dziaa, bdcych reakcj na zagro enie, de daoby inne efekty. Wybrane mo e by jedno z tych dziaa albo a ka kombinacja wicej. W ka dym przypadku nale y rozwa y oddziaywanie: (a) dwch lub zmateriali- zagro enia oraz ( b) podjtego przeciwdziaania zowanego na: Plan Zespou, Plan Etapu i/lub Plan Projektu; biznes firmy lub program; Uzasadnienie Biznesowe; inne czci projektu. Rozwa ania te powinny by prowadzone z uwzglednieniem tolerancji dla ryzyka.

17.3.2.

Zarz dzanie ryzykiem

Planowanie i przydzielanie zasobw Po dokonaniu wyboru, wprowadzenie w ycie wybranych dziaa bdzie wymagao zaplanowania i przydzielenia zasobw oraz prawdopodobnie wprowadzenia zmian w planie i uruchomienia nowych Grup Zada lub zmodyfikowania dotychczasowych: planowani , ktre w odniesieniu do rodkw zaradczych, wybranych w wyniku e przeprowadzonej oceny ryzyka, obejmuje: okrelanie iloci i rodzaju zasobw, potrzebnych do przepr owadzenia tych przeciwdziaa; przygotowanie szczegowego planu dziaa, ktry bdzie wczony do Planu Projektu i Planu Etapu albo jako dziaania dodatkowe, albo jako plan rezerwowy; potwierdzenie celowoci podjcia dziaa, okrelonych podczas oceny zagro enia, w wietle wszelkich zdobytych informacji dodatkowych; uzyskanie zgody kierownictwa tak e w odniesieniu do wszystkich innych opracowywanych planw; aspektw przydzielenie , ktre okreli i wyznaczy faktyczne zasoby do zasobw prowadzenia prac zwizanych z wykonaniem zaplanowanych wykorzystania, w celu dziaa; przydziay te bd ukazane w Planie Projektu i Planie Etapu; nale y zauwa y, e zasoby potrzebne do dziaa pr ewencyjnych, redukcji i przeniesienia musz by sfinansowane z bud etu projektu, gdy s dziaania- ktrych wykonania kierujcy projektem s mi, do zobowizani; dziaania rezerwowe bd zwykle finansowane z bud etu rezerwowego.

Monitorowanie i raportowanie Powinny istnie mechanizmy monitorowania i raportowania realizacji dziaa, wybra- w zwizku z zagro nych eniami. Niektre z nich mog polega jedynie na monitorowaniu zidentyfikowanego zagro enia ktem oznak zmiany jego statusu. Jednak e monitorowanie mo e obejmowa tak pod e: sprawdzanie, czy realizacja planowanych dziaa daje po dane efekty; 287

MANAGEMENT OF RISK obserwowanie wczesnych sygnaw rozwoju zagro enia; modelowanie tr endw, przewidywanie potencjalnych zagro e lub okazji; sprawdzanie, czy oglne zarzdzanie ryzykiem jest prowadzone efektywnie. Jeli w wyniku monitorowania stwierdzono, e dziaanie nie przynioso oczekiwanegoe tolerancja dla ryzyka mo e zosta przekroczona, nale y sporzdzi skutku lub Raport o Istotnych Odchyleniach.

PRINCE2

17.4.

Profil ryz yka

Jest to prosty mechanizm su cy poprawie wizualizacji zagro e i pomocy kierownictwu w podejmowaniu decyzji. Jest to graficzna reprezentacja informacji zwykle znajduj- si cych w Rejestrze To tylko jeden z mo liwych sposobw przedstawienia Ryzyka. statusu ryzyka projektu. Komitet Sterujcy mo e zdecydowa, e chce wczenia do Raportu Okresowego atwego do zinter pretowania diagramu, np. takiego jak ten, ktry pokazuje Rysunek 17.5. Profil ukazuje zagro enia wykorzystujc identyfikatory zagro e w kategoriach prawdopodobiestwa wystpienia i stopnia oddziaywania, z uwzgldnieniem efektw planowanych przeciwdziaa. Kierownik Projektu mo e aktualizowa t tablic razem z regular- aktualizowanym Rejestrem nie Na przytoczonym przykadzie mo na zauwa Ryzyka. eniu nr 5 okrelono wysokiey, e zagro prawdopodobiestwo wystpienia i du e oddzia- W szczeglnoci, wszelkie zagro enia ukazane powy ej i na prawo od linii ywanie. tolerancji (gruba czarna linia) powinny by przekazane na wy szy szczebel ryzyka Lini t zarzdzania. ustala si dla projektu na podstawie uzgodnie midzy Przewodniczcym a Kierownikiem Projektu. W miar przegldania zagro e, wszelkie zmiany ich oddziaywania lub prawdopodobiestwa, ktre powoduj ich przesunicie powy ej i na prawo od linii toler ancji ryzy- musz by wnikliwie rozpatrywane i powinny by przekazane na wy szy ka, szczebel zarzdzania w celu uzyskania od kierownictwa decyzji o dziaaniach, ktre nale y podj.
Linia tolerancji ryzyka

Wysokie rednie Mae

1, 2 4 3 6, 9 Sabe Umiarkowane

7, 8 Du e
Oddziaywanie

Rysunek 17.5. ryzyka

Sum aryczny profil

28 8

PRINCE2

ZARZDZANIE RYZYKIEM

17.5.

Bud etowanie na potrz eby zarz

dzania ryzykiem

Na zar zdzanie ryzykiem w projekcie nale y przeznaczy odpowiedni bud czas i zaet, soby. Proces zarzdzania ryzykiem musi by wbudowany w rodowisko projektu, a nie wprowadzany po fakcie. Koszty prowadzenia zarzdzania r yzykiem oraz poziom zaanga- i czasu, w postaci planw rezerwowych, unikania ryzyka lub jego redukcji mu owania sz by rozpoznane i uzgodnione. Chocia mo e by przyznany bud et na dziaania doty- reakcji na zaistniae zagro enie, zapomina si czsto o zapewnieniu czce wystarczajce-na wczesne fazy tego procesu, takie jak ocena ryzyka, ktra mo e go bud etu wymaga zr nicowanego zestawu umiejtnoci, narzdzi i technik. Dowiadczenie uczy, e przy- odpowiedniego bud etu dla procesu zarzdzania ryzykiem we wczesnej fazie znanie cyklu ycia zwrci si z nawizk w fazach pniejszych.

17.6.

Odwzorowanie zarz PRINCE2

dzania ryz ykiem na procesy

W kluczowych punktach projektu powinno si prowadzi zarzdzanie ryzykiem - ysunek 17.6. R

17.6.1.

Przygotowanie Zao e

Projektu (PP4)

Do tego momentu powinien ju by zao ony Rejestr Ryzyka. Jego sugerowana struktura jest umieszczona w Dod atku Zarysy Opisw . Zlecenie Przygotowania A Produktw Projektu mo e opisywa szereg zagro e, w obliczu ktrych staje potencjalny Mog projekt. dziaanie konkurencji, niesprzyjajce projektowi lub niejednoznaczne prawo to by: , miany polityki firmy, reorganizacja personelu lub problemy z pynnoci z finansow. Oczywicie przygotowanie Zao e Projektu powinno da asumpt do wczesnego zbadania takich zagro e. Opracowanie Formuy Realizacji Projektu Okr lenie Formu (patrz: e zagro y Realizacji (PP5) ) mo e rwnie wprowadzi kilka dodatkowych Projektu e.

17.6.2.

Zezwolenie na Zainicjowanie Projektu (ZS1)

Jest to pierwszy formalny kamie milowy projektu, kiedy Komitet Ster ujcy, w ramach podejmowania decyzji o zasadnoci zainicjowania projektu, mo e przeanalizowa Rejestr Ryzyka. Od strony praktycznej, Kierownik Projektu powinien nieformalnie przedyskutowa z czonkami komitetu wszelkie znane zagro enia, co do ktrych przypuszcza, e ogyby poda w wtpliwo celowo projektu. m

17.6.3.

Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka (IP3)

Kierownik Projektu bada powtrnie ka de zagro enie jako element przygotowywania Dokumentu Inicjujcego Projekt. W tym czasie powstaje Plan Projektu i mo e z niego wynika szereg zagro e, takich jak nieznajomo wydajnoci zasobw, mo liwoci kontrahenta czy wpyw wszelkich zao e poczynionych w planie. Nowe zagro enia mog rwnie ujawni si w wyniku uszczegowienia Zao e Projektu. W tym samy m czasie wszystkie istniejce zagro enia s przegldane pod ktem nowych informacji lub zmian yotyczcych d ich okolicznoci.

289

MANAGEMENT OF RISK

PRINCE2

Sygna wej

ciow y ze strony kierownictwa firmy lub programu

Zlecenie Przygotowania Projektu Zao enia Projektu

PP4 Przygotowanie Zao e Projektu

PP5 Okre lenie Formuy Realizacji Projektu

ZS1 Zezwolenie na Zainicjowanie Projektu

Formua Realizacji Projektu

Dokument Inicjuj

Plan Projektu cy Projekt

IP3 Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka ZS2 Zezwolenie na Realizacj Projektu

ZE4 Uaktualnienie Rejestru Ryzyka

Plan Etapu

PL6 Analizowanie Ryzyka

ZS4 Podejmowanie Decyzji Dora nych

ZS3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego

SE6 Raportowanie Okresowe

Raport o Istotnych Odchyleniach

SE1 Zgoda na Wykonanie Grupy Zada

Plan Zespou

WP1 Przyjmowanie Grupy Zada do Wykonania

Rejestr Zagadnie Rejestr Ryzyka

SE4 Analizowanie Zagadnie Projektowych

SE8 Przekazywanie Zagadnie Projektowych SE5 Przegl d Stanu Etapu

Rejestr Ryzyka

ZP2 Okre lenie Dziaa Nast pczych

Rysunek 17.6. pro-

Diagram przepywu ryzyka ukazujcy kluc zowe punkty jektu, w ktrych konieczne jest zarzdzanie ryzykiem Projektu (ZS2)

17.6.4.

Zezwolenie na Realizacj

Komitet Sterujcy ma wwczas zbada uaktualniony Rejestr Ryzyka, w ramach procesu podejmowania decyzji, dotyczcej celowoci kontynuowania projektu. W wyniku doprecyzowania Uzasadnienia Biznesowego mogo zosta ujawnionych wiele zagro e. Bar- czsto ich wacicielami bd czonkowie Komitetu Sterujcego i musz oni dzo po-

29 0

PRINCE2

ZARZDZANIE RYZYKIEM

twierdzi przyjcie danego zagro enia na wasno oraz zobowiza si do realizacjiwymaganych od waciciela zaro dziaa enia.

17.6.5.

Analizowanie Zagro e

(PL6)

Za ka dym razem, gdy powstaje plan, pewne jego elementy mog wprowadza nowe za- enia, modyfikowa ju istniejce lub eliminowa inne. aden plan nie powinien gro by przedstawiony do zatwierdzenia, zanim zwizane z nim zagro enia nie zostan przeanalizowane. Taka analiza mo e prowadzi do modyfikacji planu w celu podjcia waciweg oziaania lub dziaa, wynikajcych z wybranej reakcji na zagro enie. Rejestr d Ryzyka powinien by uaktualniony wszystkimi takimi szczegami.

17.6.6.

Uaktualnienie Rejestru Ryzyka (ZE4)

W ramach przygotowa do kolejnego etapu Kierownik Projektu uaktualnia Rejestr Ryzyka, wprowadzajc wszelkie zmiany dotyczce istniejcych zagro e.

17.6.7.

Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego (ZS3) realizacj planu, Komitet Sterujcy ma sposobno przygotowywania oceny dalszej zasadnoci (SE1)

Przed zezwoleniem na przeanalizowania ryzyka w ramach projektu.

17.6.8.

Zgoda na Wykonanie Grupy Zada

Negocjacje z Kierownikiem Zespou lub czonkiem zespou mog wskaza nowe zagr o- nia e lub zmiany ju Mo e si okaza niezbdne, by Kierownik Projektu znanych. wczeniejszych ustale i poprawi jak cz pierwotnie okrelonej Grupy wycofa si z Zada lub zmieni Plan Przykadami tego mog by np. decyzja wykonawcy Etapu. o zastosowanie nowej technologii lub potrzeba znalezienia specjalnych lub rzadkich zasobw.

17.6.9.

Przyjmowanie Grupy Zada

do Wykonania (WP1)

W tej fazie projektu Kierownik Zespou sporzdza Plan Zespou, aby wykaza, e produkty mog by dostarczone w ramach ogranicze uzgodnionej Grupy Tak jak Zada. inny plan, mo e on zawiera jakie nowe zagro enia albo modyfikowa ka dy istniejce.

17.6.10.

Analizowanie Zagadnie

Projektowych (SE4)

Ocena nowego Zagadnienia Projektowego mo e wskaza na ryzykown sytuacj. Na przykad proponowana zmiana mo e wytworzy zagro enie wyprowadzenia etapu lub projektu poza granice tolerancji.

17.6.11.

Przegl d Stanu Etapu (SE5)

W tym podprocesie zestawia si razem Plan Etapu wraz z ostatnimi faktycznymi danymirealizacji, o Plan Uzasadnienie Biznesowe, otwarte Zagadnienia Projektu, tolerancji i Rejestr Projektowe, status Kierownik Projektu (w porozumieniu z osobami Ryzyka. spra291

MANAGEMENT OF RISK wujcymi rol Nadzoru Projektu) poszukuje zmian statusu zagro e, jak rwnie wszelkich innych sygnaw ostrzegawczych.

PRINCE2

17.6.12.

Przekazywanie Zagadnie

Projektowych (SE8)

Podobnie jak w przypadku Zagadnienia Projektowego, zmiana ryzyka mo e zmusi Kierownika Projektu do przedo enia Komitetowi Raportu o Istotnych Sterujcemu Odchyleniach.

17.6.13.

Raportowanie Okresowe (SE6)

W trakcie tego podprocesu Kierownik Projektu mo e skorzysta z okazji, by zgosi Komitetowi Sterujcemu wszelkie sprawy zwizane z ryzykiem. Przykadami mo e by powiadomienie Komitetu o ka dym zagro eniu, ktre nie jest ju istotne, ostrze enie o no- zagro eniu oraz przypomnienie o wszystkich zagro eniach, na ktre powinni wym zwraca uwag czonkowie Komitetu Sugerowany format Raportu Sterujcego. w Dodatku A Okresowego znajduje si Zarysy Opisw . Produktw

17.6.14.

Podejmowanie Decyzji Dora

nych (ZS4)

Kierownik Projektu zawiadamia Komitet Sterujcy o sytuacjach wystpienia istotnych za pomoc Raportu o Istotnych Odchyleniach. Komitet Sterujcy ma mo odchyle liwo zareagowania rad lub decyzj, np. przedwczenie zamykajc projekt, proszc Nadzwyczajny albo usuwajc problem. Komitet Sterujcy mo e udzieli o Plan doranej podstawie informacji otrzymanych od kierownictwa firmy, programu lub z rady na innego zewntrznego rda. Podczas analizy zagro e Kierownik Projektu powinien przedyskutowa Komitetem dziaania zaradcze i uzyska jego decyzj w tym wanie Sterujcym podprocesie. z

17.6.15.

Okre lenie Dziaa

Nast pczych (ZP2)

Pod koniec projektu mog ujawni si zagro enia, ktre mog wpyn na produkt w czasie jego eksploatacji. Powinny one by przeniesione do Zalece Dziaa Nastpczych w celu poinformowania tych, ktrzy bd utrzymywali produkt po zakoczeniu projektu.

17.7.

Wzajemne zale no

ci

Zagro enia mog posiada dodatkowe zwizane z nimi czynniki, ktre powiksz zo ono oceny caociowego ryzyka projektu. Obejmuje to tak e wzajemne zale noci. jest, aby zrozumie wspzale no zagro e, oraz jak mog one potgowa Istotne si wzajemne. Niewystarczajce kwalifikacje w poczeniu z powa ny mi problemami technicznymi oraz wymogiem przyspieszenia terminu dostawy produktu s powszechnie zna- przykadami wzmacniania si zagro e. Wzajemne zale noci mog si nymi pojawia na ka dym z poziomw projektu oraz midzy r nymi poziomami. Projekt mo e by zale ny od innych projektw. Mo e by uzale niony od dostawcy wyrobw lub usug, ktry z kolei w acuchu dostaw jest uzale niony od innego wewntrznego projektu, dostarczajcego swoje produkty, itd. Zale noci te musz by jednoznacz29 2

PRINCE2

ZARZDZANIE RYZYKIEM

nie okrelone i ocenione w ramach procesu zarzdzania ryzykiem. Wzajemne zale noci przekraczaj granice r nych obszarw, takich jak forma wasnoci, sposoby czsto finansowania, zasady podejmowania decyzji, granice organizacyjne lub geograficzne. oceni wynikajce std zagro enia i komunikowa si poprzez te Trzeba umie granice.

17.8.

Dalsze rozwa ania o zarz

dzaniu ryzykiem

Relacja mi dzy zagro eniem dotycz cym korzy ci biznesowych a zagro eniem dotycz cym dostarczania produktw Czsto pr oces zarzdzania ryzykiem koncentruje si przede wszystkim na dostarczaniua nie na korzyciach biznesowych. Zmiany dat dostawy, kosztw, jakoci produktw, itp. s odnoszone do korzyci. Skonno do kontynuowania dostarczania produktw nie mo-trwa jeszcze dugo po tym, jak potencjalne korzyci zostay ju e znacznie zmniejszone lub utracone. Typow przyczyn tego jest, e waciciele celw zwizanych z korzy- biznesowymi nie s tymi samymi osobami, co waciciele celw zwizanych ciami z ostarczeniem produktw. Decyzje podejmowane w odniesieniu do dostarczania d produktw musz by konfrontowane z zapewnieniem korzyci biznesowych i na odwrt. Zagro enia wewn trzne a zagro enia zewn trzne Gwne procesu trudne do zo one w obu

Czyniono wysiki, by rozr ni zagro enia wewntrzne i zewntrzne. znalezione r nice dotycz jednak e mo liwoci wykorzystania do ka dego z nich zarz- ryzykiem. Zagro enia wewntrzne mog by po prostu tak samo dzania zidentyfikowania, oceny i wyceny, jak zagro enia zewntrzne, a zatem rwnie zarzdzaniu. Te same oglne zasady zarzdzania ryzykiem odnosz si do rodzajw. Wskazwki i rady

Koszty ustanowienia procesu zarzdzania ryzykiem w projekcie zale od zo onoci zwizanych z nim czynnikw technicznych, politycznych i organizacyjnych. Jednak e istnieje kilka oglnych wskazwek, ktre mog by zastosowane. Planici projektw powinni oczekiwa, e 1 - 3 procent ich bud etw zostanie wydane na wstpne prace dotyczce zarzdzania ryzykiem, a dalsze 2 procent na monitorowanie i aktualizowanie go w czasie caego cyklu realizacji. Lista kontrolna dotyczca ustanawiania wacicieli zagro e: Czy waciciele zagro e zostali przypisani do wszystkich czci caego procesu zarzdzania ryzykiem oraz czy zajto si caym zakresem zagro e? Na przykad dostawcy mog by ustanowieni wacicielami oszacowania i oceny ryzyka w ramach swoich kontraktw. Czy r ne role i obowizki zwizane z wasnoci zostay dobrze okrelone? Czy osoby, ktrym przydzielono wasno, faktycznie posiadaj uprawnienia, by w praktyce wypenia swoje obowizki? Czy r ne role i obowizki zostay zakomunikowane i zrozumiane? Czy wskazani waciciele s waciwi?

293

MANAGEMENT OF RISK
Czy w przypadku zmiany, wasno mo e by szybko i efektywnie przydzielona komu innemu? Czy r nice pomidzy ryzykiem zwizanym z osiganiem korzyci biznesowych a ryzykiem zwizanym z dostarczeniem produktu s dobrze zrozumiane i konieczne - czy maj one r nych wacicieli?

PRINCE2

- jeli to

Dziennik prowadzony przez Kierownika Projektu mo e by bardzo u yteczny w monitorowaniu zagro e. Kierownik Projektu mo e dokonywa w nim zapisw dotyczcych sprawdzenia statusu ka dego zagro enia, ktrego jest wacicielem. Inne zapisy mog by czynione w celu przypomnienia o koniecznoci sprawdzenia, czy pozostali waciciele monitoruj i kontroluj swoje zagro enia i dostarczaj informacji zwrotnej. Jeli projekt jest czci programu: Kierownictwo programu jest odpowiedzialne za zapewnienie zarzdzania tymi zagro eniami, ktre s wspzale ne pomidzy projektami i programem. Tam, gdzie jest to waciwe, program powinien uczestniczy w zarzdzaniu ryzykiem na poziomie projektu. Zwykle mo e to by realizowane przez uczestniczenie w ocenach kocowych etapw czonka kierownictwa programu bd wyznaczonej osoby penicej w programie funkcje zwizane z zarzdzaniem ryzykiem. Zagro enia czsto mog by wsplne dla r nych projektw i mo e by korzystne ich scentralizowanie na poziomie programu. Koszt dziaania korygujcego mo e by zmniejszony, jeli jest ono planowane, uzgodnione i uruchomione tylko raz. W przeciwnym przypadku istnieje niebezpieczestwo pojawienia si dodatkowych problemw, wynikajcych z niespjnego podejcia przyjtego w poszczeglnych projektach.

29 4

18.

J AK O ODO WI S KU P RO JE KTU W R
QUALITY IN A PROJECT ENVIRONMENT

Sterowanie zmianami
dz ani Zarz e S t rat egi cz ne Pro jekt em dz ani Zarz Z S4 e S t rat egi cz ne Pro jekt em

Uzasadnienie biznesowe

Z S4 Z S1 ZS 2 Z S3 Z S5 Z S1 ZS 2 Z S3 Z S5
dz ani Zarz e dz ani Zarz e Zakresem Zakresem E t apu E t apu

Zarz dzanie konfiguracj

Organizacja

Jako Jako rodowisku w Pr jekt E t ojek tu Proapem u P roj ektu rodowisku w projektu d zan Zarz ie d zan ie Zarz warz ani em Wyt owan ie P lan projektu Wyt warz w em rod ukt ani P lan owan ie
Zam wani e St eroow ie I rz yg otani anie P nicjykanowe Zam ow St I ojek P rz jekttu wani Prteroekt u e E rojyg otani Proapemu ie anie P nicjykanowe P rod ukt w

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 18.1. struktu-

Komponent Jako w rodowisku projektu w modelu ralnym PRINCE2

18.1.

Cel

Celem niniejszego rozdziau jest zarysowanie gwnych elementw jakoci wykorzysty- projektach oraz przedstawienie jakoci projektu w kontekcie standardw wanych w jakoci ISO (International Organisation for . Standards)

18.2.

Czym jest jako

Jako w projektach to kwestia identyfikowania tego, co sprawia, e produkty projektu lub usugi odpowiadaj swemu przeznaczeniu, jakim jest zaspokojenie wyspecyfikowanych potrzeb. Projekty nie powinny polega na potrzebach domniemanych. Prowadzi to niepewnoci i jako takie jest mao do przydatne.

29 5

QUALITY IN A PROJECT ENVIRONMENT

PRINCE2

18.3.

Zarz dzanie jako

ci

Zarzdzanie jakoci jest procesem zapewniajcym, e jako oczekiwana przez klienta osignita. Obejmuje wszystkie dziaania zarzdcze, ktre su zostaje przygotowaniu i wdro eniu Planu Jakoci R ne elementy zarzdzania jakoci w Projektu. si wzajemnie i s one organizacji wi nastpujce: System obejmujcy struktur organizacyjn, procedury i procesy do wdro ci jako zarzdzania e, jakoci. Zarwno klient, jak i dostawca mog mie swoje nia systemy Mo e zaistnie konieczno wykorzystania w projekcie jednego z tych jakoci. systemw bd uzgodnionego poczenia ich obu. Sama w sobie, metodyka PRINCE2 bdzie zwykle stanowia cz systemu jakoci firmy lub programu, w ktrym zostaa przyjta jako standard firmy lub programu. Nadzr ktry tworzy i utrzymuje system jakoci oraz monitoruje jego ci jako , stosowanie w celu zapewnienia, e system jakoci funkcjonuje i jest efektywny w dochodzeniu do produktu kocowego, ktry spenia wymagania jakociowe i inne wymagania klienta. Funkcja nadzoru jakoci powinna by oddzielona i niezale na od firmowych dziaa projektowych i operacyjnych, aby umo liwi monitorowanie stosowania systemu jakoci we wszystkich projektach w ramach jednostki organizacyj- Jeli takie niezale ne ciao nie istnieje, to penicy rol Nadzoru nej firmy. Projektu w projekcie tak e rol nadzoru przyjmuj jakoci. Planowanie ktre okrela cele i wymagania dotyczce jakoci i ci jako dziaania su ce , proponuje systemu jakoci. W Dokumencie Inicjujcym stosowaniu Projekt zapewnienia jakoci dla caego projektu s okrelone w Planie Jakoci metody Pro- Wa ne jest, by Oczekiwania jakociowe klienta byy zrozumiane i udoku jektu. towanemen- przed rozpoczciem Odbywa si to podczas Przygotowania projektu. . Ka dy Plan Etapu okrela szczegowo wymagane Projekt (PP) dziaania oraz u zasoby dotyczce jakoci, wraz ze szczegowymi kryteriami jakoci przedstawionymi wpisach Produktw. Opisy Produktw definiuj kryteria jakoci oraz metod O kontro- powinna by zastosowana w celu sprawdzenia, czy wymagana jako li, jaka pro- zostaa osignita. Opis Produktu mo e wymaga aktualizacji, jeli duktu uzgodniono wprowadzenie zmiany produktu. Od chwili zatwierdzenia, Opis Produktu nie powinien by zmieniony bez przejcia przez procedur sterowania zmianami. Kontrola ktra jest rodkiem zapewnienia, e produkty speniaj ci jako nich kryteria jakoci. Kontrola jakoci ma zbada produkty, by stwierdzi, , okrelone dla epeniaj one wymagania. Przegldy jakoci s podstawow technik PRINCE2, s stosowan podczas wykonywania w projekcie prac zwizanych z jakoci. S one wyczerpujco opisane w Rozdziale Technika d . c 24 Przegl jako i

18.4.

Droga do jako

ci

Drog do jakoci w PRINCE2 przedstawia Rysunek 18.2. Ka dy element tego rysunku jest objaniony w nastpujcych poni ej podrozdziaach, wraz z odniesieniem do tych obszarw PRINCE2, ktre si z nim wi . Rysunek 18.3 ukazuje t drog w inny sposb.

29 6

PRINCE2

JAKO W RODOWISKU PROJEKTU

PP4 Przygotowanie Zao e Projektu

Kryteria Oczekiwania
PP5 Okrelenie Formuy Realizacji Projektu

Akceptacji jako ciowe klienta

Zewntrzne dla projektu ISO

Formua Realizacji Projektu

IP1 Planowanie Jakoci Rejestr Jako ci (zao ony) Plan Jako ci Projektu

Polityka jako ci

System jako
PL2 Okrelenie i Analizowanie Produktw

ci

Opisy Produktw i Kryteria Jako ci

Nadzr jako ci

ZE1 Planowanie Etapu

Plan jako ci etapu

ZE1 Planowanie Etapu

SE1 Zgoda na Wykonanie Grupy Zada WP1 Przyjmowanie Grupy Zada do Wykonania

Rejestr Jako ci zaplanowane daty

Grupa Zada

WP2 Wykonywanie Grupy Zada WP2 Wykonywanie Grupy Zada

Rejestr Jako ci aktualizacja rezultatw

Kontrola jako ci

Rysunek 18.2. (proces)

Droga do jakoci

297

QUALITY IN A PROJECT ENVIRONMENT

PRINCE2

Zlecenie Przygotowania Projektu

Oczekiwania jako ciowe klienta Kryteria Akceptacji

PP4 Przygotowanie Zao e Projektu

PP5 Okre lenie Formuy Realizacji Projektu

Formua Realizacji Projektu

Plan Jako

ci

Projektu

IP1 Planowanie Jako

ci

Rejestr Jako (zao ony)

ci

Plan jako

ci etapu

Rejestr Jako - zaplanowane daty

ci

ZE1 Planowanie Etapu

PL2 Okre lenie i Analizowanie Produktw

Opisy Produktw Kryteria Jako ci

SE1 Zgoda na Wykonanie Grupy Z ada

Grupa Zada

WP1 Przyjmowanie Grupy Zada do Wykonania

Rejestr Jako - aktualizacja rezultatw

ci

WP2 Wykonywanie Grupy Zada

Kontrola jako

ci

Rysunek 18.3. Dr oga do jakoci (przepyw prac)

18.4.1.

Elementy drogi do jako

ci

W PRINCE2 kwestie dotyczce jakoci zaczynaj si od stwierdzenia, jakie s Kryteria Akceptacji oraz Oczekiwania jakociowe klienta. Powinno to by wykonane w podprocesie Przygotowanie Zao Projekt (PP4). aden realistyczny plan dostarczenia towie produktu o okrelonej u jakoci nie mo kliene powsta, dopki obie strony, klient i dostawca, nie opisz i nie uzgodni, jaka ma b y ta jako. Klient i dostawca potrzebuj zrozumienia zwizku midzy jakoci, kosztami i czasem, i musz je wsplnego rwno- zapewniajc, e produkt kocowy odpowiada swemu przeznaczeniu i zosta wa y wykonany w ramach innych ogranicze.

29 8

PRINCE2 Oczekiwania jako ciowe klienta

JAKO W RODOWISKU PROJEKTU

Potoczne rozumienie sowa jako zakada wysok jako, tj. wykorzystanie najlep- surowcw, mistrzowskiego rzemiosa, kontr oli we wszystkich fazach szych wytwarzania produktu oraz gruntownego przetestowania go wykraczajc poza wszystkie oczekiwane tak nie musi by. Nie ma takich samych oczekiwa jakociowych granice. Ale wobec wszystkich produktw. Wa ne jest, czy produkt jest przeznaczony do wiecznego u yt- czy te do u ytku jednorazowego. Wystarczy porwna czas i nakad pracy ku, powi- to, aby Wielki sownik zyka... by wolny od bdw ortograficznych, z cone na j i nakadem pracy powiconym . na to czasem w przypadku gazety codziennej. Oczekiwania jakociowe klienta powinny prowadzi do Kryteriw Akceptacji dla kocowego rezultatu pr ojektu (np. do sensownego zharmonizowania kosztw, terminu kocowego i jakoci). Mo liw tre oczekiwa jakociowych klienta przedstawiono w odpowiednim zarysie Opisu Produktu w Dodatku A. Kryteria Akceptacji Definiuj one w kategoriach mierzalnych cechy wymagane od produktu kocowego (lub produktw), aby by on zaakceptowany przez klienta i personel, na ktry bdzie on oddziaywa. Oczekiwania jakociowe klienta mog by niespjne i/lub niekompletne, mo e zaistnie znalezienia kompromisu midzy oczekiwaniami klienta i innymi potrzeba czynnikami, np. wymogami prawa. Czsto zaistnieje potrzeba wywa enia oczekiwa jakociowych ogranicze dotyczcych terminw i kosztw. Jako produktu klienta oraz kocowegoby jednoczenie taka, aby mo liwe byo osignicie planowanych powinna korzyci biznesowych. Kryteria Akceptacji s rezultatem kocowym tych kompromisw i s finalizowane w podprocesie Planowanie (IP1). c Jako i Kilka sugerowanych Kryteriw Akceptacji podano w zarysie Opisu Produktu w Dodatku A. ISO ISO publikuje szereg midzynarodowych standardw, cznie ze standardami dla syste- zarzdzania jakoci. Istnieje specjalny standard obejmujcy wymagania dla mw syste- zar zdzania jakoci w zakresie projektowania lub konstruowania, mw wytwarzania, i serwisowania produktu wr az z zarzdzaniem projektem. Standard ten uruchamiania stosowany jest przez wiele organizacji jako podstawa ich systemw zarzdzania jakoci (SZJ). Zastosowanie PRINCE2 mo e pomc w sprostaniu temu standardowi jakoci. Firma mo e stosowa standard jakoci ISO: ustanawiajc funkcj zarzdzania jakoci; sprawdzajc systemy nadzoru jakoci dostawcy. Mo e to zatem mie szereg oddziaywa na czynniki dotyczce jakoci w projekcie: ten standard mg by u yty przez klienta i/lub dostawc podczas budowy wasnego systemu zarzdzania jakoci;

299

QUALITY IN A PROJECT ENVIRONMENT

PRINCE2

metody konstruowania produktu stosowane przez dostawc mog by certyfikowane ze standardem jako zgodne ISO; klient mo e sobie yczy porwnania metod zarzdzania jakoci dostawcy z wymaganiami standardu ISO lub wymaga takiego dostawcy, ktry posiada certyfikat zgodnoci ze standardem ISO; mo e on zosta wykorzystany jako podstawa polityki jakoci firmy dostawcy. ci

Polityka jako

Klient i/lub dostawca mog posiada okrelon polityk jakoci, formuujc stanowisko firmy w odniesieniu do jakoci wszystkiego, co firma robi lub stosuje. Powinna ona ukierunkowywa i wpywa na nastawienie dostawcy przy konstruowaniu, testowaniu i reagowaniu na wszelkie za alenia klienta dotyczce jakoci. Jeli zarwno klient, jak i dostawca maj polityk jakoci, sensowne jest sprawdzi, czy s one zharmonizowane. Jeli nie, powstanie potrzeba wypracowania kompromisu, opar- na potrzebach i w najlepszym interesie tego klienta. Jeli projekt jest czci programu, program musi zapewni dyrektywy lub wytyczne dla polityki jakoci projektu. System zarz dzania jako ci

Dwa elementy powinny wspiera polityk - system zarzdzania jakoci jakoci (SZJ) i struktura organizacyjna zarzdzania jakoci. SZJ jest zbiorem standardw obejmujcych wszystkie typowe prace wykonywane przez Ka dy firm. standard powinien obejmowa techniki, narzdzia, wymagane umiejtnocijakie trzeba przedsiwzi przy wytwarzaniu produktu okr elonego typu. oraz kroki, Jeli produkt jest dokumentem, standard obejmie tak e jego format lub wygld. Jeli zarwno klient, jak i dostawca posiadaj systemy zar zdzania jakoci, nale y si porozumie, ktry SZJ bdzie wykorzystany, albo czy zostanie wykorzystana jaka kombinacja standardw z obu systemw. Struktura organizacji jakoci okrela odpowiedzialno za jako, to znaczy odpowiada na pytanie, kto ustanawia polityk jakoci, kto ustala standardy, by zapewni zgodno wszelkie zewntrzne ciaa, nakadajce ograniczenia dotyczce jakoci, z t polityk, kto monitoruje stosowanie standardw i wszelkie grupy szkoleniowe w zakresie jakoci.z tych prac jest czsto wykonywanych w ramach funkcji centralnego nadzoru Wiele jakoci. Formua Realizacji Projektu To, w jaki sposb projekt chce speni Oczekiwania jakociowe klienta, bdzie zale ao podejcia wybranego dla osignicia kocowego rezultatu. Typowe formuy od realizacji to: produkt jest konstr uowany od zera przez personel klienta; zewntrzny dostawca konstruuje produkt od zera;

30 0

PRINCE2

JAKO W RODOWISKU PROJEKTU

produkt jest konstruowany od zera przy wsparciu wielu firm zewntrznych; istniejcy produkt jest modyfikowany, by sprosta nowym potrzebom; kupowany jest gotowy produkt, tzw. produkt z pki. Metody sterowania jakoci oraz zakresy odpowiedzialnoci bd si zmieniay w zale - oci od wybranej formuy. n Formua Realizacji Projektu zostaje potwierdzona jako element Przygotowani procesu (PP) . Od tego momentu jest obowizujca i mo e by wykorzystana w e Projekt u podpro- (IP1). cesie Planowanie c Jako i Zwykle nie jest mo liwe uczestnictwo w testowaniu produktu z pki. Uprzywilejowa- by zaproszony do udziau we wczesnym testowaniu produktu, ale ny klient mo e 30 zazwyczaj dzieje si to wtedy, gdy firma ju jest . Sprawdzanie jakoci klientem takich produktw mo e zosta przeprowadzone z udziaem aktualnych klientw. Czasami, w przypadku dro szych produktw, wprowadza si okres prbny, w ktrym produkt moe by testowany. Nadzr Projektu Metodyka PRINCE2 proponuje dobre metody sprawdzania jakoci w przypadku, gdy produkt ma by konstruowany przez zewntrznych kontrahentw. Wykorzystuje si do tego Nadzr Projektu. Za ka dym razem, gdy Kierownik Zespou zewntrznego planujedla projektu, osoby penice rol Nadzoru Projektu powinny przeprowadzi prace prze- i zaakceptowa projekt planu. Celem jest identyfikacja tych produktw gld wytwarzanych w ramach planu, ktre s w sferze zainteresowania Nadzoru Projektu. Wwczas to weryfikuje on, czy rozwizania dotyczce sprawdzenia jakoci tych produktw s satysfakcjonujce. Dotyczy to metod kontroli, punktw w procesie wytwarzania produktu, w ktrych powinny by przeprowadzone inspekcje, oraz osb, ktre bd uczestniczyy w tych inspekcjach. Nadzr Projektu musi mie mo liwo wyznaczenia osb, ktre zo- wczone do inspekcji. Jest to szczeglnie istotne i wa ne dla nadzoru klienta stan nad pracami zewntrznego kontrahenta. Wymg mo liwoci przegldu i modyfikacji planw kontrahenta powinien zosta wczony do u mowy. Plan Jako ci Projektu

Powstaje w procesie Inicjowanie Projektu IP) Stanowi cz Dokumentu ( Inicjujcego Projekt i okrela w oglnych kategoriach, . jak projekt speni Oczekiwania jakociowe klienta . Dokument wskazuje techniki i standardy, ktre bd u yte. Jeli istnieje SZJ, zwykle wystarcza proste odniesienie do ksigi jakoci SZJ, w ktrej s zawarte standardy. Jeli to konieczne, Plan Jakoci Projektu powinien wskaza te standardy w SZJ, ktre nie bd stosowane, lub wymieni wszelkie inne dodatkowe standardy, ktrych nie ma w SZJ, a ktre bd zastosowane. Plan powinien tak e ustala zakresy obowizkw zwizanych z jakoci w projekcie. Na przykad jeli klient lub dostawca posiada w swej firmie funkcj nadzoru jakoci, plan powinien wyjania, jak rol w projekcie bdzie odgrywaa komrka organizacyjna pe30

Producenta przypis tumacza.

301

QUALITY IN A PROJECT ENVIRONMENT nica t funkcj. Wi e si to z komponentem Organizacj (patrz PRINCE2 a 14), zgodnie z ktrym przedstawiciel komrki organizacyjnej zewntrznego Rozdzia nadzoru jakoci mo e obj cz obowizkw roli Nadzr Projektu.

PRINCE2

W Planie Jakoci Projektu powinny by wymienione zakresy obowizkw zwizanych z jakoci dla Kierownika Projektu i Bibliotekarza Konfigur acji oraz zdefiniowany spo- w jaki maj by penione obowizki nadzoru ka dego z czonkw Komitetu sb Sterujcego. Plan jako ci etapu lub plan jako ci zespou

Plany Etapw lub Plany Zespow powinny zawiera plan jakoci, ktry okreli metody i zasoby, u yte do kontroli jakoci ka dego Osoby penice rol Nadzoru Proproduktu. jektu maj tutaj do wykonania istotne zadanie w identyfikowaniu produktw o kluczowym znaczeniu dla reprezentowanych przez nich interesw oraz w okrelaniu, kto powi- wzi udzia w kontroli jakoci tych produktw. Na przykad w przypadku ka nien dego przegldu jakoci powinny by podane nazwiska kierownika przegldu i testerw. Plan lub Plan Zespou powinien ukazywa w formie graficznej (zwykle na Etapu wykresie kiedy nastpi przegld jakoci i jak dugo Gantta), potrwa. Jest to szczeglnie wa ne w przypadku, gdy praca jest powierzona zespoowi zewntrz- Zamiast nemu. czeka, a produkt zostanie poddany prbom ukoczony by lepiej dla klienta skierowa akceptacyjnym, mo e ludzi sprawdzajcych produkt przez cay czas projektowania i wytwarzania. Odkrycie, e produkt nie spenia wymaga jego dopiero prb akceptacyjnych, mo e drogo kosztowa, a nawet okaza si zgubne w czasie dla projektu. Plany jakoci etapw i zespow nie s oddzielnymi dokumentami, ale s integralnymi Planw Etapw i Planw fragmentami Zespow. Jeli w projekcie bd wykorzystywane zespoy zewntrzne, wa ne jest, by okreli w umowie, e osoby penice rol Nadzoru Projektu maj prawo wgldu we wstpne planw i mog domaga si, by personel nadzoru uczestniczy w kontrolach wersje jako- kiedy tylko sobie tego za ci, yczy. Opisy Produktw i kryteria ci jako Czci Planu Etapu powinny by Opisy Produktw dla ka dego gwnego produktu, ktry ma powsta w trakcie tego etapu. Zawieraj one midzy innymi kryteria jakoci, ktre produkt musi speni oraz metod sprawdzenia, czy ukoczony produkt odpowiada tym kryteriom. Jest sensowne, a czsto niezbdne, by personel klienta bra udzia w przygotowaniu Opi- Pr oduktw, cznie z kryteriami jakoci, nie tylko dlatego, e s to osoby, ktre sw powinny posiada najlepsz wiedz na ten temat, ale tak e dlatego, e produkt powinien speni wanie ich oczekiwania jakociowe. Nieodcznym kryterium jakoci dla ka dego produktu jest to, e produkt powinien odpowiada wszystkim elementom Opisu Produktu. Na przykad powinien zawiera ele- wymienione w sekcji Skad i posiada zdolno spenienia okrelonego dla menty niego przeznaczenia.

30 2

PRINCE2 Przegl d jako ci

JAKO W RODOWISKU PROJEKTU

PRINCE2 o krela specyficzn technik kontroli jakoci, zwan Przegldem jakoci. szczeglne kroki przegldu jakoci s objanione w Rozdziale Technika 24 . Oglnie rzecz biorc, jest to uporzdkowany przegldPrzegl k c dokumentu, o i dokonywany w sposb planowy, udokumentowany i zorganizowany. Osoby przez grup osb biorce udzia powinny by wyznaczone podczas przygotowywania Planu Etapu. w nim Techni-e si z czci organizacji projektu zajmujc si zarzdzaniem konfiguracj, ka wi kt- bdzie odpowiada za wydawanie kopii dokumentacji, podlegajcej ra przegldowi,oryginaowi statusu obiektu odniesienia oraz aktualizowanie statusu nadawanie produktu. Istnieje tak e powizanie Przegldu jakoci z osobami penicymi rol Wsparcia Projektu, ktre mo g si podj zorganizowania przegldu i rozpowszechniania dokumentacji. Rejestr Jako ci

Pod ja-

Rejestr Jakoci tworzony jest w trakcie Inicjowanie (IP) . Znajduj si procesu zapisy dotyczce wszelkich przeprowadzanych kontroli Projektu w nim jakoci. Szczegy wszystkich przyszych dziaa, dotyczcych kontroli jakoci, s wpisywane do rejestru, w momencie gdy s one planowane albo w Planie Etapu, albo w Planie Zespou. Kierownik Zespou lub pojedynczy czonek zespou, odpowiedzialny za wytworzenie produktu, kolejno aktualizuje i testowanie wpisujc wyniki i daty kontroli rejestr, ci. Stanowi to lad rewizyjny dla audytorw prac jakodotyczcych jakoci wykonanych w projekcie .

18.4.2.

Zagadnienia Projektowe

Zagadnienia Projektowe maj szereg potencjalnych oddziaywa na jako. Zagadnieniem Projektowym mo e by problem odnoszcy si do jakoci. Zwykle problemy takie powinny by wykrywane w czasie kontroli Ale problem dotyczcy jakoci mo jakoci. e by wykryty w produkcie, ktry zosta ju zatwierdzony, czy te w trakcie przegldu jakoci ujawni si problem w produkcie, ktry nie jest aktualnie sprawdzany. Jest tak e o liwe, e w czasie kontroli jakoci wykrywa si problem, ktrego rozwizanie m wymaga wiele czasu i/lub zaanga owania znacznych zasobw. Ze wzgldu na ograniczenia na zdecydowa o zatwierdzeniu produktu, ktry zawiera wad. W czasowe mo obydwu tych przypadkach wada mo e zosta zaakceptowana jako Ustpstwo. Bdzie ona zgoszona jako Zagadnienie Projektowe (jako , tak by istnia waciwy zapis, Odstpstwo)nie a wada zostaa przeoczona. Jeli Zagadnienie Projektowe wymag a zmiany w jednym lub wikszej liczbie produktw, nale y przejrze odnone Opisy Produktw, aby ustali, czy nie nale y rwnie w nich dokona zmian.

18.4.3.
Jest trudne ten nie klienta.

Co jest znamienne dla ci w rodowisku projektu? jako bardzo - a nawet niemo - osign korzyci biznesowe liwe spenia oczekiwa jakociowych jeli

z produktu,

303

QUALITY IN A PROJECT ENVIRONMENT

PRINCE2

Ze swej natury projekt jest rodowiskiem majcym ograniczony czas - budowatrwania okrelonym celu. Z tego wzgldu, jeli firma nie posiada wdro onego nym w systemu mo e wystpi konieczno stworzenia wymaganego systemu zarzdzania jakoci, jako- specjalnie na potrzeby konkretnego ci projektu.

18.5.

Realizacja prac dotycz

cych jako

ci projektu

Planowanie jakoci projektu, w celu zapewnienia, e wyniki projektu bd miay akcep- poziom jakoci, powinno obj nastpujce towalny aspekty: W jaki ka dy produkt bdzie testowany pod ktem spenienia jego sposb kryteriw jakoci? Kied ka dy produkt bdzie testowany pod ktem spenienia jego kryteriw y jakoci? Przez ka dy produkt bdzie testowany pod ktem spenienia jego kogo kryteriw jakoci?

Ja dro odbdzie si powiadomienie o k g akceptacji? Pierwszy aspekt znajduje odbicie w Planowanie (IP1), c podprocesie Jako i realizowanym na samym pocztku projektu, w trakcie Inicjowanie (IP) . Dwa koprocesu aspekty Projektu lejne znajduj odbicie w odpowiednich Planach Etapw, przygotowanych Planowanie w podprocesie (ZE1). Etapu Jako osignita zostaje za pomoc kombinacji tych dziaa. Kryteria jakoci dla wszystkich poziomw produktu okrelane s w kategoriach mierzalnych w Opisach Produktw (przedstawiono to w Rozdziale Planowanie oparte na ). Proces 22 wytwarzania produktw i usug sterowany produktach jest poprzez Zgoda na podprocesy (SE1) i Ocena Wykonanie Grupy Zada pw (SE2). Post Ostatnim aspektem jest proces wykorzystania wszystkich technik kontroli jakoci, zdefiniowanych w systemie jakoci. Dziel si one przewa nie na dwie grupy: metody obiektywne, po zastosowaniu ktrych mo na przewa nie udzieli ostatecznej tak lub nie na pytanie, czy produkt posiada odpowiedni odpowiedzi jako. Przykadami tych metod jest zastosowanie czujnikw i miernikw, testowania i list kontrolnych ; metody subiektywne, w ktrych kryteria oparte s na osdach lub opiniach, dotyczcych takich spraw jak wygoda dla u ytkownika, zgodno ze strategi biznesow przez rynek. Technika Przegld jakoci mo e by wykorzystywana i akceptacja do sterowania procesem sprawdzania jakoci tak e w tych obszarach. Wskazwki i rady
Zdefiniowanie obiektywnie mierzalnych kryteriw jest prawie zawsze mo liwe. Ale czasem nie warto tego robi - nie jest to opacalne ze wzgldu na koszty i czas. Dziennik mo e by wykorzystany albo przez Kierownika Projektu albo przez Kierownika Zespou do odnotowywania spraw do wyjanienia, zwizanych z jakoci, takich jak wykrywanie, dlaczego planowana kontrola jakoci nie zostaa przeprowadzona (lub nie zo-

30 4

PRINCE2

JAKO W RODOWISKU PROJEKTU

staa odnotowana w Rejestrze Jakoci), dlaczego tak wiele wad zostao wykrytych podczas sprawdzania jakoci itd. Klienci i dostawcy mog mie r ne standardy jakoci. Wa ne jest zapewnienie, aby odpowiednie miary zostay uzgodnione midzy wszystkimi stronami.

305

19.

ZA RZ DZA NI E K ONFI GU RA CJ
CONFIGURATION MANAGEMENT

Sterowanie zmianami
dz ani Zarz e St rat egi cz ne Pr ojekt em dz ani Zarz e St rat egi cz ne Pr ojekt em

Uzasadnienie biznesowe

Z S4 Z S4 ZS 2 Z S 3 Z S5 Z S1 Z S1 ZS 2 Z S 3 Z S5
dz ani Zarz e dz ani Zarz e Zakresem Zakresem E t apu E t apu Zam owan ie S rz ykan ie I ter jow ow ani P nic yg otani e e Zam ykan ie S rz jow ani I terygktu ie ani P nicjekt u owe e ot E roj owan Proapem u rojeekt t E roje ktu Proapem u P roj ektu t jekt d zan Zar z ie d zan Zar z ie ani em Wyt warz nie P l anowa Wyt warz nie P rod ukt ani P l anowa w em P rod ukt w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu Zarz dzanie ryzykiem Elementy sterowania

Plany

Rysunek 19.1. struktural-

Komponent Zarzdzanie konfiguracj w modelu nym PRINCE2

19.1.

Cel

adna firma nie mo e by w peni sprawna i skuteczna w dziaaniu, jeli nie zarzdza swoimi aktywami, szczeglnie jeli te aktywa maj ywotne znaczenie dla prowadzenia biznesu firmy. Aktywami projektu s produkty, ktre projekt wytwarza, a wic trzeba nimi zarzdza. czny zbir tych aktyww nazywany jest konfiguracj. tak e Konfiguracj kocowego rezultatu projektu jest czna suma wszystkich jego produktw. W kontekcie zarzdzania projektami celem zarzdzania konfiguracj jest identyfikacja, i ochrona produktw ledzenie projektu.

19.2.

Definicja

Zar dzanie mo e by rozwa ane jako kontrola aktyww lub z konfiguracj Jest to dyscyplina, ktra produktw.na precyzyjne sterowanie produktami projektu, pozwala pozwalajc zarzdzajcym:

30 7

CONFIGURATION MANAGEMENT

PRINCE2

specyfikowa wersje produktw u ytkowane i istniejce oraz zachowywa informa- na cj temat: ich statusu (np. w u yciu, zarchiwizowany, gotowy do kontroli jakoci); waciciela ka dego produktu (osoba bezporednio odpowiedzialna za produkt); relacji midzy produktami; utrzymywa zaktualizowane zapisy zawierajce te elementy infor macji; sterowa zmianami w produktach poprzez zapewnienie, e zmiany dokonywane s jedynie za zgod formalnie do tego uprawnionych osb lub gremiw; dokonywa audytu dokumentacji w celu zapewnienia, by zawieraa ona produkty zatwierdzone, i jedynie takie produkty. Budowa samochodu jest dobrym pr zykadem potrzeby zarzdzania konfiguracj. Jakie elementy musz by zgro madzone, aby zmontowa t wersj samochodu? A co z ostatni tablicy pr zyrzdw oraz z przeprojektowanymi wycieraczkami przedniej zmian szyby?pracownicy monta u czerpi pewno, e dysponuj waciwymi czciami? Skd Odpowied brzmi: na podstawie zapisw gromadzonych w ramach zarzdzania konfigura- wymagana jest wymiana korbki podnonika szyby w 5-letnim modelu, cj. Jeli poczenie numeru seryjnego samochodu z zapisami utrzymywanymi w ramach zarzdzania konfiguracj zagwarantuje, e dostarczona zostanie waciwa cz. Na tym przykadzie wida, e Zarzdzanie konfiguracj potrzebne jest w cigu caego ycia produktu i musi by kontynuowane tak e po zakoczeniu cyklu okresu ycia projektu, ktry go wytworzy. Wytwor zenie produktu w ramach projektu jest tylko cz- zaspokojenia tej potrzeby. W trakcie projektu Zarzdzanie konfiguracj ma ci zapewni: mechanizmy zarzdzania, ledzenia i utrzymywania kontroli nad wszystkimi produktami. W jego ramach gromadzi si teczki dokumentw i utrzymuje biblioteki produktw od momentu sprawdzenia ich jakoci oraz kontroluje si wszystkich do- do nich i utrzymuje zapisy dotyczce stp statusu; pewne i bezpieczne przechowywanie ka dego produktu w sposb najbardziej dla niego odpowiedni. Obejmuje to kontrol dostpu do produktu w sposb, ktry pozwoli z jednej strony unikn uszkodzenia produktu, a z drugiej zapobiec nieuprawnionemu dostpowi; mo liwo wyboru i zestawiania rozmaitych komponentw, z ktrych skada si dziaajcy produkt kocowy. Obejmuje to wydanie gotowego produktu lub uaktual-niego; nie do system rejestrowania, Projektowych. ledzenia i przechowywania wszystkich Zagadnie

Zarzdzanie konfiguracj odgr ywa zasadnicz rol w kontroli jakoci Bez nieprojektu. go zarzdzajcy mieliby niewielk lub adn kontrol nad wytwarzanymi produktami, statusem, miejscem gdzie si aktualnie znajduj, czy mog zosta np. nad ich zmienione, ich ostatnie wersje. Zarzdzanie konfiguracj przyczynia si do jakie s ekonomicznegoproduktw o oczekiwanej jakoci wytwarzania poprzez: uczynienie zarzdzania zmianami i uaktualnieniami produktu taszym i mniej nara- na bdy; onym

30 8

PRINCE2

ZARZDZANIE KONFIGURACJ

pomoc w identyfikowaniu produktw, ktre mog by dotknite skutkami proble- zwizanych z innymi powizanymi z nimi mw produktami; sprawdzanie, jakie wersje produktw u ytkownik stosuje lub jest z nimi powizany; czy u ytkowane produkty s zatwierdzone; czy produkty ulegy oddziaywaniuktre inne powizane produkty mog by przyczyn zmian oraz problemw. Zarzdzanie konfiguracj jest obowizkowe. Jeli wytworzono wicej ni jedn wersj produktu, Zarzdzanie konfiguracj ju jest realizowane. Pytaniem jest tylko, na ile formalnie nale y je prowadzi. Zarzdzanie konfiguracj produktw zarzdczych ma takie samo znaczenie jak Zarz- konfiguracj produktw specjalistycznych. Na przykad Plan Etapu uaktualnia dzanie si wiele razy w cigu jednego etapu. Ka da aktualizacja bdzie stanowi now jego wersj.

19.3.

Obiekt odniesienia

Obiektem odniesienia jest fotografia produktu i wszelkich jego skadnikw, zamro onych w pewnym punkcie czasu w okrelonym celu. Na przykad po tym, Plan Pr ojak zostanie uzgodniony midzy Kierownikiem Pr ojektu a Komitetem Sterujcym, jektu Plan Projektu zostaje uznany za obiekt odniesienia. Obiekt odniesienia rejestruje zmiany statusu produktu, ktr y przechodzi do biblioteki konfiguracji po pomylnym zakoczeniu kontroli jakoci, np. testu lub przegldu jakoci. to jego status i zamra a zawarto. Mo e by odtd wykorzystywany jako Zmienia stabilna podstawa do rozwoju jakiegokolwiek pniejszego produktu. Jeli produkt bdzie zmieniany w pniejszym terminie, wersja odniesienia pozostaje niezmieniona. Nale y nada produktowy nowy numer wersji, udostpni kopi produktu ten numer, a wszystkie te fakty odnotowuje si w zapisach zarzdzania noszc konfiguracj. Kiedy poprawiana wersja zostanie ukoczona i przejdzie kontrol jakoci, przeka- jest do biblioteki i staje si nowym obiektem odniesienia dla tej zywana wersji. Poprzednie wersje, bdce obiektami odniesienia, nigdy nie s usuwane. Metoda zarz- konfiguracj musi umo liwia zawsze odtworzenie wszystkich wer sji dzania udostpniionego produktu.

19.3.1.

Wydanie

Wydanie jest kompletnym i spjnym zestawem produktw, ktry stanowi ustalony punkt odniesienia w trakcie wytwarzania kocowego rezultatu, np. cz urzdzenia wraz dokumentacj utrzymania i materiaami szkoleniowymi. Ka dy produkt tego z jego wy- musia by uznany za obiekt odniesienia, aby byo wiadomo, ktre wersje r dania nych powinny by do niego wczone. czci Najbardziej oczywistym wydaniem jest wynik kocowy, ktry jest przekazywany na kocu projektu. Czym typowym jest dostarczanie porednich wyda dla zapewnieniauzgodnionej podstawy dla dalszych prac, najlepiej w naturalnych ustalonej, punktach przeomowych cyklu wytwarzania. Przykadem mo e by wydanie specyfikacji, na pod- ktrej mogyby si rozpocz pr ace zwizane z projektowaniem. To wydanie stawie mo- by uwa ane za rodzaj zestawienia materiaowego - list wszystkich e produktw,

309

CONFIGURATION MANAGEMENT ktre skadaj si na to wydanie, pokazujc numer wersji ka dego produktu oraz dat uznania jej za obiekt odniesienia.

PRINCE2

19.4.

Zarz dzanie konfiguracj

Zarzdzanie konfiguracj obejmuje pi podstawowych funkcji: planowani : decydowanie, jaki poziom zarzdzania konfiguracj bdzie e projekcie iniezbdny w zaplanowanie, w jaki sposb poziom ten bdzie osignity; identyfikowani : wyszczeglnianie i identyfikowanie wszystkich skadnikw e produktu kocowego; sterowani : zdolno do uzgadniania i ustanawiania obiektw odniesienia e produktw, a nastpnie dokonywanie zmian wycznie za zgod waciwych, formalnie okrelonych organw (od chwili zatwierdzenia produktu mottem staje si: Nic nie drgnie, nic si nie zmieni bez zezwolenia); charakteryzowanie : zapisywanie i raportowanie wszelkich aktualnych i statusu historycznych danych, dotyczcych ka dego produktu; weryfikowani : serie przegldw i audytw konfiguracji w celu zapewnienia, e aby rzeczywisty status wszystkich produktw pozostawa w zgodzie z zatwierdzonym stanem produktw, jaki zarejestrowano w zapisach zarzdzania konfiguracj. Zarzdzanie konfiguracj umo liwia zespoowi zarzdzania projektem zachowanie penej kontroli nad aktywami projektu. Osobie, ktra praktycznie stosuje metod zarzdzania konfiguracj, nadaje si tytu Bibliotekarza Konfiguracji. Wzr opisu roli Bibliotekarza znajduje si w Dodatku Konfiguracji Role w zespole dzania B zarz projektem. Wszystkie wymienione wy ej funkcje systemu zarzdzania konfiguracj s niezbdne do zapewnienia projektom powodzenia. Je eli projekt jest czci programu, mo e by wskazane sprawowanie funkcji zarzdzania konfiguracj na poziomie programu, gdy produkty bd prawdopodobnie wykorzy- przez r ne projekty w ramach programu, a ich przekazywanie midzy stywane projek-mo e mie miejsce w czasie trwania projektw. Istotne jest, aby poza tami wewntrznymi wymogami projektu Zarzdzanie konfiguracj w ka dym projekcie speniao wy magania programu. Plan Zarz dzania Konfiguracj Plan ten stanowi cz Planu Jakoci Projektu. Definiuje on: jak i gdzie produkty bd przechowywane; jakie bdzie zabezpieczenie dla ich wprowadzania i dostpu do nich; jak bd identyfikowane produkty i ich kolejne wersje; kto odpowiada za Zarzdzanie konfiguracj. Peny opis sugerowanej zawartoci Planu Zarzdzania Konfiguracj przedstawiony zosta w Dodatku A Zarysy Opisw . Produktw

19.4.1.

31 0

PRINCE2

ZARZDZANIE KONFIGURACJ

Identyfikowanie konfiguracji Ka dy produkt ( i ka da wersja produktu) wymaga jednoznacznego identyfikatora. Minimalnie przyjty schemat kodowania powinien okrela: projekt, w ramach ktrego produkt jest wytwar zany; typ produktu, np. dokument, sprzt; nazw produktu; numer ostatniej wersji. W zale noci od typu produktu, taki unikatowy klucz mo e zawier a tak e inne elementy, takie jak wariant (np. wersja jzykowa). Dodatek A.5 zawiera opis typowej informacji, ktra powinna by przechowywana w Za- Obiektu Konfiguracji. Prace, podczas ktrych powstaje wikszo informacji pisie znajdujcych si w Zapisie Obiektu Konfiguracji, prowadzone s w ramach podprocesu Okr lenie i Analizowanie (PL2). e Produktw 19.4.3. Sterowanie konfiguracj Sterowanie konfiguracj zajmuje si fizyczn kontrol przyjmowania i wydawania produktw, ledzeniem statusu, zabezpieczaniem gotowych produktw i kontrolowaniem wszelkich wprowadzanych w nich zmian. Przekazywanie produktu Kiedy produkt osiga stan, w ktrym powinien zosta poddany sterowaniu konfiguracj (np. gotowy do przegldu albo do zatwierdzenia), powinna istnie przyjta procedura przekazywania produktu Bibliotekarzowi Konfiguracji. Procedura ta powinna posiada odpowiedni mechanizm zabezpieczenia produktu przed pniejszymi zmianami dokony- przez autora lub kogokolwiek innego. W projektach, w ktrych wystpuje wanymi wiele produktw, mo e to wymaga u ycia protokou przekazania. Procedura przekazywania Bibliotekarzowi Konfiguracji mo liwo uaktualnienia statusu powinna da produktu oraz poinformowania o tym Kierownika Projektu. Udost pnianie produktu Kiedy fizyczny stan produktu na to pozwala, oryginalny egzemplarz powinien by zachowany przez Bibliotekarza Konfiguracji, a na zewntrz powinny by wydawane jed y- kopie (np. dokumenty). Potrzeba udostpnienia produktw mo e wynika z nie wielu powodw: szkic produktu powinien zosta poddany przegldowi; trzeba u y produktu do wytwarzania kolejnego produktu w acuchu wytwarzania ( np. kopia uzgodnionej jest potrzebna do wytworzenia projektu konstrukcyjnego), albo produkt specyfikacji jest czci pakietu kolejnego wydania. Procedura udostpniania produktu powinna zapewni zarejestrowanie, komu produkt zosta wydany, oraz daty wydania. Ideaem byoby zapisywanie tak e powodu wydania oraz terminu, w jakim produkt powinien by zwrcony udostpniono wiele kopii dokumentu w ramach przygotowa do przegldu (np. gdy jako- W projektach du ych lub majcych poufny charakter, mo e si okaza ci). konieczne udokumentowanie wniosku o udostpnienie produktu oraz doczenie dodatkowej infor- stwierdzajcej uprawnienia do jego otrzymania, z tak e wszelkich wskaza macji, stopnia poufnoci (cile tajne!, Tajemnica firmowa, Do wasnego u ytku itp.). 311

19.4.2.

CONFIGURATION MANAGEMENT Udost pnianie kopii produktu

PRINCE2

Wszystkie kopie produktu formalnie udostpniane przez Bibliotekarza Konfiguracji po- by, jeli to mo liwe, oznakowane jako kopie i ponumerowane. Ma to na celu winny zagwarantowanie, e w obiegu znajduj si wycznie oficjalne kopie, bo tylko ich waci-znajd si w rejestrze tych, ktrzy maj otrzymywa wszelkie ciele uaktualnienia. prawdopodobiestwo wykorzystywania w trakcie prac nieaktualnych Zmniejszy to produktw. Ideaem byoby, gdyby kopie nieaktualnych wersji wycofywano i niszczono.

19.4.4.

Zestawienie St atusu Produktw

Jest to raport Bibliotekarza Konfiguracji o statusie produktw, np. Czy sporzdzono Opis Produktu?, Czy prototyp produktu jest gotowy?, Czy zosta zatwierdzony?. dotyczy wszystkich produktw projektu albo tylko produktw Raport mo e jednego etapu. Kierownik Projektu mo e si domaga tego zestawienia np. gdy pr zygotowuje Ra- Kocowy Etapu czy te Raport Kocowy Pr ojektu, aby si upewni, czy port wszystkie stosowne produkty maj status zatwierdzony.

19.4.5.

Audyty konfiguracji

W ich trakcie sprawdza si zgodno rzeczywistych produktw z informacjami znajduj- w zapisach zarzdzania konfiguracj, poszukujc takich rozbie noci, jak: cymi si niezgodno w numerach wersji, czy zarejestrowana osoba faktycznie posiada obiekt konfi- wydany jej w celu wprowadzenia zmiany, czy status produktu jest guracji waciwy np. czy produkt majcy status obiektu odniesienia, nie jest zmieniany itp. W trakcie audytu czsto sprawdza si tak e, czy proces zarzdzania konfiguracj odbywa si zgodnie z przyjtym standar dem. Takie audyty maj zwykle miejsce pod koniec ka dego etapu. Zwykle za audyty konfiguracji odpowiedzialny jest kto penicy rol Nadzoru Projektu. Bibliotekarz Konfiguracji powinien go w tym wspomaga. Jeli Komitet Sterujcy spra- samodzielnie Nadzr Projektu, Kierownik Projektu mo e wyznaczy kogo wuje innego przeprowadzenia do audytu konfiguracji.

19.5.

Metoda zarz

dzania konfiguracj

Zarzdzanie konfiguracj mo e by prowadzone odrcznie lub by zautomatyzowane wybiera si metod, ktra jest dostpna i najwaciwsza dla projektu i organizacji. Zarzdzanie konfiguracj obejmuje nastpujce funkcje: identyfikowanie pojedynczych podproduktw produktu kocowego; identyfikowanie produktw potrzebnych do wytworzenia innych produktw; (Te dwa pierwsze punkty proponuj wyranie powizanie z informacjami pochodzcymiPlanowanie oparte na produktach, stosowanej w z techniki PRINCE2.) ustanowienie systemu kodowania, ktry pozwoli jednoznacznie zidentyfikowa ka - y produkt; d identyfikowanie produktu; waciciela

31 2

PRINCE2

ZARZDZANIE KONFIGURACJ

ustalenie, komu powierzono opracowanie lub poprawienie wersji produktu (informa- zwykle pochodzi z cja ta Zgoda na Wykonanie Grupy (SE1)); podprocesu Zada rejestrowanie, monitorowanie i raportowanie aktualnego statusu ka dego produktu, jak rozwija si on w ramach swego specyficznego cyklu w miar ycia; gromadzenie caej dokumentacji opracowanej w okresie wytwarzania produktu; przechowywanie w bibliotece konfiguracji oryginaw wszystkich waciwych produktw, ktre zostay ukoczone; dostarczenie procedur w celu zapewnienia aspektw ochrony i bezpieczestwa pr oduktw oraz kontroli dostpu do nich; dystrybucja kopii wszystkich produktw i rejestrowanie osb, ktre posiadaj kopie produktw; prowadzenie rejestru zale noci midzy produktami, tak aby aden produkt nie zo- zmieniony bez mo liwoci sprawdzenia ewentualnego oddziaywania tej sta zmiany na powizane produkty;

udzielanie wsparcia administracyjnego w przypadku zmian ka dego produktu; ustanawianie obiektw odniesienia (patrz Rozdzia 19.3.); przeprowadzanie audytw konfiguracji. Wiele spord tych funkcji mo na wczy do zakresu obowizkw roli Bibliotekarza Poza pracami w zakresie zarzdzania konfiguracj, Bibliotekarz Konfiguracji. Konfigu- e tworzy i utrzymuje dokumentacje projektu i racji tak etapw. Poszczeglne obiekty mog by modyfikowane lub usuwane wycznie poprzez przedo- Bibliotekarzowi enie Konfiguracji zatwierdzonego Zagadnienia Projektowego.

19.5.1.

Obszar zarz

dzania konfiguracj

Niezbdne dla projektu zakres i stopie sformalizowania zarzdzania konfiguracj zale d typu i rozmiaru projektu oraz od wymogw otoczenia projektu. Jest to sprawa, o ktr trzeba rozstrzygn na samy m pocztku projektu. Metoda zarzdzania konfiguracj powinna obj wszystkie produkty od chwili, kiedy osign one stan wstpnego przygotowania.

19.5.2.

Zarz dzanie konfiguracj

produktw zarz

dczych PRINCE2

Jednym z aspektw zarzdzania konfiguracj, ktry nale y rozwa y, dotyczy tego, czy produkty zarzdcze metodyki PRINCE2 maj podlega zarzdzaniu konfiguracj. Na przykad Plan Etapu aktualizowany bdzie wielokrotnie w oparciu o dane rzeczywiste. Rozsdek nakazuje zastosowa do niego kontr ol Dokonywa si bdzie zapisw wersji. aktualizujcych, ilustrujcych stan realizacji etapu w r nych momentach. Ka da aktualizacja stanowi bdzie now wersj, aby unikn nadpisywania Planu Etapu, ktry uzgod- zosta przez Komitet Sterujcy, czy choby Planu Etapu w swojej postaci niony sprzed dwu tygodni. Ten sam tok rozumowania mo e znale zastosowanie wobec ka dego z produktw zarzdczych PRINCE2, ktre mog zmienia si w miar przebiegu projektu, takich jak 313

CONFIGURATION MANAGEMENT

PRINCE2

Plan Projektu czy Uzasadnienie Biznesowe, struktura zespou zarzdzania projektem i opisy zakresw obowizkw jego czonkw. Z tego wzgldu ma sens objcie tego typu produktw zarzdzaniem konfiguracj. Rejestr Zagadnie, Rejestr Ryzyka, Rejestr Jakoci i Rejestr Dowiadcze nie s zwykle zarzdzaniem konfiguracj. Po prostu regularnie si je aktualizuje. Tak e objte mao prawdopodobne jest to, e raporty, ktre maj tylko jedn wersj, zostan poddane zarzdzaniu konfiguracj.
Produkt A

A1 A2 A3 A4

A3.1 A3.2 A3.3

Rysunek 19.2. konfiguracji

Struktura

19.5.3.

Wybr poziomu produktu

Wa n czci zarzdzania konfiguracj jest podjcie decyzji co do poziomu, na ktrym sprawowana bdzie kontrola z produktami najwy szego poziomu rozo onymi na skadniki, ktre same z kolei s produktami itd. Rysunek 19.2 przedstawia Produkt A, ktry skada si ze skadnikw A1, A2, A3 i A4 . Ka dy z tych skadnikw mo e by podzielony na skadniki podrzdne. W tym przykadzie A3 skada si z A3.1, A3.2 i A3.3. z pokazanych skadnikw jest nazywany pr oduktem, cznie z produktem Ka dy koco- najwy szego poziomu. wym Zwykle produkty s okrelane do najni szego poziomu, na ktrym skadnik mo e by niezale nie instalowany, wymieniany lub modyfikowany. W ka dym projekcie trzeba zdecydowa, na ktrym poziomie zaprzesta rozkadania produktu na ni sze poziomy. na przykad produkt, ktry jest podrcznikiem czy ma sens rozkadanie go Wemy na drobniejsze produkty, takie jak spis treci, indeks, streszczenie, sownik poj itp.? Mo eepsze i prostsze byoby pokazanie tego rozbicia w czci skad Opisu Produktu l Podrcznik. Parametrami, ktre bierze si pod uwag w wyborze liczby poziomw w strukturze produktw, to koszty i pracochonno. Bardziej szczegowe rozbicie daje wiksz kontro- tak e zwiksza koszty i pracochonno zarzdzania l, ale konfiguracj.

31 4

PRINCE2

ZARZDZANIE KONFIGURACJ

19.6.

Zarz dzanie konfiguracj

a sterowanie zmianami

Musi istnie cise powizanie midzy zarzdzaniem konfiguracj a sterowaniem zmia- Kluczowym elementem jest zdolno do identyfikowania i kontrolowania r nami. nych wersji produktu. Produkt, ktry ustalono jako obiekt odniesienia, mo e by zmieniony tylko w ramach formalnej procedury sterowania zmianami. To oznacza, e Zagadnienie Projektowe zostao zatwierdzone i przekazane Bibliotekarzowi Od chwili Konfiguracji. jego wersja nigdy nie ulega zmianie. Jeli zmiana jest potrzebna, zatwierdzenia produktu, ta tworzona wersja produktu, ktra bdzie zawieraa t zmian. Zmiana powinna mie jest nowa odniesienie do odpowiedniego Zagadnienia Projektowego. Produkt nie powinien by wydawany w celu wprowadzenia zmiany wicej ni jednej w tym samym czasie. Jeli w jednym produkcie jest wiele zmian do osobie wprowadze- one by poczone w jaki sposb, a skompletowanie produktu nia, musz zawierajcego wszystkie zmiany powinno by zlecone jednej osobie. W szerokim i zo onym rodowi- to okaza si mao praktyczne, ale wielokrotne zmiany bd i tak musiay sku mo e podlega koordynacji przez jedn osob/funkcj w celu uniknicia baaganu wynikajcego modyfikacji. W przeciwnym wypadku kolejne zmiany musz czeka, z wielorakich a ie ca zmiana zostanie wdro ona. Nastpnie po zatwierdzeniu tej zmiany nowa b wersja moga by wydana w celu wprowadzenia kolejnej bdzie zmiany. Jeli to mo liwe, nie powinno si nigdy wydawa oryginalnego egzemplarza adnego z produktw, lecz jedynie jego kopi.

19.7.

Zarz dzanie konfiguracj

a Biuro Wsparcia Projektw

Poniewa wikszo produktw kocowych bdzie eksploatowanych dugo po zakoczeniu projektu ktry je wytwor zy, zarzdzanie konfiguracj prowadzi si zwykle w caej organizacji po to, by stosowa takie samo podejcie do nadzorowania produktw projek- i produktw eksploatowanych. To dobry powd, by udostpni wszystkim tu, jak projektom kompetencje w zakresie zarzdzania konfiguracj wykorzystujc centralne Biuro Wsparcia Projektw, ktre bdzie kontynuowao kontrol produktw w trakcie ich eksploatacji . Projektowi mo e by przedstawiony wymg dostosowania si do metod zarzdzania konfiguracj stosowanych przez klienta. Wikszo produktw kocowych projektu bdzie dugi, u yteczny ywot i bd modyfikowane wiele razy w cigu okresu u miao ytko- Zarzdzanie konfiguracj jest istotne dla ledzenia tych zmian. Jeli projekt wania. by zlecony wykonawcom zewntrznym, metoda zarzdzania konfiguracj stosowana przez dostawc powinna by zgodna z t, za pomoc ktrej jakakolwiek grupa bdzie opieko- si produktem w trakcie jego waa eksploatacji.

315

20.

S TE RO WA NI E ZM I AN AM I
CHANGE CONTROL

Sterowanie zmianami Sterowanie zmianami

dz ani Zarz e S t rat egi cz ne Pro jekt em dz ani Zarz e S t rat egi cz ne Pro jekt em

Uzasadnienie biznesowe

Z S4 Z S4 Z S 2 Z S3 Z S5 Z S1 Z S1 Z S 2 Z S3 Z S5
dz ani Zarz e dz ani Zarz e Zakresem Zakresem E t apu E t apu Zam owani e S rz ykani e I ter jow o wani P nic ygot ani e e Zam ykani e S rz jow u e I terygot ani e P nicjekt uo wani e Prt ojekt E roj owani Proapem ekt Pr jekt E t ojekt Proapem u P roj ektu d zan Zarz ie d zan ie Zarz warz ani em Wyt P l anowa nie Wyt warz nie rod ukt ani P l anowa w em P rod ukt w

Zarz dzanie konfiguracj

Organizacja

Jako w rodowisku projektu

Plany

Zarz dzanie ryzykiem

Elementy sterowania

Rysunek 20.1. strukturalnym

Komponent Sterowanie PRINCE2

zmianami

modelu

20.1.

Cel

Zmiany specyfikacji lub zakr esu mog potencjalnie zrujnowa ka dy projekt, o ile si nimi nie steruje starannie. Zmiana jest jednak e wysoce prawdopodobna. Sterowanie oznacza ocen oddziaywania potencjalnych zmian, ich znaczenia i zmianami kosztw oraz rozsdn decyzj kierownictwa, czy je wprowadzi. Wszelkie zatwierdzone zmiany znale odbicie w koniecznej, odpowiedniej zmianie harmonogramu i bud musz etu. Technik sterowania zmianami przedstawiono w Rozdziale Technika 23 Sterowanie zmianami . W ka dym projekcie wystpuje potrzeba zarzdzania wszystkimi dotyczcymi go dokumentami. Dokumenty te mog by wnioskami o wpr owadzenie zmian, sugestiami lub dobrymi pomysami, mog by zwizane z problemami w sprostaniu wymaganiom, dokumentowa zewntrzne zmiany wpywajce na Uzasadnienie lub ryzyko, Biznesowe prostu mog stawia pytania i przekazywa spostrze enia dotyczce albo po pewnych projektu, takich np. jak prawdopodobne przeniesienie kogo z zespou aspektw zarz- projektem. PRINCE2 wykorzystuje sterowanie zmianami jako ogln dzania procedur wychwytywania i rejestrowania wszystkich takich Zagadnie Projektowych. 31 7

CHANGE CONTROL

PRINCE2

20.2.

Zarz dzanie Zagadnieniami Projektowymi

Celem jest przyjcie, zarejestrowanie i sklasyfikowanie wszystkich Zagadnie Projektowych . Zagadnienia mog by wniesione w ka dym momencie w trakcie projektu, Projektowe dego zainteresowanego projektem lub jego przez ka wynikiem. Zagadnieniem Projektowym jest wszystko to, co mogoby mie wpyw na projekt (czy to szkodliwy, czy to korzystny). Zagadnienia obejmuj Projektowe : zmian w wymaganiach, choby ma (nawet pozornie bardzo mae zmiany mog mie du e dugoterminowe implikacje); zmian w otoczeniu wpywajc na projekt, np.: zmiana prawa; zmiana celw firmy; nowy klient; nowy dostawca; nieoczekiwana zmiana czonka zespou zarzdzania projektem; dziaania konkurencji; polecenie kierownictwa programu; reor ganizacja firmy; problem wystpujcy lub taki, ktry zosta ujawniony, a ktry nie by dostrze ony podczas analizy zagro e; wystpienie zagro enia przewidywanego, ale niemo liwego do uniknicia; problem lub bd, ktry wystpi w pracy ukoczonej lub aktualnie wykonywanej; zawiadomienie o nowym zagro eniu; zapytanie o jakikolwiek aspekt projektu. Zarzdzanie Zagadnieniami Projektowymi powinno obj: wychwycenie i formaln rejestracj Zagadnienia Projektowego (w Rejestrze Zagad-; nie) ocen Zagadnienia Projektowego w celu zdecydowania o jego rodzaju i o tym, jakie dziaanie w zwizku z tym jest potrzebne; rozpatrywanie wymaganych dziaa; doku mentowanie dziaa i potwierdzanie ich wykonania; regularne przegldanie Rejestru Zagadnie celu monitorowania postpw, w czcych niezaatwionych Zagadnie dotyProjektowych. Zagadnienia mog pochodzi z wielu r nych rde (wczajc w to Projektowe procesy innych projektw), wystpowa w wielu formach i przejawia si na wiele r nych sposobw. Dlatego pierwszym wymaganiem tego procesu jest zapewnienie logicznej i niezawodnej metody wychwytywania wszystkich Zagadnie Projektowych. Wszystkie Zagadnienia powinny by wpisane do Rejestru Zagadnie niezwocznie po Projektowe ich zidentyfikowaniu . 31 8

PRINCE2

STEROWANIE ZMIANAMI

Pocztkowa ocena powinna by wykonana zgodnie z natur ka dego zagadnienia. Poza oglnymi problemami i zastrze eniami, mog wynikn dwa szczeglne rodzaje zmian: Wniosek o Wprowadzenie , ktry z jakichkolwiek przyczyn Zmiany specyfikacji lub Kryteriw Akceptacji projektu lub jednego z jego pr spowoduje zmian oduk-Wszelkie dodatkowe koszty wprowadzenia takiej zmiany s zwykle tw. wane finanso-przez klienta; Odstpstwo, obejmujce bdy lub zaniedbania wykryte w pracach ju wykonanych lub planowanych na przyszo, ktre spowoduj, e uzgodnione specyfikacje lub Kryteria nie zostan spenione. Dodatkowe koszty wykonania prac Akceptacji zwykle obci aj zwizanych z tym naprawczych dostawcw. Implikacje finansowe czyni wa nym odr nianie tych dwch rodzajw Zagadnie Projektowych. Zwykle jest wiksza motywacja, by zaj si bdami (to znaczy Odstp- ni stwami) wprowadza zmiany (Wnioski o Wprowadzenie Zmian), chocia proceduraprzypadkach jest taka w obu sama. Jeli Zagadnienie Projektowe polega na zawiado mieniu o nowym zagro eniu, powinno wpisane do Rejestru Ryzyka i przeanalizowane w zwyky sposb w by ono podprocesie Analizowanie Projektowyc (SE4). Proponowane dziaanie zaradcze mo Zagadnie konieczno wprowadzenia zmiany do projektu, a zmiana ta mo e h e wywoa stanowi analizy, przed przedstawieniem jej Komitetowi Sterujcemu w celu przedmiot dokonania wyboru najwaciwszego dziaania.

20.3.

Poziomy uprawnie

do wprowadzania zmian

Na pocztku inicjowania projektu nale y rozwa y, komu wolno bdzie zezwala na wprowadzenie zmiany (Zagadnienia , ktre wystpi w projekcie. Projektowe)zmiana dotyczy ustale, ktre Komitet Sterujcy zatwierdzi na pocztku pr Poniewa ewentualna ojektu, jego obowizkiem jest wyra anie zgody na ka d zmian, przed jej wdro eniem. W projekcie, w ktrym przewiduje si niewiele zmian, rozsdne mo e by pozostawienie prawa wydawania zgody na zmian w rkach Komitetu Sterujcego. Ale projekt mo eoczy si w rodowisku dynamiczny m, w ktrym np. bdzie wiele wnioskw o t wprowadzenie zmian wzgldem pierwotnie okrelonego zakresu projektu. Nale y pamita, e agadnienie Projektowe mo e by tak e informacj o trudnociach w sprostaniu Z specyfi- nie tylko wnioskiem o zmian ze strony u kacji, a ytkownika. rozwa enia, Kwestie do to: Czy Komitet Sterujcy jest przygotowany do przeznaczenia czasu na dokonywanie przegldw wszystkich Zagadnie Projektowych? Czy chce on rozwa a tylko Zagadnienia Projektowe o najwy szym priorytecie, decyzje dotyczce drugorzdnych zagadnie innemu a deleguje organowi? Zanim zakoczy si inicjowanie projektu, Komitet Sterujcy powinien zdecydowa, kto bdzie mia prawo do zatwierdzania lub odrzucania Zagadnie Projektowych, a obowizki te musz by wpisane do odpowiednich zakresw obowizkw. W niektrych projektach Komitet Sterujcy mo e wybra delegowanie decyzji dotyczcych dziaa zwizanych z Zagadnieniami grupie osb nazywanej komisj do spraw Projektowymi zmian.

319

CHANGE CONTROL

PRINCE2

Dla projektw, ktre istniej w ramach programu, kierownictwo programu powinno poziom uprawnie, jakie Komitet Sterujcy bdzie posiada w obszarze okreli zatwierdzania zmian.

20.3.1.

Bud et zmian

Podobnie jak kwesti, kto ma prawo do podejmowania decyzji, Komitet Sterujcy musi y tak e: rozwa Jak zmiany bd finansowane? Czy Komitet Sterujcy bdzie zwraca si do kierownictwa firmy lub programu finansowania, harmonogramu lub zakresu, za ka dym razem, kiedy o zmian zmiana jest potr zebna? O ile przewidywany poziom zmian w projekcie nie jest niski, wskazane jest przydzielenie spraw zmian bud etu na opacanie zatwierdzonych zmian. Takie komisji do rozwizanie projektach, w ktrych przewidywana jest wysoka czstotliwo pozwala w wystpowania Zagadnie Projektowych, unikn w trakcie etapu wielu ocen nadzwyczajnych z udziaem Komitetu . Jeli przydzielono bud et zmian, nale y zawrze Sterujcego sposobu jego wykorzystywania, rozo enia obowizkw oraz ogranicze porozumienie co do naoonych na uruchomienie bud etu.

20.4.

Integralno zmian
by rozpatrywane w odosobnieniu. Kilka

Zagadnienia nie powinny Projektowe przedstawiono poni innych wzgldw ej.

20.4.1.
Zagadnienia Projektowe rzyci oraz Biznesowe

Kierowanie si ich

korzy ciami/Uzasadnieniem Biznesowym powinny by przegldane pod ktem wynikajcych z nich kooddziaywania na Uzasadnienie .

20.4.2.

Rejestr Ryz yka nowego zagro enia, Zagadnienia po-

W zwizku z mo liwoci ujawnienia Projektowe rozwa ane na trzy sposoby: winny by

Czy wpywa ono na istniejce zagro enia? Czy takie oddziaywanie ju przewidziano w ramach procesw zarzdzania ryzy- i z tego wzgldu mechanizm dla jego obsugi zosta ju kiem okrelony? Czy mo e ono spowodowa nowe zagro enie? Rwnowaga czas koszt ryzyko

20.4.3.

Powinno si d y do zachowania rwnowagi midzy korzyciami osiganymi w wyniku wprowadzenia zmiany a czasem, kosztem i ryzykiem jej wdro Ilustruje to enia. Czy mo na sobie pozwoli na opnienie projektu? Czy mo na znale Rysunek 20.2. dodatkowe Albo czy zmiana zaoszczdzi czas i pienidze? Czy dobrym rozwizaniem fundusze? jest 32 0

PRINCE2

STEROWANIE ZMIANAMI

wydanie dodatkowych funduszy? Czy nie jest to zbyt ryzykowne? Czy zmiana powinnae) zaczeka a do skoczenia bie cego (i mo projektu?

Zmiana Ryzyko Koszt Czas

Korzyci Oszczdnoci

Rwnowa enie ryzyka, kosztw i czasu zmiany z tym, co w efekcie uzyska klient Rysunek 20.2. zmiany Wywa anie decyzji o wprowadzeniu

Je li projekt jest ci programu cz Jeli projekt jest czci programu, powinno si rwnie rozwa y oddziaywanie wnioskowanej zmiany na program jako cao. Mog wystpi tak e konsekwencje dla innych projektw, niekoniecznie bdcych czci programu. Procedury sterowania zmian w projekcie i programie powinny by zharmonizowane.

20.4.4.

20.5.

Zarz dzanie zmianami a Zarz

dzanie konfiguracj

Procedura stosowana do sterowania Zagadnieniami musi by Projektowymi stosowanym do zarzdzania konfiguracj, okrelonym w Planie zintegrowana z podejciem Zarzdzania Konfiguracj. Jeli projekt realizowany jest w rodowisku, ktre nie posiada jeszcze procedury sterowania zmianami, mo na zastosowa technik Sterowanie zmianami przedstawion w Rozdziale 23. Kierownicy projektw powinni poszukiwa sposobw wycigania korzyci z zachostale dzcych zdarze aby zoptymalizowa koszty projektu, harmonogram lu b osignicia. Te sposoby powinny by tak e zarejestrowane jako Zagadnienia (a ich Projektowe odnotowane w Rejestrze Dowiadcze). rezultaty powinny by

Wskazwki i rady
Jeli bud et zmian jest przydzielony Komisji do spraw zmian, Komitet Sterujcy mo e ustali limit dla: (a) kosztw pojedynczej zmiany oraz (b) kwoty, ktr mo na wyda na wprowadzenie zmian w ka dym etapie bez koniecznoci zwracania si do Komitetu Sterujcego.

321

CHANGE CONTROL
Jeli w projekcie bior udzia zewntrzni dostawcy (strona trzecia), wa ne jest, eby procedury zmian byy uzgodnione jako cz negocjacji kontraktu. Szczeglnie wa ne jest, by uzgodni, jak bd rozr niane Wnioski o Wprowadzenie Zmiany od Odstpstw, przez kogo oraz jakie procesy arbitra owe mog by potrzebne. Bardzo czsto osoby z delegowanymi im obowizkami Nadzoru Projektu mog dziaa jako Komisja do spraw zmian.

PRINCE2

32 2

21.

W PR OWAD ZE NI E DO TE C HN IK

PRINCE2 mo e wspdziaa z wikszoci technik, ktre wdra aj najlepsze praktyki zarzdzania projektami. Trzy techniki s szczegowo opisane w PRINCE2: Planowanie oparte produktach; Sterowanie zmianami; Przegld jakoci. na

Planowanie oparte na produktach jest kluczow cech PRINCE2, zapewniajc koncen- produktach, ktre maj by dostarczone, i na ich jakoci. Stanowi ono tracj na integraln cz procesu Planowani (PL) i prowadzi do u ycia innych oglnych technik e planistycznych, takich jak planowanie sieciowe i wykresy Gantta. Sterowanie zmianami jest istotn czci zarzdzania dowolnym projektem. PRINCE2 mo e integrowa si z jakkolwiek istniejc technik sterowania zmianami, ale w ramach metodyki zaproponowano prost technik mo liw do przyjcia w tych projektach, nie stosuje si jeszcze w ktrych adnej. Technika przegldu jakoci jest u yteczna dla kontroli produktw opartych na dokumen- e by stosowana w poczeniu z innymi technikami kontroli jakoci i tach i mo testowa- stosowanie nie jest obowizkowe. Organizacje mog ju posiada podobne nia. Jej tech- ale przegldy jakoci s zalecane jako dobrze sprawdzona technika tam, gdzie niki, nie zadowalajcego standardowego podejcia do sprawdzania ma dokumentw.

323

22.

P LA NOWAN IE OPAR TE N A P R ODU KTA CH

(PRODUCT-BASED PLANNING)

Technika Planowanie oparte na produktach mo e by wykorzystywana na wszystkich planw wymaganych w projekcie. Stosuje si j w poziomach Okr leni podprocesie Analizowanie e e i (PL2). Produktw Technika ta zapewnia platform planistyczn, bazujc na produktach, ktr mo na stosowa we wszelkiego rodzaju projektach, aby nada pracom w projekcie logiczn kolej- Produkt mo e by zarwno materialny, jak maszyna, dokument czy cz no. oprogra- ale mo e mie te charakter niematerialny, taki jak zmiany k ulturowe czy mowania; te nowa struktura organizacyjna. W PRI NCE2 wszystko to nosi miano . Zaproduktwtej techniki zilustrowano prostym przykadem o rganizowania konferencji stosowanie w podrozdziale 22.7.

22.1.

Cztery produkty planowania opartego na produktach

W ramach techniki Planowanie oparte na produktach powstaj cztery produkty: Opis Produktu dla kocowego produktu projektu; Diagram Struktury Produktw; Opis Produktu dla ka dego z produktw; Diagram Nastpstwa Produktw.

22.2.

Korzy ci z planowania opartego na produktach

Planowanie oparte na produktach jest integraln czci PRINCE2 dotyczc koncentracji na jakoci produktw. Skupia si na produkcie kocowym, a tym samym zapewnia, e szystkie produkty czstkowe i dziaania dodaj warto i przyczyniaj si do w wytworzenia produktu kocowego.

22.2.1.

Diagram Struktury Produktw

Diagram Struktury Produktw jest hierarchiczn struktur, w ktrej produkt kocowy jest na prowadzce do jego wytworzenia produkty czstkowe. Pozwala rozo ony planu- pomyle o innych produktach, potrzebnych do wytworzenia produktu jcemu kocowe- jasno okreli wszelkie niezbdne prace prowadzce do jego wytworzenia. go, oraz Rozo enie produktw na podprodukty o mniejszej zo onoci pozwala: oszacowa niezbdn pracochonno, zasoby i ramy czasowe; skonkretyzowa kryteria jakoci; unikn pominicia niektrych produktw. 325

PRODUCT BASED PLANNING

PRINCE2

22.2.2.

Opisy Produktw

Jasny, kompletny i jednoznaczny opis ka dego produktu to nieoceniona pomoc w osigniciu sukcesu przy jego wytwarzaniu. Opis Produktu pomaga zrozumie przeznaczenie oszacowa nakady, ktrych bdzie wymagao jego produktu i wytworzenie. Opis Produktu zawiera wa ne informacje o produkcie. To podstawowy element zapew- jakoci w projekcie. Jest on przekazywany wytwrcy, by wyjani, jaka nienia jako bdzie wymagana w trakcie jego wytwarzania. W dalszej kolejnoci, Opis produktu Pro- przekazywany jest testerom jakoci, w celu ustalenia sposobu kontroli jakoci duktu oraz pomocy w ocenie, czy produkt rzeczywicie osign wymagan jako. W ka dy m projekcie powinien by sporzdzony przynajmniej jeden Opis Produktu dla produktu kocowego. Wskazane jest tak e sporzdzenie Opisw Produktu dla ka dego z produktw prostych (patrz podrozdzia 22.4.1) przedstawionych na Diagramie Struktury Produktw. Wczony do dokumentacji i uzgodniony, dla ka dego pr oduktu, Opis Produktu pomaga: zagwarantowa, e wszystkie osoby, ktrych produkt dotyczy, jednakowo rozumiej jego przeznaczenie; zapewni wytyczne do okrelenia sposobu prezentacji produktu; okreli kr yteria jakoci; okreli sposb, w jaki bdzie testowane osignicie wymaganej jakoci.

22.2.3.

Diagram Nast

pstwa Produktw

Ka dy planista musi zna odpowied na pytanie: Co najpierw, a co potem?. Diagram Nastpstwa Produktw ukazuje kolejno wytwarzania produktw ujtych w planie or zale noci midzy nimi. az Okrela ponadto powizania z wszelkimi produktami, ktre 31 wykraczaj poza zakres . Prowadzi to w naturalny sposb do uwzgldnienia planu dziaa i dostarcza informacji dla narzdzi planistycznych, ktrych PRINCE2 niezbdnych nie obejmuje - jak sie dziaa czy wykres Gantta.

22.3.

Sporz dzanie Opisu Produktu dla produktu ko

cowego

Pierwszym zadaniem w planowaniu opartym na produktach jest udzielenie wsparcia w sporzdzeniu Opisu Produktu dla produktu kocowego projektu. klientowi Przedyskutowanie rozmaitych skadnikw Opisu Produktu (patrz Dodatek Zarysy Opisw A Produkt ) pomo e wyjani, co jest wymagane w tym w przypadku.

22.4.

Tworzenie Diagramu Struktury Produktw (DSP)

Drugim zadaniem w planowaniu opar tym na produktach jest utworzenie Diagramu Struk- Produktw (DSP). Jego cele s tury nastpujce:

31

Produkty zewntrzne przypis tumacza.

32 6

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH identyfikacja produktw, ktre maj by wytworzone lub pozyskane w wyniku planowanych prac; identyfikacja dodatkowych produktw, ktre s niezbdne do budowy i wsparcia kocowych; produktw osignicie porozumienia w zakresie najlepszego pogrupowania produktw, w celu ustalenia jakie produkty musz by wytworzone lub pozyskane. Produkty proste

22.4.1.

Produkty, ktre wystpuj na najni szym poziomie ka dej z gazi struktury hierarchicznej, to produkty - zwane tak dlatego, e w Diagramie Struktury Produktw proste dalej uszczegawiane. Najni szy poziom Diagramu Struktury Produktw nie nie s ju jest Zale y on od stopnia szczegowoci wymaganego p lanem, ktry powinien umo stay. -iwi Komitetowi Sterujcemu, Kierownikowi Projektu lub Kierownikowi Zespou l sprawowanie odpowiedniego poziomu kontroli. Produkty proste przedstawia si na Diagra-Struktury mie Produktw w formie prostoktw.

22.4.2.

Produkty po

rednie

Terminu produkt poredni u ywa si do oznaczenia produktw, ktre s dalej rozo o- na produkty skadowe. Produktami porednimi s wic te wszystkie produkty, ktre ne s widoczne na Diagramie Struktury Produktw, oprcz produktu kocowego i produktw znajdujcych si na kracach gazi diagramu. Produkty porednie prostych, wystpuj z dwch rodzajw, ktre zdefiniowano poni ej, jako produkty integracji w jednym lub grupy produktw. jako Produkty integracji Produkt integracji to taki, wobec ktrego zajdzie potrzeba wykonania jednego lub wicej takich jak monta czy testowanie ju po wytworzeniu jego podproduktw. Z dziaa, tego powodu produkty integracji powinny zosta ukazane na Diagramie Nastpstwa Produk- a dla ka dego z nich wymagane bdzie sporzdzenie Opisu Produktu. tw 32 , Produkty integracji zaznacza si jako prostokty. Grupy produktw grupa produktw nie jest sensu , ktrego wytworzenie wymaga produktem stricto form klasyfikacji pewnej liczby dziaa. grupa produktw jest wycznie dogodn produktw. Jest to sposb pobudzenia planisty do gbszego przemylenia, jakie produkty s faktycznie potrzebne. Przykadem grupowania produktw mo e by Grupa produktw szkoleniowych, ktra sama w sobie nie jest produktem, a ktr wykorzystuje si jako punkt wyjcia do mylenia o rzeczywistych produktach, takich jak notatki dydaktyczne, notatki z wykadw, wiczenia, przerocza itd. Grupy produktw mog wystpowa Struktury Produktw, w Diagramie nie mo na ich przenosi do Diagramu ale Nastp-

32

Nale y to rozumie w ten sposb: do Diagramu Nastpstwa Produktw przeniesione zostan, z Diagramu Struktury Produktw, zarwno symbole produktw prostych, jak i symbole Produktu integracji, w skad ktrego te produkty proste wchodz. przypis tumacza.

327

PRODUCT BASED PLANNING stwa Produktw 33 . Grupy produktw Produktw w formie rwnolegobokw. przedstawia si na

PRINCE2 Diagramie Struktury

Autor Diagramu Struktury Produktw powinien stosowa bardzo jasne nazewnictwo produktw porednich, aby wskaza, gdzie chodzi o produkty integracji, a gdzie o grupy produktw. Dobr zasad jest u ycie sw grupa albo zestaw w nazwie grupy produktw, a sw zintegrowany, przetestowany czy zmontowany w nazwie produktu integracji . W Diagramie Struktury Produktw, planici mog jednoczenie umieci produkty inte- i grupy produktw. Rysunek 22.1 przedstawia przykad Diagramu Struktury gracji Produktw w odniesieniu do Dokumentu Inicjujcego Projekt (DIP). Diagram (a) ukazuje Zestawiony DIP jako produkt prosty nale cy do grupy produk- jest grupa produktw DIP. W tym przypadku do Diagramu Nastpstwa tw, jak Produktw przeniesione zostan tylko produkty proste, a nie grupy produktw. Diagram (b) ukazuje Zestawiony DIP jako produkt integracji, ktry bdzie przeniesio- Diagramu ny do Nastpstwa Produktw.
Diagram (a)
G ru p a p r o du k tw DI P

Uza sa d n ie ni e p r oj e ktu

De fi ni c ja p ro j ek tu

Stru k tu ra o rg a ni za cy jn a p ro j ek tu

Pl an Ko m u ni k ac ji T ol e ran c je

pr o j ek tu

El em e nty s te ro w an i a p ro j ek tem

Po c z tk o w e Uz as ad n i en i e Bi zn e so w e

Po c z tko w y Pl a n Pr o je ktu

Poc z tk ow y R ej es tr R yzy ka

Z e sta w io n y D I P

Diagram (b)

Z e sta w io n y D I P

Uz as ad n i en i e p r o je ktu

De fi n ic ja p r o je ktu

Str u ktu ra o rg a n iza cy j na p r oj e ktu

Pl an K om u n ik ac j i T o le ra nc je

p ro j ek tu

E le me n ty ste ro w a ni a p ro j e kte m

P oc z tko w e U zas ad n i en i e Bi zn e so w e

Po cz tk ow y Pl a n Pro j ekt u

Po cz tk o wy R e je str Ry zyk a

Rysunek 22.1. inte-

Przykad wykorzystania grup produktw oraz produktw gracji

W czasie tworzenia przez zesp Diagramu Struk tury Produktw mo e mie miejsce dys- jakie grupy produktw nale y wyr ni, tzn. jak nale y pogrupowa produkty. kusja, Je- np. efektem prac projektowych ma by komputerowy system ksigowoci, u li ytkowni- za da podziau systemu na grupy produktw, takie jak: Patnoci, Nale cy mog - oci, Ksiga Gwna itp. Dostawcy mog preferowa takie grupy produktw, n jak
33

Nale y to rozumie w ten sposb: do Diagramu Nastpstwa Produktw przeniesione zostan tylko symbole produktw prostych, a nie symbol grupy produktw, w skad ktrej te produkty proste zostay zaliczone. przypis tumacza.

32 8

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH Ekrany u ytkownika, Raporty, Bazy danych itp. Ani jeden , ani drugi podzia nie wadliwy, ale zesp projektowy musi doj do porozumienia, jaka metoda jest zostanie Diagramie Str uktury Produktw, a zatem i w caym projekcie. Przyjcie u yta w wsplnego jzyka, ktry u ywany bdzie w pr ojekcie, pomo e w budowaniu zespou.

22.4.3.

Rodzaje produktw

W PRINCE2 wystpuj dwa rodzaje produktw: produkty ktrych wytworzenie objte jest specjalistyczne, planem; produkty zarzdcze, ktre bd wymagane podczas zarzdzania projektem, a tak e przy definiowaniu i utrzymywaniu jakoci (np. Raport Okresowy, Raport Kocowy Etapu, Zagadnienia Pr ojektowe itp.). Rysunek 22.2 przedstawia jeden z wielu mo liwych Diagramw Struktury Produktw, standardowe produkty zarzdcze PRINCE2. Jakikolwiek byby rodzaj obejmujcych pro- produkty zarzdcze metodyki pozostan niezmienne i mog by wykorzystywane jektu, jak to przedstawiono lub z odpowiednimi modyfikacjami we wszystkich tak projektach. W celu umo liwienia zastosowania wikszego rozmiaru czcionki i polepszenia czytelnoci diagramu produkty dotyczce jakoci przedstawiono na osobnym diagramie 22.3. Oba schematy przypominaj planicie o produktach zarzdczych, Rysunek ktre niezbdne, a ktrych wytworzenie wymaga bdzie nakadw i bd czasu.
Pr odu k ty rz Za dc ze

34

U z a sa dn i e ni P la n y R a po rt e B i z ne s owe y

S tr uk tu or ra ni za c y j ga na

E l e me nt y s te ro wa ni a

P r oduk t y j ak o c i

P l an P r oj e k tu

P la n Eta p u

Pl a n Z e sp o u

Plan K omu ni k a cj i DIP

(rozwinito na Rysunku 22.3)

R ej e s tr R y zy k a

D zi e nn i k G ru pa da Ze zw ol e ni e K om i te tu S te r uj c e go Za

Z a o e ni a P ro je k t u

Pl a n N a dz wy c z aj n y

P l a n P rz e du gl P opr oj e k to we go

Zl e c e ni e Pr zy go tow a ni a P ro j ek t u

F orm u a R e al i z a cj i Pr oj e k tu

R a por t K o c ow y P r oj e kt u

R a por t K o c ow y E ta pu

R ap or t O k re s ow y

R a p ort z P un kt K uont ro l ne go

R a por t o D o w i a dc ze ni a c h

Z a l ec e ni a D zi a a N a s t pc zy c h

R a p ort o I s to tny c h Od c hy le n ia c h

Rysunek 22.2. zarzdczych

Diagram Struktury Produktw dla produktw

34

Jako rozwinicie w postaci DSP grupy produktw Produkty jakoci z Rysunek 22.2 przypis tumacza.

329

PRODUCT BASED PLANNING

PRINCE2

Pr oduk ty o

j ak ci

K r y te ri a A k ce pta c j i

Pl a n Ja k o c i P roj e k tu

P rodu kt y kon trol i a k oci j

R e je s tr D o wi a dcz e

D ok um e nt ac j a Za ga dni e Pr oj e kt ow y ch

Pr oduk ty kon fi gura c j i

D okum e nty ze gl du pr j a k oc i

R e j e str J a k oc i

I nne dok um e nty k ontr ol ij a k oc i

Re j e str Za ga dni e

Za ga dnie ni aPro je k towe

Opi s P y roduk tw

Za pi sy Obi e k tu K onfi gur a cj i

P l an Za r dza z K onfi gur a nia cj

Zap ros ze ni a na pr ze gl dy j a k oc i

Li s ty za str ze e pr ze gl dw j a k oc i

Li sty dz ia a st pc zy c h na pr ze gl dw ja k ci o

Rysunek 22.3. jakoci

Produkty zarzdcze dotyczce

W czasie trwania projektu powstaje wiele wersji produktw takich jak Uzasadnienie Biznesowe. Nowa wersja tego produktu mo e by utworzona na kocu ka dego etapu. Nie celowe przedstawianie wielu wersji produktu na Diagramie Struktury jest Produktw, wnosi to niczego nowego poniewa nie .

22.4.4.

Poziomy struktury produktw

Kluczem do budowy struktury produktw specjalistycznych jest wymg, aby pokazywaa planu. Planista umieszcza produkt kocowy planu na szczycie hierarchii ona zakres Diagramu Struktury Produktw. Produkt ten jest rozbijany na jego gwne produkty, ktre nastpny poziom struktury. Ka dy z tych produktw rozbijany jest nastpnie tworz na mniejsze a do osignicia odpowiedniego poziomu szczegowoci, jakiego wymaga plan. Rysunek 22.2 ukazuje jeden z mo liwych sposobw rozrysowania Diagramu Struktury Produktw, ale istniej i inne, jak choby wykresy map myli.

22.4.5.

Stadia produktu

Jeden z dylematw, jaki pojawia si przy tworzeniu Diagramu Struktur y Pr oduktw, to pytanie, czy ujmowa w niej r ne stadia/ stany Dwa przykady stadiw r produktu. nych produktw to: przygotowana zaprawa gipsowa, nao ona zaprawa gipsowa i zaprawa gipsowa po zwizaniu oraz zdemontowana maszyna, maszyna przetrans- i maszyna powtrnie zmontowana. Decyzja w tej kwestii nale y do portowana plani-Rozstrzygn trzeba przede wszystkim, czy r ne stadia/ stany produktu sty. wymagaj oddzielnych Opisw Produktu, zbiorw kryteriw jakoci i kontroli jakoci. Pierwszy z przykadw najlepiej przedstawi na Diagramie Struktury Produktw jako jeden pro- nao ona zaprawa gipsowa, a r ne stadia produktu wyrazi w postaci dukt dziaa opisanych w Okr lenie i Wspzale (PL3). W przykadzie c podprocesie maszyny, planista mo e przewidywa, e ka de stadium produktu jest e Dziaa no i dotyczcym na specyficzne, aby wymaga odrbnego Opisu Produktu, i e sensowne bdzie tyle umiesz- wszystkich trzech stadiw produktu na schemacie jako osobnych produktw. czenie In- powodem wyr niania stadiw produktu jest to, e mo e si zmienia nym odpowie33 0

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH dzialno za poszczeglne stadia, np. jedna brygada rozbiera maszyn na czci, przedsibiorstwo specjalizujce si w transporcie przemieszcza maszyn do punktu docelowe- z powrotem j skada. Ka da z tych brygad mo e wymaga odrbnego go, a inna Opisu Produktu.

22.4.6.

Produkty zewn

trzne

Jak wy ej wspomniano, Diagram Struktury Produktw specjalistycznych powinien odzwierciedla zakres zwizanego z ni planu. W Diagramie Struktury Produktw u miesz- nie tylko produkty dostarczane w ramach projektu, ale tak e wszelkie cza si 35 . produkty ju istniejce albo pochodzce z zewntrznych Kierownik Projektu nie jest rde odpowiedzialny za wytworzenie produktw zewntrznych, cho produkty te s nieodzowne jeli ma osign stawiane przed nim cele. Plan musi zatem w projekcie, obejmowa wszelkie produkty zewntrzne, ktre s niezbdne do realizacji celw projektu, oraz odpowiednie uzale nienia od tych produktw zewntrznych. Do wyr nienia produktw zewntrznych nale y u ywa odrbnego symbolu. W niniej- podrczniku do oznaczenia produktw zewntrznych zarwno w szym Diagramie Produktw, jak i w Diagramie Nastpstwa Produktw u yto elips. Nale Struktury yauwa y, e przedstawia si tak produkt, a nie jego rdo. Jeli plan wymaga z rozkadupocigw lokalnych, produktem zewntrznym bdzie Rozkad jazdy jazdy pocigw, a nie zwizany z tym przewonik. W przedstawionym w dalszej czci tego r ozdziau prostym przykadzie, dotyczcym zorganizowania konferencji. Diagram Struktury Produktw dla produktw specjalistycz- Rysunek 22.5. Produkt Wybrany temat jest produktem zewntrznym, nych pokazuje bo chwili rozpoczcia projektu, temat konferencji by ju w ustalony.

22.4.7.

Kryt eria oceny ci jako Czy zidentyfikowano wszystkie produkty specjalistyczne, ktre s nieodzowne dla zaspokojenia potrzeb biznesu? Czy zidentyfikowano wszystkie produkty biznesowe, ktre musz by wytworzoneprojektu na potrzeby audytu lub Nadzoru Projektu oraz wydawania w trakcie wytycznych i sterowania? Czy wymagany plan zale y od produktw, ktre nie nale do zakresu projektu (produkty zewntrzne)? Jeli tak, to czy wszystkie je zidentyfikowano? Czy jasno zdefiniowano i uzgodniono odpowiedzialno za pozyskanie produktw zewntrznych? W jaki sposb zewntrznych? bd monitorowane postpy prac, dotyczce produktw

35

Skadaj si one na kocowy produkt (rezultat wynik) projektu lub warunkuj jego uzyskanie przypis tumacza.

331

PRODUCT BASED PLANNING Wskazwki i rady

Produkty objte planem to nie tylko te, ktre zostan wytworzone w ramach planu, ale wszelkie produkty zewntrzne, ktrych dostarczenie bdzie nieodzowne do wykonania zaplanowanych prac. Jeli produkt uwzgldniony na Diagramie Struktury Produktw jest rozkadany dalej na produkty czstkowe, nale y zapewni spjno treci opisu jego skadu w Opisie Produktu ze sposobem, w jaki produkt zosta rozo ony na Diagramie Struktury Produktw. Konieczno dostarczenia lub pozyskania ka dego z produktw zewntrznych jest uzale nieniem dla projektu, dlatego stanowi potencjalne zagro enie. Produkty z wy szych poziomw DSP musz by w peni okrelone przez produkty ni szego poziomu, z ktrymi s powizane. Rozo enie produktu poredniego na produkty ni szego poziomu oznacza, e Ten produkt skada si z nastpujcych produktw, i tylko z nich. Nie nale y tego rozumie, e Po tym produkcie wystpuj takie produkty. Niewaciwe jest rozkadanie produktu na tylko jeden produkt prosty. Nie na tym polega dekompozycja. Sprowadzaoby si to do powiedzenia: Dany produkt skada si tylko z jednego produktu, co oznacza, e w tym przypadku dekompozycja jest zbyteczna. Nie mo na u ywa strzaek w Diagramie Struktury Produktw. Ukad produktw na tym diagramie w aden sposb nie stanowi o ich kolejnoci. Odgazienia w Diagramach Struktury Produktw nie powinny schodzi ni ej ni do poziomu hierarchii bezporednio ni szego. Jeli na rysunku nie ma wystarczajco du o miejsca, aby pokaza struktur horyzontalnie, mo na j pokaza w ukadzie pionowym, ale jedynie w sposb, ktry przedstawia Rysunek 22.4 (a). Ukad pokazany na przykadzie (b) sugerowaby, e jest to szereg rozkadw produktw typu jeden-na-jeden, co byoby niewaciwe.
(a) (b)
P ro d u kt w y sze g o p o zi o m u Pr o d u kt w y sze g o p o zi o m u

PRINCE2

Pro d u k t n i s ze go a

p o zi o mu

P ro d u kt n i sz eg o a

p o zio m u

Pro d u k t n i s zeg o b

p o zi o mu

P ro d u kt n i sz eg o p oz io m u b

Pro d u k t n i s ze go c

p o zi o mu

Pro d u kt n i s zeg o p o zi om u c

Pr od u k t n i s ze g o p o zi o mu d

P ro d u kt n i sz eg o p oz io m u d

Poprawnie

le

Rysunek 22.4. pionowym

Sposb rysowania struktury produktw w ukadzie

33 2

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH

22.5.

Sporz dzanie Opisu Produktu

Jak wy ej wspomniano, w ka dym projekcie planowanie oparte na produktach powinno si od sporzdzenia Opisu Produktu dla produktu kocowego. Zaleca si tak zaczyna eporzdzanie Opisu Produktu dla ka dego z wa niejszych produktw prostych i ka s dego produktu integracji wystpujcych na Diagramie Struktury Produktw i Diagramie Nastpstwa Produktw. Sporzdzenie Opisu Produktw dla grup produktw nie jest obowizkowe. Opis Produktu powinien powsta tak szybko, jak to mo liwe, po stwierdzeniu potrzeby jego budowy. Pocztkowo mo e to by jedynie szkielet zawier ajcy nieco wicej informacji ni nazw i identyfikator. Bdzie on doprecyzowywany i poprawiany, gdy pro- zostanie lepiej rozpoznany oraz po wykonaniu kolejnych krokw planowania. dukt Opis Produktu powinien sta si obiektem odniesienia, gdy plan, w ktrym przewidziano jego wytworzenie, zostanie uznany za obiekt odniesienia. Jeli pniej produkt ulegnie zmia-rwnie Opis Produktu musi zosta objty procedur sterowania nie, zmianami.

22.5.1.

Zawarto Opisu Produktu

Przykad Opisu Produktu dla jednego z produktw z prostego przykadu zorganizowania konferencji przedstawia Rysunek 22.6. Szczegy na temat zawartoci Opisu Produktu zawiera Dodatek Zarysy Opisw A Produkt . w Chocia odpowiedzialno za sporzdzenie Opisw Produktu spoczywa formalnie na Kierowniku Projektu lub Kierowniku uzasadnione jest wczenie do prac Zespou, fachow, a tak e przyszych u ytkownikw rozpatrywanego produktu. Od osb z wiedz tych ostatnich wymaga si bdzie na pewno okrelenia jakoci, ktrej bd oczekiwali od produktu.

22.5.2.

Kryt eria oceny ci jako Czy produkty zostay jasno i jednoznacznie okrelone? Czy wymienione zostay wszystkie rodzaje kontr oli jakoci produktw, ktre pozwol na stwierdzenie, e osignito ustalone kr yteria jakoci? Czy istniej centralnie przechowywane standardy, ktre mo na wskaza w opisie,dojdzie do okrelania kryteriw jakoci, i czy je gdy zastosowano? Czy w przypadku konfliktu midzy standardami klienta i dostawcy udao si osign sensowne porozumienie bd kompromis? Czy u ytkownik lub klient daj wprowadzenia jakich szczeglnych standardw? Czy w sporzdzaniu Opisu Produktu wziy udzia waciwe osoby? Czy dostpne s odpowiednie listy kontrolne, wspomagajce sprawdzanie produktw?

333

PRODUCT BASED PLANNING Wskazwki i rady

Wypenienie w Opisie Produktu sekcji Przeznaczenie i Skad pomaga wyjani, jakie nakady pracy bd potrzebne do wytworzenia produktu. Mo e to by z du pomoc w szacowaniu. Dodatek A Zarysy Opisw Produktw zawiera szkice opisw wszystkich produktw zarzdczych PRINCE2. Nie powinno by konieczne ich ponowne definiowanie dla ka dego projektu, chyba e bd to ich lokalne zmiany. Wykonanie dobrych Opisw Produktu to przedsiwzicie wcale niebahe! Szczeglnie dokadnego przemylenia wymagaj kryteria jakoci, ktre umo liwiaj odr nienie produktw akceptowalnych od niemo liwych do zaakceptowania. Podstawowe znaczenie ma wczenie u ytkownika lub klienta do sporzdzania Opisw Produktw, okrelenia kryteriw jakoci i zdecydowania, w jaki sposb odbywa si bdzie sprawdzenie zgodnoci produktu z tymi kryteriami. Testem na to, czy kryteria jakoci zostay ustalone, jest prba znalezienia odpowiedzi na pytanie: Po czym poznam, czy prace nad produktem zostay ukoczone, czy przeciwnie tylko wstrzymane? Sporzdzenie listy skadnikw produktu mo e czsto uwiadomi planicie, jakie jeszcze inne produkty s niezbdne. Czstokro wytworzenie takich samych produktw jest przedmiotem wielu planw. Mo na tworzy standardowe Opisy Produktw, by mc je wykorzysta w wielu planach. Czy istniej standardy sporzdzania list kontrolnych, ktre mo na wykorzysta? Nie nale y prbowa zastpi szczegowej specyfikacji wymaga Opisem Produktu! Jeli kryteria jakoci zostay uzgodnione z klientem, mo e to pomc w ostatecznej akceptacji produktu. Jeli Opisy Produktu wykorzystywane s jako dokumenty sterowania, mo na uzupeni je o dodatkowe informacje, takie jak szacowane i faktyczne terminy czy te nakady. Ustalenie, kto dokona akceptacji konkretnego produktu, a jednoczenie zapewnienie, e te same osoby wezm udzia w sporzdzaniu i uzgodnieniu Opisu Produktu, mo e ograniczy potencjalne pole konfliktu w dalszych etapach realizacji planu. Przy definiowaniu jakoci, a szczeglnie wtedy, gdy zgodno z przyjtymi standardami jest czci Kryteriw Akceptacji, nale y zabiega o wsparcie ze strony specjalisty ds. jakoci . Jeli produkt jest przedmiotem zmiany, towarzyszcy mu Opis Produktu musi rwnie zosta zweryfikowany pod ktem wszelkich koniecznych uaktualnie.

PRINCE2

33 4

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH

22.6.

Sporz dzanie Diagramu Nast

pstwa Produktw

Ostatnim krokiem techniki Planowanie oparte na produktach jest sporzdzenie Diagramu Produktw Nastpstwa (DNP). Diagram Nastpstwa Produktw budowany jest na podstawie Diagramu Struktury Produktw i ukazuje kolejno, w jakiej planowane produkty maj by wytworzone. Poprzedza on identyfikacj dziaa, przeprowadzan w ramach podprocesu Okr lenie i Wspzale (PL3) . c e Dziaa no i Rysunek 22.7 ukazuje Diagram Nastpstwa Produktw dla prostego przykadu projektu zorganizowania konferencji, przytoczonego dalej w niniejszym rozdziale.

22.6.1.

Tworzenie Diagramu Nast

pstwa Produktw

Diagram Nastpstwa Produktw wymaga bardzo niewielu symboli. Ka dy produkt, ktryby wytworzony w ramach planu, jest oznaczony prostoktem. Strzaki cz ma prostokty ukazujc kolejno, w jakiej produkty maj by wytworzone. Wszelkie produkty, istniej czy te s poza kontrol planisty, musz zosta jasno wyr nione ktre ju przy u yciu innego rodzaju oznaczenia w podrczniku zastosowano elips. Diagram rozpoczyna si od produktw, ktre dostpne s na pocztku planu (wiele z nich to dokumenty, takie jak listy wymaga czy dokumentacja projektowa), a koczy na 36 kocowym(-wych) produkcie(-tach) przygotowywanego . planu W trakcie tworzenia Diagramu Nastpstwa Produktw mog si ujawni nowe produkty, ktre bd potrzebne. Powinny one zosta dodane do Diagramu Struktury Produktw sporzdzi dla nich Opisy i nale y Produktw. Chocia odpowiedzialno za wykonanie Diagramu Nastpstwa Produktw spoczywa na Kierowniku Projektu lub Kierowniku uzasadnione jest wczenie do jego Zespou,osb, ktre wytwarzaj lub przyczyniajtwo- do wytworzenia produktw rzenia si objtych planem.

22.6.2.

Kryt eria oceny ci jako Od ktrych innym produktw zale ny jest ka dy z produktw? Czy ktry z produktw zale y od produktu, ktrego wytworzenie nie wchodzi tego planu? w zakres Ktre z produktw wytwarzane bd rwnoczenie? Czy wykryto jakie nowe bd dotd niezidentyfikowane produkty?

Wskazwki i rady
Na poziomie projektu zale noci midzy produktami bd w wikszoci przypadkw bardzo oglnikowe, np. nie wszystkie skadniki Produktu gwnego Nr 1 musz by wytworzone, zanim rozpocznie si wytwarzanie jakich skadnikw Produktu gwnego Nr 2. D enie do rozo enia produktw gwnych na produkty czstkowe, aby dokadniej i peniej zidentyfikowa dziaania, bdzie zwykle prowadzi do zawikania diagramu. Le36

Poziomu planu zwizanego z diagramem przypis tumacza.

335

PRODUCT BASED PLANNING

piej zadowoli si w tej w tej fazie bardzo oglnymi zale nociami, a uszczegowi je na poziomie Planu Etapu. Najprostszy sposb na zbudowanie Diagramu Nastpstwa Produktw to uo enie wszystkich produktw specjalistycznych we waciwej kolejnoci, a nastpnie dodanie w odpowiednich punktach diagramu wszelkich niezbdnych produktw zarzdczych. Czasem atwiej jest budowa diagram, cofajc si od produktu kocowego i zadajc sobie pytanie: Jakie produkty s potrzebne do wytworzenia tego produktu?. Karteczki samoprzylepne umieszczane na tablicy mog by skutecznym sposobem budowania szczeglnie w przypadku, gdy przewiduje si wiele Diagramu Nastpstwa Produktw modyfikacji i poprawek. Dobrym sposobem na rozpoczcie okrelania kolejnoci produktw specjalistycznych jest metoda gra-d. Kocowy produkt planu umieszcza si na dole kartki papieru, a wszystkie produkty, ktre warunkuj rozpoczcie prac, na grze kartki. Nastpnie wybiera si kolejny produkt z listy i konfrontuje go z ka dym z produktw, znajdujcych si na diagramie, w celu stwierdzenia, czy jest jaka szczeglna zale no midzy nimi. Nale y tak postpi ze wszystkimi produktami. Uzyskan informacj wykorzystuje si do powizania wszystkich produktw w ich waciwej kolejnoci poczynajc od produktw wystpujcych na samym pocztku (na grze kartki), a koczc na produkcie kocowym. Jeli wydawane przez Komitet Sterujcy zezwolenia na kontynuowanie prac, s wymienione na licie produktw jako produkty zarzdcze, ich odpowiednie umieszczenie na diagramie poka e miejsca, w ktrych powinny koczy si etapy, jeli dotd jeszcze tego nie ustalono. W rubryce Pochodzenie / rda danych Opisu Produktu znale mo na u yteczne informacje o zale nociach dla danego produktu. Kluczowym pytaniem, jakie trzeba zada, jest pytanie: Skd uzyska te informacje?

PRINCE2

22.7.

Przykad planowania opartego na produktach

Rysunki 22.5, 22.6 i 22.7 ilustruj przykad planowania opartego na produktach. Celem niezwykle prostego przykadu jest przedstawienie r nych krokw i tego skadnikw techniki, unikajc wszelkiej zo onoci, ktr mgby nie ze sob pr zedmiot planu. Po- szy kr tki scenariusz wyjania okolicznoci zwizane z tym ni przykadem.

22.7.1.

Prosty przykad scenariusz

Trzeba zrealizowa projekt, ktry bdzie polega na zorganizowaniu i przeprowadzeniu od 75 do 95 uczestnikw. Wymagany termin i wybrany temat konferencji dla konferencji podano planicie. Temat obejmuje uaktualnienie stanu wiedzy przedstawicieli okrelonej grupy zawodowej w zakresie wie o wprowadzonych zmian w procedurach i standardach ich profesjonalnej dziaalnoci. Nale y znale miejsce, w ktrym odbdzie si konferencja, zbada jego dostpno, wyposa enie i ceny, a nastpnie dokona rezerwacji. Wszyscy uczestnicy bd nale eli do tej samej grupy zawodowej. Lista ich adresw poczto-jest znana i mo na j wykorzysta. Nale y dokona wyboru odpowiednich wych prele33 6

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH gentw, nawiza z nimi kontakt i zawrze umowy. Po zakontraktowaniu prelegentw trzeba bdzie szczegowy rozkad zaj (agenda) i program k onferencji. opracowa Potrzebnych bdzie sto pakietw z materiaami dla uczestnikw, okadka pakietw ma sygnalizowa temat konferencji. Pakiet powinien zawiera wydrukowany porzdek dnia, odzwierciedlajcy uzgodniony program kon ferencji, kopie slajdw oraz notatek wykorzystywanych przez prelegentw, a tak e opart na programie ankiet oceniajc, ktra pozwoli na zebranie uwag uczestnikw. Nale y opracowa zasady zgaszania uczestnic- chtnych do wzicia udziau w konferencji. Zasady te powinny by twa przez opracowane, program musi by uzgodniony, a miejsce konferencji wybrane i zarezerwowane, za- zostan rozesane poczt materiay informacyjne. Po zarezerwowaniu miejsca nim konfe- na podstawie programu konferencji nale y przygotowa informacj dla prasy. rencji, Na- spodziewa si jeszcze pewnej liczby zgosze w rezultacie takiej publikacji. le y Lista uczestnictwa zostanie uaktualniona na podstawie zgosze napywajcych po opublikowaniu informacji o konferencji w prasie i po r ozesaniu materiaw informacyjnych poczt. Bdzie tak e trzeba zatrudni pomocniczych pracownikw obsugi na dzie konferen- na podstawie ostatecznej listy cji uczestnikw.
Z o rg a n iz ow a n a k on fe re n cj a

Us tal o n y ter m in ko n fer en c ji

Gr u p pr ao d uk t w o ka li za cj a L

G ru p a p ro d u kt w zes tn i cy Uc

G ru p a p ro d u kt w ek la m R a

Sko m p l eto w a nyak ie t u cze stn i p ka

G ru p a p ro d u kt wrg a n iz ac ja O

L i sta w ym ag a l a l o ka li za cj d i o nf ere n cj i k

L is ta mo li w yc h ok al i za cj l i

M ate ri a i n fo rm ac yj n y y sy a n w y o cz t p

I n fo rm ac ja d l a p ra sy

U sta l o ny tem at ko n fe re n cj i

Za ko n tr ak to w an i na dz ie n fer en c ji ko pr ac o w n ic y s u g ob i

U st al o n y r o gr am p I n fo rm a cj e o l o ka li za cj ac h W yb ra n a za re ze rw o w an a i lo k al i za cj a k o n fer en cj i

G ru p a p ro d u kt w Pr el eg e n ci

L is ta a d res o w a

Op r ac o w an y te m sys pr zyj m o w an i a o s ze zg

O sta tec zn a li s ta uc ze stn i k w

Z g o s zen i u a stn i c tw a cze

L is ta p ot en cj a ln y chrel e g en t w p

Z ap r o sze n ia dl a re l eg en t w p

Z ak on tr ak to w an i rel e g en ci p

O k a dk i ate ri a w m

W yd ru k o w an y or z d e k p d ni a

W y dr u ko w a nela j d s y n ot atk i i

An k ie tace ni a j ca o ko n fe ren c j

Rysunek 22.5. Produktw

Zorganizowanie konferencji Diagram Struktury

337

PRODUCT BASED PLANNING

PRINCE2

Nazwa produktu Przeznaczenie / Cel Skad

Lista wymaga dla lokalizacji konferencji. Okrelenie wszelkich warunkw, ktre winny by spenione przez lokalizacj, aby bya ona waciwa dla konferencji. Termin, w ktrym lokalizacja powinna by dostpna. Terminy rozpoczcia i zakoczenia. Spodziewana liczba uczestnikw. Wymagania dotyczce pomieszcze. Wymagane wyposa enie. Wymagania dotyczce poczstunku i/lub napojw. Warunki parkowania. Lista adresowa. Ustalony termin konferencji. Dane i informacje pochodzce z poprzednich konferencji. Listy wymaga z poprzednich konferencji. Wydrukowana lista z nagwkami jak w w/w wierszu Skad. Organizator konferencji. Lista musi obejmowa wszystkie wymogi, ktre musi spenia miejsce konferencji. Lista musi wyranie oddzieli wymogi niezbdne od po danych. Lista musi obejmowa wszystkie punkty wymienione w pozycji Skad. Ka dy wymg powinien by mierzalny. Jedna kontrola sprawdzajca, czy lista zawiera wszystkie punkty wymienione w pozycji Skad. Kontrola tekstu z pomoc edytora i przez niezale nego testera. Porwnanie z listami wymaga poprzednich konferencji. Porwnanie z listami ofert z centrw konferencyjnych. Lista musi uwzgldni zale no jakoci i kosztw, z naciskiem na jako, w granicach do 10% r nicy w kosztach. Tam, gdzie to mo liwe, nale y wyznaczy obszar tolerancji dla poszczeglnych parametrw. Umiejtno korekty tekstu. Najlepiej osoba, ktra organizowaa ju podobn konferencj lub etatowy organizator konferencji z sieci hoteli.

Pochodzenie /

rdo

Format / Wygl Przydzielono

Kryteria jako ci

Metoda kontroli jako ci

Tolerancja dla jako ci

Kwalifikacje testerw i/lub wymagane osoby

Rysunek 22.6. Produktu

Zorganizowanie konferencji przykad Opisu

33 8

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH

Ustalony temat konferencji Lista wymaga dla lokalizacji konferencji

Ustalony termin konferencji

Lista potencjalnych prelegentw

Zaproszenia dla prelegentw

Lista mo liwych lokalizacji

Opracowany system przyjmowania zgosze

Informacje o lokalizacjach Zakontraktowani prelegenci Okadki materiaw Ustalony program konferencji Wybrana i zakontraktowana lokalizacja Lista adresowa

Wydrukowane slajdy i notatki

Materia informacyjny wysany poczt Wydrukowany porz dek dnia Ankieta oceniaj ca konferencj

Informacja dla prasy Zgoszenia uczestnictwa

Skompletowany pakiet uczestnika Ostateczna lista uczestnikw Zakontraktowani na dzie konferencji pracownicy obsugi

Zorganizowana konferencja

Rysunek 22.7. Produktw

Zorganizowanie konferencji Diagram Nastpstwa

22.8.

Inne przykady

Podane zostan teraz dwa kolejne przykady dostarczania produktw. Pierwszy dotyczy Planu Projektu. Rysunek 22.8 przedstawia Diagram Struktury Produktw, poziomu za Rysunek 22.9 Diagram Nastpstwa Produktw. Drugi przykad dotyczy Planu Etapu pierwszego tego projektu. Rysunek 22.10 przedstawia Diagram Struktury Produktw, a Rysunek 22.11 Diagram Nastpstwa Produktw.

339

PRODUCT BASED PLANNING

PRINCE2

Produkt w peni przygotowany do wdro enia

Grupa impulsw wyzwalaj cych

Grupa produktw kupowanych

Grupa produktw szkoleniowych

Grupa produktw wdro eniowych

Wymogi biznesowe

Kryteria pomiarowe

Strategia szkole

Materiay szkoleniowe

Przeszkoleni u ytkownicy

Przygotowane rodowisko

Zainstalowany produkt

Przetestowany produkt

Grupa dostawcy

Informacja o procesach zakupu

Zaproszenie do przetargu

Grupa produktw oceny

Opracowana strategia testowania

Produkt zaakceptowany

Raporty oceny produktu

Oceniony produkt

Wybrany produkt

Podpisana umowa

Oferty

Informacja o dostawcach

Lista dostawcw

Rysunek 22.8. Projektu

Diagram Struktury Produktw poziom Planu

34 0

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH

Wymogi biznesowe Informacja o procesach zakupu Zaproszenie do przetargu

Informacja o dostawcach

Kryteria pomiarowe

Lista dostawcw

Oferty

Oceniony produkt Strategia szkole

Wybrany produkt

Raporty oceny produkt u

Materiay szkoleniowe

Podpisana umowa Opracowana strategia testowania

Przygotowane Przeszkoleni u ytkownicy

rodowisko

Zainstalowany produkt

Produkt zaakceptowany

Przetestowany produkt

Produkt w peni przygotowany do wdro enia

Rysunek 22.9. Projektu

Diagram Nastpstwa Produktw poziom Planu

341

PRODUCT BASED PLANNING

PRINCE2

Zaproszenie do przetargu

Grupa produktw Wymogi biznesowe

Informacja o procesach zakupu

Grupa produktw Dostawcy

Grupa produktw Przetarg

Grupa produktw Pomiar

Odpowiedzi na zapytania

Zapytania Arkusz ocen

Kryteria selekcji

Lista dostawcw

Wybrani dostawcy

Informacja o dostawcach

Szablon odpowiedzi

Zapytanie o informacj

Standardowe warunki i wymagania

Definicja wymaga

Obszary oddziaywania

Specyfikacja potrzeb

Warianty rozwi za

Rekomendacje

Rysunek 22.10. Etapu

Diagram Struktury Produktw poziom Planu

34 2

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH

Obszary oddziaywania Informacja o dostawcach

Specyfikacja potrzeb Informacja o procesach zakupu

Warianty rozw i za

Lista dostawcw

Rekomendacje

Zapytania

Odpowiedzi na zapytania

Definicja wymaga

Dostawcy w ybrani

Kryteria selekcji

Zapytanie o informacj Standardowe warunki i w ymagania

Arkusz ocen

Szablon odpowiedzi

Zaproszenie do przetargu

Rysunek 22.11. Etapu

Diagram Nastpstwa Produktw - poziom Planu

22.9.

Wytyczne do opracowania planu opartego na produktach

Uwagi oglne 1. Wytworzenie ka dego z czterech produktw planowania opartego produktach bna dzie prawdopodobnie procesem iteracyjnym. W przypadku Opisw Produktu (z wyjtkiem produktu kocowego) znaczy to, e na pocztku nie trzeba zanotowa niczego wicej poza nazw produktu i pierwsz przymiark opisu jego przeznaczenia. 343

PRODUCT BASED PLANNING

PRINCE2

Dlatego w opisanych poni ej krokach postpowania zwrot sporzdzi opis ( stoso-np. w wyra eniu sporzdzi Opis Produktu) nale y interpretowa jako wany rozpoczcie opisywania a nastpnie uzupenianie go tak szczegowo, jak to celowe, szybko, jak to i tak dogodne. 2. Procesy mylowe s r ne u r nych osb, wic opisane poni ej kroki postpowaniatraktowa jedynie jako sugerowan kolejno postpowania, ktra mo e nale y by przyjcia jedynie dla niektrych osb (aczkolwiek r ekomenduje si j jako do punkt wyjcia dla wszystkich). Niektre osoby mog wypracowa swj wasny sposb wytwarzania produktw Licz si w kocu rezultaty, a nie specjalistycznych. proces, ktry doprowadzi do ich osignicia. Krok sporz dzenie Opisu Produktu ko cowego

1. Sporzd Opis Produktu dla produktu kocowego. Nale y doo y wszelkich stara, aby ju od pocztku uczyni ten Opis Produktu mo liwie kompletnym. Kroki sporz dzania Diagramu Struktury Produktw

1. Posugujc si zawartoci sekcji Skad Opisu Produktu dla produktu kocowego y utworzy dwa grne poziomy Diagramu Struktury nale Produktw. Uwaga: Kocowy produkt (wynik, rezultat) znajdujcy si na szczycie hierarchii nie tr aktowany jako osobny jest poziom. 2. Rozwa y, co u ytkownicy produktu kocowego bd musieli dostarczy, aby u mo liwi wykonawcy wytworzenie produktu kocowego. Czy prowadzi to do zidentyfikowania dodatkowych produktw (np. specyfikacji)? 3. Przyjrze si ka demu z produktw na drugim poziomie Diagramu Struktury Pro- duktw odpowiadajc sobie na pytania: Z czego wywodzi si ten produkt? Czy uwzgldniono wszystko, co nale y wytworzy? Czy jest wszystko, co bdzie potrzebne, lub czy stwierdza si potrzeb takiego produktu, jak grupa produktw przygotowawczych? 4. Przeanalizowa sekcj Pochodzenie / r do Opisu Produktu dla produktu kocowego pod ktem potrzebnych produktw zewntrznych (istniejcych ju wczeniej). 5. Jeli plan wy maga wikszej szczegowoci, rozo y produkty drugiego poziomu diagramu na pr odukty poziomu trzeciego. Podzia produktw nale y kontynuowa, poziomy diagramu, a osignie si produkty, ktre bdzie mo tworzc dalsze na kontrolowa na poziomie odpowiednim do przeznaczenia planu. 6. Oceni, czy do wytworzenia ktregokolwiek ze wie o zidentyfikowanych produktw niezbdny jest jaki produkt zewntrzny? 7. Oceni, czy ktry z nowych produktw nie wymaga jakich dodatkowych produk- ktre powinny by wytworzone lub zakupione w ramach planowanych tw, prac? 8. Jeli liczba produktw na poziomie drugim lub na poziomach ni szych bdzie zbyt du a, nale y zastanowi si, czy nie poczy ich w jedn lub wicej grup produktw.

34 4

PRINCE2 PLANOWANIE OPARTE NA PRODUKTACH Kroki sporz dzania Opisw Produktw

1. Sporzdzi Opis Produktu dla ka dego produktu integracji i ka dego produktu pro- stego. 2. Sprawdzi, czy z sekcji Skad i Pochodzenie / rdo Opisu Produktu nie wyni-ka potrzeba jakich dodatkowych produktw, ktre powinny by dodane do Diagramu Struktury Produktw. 3. Sprawdzi, wsplnie z u czy w sekcji Cel / Przeznaczenie ytkownikami, nie znajduj si jakie ukryte rodzaje przeznaczenia, ktre Opisu Produktu mogyby sob wymagania jakich dodatkowych produktw. nie ze 4. Zapewni, by kryteria jakoci byy mierzalne oraz to czy, o ile zostan osignite, pozwol zagwarantowa, e produkt odpowiada bdzie ka demu wy mienionemu jego przeznaczeniu. Kroki sporz dzania Diagramu Nast pstwa Produktw

1. Umieci produkt kocowy na kocu Diagramu Nastpstwa Produktw. 2. Ustali, ktre produkty musz by gotowe jako przedostatnie, tzn. zanim bdzie g by skompletowany produkt kocowy, i umieci je bezporednio przed m produktem kocowym. 3. Biorc pod uwag te przedostatnie pr odukty, umieci przed nimi te produkty po- chodzce z Diagramu Struktury Produktw, ktre bd potrzebne bezporednio przed skompletowaniem przedostatnich produktw. 4. Umieci na pocztku diagramu wszystkie ju istniejce produkty zewntrzne. 5. Doda produkty, ktre powinny nastpowa bezporednio po tych ju istniejcych produktach zewntrznych. 6. Na pocztku diagramu umieci wszelkie inne produkty, ktrych wytworzenie si planuje, a ktre nie wymagaj adnych poprzednikw. 7. Sprawdzi, czy wszystkie produkty, ktre znajduj na pocztku diagramu, nie wy- magaj uprzedniej obecnoci jakich nieujawnionych dotd produktw. Doda je do tworzonego diagramu oraz do Diagramu Struktury Produktw. 8. Zestawiajc ze sob parami te produkty na Diagramie Struktury Produktw, ktre dotd nie zostay ulokowane, rozstrzygn, jaka jest (jeli wystpuje) ich wzajemna kolejno. 9. Zestawiajc tak wyr nione pary z produktami, ktre zostay ju przedstawione na Diagramie Nastpstwa Produktw, rozstrzygn, jaka jest kolejno jednych wzgl- ugich. dem dr 10. Sprawdzi, czy na Diagramie Struktury Produktw nie pozostay jakie produkty zewntrzne, ktrych nie przeniesiono do Diagramu Nastpstwa Produktw, i spraw- ktre produkty w planie tych produktw dzi, potrzebuj. 345

PRODUCT BASED PLANNING

PRINCE2

11. Sprawdzi, czy wszystkie produkty integracji zostay umieszczone bezporednio po produktach wchodzcych w ich skad. 12. Upewni si, e symbol adnej grupy produktw nie zosta przeniesiony do Diagra- Nastpstwa Produktw. mu 13. Sprawdzi kolejno ka dy produkt znajdujcy na Diagramie Nastpstwa Produktw, z innych cie ek na diagramie, pod ktem ewentualnych wspzale z ka d noci. 14. Sprawdzi, czy istnieje na Diagramie Nastpstwa Produktw produkt zale ny od produktu, ktrego brak na Diagramie Struktury Produktw. Nale y uzupeni oby- diagramy. Czy w stosunku do planu jest to produkt zewntrzny, czy dwa wewntrz- wymaga on sporzdzenia Opisu ny? Czy Produktu? 15. Sprawdzi, czy wszystkie zale noci pomidzy produktami odwzorowane zostay za po moc strzaek. 16. Sprawdzi zgodno nazw produktw na Diagramie Struktury Produktw, na Dia- gramie Nastpstwa Produktw i w Opisach Produktw. 17. Sprawdzi ka dy produkt umieszczony na Diagr amie Nastpstwa Produktw, aby upewni si, e pokazano jego zale noci od wszystkich produktw, ktrych istnie- wymaga. nia on Jeli pr ojekt jest podzielony na kilka etapw, produkty dla ka dego z etapw s wybierane z Diagramu Struktury Produktw projektu, aby zbudowa Diagram Struktury Produktw danego etapu. Mo e on by rozbudowany o kolejne poziomy szczegowoci i w ten sposb dodane s produkty konieczne do tego, aby uzyska stopie szczegowoci niezbdny dla Planu Etapu. Nale y zwrci uwag na to, by u ywa tych samych nazw na diagramach zwizanych z Planami Etapw i diagramach u ytych w Planie Projektu. Tworzenie diagramw zwizanych z Planami Etapw mo e prowadzi do przemyle, ktre wymaga bd dalszej modyfikacji diagramw zwizanych z Planem Projektu zachowania spjnoci midzy w celu nimi.

34 6

23.

TE C HNI K A S TE ROWA NI E ZM I AN AM I
(CHANGE CONTROL TECHNIQUE)

Ten rozdzia traktuje o sterowaniu zmianami produktw specjalistycznych, a nie produktw zarzdczych. Wa ne s dwie nastpujce uwagi: Jeli produkt ma by zmieniony, nale y sprawdzi Opis Produktu pod ktem wpr owadzenia w nim wszelkich koniecznych zmian. Kiedy produkt zostanie ju zatwierdzony, Kierownik Projektu nie powinien zezwala na adne dziaania, ktre by go zmieniy bez zgody Komitetu Sterujcego. Program lub organizacja mog posiada swoje wasne procedury i formularze do stero- zmianami. Nie stanowi to problemu, dopki ich kluczowe punkty s zgodne z wania podejciem opisanym szczegowo w tym rozdziale. Tym, ktrzy nie posiadaj obowizkowej procedury sterowania zmianami, poni ej zaproponowane postpowanie zapewni, e zmiany w trakcie projektu bd sterowane.

23.1.

Kroki w sterowaniu zmianami

Wszystkie zmiany traktuje si jako Zagadnienia Projektowe i zarzdza nimi przy zastosowaniu tej samej techniki sterowania zmianami. Nale y przeczyta Rozdzia Stero 20 wanie , gdy wi e si on z t zmianami technik. Zmianami mog by: wniosek o zmian ustale odnonie tego, co projekt ma dostarczy, np. specyfikacji (Wniosek wymaga o Wprowadzenie Zmiany); sugestia ulepszenia jednego lub wicej produktw projektu (Wniosek o Wprowadzenie Zmiany) ; zapis jakiego bie cego lub przewidywanego niepowodzenia w sprostaniu uzgodnionym wymaganiom . ( Odstpstwo) Rysunek 23.1 przedstawia kroki zwizane z wychwytywaniem Zagadnie Projektowych, a nastpnie zarzdzaniem tymi spord nich, ktre dotycz zmian, a do ich rozwizania.

23.1.1.

Rejestr Zagadnie

Bez wzgldu na rodzaj, ka de zagadnienie jest rejestrowane jako Zagadnienie Projektowe Zagadnie. Sugerowana zawarto takiego rejestru jest podana w Dodatku w Rejestrze Aarysy Z opisw . Zagadnieniu nadaje si niepowtarzalny numer, wpisuje produktw zgoszenia oraz jego dat status.

347

CHANGE CONTROL TECHNIQUE

PRINCE2

SE3

Nowe zagadnienie projektowe

Rejestracja

Rejestr Zagadnie

Informacja zwrotna dla autora

Analiza wpywu SE4 Ponowna ocena priorytetw SE7 Podejmowanie Dziaa Koryguj cych

W granicach tolerancji ?

N SE8 Przekazywanie Zagadnie Projektowych Raport o Istotnych Odchyleniach ZS4 Podejmowanie Decyzji Dora nych

Wdro enie zmiany SE8 Przekazywanie Zagadnie Projektowych ZE6 Plan Nadzwyczajny ZS3 Zezwolenie na Realizacj Planu Etapu Planu Nadzwyczajnego lub

Odrzuci Usun przyczyn W zawieszeniu

Rysunek 23.1. zmianami

Kroki techniki Ster owanie

Okre lenie priorytetu Ka de Zagadnienie Projektowe powinno by ocenione w celu okrelenia jego priorytetu. Sugerowana klasyfikacja priorytetw: 1. konieczno (musi by) - produkt kocowy nie bdzie funkcjonowa bez zmiany; 2. zmiana wa na (powinno by) - niewprowadzenie jej dane, chocia dalsza praca bez niej jest mo liwa przez jaki czas; 3. zmiana po dana (dobrze byoby mie) ale nie niezbdna; 34 8 byoby bardzo

23.1.2.

tej

niepo

PRINCE2

TECHNIKA STEROWANIE ZMIANAMI

4. zmiana kosmetyczna (wskazane byoby - bez istotnego jeszcze) znaczenia; 5. zagadnienie nie wi e si ze zmian (chciabym jeszcze dodatkowo ..) brak zgo- dy na zmian. Kopia wychwyconego Zagadnienia Projektowego jest zwracana autorowi w celu potwierdzenia przyjcia i wpisania go do Rejestru Zagadnie. Wszelkie Zagadnienia Projektowe, ktr e s pytaniami lub wynikaj z nieporozumienia,wyjanione bezporednio. Odpowied jest przesyana autorowi, powinny by kopia umieszczana w dokumentacji, a Rejestr Zagadnie uaktualniany, by odzwierciedli podjte dziaanie.

23.1.3.

Analiza oddziaywania

W przypadku ka dego otwartego Zagadnienia Projektowego przeprowadza si analiz oddziaywania na projekt w celu jego okrelenia: co nale aoby zmieni cznie z ewentualnymi zmianami w produktach powizanych; jakich nakadw wymagaoby zmiany; jaki byby wpyw na Plan Zespou, wprowadzenie

Plan Etapu i Plan Projektu; czy ten wpyw spowodowaby odchylenie poza granice toler ancji wyznaczone dla zespou, etapu lub projektu; jakie byoby oddziaywanie na Uzasadnienie Biznesowe ; jakie byoby oddziaywanie na ryzyko. Zmiana mo e oddziaywa tylko na klienta, tylko na dostawc lub na nich obu. Po analizie oddziaywania nale y ponownie oceni priorytety. Mo na to zrobi na wiele sposo- w zale noci od okolicznoci projektu. Komitet Sterujcy mo e zastrzec dla bw, siebie przeprowadzenie tej ponownej oceny. Komitet Sterujcy mo e zdecydowa decyzji dotyczcych Zagadnie Projektowych do Komisji do sp o delegowaniu raw zmian. Udzielanie zezwolenia Zadania komisji do spraw zmian s opisane w Rozdziale 20 rozdzia 20.3).

23.1.4.

Sterowanie zmianami

(pod-

Jedynie Komitet Sterujcy lub komisja do spraw zmian, ktrej delegowano uprawnienia, powinni podejmowa decyzje dotyczce Wnioskw o Wprowadzenie Zmiany. W przypadku Odstpstw Kierownik Projektu mo e stara si rozwiza problem w grani- tolerancji etapu. Mo e to oznacza zmiany planu(-w), z uwagi na cach konieczno wczenia dodatkowych dziaa. Tam, gdzie korekta Odstpstwa w granicach tolerancji nie jest mo liwa, Kierownik Projektu postpuje wedug procedury dotyczcej istotnych - podproces Przekazy odchyle wanie Projektowyc (SE8), w celu zwrcenia uwagi Komitetu Zagadnie rozpatrzy h spraw Sterujcego, ktry w ramach Podejmowanie Decyzji nyc (ZS4). podprocesu Dora h

349

CHANGE CONTROL TECHNIQUE

PRINCE2

Jeli Komitet Sterujcy zdecyduje o zaakceptowaniu Odstpstwa bez adnych dziaa korygujcych, wwczas decyzj tak nazywa si . ustpstwem Po analizie oddziaywania Zagadnienia Projektowe s przekazywane Komitetowi Steru- lub ko misji ds. zmian. Te ciaa mog zdecydowa o odrzuceniu Zagadnienia jcemu Projektowego, nadaniu mu statusu w zawieszeniu, usuniciu przyczyny problemu lub eniu. Zagadnienia Projektowe aktualizuje si w przypadku wszelkich zmian w wdro priorytetach oraz w wyniku polece Komitetu Sterujcego. 37 Zagadnienia s zwracane Kierownikowi Projektu, ktry uaktualnia Projektowe a uaktualnionRejestr Zagadnie, kopi zgoszenia przesya autorowi. Wszelkie Zagadnienia Projektowe, ktrych wdro enie mogoby spowodowa odchylenie poza tolerancj etapu lub projektu, bd podstaw Raportu o Istotnych Odchyleniach, podprocesie tworzonego w Przekazywanie Projektowyc (SE8). W zale noci Zagadnie to odby h od rodowiska projektu mo e si formalnie lub nieformalnie. Prawdopodobnym rezultatem raportu bdzie skierowanie przez Komitet Sterujcy do Kierownika Projektu, opracowania Planu Nadzwyczajnego, uwzgldniajcego dodatkowe prace. polecenia Powinien on by przedstawiony po zrealizowaniu Opracowanie Planu podprocesuZE6). Nadzwyczajneg ( o Uwaga: Jeli Komitet Sterujcy delegowa decyzje dotyczce wdro enia zmian do odrbnej komisji ds. zmian, nazw tego ciaa nale y wstawi w powy szym opisie tej techniki w miejsce nazwy Komitet Sterujcy. Wskazwki i rady
Ocena oddziaywania potencjalnych zmian mo e by bdnie ograniczona jedynie do badania oddziaywania na klienta. Analiza oddziaywania musi obj trzy obszary: biznesu, u ytkownika i dostawcy. Zanim wprowadzenie zmiany zostanie przekazane pod rozwag Gwnemu U ytkownikowi, musi by znane jej oddziaywanie na dostawc, np. koszty i wymagane nakady oraz okrelenie, ktre produkty musiayby by zmienione. Jeli projekt jest czciowo lub w caoci finansowany przez dostawc, w Komitecie Sterujcym mo e nastpi zmiana uprawnie w sprawach zwizanych ze zmianami. Mo e si to sta w wikszym stopniu wspln decyzj, opart na warunkach kontraktu, lub wiza si z wprowadzeniem modyfikacji w kontrakcie. Wszelkie zmiany zakresu obowizkw i uprawnie powinny znale odbicie w opisach zakresw obowizkw. Jeli projekt jest czci programu, to czy mo e dokonywa zmian, ktre mog oddziaywa na inne projekty? Czy ma uprawnienia do podejmowania takich decyzji? Mo liwe s dwa potencjalne podejcia: przeniesienie wszystkich propozycji zmian na poziom programu, gdzie podejmowane s decyzje; zapewnienie, aby przedstawiciel programu bra udzia w procesie podejmowania decyzji w ramach projektu.

37

Przekazane do Komitetu Sterujcego przypis tumacza.

35 0

24.
24.1.

TE C HNI K A P RZ EGL JA KO I D C
(QUALITY REVIEW TECHNIQUE)

Czym jest przegl

d jako ci?

Przegld jakoci jest strukturaln i usystematyzowan procedur opracowan w celu liwienia oceny, czy produkt odpowiada przeznaczeniu lub czy spenia umo wymagania. Procedura rozpoczyna si od identyfikacji osb lub grup ywotnie zainteresowanych produktem poddawanym przegldowi. Produkt jest sprawdzany, a uwagi i komentarze dyskutowane podczas usystematyzowanej narady. W trakcie tej testerw s narady uzgadniane s niezbdne zmiany oraz sporzdzana jest kompletna lista niezbdnych dziaa naprawczych. Procedura zostaje zakoczona, gdy wszystkie wymagane zmiany zostay wykonane, a produkt for malnie zwolniony, co oznacza, e spenia on ustalone kryte-jakoci i jest od tego momentu ria zatwierdzony.

24.2.

Korzy ci z przegl

du jako ci

Dziki efektywnemu stosowaniu przegldw jakoci mo na osign nastpujce korzyci: wczesna identyfikacja wad produktw, dajca podstaw do ich poprawiania, a co za tym idzie, zmniejszenie kosztw wytwarzania i eksploatacji pr oduktu kocowego; istnienie w projekcie obiektywnej miary dla zarzdczej kontroli postpu prac. Jedn jest zapewnienie przez wytwrc, e produkt jest ukoczony, ale daleko spraw bar- u yteczne jest wiedzie, e grupa niezale nych osb zbadaa produkt i dziej zaakceptowaa go. Daje to Kierownikowi Projektu du o wiksz pewno statusu produktu; dostarczenie wszystkim stronom ywotnie zainteresowanym produktem, sposobnoci do wsplnej pracy dla poprawy jakoci. Pomaga to budowa zespoowe podejcie wytwarzania do produktu; po przejciu produktu przez przegld jakoci, u ytkownik lub u ytkownicy reprezen- zespole przegldu jakoci, chtniej anga uj si na rzecz tego towani w produktu.

24.3.

Kontekst

Przegld jakoci mo na przeprowadzi w ka dym stadium projektu, gdy ka dy produkt mo e zosta poddany przegldowi jakoci, jeli istniej waciwe mu elementy jakoci, ktre powinny by monitorowane. Ma to cisy zwizek z nastpujcymi procesami: Planowani (PL) ze wzgldu na wstpne zaplanowanie i przydzielenie e zasobw dla niezbdnych przegldw jakoci na poziomie Planu Etapu lub Planu wikszych Zespou; 351

QUQLITY REVIEW TECHNIQUE

PRINCE2

Zar dzanie Wytwarzaniem (WP) to ,ktry obejmuje z Produktw wytwarzanie produktw projektu, a wic to proces przeprowadza si wikszo w nim przegldw jakoci (podczas Wykonywanie Grupy (WP2)) ; podprocesu Zada Zgoda na Wykonanie Grupy (SE1) podproces, w ktrym przekazuje si Zada odpowiedzialno za wytworzenie produktu i ustala si wymagania dotyczce przegldw jakoci; Ocena pw (SE2) - podproces, ktry dotyczy monitorowania i Post postpu prac, i do raportowania ktrego dostarcza si szczegowych informacji o wynikach zakoczonych przegldw jakoci, w formie wpisw do Rejestru Jakoci.

24.4.
24.4.1.

Opis techniki Przegl

Cele

d jako ci

Przegld jakoci ma na celu: oceni zgodno produktu z ustalonymi kryteriami; da podstaw do doskonalenia produktu; wczy do kontroli jakoci wszystkie strony zainteresowane produktem; rozszerzy poczucie wasnoci produktu; uzyska zaanga owanie wszystkich ywotnie zainteresowanych produktem; dostarczy mechanizmu dla monitorowania i kontroli zarzdczej.

24.4.2.

Obowi zki

Istniej cztery specyficzne role uczestniczce w procedurze przegldu jakoci: Kierownik przegl du jako ci rola Przewodniczcego,

Rola ta prowadzi przegld jakoci. Jest to inna rola ni ktry przewodniczy Komitetowi Sterujcemu. Gwne jej obowizki to:

sprawdzenie, czy produkt jest gotowy do przegldu; zapewnienie, e przegld jakoci jest waciwie zorganizowany (miejsce, data, godzina rozpoczcia, uczestnicy, czas trwania); zestawienie listy zastrze e oraz sporzdzenie programu (agendy) narady przegldu jakoci; przewodniczenie naradzie przegldu jakoci; zapewnienie, aby przebieg przegldu jakoci nie traci z pola widzenia swojego celu; gwnego zapewnienie, aby uzgodniono dziaania, jakie nale y podj, i ich wyniki; ustalenie wsplnie z testerami wyniku przegldu jakoci;

35 2

PRINCE2

TECHNIKA PRZEGLD JAKOCI

informo wanie Kierownika Projektu i/lub Kierownika Zespou o stanie realizacji wszystkich przegldw jakoci; zo enie kocowego podpisu zatwierdzajcego produkt; uruchomienie procedury postpowania z istotnymi odchyleniami za porednictwem Kierownika Projektu i/lub Kierownika jeli problemy zwizane z Zespou, mog by rozwizane w krtkim przedziale produktem nie czasu.

Wytwrca Rol t peni osoba, ktra wytworzya produkt, lub czonek zespou, ktry odpowiada za jego wykonanie. Z rol t zwizane s nastpujce obowizki: dostarczenie wszystkim testerom stosownych produktw do przegldu jakoci; przygotowanie si do narady przegldu jakoci; ocena listy zastrze e przed narad przegldu jakoci oraz wykorzystanie jej do po- kierownikowi przegldu jakoci w ustaleniu progr amu nar mocy ady; odpowied na pytania dotyczce produktu w trakcie procedury przegldu jakoci, uzgodnienie bdw oraz wyjanienie wszelkich ich konsekwencji; uzgodnienie dziaa majcych na celu napraw stwierdzonych bdw; upewnienie si, e wszelkie uzgodnione dziaania s wykonane; uzyskanie podpisw testerw potwierdzajcych, e wprowadzono uzgodnione zmiany produktu; po zatwierdzeniu wszystkich zmian przez testerw, uzyskanie od kierownika prze- jakoci kocowego podpisu zatwierdzajcego gldu produkt.

Tester Do obowizkw testera nale y: dokonanie przegldu produktu; ocena produktu pod wzgldem zgodnoci z kryteriami jakoci w Opisie Produktu; udokumentowanie zastrze e dotyczcych produktu w aspekcie wczeniej ustalonych kryteriw jakoci; zapewnienie, by bdy byy w peni zrozumiane przez wytwrc, a nastpnie usunite w satysfakcjonujcy sposb; zo enie podpisu zatwierdzajcego realizacj wszystkich pozycji na licie dziaa nastpczych, o ile zosta on wyznaczony jako osoba odpowiadajca za ich sprawdzenie. Protokolant Gwne obowizki tej roli to: pomoc kierownikowi przegldu jakoci w czynnociach administracyjnych, takich np. organizacja miejsca jak narady; notowanie dziaa uzgodnionych podczas narady przegldu jakoci; 353

QUQLITY REVIEW TECHNIQUE

PRINCE2

powtrne przeczytanie listy uzgodnionych dziaa przed kocem nar ady oraz odnotowanie, kto ma podj dziaania naprawcze i kto ma sprawdzi wykonanie poprawek.

Dodatkowo oprcz tych konkretnych rl uczestniczcych w przegldzie, s jeszcze inne obowizki, ktrych wypenienia powinny podj si inne osoby. S to te obowizki, ktre stanowi cz ich normalnych zada, ale ktre odnosz si w sposb szczeglny do przegldw jakoci. I tak: Kierownik Projektu Ma za zadanie: zaplanowa w zarysie jakoci; zaplanowa postpowanie wynikaj-przegldu jakoci i cych z odchyle; dziaa jako tester, gdy waciwe. Kierownik Zespou Ma za zadanie: szczegowo zaplanowa przegldy jakoci; zidentyfikowa wszelkie zasoby, ktre zesp powinien dostarczy do przegldw jakoci (oprcz testerw wskazanych przez penicych rol Nadzoru Projektu); monitorowa realizacj przegldw jakoci w porwnaniu z planem; raportowa o postpach Kierownikowi Projektu. Nale y zauwa y, e Kierownik Projektu czsto bdzie bezporednio kierowa pracami, rezultaty poddawane bd przegldowi jakoci. W takim przypadku ktrych obowizki Kierownika Projektu i Kierownika bd poczone. Zespou Osoby peni ce rol Nadzoru Projektu:

przegldy we wszelkich zidentyfikowanych gro cych powstaniem istotnych jest to sytuacjach,

doradzaj w doborze odpowiednich testerw do ka dego przegldu jakoci; sprawdzaj, czy wszyscy zaanga owani w proces przegldu jakoci s wiadomi swoich rl i obowizkw oraz czy zapewniono wszystkim odpowiednie przeszkolenie w zakresie techniki Przegld jakoci; zapewniaj waciw realizacj procedury przegldu jakoci; sprawdzaj, czy testerzy s dobierani prawidowo i czy zostali wyposa eni we waciwe instrukcje, dotyczce ich prac; sprawdzaj, czy dziaania nastpcze s waciwie monitorowane; dokonuj wpisw w rejestrach i raportuj na temat sposobw u ycia standardw oraz doradzaj w sprawach ewentualnych udoskonale i firmowych poprawek; w razie potrzeby wystpuj w roli testerw.

35 4

PRINCE2 Osoby peni ce rol Wsparcia Projektu

TECHNIKA PRZEGLD JAKOCI

Je eli Kierownik Pr ojektu korzysta ze Wspar cia Projektu, mo e ono by wykorzystane kierownikowi przegldu jakoci oraz wytwrcy w zorganizowaniu do pomocy miejsca przygotowaniu i rozsyaniu dokumentacji przegldu, w penieniu narady, obowizkw i ledzeniu postpw prac znajdujcych si na licie dziaa nastpczych, protokolanta a o momentu, gdy wszystkie bdy zostan usunite i zostanie to potwierdzone d podpisem waciwego testera. Osoby penice rol Wsparcia Projektu mog dziaa jako testerzy, jest jeli to waciwe. Kroki procedury formalnego du jako ci przegl Przegld jakoci skada si z pewnej liczby dziaa, a jego gwnym elementem jest na- dotyczca przegldu jakoci, na ktrej wszyscy uczestnicy zbieraj si, aby rada okreli wady produktu i uzgodni dalsze wszelkie postpowanie. Istniej trzy podstawowe kroki przegldu jakoci: Przygotowanie, skadajce si z: potwierdzenia, e produkt jest gotowy do przegldu; potwierdzenia dostpnoci wyznaczonych testerw oraz uzgodnienia daty zwr o- uwag testerw oraz daty samego tu przegldu; rozprowadzenia wrd testerw kopii produktu oraz jego Opisu Produktu, tam jest to mo liwe, np. jeli jest to drukowany dokument. Alternatywnie gdzie mo- to by udostpnienie produktu do zbadania przez e testerw; oceny zgodnoci produktu z kryteriami jakoci; zapisania zastrze e oraz podejrzewanych bdw na licie zastrze e; odnotowania mniej wa nych bdw na produkcie (np. gramatycznych i ortograficznych) ; zwrcenia produktu z adnotacjami wraz z list zastrze e do wytwrcy; zaplanowania narady przegldu jakoci oraz uzgodnienia jej programu (agendy). Narada przegldu jakoci, skadajca si z: dyskusji, wyjanienia oraz uzgodnienia wszystkich spraw przedstawionych przez testerw; uzgodnienia dziaa nastpczych odpowiednich dla ka dego uzgodnionego bdu; udokumentowania odpowiedzialnoci za dziaania nastpcze; podsumowania zaplanowanych dziaa na koniec narady; uzgodnienia wyniku przegldu jakoci oraz podpisania zatwierdzenia produktu, to mo jeli jest liwe; zaktualizowania Rejestru Jakoci. Dziaania nastpcze po pr zegldzie jakoci, skadajce si z: powiadomienia Kierownika Projektu i/lub Kierownika Zespou o wyniku prze- jakoci; gldu

24.4.3.

355

QUQLITY REVIEW TECHNIQUE zaplanowania wszelkich naprawczych; podpisania zatwierdzenia powodzeniem prac naprawczych; potrzebnych produktu prac w nastpstwie

PRINCE2

zakoczonych

zaktualizowania Rejestru Jakoci. Tabele 24.1, 24.2 i 24.3 pokazuj szczegowy zakr es prac dla rl w przegldzie jakoci dla ka dego z tych krokw. Przygotowanie Tabela 24.1. jakoci Kierownik przegldu jakoci
Sprawdzi gotowo produktu. Potwierdzi, e testerzy s dostpni oraz e nadal s to waciwe osoby.

Przygotowanie do przegldu Wytwrca Tester Kierownik Projektu/Kierownik Zespou

Przeczyta Opis Produktu podlegajcego przegldowi. Wstawi do swego terminarza czas na przygotowanie oraz na przegld jakoci. Sprawdzi zgodno przegldu z harmonogramem prac. Zapewni przestrzeganie procedury przegldu jakoci.

Potwierdzi, e produkt jest dostpny do przegldu. Rozesa kopi produktu oraz Opis Produktu testerom (lub te zapewni dostp do produktu, ktry poddany ma by przegldowi). Uzgodni czas i miejsce przegldu. Poda nazwiska dodatkowych testerw. Dokona aktualizacji planowanego terminu, jeli ten uleg zmianie. Oceni listy zastrzee.

Potwierdzi czas na przygotowanie przegldu jakoci. Potwierdzi informacje w Rejestrze Jakoci

Oceni produkt pod wzgldem zgodnoci z Opisem Produktu. Wypeni list zastrze e oraz odnotowa uwagi na produkcie.

Potwierdzi terminy.

Odebra listy zastrze e i przedyskutowa je z wytwrc. Ustali i uzgodni program (agend) narady przegldu jakoci. Uzgodni form i czas prezentacji (jeli taka jest).

Przekaza kierownikowi przegldu list zastrze e oraz produkt z adnotacjami. Potwierdzi sw obecno na naradzie przegldu jakoci.

Uzgodni program narady z kierownikiem przegldu jakoci. Potwierdzi testerom przed narad szczegy przegldu.

Protokolant mo e wykona wikszo administracyjnych czynnoci dla kierownika prze- jakoci. gldu

35 6

PRINCE2 Narada przegl Tabela 24.2. jakoci Kierownik przegldu jakoci

Otworzy narad, ogosi jej cele, czas trwania, program oraz formu. Zachci do przedstawiania oglnych uwag (zdecydowa, czy jest potrzebne przerwanie narady).

TECHNIKA PRZEGLD JAKOCI du jako ci Narada przegldu Wytwrca Tester Kierownik Projektu/Kierownik Zespou
Zapewni, by caa dokumentacja przegldu jakoci zostaa wczona do akt. Podj odpowiednie dziaanie w sprawie niezakoczonych przegldw jakoci lub ujawnionych bdw, ktre wykraczaj poza zakres normalnych dziaa nastpczych.

Zanotowa zastrzeenia, komentarze i uwagi. Wyjani komentarze testerw.

Rozwin komentarze do listy zastrzee. Wspiera sprawy podnoszone przez innych testerw.

Przeprowadzi przegld produktu w sposb zgodny z agend. Zaprosi testerw do przedstawiania zastrze e i uwag. Zapewni, obecno wszystkich testerw. Zapewni, aby wszystkie ustalone bdy zostay zapisane na licie dziaa nastpczych. Uzgodni odpowiedzialno za dziaanie nastpcze oraz za zo enie podpisu zatwierdzajcego. Uzgodni wynik przegldu jakoci. Sprawdzi, czy do Rejestru Jakoci wpisano dat narady i ustalone dziaania. Poinformowa Kierownika Projektu / Zespou o wyniku przegldu jakoci.

Uzgodni bdy oraz dziaanie nastpcze. Odebra list dziaa nastpczych oraz kopie produktu z adnotacjami.

Uzgodni bdy oraz dziaania nastpcze.

Zaleca si, aby uzgodnione bdy na licie dziaa nastpczych rejestrowa protokolant, kierownikowi przegldu jakoci koncentrowa si na prowadzeniu pozwalajc spotkania. 357

QUQLITY REVIEW TECHNIQUE Dziaania nast Tabela 24.3. jakoci pcze po naradzie przegl du jako ci

PRINCE2

Dziaania nastpcze po naradzie przegldu Wytwrca Tester Kierownik Projektu / Kierownik Zespou
Zapewni, eby plany zostay uaktualnione po usuniciu bdw.

Kierownik przegldu jakoci

Zgosi Zagadnienia Projektowe dotyczce wszelkich nienaprawionych bdw lub bdw w produktach innych ni ten, ktry podlega przegldowi. Zawiadomi Kierownika Projektu / Zespou, jeli termin dziaa korekcyjnych zosta przekroczony. Po naprawieniu wszystkich bdw, podpisa zatwierdzenie (odbir) produktu i poinformowa o tym Kierownika Projektu / Zespou. Wprowadzi do Rejestru Jakoci dane, dotyczce rzeczywistego terminu przekazania (odbioru).

Naprawi bdy. Sprawdzi i potwierdzi podpisem napraw bdw.

Uzyska od kierownika przegldu jakoci podpisan list dziaa nastpczych. Zawiadomi kierownika przegldu jakoci o naprawach, ktre przekroczyy wyznaczone dla nich terminy.

W razie potrzeby pomc w naprawianiu bdw.

Wo y do akt ca podpisan dokumentacj.

Zaj si wszelkimi potrzebnymi dziaaniami, zwizanymi z istotnymi odchyleniami.

Wikszo prac dotyczcych ledzenia postpu dziaa nastpczych i zatwierdze (odbio-mo e, w imieniu kierownika przegldu jakoci, wykona rw) protokolant. Planowanie przegl du jako ci Istotne jest, aby przegldy jakoci byy waciwie zaplanowane z udziaem osb penicych rol Nadzoru Dlatego istnieje jeszcze dodatkowy krok planowania pr Projektu. gldw jakoci, skadajcy si zez: okrelenia produktw, ktre bd podlegay przegldowi jakoci; zaplanowania terminw dla wszystkich przegldw jakoci; wyznaczenia testerw oraz dodania ich do planw zasobw. Czynnoci te stanowi cz prac zwizanych z tworzeniem Planu Etapu lub Planu Ze- w procesie Planowani (PL). spou e

35 8

PRINCE2

TECHNIKA PRZEGLD JAKOCI Wyniki przegl du jako ci

24.4.4.

Na koniec przegldu jakoci, kierownik przegldu powinien uzyska jednomylnejego wyniku. Jeli ktrykolwiek z testerw nie jest gotowy do zo enia uzgodnienie pod- akceptujcego produkt, znaczy to, e produkt nie speni kryteriw jakoci, a pisu zatem gotowy do u ytku. Jeli komentarze testerw nie mog by uwzgldnione z nie jest jakiego powodu np. sporu midzy testerami dalsza dyskusja oraz porozumienie w tej sprawie powinny by wprowadzone jako pozycja na list dziaa nastpczych. Jeli pro- dotyczy innych produktw ni poddanego przegldowi, powinno to by blem zgoszone jako Zagadnienie Projektowe, a dziaanie zarejestrowane na licie dziaa nastpczych. Zwykle wynik przegldu przyjmuje jedn z trzech postaci: produkt nie ma bdw i mo e by natychmiast zatwierdzony; produkt mo e by zatwierdzony dopiero, gdy znalezione bdy zostan 39 ; naprawione i zostanie to potwierdzone podpisem naprawa znalezionych bdw radykalnie zmieni produkt i powinien on w zwizku z tym powtrnie zosta poddany przegldowi. Kierownik przegldu jakoci mo e te zdecydowa o przeo eniu terminu narady przegldu, jeli: w naradzie uczestniczy niewystarczajca liczba testerw, by obj cao spraw jakoci, ktrych dotycz kryteria jakoci produktu; testerzy uczestniczcy w naradzie nie maj odpowiednich kwalifikacji do komento- zagadnie, wania ktre zostay podniesione; jest jasne, e testerzy nie zbadali produktu podczas przygotowania; stao si oczywiste, e produkt nie nadaje si do przegldu. 24.4.5. Kryt eria oceny ci jako Czy kryteria jakoci produktu zostay wyspecyfikowane? Czy Opis Produktu zosta testerom razem z przekazany produktem? Czy testerzy dokadnie sprawdzili produkt przed narad przegldu jakoci? Czy lista zastrze e bya przesana wytwrcy lub kierownikowi pr zegldu jakoci przed narad przegldu? Czy narada przegldu jakoci koncentrowaa si na wykrywaniu bdw, a nie na naprawianiu bdw lub przekonstruowaniu produktu? Czy dziaania nastpcze zostay udokumentowane i przydzielone do wykonania? Czy testerzy byli zapytani, ktre zmiany gotowi s zatwierdzi swoim podpisem? Czy osignite zostao porozumienie co do wyniku przegldu jakoci?

38

38 39

W wyniku ustalonych dziaa nastpczych przypis tumacza. Wskazanej osoby, zwykle jednego z testerw przypis tumacza.

359

QUQLITY REVIEW TECHNIQUE Wskazwki i rady

Przegld jakoci polega na identyfikacji bdw/ okazji, a NIE na ich korygowaniu. Pokusa uzgodnienia rozwiza dla znalezionych w produkcie usterek mo e by znaczna. Jeli poszukiwanie rozwiza miaoby si sta cech przegldu jakoci, wtedy procedura przegldu straciaby wiele ze swojej efektywnoci, poniewa dyskusja nad rozwizaniami pochania czas i wysiek potrzebny na rozwa enie gwnego celu przegldu jakoci, tzn. identyfikacji i uzgodnieniu usterek produktu po to, by stworzy podstaw dla poprawy produktu. Mo e by tak e wicej ni jedno rozwizanie problemu, a grupa osb zebranych aby przeprowadzi przegld produktu, mo e nie by predestynowana do wyboru najlepszego rozwizania. Wszelkie rozwizania sugerowane podczas procesu przegldu powinny by zanotowane w celu pniejszego rozwa enia. Istnieje potrzeba odwoania si do psychologii stosunku midzy wytwrc a testerem. Celem przegldu jakoci jest znalezienie wad produktu, nie wad wytwrcy. Testerzy i wytwrcy powinni podchodzi do przegldu z konstruktywnym zespoowym nastawieniem na osignicie jakoci produktw. Jeli nie uda si zapewni owego zespoowego podejcia, mo e si pojawi konflikt, ktry destruktywnie wpynie na procedur przegldu jakoci. Pomocne jest, jeli testerzy odnosz si wycznie do produktu (jako takiego), a nie do waszego produktu. Narada przegldu jakoci nie jest doranym zgromadzeniem osb. Nie jest pierwsz okazj dla uczestnikw do zapoznania si z produktem w celu zidentyfikowania problemu. Tak jak podczas ka dej prawidowo przygotowanej narady, jej uczestnikami powinny by osoby, ktre bray udzia w sprawdzeniu produktu objtego przegldem. Powinny one by przygotowane do udziau w naradzie, znajc jej porzdek, cele oraz wasn rol, jak powinny peni podczas narady. Uczestnicy przegldu jakoci musz przygotowa si do przegldu, wypisujc powa ne zastrze enia oraz podejrzewane bdy na licie zastrze e, jeli to mo liwe, odnotowujc na produkcie mniejsze bdy, oraz informujc kierownika przegldu o swoich spostrze eniach. Niestosowanie si do tego jest strat czasu innych uczestnikw narady oraz podwa a warto kocowego zatwierdzenia produktu, poniewa jest wtedy bardziej prawdopodobne, e bdy pozostan nieujawnione. Nale y zadba o to, by mened erowie nie uczestniczyli w przegldzie jakoci w roli osb kierujcych ich uczestnikami. Nie bior oni udziau w naradzie po to, by oceni osignicia swoich pracownikw. Jest to szczeglnie istotne w odniesieniu do kierownika ze strony producenta, gdy mo e to obni y warto narady oraz wywoa u wytwrcy dodatkowy stres. Jednak mened erowie mog uczestniczy w roli testerw. Powinno si wykorzystywa listy kontrolne. Gwnym rodkiem oceny jakoci produktu jest odniesienie do Opisu Produktu, ktry definiuje zawarto, form i kryteria jakoci produktu. Jeli nie jest on dostpny, powinna by dostpna lista kontrolna standardowych kryteriw jakoci dla produktw danego rodzaju. Bez Opisu Produktw lub Listy Kontrolnej, testerzy bd pozostawieni bez wytycznych, czym jest akceptowalna jako. W idealnej sytuacji kierownik przegldu nie powinien dziaa jako tester. Trudno jest rwnoczenie przewodniczy naradzie przegldu oraz dokonywa przegldu produktu. Kierownik przegldu jakoci powinien jedynie prowadzi narad.

PRINCE2

36 0

PRINCE2
Nieobecno testera:

TECHNIKA PRZEGLD JAKOCI

Jeli tester nie mo e by obecny na naradzie, kierownik przegldu mo e albo zaakceptowa list jego zastrze e i przeprowadzi dyskusj punktw tej listy podczas narady, albo zmieni testera. Jeli liczba nieobecnych jest taka, e zagrozi to efektywnoci narady albo z powodu braku odpowiedniej liczby osb do dyskusji, albo braku istotnych kompetencji, konieczne mo e by przeo enie narady. W sytuacji gdy uczestnicy nie s przygotowani do przegldu albo nie dostarczyli list zastrzee, waciwe mo e by odo enie przegldu, jeli przewiduje si, e mgby by nieefektywny. Kierownik Projektu mo e podj decyzj, by zwrci si do testerw o dostarczenie list zastrze e, a nastpnie odby narad tylko z udziaem kierownika przegldu jakoci i wytwrcy, przy czym kierownik przegldu dziaaby w imieniu testerw. W takich przypadkach kierownik przegldu jakoci powinien uzyska wszelkie zatwierdzenia dziaa nastpczych bezporednio od testerw, ktrzy przedo yli zastrzeenia.

Dla produktw powstajcych w ramach kilku projektw, przedstawiciele tych projektw powinni uczestniczy w przegldach jakoci. Wytwrca mo e si podj sugerowanej roli protokolanta, szczeglnie podczas nieformalnych przegldw jakoci. Ta rola nie powinna by peniona przez kierownika przegldu jakoci, gdy odrywanie uwagi na prowadzenie notatek mo e osabi kontrol nad przebiegiem narady. B dy w innych produktach: Przegld jakoci mo e doprowadzi do stwierdzenia bdu w produkcie innym ni podlegajcym przegldowi. Powinno to by zarejestrowane jako pozycja dziaa nastpczych, ktra bdzie zamykana po przeniesieniu do waciwego Zagadnienia Projektowego. Przegldy jakoci mog ujawni bdy nie tylko po stronie wytwrcy, ale tak e bdy spowodowane wadami standardw jakoci i metod wytwarzania. Niepowodzenie w u yciu standardu mo e wskazywa na to, e standard nie jest nadal praktyczny lub waciwy. Takie zdarzenia powinny spowodowa przegld takich podejrzanych obszarw standardw.

361

LEKSYKON TERMINW PRINCE2

G LO SS ARY

Akceptacja przez su by eksploatacji i su by Operational and maintenance acceptance utrzymania produktu przez osob lub grup osb, ktre zajmowa si bd Przyjcie produktem eksploatacji, akceptujce jego wczenie do rodowiska operacyjnego. w czasie Formua akceptacji bdzie zale aa od samego produktu. Mo e przybra posta pisma akceptujcego, podpisanego przez osoby upowa nione, lub bardziej rozbudowanego raportu, opisujcego szczegowo wprowadzone rozwizania dotyczce eksploatacji i utrzymania. Akta projektu Project records Zbir wszystkich zatwierdzonych produktw zarzdczych i specjalistycznych oraz in- materiaw, ktre s niezbdne do skompletowania dokumentacji projektu, nych nadaj- si cej do audytu. Uwaga: Nie obejmuj one dokumentacji roboczej. Analiza wartoci wypracowanej Earned value analysis Jest to metoda pomiaru osigni projektu. Wskazuje, jaka cz bud etu powinna by, zostaa faktycznie wykorzystana w zestawieniu z rozmiarem wykonanych a jaka prac, zadaniami, przydziaami lub zasobami. Audyt Configuration audit konfiguracji numerw ostatnich wersji i statusu wszystkich produktw, wykazanych w Porwnanie rejestrach biblioteki konfiguracji, z informacjami posiadanymi przez autorw produktw. Biuro Wsparcia Project Suport Office Projektu stworzona w celu wiadczenia pewnych usug administracyjnych Grupa Kierownikowi Projektu. Czsto wiadczy swoje usugi wielu projektom rwnolegle. Blisko (zagro Proximity (of risk) enia) Oddaje wymiar czasowy ryzyka, tzn. czy zagro enie (lub kor zystna okazja) wystpi z wiksz si w konkretny m czasie, czy zniknie po pewnym czasie, albo czy prawdopo- lub oddziaywanie zmienia si bd wraz z upywem dobiestwo czasu? Bud et rezerwowy Contingency budget Pewna kwota wymagana do wdro enia planu rezer wowego. Jeli Komitet Sterujcy zatwierdza plan rezerwowy, zwykle powinien rwnie przydzieli bud et rezerwowy do wykorzystania tylko jeli plan rezerwowy bdzie musia by wprowadzony w ycie w przypadku zmaterializowania si zwizanego z nim zagro enia. Patrz tak e: Plan rezerwowy. Bud et zmian rodki pieni ne przekazane komisji ds. zmian, przeznaczone zaakceptowanych Wnioskw o Wprowadzenie Zmian.
Change budget

na realizacj

363

GLOSSARY

PRINCE2

Cykl ycia Project life cycle projektu stosowany jest w niniejszym podrczniku do okrelenia okresu od Termin rozpoczcia projektu a do przekazania ukoczonego produktu tym, ktrzy bd go eksploatowa i utrzymywa. Diagram Nastpstwa Produktw (DNP) Product Flow Diagram PFD Diagram pokazujcy kolejno wytwarzania oraz wzajemne zale noci midzy produk-wymienionymi tami Diagramie Struktury . na Produktw Diagram Struktury Produktw Product Breakdown Structure - PBS (DSP) Hierarchia wszystkich produktw, ktre maj by wytworzone w ramach planu. Dokument Inicjujcy Projekt Project Initiation Dokument - PID (DIP) Dokument natury koncepcyjnej, ktry zestawia najistotniejsze informacje niezbdne do rozpoczcia realizacji projektu na podstawie mocnych przesanek i przekazuje je wszyst- stronom kim zainteresowanym projektem. Dostawca Supplier Grupa lub grupy odpowiedzialne za dostaw specjalistycznych produktw projektu. Dyrektor zarzdzajcy, Dyrektor Senior Responsible Owner odpowiedzialny Nie jest to termin PRINCE2, cho stosowany jest przez wiele organizacji. Jego odpowiednikiem w PRINCE2 jest rola Przewodniczcego. Patrz tak e: Przewodniczcy. Dziennik Daily Log Spis prac do wykonania lub do sprawdzenia ich wykonania przez innych, spis zobowi- strony osoby prowadzcej dziennik lub innych osb, wa nych wydarze, za ze decyzji lub dyskusji. Dziennik powinien by prowadzony pr zez Kierownika Projektu i ka dego Kierownika Zespou. Dziennik ryzyka Risk Register Patrz: Rejestr Ryzyka Etap Stage Etap jest fragmentem projektu, zarzdzanym przez Kierownika Projektu w imieniu i na rzecz Komitetu Sterujcego w dowolnym czasie, na koniec ktrego Komitet Sterujcy przegldu postpw prac zrealizowanych do tego dnia, stanu Planu dokonuje Projektu, Uzasadnienia Biznesowego i zagro e oraz Etapu (nastpnego) , aby zdecydowa Planu o kontynuacji projektu. Faza Phase Cz, sekcja lub segment projektu, o znaczeniu podobnym do etapu w PRINCE2. podstawowym znaczeniem okreslenia etap w rozumieniu PRINCE2 jest etap zarzdczy, tj. czci projektu, w ktr e Komitet Sterujcy powinien si kolejno (po jednym w danym momencie) zaanga owa. Faza mo e w wikszym stopniu wiza si z przedziaem cza- koniecznymi zmianami umiejtnoci lub zmian su, akcentw. Formua Realizacji Project Approach Projektu Opis sposobu, w jaki prowadzone bd prace projektu. Przykad: Czy budujemy produkt czy nabywamy produkt ju istniejcy? Czy decyzje podjte na poziomie od zera, programu ograniczaja mo liwo wykorzystania technologii i produkw?

36 4

PRINCE2

LEKSYKON TERMINW

Gwny Dostawca Senior Supplier Rola w Komitecie Sterujcym, ktra dostarcza wiedzy i dowiadczenia w zakresie gw- dyscyplin zwizanych z wytwarzaniem produktw projektu. W projekcie nych reprezentuje interesy dostawcy(-w) i dostarcza zasobw dostawcy. Gwny U ytkownik Senior User Rola w Komitecie Sterujcym odpowiedzialna za zagwarantowanie, e potrzeby u ytkownika s prawidowo okrelone oraz e rozwizanie spenia te potrzeby. Grupa Zada Work Package Zbir informacji dotyczcych wytworzenia jednego produktu lub wikszej ich liczby. opis prac, Opis(y) Produktu(-w), szczegy wszelkich ogranicze Zawiera dotyczcychtakich jak czas i koszty, punkty styku, a tak e potwierdzenie uzgodnienia produkcji, mi- Kierownikiem Projektu a osob wykonujc lub waciwym Kierownikiem dzy Zespou, mo e by wykonana w ramach tych e praca ogranicze. Interesariusz Stakeholders e Strony zainter esowane realizacj i wynikami projektu. Zaliczy mo na do nich tak e ob- biznesu, na ktre ten wynik bdzie oddziaywa, lub ktr e od niego zale szary . Istotne Exception odchylenie Prognozowane odchylenie poza tolerancje uzgodnione midzy Kierownikiem Projektu a Komitetem Sterujcym (lub midzy Komitetem Sterujcym a kierownictwem firmy al- programu, lub midzy Kierownikiem Zespou a Kierownikiem bo Projektu). Jako Quality Og waciwoci i cech wyrobu lub usugi, ktre wiadcz o jego/jej zdolnoci do zaspokojenia ustalonych potrzeb. Tak e definiowana jako zgodno z przeznaczeniem wymaganiami. lub zgodno z Kierownik Project Manager Projektu Osoba, ktrej nadano uprawnienia i obowizek zarzdzania na bie co projektem, w celu dostarczenia wymaganych produktw w ramach ogranicze uzgodnionych z Komitetem Sterujcym . Kierownik Zespou Team Manager Rola, ktr mo e wykonywa osoba zatrudniona przez Kierownika Projektu lub Gwnego Dostawc w celu kierowania prac czonkw zespou projektowego. Klient Customer Osoba lub grupa, ktra zlecia prac i odniesie korzyci z jej kocowych rezultatw. Komisja do spraw Change authority zmian osb, ktrej Komitet Sterujcy mo e delegowa odpowiedzialno za Grupa rozpatrywanie Wnioskw o Wprowadzenie Zmiany. Komisja do spraw zmian ma przydzielony bu- i mo e zatwierdza zmiany w granicach tego bud d et etu. Korzyci Benefits Pozytywne efekty ujte ilociowo lub nie, dla osignicia ktrych projekt podjto, a ktre uzasadniaj tak inwestycj. Kryteria Acceptance Criteria Akceptacji Uo ona wedug priorytetu lista kryteriw, ktre musi speni produkt kocowy zanim zaakceptowany przez klienta; okrelenie w mierzalnych kategoriach tego, zostanie co powinno by zrobione, aby produkt kocowy by akceptowalny przez klienta. Powinny 365

GLOSSARY

PRINCE2

one by zdefiniowane jako cz Zao e Projektu oraz uzgodnione midzy klientem a dostawc nie pniej ni podczas Etapu inicjowania projektu. Powinny by udokumentowane w Dokumencie Inicjujcym Projekt. Linia tolerancji Risk tolerance line ryzyka tolerancji ryzyka to linia oddzielajca te zagro enia, ktre mog by Linia zaakceptowa- ktrych zaplanowano odpowiednie dziaania, od tych zagro e, ktre ne lub wobec uzna za wystarczajco powa ne, aby zawiadomi o nich nastpny, wy szy szczebel trzeba zarzdzania projektem. Lista Kontrolna Product Checklist Produktw Lista gwnych produktw ujtych w planie wraz z kluczowymi terminami, zwizanymi z ich dostaw. Nadzr Projektu Project Assurance Obszar obowizkw Komitetu Sterujcego zwizanych z koniecznoci zapewnienia sobie, e projekt jest prowadzony waciwie. Obiekt Baseline odniesienia Ujcie migawkowe; zarejestrowane poo enie, status lub sytuacja. Mimo e mog by pniej zmienione, obiekt odniesienia pozostaje niezmieniony i jest dostpny one jako przypomnienie pierwotnego stanu oraz wykorzystywany jako porwnanie ze stanem aktualnym. Produkty, ktre przeszy sprawdzenie jakoci i zostay zatwierdzone, staj si obiektami odniesienia. Wszystko, co uznano za obiekt odniesienia, musi podlega kontroli wersji w ramach zarzdzania konfiguracj oraz by zamro one, tzn. nie s dozwolone adne zmiany tej wersji. Ocena kocowa etapu End Stage Assessment Przegld Raportu Kocowego Etapu dokonywany przez Komitet Sterujcy i Kierownika celu podjcia decyzji, czy zatwierdzi Plan Etapu (nastpnego) o ile Projektu w wanie nie zakoczono ostatniego etapu. W zale noci od wielkoci i znaczenia projektu, prze- mo e mie charakter formalny lub nieformalny. Wydanie zezwolenia na gld kontynuacj powinno by udokumentowane jako wa ny produkt zarzdczy. Ocena nadzwyczajna Exception assessment Jest to posiedzenie Komitetu Sterujcego w celu zatwierdzenia (lub odrzucenia) Planu Nadzwyczajnego. Oczekiwania jakociowe Customers quality expectations klienta Owiadczenie klienta na temat oczekiwanej jakoci produktu kocowego. Powinno zosta uzyskane podczas przygotowania projektu w Przygotowanie Zao podprocesie e (IP1), Projekt (PP4) jako wa ny wkad do podprocesu Planowanie c gdzie u si je z Formu Realizacji Projektu i standardami, ktre trzeba bdzie zachowa, Jako i zestawia e- jako t osign. by Odstpstwo Off-Specification Co, co powinno by dostarczone przez projekt, ale nie jest (lub przewiduje si, e nie bdzie). Mo e to by brakujcy produkt lub produkt, ktry nie spenia wymaga swojej specyfikacji. Rodzaj Zagadnienia Projektowego. Okres ycia produktu Product life span Termin u y wany w niniejszym podrczniku do okrelenia caego okresu ycia produktu d momentu pierwszego pomysu na produkt a do jego wycofania z eksploatacji. o Praw-

36 6

PRINCE2

LEKSYKON TERMINW

dopodobnie w okresie ycia produktu, dotyczy go bdzie wiele projektw takich jak: studium wykonalnoci, wytworzenie, rozwj i udoskonalenia lub korekty. Opis Produktu Product Description Opis przeznaczenia produktu, skadu, pochodzenia i kryteriw jakoci. Powstaje w czasie planowania tak szybko, jak to mo liwe po stwierdzeniu potrzeby takiego produktu. Plan bazowy Baseline Patrz: Obiekt odniesienia Plan Jakoci Project Quality Plan Projektu Plan definiujcy gwne kryteria jakoci, procesy kontroli jakoci i audytw, ktre powinny by zastosowane do zarzdzania projektem oraz jego pracami specjalistycznymi zdzanych zgodnie z metodyka PRINCE2. Jest czci tekstu w projektach zar Dokumen- Inicjujcego tu Projekt. Plan Communication Plan Komunikacji Cz Dokumentu Inicjujcego Projekt opisujca, jak interesariusze projektu i inne zainteresowane strony bd informowan i w trakcie projektu. Plan Nadzwyczajny Exception Plan Jest to plan, ktry czsto powstaje w nastpstwie Raportu o Istotnych Odchyleniach. Nadzwyczajnego Planu Zespou obejmuje okres od chwili powstania W przypadku do koca realizacji Grupy Zada; w przypadku Nadzwyczajnego Planu Etapu okres od chwili powstania do koca bie cego etapu. Jeli istotne odchylenie wystpi na poziomie nale y zastpi Plan projektu, Projektu. Plan Project Plan Projektu Plan wysokiego poziomu, pokazujcy gwne produkty projektu, terminy ich dostarczenia i koszty. Pocztkowy Plan Projektu jest przedstawiany jako cz Dokumentu Inicju- Projekt. Jest on uaktualniany w miar napywu informacji o faktycznym jcego postpie Komitetu Sterujcego jest to gwny dokument do sterowania projektem, su prac. Dla - do oceny faktycznych postpw w odniesieniu do cy oczekiwa. Plan Rezerwowy Contingency Plan Plan zawierajcy informacje o krokach, ktre powinny by podjte w przypadku, gdyby okrelone zagro enie faktycznie wystpio. Plan rezerwowy przygotowuje si, gdy inne dziaania (zapobieganie zagro eniu, redukcja lub przeniesienie) s albo niemo liwe, albo kosztowne, albo gdy aktualna ocena zagro enia wskazuje, e koszty zbyt poniesione w przypadku jego zmaterializowania si, nie bd do wysokie, aby uzasadnia podjcieprzeciwdziaajcych temu zagro eniu, a zagro enia tego nie mo na po prostu dziaa zaakceptowa. Komitet Sterujcy ma w ten sposb wiadomo, e jeli zagro enie si zmaterializuje, to istnieje plan zareagowania na to. Jeli Komitet Sterujcy zgodzi si, eest to najlepsza metoda dziaania, mo e wydzieli bud et rezerwowy na pokrycie j kosz- r ealizacji planu rezerwowego do wykorzystania tylko w przypadku tw urzeczywistnie- zagro nia si tego enia. Planowanie oparte na Product-based planning produktach cztery kroki technika, prowadzca do opracowania caociowego Obejmujca planu, opartego na wytworzeniu i dostarczeniu wymaganych produktw. Technika ta bierze pod uwag niezbdne produkty, wymagania jakociowe oraz zale noci midzy produktami.

367

GLOSSARY

PRINCE2

Powiadomienie o rozpoczciu Project start-up notification projektu Powiadomienie organizacji, w ktrej projekt na by realizowany, e projekt ma si wkrtce rozpocz, zawierajce prob o wiadczenie potrzebnych usug Wsparcia Projektu. Powiadomienie o zamykaniu Project closure notification projektu Powiadomienie skierowane przez Komitet Sterujcy do wszystkich interesariuszy oraz do organizacji, w ktrej projekt jest realizowany, e zasoby projektu mog by rozwizane, pomocnicze takie jak pomieszczenia, wyposa enie i dostp zwolnione. a zasoby Powinno termin zamknicia umo liwiajcy okrelenie kosztw, majcych obci y zawiera projekt. PRINCE2 Metodyka, ktra wspiera kilka wybranych aspektw Akronim oznacza w jzyku PR ojects IN Controlled angielskim w sterowanych rodowiskach.
ProjectINControlledEnvironments

zarzdzania projektem. Environments, projekty

czyli

Proces Process To, co musi by zrobione, aby doprowadzi do okrelonego wyniku, w kategoriach informacji, ktre nale y zgromadzi, decyzji, ktre nale y podj, i rezultatw, ktre musz by uzyskane. Produkt Product Jakiekolwiek wejcie lub wyjcie z pr ojektu. PRINCE2 rozr nia produkty zarzdcze, ktre powstaj jako cz procesw zarzdczych lub procesw zapewnienia jakoci w projekcie, od produktw specjalistycznych, ktre skadaj si na produkt kocowy. mo e sam by zbiorem innych Produkt produktw. Profil Risk profile ryzyka Graficzna prezentacja informacji, zwykle znajdujcych si w Rejestrze Ryzyka. Program Programme Portfel projektw wybranych, planowanych i zarzdzanych w skoordynowany sposb. Projekt Project Organizacja stworzona na okrelony czas w celu dostarczenia jednego lub wicej produktw biznesowych, zgodnie z okrelonym Uzasadnieniem Biznesowym. Projekt zarzdzany wedug PRINCE2 PRINCE2 project Projekt, ktrego produkty mo na okreli ju na jego pocztku wystarczajco precyzyj- by mogy by mierzone w odniesieniu do wczeniej zdefiniowanych war nie, tak toci y jest zarzdzany zgodnie z metodyk i ktr PRINCE2. Przedmiot dostawy (Produkt Deliverable czstkowy)ktry projekt musi stworzy jako cz wymaga. Mo e to by cz Element, wyniku kocowego lub element poredni, od ktrego zale y jeden lub wicej kolejnych produktw czstkowych. W zale noci od rodzaju projektu inn nazw przedmiotu dostawy jest produkt. Przegld jakoci Quality review Przegld jakoci jest technik sprawdzania jakoci o okrelonej strukturze, zdefiniowa- i procedurze, opracowan w celu zapewnienia kompletnoci produktu or nych rolach az jego zgodnoci ze standardami. Uczestnicy s wybierani spord tych, ktrzy s zaintere- produktem, oraz tych, ktrzy posiadaj niezbdne umiejtnoci, aby sowani dokona 36 8

PRINCE2

LEKSYKON TERMINW

przegldu prawidowoci produktu. Przykadem sprawdzenia przeprowadzonego w trak- przegldu jakoci jest pytanie: Czy dokument spenia kryteria jakoci cie zawarte w dotyczcym go Opisie Produktu? Przegld Gate review kontynuacyjny oglne okrelenie ni pojcie metodyki PRINCE2, oznaczajce punkt Jest to raczej na kocu etapu lub fazy, w ktrym podejmowana jest decyzja, czy kontynuowa projekt. W PRINCE2 odpowiada on ocenie kocowej etapu. Przegld Peer review partnerski partnerskie s specyficznymi przegldami projektu lub jakiego z jego Przegldy produk- w ktrych personel z wewntrz organizacji i/lub z innych organizacji tw, przeprowadza-ocen pr ojektu. Przegldy partnerskie mog by wykonywane w j niezale n dowolnym punkcie projektu, ale czsto przeprowadza si je na kocach etapw. Przegld poprojektowy Post-project review Jeden lub wicej przegldw wykonywanych po zamkniciu projektu w celu okrelenia, czy uzyskano oczekiwane korzyci. Znany tak e jako przegld powdro eniowy. Przegld powdro eniowy Post-implementation review Patrz: Przegld poprojektowy Przewodniczcy Executive Osoba, ktra ponosi pen odpowiedzialno za zapewnienie, e projekt osignie swojei przyniesie planowane korzyci. Osoba ta powinna zagwarantowa, by projekt cele lub program utrzymywa swoje nastawienie na biznes, mia jasno okrelone zakresy upraw- oraz by prace, cznie z ryzykiem, byy aktywnie zarzdzane. nie Przewodniczcy Komitetowi Sterujcemu, reprezentuje klienta i jest wacicielem przewodniczy Uzasadnienia Biznesowego. Punkt kontrolny Przegld postpu prac na poziomie terminach, powizany z narad. zazwyczaj
Checkpoint

zespou,

odbywajcy

si

w okrelonych

Raport Kocowy Etapu End Stage Report Raport przekazywany Komitetowi Sterujcemu przez Kierownika Projektu na zakoczenie ka dego etapu zarzdczego projektu. Dostarcza informacji o osigniciach projektu etapu oraz o stanie projektu na kocu w trakcie etapu. Raport Kocowy Projektu End Project Report Raport przekazywany Komitetowi Sterujcemu przez Kierownika Projektu, ktry potwierdza przekazanie wszystkich produktw oraz zawiera uaktualnione Uzasadnienie ocen, jak dobrze projekt zosta zrealizowany w odniesieniu do jego Biznesowe oraz Dokumentu Inicjujcego Projekt. Raport o Dowiadczeniach Lessons Learned Report Raport, ktry opisuje dowiadczenia zdobyte w trakcie prowadzenia projektu i ktry zawiera tak e dane liczbowe, dotyczce kontroli jakoci produktw zarzdczych projektu. Jest on zatwierdzany przez Komitet Sterujcy, a nastpnie przechowywany centralnie, tak by przynis korzyci przyszym projektom. Raport o Istotnych Exception Report Odchyleniach Komitetowi Sterujcemu opis sytuacji nadzwyczajnej, jej wpywu, mo Przekazywany -iwych l dziaa naprawczych, rekomendowanego dziaania oraz wpywu rekomendowa369

GLOSSARY

PRINCE2

nego dziaania. Raport sporzdzany jest przez waciwego mened era w celu poinformowania kolejnego, wy szego szczebla zarzdzania o zaistniaej sytuacji. Raport Okresowy Highlight Report Raport Kierownika Projektu dla Komitetu Sterujcego o postpach etapu, przekazywany w okrelonych terminach. Raport z Punktu Checkpoint Report Kontrolnego postpach oparty na informacjach zebranych na naradzie w punkcie Raport o kontrolnym, przekazywany przez zesp Kierownikowi Projektu i dostarcza danych ktry jest sprawozdawczych okrelonych w Grupie Zada. Realizowanie korzyci Dziaania zapewniajce, e wynik zapisane w Uzasadnieniu Biznesowym.
Benefits realisation

projektu

wytwarza

zaplanowane

korzyci,

Rejestr Dowiadcze Lessons Learned Log Nieformalny zbir pozytywnych i negatywnych nauk odebranych w miar realizacji pro- zarzdczych i specjalistycznych. Pod koniec projektu nadaje mu si posta cesw for- i systematyzuje w formie Raportu o Dowiadczeniach. Patrz tak e: Raport o maln Dowiadczeniach. Rejestr Quality Log Jakoci zapis wszelkich planowanych i przeprowadzonych dziaa w zakresie Zawiera jakoci. Wykorzystywany jest przez Kierownika Projektu i Nadzr Projektu w trakcie przegldu postpw. Rejestr Ryzyka Risk Log Dokument, ktry zawiera wszystkie informacje o zagro eniach, ich analizie, przeciwdziaaniach i statusie. Znany tak e pod nazw Ryzyka. Dziennik Rejestr Issue Log Zagadnie wszystkie Zagadnienia Projektowe, cznie z Zawiera Wnioskami o Wprowadzenie Zmian, zgoszone w trakcie trwania projektu. Ka de z Zagadnie Projektowych opatrzo- niepowtarzalnym numerem i zarchiwizowane w Rejestrze Zagadnie z ne jest nadaniem waciwego statusu. Patrz tak e: Zagadnienie Projektowe. Ryzyko Risk Ryzyko mo na okreli jako niepewno wyniku czy to w sensie pozytywnym oznaczajcym dogodn okazj, czy te w negatywnym zagro enie. Z ka dym projektem wi ei ryzyko. Zarzdzajcy projektem maj zadanie identyfikacji zagro e s dotyczcych projektu oraz podjcia odpowiednich krokw w celu wykorzystania okazji, jakie mog si pojawi, lub w celu uniknicia, zredukowania lub zareagowania na zagro enie. Sie dziaa Activity network Diagram nastpstwa pokazujcy planowane dziaania i wzajemne zale noci midzy ni- Sie pokazuje czas trwania ka dego dziaania, najwczeniejsze terminy mi. rozpoczcia i zakoczenia, najpniejsze terminy rozpoczcia i zakoczenia oraz zapas czasu. Znany jako sie planistyczna. Patrz tak e: cie ka tak e krytyczna. Specyfikacj Specification a Szczegowy wykaz tego, czego oczekuje u ytkownik w kategoriach produktw, jak po- one wyglda, jak powinny funkcjonowa i z czym powinny wsppracowa. winny

37 0

PRINCE2

LEKSYKON TERMINW

Sponsor Sponsor Nie jest to konkretna rola w PRINCE2, ale jest czsto u ywana do okrelenia gwnej siy napdowej projektu. Mo e by odpowiednikiem Przewodniczcego lub kierownictwa firmy/programu . Sterowanie Configuration control konfiguracj konfiguracj obejmuje fizyczn kontrol odbioru i wydawania Sterowanie produktw, statusu produktw, zabezpieczenie produktw ukoczonych oraz ledzenie kontrol wszelkich wprowadzanych w nich zmian. Sterowanie Change control zmianami Procedura zapewniajca, e postpowanie ze wszystkimi Zagadnieniami Projektowymi jest pod kontrol, obejmujc zgaszanie, analiz i podejmowanie decyzji. Studium wykonalnoci Feasibility study Studium wykonalnoci jest wczesnym studium problemu i ma na celu ocen, czy rozwi- wykonalne. Zwykle studium okrela zakres problemu, identyfikuje i bada zanie jest kilka rozwiza oraz zaleca dziaania, jakie nale y podj. Czci prac zwizanych z opracowywaniem mo liwych rozwiza s obliczenia do zarysu Uzasadnienia Biznesowego dla dego z nich, jako jeden z aspektw por ka wnawczych. System Quality system jakoci System Patrz: zarzdzania jakoci. System zarzdzania Quality management system jakoci Kompletny zbir standardw jakoci, procedur i obowizkw dla caej organizacji lub jej czci. Sytuacja nadzwyczajnaktrej przewiduje Sytuacja, w odchylenie.
Exception

si wystpienie istotnego odchylenia. Patrz:

Istotne

cie ka Critical path krytyczna Jest to linia czca punkt pocztkowy sieci dziaa z ostatnim dziaaniem w tej sieci, przechodzca przez dziaania, ktre maj zerowe zapasy czasu, tj. dziaania, w przypadku ktrych jakakolwiek zwoka opni termin kocowy realizacji caego planu. cie ek takich mo e by wicej ni jedna. Suma czasw realizacji dziaa na cie ce krytycznej bdzie dat koca realizacji wyznacza planu. Tester Reviewer Osoba wyznaczona do dokonania przegldu pr oduktu poddawanego przegldowi jakoci. Tolerancja Tolerance Dopuszczalne odchylenie poni ej i powy ej oszacowanych w planie czasu i kosztw, wymaga przekazania na wy szy szczebel zarzdzania. Dla czasu i dla ktre nie kosztw by okrelone odrbne tolerancje. Mog by tak e okrelone wartoci powinny tolerancji dla jakoci, zakresu, korzyci i ryzyka. Tolerancj stosuje si na poziomach projektu, eta- zespou. pu i Ustpstwo Concession Odstpstwo, ktre zostao zaakceptowane przez Komitet Sterujcy bez koniecznoci podejmowania dziaa korygujcych.

371

GLOSSARY

PRINCE2

Uzasadnienie Biznesowe Business Case Informacja, ktra zawiera uzasadnienie rozpoczcia i kontynuacji projektu zarzdzanego zgodnie z PRINCE2. Opisuje powody podjcia projektu (oraz odpowiada na pytanie Dlaczego?). Zarys Uzasadnienia Biznesowego powinien znale si w Zleceniu Przygotowania Projektu. Obecno Uzasadnienia Biznesowego weryfikowana jest w ramach Projektu oraz poddawana przegldom; wersja bardziej obszerna wchodzi w Zao e skad Dokumentu Inicjujcego Projekt. Jest uaktualniana w kluczowych punktach w cigu ca- projektu, np. podczas oceny kocowej ego etapu. U ytkownik(-cy) User(s) Osoba lub grupa, ktra bdzie u ywaa kocowy(-e) produkt(-y) projektu. Wniosek o Wprowadzenie Request for Change Zmiany su cy proponowaniu mody fikacji aktualnej specyfikacji produktu. Jest to rodek jeden z rodzajw Zagadnie Projektowych. Wsparcie Project Support Projektu Projektu jest rol administracyjn w zespole zarzdzania projektem. Wsparcie Wsparcie mo e by realizowane w postaci rad i pomocy w stosowaniu narzdzi Projektu zarzdzania projektem, wytycznych, usug administracyjnych jak archiwizacja czy gromadzenie danych. Zapewnienie Wsparcia Projektu na formalnej podstawie jest rzeczywistych fakultatywne. Zadania w tym zakresie powinny by wykonywane przez Kierownika Pro- lub delegowane odrbnej jednostce organizacyjnej, w zale noci od potrzeb jektu konkretnego projektu i Kierownika Projektu. Peny opis roli mo na znale w Dodatku Bole w zespole dzania R . zarz projektem Funkcja wsparcia, ktra musi by uwzgldniona, to Zarzdzanie konfiguracj. W zale - oci od rozmiarw projektu i od rodowiska wystpi mo e potrzeba nadania jej n ram formalnych, gdy szybko mo e si sta zadaniem, ktremu Kierownik Projektu bez wsparcia mo e nie sprosta. Szczegowy opis roli Bibliotekarza Konfiguracji mo na znale w Dodatku B Role w zespole dzania . zarz projektem Wykres Gantta Gantt chart Jest to diagram dziaa ujtych w planie na tle czasu, pokazujcy czasy rozpoczcia i zakoczenia dziaa oraz wymagane zasoby. Wymagania Requirements Opis potrzeb u ytkownika. Patrz tak e: Specyfikacja. Wynik/Rezulta Outcome t Pojcie u ywane do okrelenia caoci tego, co projekt powinien dostarczy i po co zosta ustanowiony, skadajcej si ze wszystkich produktw specjalistycznych. Na przykad, by zainstalowany system ko mputer owy z personelem przeszkolonym, by mo e to goytkowa, wsparty nowymi sposobami wykonywania pracy i dokumentacj. Mo e u to by odremontowany i wyposa ony budynek z przeniesionym do niego i pracujcym personelem, czy te nowy produkt wprowadzony na rynek, wraz z zatrudnionym i funkcjo- zespoem sprzeda y i nujcym wsparcia. Wytwrca Producer Rola reprezentujca wytwrc(-w) produktu, ktry podlega przegldowi jakoci. Zazwyczaj peni j osoba, ktra wytworzya produkt lub ktra kierowaa zespoem za to odpowiedzialnym .

37 2

PRINCE2

LEKSYKON TERMINW

Zagadnienie Project Issue Projektowe ywany do okrelenia jakiejkolwiek obawy, zapytania, Wniosku o Termin u Wprowadze- sugestii lub Odstpstwa, zgaszanych w trakcie projektu. Mo e odnosi nie Zmiany, si wszystkiego, co ma cokolwiek wsplnego z do projektem. Zalecenia Dziaa Follow-on Action Recommendation Nastpczych Raport, ktry mo e by wykorzystany jako wejcie do procesu tworzenia Uzasadnienia / Zlecenia Przygotowania Pr ojektu dla dowolnego projektu, bdcego Biznesowego nastpstwem projektu zarzdzanego wedug PRINCE2, oraz do zarejestrowania wszelkich dotyczcych dziaa nastpczych, wynikajcych z nieukoczonych instrukcji produktw niezaatwionych lub Zagadnie Projektowych. Zalecenie zamknicia \i Project closure recommendation projektu przygotowane przez Kierownika Projektu dla Komitetu Sterujcego do Zalecenie przekazania w formie powiadomienia zainteresowanych str on o zamykaniu projektu, gdy na oczekiwa aprobaty Komitetu Sterujcego dla zamknicia mo projektu. Zao enia Projektu Project Brief Opis tego, co nale y wykona w projekcie; jest to udoskonalona i poszerzona wersja Zle- Przygotowania Projektu, ktr zatwierdza Komitet Sterujcy i ktra stanowi cenia wejcie do inicjowania projektu. Zarzdzanie Configuration management konfiguracj zwykle narzdziami programistycznymi dyscyplina, ktra daje Wspierana kierownictwu precyzyjnej kontroli posiadanych aktyww (np. produktw projektu) , mo liwo obejmujca planowanie, identyfikowanie, sterowanie, charakteryzowanie statusu oraz weryfikowanie produktw. Zarzdzanie Project management projektem Planowanie, monitorowanie i kontrolowanie wszystkich aspektw projektu oraz motywowanie wszystkich zaanga owanych w jego realizacj do osignicia celw projektu w terminie, przy okrelonych kosztach, wymaganej jakoci i poziomie wykonania. Zesp zarzdzania Project management team projektem ca struktur zarzdzania projektem, skadajc si z Komitetu Obejmuje Sterujcego, Projektu, wraz z rolami Kierownikw Zespow oraz Nadzoru Kierownika Projektu Wsparcia i Projektu. Zestawienie Statusu Product Status Account Produktw statusach produktw. Wymagane produkty mog by wyr nione Raport o identyfikatorem lub odniesieniem do tej czci projektu, w ktrej s wytwarzane. Zlecenie Przygotowania Project Mandate Projektu Informacja stworzona poza projektem, okrelajca wymagania i warunki, ktra jest wykorzystywana do przygotowania projektu zarzdzanego wedug PRINCE2.

373

DODATEK A

ZARYSY OPISW PRODUKTW

AP PE NDI X A: P ROD UCT DES CRI PTI O NS O UTLI NES

Dodatek zawiera zarysy Opisw Produktw dla standardowych produktw zarzdczych. nie zawieraj wszystkich standardowych nagwkw sekcji i zawartoci Te zarysy treci produktu zarzdczego Opis Produktu, takich jak format oraz wygld czy metoda kon- jakoci. Mog si one r ni midzy projektami i dlatego nie podjto prby troli okrelenia, czego konkretny projekt mo e potrzebowa. przeksztaci te zarysy w pene Opisy Produktw bd musiay doda Osoby chcce bra- informacje. Jest to dobra sposobno do porwnania podanego materiau z kujce warun- konkretnego projektu oraz przystosowania tekstu tak, by lepiej do nich kami pasowa. zawartoci produktu zarzdczego Opis Produktu jest podany w Peny opis A.22. Spis alfabetyczny polskich nazw produktw zarz dczych PRINCE2
Nazwa polska Diagram Nast pstwa Produktw 399 Diagram Struktury Produktw 395 Dokument Inicjuj cy Projekt (DIP) 404 Dziennik 383 Formua Realizacji Projektu 401 Grupa Zada 419 Kryteria Akceptacji 376 Lista Kontrolna Produktw 396 Oczekiwania jako ciowe klienta 382 Odst pstwo 393 Opis Produktu 397 Plan Etapu 417 Plan Jako Projektu 412 ci Plan Komunikacji 379 Plan Nadzwyczajny 386 Plan Projektu 410 Plan Przegl du Poprojektowego 394 Plan Zarz dzania Konfiguracj 381 Raport Ko cowy Etapu 385 Raport Ko cowy Projektu 384 Raport o Do wiadczeniach 392 Raport o Istotnych Odchyleniach 387 Raport Okresowy 389 Raport z Punktu Kontrolnego 378 Rejestr Do wiadcze 391 Rejestr Jako 413 ci Rejestr Ryzyka 415 Rejestr Zagadnie 390 Uzasadnienie Biznesowe 377 Wniosek o Wprowadzenie Zmiany 414 Zagadnienie Projektowe 407 Zalecenia Dziaa Nast pczych 388 Zao enia Projektu 402 Zapis Obiektu Konfiguracji 380 Zestawienie Statusu Produktw 400 Zlecenie Przygotowania Projektu 408 Strona Symbol English name A.23 Product Flow Diagram A.20 Product Breakdown Structure A.27 Project Initiation Document (PID) A.8 Daily Log A.25 Project Approach A.36 Work Package A.1 Acceptance Criteria A.21 Product Checklist A.7 Customers quality expectations A.18 Off-Specification A.22 Product Description A.35 Stage Plan A.31 Project Quality Plan A.4 Communication Plan A.11 Exception Plan A.30 Project Plan A.19 Post-Project Review Plan A.6 Configuration Management Plan A.10 End Stage Report A.9 End Project Report A.17 Lessons Learned Report A.12 Exception Report A.14 Highlight Report A.3 Checkpoint Report A.16 Lessons Learned Log A.32 Quality Log A.34 Risk Log A.15 Issue Log A.2 Business Case A.33 Request for Change A.28 Project Issue A.13 Follow-on Action Recommendations A.26 Project Brief A.5 Configuration Item Record A.24 Product Status Account A.29 Project Mandate

375

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.1. Kryteria Akceptacji

Acceptance Criteria

Nie jest to samodzielny produkt zarzdczy PRINCE2, ale jego zamieszczenie mo e po- w zrozumieniu, jaka mogaby by zawarto takiego mc dokumentu. A.1.1. Cel / Przeznaczenie Okrelenie w mierzalnych kategoriach charakterystyk wymaganych od produktu lub produktw kocowych, aby mogy by zaakceptowane przez klienta i personel, na ktry b- oddziaywa. W wielu przypadkach Kryteria Akceptacji bd takie same, jak d kryteria zawarte w dokumencie Opis Produktu dla produktu jakoci kocowego. A.1.2. Skad Bdzie si zmienia w zale noci od typu produktu kocowego. Proponowane pozycje to: terminy docelowe; podstawowe funkcje; wygld; personel potrzebny przygotowania; wydajno / osigi; do u ycia/eksploatacji produktu i stopie jego

zdolnoci produkcyjne pojemno; dokadno; dostpno;

przetwrcze

niezawodno (redni/maksymalny czas naprawy, redni czas bezusterkowej pracy); koszt wytworzenia; koszty eksploatacji; bezpieczestwo ; atwo u ytkowania; terminy . Pochodzenie / rdo

A.1.3.

Kryteria Akceptacji pochodz od/z: Gwnego U ytkownika; Jakociowych oczekiwa klienta. Kryteria pochodz od kierownictwa programu, albo s opracowywane w procesie PP. A.1.4. Kryteria ci Wszystkie jakokryteria s mierzalne; ka de z kryteriw traktowane niezale nie jest realistyczne; kryteria traktowane jako grupa s realistyczne, np. wysoka jako, wczesna dostawa oraz niskie koszty mog nie by osigalne cznie; Kryteria Akceptacji tworz kompletn list kryteriw, ktra pozwala okreli, co stanowi bdzie pr odukt mo liwy do zaakceptowania przez klienta. 37 6

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.2.
A.2.1.

Uzasadnienie Biznesowe
Cel / Przeznaczenie

Business Case

Udokumentowanie uzasadnienia dla podjcia projektu, opartego na oszacowanych kosz- wytworzenia i wdro enia odniesionych do zagro e (ryzyka) oraz tach przewidywanych korzyci biznesowych i oszczdnoci. Rozwa y nale y ca zmian biznesu, ktra mo e y znacznie szersza ni tylko koszty realizacji b projektu. Uzasadnienie Biznesowe jest wykorzystywane do stwierdzenia, dlaczego przewidywany oraz czasu bd wartociowym nakadem. Komitet Sterujcy powinien nakad pracy na co kontrolowa zasadno pr ojektu w odniesieniu do Uzasadnienia bie Biznesowego. A.2.2. Skad przyczyny, powody, dla ktrych realizuje si projekt; mo liwe warianty (krtki opis r nych wariantw rozwa anych w zwizku z projektem, wraz ze wskazaniem i uzasadnieniem wariantu wyb ranego); oczekiwane korzyci (ujte w mierzalnych kategoriach, w odniesieniu do sytuacji czasie w tworzenia dokumentu); ryzyko (zestawienie gwnych zagro e zwizanych z projektem); koszty (wycig z Planu Projektu); terminy (podsumowanie Planu Projektu); ocena opacalnoci inwestycji; ocena oglna.

A.2.3.

Pochodzenie /

rdo

Informacje do Uzasadnienia Biznesowego pochodz z/od: Zlecenia Przygotowania Projektu i/lub Zao e Projektu (przyczyny); Planu Projektu (koszty i terminy); klienta . Podczas procesu Przygotowanie (PP) sprawdza si, czy przedstawiono Projektu Uzasadnienie Biznesowe. Jeli Zleceniewstpne Przygotowania Projektu nie zawiera Uzasadnienia Biznesowego, nale y je opracowa. Uzasadnienie Biznesowe jest ucilane w trakcie podprocesu Doprecyzowywanie Uzasadnienia Biznesowego i (I P3). Ryzyka A.2.4. Kryteria ci jako Wszystkie korzyci musz by uzasadnione; Plan Projektu oraz Uzasadnienie Biznesowe musz by spjne; przyczyny uruchomienia projektu musz by zgodne ze strategi firmy lub strategi 40 . programu

40

W ramach ktrego realizowany jest projekt przypis tumacza.

377

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.3. Raport z Punktu Kontrolnego

A.3.1.
Cel / Przeznaczenie

Checkpoint Report

Raportowanie z czstotliwoci okrelon w Planie Etapu i/lub w Grupie Zada stanuka dego czonka zespou. prac Skad Data przegldu w punkcie kontrolnym; okres sprawozdawczy objty raportem; dziaania nastpcze z poprzednich raportw; dziaania realizowane w okresie sprawozdawczym; produkty zakoczone w tym okresie; prowadzone w tym okresie prace zwizane z jakoci; stan tolerancji dla Grupy Zada; zaistniae lub potencjalne problemy oraz uaktualnienie zagro enia; prace planowane na nastpny okres sprawozdawczy; produkty, ktre maj by ukoczone w nastpnym okresie. A.3.3. Pochodzenie / rdo Ustne sprawozdania czonkw zespou; Plan Etapu lub Plan Zespou; poprzedni punkt kontrolny (narady w punktach kontrolnych s czci podprocesu Wykonywanie Grupy (WP2)). Zada A.3.4. Kryteria ci jako Uwzgldniono wszystkie pozycje Planu Etapu lub Planu Zespou dla danego okresu; ka dy czonek zespou pracuje zgodnie z uzgodnionym harmonogramem; w raporcie uwzgldniono wyniki prac wszystkich czonkw zespou; przedstawiono informacj o wszystkich problemach wymienionych w poprzednim ktre raporcie, s nadal nierozwizane.

A.3.2.

37 8

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.4.
A.4.1.

Plan Komunikacji
Cel / Przeznaczenie

Communication Plan

Okrelenie wszystkich stron zainteresowanych projektem. Obejmuje opis rodkw komunikacji i czstoci komunikowania si ka dej ze stron z zespoem projektowym. A.4.2. Skad Wykaz zainteresowanych stron (np. interesariusze, pracownicy ksigowoci, forum u ytkownikw, audyt wewntrzny, nadzr jakoci); wymagane informacje; dostawca informacji; czsto komunikacji; metoda komunikacji; format komunikatu. A.4.3. Pochodzenie / rdo Komitet Sterujcy; struktura zespou zarzdzania projektem; Zao enia Projektu; Plan Jakoci Projektu; Formua Realizacji Projektu. A.4.4. Kryteria ci Wszystkie jako wymienione rda danych obowizkowo zostay sprawdzone; zdefiniowano wszystkich interesariuszy i okrelono ich potrzeby komunikacyjne; ze wszystkimi zainteresowanymi stronami uzgodniono zawarto przekazywanych informacji, czsto oraz metody ko munikowania si; uzgodniono wsplne standardy; w Planach Etapu przydzielono czas niezbdny do zrealizowania przewidzianej komunikacji .

379

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.5. Zapis Obiektu Konfiguracji

A.5.1.
Cel / Przeznaczenie statusie/stanie Zapis informacji o produktu. A.5.2. Skad Identyfikator projektu; typ produktu; nazwa produktu;

Configuration Item Record

nu mer najnowszej wersji; Opis Produktu;

opis faz cyklu ycia waciwych dla produktu; waciciel produktu; osoba pracujca nad produktem; data przydzielenia; biblioteka lub lokalizacja, gdzie produkt jest przechowywany; rdo pochodzenia np. wytworzony w firmie lub zakupiony od firmy zewntrznej; zwizki z produktami powizanymi; status ; posiadacze kopii produktu oraz potencjalni u ytkownicy; odwoania do Zagadnie Projektowych, ktre spowodoway zmiany produktu; odwoania do korespondencji dotyczcej produktu. A.5.3. Pochodzenie / rdo Diagram Struktury Produktw; Plany Etapu i Plany Zespow; Grupa Zada; Rejestr Jakoci; Rejestr Zagadnie. Kryteria ci jako Zapis dokadnie odzwierciedla status produktu; wszystkie Zapisy Obiektw Konfiguracji s przechowywane razem w bezpiecznym miejscu ; nu mer wersji w zapisie odpowiada rzeczywistej wersji produktu; informacja o posiadaczach kopii jest prawidowa; kopie znajdujce si u ich posiadaczy maj numer wersji zgodny z nu merem poda-w zapisie. ny m

A.5.4.

38 0

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.6.
A.6.1.

Plan Zarz dzania Konfiguracj

Cel / Przeznaczenie

Configuration Management Plan

Okrelenie, w jaki sposb i przez kogo produkty projektu bd kontrolowane i zabezpieczane.

A.6.2.

Skad

Plan jest czci Planu Jakoci Projektu. Zawiera: wyjanienie celu zarzdzania konfiguracj; opis (lub odniesienie) metody zarzdzania konfiguracj, ktra ma by zastosowana. no w stosunku do standardw firmowych Ka da rozbie programu powinna by lub uwypuklona z podaniem uzasadnienia tej rozbie noci; odniesienie do wszelkich systemw zarzdzania konfiguracj lub narzdzi, ktre b- zastosowane, a z ktrymi powizania bd d konieczne; informacj, w jaki sposb i gdzie magazynowane bd produkty (np. struktura dokumentacji projektu); informacj, jakie mechanizmy bezpieczestwa skadowania i odzyskiwania bd zastosowane; wyjanienie, w jaki sposb bd identyfikowane produkty i ich r ne wersje; okrelenie, kto ponosi odpowiedzialno za Zarzdzanie konfiguracj. A.6.3. Pochodzenie / rdo Szczegy planu mog pochodzi z/od: Systemu zarzdzania jakoci klienta; SZJ dostawcy;

(SZJ)

okrelonych wymaga, wynikajcych z potrzeb produktw i otoczenia projektu; struktury organizacyjnej projektu; opisu oprogramowania wspomagajcego Zarzdzanie konfiguracj stosowanego lub wymaganego przez klienta. A.6.4. Kryteria ci Obowizki jakojasne i zrozumiane zarwno przez klienta, jak i s dostawc; zdefiniowany jest kluczowy identyfikator dla produktw projektu; metody i uwarunkowania kontroli wersji s jasne; plan zapewnia Kierownikowi Projektu kompletn informacj o wszystkich pr oduktach.

381

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

Customers quality expectations Oczekiwania jakociowe klienta nie s samodzielnym produktem zarzdczym PRINCE2, ale ich wczenie do tego dodatku powinno pomc w zrozumieniu, jaka powinna by zawarto takiego dokumentu.

A.7. Oczekiwania jako

ciowe klienta

A.7.1.
Uchwycenie jakoci.

Cel / Przeznaczenie aspiracji Skad klienta zwizanych z

A.7.2.

Oczekiwania jakociowe klienta powinny zosta okrelone w Zao eniach Projektu. For- ich przedstawienia mo e by r norodny. Mo na rozwa y nastpujce mat pytania: Jakie elementy obowizujcego u klienta systemu zarzdzania jakoci powinny zo- wykorzystane? sta Jakie inne standardy powinny by wzite pod uwag przy planowaniu projektu? Jakie rozwizania wprowadzono do zarzdzania zmianami biznesu? Jakie rozwizania wprowadzono, aby umo liwi efektywne zarzdzanie personelem/klientami, ktrych dotyczy bd zmiany? Co zrobiono, aby umo liwi organizacji zarzdzanie tymi zmianami po zakoczeniu projektu? Jaki stopie satysfakcji zespou powinien zosta osignity, jeli bdzie si go badao? Jaki stopie satysfakcji klienta powinien zosta osignity, jeli bdzie si go badao? Pochodzenie / rdo

A.7.3.

Oczekiwania jakociowe klienta pochodz od/z: Gwnego U ytkownika; oczekiwa klienta. Te kryteria dostarczane s albo przez kierownictwo programu, albo opracowywane pod- procesu Przygotowanie czas (PP). Projektu A.7.4. Kryteria ci jako Oczekiwania jakociowe klienta tworz kompletn list wymogw, ktrych spenienie pozwoli klientowi zaakceptowa kocowy produkt projektu. Oczekiwania jakociowe klienta powinny by wyra one w taki sposb, aby na ich podstawie mo na byo ustali Kryteria Akceptacji.

38 2

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.8.
A.8.1.

Dziennik
Cel / Przeznaczenie

Daily Log

Zapisywanie wymaganych dziaa lub wa nych wydarze, ktrych nie uwzgldniaj inne dokumenty PRINCE2. To rodzaj pamitnika Kierownika Projektu lub Kierownika Zespou.

A.8.2.

Skad Data zapisu;

dziaanie lub komentarz; osoba odpowiedzialna; termin realizacji; rezultat . A.8.3. Pochodzenie / Rejestr Ryzyka; Plan Etapu;

rdo

Raporty z Punktw Kontrolnych

Rejestr Jakoci; rozmowy i obserwacje. A.8.4. Kryteria ci Wpisy s jako zrozumiae tak e po pewnym czasie; wszystkie informacje o trwaym charakterze s przenoszone w formie odpowiednich zapisw np. Zagadnienia powinny by wprowadzane do Rejestru ZaProjektowe gadnie; data, osoba odpowiedzialna oraz termin realizacji s zawsze wpisywane.

383

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.9. Raport Ko cowy Projektu

A.9.1.
Cel / Przeznaczenie

End Project Report

Jest to raport Kierownika Projektu dla Komitetu Sterujcego (ktry mo e przekaza go dalej kierownictwu firmy lub programu) na temat tego, jak wykonano projekt w porw- z ustaleniami zawartymi w Dokumencie Inicjujcym Projekt, wczajc w to naniu pierwotnie planowany koszt, harmonogram i tolerancje, uaktualnione Uzasadnienie Bizne- oraz kocow wersj Planu sowe Projektu. A.9.2. Skad
Stopie osignicia celw projektu; przegld korzyci, uzyskanych do dnia raportowania (jeli takie uzyskano); osignite wyniki w porwnaniu z planowanymi terminami, kosztami i tolerancjami; efekty wpywu wszelkich zatwierdzonych zmian na pierwotny Plan Projektu i pierwotne Uzasadnienie Biznesowe; kocowe dane liczbowe o Zagadnieniach Projektowych, zgoszonych podczas projektu; oglny, cakowity wpyw wszystkich zatwierdzonych zmian; dane liczbowe o wszystkich pracach przeprowadzonych w obszarze jakoci. termin i Plan Przegldu Poprojektowego.

A.9.3.

Pochodzenie /

rdo

Raport Kocowy Projektu wywodzi si z:

uaktualnionego Planu Projektu (cznie z Planami Zespow, Planami Etapw i Planami Nadzwyczajnymi); Dokumentu Inicjujcego Projekt; Rejestru Ryzyka; Rejestru Jakoci; Uzasadnienia Biznesowego; Raportu(-w) o Dowiadczeniach; Raportu(-w) Kocowych Etapw; Rejestru Zagadnie; Planu Przegldu Poprojektowego.

Raport Kocowy Projektu jest sporzdzany w Zamykanie procesie Projektu A.9.4. Kryteria ci jako Raport opisuje oddziaywanie zatwierdzonych zmian na Dokument Inicjujcy Projekt;

(ZP).

raport uwzgldnia wszystkie korzyci, ktre mogy by ocenione w momencie jego opracowywania; prace zwizane z jakoci wykonane w trakcie trwania projektu zaspokoiy Oczekiwania jakociowe klienta.

38 4

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.10. Raport Ko cowy Etapu

A.10.1.
Cel / Przeznaczenie

End Stage Report

Przedstawienie podsumowania postpw do dnia raportowania, caociowej sytuacji pro- or az informacji wystarczajcych, by wystpi do Komitetu Sterujcego o jektu decyzj, dotyczc kontynuacji projektu. Komitet Sterujcy wykorzystuje informacje zawar te w Raporcie Kocowy m Etapu do podjcia decyzji, jakie dziaania nale y przedsiwzi w stosunku do projektu: zezwoli na realizacj nastpnego etapu, za da Planu Etapu (nastpnego), wnie weryfikacji do zakresu projektu czy zatrzyma poprawki projekt. A.10.2. Skad Plan Etapu (bie cego) i wszelkie dane o faktyczny m jego wykonaniu; porwnanie uzyskanych wynikw z tolerancjami etapu; stan realizacji Planu Projektu; przegld Uzasadnienia Biznesowego; przegld ryzyka; stan Zagadnie Projektowych; dane liczbowe dotyczce jakoci; raport Kierownika Projektu na temat wszelkich wydarze, ktre wpyny na wyko-etapu. nanie

A.10.3.

Pochodzenie /

rdo

Informacje do raportu s uzyskiwane z: Planu Etapu z naniesionymi infor macjami o wyko naniu; Planu Etapu (nastpnego) - jeli jest to waciwe; uaktualnionego Planu Projektu; Rejestru Ryzyka; Rejestru Dowiadcze; Rejestru Jakoci; Rejestru Zagadnie; Raportu o Istotnych Odchyleniach lub\i Nadzwyczajnego; danych dotyczcych ukoczonych Grup Zada.

Planu

Raport Kocowy Etapu stanowi wyjcie z procesu

A.10.4.
385

Zar dzanie z Etapu

Zakresem

(ZE).

Kryteria ci jako Raport dokadnie odzwierciedla wykonanie etapu w porwnaniu z planem; opisano wszelkie odbiegajce od normy sytuacje, wraz z ich oddziaywaniem; wszyscy penicy rol Nadzoru Projektu zgadzaj si z treci raportu.

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.11. Plan Nadzwyczajny

A.11.1.
Cel / Przeznaczenie

Exception Plan

Plan Nadzwyczajny to plan opracowywany na u ytek odpowiedniego szczebla zarzdzania, pokazujcy niezbdne dziaania, ktre nale y przedsiwzi, aby mc zaradzi skut- przekroczenia tolerancji. Jest on oparty na rekomendacjach przedstawionych w kom Raporcie o Istotnych Odchyleniach. Plan Nadzwyczajny mo e zastpi dotychczasowy Plan Projektu, Plan Etapu lub Plan Zespou. Jeli zostanie zatwierdzony, zastpuje plan, w ktrym wystpiy istotne odchy- i staje si nowym lenia, odniesienia odpowiednio dla Planu Projektu, obiektem zale nie od konkretnej Etapu Zespou sytuacji. A.11.2. Skad Plan Nadzwyczajn, ktry zastpuje Plan Projektu ma skad przedstawiony w Opi-Pr oduktu dla Planu Projektu ( Dodatek sie A.30.2); Plan Nadzwyczajny, ktry zastpuje Plan Etapu ma skad przedstawiony w Opisie Produktu dla Planu Etapu (Dodatek A.35.2). Zwykle zmiana dokonana w Planie prowadzi bdzie do aktualizacji Planu Projektu, ale ta zmiana nie Etapu powinna wpywa na oglne tolerancje projektu; Dla Planu Nadzwyczajnego, ktry zastpuje Plan Zespou - bdcy przecie planem opcjonalnym, nale y zastosowa lokalne procedury planistyczne i skad aktualnie obowizujcego planu. Zwykle zmiana dokonana w Planie Zespou prowadzi b- do aktualizacji Planu Etapu, ale ta zmiana nie powinna wpywa na oglne dzie tolerancje etapu. A.11.3. Pochodzenie/ rdo Ten plan wywodzi si z: planu, od ktrego wystpiy istotne odchylenia; Zagadnienia Projektowego, w ktrym tkwi powd odchylenia. A.11.4. Kryteria ci Plan jest jako mo liwy do wykonania; wzito pod uwag wszystkie aspekty jakociowe zawarte w zarysach Opisw Produktw dla Planu Projektu lub Planu Etapu; plan koryguje odchylenia okrelone w zwizanym z nim Raportem o Istotnych Odchyleniach ; plan jest zgodny z decyzjami podjtymi po przedstawieniu Raportu o Istotnych Odchyleniach ; dla Planu Nadzwyczajnego zdefiniowano nowe tolerancje.

lub

38 6

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.12. Raport o Istotnych Odchyleniach

A.12.1.
Cel / Przeznaczenie

Exception Report

Raport o Istotnych Odchyleniach sporzdzany jest, gdy przewiduje si, e zatwierdzony Plan Etapu lub Plan Projektu wyjdzie poza ustalone dla niego granice Plan Zespou, tolerancji. Raport jest przygotowywany przez waciwego kierownika w celu poinformowania nastpnego, wy szego szczebla zarzdzania o niepo danej sytuacji. A.12.2. Skad Opis przyczyny odchylenia od odnonego planu; konsekwencje odchylenia; mo liwe opcje; wpyw ka dej opcji na Uzasadnienie Biznesowe, ryzyko i tolerancje; rekomendacja ze strony Kierownika Projektu lub Kierownika Zespou. A.12.3. Pochodzenie / rdo Informacje do Raportu o I stotnych Odchyleniach mog pochodzi z: aktualnego planu i danych o jego faktycznym wykonaniu; Rejestru Zagadnie; Rejestru Ryzyka; Planu Projektu; Rejestru Jakoci; Raportw Okresowych; Raportw z Punktw Kontrolnych; zalece Komitetu Sterujcego, dotyczcych zewntrznych wydarze, ktre wpywaj na projekt.

Jeli istotne odchylenia dotycz Planu Etapu lub Planu Projektu, Raport o Istotnych Odchyleniach bdzie wyjciem Przekazywanie Projektowyc (SE8). podprocesu odchylenia dotycz Planu Zespou, Raport o Istotnych hOdchyleniach Zagadnie Jeli istotne bdzie wyjciem podprocesu Wykonywanie Grupy (WP2) i przekazany zostanie Zada Zagadnienie Kierownikowi Projektu jako Projektowe. A.12.4. Kryteria ci jako musi dokadnie pokazywa stan bud etu i Aktualny plan harmonogramu; musz by wymienione przyczyny odchylenia(e).

387

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.13. Zalecenia Dziaa

A.13.1.

Nast pczych
Follow-on Recommendations Action

Cel / Przeznaczenie

Przekazanie szczegw dotyczcych nieukoczonych prac, istniejcych zagro e (ryzyka) lub potencjalnych modyfikacji produktu, grupie zobowizanej do utrzymywania produktu kocowego w trakcie jego eksploatacji. A.13.2. Skad Data opracowania zalece; zestawieni Wnioskw o Wprowadzenie Zmiany, ktre uznano za istotne, ale e wdro ono nie w trakcie ich projektu; zestawienie Odstpstw zawierajce wykaz produktw, ktrych nie dostarczono i/lub wykaz produktw, ktre nie speniaj pierwotnych wymaga; zagro enia (ryzyko) zidentyfikowane w trakcie projektu, ktre mog wpyn na produkt podczas jego eksploatacji; wszelkie zidentyfikowane potrzeby niezbdnych dostaw lub szkole; wszystkie inne dziaania potrzebne do przekazania produktu do nastpnego etapu jego okresu ycia. A.13.3. Pochodzenie / rdo Rejestr Zagadnie; Raport o Dowiadczeniach; Rejestr Jakoci; Rejestr Ryzyka . Kryteria ci jako tego 41 Zagadnienia Projektowego musi istnie stosowny Dla ka dego otwar zapis w zaleceniach; 42 odpowiednie Zagadnienia Projektowe powinny by zapisem zamknite zostay przeniesione do omawianych oznaczajcym, e zalece; wszelka dostpna i u yteczna dokumentacja lub wiadectwa (dowody) powinny by doczone do zalece.

A.13.4.

41 42

Niezaatwionego przypis tumacza. W Rejestrze Zagadnie przypis tumacza.

38 8

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.14. Raport Okresowy

A.14.1.
Cel / Przeznaczenie

Highlight Report

Dostarczenie Komitetowi Sterujcemu (lub ewentualnie inny m interesariuszom) podsumowania stanu etapu w okrelonych przez nich odstpach czasu. Komitet Sterujcy wykorzystuje raport do monitorowania postpw etapu i projektu. Kierownik Projektu wykorzystuje go do powiadomienia Komitetu Sterujcego o wszelkich potencjalnych problemach lub obszarach, w ktrych Ko mitet Sterujcy mo e pomc. A.14.2. Skad Data opracowania raportu; okres sprawozdawczy; stan realizacji bud etu; stan zaawansowania harmonogramu; produkty zakoczone w okresie sprawozdawczym; faktyczne lub potencjalne problemy oraz uaktualnione ryzyko; produkty, ktre maj by ukoczone w nastpnym okresie; stan Zagadnie Projektowych; wpyw wszelkich zmian na bud et i harmonogram; sytuacja projektu wzgldem toler ancji. A.14.3. Pochodzenie / rdo Informacje do Raportw Okresowych pochodz z: Raportw z Punktw Kontrolnych; Rejestru Zagadnie; Dokumentu Inicjujcego ojekt; uaktualnionego Plan Etapu; informacji o stanie etapu; Rejestru Jakoci; Rejestru Ryzyka;

Pr

Planu Komunikacji. Raporty okresowe stanowi wyjcia z Raportowanie podprocesu Okresowe A.14.4. Kryteria ci jako Dokadne odzwierciedlenie informacji z punktw kontrolnych; dokadne podsumowanie Rejestru Zagadnie; dokadne podsumowanie stanu realizacji planu; uwypuklenie wszystkich obszarw potencjalnych problemw. 389

(SE6).

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.15. Rejestr Zagadnie

A.15.1.

Issue Log

Cel / Przeznaczenie

Celem Rejestru Zagadnie jest: przypisanie niepowtarzalnego numeru do ka dego Zagadnienia Projektowego; zarejestrowanie rodzaju Zagadnienia Projektowego; podsumowanie wszystkich Zagadnie Projektowych, ich analiz i statusu. A.15.2. Skad Numer Zagadnienia Projektowego; rodzaj Zagadnienia Projektowego (Wniosek o Wprowadzenie Zmiany, Odstpstwo, oglna kwestia lub wyraz zaniepokojenia); autor zgoszenia; data zidentyfikowania zagadnienia; data ostatniej aktualizacji; opis; priorytet ; status. Pochodzenie / rdo

A.15.3.

Zagadnienia Projektowe mog by wniesione w ka dym czasie, przez ka d osob powizan z projektem. A.15.4. Kryteria ci jako Status wskazuje, czy dziaanie zostao podjte; Zagadnienia Projektowe s jednoznacznie zidentyfikowane wraz ze wskazaniem produktu, ktrego dotycz; dostp do Rejestru Zagadnie jest kontrolowany; Rejestr Zagadnie jest przechowywany w bezpiecznym miejscu.

39 0

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.16. Rejestr Do wiadcze

A.16.1.
Cel / Przeznaczenie

Lessons Learned Log

Rejestr Dowiadcze ma by to repozytorium (skadnica) wszelkich dowiadcze nabytych podczas realizacji projektu, ktre mog by z po ytkiem zastosowane w innych pr ojektach. Podczas zamykania projektu jest on formalnie przeksztacany w Raport o Dowiadczeniach. Rejestr powinien by aktualizowany przynajmniej na koniec ka de- etapu, lecz sensownie jest wprowadza do niego zapisy dobrych lub zych go dowiadcze, wynikajcych z u ywania produktw zarzdczych i specjalistycznych oraz narz- bezporednio dzi, w momencie gdy ich dowiadczono. A.16.2. Skad Informacja o tym, ktr e procesy zarzdcze i procesy dotyczce jakoci: przebiegy dobrze; przebiegy le; ktrych brakowao; opis wszelkich odbiegajcych od normy wydarze powodujcych odchylenia; uwagi dotyczce sprawdzania si specjalistycznych metod oraz u ytych narzdzi; zalecenia dla przyszej poprawy lub modyfikacji metody zarzdzania projektem; u yteczne dane o rzeczywistej pracochonnoci wytworzenia r nych produktw; uwagi na temat efektywnych i nieefektywnych przegldw jakoci oraz innych testw, obejmujce tak e przyczyny ich dobrego lub zego przebiegu. A.16.3. Pochodzenie / rdo Informacje wpisywane do Rejestru Dowiadcze pochodz z: obserwacji i dowiadcze, wynikajcych z praktycznej realizacji procesw; Rejestru Jakoci; zakoczonych Grup Zada; Rejestru Ryzyka; Raportu(-w) Okresowego(ych); Raportw z Punktw Kontrolnych;

Planw Etapw wraz z danymi o ich faktycznym wykonaniu. A.16.4. Kryteria ci Ka dy jako element sterowania zarzdczego zosta uwzgldniony; zapisano przyczyny odchyle poza toler ancje oraz dziaania naprawcze; zapisw w rejestrze dokonuje si przynajmniej na koniec ka dego etapu; Nadzr oraz Wsparcie Projektu poproszono o wkad w opracowanie zapisw; w rejestrze zawarto dane liczbowe dotyczce powodzenia przegldw jakoci oraz testw. innych

391

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.17. Raport o Do wiadczeniach

A.17.1.
Cel / Przeznaczenie

Lessons Learned Report

Przekazanie dowiadcze, ktre mog by z po ytkiem zastosowane w innych projektach. Dane z raportu powinny by wykorzystane przez takie grupy w firmie, jak nadzr jakoci odpowiedzialny za system zapewnienia jakoci, aby udoskonali, zmieni oraz poprawi standar dy. Dane liczbowe o rzeczywistej pracochonnoci, ktrych wymagay produkty, mog pomc poprawi przysze jej szacowania. A.17.2. Skad Opis procesw zarzdczych oraz procesw dotyczcych jakoci, ktre: przebiegy dobrze; przebiegy le; ktr ych brakowao; opis wszelkich odbiegajcych od normy wydarze, powodujcych odchylenia; ocena u ywanych metod technicznych i narzdzi; analiza Zagadnie Projektowych i ich wynikw; zalecenia dla przyszej poprawy lub modyfikacji metody zarzdzania projektem; u yteczne dane o pracochonnoci wytworzenia r nych produktw; dane liczbowe dotyczce efektywnoci przegldw jakoci i innych testw w wykrywaniu bdw (np. ile bdw zostao znalezionych po wczeniejszym przejciu przez przegld jakoci lub produktw test). A.17.3. Pochodzenie / rdo Informacje wykorzystywane do sporzdzenia raportu pochodz z: Rejestru Dowiadcze; Raportw Kocowych Etapw;

Rejestru Jakoci; Rejestru Zagadnie. Raport o Dowiadczeniach podprocesie (ZP3) .

jest

sporzdzany

Przegl d Oceniaj cy Projekt

A.17.4.

Kryteria ci jako Ka dy element sterowania zarzdczego zosta uwzgldniony; wczono dane liczbowe o skutecznoci przegldw rodzajw testw;

jakoci

oraz

innych

podano szczegy dotyczce pracochonnoci zwizanej z ka dym z produktw.

39 2

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.18. Odst pstwo

A.18.1.
Cel / Przeznaczenie

OffSpecification

Udokumentowanie ka dej sytuacji, w ktrej produkt nie spenia lub pr zewiduje si, e nie speni wymaga jego specyfikacji. A.18.2. Skad Data zgoszenia; numer w Rejestrze Zagadnie; status ; opis odstpstwa od specyfikacji; oddziaywanie (konsekwencje) odstpstwa; oszacowanie priorytetu; decyzja; (jeli jest to

szczegy przydzielenia celowe); data przydzielenia; data zaatwienia. A.18.3. Pochodzenie /

rdo

Odstpstwo mo e by zgoszone w dowolnym momencie przez ka dego, kto jest zwiza- projektem. Bdzie ono przyjte jako cz ny z Rejestrowanie podprocesu Zagadnie Projektowyc (SE3). Kierownik Projektu mo e tak e w trakcie Analizowani h podprocesu (SE4) podj decyzj, e Odstpstwem jest ktre ze e Zagadni Projektowyc e h Projektowych zgoszonych Zagadnie .

A.18.4.

Kryteria jako Zarejestrowane w Zagadnie; dokadny opis problemu.

ci Rejestrze

393

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.19. Plan Prz egl du Poprojektowego

A.19.1.
Cel / Przeznaczenie

Post-Project Review Plan

Okrelenie na u ytek Przewodniczcego, w jaki sposb i w jakim terminie bdzie mo na zmierzy stopie osignicia korzyci z projektu. Plan jest przedstawiany Przewodniczcemu na zakoczenie projektu. Plan musi uwzgldnia nakad pracy na zbadanie: czy w wyniku u ytkowania produktw zostay osignite oczekiwane korzyci; czy u ytkowanie produktu(-w) spowodowao jakiekolwiek problemy. Dla ka dej z oczekiwanych korzyci powinno si oceni stopie jej osignicia w momencie przegldu lub dodatkowy czas, ktry bdzie potrzebny do zmaterializowania si korzyci. U ytkowanie produktu mo e przynie nieoczekiwane efekty uboczne tej zarwno korzystne, jak i niekorzystne. Nale y przewidzie czas i pracochonno niezbd- udokumentowania wyjanie, dlaczego te efekty uboczne nie zostay ne do przewidziane. uwzgldnia czas na przygotowanie zalece dotyczcych sposobu Plan musi osignicia lub powikszenia korzyci albo przeciwdziaania problemom. A.19.2. Skad Sposb pomiaru osignicia oczekiwanych korzyci; terminy pomiaru r nych korzyci; zasoby potrzebne do przeprowadzenia prac zwizanych z przegldem; inne obszary, np. reakcja u ytkownika, ktre mog wymaga rozwa enia. A.19.3. Pochodzenie / rdo Uzasadnienie Biznesowe; dyskusja z u ytkownikami oraz osobami obsugujcymi produkt. Przegld poprojektowy jest planowany jako cz Okr lenie Na podprocesu (ZP2), ale Przewodniczcy jest odpowiedzialny za e Dziaa e s pczyc zapewnienie, t h odbdzie przegld si po zakoczeniu projektu. A.19.4. Kryteria ci jako wszystkie korzyci wymienione w Uzasadnieniu Plan obejmuje Biznesowym; zamieszczono odpowiednie terminy dla pomiaru korzyci, wraz z ich uzasadnieniem; okrelono kwalifikacje lub osoby niezbdne do przeprowadzania pomiarw; plan jest realistyczny w kategoriach niezbdnej pracochonnoci, gdy si j porwna do przewidywanych korzyci.

39 4

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.20. Diagram Struktury Produktw

A.20.1.
Cel / Przeznaczenie

Product Breakdown Structure

Pokazanie wszystkich produktw, ktre maj by wytworzone i ktrych jako ma by skontrolowana. Zrozumienie skadu i funkcji wszystkich produktw, ktre maj by wytworzone.

A.20.2.

Skad

Diagram w ukadzie od gry do dou pokazujcy podzia wszystkich produktw, ktre wykona. Produkty zewntrzne musz by uwzgldnione w Diagramie trzeba Struktury Produktw i wyr anie odr nione od produktw wytwarzanych w projekcie. Konwencj jest oznaczenie produktw projektu jako prostoktw, grup produktw PRINCE2 jako rwnolegobokw, a produktw zewntrznych jako elips. A.20.3. Pochodzenie / rdo Zao enia Projektu; Plan Jakoci Projektu. A.20.4. Kryteria ci jako Wszystkie zewntrzne produkty oraz produkty projektu zostay uwzgldnione; Diagram Struktury Produktw jest zgodny z List Kontroln Produktw; prawdziwe produkty integracji (tj. produkty, ktre nie s produktami najni szego poziomu, a wymagaj oddzielnych Opisw Produktw) s odr nione od grup pr oduktw (majcych jedynie wspiera zrozumienie struktury); zidentyfikowano i rozr niono produkty zarzdcze i specjalistyczne; Opisy Pr oduktw dla produktw najni szego poziomu mo na sporzdzi bez potrzeby dalszej dekompozycji; zidentyfikowano wystarczajc liczb produktw na najni szym poziomie, by spro- wymaganiom planowania i kontroli sta zarzdczej; kombinacja wszystkich zidentyfikowanych produktw speni potrzeb biznesow; zidentyfikowano wszystkie pr odukty dotyczce jakoci, ktre speniaj potrzeby audytu i Nadzoru Projektu w sposb opisany w Planie Jakoci klienta, Projektu.

395

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.21. Lista Kontrolna Produktw

A.21.1.
Cel / Przeznaczenie

Product Checklist

Wyszczeglnienie produktw, ktre nale y wytworzy w ramach Planu Etapu, wraz z kluczowymi datami dotyczcymi ich statusu. Wykorzystywana przez Komitet Sterujcy do monitorowania postpu prac. A.21.2. Skad Okrelenie planu, ktrego lista dotyczy; nazwy produktw (oraz nu mery porzdkowe, jeli jest to celowe); planowane oraz faktyczne daty osignicia: gotowoci produktu do przegldu; sprawdzenia jakoci; zatwierdzenia (odbioru). A.21.3. Pochodzenie / rdo Uzyskana na podstawie Diagramu Nastpstwa Produktw. Powstaje jako wyjcie z Okr lenie i Analizowanie (PL2) podprocesu Produktw przyjmuje ostateczn posta w e Kompletowanie (PL7) oraz podprocesie Planu aktualizowana w procesie Sterowanie (SE). Etapem A.21.4. Kryteria ci Informacje jako s zgodne z zawartymi w Planie i daty Etapu.

i jest

39 6

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.22. Opis Produktu

A.22.1.
Cel / Przeznaczenie

Product Description

Celami s: Zrozumienie szczegowej natury, przeznaczenia i funkcji produktu; okrelenie rde informacji lub dostawy dla produktu; opisanie wymaganego wygldu produktu; okrelenie poziomu jakoci wymaganego od produktu; umo liwienie okrelenia dziaa wymaganych dla wytwarzaniu i kontroli jakoci produktu; okrelenie osb lub umiejtnoci potrzebnych do wytworzenia i sprawdzenia produktu. Skad Identyfikato : niepowtarzalne oznaczenie, zwykle przyznawane produktowi w r ramach metody zarzdzania konfiguracj. Nazwa : okrelenie, pod ktrym produkt jest znany. Przeznaczeni : okrela cel, ktremu produkt bdzie su y. Czy produkt jest e rodkiem do realizacji celu, czy celem samym w sobie? Pomocne jest zrozumienie funkcji produktu, rozmiaru, jakoci, zo onoci, trwaoci itd. Ska : jest to lista czci produktu. Na przykad, jeli produkt jest dokumentem, mo d gaby - to by lista planowanych rozdziaw lub podrozdziaw. Pochodzenie rd : okrela, jakie s rda, z ktrych produkt si wywodzi, / o np.: konstrukcja wywodzi si ze specyfikacji; produkt jest zakupiony od dostawcy; wykaz oczekiwanych korzyci otrzymany od u ytkownika; produkt jest uzyskany od innego wydziau lub zespou. Format oraz d: wszelki standardowy wygld, jaki produkt powinien wygl mie. Przydzielony osoba, grupa lub umiejtnoci niezbdne do wytworzenia tego : produktu. Kryteria : zgodnie z jak specyfikacj jakoci pr odukt musi by c jako jakie pomiary jakoci bd zastosowane przez badajcych ukoczony i wytworzony oraz produkt. by proste odniesienie do jednego lub kilku powszechnych standardw Mo e to udokumentowanych gdzie indziej, mo e to by te pene objanienie jakiego przyrzdu pomiarowego, ktry ma by zastosowany. Metoda kontroli jakiego r odzaju sprawdzenie jakoci, np. test, badanie ci jako : lub przegld, ma by zastosowane do sprawdzenia jakoci lub funkcjonalnoci produktu?

A.22.2.

397

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2 Tolerancja dla : Informacje o c przedziale wartoci kryteriw jako jakoci, w obrbie ktrego mo i liwe bdzie zaakceptowanie produktu. Mo e temu towarzyszy sekwencja przedziaw czasu, w ktrych wymaga si poprawiania jakoci produktu, tak aby pozostawaa ona w granicach tolerancji. Umie tn i/lub osoby wymagane do sprawdzenia ci obejmuje ci albo j o ktre maj sprawdzi jako, wskazanie wymaganych do tego jako : okrelenie osb, umiejtnoci albo wskazanie obszarw firmy, ktre powinny zapewni zasoby do testowania. Wyznaczenie konkretnych osb mo e by odo one a do rozpoczcia planowania ktrym sprawdzenie jakoci ma by etapu, w wykonane. A.22.3. Pochodzenie / rdo Diagram Struktury Produktw; kocowi u ytkownicy produktu; istniejce systemy zapewnienia jakoci u klienta lub dostawcy. A.22.4. Kryteria ci jako Przeznaczenie / cel jest dobrze okrelone i spjne z innymi produktami; produkt jest opisany na tyle szczegowo, aby wystarczao to do zaplanowania i zarzdzania jego wytwarzaniem; skad produktu opisuje bardziej zawarto/elementy produktu ni stanowi specyfikacj wymaga; odpowiedzialno za wytworzenie produktu jest jasno okrelona; odpowiedzialno za wytworzenie produktu jest zgodna z rolami i obowizkami opisanymi w organizacji zespou zarzdzania projektem oraz w Planie Jakoci Projektu; kryteria jakoci produktu s zgodne ze standardami jakoci projektu, standardowymi listami kontrolnymi oraz Kryter iami Akceptacji; kryteria jakoci nadaj si do rozstrzygnicia, czy produkt odpowiada przeznaczeniu; wymagane metody weryfikacji jakoci umo liwiaj sprawdzenie, czy produkt spe- ustalone nia kryteria jakoci.

39 8

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.23. Diagram Nast

A.23.1.

pstwa Produktw

Product Flow Diagram

Cel / Przeznaczenie

Pokazanie wymaganej sekwencji dostarczenia produktw ujtych w planie oraz zidentyfikowanie zale noci midzy tymi produktami, z uwzgldnieniem produktw zewntrznych.

A.23.2.

Skad

Diagram pokazujcy kolejno, w jakiej dostarczane s produkty w ukadzie z gry na lub od lewej do prawej oraz powizania midzy tymi produktami. Strzaki d pokazuj zale noci midzy produktami. Produkty zewntrzne musz by wyranie odr nione od produktw wytworzonych w ramach planu. Konwencj PRINCE2 jest, e produkty pro- oznacza si umownie jako prostokty, natomiast produkty zewntrzne jako jektu elipsy. A.23.3. Pochodzenie / rdo Opisy Produktw; Diagram Struktury Produktw. A.23.4. Kryteria ci jako Produkt umieszczony na szczycie Diagramu Struktury Pr oduktw (DSP) to produkt kocowy w Diagramie Nastpstwa Produktw; zidentyfikowano wszystkie produkty zewntrzne, a powizania midzy produktami dobrze zobrazowano; wszystkie produkty z najni szego poziomu Diagramu Struktury Produktw (DSP) przeniesione do Diagramu Nastpstwa Produktw zostay (DNP); wszystkie zidentyfikowane na Diagramie Struktury Produktw (DSP) produkty inte- zostay pokazane na Diagramie Nastpstwa Pr oduktw gracji (DNP); wszystkie produkty przedstawione na DNP s zidentyfikowane jako produkty na DSP; nie wystpuj produkty, dla ktrych nie okrelono ich zwizkw z innymi; zale noci midzy produktami s zidentyfikowane na poziomie odpowiadajcym planowi, ktrego czci jest DNP; w przypadku wszystkich produktw, zale noci midzy nimi s spjne z treciami w sekcji Pochodzenie / r do (w ich Opisach zawartymi Produktw) .

399

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.24. Zestawienie Statusu Produktw

A.24.1.
Cel / Przeznaczenie

Product Status Account

Zestawienie Statusu Produktw dostarcza informacji o stanie produktw w okrelonychGranice te mog by zmienne, np. zestawienie mo e dotyczy caego granicach. projektu, pojedynczego etapu albo okrelonego obszaru projektu. Jest szczeglnie przydatne, gdy Kierownik Projektu zamierza potwierdzi numery wersji produktw. A.24.2. Skad Skad zestawienia mo e si zmienia, cho zwykle zawiera nastpujce informacje: nazwa projektu; typ produktu; identyfikator produktu; nu mer wersji. Zestawienie mo e dodatkowo dostarczy dla ka dego produktu nastpujce informacje: data uznania Opisu Produktu za obiekt odniesienia; data uznania produktu za obiekt odniesienia; lista pr oduktw powizanych; data wydania kopii produktu w celu wprowadzenia zmian; planowana data ustanowienia kolejnej wersji produktu jako obiektu odniesienia; planowana data sporzdzenia nastpnego wydania produktu (kolejnej wersji produktu); waciwe uwagi, takie jak zmiana w toku, w trakcie przegldu. A.24.3. Pochodzenie / rdo Zapisy Obiektw Konfiguracji. A.24.4. Kryteria ci jako Zestawienie obejmuje wszystkie wymagane obiekty; zestawienie jest dokadne.

40 0

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.25. Formua Realizacji Projektu

A.25.1.
Cel / Przeznaczenie

Project Approach

Zdefiniowanie rodzaju rozwizania, ktre powinno by zrealizowane przez projekt i/lub metody dostarczenia tego rozwizania. Powinno by tak e okrelone ka de rodowisko, ktrego to rozwizanie powinno by dopasowane. do wymogw

A.25.2.

Skad Mo liwe s do rozwa enia np. nastpujce propozycje: wykonanie na zamwienie; umowa z zewntrznym wykonawc; modyfikacja produktu; projektowanie pocztku; wykorzystanie firmy; wynajcie kontraktowych; zakup rozwizania; wybrana propozycja; istniejcego od personelu pracownikw gotowego

uzasadnienie wyboru/odrzucenia; np. wynika z formuy realizacji przyjtej przez program ; rodowisko operacyjne (okrelenie wszelkich obszar w, ktrych wymogi proponowane rozwizanie powinno uwzgldnia). Pochodzenie / enia rdo

A.25.3.

Zao Projektu; komitet (zesp) do spraw konstrukcji lub jego odpowiednik; rynek, czyli to, co jest dostpne. A.25.4. Kryteria ci jako Musi by zgodna ze strategi dotyczc rodowiska eksploatacji produktu; musi by mo liwa do realizacji w ramach wszystkich znanych ogranicze czasowych i kosztowych projektu; musi by mo liwa do realizacji przy zastosowaniu znanej technologii.

401

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.26. Zao enia Projektu

A.26.1.
Cel / Przeznaczenie

Project Brief

Dostarczenie penych i solidnych podstaw dla inicjowania projektu. Zawarte w Zao eniach Projektu treci s rozbudowywane i udoskonalane w Doku mencie Inicjujcym Projekt, ktry jest dokumentem roboczym, su cym do zarzdzania strategicznego i kierowania projektem. Zao enia Projektu s kluczowym dokumentem same w sobie. Stanowi podstaw do sporzdzenia Dokumentu Inicjujcego Projekt. Jakakolwiek znaczca zmiana informacji w Zao eniach Projektu musi by z tego wzgldu przekazana do decyzji zawartych zarzdu firmy lub programu. A.26.2. Skad Poni ej przedstawiono sugerowany spis zawartoci, ktry powinien by indywidualnie do wymaga i rodowiska ka dego dostosowany projektu: przyczyny powoania projektu; definicja projektu wyjaniajca, co projekt ma osign. Taka definicja powinna zawiera: cele projektu; zakres projektu i wyczenia; szkic produktw, ktre projekt ma dostarczy i/lub po danych wynikw; ograniczenia ; punkty styku (inter fejsy); zarys Uzasadnienia Biznesowego: opis, w jaki sposb projekt wspomaga strategi biznesow, plany lub programy; powody, dla ktrych projekt jest potrzebny; tolerancje projektu; Oczekiwania jakociowe klienta (patrz Dodatek A.7, w ktrym przedstawiono szczegy);

Kryteria Akceptacji (patrz Dodatek A.1, w ktrym przedstawiono szczegy); wszelkie znane zagro enia - znane ryzyko. Jeli wczeniej wykonano pewne prace, Zao enia Projektu powinny raczej odnosi si dokumentw zawierajcych u yteczne informacje, takich jak zarys Planu Projektu, do ni zawiera ich kopie.

A.26.3.

Pochodzenie /

rdo Zao e

Zao enia Projektu wywodz si z rozwinicia Zlecenia Przygotowania Projektu, dostarczonego na pocztku projektu, powstaj w ramach Przygotowani podprocesu e

40 2

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE Projekt (PP4), a s zatwierdzane w ramach Zezwolenie u Zainicjowanie Projekt podprocesu (ZS1). u Jeli projekt jest czci progr amu, program powinien dostarczy dokument Zao enia Projektu. W takich okolicznociach zao enia nie bd musiay wywodzi si ze Zlecenia Przygotowania Projektu. Jeli nie dostarczono adnego Zlecenia Przygotowania Projektu, Kierownik Projektu mu-wytworzy Zao enia Projektu od zera w trakcie dyskusji z klientami i u si ytkownikami. na

A.26.4.

Kryteria ci jako Zao enia Projektu dokadnie odzwierciedlaj Zlecenie Przygotowania Projektu; stanowi solidn podstaw, na ktrej mo na zainicjowa projekt Inicjowanie ( Projekt (IP)) u ; wskazuj, w jaki sposb klient bdzie ocenia akceptowalno ukoczonego(ych) produktu(-w).

403

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.27. Dokument Inicjuj

A.27.1.

cy Projekt (DIP)

Project (PID)

Initiation

Document

Cel / Przeznaczenie

Zdefiniowanie projektu w celu stworzenia podstawy do zarzdzania nim oraz oceny kocowego powodzenia. Dokument Inicjujcy Projekt wyznacza kierunek i zakres projektu i stanowi swoisty kontrakt zawarty midzy zespoem zarzdzania projektem a kierownictwem firmy lub programu. Istniej dwa podstawowe zastosowania tego dokumentu: zagwarantowanie, e projekt posiada solidn podstaw, przed zwrceniem si do Komitetu Sterujcego, aby poczyni jakiekolwiek wiksze zobowizania wobec projektu; penienie roli bazowego dokumentu, w odniesieniu do ktrego Komitet Sterujcy i Kierownik Projektu mog ocenia postpy, Zagadnienia Projektowe i bie ce kwestie, dotyczce zasadnoci kontynuowania projektu. A.27.2. Skad

Podstawowe informacje potrzebne do zarzdzania strategicznego i kierowania projektem, ktrych zakres wyznaczaj nastpujce fundamentalne pytania: Co projekt zamierza osign? Dlaczego osignicie tego jest wa ne? Gdzie wytwarzany bdzie produkt w przypadku produktu, ktrego wytwarzanie bdzie odbywa si w rozproszeniu geograficznym? Kto bdzie zaanga owany w zarzdzanie projektem i jakie bd obowizki zaangaowanych? Jak i kiedy to wszystko ma si wydar zy? Te informacje bd przechowywane w r ny sposb, i zaproponowana ni ej zawarto powinna by odczytywana nie jako spis treci jakiego dokumentu, lecz raczej jako zestawienie informacji potrzebnych do podjcia pocztkowych decyzji. W DIP wyr nio-sekcje stabilne i zmienne, po to aby wskaza te, ktre bd wymagay no tworzenia wersji w miar postpw w realizacji nowych projektu. Sekcje stabilne To wyjaniajce kontekst projektu oraz okolicznoci, w wyniku ktrych projekt znajduje si w obecnym punkcie; definicja projektu wyjaniajca, co projekt musi osign. W czci o takim nagwku bd przedstawione: cele projektu; zakres projektu;

40 4

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE produkty, ktre projekt ma dostarczy i/lub po dane wyniki; wyczenia; ograniczenia ; punkty (interfejsy); zao enia; styku

Formua Realizacji Projektu; tolerancje projektu; Elementy sterowania projektem opis sposobu sterowania, ktry zostanie zastoso- w projekcie, oraz wspierajcych wany mechanizmw raportowania i kontrolowania. Przedstawia si tu tak e proces postpowania z istotnymi odchyleniami.

Sekcje zmienne pocztkowe Uzasadnienie Biznesowe, wyjaniajce, dlaczego podjto realizacj projektu. pocztkowy Plan Projektu, wyjaniajcy, w jaki sposb i kiedy dziaania projektowe bd zachodziy (szczegy dotyczce zawartoci Planu Projektu, przedstawiono w oddzielnym zarysie Opisu Produktu). pocztkowy Rejestr Ryzyka, dokumentujcy rezultaty analizy zagro e, oraz dziaa- dotyczce nia zarzdzania ryzykiem; struktura organizacyjna projektu przedstawiajca, kto nale e bdzie do zespou zarzdzania projektem: struktura zespou zarzdzania projektem, opisy zakresw obowizkw; Plan Komunikacji (patrz odrbny zarys Opisu Produktu dla Planu Komunikacji); Plan Jakoci Projektu (patrz odrbny zarys Opisu Produktu dla Planu Jakoci Projektu).

Pochodzenie / rdo Standardy dostawcy dotyczce zarzdzania projektami (jeli s znane). wyspecyfikowane wymagania klienta dotyczce kontroli; wikszo informacji powinna pochodzi ze Zlecenia Przygotowania Projektu, rozszerzonego w Zao eniach Projektu. Dokument I nicjujcy Projekt bdzie skompletowany podczas Inicjowanie procesu Jego czci, takie jak Rejestr Ryzyka, Plan Projektu oraz Uzasadnienie Projekt (IP). u Bizne-by uaktualniane i doprecyzowywane za ka dym razem, gdy realizowany sowe mog b- proces Zar dzanie dzie Zakresem (ZE), a na zakoczenie zarchiwizowane w Etapu mach procesu z Zamykanie (ZP) . raProjektu A.27.4. Kryteria ci jako Dokument waciwie przedstawia projekt; ukazuje sensowny, mo liwy do zrealizowania projekt, ktry pozostaje w zgodzie ze strategi firmy lub oglnymi potrzebami pr ogramu; 405

A.27.3.

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2 str uktura organizacyjna projektu jest kompletna wraz z nazwiskami i tytuami; wzito pod uwag wszystkie role; wyranie ukazuje system sterowania, raportowania i zarzdzania strategicznego, kt-jest mo liwy do wprowadzenia, odpowiedni do skali, ryzyka biznesowego ry oraz znaczenia biznesowego projektu; str ukturze organizacyjnej projektu towarzysz uzgodnione i podpisane opisy zakresw obowizkw; relacje i linie podziau wadzy w projekcie s jasne; jeli to konieczne, struktura organizacyjna projektu wskazuje, komu podlega Komitet Sterujcy; elementy sterowania speniaj potrzeby Komitetu Sterujcego, Kierownika Projektu i Kierownikw Zespow; elementy sterowania speniaj wymagania delegowanego nadzoru; jest jasne, kto administruje ka dym z elementw sterowania.

40 6

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.28. Zagadnienie Projektowe

A.28.1.
Cel / Przeznaczenie

Project Issue

Zagadnienie Projektowe to oglne okrelenie dla jakiejkolwiek sprawy, ktra musi by poddana uwadze zespou projektowego i wymaga rozwizania. Po otrzymaniu niepowtarzalnego numeru referencyjnego Zagadnienia Projektowe s oceniane w kategoriach oddziaywania na produkt, pracochonno, koszty, ryzyko, Plan Projektu oraz na Uzasadnienie Biznesowe. Kierownik Projektu mo e zdecydowa, jakie dziaanie korygujce na- podj, lub mo e przekaza Zagadnienie Projektowe Komitetowi Sterujcemu. le y Zagadnienie Projektowe mo e mie negatywne lub pozytywne oddziaywanie na projekt. Zagadnienia Projektowe obejmuj: Wnioski o Wprowadzenie Zmian; Odstpstwa; pytania ; wyrazy zaniepokojenia. A.28.2. Skad Autor zgoszenia; data zgoszenia; numer Zagadnienia Projektowego; opis Zagadnienia Projektowego; priorytet ; analiza oddziaywania; decyzja; podpis(-y) decyzj; data decyzji. podejmujcych wydania Pochodzenie / rdo

A.28.3.

Zgosi Zagadnienie Projektowe mo e ka dy. Typowym rdem s u ytkownicy oraz specjalici pracujcy nad projektem. Rejestrowanie Projektowyc Podproces y gromadzeniu Zagadnie Projektowych. Nastpnie s one badane Zagadnie h (SE3) su podczas podprocesu Analizowanie Projektowyc (SE4). Zagadnie h A.28.4. Kryteria ci jako Problem/wymaganie/okazja przedstawiono w sposb zrozumiay; wszystkie konsekwencje zostay dogbnie przemylane; Zagadnienie Projektowe zostao prawidowo zarejestrowane.

407

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.29. Zlecenie Przygotowania Projektu

A.29.1.
Cel / Przeznaczenie

Project Mandate

Informacje w Zleceniu s wykorzystywane do rozpoczcia Przygotowanie procesu Projekt (PP). Powinno ono zawiera informacje wystarczajce do zidentyfikowania u przy- przyszego Przewodniczcego Komitetu Sterujcego oraz wskazywa najmniej gwny przedmiot projektu. Bdzie ono wykorzystane do opracowania Zao e . Projektu A.29.2. Skad Faktyczna zawarto Zlecenia Przygotowania Projektu bdzie si r nia w zale noci od i rozmiarw projektu, a tak e rodowiska, w ktrym Zlecenie powstao. Projekt typu mo- by cakowicie nowym fragmentem prac, ktry wanie si pojawi, mo e by e wynikiem wczeniejszych bada lub czci wikszego programu. Poni sza lista wymienia sugerowan zawarto Zlecenia Przygotowania Projektu, ktr y dostosowa, by pasowaa do konkretnego nale projektu: wadza odpowiedzialna; przyczyny projektu; cele projektu; zakres; powoania

ograniczenia ; punkty styku (interfejsy); Oczekiwania jakociowe klienta; zarys Uzasadnienia Biznesowego (przyczyny uruchomienia Zlecenia); tolerancje projektu; odniesienia do wszelkich powizanych dokumentw lub produktw; wskazanie, kto ma by Przewodniczcym oraz Kierownikiem Projektu; klient(-ci) , u ytkownik(-cy) i wszystkie inne znane zainteresowane strony. Jeli Zlecenie Przygotowania Projektu jest oparte na wczeniejszych pracach, mog ist- jeszcze inne u yteczne informacje, jak oszacowania rozmiaru projektu i czasu nie jego trwania oraz przegld zagro e, na ktre nara ony jest projekt. A.29.3. Pochodzenie / rdo Zlecenie Przygotowania Projektu mo e pochodzi zewszd, cho powinno pochodzi tego poziomu zarzdzania, ktry ma uprawnienia do zezwalania na zawsze z poniesienieoraz wykorzystanie zasobw. Stanowi wejcie do kosztw Przygotowanie procesu Projekt (PP). u

40 8

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.29.4.

Kryteria ci jako Poziom uprawnie jest wspmierny z prognozowanym zakresem, ryzykiem i kosztami projektu; istniej wystarczajce dane, pozwalajce mianowa odpowiednie osoby do roli Przewodniczcego oraz Kierownika Projektu; okrelono wszystkie znane strony zainteresowane projektem; Zlecenia Przygotowania Projektu dostarcza opisu tego, czego si od projektu wymaga.

409

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.30. Plan Projektu

A.30.1.
Cel / Przeznaczenie

Project Plan

Plan Projektu jest planem obowizkowym, ktry dostarcza zestawienia tego, w jaki spo- i kiedy cele projektu maj by osignite, poprzez pokazanie gwnych sb produktw, zasobw potrzebnych do dziaa i projektu. Dostarcza planowane koszty na potrzeby Uzasadnienia Biznesowego, ustala etapy zarzdcze oraz inne gwne punkty kontrolne. Jest wykorzystywany przez Komitet Sterujcy jako plan bazowy do monitorowania wzgldem niego postpw projektu oraz kosztw, etap po etapie. A.30.2. Skad Ten produkt stanowi cz Dokumentu Inicjujcego Projekt i powinien zawiera: opis planu, dajcy krtki zarys tego, co plan zawiera; wstpne uwarunkowania projektu, zawierajce wykaz podstawowych spraw, ktre by zaatwione na starcie projektu i musz pozostawa we waciwym musz porzdku, aby projekt zakoczy si sukcesem; zale noci zewntrzne; zao enia planistyczne; Plan Projektu, zawierajcy: wykres Gantta lub wykres paskowy na poziomie projektu z okrelonymi etapami zar zdczymi; Diagram Struktury Produktw na poziomie projektu; Diagram Nastpstwa Produktw na poziomie projektu; Opisy Produktw na poziomie projektu; sie dziaa na poziomie projektu; finansowy bud et projektu; bud et zmian projektu; tabel wymaganych zasobw na poziomie projektu; wnioskowane/pr zydzielone konkretne zasoby; tolerancje na poziomie projektu (np. dla czasu i bud etu); Plany rezerwowe, pokazujce, w jaki sposb zamierza si postpowa z konsekwencjami wszelkich zagro e, ktre si zmaterializuj. A.30.3. Pochodzenie / rdo Zao enia Projektu.

41 0

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE Plan Projektu jest tworzony poprzez udoskonalenie zarysu Planu Projektu z Zao e Projektu w pr Planowanie (IP2). Jest uaktualniany podczas Uaktual ocesie Planu Projektu procesu niani (ZE2). e Projektu A.30.4. Kryteria ci jako Plan jest mo liwy do wykonania; wspiera pozosta cz Dokumentu Inicjujcego Projekt.

411

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.31. Plan Jako ci Projektu

A.31.1.
Cel / Przeznaczenie

Project Plan

Quality

Plan Jakoci Projektu jest czci Dokumentu Inicjujcego Projekt. Ma na celu okrelenie technik oraz standardw jakoci, ktre bd zastosowane, oraz r - ych obowizkw zwizanych z osigniciem wymaganych poziomw jakoci n podczas realizacji projektu. A.31.2. Skad Oczekiwania jakociowe klienta (z Zao e Projektu); tolerancje jakoci; Kryteria Akceptacji; obowizki dotyczce jakoci; odniesienie do wszelkich standardw, ktrych nale y przestrzega; procesy kontroli jakoci i procesy audytu, zastosowane w zarzdzaniu projektem; wymagania dotyczce kontroli jakoci i procesu audytu dla prac specjalistycznych; procedury zarzdzania zmianami; Plan Zarzdzania Konfiguracj; wykaz wszelkich narzdzi wykorzystywanych dla zapewnienia jakoci. A.31.3. Pochodzenie / rdo Plan Jakoci Projektu wywodzi si z: Oczekiwa jakociowych klienta; Kryteriw Akceptacji; standardw organizacyjnych; Formuy Realizacji Projektu; Zao e Projektu; systemw zarzdzania jakoci (SZJ) dostawcy i klienta; wymaga zarzdzania konfiguracj; wymaga sterowania zmianami. Plan Jakoci Projektu jest wynikiem Planowanie (IP1). c podprocesu Jako i A.31.4. Kryteria ci Plan jasno jako okrela sposoby, ktrymi speni si jakociowe oczekiwania klienta; przyjte sposoby wystarczaj, by osign wymagan jako; okrelono obowizki zwizane z zapewnieniem jakoci a do poziomu zarzdczego,niezale ny od projektu i Kierownika ktry jest Projektu; plan jest zgodny z polityk jakoci firmy.

41 2

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.32. Rejestr Jako

A.32.1.

ci

Quality Log

Cel / Przeznaczenie

Celem jest: Nadanie niepowtarzalnego numeru referencyjnego ka dej kontroli jakoci. Penienie roli odsyacza do dokumentacji kontroli jakoci dla produktu. Penienie roli zestawienia liczby i rodzajw przeprowadzonych kontroli jakoci. Rejestr zestawia wszystkie kontrole jakoci, ktre s planowane lub zostay przeprowadzone oraz dostarcza infor macji do Raportu Kocowego Etapu i Raportu Kocowego jak Projektu, rwnie do Raportu o Dowiadczeniach. A.32.2. Skad Ka dy wpis do zawiera: numer referencyjny; produkt 43 ; rejestru powinien

metod kontroli jakoci; personel odpowiedzialny, role; planowana data przegldu; faktyczna data przegldu; wynik przegldu;

nazwiska,

liczba dziaa; planowana data zatwierdzenia; faktyczna data zatwierdzenia. A.32.3. Pochodzenie / rdo Pierwsze wpisy do rejestru s dokonywane wtedy, gdy kontrola jakoci lub test jest wpr owadzany do Planu Etapu .Pozostae informacje pochodz z faktycznego wykonania troli. Data zatwierdzenia konoznacza dzie, w ktrym wszystkie dziaania naprawcze zostay zatwierdzone podpisem. Pocztkowy, czysty Rejestr Jakoci jest tworzony podczas podpr Planowanie ocesu Jako (IP1). c i A.32.4. Kryteria ci jako Istnieje procedura gwarantujca wpisanie ka dej kontr oli jakoci do rejestru; przypisano odpowiedzialno za rejestr.

43

Identyfikator i nazwa produktu przypis tumacza.

413

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.33. Wniosek o Wprowadzenie Zmiany

A.33.1.
Cel / Przeznaczenie

Request for Change

Wnioskowanie o modyfikacj produktu lub kryterium akceptacji, w stosunku do obecnie obowizujcych.

A.33.2.

Skad Data zgoszenia; nu mer w Rejestrze Zagadnie; status zagadnienia; opis pr oponowanej zmiany; oddziaywanie zmiany; ocena priorytetu; decyzja;

szczegy dotyczce przydzielenia; data przydzielenia; data zaatwienia. A.33.3. Pochodzenie / rdo Wniosek o Wprowadzenie Zmiany mo e by zo ony przez ka d osob, ktra ma zwi- z projektem. Wniosek o Wprowadzenie Zmiany mo e by zo ony i zek zarejestrowany w ramach podprocesu Rejestrowanie Projektowyc (SE3); alternatywnie Zagadnie h szone Zagadnienie Projektowe mo e zosta zaklasyfikowane zgo- Wniosek o jako Wprowa-Zmiany przez Kierownika Projektu w trakcie dzenie Analizowanie podprocesu Zagadnie Projektowyc (SE4). h A.33.4. Kryteria ci rdo jako zgoszenia jest jasno okrelone; zarejestrowano w Rejestrze Zagadnie; dokadny opis wnioskowanej zmiany; korzyci z dokonania zmiany s jasno wyra one oraz, jeli to mo liwe, podane w mierzalnych kategoriach.

41 4

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.34. Rejestr Ryzyka

A.34.1.
Cel / Przeznaczenie

Risk Log

Celem Rejestru Ryzyka jest przechowanie wszystkich informacji o zagro eniach, ich ana- rodkach przeciwdziaania or az lizie, statusie. A.34.2. Skad Identyfikator : niepowtarzalny kod pozwalajcy na grupowanie ryzyka informacji na temat wszystkich danego zagro enia; auto : ten, kto zgosi zagro r enie; data : data zgoszenia zagro zgoszenia enia; opi : opis zagro s enia; kategoria ryzyka np. handlowe, prawne, techniczne; oddziaywanie / : skutek dla projektu/programu/organizacji, jeli zagro wpyw enie zmaterializuje si; prawdopodobi stw : oszacowane prawdopodobiestwo zmaterializowania si e enia; o zagro blisk : oszacowany dystans czasowy, ktry dzieli projekt od wystpienia zagro o nia; eprzeciwdziaani a enia; gro : dziaania, ktre zostay lub bd podjte, w celu zmniejszenia za-

wa ciciel zagro : osoba wyznaczona do obserwacji konkretnego zagro enia enia; data ostatniej : data ostatniego badania statusu zagr o aktualizacji enia; aktualny : np. zamknite, zmniejszajce si, wzrastajce, bez status zmian. A.34.3. Pochodzenie / rdo Niektre zagro enia i zwizane z nimi ryzyko mog by zidentyfikowane w trakcie prac prowadzcych do opracowania Zlecenia Przygotowania Projektu. Zagro enia (ryzyko) mog by zidentyfikowane tak e w Zao eniach Projektu oraz powinny by wzite pod uwag w trakcie inicjowania projektu, kiedy powstaje Plan Projektu. Nale y poszukiwanowych zagro e (ryzyka) za ka dym razem, gdy dokonywany jest wszelkich przegld Ryzyka, co najmniej podczas ka dej oceny kocowej etapu. Komitet Rejestru Sterujcyodpowiedzialno za sta obserwacj wydarze zewntrznych pod ktem ponosi zagroe zewntrznych. Zagro enia dla Planu Etapu powinny by badane jako element tworzenia tego planu. Przegldu zagro e nale y dokonywa za ka dym razem, gdy Plan Etapu jest uaktualniany. Rejestr Ryzyka podprocesu (PP4). jest zakadany podczas Przygotowanie e Zao Projekt u

415

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

A.34.4.

Kryteria ci jako czy dziaanie zostao podjte, czy jest ono wczone do planu Status wskazuje, rezerwowego; zagro enia s jednoznacznie zidentyfikowane (wraz z tym, ktrego projektu one dotycz, jeli pochodz one z programu); zagro enie zostao przydzielone wacicielowi; dostp do Rejestru Ryzyka jest kontrolowany; Rejestr Ryzyka jest przechowywany w bezpiecznym miejscu; w Planach Etapw uwzgldnione zostay dziaania dotyczce przegldu Rejestru Ryzyka.

41 6

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.35. Plan Etapu

A.35.1.

Stage Plan

Cel / Przeznaczenie Jest wykorzystywany jako podstawa do sterowania zarzdzaniem projektu w trakcie etapu; caego

okrela wszystkie produkty, ktre musz by wytworzone w ramach etapu; stanowi deklaracj, w jaki sposb oraz kiedy cele etapu maj by osignite, pokazujc produkty, dziaania i potrzebne zasoby; okrela sterowanie etapem oraz punkty kontrolne i czstotliwo raportowania; stanowi odniesienie, wzgldem ktrego mierzone bd postpy prac etapu; zawiera zapis tolerancji etapu; wyszczeglnia kontrole jakoci dla etapu oraz okrela zasoby do tego potrzebne. A.35.2. Skad Produkt ten zawiera nastpujce elementy: Opis planu obejmujcy: krtki opis tego, co zawiera plan; krtki opis planowanej formuy realizacji; plan jakoci (nie jako oddzielny dokument, ale fragment Planu Etapu), obejmujcy: metody kontroli jakoci, ktre bd u yte dla ka dego z gwnych produktw; terminy i zasoby, ktre nale y przewidzie dla ka dego testu lub sprawdzenia jakoci; wstpne warunki planu: obejmujce wszelkie podstawowe sprawy, ktre musz by zaatwione w momencie rozpoczynania etapu oraz musz pozostawa we waciwym porzdku,plan jeli ma si zakoczy powodzeniem; zale noci zewntrzne; tolerancje ; sposb kontrolowania i nadzorowania realizacji planu; raportowanie ; zao enia planistyczne; plan w formie graficznej, zawierajcy: diagram pokazujcy wyznaczone zasoby, dziaania, daty rozpoczcia i zako- (zazwyczaj wykres Gantta lub wykres czenia paskowy); Diagram Struktury Produktw; Diagram Nastpstwa Produktw; sie dziaa;

417

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2 bud et finansowy; zestawienie zapotrzebowania zasoby; ocen ryzyka.

na

Opisy Produktw dla gwnych produktw.

Plan Nadzwyczajny lub ka dy inny plan szczegowy powinien mie tak sam form Etapu. jak Plan

A.35.3.

Pochodzenie / rdo Rozwinity na podstawie Planu podprocesu (ZE1);

Projektu

podczas

Planowanie Etapu

oparty na dostpnoci zasobw. Plan Etapu jest aktualizowany podczas Ocena pw (SE2) oraz mo e podprocesu by modyfikowany podczas podprocesw Przeg d Post Stanu (SE5) oraz Podejmowal Etapu nie Korygu cyc (SE7). Dziaa j h A.35.4. Kryteria ci jako jest Plan wykonalny; wszyscy Kierownicy Zespow wczeni w realizacj planu s przekonani, e ich cz jest wykonalna; Plan Etapu pomaga w realizacji Planu Projektu; wzito pod uwag wszelkie ograniczenia czasu, zasobw i bud etu; plan doprowadzono do poziomu szczegowoci niezbdnego do zapewnienia, e a de odchylenie bdzie zauwa one na tyle szybko, by mc waciwie zareagowa k p. w ramach tolerancji etapu oraz w ramach przewidzianych zapasw czasu n dla dziaa; Plan Etapu zosta opracowany zgodnie ze standardami planistycznymi; Plan Etapu uwzgldnia dziaania i pracochonno zwizane Rejestru Zagadnie.

przegldami

41 8

PRINCE2 DODATEK A: OPISY PRODUKTW W ZARYSIE

A.36. Grupa Zada

A.36.1.
Cel / Przeznaczenie

Work Package

Grupa Zada jest zestawem informacji o jednym produkcie lub wikszej liczbie wyma- produktw, zebranych przez Kierownika Projektu, aby odpowiedzialno za ganych wytworzenie lub dostaw formalnie przenie na Kierownika Zespou lub czonka zespou. A.36.2. Skad Ten produkt mo e mie zr nicowan tre i stopie sformalizowania zale nie od okolicznoci. Tam, gdzie prace zwizane z wytworzeniem produktw s prowadzone przez zesp bezporednio kierowany przez Kierownika Projektu, Grupa Zada mo e by ustn instrukcj. Istniej mimo to wa ne powody, by instrukcje te przekaza pisemnie, chocia by dla uniknicia nieporozumie oraz umo liwienia dokonania oceny poziomu wykonania. W przypadku, gdy prace s prowadzone przez dostawc na podstawie kontraktu, a Kierownik Projektu nale y do organizacji klienta, istnieje potrzeba formalnie zapisanej instrukcji, zgodnie ze standardami okrelonymi w kontrakcie. Chocia zawarto dokumentw mo e si bardzo r ni, w zale noci od relacji midzy Kierownikiem Projektu a odbiorc Grupy Zada, to powinna ona obejmowa: dat dat uzgodnie pomidzy Kierownikiem Projektu a Kierownikiem Zespou/osob
wyznaczon; zesp lub osob wyznaczon z ktr dokonano uzgodnie; do wykonania

nazwisko Kierownika Zespou lub osoby,

opis Grupy Zada opis prac do wykonania; Opis(-y) Produktu(-w) zwykle s to zaczniki do Grupy Zada, ktrymi s Opisy Produktw dla produktw, ktre maj by wytworzone w ramach Grupy Zada; techniki/procesy/procedury, ktre nale y zastosowa wszelkie techniki, narzdzia, standardy, procesy i procedury, ktre powinny by zastosowane przy wytwarzaniu produktw specjalistycznych (z pominiciem procesw PRINCE2); punkty styku (interfejsy) ktrych wymagania musz by spenione przez wytworzone produkty identyfikacja wszelkich produktw specjalistycznych, z ktrymi produkt(-y) z Grupy Zada bd wsppracowa w czasie swej eksploatacji. Mog to by inne produkty, ktre bd wytworzone w tym samym projekcie, produkty ju istniejce czy te produkty, ktre wytworzone bd w innych projektach (np. gdy projekt jest czci programu); kontakty (interfejsy), ktre musz by utrzymywane w trakcie realizacji prac mog to by osoby, ktre dostarczaj informacji, albo osoby, ktrym nale y przekazywa informacje; wymagania dotycz ce zarz dzania konfiguracj okrelaj one wszelkie rozwizania, ktre musi wprowadzi wytwrca do kontroli wersji produktw Grupy Zada, uzyskiwania kopii innych produktw lub ich Opisw Produktw, poddawania produktw zarzdzaniu konfiguracj oraz wszelkie wymagania zwizane z informowaniem Bibliotekarza Konfiguracji o zmianach statusu produktw Grupy Zada; wyci g z Planu Etapu bdzie to odpowiedni fragment Planu Etapu lub Listy Kontrolnej Produktw albo odniesienie do nich;

419

APPENDIX A: PRODUCT DESCRIPTION OUTLINES PRINCE2

wsplne uzgodnienie nakadw, kosztw, dat pocz tku i ko ca oraz tolerancji uzgodnionych kwot i terminw, cznie z tolerancjami dla Grupy Zada; szczegy

wszelkie ograniczenia, z ktrymi nale y si liczy wszelkie ograniczenia (oprcz tolerancji) dotyczce pracy, zaanga owanych osb, terminw, obowizkw, stosowanych zasad (np. bezpieczestwa i higieny) itd.; organizacj raportowania Kontrolnych;

spodziewan czstotliwo i zawarto Raportw z Punktw

zwykle

sposb post powania z problemami oraz przekazywania ich na wy szy szczebel dotyczy to procedury zgaszania Zagadnie Projektowych i zagro e;

wymagania dotycz ce odbioru prac (zatwierdzania) osoba, rola lub grupa osb, ktra bdzie zatwierdza (odbiera) produkty ukoczonej Grupy Zada;

okrela si tutaj, w jaki sposb Kierownik Projektu sposb powiadomienia o wykonaniu ma by zawiadomiony o wykonaniu Grupy Zada.

W Grupie Zada powinno si znale miejsce do zarejestrowania wydania zgody na jej uruchomienie oraz akceptacji odbioru produktw wykonanej Grupy Zada. Dodatkowo mo na wczy ocen realizacji pracy, zmierzajc w kierunku oceny wynikw i zaanga owania pracownikw.

A.36.3.

Pochodzenie /

rdo

Opis(-y) Produktu(-w); Plany Etapw.

A.36.4.

Kryteria

ci

jako Wymagana Grupa Zada jest jasno zdefiniowana i zrozumiaa dla zasobw przydzielonych do jej wykonania;
istnieje(-) Opis(-y) Produktu(-w) dla wymaganego produktu lub produktw wraz z jasno okrelonymi i akceptowalnymi kryteriami jakoci; Opis Produktu jest zgodny z pozosta dokumentacj Grupy Zada; standardy obowizujce dla realizacji prac s uzgodnione; zdefiniowane standardy s zgodne z tymi, ktre stosuje si dla podobnych produktw; wszystkie konieczne punkty styku (interfejsy) zostay okrelone; organizacja raportowania zawiera postanowienia dotyczce raportowania istotnych odchyle; Kierownik Projektu i odbiorca Grupy Zada ustalili precyzyjnie, co ma by wytworzone; uzgodniono ograniczenia dotyczce pracochonnoci, kosztw i docelowych terminw; terminy i pracochonno s zgodne z tymi, ktre zawarto w Planie Etapu; ustalono organizacj raportowania; okrelono wymagania dotyczce obecnoci oraz udziau osb niezale nych w kontroli jakoci.

42 0

DODATEK B

ROLE W ZESPOLE ZARZ DZANIA PROJEKTEM

APP EN DIX B:PRO JE CT MANAG E MENT TE AM RO LES

Poni sze opisy rl dotycz normalnych zakresw obowizkw i zada ka dego z czon- zespou zarzdzania projektem. Dla konkretnego projektu mog by one kw dostoso- do aktualnych potrzeb. Dostosowanie mo e obejmowa czenie rl lub wywane podzia roli midzy dwie lub wicej osb. Wa ne jest, by pamita, e wszystkie jednej przedstawione w tym rozdziale obowizki musz by przez kogo speniane bez wzgldu na rozmiar projektu. Obowizki mog by przesunite z jednej roli do drugiej, lecz nigdy nie powinny by pominite. Rozdzia Organizacj daje jasne wskazwki, do jakich 14 a mog lub nie mog by przypisane pewne obowizki; rl Kierownik Projektu nie mo np. e eni obowizkw Nadzoru Projektu. p

B.1.

Komitet Steruj

cy

Project Board

Komitet Sterujcy odpowiada przed kierownictwem firmy lub programu za oglne ukierunkowanie i zarzdzanie strategiczne projektem, a tak e posiada w projekcie uprawnienia decyzyjne i ponosi odpowiedzialno za projekt w granicach delegowania ich (Zlecenie Przygotowania Projektu) przez zarzd firmy lub programu. Komitet Sterujcy kontaktuje si w imieniu projektu z otoczeniem zewntrznym i jest odpowiedzialny za promocj projektu lub innego rodzaju rozpowszechnianie informacji o nim. zkw Komitetu cego Steruj Komitet Sterujcy zatwierdza wszystkie gwne plany oraz zezwala na wszelkie znaczne odchylenia od zatwierdzonych Planw Etapw. Jest to organ, ktry ostatecznie zatwierdza zakoczenie ka dego etapu i zezwala na rozpoczcie etapu nastpnego. Zapewnia, aby zostay przydzielone niezbdne zasoby, oraz jest arbitrem we wszelkich konfliktach i negocjuje rozwizania wszelkich problemw, dotyczcych projektu i w projekcie podmiotw zewntrznych. Dodatkowo zatwierdza nominacj i obowizki Kierownika Pro- oraz delegowanie swoich obowizkw zwizanych z Nadzorem jektu Projektu. Komitet Sterujcy ma rozliczne obowizki. Poni sza lista ma charakter oglny i wymaga adaptacji dla konkretnego projektu. Komitet Sterujcy na pocztku pr ojektu: zezwala na rozpoczcie projektu poprzez akceptacj Zao e Projektu; ustala z Kierownikiem Projektu zakres jego obowizkw i stawiane przed nim cele; potwierdza z kierownictwem fir my lub programu tolerancje dla projektu; okrela zewntrzne ograniczenia projektu, takie jak np. nadzr jakoci; zatwierdza kompletny i satysfakcjonujcy Dokument Inicjujcy Projekt, zapewniajc jego zgodno z odpowiednimi standardami i polityk klienta, a tak e z wszelkimi umowami zawartymi z dostawc; 421

B.1.1.

Szczegowy zakres obowi

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2 deleguje role Nadzoru Projektu; przydziela dla projektu zasoby wymagane przez Plan Etapu . (nastpnego) W trakcie realizacji projektu: zapewnia oglne wytyczne i strategiczne zarzdzanie projektem, zapewniajc, aby przebiega on w okrelonych ramach, wynikajcych ze zdefiniowanych ogranicze; dokonuje przegldu ka dego zakoczonego etapu oraz zezwala na przejcie do nastpnego etapu; dokonuje przegldu i zatwierdzenia Planw Etapw oraz Planw Nadzwyczajnych; peni rol waciciela jednego lub wielu zidentyfikowanych zagro e (ryzyka),z przydziaem d okonanym podczas zatwierdzania planu oznacza to zgodnie odpowiedzialno za monitorowanie zagro enia oraz doradzanie Kierownikowi Projektu w przypadku zmian jego statusu, a tak e podejmowanie w razie potrzeby dziaa majcych na celu agodzenie zagro enia; zezwala na wprowadzenie zmian; zapewnia zgodno projektu z dyrektywami zarzdu firmy lub programu. Na kocu projektu: nadzoruje prawidowo dostarczenia wszystkich produktw projektu; nadzoruje spenienie wszystkich Kryteriw Akceptacji; zatwierdza Raport Kocowy Projektu; zatwierdza Raport o Dowiadczeniach oraz przekazuje go waciwej jednostce organizacyjnej, odpowiadajcej za standardy, w celu podjcia waciwych dziaa; podejmuje decyzje dotyczce Zalece Dziaa Nastpczych oraz przekazuje je waciwemu kierownictwu;

zatwierdza Plan Przegldu Poprojektowego - jeli jest to waciwe; przekazuje powiadomienie o zamykaniu projektu kierownictwu firmy lub programu. Komitet Sterujcy jest wacicielem Zar dzanie Strategiczne (ZS). procesu z Projektem Komitet Sterujcy ponosi ostateczn odpowiedzialno za zagwarantowanie, e projekt prowadzony jest w sposb waciwy, zapewniajcy dostarczenie po danego rezultatu o wymaganej jakoci, w celu zrealizowania Uzasadnienia Biznesowego przedstawionegoInicjujcym Projekt. W zale noci od rozmiaru, zo onoci oraz r w Dokumencie yzyka projektu Komitet Sterujcy mo e podj decyzj o delegowaniu niektrych obowizkw z Nadzor em Projektu. Wicej szczegw znajduje si w zwizanych podrozdziaach 14.2.4 i B.7 . Jednym z obowizkw Komitetu Sterujcego, ktry wymaga jest zatwierdzanie oraz finansowanie zmian. Patrz: Rozdzia 20 Obowizki poszczeglnych czonkw Komitetu Sterujcego odpowiednich sekcjach. uwa nego rozwa enia, Sterowanie . zmianami s opisane dalej w

42 2

PRINCE2 DODATEK B: ROLE W ZESPOLE ZARZDZAJCYM PROJEKTEM

B.2.

Przewodnicz

cy

Executive

Przewodniczcy jest ostatecznie odpowiedzialny za projekt, przy wsparciu ze strony Gwnego U ytkownika oraz Gwnego Dostawcy. Do roli Przewodniczcego nale y zagwarantowanie, by projekt w caym cyklu swego ycia ukierunkowany by na osiganie zamierzonych celw i na dostarczenie produktu, ktry przyniesie przewidywane korzyci. Przewodniczcy musi zagwarantowa, e projekt wytworzy warto odpowiedni do poniesionych nakadw, zapewniajc w trakcie projektu podejcie oparte na wiado-ponoszonych kosztw przy jednoczesnym rwnowa eniu wymaga biznesu, u moci ytkownika i dostawcy. W czasie trwania projektu Przewodniczcy jest wacicielem Uzasadnienia Biznesowego. B.2.1. Szczegowy zakres obowi zkw Przewodnicz cego Nadzorowanie opracowywania Zao e Projektu oraz Uzasadnienia Biznesowego; zagwarantowanie spjnej struktury organizacyjnej oraz logicznego zestawu planw; akceptowanie wydatkw ponoszonych przez klienta oraz ustalenie tolerancji dla etapw; monitorowanie i kontrola postpw projektu na poziomie strategicznym, w szczeglnoci stae dokonywanie przegldu Uzasadnienia Biznesowego (np. w ramach kocowej ka dego oceny etapu); zagwarantowanie, e wszelkie proponowane zmiany zakresu, kosztw lub terminw s sprawdzane pod ktem ich mo liwego wpywu na Uzasadnienie Biznesowe; zapewnienie, e ka de zagro enie bdzie obserwowane oraz e jego wpyw bdzie agodzony najefektywniej, jak to mo liwe; przekazywanie krtkich informacji kierownictwu firmy lub programu o postpach projektu ; organizowanie posiedze Komitetu Sterujcego i przewodniczenie im; zalecanie kierownictwu firmy lub programu przyszych dziaa zwizanych z projektem, jeli przekroczone zostan granice tolerancji projektu; zatwierdzanie Raportu Kocowego Projektu i Raportu o Dowiadczeniach oraz zapewnienie, e wszelkie niezaatwione Zagadnienia Projektowe s udokumentowane i przekazane odpowiednim instancjom; zatwierdzenie wysania do kierownictwa firmy lub programu powiadomienia o zamykaniu projektu; sprawdzenie, przez przeprowadzenie przegldu poprojektowego, e korzyci zostay osignite oraz przekazanie rezultatw tego przegldu waciwym interesariuszom. Przewodniczcy ponosi odpowiedzialno za cao nadzoru biznesowego nad projektem, to, by celem projektu pozostawao dostarczenie produktw, ktre czyli za przynios oczekiwane korzyci biznesowe, oraz za to, e projekt bdzie zakoczony w ramach uzgodnionych tolerancji, dotyczcych bud etu i harmonogramu. Nadzr biznesowy obejmuje: walidacj i monitorowanie Uzasadnienia zewntrznych wydarze oraz na tle postpw projektu; Biznesowego w kontekcie

423

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2 zapewnienie zgodnoci projektu ze strategi klienta; monitorowanie finansw projektu w imieniu klienta; monitorowanie ryzyka biznesowego; monitorowanie wszelkich patnoci dla dostawcw i wykonawcw; monitorowanie zmian w Planie Projektu w celu sprawdzenia ich ewentualnego oddziaywania na potrzeby biznesu lub na Uzasadnienie Biznesowe projektu; ocenianie oddziaywania potencjalnych zmian na Uzasadnienie Biznesowe oraz Plan Projektu ; ograniczanie nadmiernych da u ytkownika i dostawcy; informowanie zespou projektowego o wszelkich zmianach wymuszanych przez program, ktrego projekt jest czci (ten obowizek mo e by przekazany innej osobie, jeli peni ona rol przedstawiciela programu w zespole zarzdzania projektem) ; monitorowanie postpw etapu i projektu w porwnaniu z uzgodnionymi tolerancjami . Jeli charakter projektu to usprawiedliwia, Przewodniczcy mo e delegowa niektre obowizki funkcji nadzoru biznesowego. Komitet cy nie jest ciaem demokratycznym dz cym si wi kszo goci Steruj sw. Przewodnicz rz cy jest gwny m decydentem, bo to on ponosi odpoostateczn wiedzialno przed zarz dem biznesowym. Wspomagaj go Gwny U ytkownik i Gwny Dostawca.

B.3.

Gwny U ytkownik

Senior User

Gwny U ytkownik odpowiada za okrelenie potrzeb wszystkich tych, ktrzy bd wykorzystywali produkt(-y) kocowy(-e), za czno u ytkownikw z zespoem projekto- az za monitorowanie, aby rozwizanie spenio te potrzeby w ramach wym or ogranicze wynikajcych z Uzasadnienia Biznesowego w kategoriach jakoci, funkcjonalnoci or az atwoci u ytkowania. Rola reprezentuje interesy wszystkich tych, ktrzy bd wykorzystywali produkt(y) kocowy(e) projektu, tych, ktrym produkt projektu umo liwi osignicie celw, oraz ktrzy bd wykorzystywali produkt dla dostarczania korzyci biznesowych. tych, Rola Gwnego U ytkownika zapewnia zasoby u ytkownika oraz monitoruje spenianie wymaga przez produkty projektu. Rola ta mo e wymaga wicej ni jednej osoby, po to, uwzgldnia interesy wszystkich u ytkownikw. Pr zez wzgld na efektywno aby rola powinna by dzielona midzy zbyt wiele nie osb. B.3.1. Szczegowy zakres obowi zkw Gwnego U ytkownika Zapewnienie, e istnieje specyfikacja po danego wyniku projektu; upewnienie si, e postpy projektu w kier unku uzyskania rezultatu wymaganego przez u ytkownikw realizowane s logicznie z punktu widzenia u ytkownikw;

42 4

PRINCE2 DODATEK B: ROLE W ZESPOLE ZARZDZAJCYM PROJEKTEM promowanie i utrzymywanie koncentracji projektu na uzyskaniu po danego rezultatu; zagwarantowanie, e wszelkie zasoby u ytkownika niezbdne dla projektu bd udostpniane ; zatwierdzanie Opisw Produktu dla tych produktw (porednich lub kocowych), ktre s wejciowymi lub wyjciowy mi do/od dostawcy lub bd na nie wpywa bezporednio; zapewnienie, e produkty bd for malnie odebr ane po ich wytworzeniu; ustalanie priorytetw i przekazywanie opinii u ytkownika w zwizku z decyzjami Sterujcego dotyczcymi wdra ania pr oponowanych Komitetu zmian; rozwizywanie konfliktw dotyczcych wymaga i prior ytetw u ytkownika; prezentowanie punktu widzenia u ytkownika na temat Zalece Dziaa Nastpczych; u ytkownika we

zwize informowanie oraz doradzanie kierownictwu wszystkich sprawach dotyczcych projektu. Obowizki nadzorcze Gwnego U ytkownika to troska o to, aby:

specyfikacja potrzeb u ytkownika bya dokadna, kompletna i jednoznaczna; rozwj rozwizania we wszystkich etapach by monitorowany dla zapewnienia, epeni ono potrzeby u ytkownika oraz e postpuje w kierunku realizacji tego s celu; wpyw potencjalnych zmian by oceniany z punktu widzenia u ytkownika; zagro enia dotyczce u ytkownika byy czsto monitorowane; kontrole jakoci produktu na wszystkich etapach miay odpowiedni reprezentacj u ytkownika; procedury kontroli jakoci byy stosowane pr awidowo, by zagwarantowa, e produkty speniaj wymagania u ytkownika; czno z u ytkownikiem funkcjonowaa efektywnie.

W projektach, ktrych rozmiar, zo ono lub znaczenie to usprawiedliwiaj, Gwn y ytkownik mo e delegowa obowizki i uprawnienia zwizane z odpowiedzialnoci U za niektre obszary nadzoru.

B.4.

Gwny Dostawca

Senior Supplier

Gwny Dostawca reprezentuje interesy tych, ktrzy konstruuj, wytwarzaj, wspomaga- uj, wdra aj oraz w niektrych przypadkach eksploatuj i utrzymuj j, zaopatr produkty Ta rola jest odpowiedzialna za jako produktw dostarczonych przez projektu. dostaw- Rola Gwnego Dostawcy musi posiada uprawniania do anga owania lub c(-w). pozyskiwania zasobw dostawcy niezbdnych dla projektu. Nale y zauwa y, e w pewnych okolicznociach klient mo e dzieli z dostawc upraw- dotyczce konstrukcji produktw lub mie w ich sprawie gwny nienia gos.

425

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2 Jeli jest to konieczne, kilka osb mo e reprezentowa dostawcw. B.4.1. Szczegowy zakres obowi zkw Gwnego Dostawcy Uzgadnianie celw dziaalnoci dostawcy; upewnianie si, e postpy projektu w kierunku uzyskania wyniku kocowego s logiczne z punktu widzenia dostawcy; promowanie i utrzymywanie koncentracji projektu na po danych wynikach koco- projektu z punktu widzenia kierownictwa wych dostawcy; zagwarantowanie, e wymagane przez projekt zasoby dostawcy bd udostpniane; zatwierdzanie Opisw Produktu dla produktw dostawcy; prezentowanie opinii dostawcy przy podejmowaniu przez Komitet Sterujcy decyzji dotyczcych wdra ania proponowanych zmian; rozwizywanie konfliktw wymaga i priorytetw po stronie dostawcy; rozstrzyganie oraz zapewnianie rozwizania wszelkich konfliktw dotyczcych priorytetw lub zasobw po stronie dostawcy; zwize informowanie kierownictwa, ktre mo e nie mie dogbnej wiedzy specjalistycznej, o aspektach projektu dotyczcych dostawcy. Gwny Dostawca odpowiada za specjalistyczn integralno projektu. Obowizki zwi- z nadzorcz rol dostawcy zane to: doradzanie w sprawach wyboru strategii wytwarzania, konstruowania i stosowanych metod; zapewnienie, e wszelkie standardy dostawcy oraz eksploatacji dotyczce projektu s przestrzegane i wykorzystywane z dobrym skutkiem; monitorowanie, z punktu widzenia dostawcy, potencjalnych zmian oraz ich wpywu na prawidowo, kompletno oraz integralno produktw w odniesieniu do ich Produktu; Opisu monitorowanie wszelkich zagro e (ryzyka), dotyczcych wytwrczych aspektw projektu ; zagwarantowanie, eby procedury kontroli jakoci byy stosowane prawidowo, zapewniajc zgodno produktw z wymaganiami.

Jeli jest to uzasadnione, niektre z tych obowizkw nadzorczych mog by delegowane personelowi nadzoru dostawcy. W zale noci od konkretnego odrbnemu rodowiska klient/dostawca w projekcie, klient mo e tak e chcie wyznaczy osoby do sprawowania nad nadzoru produktami dostawcy.

B.5.

Kierownik Projektu

Project Manager

Kierownik Projektu posiada upr awnienia do bie cego prowadzenia projektu w imieniu Sterujcego, w ramach ogranicze okrelanych przez ten Komitetu komitet. Podstawowym obowizkiem Kierownika Projektu jest zapewnienie, aby projekt wytwarza wymagane produkty, zgodne z wymaganymi standardami jakoci oraz w ramach 42 6

PRINCE2 DODATEK B: ROLE W ZESPOLE ZARZDZAJCYM PROJEKTEM okrelonych ogranicze czasu i kosztw. Kierownik Projektu jest tak e odpowiedzialny za to, eby projekt wytworzy rezultat, ktry bdzie zdolny do osignicia korzyci biznesowych zdefiniowanych w Uzasadnieniu Biznesowym. B.5.1. Szczegowy zakres obowi zkw Kierownika Projektu Zarzdzanie wytwarzaniem wymaganych produktw; kierowanie i motywowanie zespou projektowego; planowanie i monitorowanie projektu; uzgadnianie wszelkich delegacji oraz sposobu wykorzystania roli Nadzoru Projektu, wymaganych przez Komitet Sterujcy; opracowanie Dokumentu Inicjujcego Projekt; przygotowanie Planw Projektu, Etapu i jeli to konieczne Planw Nadzwyczajnych wsplnie z Kierownikami Zespow oraz osobami wyznaczonymi do roli Nadzoru oraz uzgadnianie ich z Komitetem Projektu, Sterujcym; zarzdzanie zagro eniami wraz z opracowywaniem planw rezerwowych; utrzymywanie cznoci z kierownictwem programu, jeli projekt jest czci programu; utrzymywanie cznoci z kierownictwem programu lub powizanymi projektami w celu zagwarantowania, eby pewne prace nie zostay pominite ani nie byy wykonywane podwjnie; przyjcie odpowiedzialnoci za caociowe postpy i wykorzystanie zasobw oraz za inicjowanie w razie koniecznoci dziaa korygujcych; ponoszenie odpowiedzialnoci za Ster owanie zmianami oraz wymagane Zarzdzanie konfiguracj ; przygotowywanie raportw oraz raportowanie Komitetowi Sterujcemu za pomoc Okresowych oraz Raportw Kocowych Etapw; Raportw utrzymywanie cznoci z Komitetem Sterujcym lub osobami wyznaczonymi przez do roli Nadzoru Projektu w celu zapewnienia oglnego ukierunkowania i niego integralnoci projektu; uzgadnianie strategii dziaa technicznych i zwizanych z jakoci z waciwymi czonkami Komitetu Sterujcego; przygotowanie Raportu o Dowiadczeniach; przygotowanie wszelkich wymaganych Zalece Dziaa Nastpczych; przygotowanie Raportu Kocowego Projektu; okrelanie i pozyskiwanie wszelkiego wsparcia i pomocy potrzebnej do zarzdzania, planowania i sterowania projektem; ponoszenie odpowiedzialnoci za administrowanie projektem; utrzymywanie cznoci z dostawcami lub osobami zarzdzajcymi relacjami z lientem k ; penienie (jeli to konieczne) rl Kierownika Zespou oraz Wsparcia Projektu.

427

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2

B.6.

Kierownik Zespou

Team Manager

Podstawowym obowizkiem Kierownika Zespou jest zapewnienie wytworzenia okrelonych przez Kierownika Projektu produktw o waciwej jakoci, terminowo oraz po koszcie akceptowalnym dla Komitetu Sterujcego. Kierownik Zespou podlega Kierow- Projektu i przyjmuje od niego nikowi instrukcje. B.6.1. Szczegowy zakres obowi zkw Kierownika Zespou Przygotowanie Planu Zespou oraz uzgadnianie go z Kierownikiem Projektu; uzyskiwanie zgody od Kierownika Projektu na wytworzenie produktw pomoc Grupy Zada);

(za

zarzdzanie zespoem; kierowanie, planowanie i monitorowanie pracy zespou; ponoszenie odpowiedzialnoci za postpy prac zespou i wykorzystanie zasobw zespou, a tak e za inicjowanie dziaa naprawczych, jeli jest to konieczne, w ramach ogranicze nao onych przez Kierownika Projektu; powiadamianie Kierownika Projektu o wszelkich odchyleniach od planu, zalecanie dziaa korygujcych oraz pomoc w przygotowaniu waciwych Planw Nadzwyczajnych; przekazywanie Kierownikowi Projektu produktw, ktre zostay zakoczone i zatwierdzone zgodnie z ustalonymi wymaganiami Grupy Zada; zapewnienie, e wszystkie Zagadnienia Projektowe s waciwie przekazywane osobie prowadzcej Rejestr Zagadnie; zapewnianie oceny Zagadnie Projektowych, ktre pojawiaj si w ramach prac zespou or az przekazywanie zalece waciwych dziaa Kierownikowi Projektu; utrzymywanie cznoci z osobami penicymi rol Nadzoru Projektu; uczestniczenie w ocenach kocowych etapu, zgodnie z poleceniami Kierownika Projektu; organizowanie oraz prowadzenie narad zespou w punktach kontrolnych oraz przygotowanie Raportw z Punktw Kontrolnych, zgodnie z ustaleniami dokonanymi z Kierownikiem Projektu; zapewnienie, e kontrole jakoci prac zespou s planowane i przeprowadzane prawidowo; zapewnienie, aby dokonywano stosownych zapisw w Rejestrze Jakoci; prowadzenie samemu lub zapewnienie prowadzenia dokumentacji zespou; identyfikowanie oraz doradzanie Kierownikowi Projektu w kwestiach zagro e zwizanych z realizacj Grupy Zada; zapewnienie, eby wszystkie zidentyfikowane zagro enia byy wprowadzane do Rejestru Ryzyka; zarzdzanie konkretnymi zagro eniami zgodnie z poleceniami Kierownika Projektu.

42 8

PRINCE2 DODATEK B: ROLE W ZESPOLE ZARZDZAJCYM PROJEKTEM

B.7.

Nadzr Projektu

Project Assurance

Nadzr obejmuje interesy wszystkich stron uczestniczcych w projekcie, wczajc w to biznes, u ytkownika i dostawc. Nadzr Projektu musi by niezale ny od Kierownika Projektu, dlatego Komitet Sterujcy e delegowa Kierownikowi Projektu adnych ze swoich obowizkw nie mo nadzorczych.

B.7.1.

Szczegowy zakres obowi

zkw Nadzoru Projektu

Wypenianie obowizkw zwizanych z nadzorem wymaga odpowiedzi na pytanie: Coby nadzorowane?. Lista mo liwoci mogaby obj zapewnienie, ma e: w cigu caego projektu utrzymywana jest cisa czno midzy dostawc a klientem; potrzeby i oczekiwania u ytkownika s speniane lub zarzdzane; zagro enia s kontrolowane; Uzasadnienie Biznesowe jest przestrzegane; przyjmowane rozwizania s stale oceniane z punktu widzenia dostarczania wartoci, usprawiedliwiajcej poniesione koszty value-for; ( money) projekt jest zgodny z ogln strategi programu lub firmy; waciwe osoby bior udzia w tworzeniu Opisw Produktw;

zaplanowano zaanga owanie waciwych osb do kontroli jakoci we waciwych momentach wytwarzania produktu; personel jest waciwie przeszkolony w zakr esie procedur kontroli jakoci; waciwe osoby bior udzia w kontroli jakoci; procedury przegldw / kontroli jakoci s waciwie realizowane; dziaania nastpcze, wynikajce z kontroli jakoci, prowadzone s pr awidowo; realizowane rozwizanie jest mo liwe do zaakceptowania; prowadzenie projektu jest nadal uzasadnione; zakres projektu nie poszerza si niepostrze enie; zachowuje si koncentracj na potrzebach biznesowych; komunikacja wewntrzna i zewntrzna funkcjonuje zadowalajco; u ywane standardy s waciwe i mo liwe do zastosowania; przestrzegane s wszystkie ograniczenia prawne; speniane s wymogi specjalistyczne (np. bezpieczestwa); przestrzega si standardw zapewnienia jakoci. Nie wystarczy wierzy, e standardy lub normy bd przestrzegane. Nie wystarczy zapewnia, e projekt zosta dobrze zorganizowany i uzasadniony na pocztku. Wszystkie aspekty wymagaj sprawdzania przez cay czas trwania projektu w celu wymienione zapewnienia, e pozostaje on zgodny z potrzeb biznesow i nadal jej odpowiada, oraz e 429

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2 adna zmiana w zewntrznym rodowisku nie zmniejsza celowoci kontynuowania projektu. Nadzr Projektu musi wic kontrolowa tworzenie Planw Etapu i Planw Zespow, przygotowywanie Grup Zada i przygotowanie przegldw jakoci. W celu poznania szczegowych zda Nadzoru Projektu nale y zapozna si z ka dym z podrozdziaw opisujcych role Komitetu Sterujcego: - Przewodnic c , B.3 B.2 z y Gwny U ytkownik , B.4 - Gwny Dostawca .

B.8.

Wsparcie Projektu

Project Support

Zapewnienie jakiegokolwiek Wsparcia Projektu z formalnego punktu widzenia nie jest obowizkowe. Zadania musz by wykonane przez Kierownika Projektu lub by delegowane komu innemu, a jest to determinowane potrzebami konkretnego projektu i Kierownika Projektu. Wsparcie Projektu mo e przybiera form doradztwa na temat narzdzi zarzdzania projektem, poradnictwa czy usug administracyjnych, takich jak groma- dokumentacji, zbieranie danych o faktycznym przebiegu dla jednego lub dzenie wikszej liczby pokrewnych projektw. Jeli Wsparcie Projektu zostanie ustanowione jako formalne ciao, mo e odgr ywa rol r epozytor ium dowiadcze oraz scentralizowanego rda fachowej wiedzy, dotyczcej specjalistycznych narzdzi wspierajcych. Jedn z funkcji wspierajcych, ktra musi by wzita pod uwag, jest Zarzdzanie konfiguracj. W zale noci od rozmiarw projektu i rodowiska, mo e zaistnie potrzeba sformalizowania tej funkcji. Mo e si to szybko sta zadaniem, z ktrym Kierownik Pro- nie jest w stanie sobie por adzi bez wsparcia. Szczegy dotyczce roli jektu Bibliotekarza Konfiguracji przedstawiono w podrozdziale B.9. B.8.1. Szczegowy zakres obowi zkw Wsparcia Projektu Poni sza lista jest spisem sugerowanych zada: administrowanie sterowania zmianami; zakadanie i utrzymywanie dokumentacji projektu; ustanowienie procedur kontroli dokumentw; zestawianie, kopiowanie oraz dystrybucja wszystkich produktw zarzdczych projektu; zbieranie aktualnych/rzeczywistych danych oraz prognoz; uaktualnianie planw; administrowanie pr ocesem przegldu jakoci; administrowanie posiedzeniami Komitetu Sterujcego; po moc w opracowywaniu raportw; udostpnianie specjalistycznej wiedzy (np. o szacowaniu, zarzdzaniu ryzykiem); udostpnianie dowiadcze dotyczcych specjalistycznych narzdzi ( np. narzdzi do planowania i sterowania, analizy zagro e); znajomo specjalistycznych technik; znajomo standardw i norm.

43 0

PRINCE2 DODATEK B: ROLE W ZESPOLE ZARZDZAJCYM PROJEKTEM

B.9.

Bibliotekarz Konfiguracji

Configuration Librarian

Bibliotekarz Konfiguracji jest opiekunem i stra nikiem wszystkich oryginaw produktw projektu. Obowizkiem tej roli jest zwykle prowadzenie Rejestru Zagadnie. Gwne zadania to: nadzr nad przyjmowaniem wszystkich produktw projektu, nadawaniem im identyfikatorw, przechowywaniem i rozpowszechnianiem; dostarczanie informacji na temat statusu wszystkich produktw; numeracja, rejestr acja, przechowywanie i dystrybucja Zagadnie . Projektowych B.9.1. Szczegowy zakres obowi zkw Bibliotekarza Konfiguracji Planu Zarzdzania Pomaganie Kier ownikowi Projektu w przygotowaniu Konfiguracj (podczas Etapu inicjowania); tworzenie zasad identyfikowania dla wszystkich produktw; tworzenie bibliotek i innych miejsc magazynowych dla przechowywania produktw; pomaganie w identyfikowaniu produktw; utrzymywanie informacji o aktualnym statusie wszystkich produktw; akceptowanie i rejestrowanie przyjcia nowych i uaktualnionych produktw do waciwej biblioteki; zapobieganie dokonywaniu zmian wersji produktu, ktry zosta zgoszony jako gotowy do przegldu jakoci; kontrolowanie przypisywania numerw nowych wer sji zmienionym produktom; archiwizowanie kopii produktu, ktre zostay zastpione przez kolejne uaktualnienie; zagwarantowanie bezpieczestwa oraz ochrona or yginaw wszystkich pr oduktw; wydawanie, zgodnie z uprawnieniami, kopii produktw do przegldu lub w celach informacyjnych ; wydawanie, zgodnie z uprawnieniami, nowej wersji produktu do zmian lub poprawy; utrzymywanie rejestru wszystkich wydanych kopii; zawiadamianie posiadaczy o wszelkich zmianach w ich kopiach; prowadzenie Rejestru Zagadnie; monitorowanie obsugi wszystkich Zagadnie Projektowych oraz zagwarantowanie, e do biblioteki konfiguracji zostan one wprowadzone ponownie po jakikolwiek autoryzowanych zmianach; zbieranie i zachowywanie informacji pomocnych w dokonywaniu ocen, na ktre produkty projektu wpywa zmiana konkretnego produktu; sporzdzanie Zestawienia Statusu Produktw; pomaganie w przeprowadzaniu audytw konfiguracji; utrzymywanie cznoci z Bibliotekarzami Konfiguracji innych projektw w sytuacjach, gdy produkty danego projektu s wsplne z innymi systemami.

431

APPENDIX B: PROJECT MANAGEMENT TEAM ROLES PRINCE2

Project Suport Office (PSO) Pojcie Biura Wsparcia Projektu sprowadza si do zapewnienia centralnej puli wykwalifikowanych zasobw, mogcych peni rol Wsparcia Projektu, takie jak wsparcie biurowe, Bibliotekarz Konfiguracji, a mo liwe e nawet konsultantw z zakresu metodyki w poszczeglnych projektach. Biuro Wsparcia Projektu mo e by PRINCE2 powoane do wspierania konkretnego projektu lub grupy projektw, realizowanych przez organizacj. Oglne cele Biura Wsparcia to dostarczenie jednemu projektowi, lub Projektu wikszej ich liczbie, zasobw, ktre dysponuj kwalifikacjami zdefiniowanymi w rozdziaach: B.8 Wsparcie i B.9 Bibliotekarz . Zasoby te mog: Projektu Konfiguracji wspiera kierownikw w pracy administracyjnej; zapewni wsparcie w takich dziedzinach jak umiejtnoci stosowania narzdzi planistycznych, kontroli or az zarzdzania ryzykiem; zapewnia prawidowe i efektywne wykorzystywanie standardw PRINCE2 we wszystkich projektach. Biuro Wsparcia Projektu mo e by przydatne, gdy: ograniczone zasoby ludzkie, zarwno w sensie liczby jak umiejtnoci, utrudniaj zapewnienie obsady do wykonania funkcji administracyjnych w ka dym aktualnie realizowanym projekcie; istnieje pewna liczba maych projektw o zr nicowanym charakterze, ktre indywidualnie wymagaj tylko ograniczonego wsparcia ze strony Wsparcia Projektu; realizowany jest du y program wymagajcy koordynacji poszczeglnych projektw; du y projekt wymaga wielu zasobw do penienia roli Wsparcia Projektu. Biuro Wsparcia Projektu mo e dostarczy wszystkich usug zdefiniowanych dla rl opisanych w B.8 i B.9, ale obj one mog tak e niektre lub wszystkie obowizki z ni ej wymienionych, w przypadku prowadzenia dziaa w wielu projektach. B.10.1. Specjalne obowi zki Biura Projektw Obsuga centralnego systemu gromadzenia dokumentacji dla wielu projektw; obsuga zo onego systemu zarzdzania konfiguracj; penienie r oli centrum wiedzy fachowej na temat technik szacowania; dostarczania wiedzy dotyczcej u ywanych programw komputerowych do planowania i kontroli; doradzanie w zakresie przygotowywania planw; opracowywanie raportw, dotyczcych wielu projektw; utrzymywanie bazy historycznych danych o czasie trwania konkretnych dziaa; analizowanie produktywnoci; dostarczanie wiedzy i doradztwa w zakresie PRINCE2; doradzanie w zakresie analiz koszty/korzyci; koordynacja standardw; penienie obowizkw protokolanta lub nawet kierownika przegldu jakoci.

B.10. Biuro Wsparcia Projektu (BWP)

43 2

DODATEK C

KATEGORIE RYZYKA
AP PE NDI X C: RI S K CATEG O RI ES

Poni ej podane s kategorie ryzyka, ktre mo na wykorzysta jako punkt wyjcia d o identyfikacji gwnych obszarw ryzyka organizacji w odniesieniu do projektw lub programw. Strategiczne, handlowe: wykonanie prac poni ej poziomu specyfikacj; poziom zarzdzania poni ej oczekiwa; bankructwo wykonawcw; wymaganego

niewypacalno inicjatora projektu; niemo no spenienia przez dostawcw umownych zobowiza; dotyczy iloci, terminw lub ich wasnego nara enia na jakoci, ryzyko; niewystarczajce przychody kapitaowe; zmienno rynku; oszustwo lub kradzie ; niemo no wywizania si poddostawcw z zawartych umw; brak mo liwoci ubezpieczenia (lub koszty ubezpieczenia korzyci z niego wynikajce); brak dostpnoci kapitau inwestycyjnego.

mo e

to

przewy szaj

Ekonomiczne, finansowe, rynkowe: zmienno kursw walut; niestabilno stp procentowych; inflacja ; niedostatek kapitau pracujcego; niepowodzenie w osigniciu planowanych przychodw; negatywny wpyw wydarze rynkowych na plany. ce z regulacji prawnych:

celw

dotyczcych

Prawne i wynikaj

nowe lub zmienione prawo mo e uniewa ni zao enia, na ktrych oparto dziaania w projekcie; niepowodzenie zezwolenia; w uzyskaniu odpowiedniego zatwierdzenia, np. planu lub

nieprzewidziane wczenie war unkowych zobowiza; utrata praw intelektualnej; do wasnoci

433

APPENDIX C: RISK CATEGORIES niepowodzenie w osigniciu zadowalajcych rozwiza kontraktowych; nieoczekiwane regulacje prawne lub wymagania licencyjne; zmiany w strukturze podatkw lub taryf. czynnikiem

PRINCE2

Organizacyjne, dcze, zwi zane z zarz ludzkim: niekompetentne zarzdzanie; nieodpowiednia polityka firmy; nieodpowiednie zastosowanie praktyk zarzdczych; sabe przywdztwo;

nieodpowiednie uprawnienia kluczowego personelu do penienia swojej roli; ze pr ocedury selekcji pracownikw; brak jasnoci w rozumieniu rl i obowizkw; osobiste interesy wywoujce konflikt oraz nara ajce na szwank realizacj celw oglnych; nieuzasadniony priorytet przyznawany interesom indywidualnym grupowym; konflikty personalne; braki decyzji lub podejmowanie niewaciwych decyzji; brak wsparcia operacyjnego; niewaciwe lub niedokadne informacje; ograniczenia dotyczce bezpieczestwa i higieny pracy. lub

Polityczne: zmiana polityki rzdu (wewntrznej lub midzynarodowej), np. podejcia do nacjonalizacji ; zmiana rzdu; wojna lub rozruchy; niekorzystna opinia publiczna\interwencje mediw.

rodowiskowe: katastrofy naturalne; sztormy, powodzie, burze nie ne; wypadki ska e; problemy transportowe, wcznie z katastrofami lotniczymi i kolizjami pojazdw. eksploatacyjne,

Techniczne, infrastrukturalne: nieodpowiednia konstrukcja; niedbalstwo zawodowe;

43 4

PRINCE2 bd ludzki lub niekompetencja; uszkodzenie infrastruktury; trwao eksploatacyjna krtsza ni oczekiwana; warto zomowa aktyww ni sza ni oczekiwana; zwikszone koszty demonta likwidacji; zagro enie bezpieczestwa; bdy wykonawcze; u lub

DODATEK C: KATEGORIE RYZYKA

problemy z utrzymaniem pozostaoci po projekcie; pezajca zmiana zakresu projektu; niejasne oczekiwania; zaniedbania bezpieczestwa (w tym bezpieczestwa infor macji); brak lub niedostateczna cigo biznesu.

435

DODATEK D

SPRAWDZIAN ZGODNO CI Z PRINCE2

AP PE NDI X D: P RI NCE 2 HEA LTHCHECK

Bardzo u yteczne dla organizacji mo e by sprawdzenie prawidowoci stosowania w jej projektach metodyki PRINCE2. Poni szy zestaw pyta stanowi dobr podstaw takiego sprawdzianu. Pytania te mog by podstaw tabeli lub arkusza kalkulacyjnego z mo liwoci dokonywania wpisw w dodatkowych kolumnach, wskazujcych, czy i jak dobrze stosowany jest ka dy element metodyki. Przygotowanie projektu Czy wystawiono Zlecenie Przygotowania Projektu? Czy Komitet Sterujcy zaproponowano/mianowano zainicjowanie? Czy opracowano Zao enia Projektu? Czy Zao enia Projektu s zgodne ze standardami PRINCE2? Czy ustalono oczekiwania klienta? Czy ustalono Kryteria Akceptacji i Oczekiwania jakociowe klienta? Czy zostaa okrelona Formua Realizacji Projektu? Czy opracowano Plan Etapu inicjowania? Czy Plan Etapu inicjowania zosta zatwierdzony? Czy zao ono Rejestr Ryzyka?

przed

zezwoleniem

na

Inicjowanie Czy formalnie zezwolono na uruchomienie Etapu inicjowania? Czy zrealizowano pozycje agendy Zezwolenie podprocesu Projekt (ZS1)? u Czy istnieje Dokument Inicjujcy Projekt (DIP)? Czy DIP opracowano zgodnie ze standar dami PRINCE2?

na

Zainicjowanie

Czy wyznaczono cele projektu? Czy ograniczenia projektu zostay zidentyfikowane? Czy okrelone zostay tolerancje dla projektu? Czy rozpoznano wszelkie wspzale noci projektu? Czy ustalono zakres projektu? Czy s zdefiniowano procedury, zawarto i czstotliwo raportowania? Czy istnieje Plan Komunikacji, obejmujcy zarwno wewntrzne, zewntrzne potrzeby komunikacyjne? Czy DIP zawiera Plan Projektu?

jak

437

APPENDIX D: PRINCE2 HEALTHCHECK Czy w DIP znajduje si Uzasadnienie Biznesowe? Czy podano powody, dla ktrych podjto projekt? Czy wykonano ocen opacalnoci inwestycji koszty/korzyci? Czy dokonano przegldu jakoci DIP? Czy Komitet Ster ujcy formalnie zatwierdzi DIP? Czy Komitet Ster ujcy by zaanga owany w ten proces? Czy inicjowanie zakoczono, zanim r ozpoczto specjalistyczny mi?

PRINCE2

lub

analiz

prace nad produktami

Czy odbya si Ocena kocowa Etapu inicjowania Zezwolenie na (proces (ZS2))? Realizacj Projekt u Czy podczas oceny kocowej Etapu inicjowania zosta przedstawiony Planu Etapu (nastpnego) ? Czy Zagadnienia Projektowe dotyczce DIP byy zarzdzane efektywnie? Czy dano formalne zezwolenie na przejcie do nastpnego etapu?

Organizacja Czy istnieje Sterujcy? Czy wszelkie udokumentowane? Czy wiadomo, Sterujcy? Ktry czonek kierownictwu? Czy Gwny U obszary u ytkowania? Komitet ograniczenia komu uprawnie Komitet podlega naczelnemu Komitetu Sterujcego s

podlega

Komitetu

Sterujcego

ytkownik w sposb zadowalajcy reprezentuje wszystkie uczestnicz we wszystkich

Czy wszyscy czonkowie Komitetu Sterujcego ocenach nadzwyczajnych oraz ocenach kocowych etapw?

Czy czonkowie Komitetu Sterujcego s obci eni obowizkami w innych projektach? Czy wyznaczono Kierownika Projektu? Czy uzgodniono role Nadzoru Projektu? Czy wyjaniono rol Wsparcia Projektu? Czy ka dy czonek zespou zarzdzania projektem posiada opis zakresu obowizkw? Czy ka da osoba uzgodnia/podpisaa swj zakres obowizkw? Czy organizacj projektu uzgodniono przed zakoczeniem procesu (PP)? Projekt u Czy udokumentowana wersja organizacji projektu jest prawidowa? Czy rola dostawcy(-w) jest jasno zdefiniowana? Czy zarejestrowano wszelkie zmiany w zespole zarzdzania projektem? Czy Komitet Ster ujcy przeszed szkolenie dotyczce jego roli?

Przygotowani e

43 8

PRINCE2 DODATEK D: BADANIE KONDYCJI PROJEKTU Czy efektywnie wykorzystano rol Kierownika Zespou? Czy istniej zakresy obowizkw dla osb, ktre mianowano pniej?

Uzasadnienie Biznesowe Czy istnieje dokument Uzasadnienie Biznesowe? Czy powody podjcia projektu s jasno zdefiniowane i wa ne? Czy dokonano oceny opacalnoci inwestycji? Czy wartoci liczbowe s oparte na zdefiniowanych obiektach, ktre mo na mierzy? Czy Uzasadnienie Biznesowe zostao przekazane z prac przedprojektowych? Jeli tak, to czy wartoci liczbowe zostay zweryfikowane? Czy koszty wynikaj z Planu Projektu, czy z jakich innych danych? Czy korzyci przedstawiono w kategoriach, ktre mog by zmierzone w ramach przegldu poprojektowego? Czy wykonano pomiary stanu przed po to, by umo liwi dokonanie projektem porwnania podczas przegldu poprojektowego? Czy Uzasadnienie Biznesowe jest uaktualniane i przegldane podczas ka dej oceny kocowej etapu? Kto mierzy wpyw zmian Biznesowe? Czy oddziaywanie zmian na oceniane? Czy, jeli projekt jest czci jest peni w odzwierciedlone projekcie? na Uzasadnienie

Uzasadnienie Biznesowe jest programu, Uzasadnienie Biznesowe programu w

Ryzyko Czy Rejestr Ryzyka? istnieje Czy jest on aktualny? Czy ryzyko zwizane z realizacj ka dego planu jest zidentyfikowane, przeanalizowane oraz czy podjto odpowiednie dziaania? Czy jest wykorzystywana formalna procedura zarzdzania ryzykiem? Czy ocena ryzyka jest czci ka dej oceny kocowej etapu? Czy gwne zagro enia (ryzyko) uwzgldniono w Uzasadnieniu Biznesowym? Czy wskazano wacicieli zagro e? Czy zagro enia s monitorowane w sposb regularny i wystarczajco czsto? Czy ocena ryzyka jest czci oceny ka dego wniosku o wprowadzenie wikszej zmiany? Czy oceniano prawdopodobiestwo i wpyw zagro enia? Czy w razie koniecznoci podejmowano pro-aktywne dziaania zwizane z ryzykiem?

439

APPENDIX D: PRINCE2 HEALTHCHECK

PRINCE2

Czy przygotowano niezbdne plany rezerwowe? Czy rozpatrzono wszystkie oczywiste zagro enia? Czy ka de zagro enie i rodki przeciwdziaania mu byy przedyskutowane z Komitetem Sterujcym? Czy podjto odpowiednie przeciwdziaania? Czy, jeli zmieniono plan, wszystkie zagro enia zostay powtrnie ocenione?

Plan Projektu Czy istnieje Plan Projektu? Czy Plan Projektu jest zgodny z wymaganiami PRINCE2? Czy s sformuowane zao enia planistyczne? Czy Plan Projektu pokazuje podzia na etapy? Czy wszystkie zagro enia dotyczce planu zostay dodane do Rejestru Ryzyka? Jeli data zakoczenia zostaa narzucona, to czy jest ona realistyczna? Czy Plan Projektu poddano przegldowi jakoci? Czy osoby penice role nadzoru byy wczone w ten przegld? Czy zastosowano technik Planowanie oparte na produktach? Czy istnieje lista kontrolna dla kluczowych produktw? Czy istnieje Opis Produktu dla ka dego gwnego produktu? Czy Opisy Produktw sporzdzono w standardowym formacie PRINCE2? Czy dokonywano przegldu Opisw Produktw, zanim rozpoczto tworzenie tych produktw?

Plan Etapu Czy istnieje Plan Etapu dla ka dego etapu zarzdczego? Czy Plan Etapu odpowiada wymaganiom PRINCE2? Czy okrelono tolerancje dla etapu? Czy elementy sterowania etapem s okrelone i waciwe? Czy wyszczeglniono zao enia planistyczne? Czy wszystkie zagro enia dotyczce Planu Etapu zostay wczone do Rejestru Ryzyka?

zidentyfikowane i

Czy Plany Etapu s spjne z Planem Projektu? Czy planowanie kolejnego etapu jest prawidowo realizowane w ka dym etapie? Czy przeprowadzono przegldy jakoci Planw Etapu? Czy realizowany Plan Etapu zosta zatwierdzony? Czy w planowaniu etapw jest stosowane planowanie oparte na produktach? Czy dla ka dego etapu istnieje Lista Kontrolna Produktw?

44 0

PRINCE2 DODATEK D: BADANIE KONDYCJI PROJEKTU Czy Opisy Produktw maj format zgodny ze standardami PRINCE2? Czy dla ka dego produktu wy mienionego na licie kontrolnej istnieje Opis Produktu? Czy dokonuje si pr zegldu Opisw Produktw, zanim rozpocznie si proces ich wytwarzania? Czy Kierownicy Zespow/czonkowie zespow byli wczeni w planowanie? Czy Nadzr Projektu dokona przegldu projektu Planu Etapu? Czy Nadzr Projektu doda kontrole jakoci do projektu Planu Etapu? Czy Nadzr Projektu ustali nazwiska osb realizujcych te kontrole jakoci? Czy pr zewidziano czas i nakady pracy na dziaania zwizane z zarzdzaniem projektem ? Czy przewidziano czas na analiz Zagadnie Projektowych? Czy przyjto rozsdny wskanik efektywnoci personelu? Czy metody kontroli jakoci s okrelone dla ka dego produktu?

Sterowanie Czy narady w punktach kontrolnych odbywaj si z czstotliwoci ustalon w Pla-Etapu? nie Jakie informacje o faktycznych postpach s rejestrowane? Czy aktualizacja Planu Etapu faktycznymi danymi odbywa si regularnie? Czy czstotliwo uaktualniania jest wspmierna do zakresu planu? Czy s zapisy wydania zgody na wykonanie Grupy Zada i jej odbioru? Czy s zbierane oszacowania w celu uzupenienia innych informacji? Czy Lista Kontrolna Produktw jest aktualna? Czy s sporzdzane Raporty z Punktw Kontrolnych? Czy Raporty Okresowe s sporzdzane w sposb, jaki ustalono w planie? Czy Raporty Okresowe s sporzdzane zgodnie z uzgodnionym standardem? Czy Plan Etapu jest systematycznie sprawdzany pod ktem tolerancji? Czy wykorzystywane s Raporty o Istotnych Odchyleniach, gdy istnieje zagro enie przekroczenia tolerancji? Czy sporzdzono wszystkie wymagane Plany Nadzwyczajne? Czy byy prowadzone oceny nadzwyczajne w celu zatwierdzenia Planw Nadzwyczajnych? Czy etapy realizowano w ramach uzgodnionych poziomw tolerancji? Czy po zakoczeniu ka dego etapu przeprowadzano oceny kocowe etapu? Czy istnieje Raport Kocowy Etapu dla ka dego etapu? Czy Raport Kocowy Etapu jest zgodny ze standardem?

441

APPENDIX D: PRINCE2 HEALTHCHECK

PRINCE2

Czy dokumentacja towarzyszca ocenie kocowej etapu jest rozsyana przed posiedzeniem Komitetu Sterujcego? Czy Raport Kocowy Etapu jest zatwierdzany w ramach oceny kocowej etapu? Czy niedokoczone produkty s wczane do Planu Etapu (nastpnego)? Czy Komitet Sterujcy zatwierdza realizacj etapu i daje zezwolenie na kontynuowanie projektu? Czy w ocenach kocowych etapw uczestnicz waciwi czonkowie zespou zarzdzania projektem? Czy dziaania wynikajce z ocen kocowych etapu s dokumentowane?

Jako Czy klient sformuowa oczekiwania jakociowe? Czy sporzdzono Plan Jakoci Projektu? Czy Plan Jakoci Projektu pozwoli zaspokoi Oczekiwania jakociowe klienta? Czy Plan Jakoci Projektu wskazuje na konkretne procedury zapewnienia jakoci? Czy obowizki zwizane z zapewnieniem jakoci s okrelone w Planie Jakoci Projektu? Czy istniej plany jakoci etapu? Czy konkretne odpowiedzialne okrelone jakoci etapu? w planach

osoby

i metody

zapewnienia

jakoci

Czy istnieje Rejestr Jakoci? Czy Rejestr Jakoci jest aktualny? Czy zespoy prowadz jeden centralny Rejestr Jakoci? Czy Kierownik Projektu otrzymuje wystarczajce informacje zwrotne, aby zapewni akceptowaln jako? Czy osoby penice rol Nadzoru Projektu s wystarczajco zaanga owane w kontrolowanie jakoci? Czy dokumentacja jakoci i Rejestr Jakoci s ze sob spjne? Czy wszystkie osoby penice etatowo funkcje nadzoru jakoci w otoczeniu projektu s zadowolone ze wsppracy?

Przegl dy jako ci Czy przeszkolono osoby, ktre uczestnicz w przegldach jakoci? Czy podczas planowania etapu lub planowania prac zespou wyznaczono kierownika przegldu jakoci oraz testerw? Czy produkty s rozsyane przed naradami przegldu jakoci? Czy Opisy Produktw oraz puste formularze list zastrze e s rozsyane wraz z produktami ? Czy produkty s sprawdzane na ich zgodno z Opisami Produktw?

44 2

PRINCE2 DODATEK D: BADANIE KONDYCJI PROJEKTU Czy produkty Produktw? s sprawdzane z u yciem rodkw wymienionych w Opisach przegldu jakoci, narad i

Czy zaplanowano do czasu na przygotowanie dziaania nastpcze?

Czy listy zastrze e s wypeniane przed przegldami jakoci? Czy dla ka dej narady dotyczcej przegldu jakoci pr zygotowano agend? Czy testerzy, ktrzy nie mogli uczestniczy w naradzie przegldu jakoci, przysali zastrze listy e? Czy w ramach przegldw jakoci tworzone s listy dziaa nastpczych? Czy wprowadzone poprawki s zatwierdzane podpisem przez testerw? Czy wytwrcy (producenci) s zawsze obecni podczas przegldu jakoci? Czy w razie potrzeby przeprowadzane s przegldy powtrne? Czy dla ka dego przegldu zarejestrowano wynik przegldu?

Sterowanie zmianami Czy istnieje udokumentowana procedura dla sterowania zmianami? Czy ta procedura jest taka sama jak wy mieniona w Planie Projektu? Czy Zagadnienia Projektowe s rejestrowane? Czy istnieje Rejestr Zagadnie? Czy Zagadnienia Projektowe s regularnie oceniane? Czy ocenia si oddziaywanie Zagadnie Projektowych na Uzasadnienie Biznesowe? Czy ocenia si oddziaywanie Zagadnie Projektowych na Rejestr Ryzyka? Czy w zwizku ze wszystkimi Zagadnieniami Projektowymi podjto dziaania? Czy status Zagadnie Projektowych jest monitorowany? Czy jeli oddziaywanie Zagadnienia Projektowego mo e spowodowa przekroczenie tolerancji, jest ono przekazywane na poziom Komitetu Sterujcego? Czy plany s uaktualniane, aby odzwierciedli wprowadzenie uzgodnionych zmian? Czy dokonuje si rozr nienia midzy Odstpstwem a Wnioskiem o Wprowadzenie Zmiany? Zarz dzanie konfiguracj 443

Czy stosowana jest formalna metoda zarzdzania konfiguracj? Czy produkty s kontrolowane po ich przedo eniu do zarzdzania konfiguracj? Czy produkty posiadaj jednoznaczne identyfikatory? Czy zidentyfikowano zale noci midzy produktami? Czy produkty s identyfikowane jako wykonane? Czy produkty posiadaj identyfikatory wersji? Czy zapisy dotyczce produktw s aktualne?

APPENDIX D: PRINCE2 HEALTHCHECK Czy dokadno zapisw zwizanych z produktami jest regularnie sprawdzana? Czy przechowuje si wszystkie poprzednie wersje produktw? Czy atwo jest odzyska poprzednie wersje produktw? Czy zapisy stosowane w zarzdzaniu konfiguracj s zgodne z wymaganiami wsparcia?

PRINCE2

Czy rola Bibliotekarza Konfiguracji jest dobrze okrelona, przydzielona konkretnej uzgodniona z osobie i ni? Czy s tworzone nowe zapisy w trakcie planowania opartego na produktach?

Prowadzenie dokumentacji projektu Czy istnieje rozpoznawalny system dokumentacji? Czy jego struktura jest udokumentowana i dostpna? Czy obejmuje on produkty zarzdcze i specjalistyczne? Czy mo e przechowywa wiele wersji, np. planw? Czy system dokumentacji zachowuje cie k rewizyjn? Czy atwo jest znale potrzebne obiekty w systemie dokumentacji? Czy jest utrzymywana aktualno dokumentacji? Czy obowizki dotyczce gromadzenia dokumentacji s jasno okrelone w zakresach obowizkw?

44 4

DODATEK E

ZARZ DZANIE DOKUMENTACJ PROJEKTU

APP EN DIX E: P RO JE CT DOCUM ENT MANA GE ME NT

Metodyka PRINCE2 zaleca zaproponowan ni ej struktur zarzdzania dokumentacj do wykorzystania w projekcie w celu przechowywania dokumentw zarzdczych PRINCE2. Wyr nia si trzy rodzaje dokumentacji: dokumentacja Projektu; dokumentacja Etapw osobna dla ka dego etapu; dokumentacja dotyczca jakoci.

E.1.

Dokumentacja projektu

Posiada sekcje przedstawione w tabeli E.1. Tabela E.1. projektu

Dokument Inicjuj cy Projekt Organizacja Plany

Sekcje dokumentacji
Orygina zatwierdzonego Dokumentu Inicjujcego Projekt. Schemat organizacji projektu oraz podpisane zakresy obowizkw. Powinny by tu wczone wszystkie opracowane wersje Planu Projektu, a nie tylko ta jedna, ktre zostaa zatwierdzona jako cz Dokumentu Inicjujcego Projekt. Wszystkie skadniki poszczeglnych wersji (takie jak Diagramy Struktury Produktw, Diagramy Nastpstwa Produktw) powinny by przechowywane z precyzyjnym podaniem daty wytworzenia, numeru wersji oraz powodw wytworzenia, takich jak zmiana zaoe, zakresu, rezultaty etapu lub dostpno zasobw. Plan Projektu powinien by uaktualniany przynajmniej przy kocu ka dego etapu. Wersje Uzasadnienia Biznesowego, uaktualnione przy kocu ka dego etapu lub kiedy s tworzone Plany Nadzwyczajne. Uaktualnione szczegy wszystkich zidentyfikowanych zagro e, ich status oraz sposoby przeciwdziaania. Kopie zezwolenia na zainicjowanie i zamknicie projektu oraz dokumenty takie jak: Zlecenie Przygotowania Projektu, Zao enia Projektu, zatwierdzenia etapw przez Komitet Sterujcy oraz Rejestr Dowiadcze. W czasie procesu Zamykanie Projektu (ZP) tu wanie umieszczone zostan: Plan Przegldu Poprojektowego, Raport o Dowiadczeniach, Zalecenia Dziaa Nastpczych i Raport Kocowy Projektu. Opracowany w ramach Inicjowania Projektu (IP) i aktualizowany w razie potrzeby poprzez wczenie nowych zainteresowanych stron.

Uzasadnienie Biznesowe Rejestr Ryzyka Elementy sterowania

Plan Komunikacji

445

APPENDIX E: PROJECT DOCUMENT MANAGEMENT PRINCE2

E.2.

Dokumentacja etapw

Dla ka dego etapu projektu powinien istnie taki odrbny zbir dokumentacji (patrz Ta- E.2). bela

Tabela E.2. etapu

Organizacja

Sekcje dokumentacji
Organizacja etapu, szczegy dotyczce czonkw zespow. Powinny tu by odzwierciedlone wszystkie przydziay zada, osignicia oraz oceny realizacji prac dokonane przez Kierownika Projektu lub Kierownika Zespou. Uaktualniane w miar potrzeb kopie Planw Etapu, Planw Zespow (jeli s stosowane) oraz Plany Nadzwyczajne. Kopie zgd na wykonanie Grup Zada, Raporty z Punktw Kontrolnych, Raporty Okresowe, Raporty o Istotnych Odchyleniach, oceny kocowe etapu oraz wszelkie przeprowadzone oceny nadzwyczajne. Notatnik Kierownika Projektu, zawierajcy wydarzenia, problemy, pytania, odpowiedzi, nieformalne dyskusje z czonkami Komitetu Sterujcego oraz dziaania podejmowane w ramach etapu. Kopie korespondencji zarzdczej lub innych pism zwizanych z etapem.

Plany Elementy sterowania Dziennik

Korespondencja

E.3.

Dokumentacja jako

ci

Celem dokumentacji jakoci jest umo liwienie dokonania w dowolnym momencie audytu wykonanych prac oraz potwierdzenia przestrzegania standar dw jakoci. jakoci Istnieje jeden zbir dokumentacji jakoci, gromadzony przez cay czas trwania projektu, i nie jest dzielony pomidzy etapy. on Zawiera: Oczekiwania jakociowe klienta; Kryteria Akceptacji; Plan Jakoci Projektu - powinien tu by umieszczony oryginalny Plan Jakoci Pro- oraz wszelkie jego nastpne jektu wersje; Plan Zarzdzania Konfiguracj; Zapisy Obiektw Konfiguracji pierwotnie powinien si tu znale przynajmniej Opis Produktu dla ka dego produktu projektu, dla ktrego przewiduje si przegld W miar uzyskiwania kolejnych informacji, mo e powsta peny, jakoci. zgodny z wymogami Dodatku A, Zapis Obiektu Konfiguracji dla ka dego produktu. Produkty kontroli jakoci - u yteczne jest umieszczenie na pocztku tej sekcji Rejestru Jakoci, zawierajcego numer ka dej kontroli, kategori kontroli lub testu jako- (np. Przegld jakoci), produkt oraz dat. Daje to szybkie odniesienie, ci pozwalajce zobaczy lub pokaza, ile kontroli przeprowadzono w poszczeglnych etapach, oraz wskaza, gdzie mo na znale odpowiedni dokumentacj. Dalszy podzia sekcji kontroli jakoci bdzie zale a od rodzaju(-w) wykonywanych kontroli lub testw. Powinna istnie odrbna dokumentacja dla dokumentw 44 6

PRINCE2 DODATEK E: ZARZDZANIE DOKUMENTACJ PROJEKTU odnoszcych si do ka dego wpisu do Rejestru Jakoci. Ta dokumentacja powinna szczegy dotyczce stosowanych metod, wykorzystanych zasobw, zawiera podpi- dokument sany zatwier - jeli jest to waciwe, szczegy wykonanych dzajcy oczekiwane i faktyczne wyniki. Dokumentacja przegldw jakoci testw, powinna zawiera: zawiadomienia o przegldzie; listy dziaa; powiadomienia o wynikach. Zagadnienia Projektowe na pocztku dokumentacji powinien by umieszczony Re- Zagadnie, uatwiajcy nadawanie kolejnych numerw oraz zapis jestr statusu i przydziau Zagadnienia Projektowego. Oryginay Zagadnie powinProjektowych ny by umieszczone kolejno za tym rejestrem. Przedmiot Zagadnie Projektowych jest wyczerpujco opisany w Rozdziale Technika Sterowanie . 23 zmianami

447

Sownik Polsko Angielski terminw PRINCE2

Nazwy procesw i podprocesw
Nazwa polska Skrt English name Abbr. Przygotowanie Projektu PP Starting Up a Project SU Mianowanie Przewodniczcego i Kierownika Projektu Organizowanie Zespou Zarzdzania Projektem Mianowanie Czonkw Zespou Zarzdzania Projektem PP1 Appointing a Project Board Executive and Project Manager PP2 Designing a Project Management Team PP3 Appointing a Project Management Team SU1 SU2 SU3

Przygotowanie Zao e Projektu PP4 Preparing a Project Brief SU4 Okrelenie Formuy Realizacji Projektu PP5 Defining Project Approach SU5 Planowanie Etapu Inicjowania PP6 Planning an Initiation Stage SU6 Inicjowanie Projektu IP Initiating a Project IP Planowanie Jakoci IP1 Planning Quality IP1 Planowanie Projektu IP2 Planning a Project IP2 Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka IP3 Refining the Business Case and Risks IP3

Ustanowienie Elementw Sterowania IP4 Setting up Project Controls IP4 Ustanowienie Systemu Dokumentacji IP5 Setting up Project Files IP5 Zestawienie Dokumentu Inicjujcego Projekt IP6 Assembling a Project Initiation Document Zarz dzanie Strategiczne Projektem ZS Directing a Project DP Zezwolenie na Zainicjowanie Projektu ZS1 Authorising Initiation DP1 Zezwolenie na Realizacj Projektu ZS2 Authorising a Project DP2 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego ZS3 Authorising a Stage or Exception Plan DP3 IP6

Podejmowanie Decyzji Doranych ZS4 Giving Ad Hoc Direction DP4 Zatwierdzenie Zamknicia Projektu ZS5 Confirming Project Closure DP5 Sterowanie Etapem SE Controlling a Stage CS Zgoda na Wykonanie Grupy Zada SE1 Authorising a Work Package CS1 Ocena Postpw SE2 Assessing Progress CS2 Rejestrowanie Zagadnie Projektowych SE3 Capturing Project Issues CS3 Analizowanie Zagadnie Projektowych SE4 Examining Project Issues CS4 Przegld Stanu Etapu SE5 Reviewing Stage Status CS5 Raportowanie Okresowe SE6 Reporting Highlights CS6

449

POLISH - ENGLISH DICTIONARY

Nazwa polska Skrt English name Abbr. Podejmowanie Dziaa Korygujcych SE7 Taking Corrective Action CS7 Przekazywanie Zagadnie Projektowych SE8 Escalating Project Issues CS8 Odbir Wykonanej Grupy Zada SE9 Receiving Completed Work Package Zarz dzanie Wytwarzaniem Produktw WP Managing Product Delivery MP Przyjmowanie Grupy Zada do Wykonania WP1 Accepting a Work Package MP1 Wykonywanie Grupy Zada WP2 Executing a Work Package MP2 Oddanie Wykonanej Grupy Zada WP3 Delivering a Work Package MP3 Zarz dzanie Zakresem Etapu ZE Managing Stage Boundaries SB Planowanie Etapu ZE1 Planning a Stage SB1 Uaktualnienie Planu Projektu ZE2 Updating a Project Plan SB2 Uaktualnienie Uzasadnienia Biznesowego ZE3 Updating a Project Business Case SB3 Uaktualnienie Rejestru Ryzyka ZE4 Updating the Risk Log SB4 Raportowanie Koca Etapu ZE5 Reporting Stage End SB5 Opracowanie Planu Nadzwyczajnego ZE6 Producing an Exception Plan SB6 Zamykanie Projektu ZP Closing a Project CP Przygotowanie Projektu do Zamknicia ZP1 Decommissioning a Project CP1 Okrelenie Dziaa Nastpczych ZP2 Identifying a Follow on Actions CP2 Przegld Oceniajcy Projekt ZP3 Project Evaluation Review CP3 Planowanie PL Planning PL Projektowanie Planu PL1 Designing a Plan PL1 Okrelenie i Analizowanie Produktw PL2 Defining and Analysing Products PL2 Okrelenie Dziaa i Wspzale noci PL3 Identifying Activities and Dependencies Szacowanie PL4 Estimating PL4 Harmonogramowanie PL5 Scheduling PL5 Analizowanie Zagro e PL6 Analysing Risks PL6 Kompletowanie Planu PL7 Completing a Plan PL7

PRINCE2

CS9

PL3

Nazwy rl w zespole zarz

Nazwa polska English name

dzania projektem (wg Dodatku B)

Bibliotekarz Konfiguracji Configuration Librarian Biuro Wsparcia Projektu Project Support Office Gwny Dostawca Senior Supplier Gwny U ytkownik Senior User Kierownik Projektu Project Manager

45 0

PRINCE2
Nazwa polska English name Kierownik Zespou Team Manager Nadzr Projektu Project Assurance Przewodniczcy Executive Wsparcie Projektu Project Support

SOWNIK POLSKO ANGIELSKI

Komponenty PRINCE2
Nazwa polska English name Elementy sterowania Controls Jako w rodowisku projektu Quality in a project environment Organizacja Organisation Plany Plans Sterowanie zmianami Change Control Uzasadnienie biznesowe Business Case Zarzdzanie konfiguracj Configuration management Zarzdzanie ryzykiem Risk management

Produkty zarz

dcze PRINCE2 (wg dodatku A)

Nazwa polska English name Diagram Nastpstwa Produktw Product Flow Diagram Diagram Struktury Produktw Product Breakdown Structure Dokument Inicjujcy Projekt (DIP) Project Initiation Document (PID) Dziennik Daily Log Formua Realizacji Projektu Project Approach Grupa Zada Work Package Kryteria Akceptacji Acceptance Criteria Lista Kontrolna Produktw Product Checklist Oczekiwania jakociowe klienta Customers quality expectations Odstpstwo Off-Specification Opis Produktu Product Description Plan Etapu Stage Plan Plan Jakoci Projektu Project Quality Plan Plan Komunikacji Communication Plan Plan Nadzwyczajny Exception Plan

451

POLISH - ENGLISH DICTIONARY

Nazwa polska English name Plan Projektu Project Plan Plan Przegldu Poprojektowego Post-Project Review Plan Plan Zarzdzania Konfiguracj Configuration Management Plan Raport Kocowy Etapu End Stage Report Raport Kocowy Projektu End Project Report Raport o Dowiadczeniach Lessons Learned Report Raport o Istotnych Odchyleniach Exception Report Raport Okresowy Highlight Report Raport z Punktu Kontrolnego Checkpoint Report Rejestr Dowiadcze Lessons Learned Log Rejestr Jakoci Quality Log Rejestr Ryzyka Risk Log Rejestr Zagadnie Issue Log Uzasadnienie Biznesowe Business Case Wniosek o Wprowadzenie Zmiany Request for Change Zagadnienie Projektowe Project Issue Zalecenia Dziaa Nastpczych Follow-on Action Recommendations Zao enia Projektu Project Brief Zapis Obiektu Konfiguracji Configuration Item Record Zestawienie Statusu Produktw Product Status Account Zlecenie Przygotowania Projektu Project Mandate

PRINCE2

Pozostae okre

lenia

Nazwa polska English name Akceptacja przez klienta Customer acceptance Akceptacja przez su by operacyjne i utrzymania Analiza zagro e Risk analysis Analiza wartoci wypracowanej Earned value analysis Analiza wra liwoci Sensitivity analysis Audyt konfiguracji Configuration audit Blisko (zagro enia) Proximity (of risk) Bud et rezerwowy Contingency budget Bud et zmian Change budget Cykl ycia projektu Project life cycle Operational and maintenance acceptance

45 2

PRINCE2
Nazwa polska English name Decyzje dorane Ad hoc decisions Dokumentacja projektu Project records Dostawca Supplier Dyrektor Odpowiedzialny / Zarzdzajcy Senior Responsible Owner Dziennik ryzyka patrz Rejestr Ryzyka Risk Register see Risk Log Etap Etap inicjowania Initiation stage Etap zarzdczy Management stage Faza Grupa produktw Collective groupings Interesariusze Stakeholders Jako Quality Kierownictwo firmy lub programu Corporate/Programme management Kierownik przegldu jakoci Review chairperson Klient Customer Komisja (zesp) ds. zmian Change authority Korzyci biznesowe Benefis Kryteria jakoci Quality criteria Linia tolerancji ryzyka Risk tolerance line Niekorzystny efekt uboczny, strata Disbenefit Obiekt/stan odniesienia lub obiekt/stan bazowy (czsto w odniesieniu do planu stosuje si plan bazowy) Baseline Phase Stage

SOWNIK POLSKO ANGIELSKI

Obserwacja, nadzr, kontrola, monitorowanie Monitoring Ocena kocowa etapu End stage assessment Ocena nadzwyczajna Exception assessment Odchylenie Deviation Odpowiedzialno Accountability Okres ycia produktu Product life span Opis planu Plan text Plan bazowy patrz Obiekt/stan odniesienia Baseline Plan Etapu inicjowania Initiation Stage Plan Plan jakoci etapu Stage Quality Plan Plan rezerwowy Contingency plan Plan Zespou Team Plan Planowanie oparte na produktach Product based planning Powiadomienie o rozpoczciu projektu Project start-up notification Powiadomienie o zamykaniu projektu Project closure notification

453

POLISH - ENGLISH DICTIONARY

Nazwa polska English name PRINCE2 PRINCE2 Proces Process Produkt Product Produkt (Przedmiot dostawy) Deliverable Produkt integracji Integration product Produkt poredni Intermediate product Produkt prosty Simple product Produkt specjalistyczny Specialist product Produkt zarzdczy Management product Produkt zewntrzny External product Profil ryzyka Risk profile Program Programme Projekt Project Projekt zarzdzany zgodnie z PRINCE2 PRINCE2 project Protokolant Scribe Przedwczesne zamknicie projektu Premature project closure Przegld jakoci Quality review Przegld kontynuacyjny Gate review Przegld partnerski Peer review Przegld poprojektowy Post-project review Przegld powdro eniowy Post-implementation review Punkt kontrolny Checkpoint Raport o zasobach Resources report Realizowanie korzyci biznesowych Benefits realisation Role i obowizki Roles and responsibilities Ryzyko Risk Sie dziaa Activity network Specyfikacja Specification Sponsor Sponsor Stadium/stan produktu Product state Status produktu Product status Sterowanie konfiguracj Configuration control Studium wykonalnoci Feasibility study System jakoci Quality system System nadzoru jakoci Quality assurance system System zarzdzania jakoci Quality management system cie ka krytyczna Critical path

PRINCE2

45 4

PRINCE2
Nazwa polska English name Technika Sterowanie zmianami Change control technique Tester Reviewer Tolerancja Tolerance Ustpstwo Concession U ytkownik User Wykres (diagram) Gantta Gantt chart Wymagania Requirements Wynik, rezultat Outcome Wytwrca, dostawca, producent Producer Zakres Scope Zalecenie zamknicia projektu Project closure recommendation Zarys uzasadnienia biznesowego Outline business case Zarzdzanie odchyleniami Management by exception Zarzdzanie projektem Project management Zarzdzanie ryzykiem Risk management Zesp zarzdzania projektem Project management team Zestawienie statusu konfiguracji Configuration status account

SOWNIK POLSKO ANGIELSKI

455

English Polish Dictionary PRINCE2 terms

PRINCE2 process and sub-process names
English name Abbr. Nazwa polska Skrt Starting Up a Project SU Przygotowanie Projektu PP Appointing a Project Board Executive and Project Manager SU1 Mianowanie Przewodniczcego i Kierownika Projektu PP1 PP2 PP3

Designing a Project Management Team SU2 Organizowanie Zespou Zarzdzania Projektem Appointing a Project Management Team SU3 Mianowanie Czonkw Zespou Zarzdzania Projektem Preparing a Project Brief SU4 Przygotowanie Zao e Projektu PP4 Defining Project Approach SU5 Okrelenie Formuy Realizacji Projektu Planning an Initiation Stage SU6 Planowanie Etapu Inicjowania PP6 Initiating a Project IP Inicjowanie Projektu IP Planning Quality IP1 Planowanie Jakoci IP1 Planning a Project IP2 Planowanie Projektu IP2 Refining the Business Case and Risks IP3 Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka Setting up Project Controls IP4 Ustanowienie Elementw Sterowania Setting up Project Files IP5 Ustanowienie Systemu Dokumentacji Assembling a Project Initiation Document IP6 Zestawienie Dokumentu Inicjujcego Projekt Directing a Project DP Zarz Authorising Initiation DP1 Zezwolenie na Zainicjowanie Projektu Authorising a Project DP2 Zezwolenie na Realizacj Projektu Authorising a Stage or Exception Plan DP3 Zezwolenie na Realizacj Planu Etapu lub Planu Nadzwyczajnego Giving Ad Hoc Direction DP4 Podejmowanie Decyzji Doranych Confirming Project Closure DP5 Zatwierdzenie Zamknicia Projektu Controlling a Stage CS Sterowanie Etapem SE dzanie Strategiczne Projektem

PP5

IP3 IP4 IP5 IP6 ZS ZS1 ZS2 ZS3 ZS4 ZS5

457

ENGLISH POLISH DICTIONARY

English name Abbr. Nazwa polska Skrt Authorising a Work Package CS1 Zgoda na Wykonanie Grupy Zada Assessing Progress CS2 Ocena Postpw SE2 Capturing Project Issues CS3 Rejestrowanie Zagadnie Projektowych Examining Project Issues CS4 Analizowanie Zagadnie Projektowych Reviewing Stage Status CS5 Przegld Stanu Etapu SE5 Reporting Highlights CS6 Raportowanie Okresowe SE6 Taking Corrective Action CS7 Podejmowanie Dziaa Korygujcych Escalating Project Issues CS8 Przekazywanie Zagadnie Projektowych Receiving Completed Work Package CS9 Odbir Wykonanej Grupy Zada SE9 Managing Product Delivery MP Zarz dzanie Wytwarzaniem Produktw

PRINCE2

SE1

SE3 SE4

SE7 SE8

WP WP1

Accepting a Work Package MP1 Przyjmowanie Grupy Zada do Wykonania Executing a Work Package MP2 Wykonywanie Grupy Zada WP2 Delivering a Work Package MP3 Oddanie Wykonanej Grupy Zada Managing Stage Boundaries SB Zarz Planning a Stage SB1 Planowanie Etapu ZE1 Updating a Project Plan SB2 Uaktualnienie Planu Projektu ZE2 Updating a Project Business Case SB3 Uaktualnienie Uzasadnienia Biznesowego Updating the Risk Log SB4 Uaktualnienie Rejestru Ryzyka ZE4 Reporting Stage End SB5 Raportowanie Koca Etapu ZE5 Producing an Exception Plan SB6 Opracowanie Planu Nadzwyczajnego Closing a Project CP Zamykanie Projektu ZP Decommissioning a Project CP1 Przygotowanie Projektu do Zamknicia Identifying a Follow on Actions CP2 Okrelenie Dziaa Nastpczych ZP2 Project Evaluation Review CP3 Przegld Oceniajcy Projekt ZP3 Planning PL Planowanie PL Designing a Plan PL1 Projektowanie Planu PL1 Defining and Analysing Products PL2 Okrelenie i Analizowanie Produktw Identifying Activities and Dependencies PL3 Okrelenie Dziaa i Wspzale noci dzanie Zakresem Etapu ZE

WP3

ZE3

ZE6

ZP1

PL2 PL3

45 8

PRINCE2
English name Abbr. Nazwa polska Skrt Estimating PL4 Szacowanie PL4 Scheduling PL5 Harmonogramowanie PL5 Analysing Risks PL6 Analizowanie Zagro e PL6 Completing a Plan PL7 Kompletowanie Planu PL7

SOWNIK ANGIELSKO POLSKI

Project management team roles (Appendix B)

English name Nazwa polska Configuration Librarian Bibliotekarz Konfiguracji Executive Przewodniczcy Project Assurance Nadzr Projektu Project Manager Kierownik Projektu Project Support Wsparcie Projektu Project Support Office Biuro Wsparcia Projektu Senior Supplier Gwny Dostawca Senior User Gwny U ytkownik Team Manager Kierownik Zespou

PRINCE2 Components
English name Nazwa polska Business Case Uzasadnienie biznesowe Change Control Sterowanie zmianami Configuration management Zarzdzanie konfiguracj Controls Elementy sterowania Organisation Organizacja Plans Plany

Quality in a project environment Jako w rodowisku projektu Risk management Zarzdzanie ryzykiem

PRINCE2 management products descriptions (Appendix A)

English name Nazwa polska Acceptance Criteria Kryteria Akceptacji Business Case Uzasadnienie Biznesowe

459

ENGLISH POLISH DICTIONARY

English name Nazwa polska Checkpoint Report Raport z Punktu Kontrolnego Communication Plan Plan Komunikacji Configuration Item Record Zapis Obiektu Konfiguracji Configuration Management Plan Plan Zarzdzania Konfiguracj Customers quality expectations Oczekiwania jakociowe klienta Daily Log Dziennik End Project Report Raport Kocowy Projektu End Stage Report Raport Kocowy Etapu Exception Plan Plan Nadzwyczajny Exception Report Raport o Istotnych Odchyleniach Follow-on Action Recommendations Zalecenia Dziaa Nastpczych Highlight Report Raport Okresowy Issue Log Rejestr Zagadnie Lessons Learned Log Rejestr Dowiadcze Lessons Learned Report Raport o Dowiadczeniach Off-Specification Odstpstwo Post-Project Review Plan Plan Przegldu Poprojektowego Product Breakdown Structure Diagram Struktury Produktw Product Checklist Lista Kontrolna Produktw Product Description Opis Produktu Product Flow Diagram Diagram Nastpstwa Produktw Product Status Account Zestawienie Statusu Produktw Project Approach Formua Realizacji Projektu Project Brief Zao enia Projektu Project Initiation Document (PID) Dokument Inicjujcy Projekt (DIP) Project Issue Zagadnienie Projektowe Project Mandate Zlecenie Przygotowania Projektu Project Plan Plan Projektu Project Quality Plan Plan Jakoci Projektu Quality Log Rejestr Jakoci Request for Change Wniosek o Wprowadzenie Zmiany Risk Log Rejestr Ryzyka Stage Plan Plan Etapu Work Package Grupa Zada

PRINCE2

46 0

PRINCE2

SOWNIK ANGIELSKO POLSKI

Others
English name Nazwa polska Accountability Odpowiedzialno Activity network Sie dziaa Ad hoc decisions Decyzje dorane Baseline Obiekt/stan odniesienia lub obiekt/stan bazowy (czsto w odniesieniu do planu stosuje si plan bazowy) Benefits Korzyci biznesowe Benefits realisation Realizowanie korzyci biznesowych Change authority Komisja (zesp) ds. zmian Change budget Bud et zmian Change control technique Technika Sterowanie zmianami Checkpoint Punkt kontrolny Collective groupings Grupa produktw Concession Ustpstwo Configuration audit Audyt konfiguracji Configuration control Sterowanie konfiguracj Configuration status account Zestawienie statusu konfiguracji Contingency budget Bud et rezerwowy Contingency Plan Plan rezerwowy Corporate/Programme management Kierownictwo firmy lub programu Critical path cie ka krytyczna Customer Klient Customer acceptance Akceptacja przez klienta Deliverable Produkt (Przedmiot dostawy) Deviation Odchylenie Disbenefit Niekorzystny efekt uboczny, strata Risk Register see Risk Log Dziennik ryzyka patrz Rejestr Ryzyka Earned value analysis Analiza wartoci wypracowanej End stage assessment Ocena kocowa etapu Exception assessment Ocena nadzwyczajna External product Produkt zewntrzny Feasibility study Studium wykonalnoci Gantt chart Wykres (diagram) Gantta Gate review Przegld kontynuacyjny Initiation stage Etap inicjowania Initiation Stage Plan Plan Etapu inicjowania

461

ENGLISH POLISH DICTIONARY

English name Nazwa polska Integration product Produkt integracji Intermediate product Produkt poredni Management by exception Zarzdzanie odchyleniami Management product Produkt zarzdczy Management stage Etap zarzdczy Monitoring obserwacja, nadzr, kontrola, monitorowanie Operational and maintenance acceptance Akceptacja przez su by operacyjne i utrzymania Outcome Wynik, rezultat Outline business case Zarys uzasadnienia biznesowego Peer review Przegld partnerski Phase Faza Plan text Opis planu Post-implementation review Przegld powdro eniowy Post-project review Przegld poprojektowy Premature Project closure Przedwczesne zamknicie projektu PRINCE2 PRINCE2 PRINCE2 project Projekt zarzdzany zgodnie z PRINCE2 Process Proces Producer Wytwrca, dostawca, producent Product Produkt Product based planning Planowanie oparte na produktach Product life span Okres ycia produktu Product state Stadium/stan produktu Product status Status produktu Programme Program Project Projekt Project closure notification Powiadomienie o zamykaniu projektu Project closure recommendation Zalecenie zamknicia projektu Project life cycle Cykl ycia projektu Project management Zarzdzanie projektem Project management team Zesp zarzdzania projektem Project records Dokumentacja Projektu Project start-up notification Powiadomienie o rozpoczciu projektu Proximity (of risk) Blisko (zagro enia) Quality Jako Quality assurance system System nadzoru jakoci

PRINCE2

46 2

PRINCE2
English name Nazwa polska Quality criteria Kryteria jakoci Quality management system System zarzdzania jakoci Quality review Przegld jakoci Quality system System jakoci Requirements Wymagania Resources report Raport o zasobach Review chairperson Kierownik przegldu jakoci Reviewer Tester Risk Risk analysis Analiza zagro e Risk management Zarzdzanie ryzykiem Risk profile Profil ryzyka Risk tolerance line Linia tolerancji ryzyka Roles and responsibilities Role i obowizki Scope Zakres Scribe Protokolant Senior Responsible Owner Dyrektor Odpowiedzialny / Zarzdzajcy Sensitivity analysis Analiza wra liwoci Simple product Produkt prosty Specialist product Produkt specjalistyczny Specification Specyfikacja Sponsor Sponsor Stage Etap Stage Quality Plan Plan jakoci etapu Stakeholders Interesariusze Supplier Dostawca Team Plan Plan Zespou Tolerance Tolerancja User U ytkownik Ryzyko

SOWNIK ANGIELSKO POLSKI

463

Dodatkowe informacje
Poradniki najlepszych praktyk OGC
OGC (Office of Government opracowao du liczb poradnikw Commerce) dotyczcych strategii, zarzdzania programami, zarzdzania usugami, zaopatrzenia oraz zarz- wydajnoci. dzania Szczegy dotyczce poradnikw OGC mo na uzyska z: The OGC Service Desk Rosebery Court St Andrews Business Park Norwich NR7 0HS Telephone: (0845) 000 4999 Email: ServiceDesk@ogc.gov.uk Website: http://www.ogc.gov.uk

PRINCE2 akredytacje i egzaminy kwalifikacyjne

APM Group Ltd APM Group Limited (APMG) jest urzdem certyfikujcym w zakresie metodyki PRIN- akredytowanym przez UKAS zgodnie z EN45011 i EN45013. CE2, Od roku 1996 APMG jest strategicznym partnerem OGC w dziedzinie tworzenia i promocji standardw zawodowych zwizanych z wykorzystywaniem i wdra aniem PRINCE2. Dziaalno APMG wykracza poza granice Wielkiej Brytanii; wyczerpujcych informa- ten temat cji na mo na zasign pod adresem: http://www.ap mgroup.co.uk. The APM Group Limited Sword House Totteridge Road High Wycombe Buckinghamshire HP13 6DG Telephone: (+44 1494) 452450 Fax: (+44 1494) 459559 Email: info@apmgroup.co.uk Website: http://www.prince2.org.uk

4 64

PRINCE2

SOWNIK ANGIELSKO POLSKI

The Best Practice User Group

The Best Practice User Group jest niezale n non, ktrej celem organizacji zachcanie do u ywania wytycznych OGC w dziedzinie zarzdzania profit jest wsparcie projek-programami i ryzykiem. The Best Pr actice User Group prowadzi forum, tami, ktrego jest dzielenie si dowiadczeniami przez u ytkownikw tych celem wytycznych. Czonkostwo jest otwarte dla osb fizycznych i firm, a niesie ze sob szereg korzyci jak regularnie wydawane newsletters, abonament na pismo Project Manager Today, mo liwo udziau w regionalnych warsztatach i dorocznej konferencji, a tak e wsp- utrzymywaniu i budowie wytycznych OGC. praca w The Best Practice Group Services c/o WG 20 Tracious Close Horsell Woking Surrey GU21 3AF User

Telephone: (+44 870) 901 5583 Fax: (+44 870) 901 6581 Email: admin@usergroup.org.uk Website: http://www.usergroup.org.uk Komentarze i uwagi na temat PRINCE2, i Management of Guidance Risk: Practitioners Zagadnie OGC http://www.usergroup.org.uk\issues.

Managing for Programmes mog by Rejestrze

Successful rejestrowane w

465

INDEKS

A
akceptacja Grupy Zada..................................................... 142 przez klienta ............................................. 103, 179 przez su by eksploatacji i utrzymania .... 103, 104, 176, 178, 179, 363 akceptacja, reakcja na zagro enie ......................... 285 akredytacja........................................................ 4, 464 akta projektu ... 363 , Patrz te : dokumentacja projektu akta,dokumentacja ....... 175, 176, 178, 363 , Patrz te : archiwizacja; Zestawienie Obiektw Konfiguracji; dokumentacja projektu; dokumentacja jakoci analiza GAP.......................................................... 222 analiza wa rtoci wypracowanej .................... 116, 363 analiza wpywu definicja............................................................ 284 Plan Nadzwyczajny .......................................... 270 Plan Projektu .160, 162, 349, Patrz te : Sterowanie zmianami; analiza zagro e Raport Kocowy Etapu .................................... 185 Raport o Istotnych Odchyleniach ............... 93, 134 udzia Nadz oru Projektu........................... 239, 241 Ustpstwo......................................................... 124 Uzasadnienie Biznesowe ...160, 162, 224, 320, 349 Wniosek o Wprowadzenie Zmiany .................. 250 Zagadnienie Projektowe .....11922, 134, 224, 320, 349, 350 zmiany Zao e Projektu .................................... 40 analiza wra liwoci......................................... 65, 221 analiza zagro e........21013, 281, 28388, Patrz te : analiza wpywu; ocena ryzyka; profil ryzyka doprecyzowanie Uzasadnienia Biznesowego 64, 65 Kierownik Projektu .......................................... 211 Kierownik Zespou................................... 144, 212 Komitet Sterujcy..............................212, 281, 292 Nadzr Projektu........................................ 211, 240 planowanie projektu ........................................... 60 analizowanie Zagadnie Projektowych........... 11922 dziaania korygujce ......................................... 130 Komitet Sterujcy..................................... 120, 350 Nadzr Projektu........................................ 120, 239 Raport o Istotnych Odchyleniach ..................... 268 sterowanie etapem ............................................ 107 Uzasadnienie Biznesowe ...................120, 121, 224 Zarzdzanie ryzykie m .......................120, 291, 319 apetyt na ryzyko.............. Patrz: tolerancja dla ryzyka APM Group Ltd .................................................... 464 archiwizacja .............................17, 175, 176, 178, 180 audyt konfiguracji......................................... 312, 363 Nadzr Projektu................................................ 166 przygotowanie projektu do z amknicia ... 178, 179, 186 Raport o Dowiadczeniach............................... 186 raportowanie koc a etapu......................... 166, 168

B
Best Practice User Group...................................... 465 Bibliotekarz Konfiguracji ..............241, 310, 313, 431 audyt konfiguracji............................................. 312 dziaania korygujce ......................................... 131 Grupa Zada ......................................111, 138, 150 Kierownik Projektu jako .............................. 242 mianowanie ........................................................ 72 ocena postpu ................................................... 115 okrelenie i analizowanie produktw ............... 197 opracowanie Planu Nadzwyczajnego ............... 170 Plan Jakoci Projektu........................................ 302 prowadzenie Rejestru Zagadnie...................... 120 przegld stanu etapu ......................................... 124 przygotowanie projektu do zamknicia ............ 178 raportowanie koca etapu................................. 166 udostpnianie kopii produktu ........................... 312 udostpnianie produktu .................................... 311 Zagadnienie Projektowe ....118, 120, 135, 312, 313 Zestawienie Statusu Produktw........................ 312 Biuro Wsparcia Projektu..40, 188, 242, 315, 363 , 432 biznes czonkostwo Komitetu Sterujcego...229, 230, 234 relacje PRINCE2 z biznesem (Rys.) ..................... 9 blisko zagro enia ....................................... 284, 363 bud et ......... Patrz: bud et zmian, bud et rezerwowy, bud et Zarzdzania ryzykiem bud et rezerwowy ... 60, 64, 194, 195, 261, 363 , Patrz te : bud et Zarzdzania ryzykiem bud et Zarzdzania ryzykiem .....212, 289, 293, Patrz te : bud et rezerwowy bud et zmian....................................60, 320, 321, 363 Komitet Sterujcy................................60, 100, 320 projektowanie planu ................................. 194, 195 tolerancje i ................................................... 261 utworzenie .................................................... 56, 60 uzgodnienie ...................................................... 100 Zagadnienie Projektowe ........................... 121, 124

C
Central Computer and Telecommunications Agency (CCTA) . Patrz: Office of Government Commerce charakteryzowanie statusu .................................... 310 cykl zarzdzania ryzykiem.............................. 28288 cykl ycia projektu...................................7, 8, 11, 364 Rys ....................................................................... 8 czas element tolerancji ............................................. 259 element tolerancji (Rys.) ............................... 260 czonkostwo............................. Patrz te : mianowanie Komitet Sterujcy..........................23042, 22835 dostawca.... 85, 99, 228, 229, 230, 231, 233, 234 kierownictwo programu ............33, 37, 100, 235

467

PRINCE2
organizowanie zespou zarzdzania projektem ...................................................................33 u ytkownik ............................. 37, 229, 231, 234 zesp zarzdzania projektem .........................10 zmiany .......................................... 9, 98, 99, 100

DODATKOWE INFORMACJE
Nadzr Projektu .................................... 49, 74, 239 ocena ryzyka ....................................................... 87 okrelenie i analizowanie produktw ................198 Opisy produktw................................................. 75 organizacja i ................................................... 88 Plan Nadzwycz ajny...........................................170 planowanie etapu ..............................................157 planowanie Etapu inicjowania ................ 47, 48, 49 planowanie ja koci...................................... 57, 296 projektowanie planu..........................................194 przegld oceniajcy projekt .............. 185, 187, 188 przygotowanie proje ktu ...................................... 30 przygotowanie proje ktu do za mknicia.....179, 180 Raport Kocowy Projektu.................................272 Raport Okresowy ..............................................267 Rejestr Dowiadcze.........................................257 struktura orga nizacji projektu ............................. 73 lad rewizyjny ...................................................256 tolerancje dla projektu...................................75, 88 ustanowienie obie ktu odniesienia ......... 8687, 256 Wsparcie Projektu............................................... 74 Zagadnienie Projektowe............................121, 135 zakres obowizkw................................. 73, 74, 75 Zao enia Projektu ...................... 43, 48, 73, 74, 87 zamknicie projektu.................... 17, 103, 175, 253 zarzdzanie programem .............. 48, 74, 75, 85, 88 Zarzdzanie ryzykiem .......................................289 zarzdzanie strategiczne projektem...............14, 83 zarzdzanie zakresem etapu ........................ 72, 155 zatwierdzenie ........................................ 8591, 256 zawarto .......................................... 8788, 404 6 zesp z arz dzania projektem ..... 48, 73, 74, 75, 87 zestawienie...................................... 57, 7275, 239 zezwolenie na realizacj pla nu etapu .................. 94 zezwolenie na realizacj projektu ..... 72, 73, 8591 zgodno z kontraktem .........................................9 zmiany w ........................................................ 98 dokumentacja etapu.......................................313, 446 dokumentacja jakoci .....138, 263, 44647, Patrz te : Dokumentacja Projektu dokumentacja projektu17, 7072, 178, 239, 313, 445, Patrz te : archiwizacja; Zarzdzanie konfiguracj; dokumentacja jakoci doprecyzowanie Uzasadnienia Biznesowego .... Patrz: Uzasadnienie Biznesowe, prze gld dostawca 10, Patrz te : rodowisko klient dostawca; Gowny Dostawca; interesariusze; dostawca bdcy stron trzeci analiza wpywu .................................................350 czonkostwo w Komitecie Sterujcym. 85, 99, 228, 229, 230, 233 definicja ........................................................6, 364 finansowanie projektu...................................66, 85 Formua Realizacji Projektu..........................45, 47 inicjowanie projektu ........................................... 84 Opis Produktu ...........................................250, 333 Plan Jakoci Projektu .......................................... 58 patnoci dla .............................................66, 90 przygotowanie proje ktu do za mknicia.............177 Sterowanie zmianami........................ 319, 322, 350 strategiczne za rzdzanie projektem..................... 80 Uzasadnienie Biznesowe ............................ 66, 230 zarzdzanie jakoci ........... 55, 238, 300, 301, 304 Zarzdzanie ryzykiem .......................................280 zesp za rzdzania projektem ........... 33, 34, 36, 37 zezwolenie na realizacj planu etapu .................. 95 zezwolenie na realizacj projektu .................89, 90

D
decyzje dorane ...........................................14, 80, 81 Dziaania Korygujce........................................130 Odstpstwo .......................................................349 podproces .............................................. 93, 96100 Raport o Dowiadczeniach ...............................272 Raport o Istotnych Odchyleniach.............. 268, 292 Raport Okresowy ..............................................127 Zagadnienie Projektowe....................................134 definiowanie Formua Realizacji Projektu..... 30, 4447, 63, 239, 289 produkt 19698, 240, 311, 325, Patrz te : Diagram Struktury Produktw projekt........................................................... 73, 87 delegowanie ..........................................................228 obowizki Gwnego U ytkownika ....................37 obowizki Kierownika Projektu........................236 obowizki Komitetu Sterujcego ................37, 228 Komisja ds. zmian ................................ 120, 349 monitorowanie oddziaywa zewntrznych..100 Nadzr Projektu.. 35, 39, 90, 228, 234, 237, 262 waciciel ryzyka ..........................................282 Diagram Nastpstwa Produktw .. 325, 326, 335, 345, 364 , 399 dziaania ............................................ 198, 201, 335 grupa produktw ...............................................328 harmonogramowanie ........................................207 okrelenie i analizowanie produktw................197 poziom Planu Etapu (Rys.) ............................343 poziom Planu Projektu (Rys.) ........................341 produkt integracji...................................... 327, 328 produkt prosty ...................................................328 produkt zewntrzny...........................................331 zale noci.......................... 198, 326, 335, 345, 346 zorganizowanie konferencji (Rys) ......... 199, 339 diagram przepywu ryzyka (Rys.) ......................290 Diagram Struktury Produktw 325, 32632, 344, 364 , 395 , Patrz te : okrelenie i analizowanie produktw Diagram Nastpstwa Produktw i 335, 345, 346 okrelenie i analizowanie produktw........ 196, 197 Opis Produktu ........... 262, 326, 330, 332, 333, 345 poziom Planu Etapu ..........................................346 poziom Planu Etapu (Rys.) ............................342 poziom Planu Projektu......................................346 poziom Planu Projektu (Rys.) ........................340 zorganizowanie konferencji (Rys.) ................337 dodatkowe informacje dotyczce PRINCE2 ...46465 Dokument Inicjujcy Projekt........ 86, 87, 364 , 404 6, Patrz te : Kryteria Akceptacji; Uzasadnienie Biznesowe; Plan Komunikacji; Diagram Struktury Produktw; Elementy sterowania; Plan Projektu; Plan Jakoci Projektu; Rejestr Ryzyka decyzje dorane ..................................................98 definicja projektu .......................................... 73, 87 Formua Realizacji Projektu....................73, 74, 87 inic jowanie projektu ........... 15, 52, 53, 54, 72, 256 Kierownik Projektu52, 53, 74, 87, 88, 90, 235, 289 Komitet Sterujcy ... 14, 5254, 83, 87, 90, 98, 256

4 68

PRINCE2
dostawca b dcy stron trzeci ..................... 141, 322 dostpno za sobw.........49, 123, 146, 206, 207, 210 dowiadczenia (zdobyte)...15, 82, 102, 154, 232, 241, Patrz: ocena; przegld oceniajcy projekt droga do jakoci ............................................ 298303 Dyrektor odpowiedzialny..................... 364 , Patrz te : Przewodniczcy dziaania sie dziaa ....... 206, 207, 208, 326, 371, 410, 417, Patrz :cie ka krytyczna dziaania (prowadzce do wytworzenia produktw) 7, 45, 59, 191, 202, 203, 204 dziaania korygujce ....................................... 12932 przegld sta nu etapu ..........................122, 124, 125 Raporty Okresowe .................................... 128, 131 sterowanie etapem .............................................. 16 tolerancje w ukadzie cza s/koszt (Rys.) ......... 260 zgoda na wykonanie Grupy Zada ................... 130 zgoda na wykonanie Grupy Zada Grupy Zada ..................................................................... 109 zmiany planu .................................................... 266 dziaania nast pcze okrelenie ......................................................... 292 Przegld jakoci.................................355, 358, 359 Dziaania Na stpcze okrelenie ............................18084, 185, 224, 240 Dziennik.................................................270, 364 , 383 dziaania korygujce ......................................... 130 Grupa Zada......................................146, 147, 270 Kierownik Projektu14, 42, 124, 270, 284, 294, 304 Kierownik Zespou................................... 270, 304 ocena postpw ................................................ 116 przegld oceniaj cy projekt .............................. 187 przegld stanu etapu ................................. 124, 270 przygotowanie projektu...................................... 14 przygotowanie Zao e Projektu ........................ 43 utworzenie .................................................... 14, 42 zarzdzanie ja koci ......................................... 304 Zarzdzanie ryzykiem .............................. 284, 294 zarzdzanie zakresem etapu.............................. 155 Dziennik Ryzyka ..................... Patrz: Rejestr Ryzyka

SOWNIK ANGIELSKO POLSKI

finansowanie... 37, 66, 84, 85, 90, 232, 287, 319, 320, 350 finansowanie przez stron trzeci ........................... 85 Formua Realizacji Projektu ......................... 364 , 401 Dokument Inicjujcy Projekt...................73, 74, 88 dostawca ............................................................. 47 Gwny Dostawca .............................................. 46 inicjowanie ..............................................44, 49, 84 Kierownik Projektu ...................................... 46, 47 klient......................................................45, 47, 300 Komitet Sterujcy............................................... 47 Nadzr Projektu.......................................... 46, 239 okrelenie ..........................30, 4447, 63, 239, 289 organizowanie zespou zarzdzajcego projektem ................................................................. 35, 37 Plan Jakoci Projektu.......................................... 44 Plan Projektu ...................................29, 44, 46, 159 planowanie ................46, 49, 59, 60, 191, 193, 194 przygotowanie projektu.........................13, 29, 301 Rejestr Ryzyka ................................................... 46 Uzasadnienie Biznesowe .........................45, 63, 65 Wsparcie Projektu .............................................. 46 Zao enia Projektu...................................44, 45, 46 zamykanie projektu .......................................... 176 zarzdzanie jakoci i .................46, 54, 57, 301 zarzdzanie programem................................ 29, 30 Zarzdzanie ryzykiem ...................................... 289 zarzdzanie zakresem etapu.............................. 155 Zlecenie Przygotowania Projektu ................. 30, 45 funkcje audytu wewntrznego ................................ 36

G
Gwny Dostawca ..9, 37, 22930, 231, 233, 365 , 425 Formua Realizacji Projektu............................... 46 inicjowanie projektu ........................................... 85 Kierownik Zespou........................................... 237 Nadzr Projektu................................................ 241 planowanie etapu .............................................. 158 zakres obowizkw ............................................ 90 zesp zarzdzania projektem ............................. 37 Gwny U ytkownik........37, 231, 233, 234, 365 , 424 delegowanie obowizkw .................................. 37 nadzr jakoci..................................................... 37 Oczekiwania jakociowe klienta ........................ 41 planowanie etapu .............................................. 158 przygotowanie Zao e Projektu........................ 41 Raport z Punktu Kontrolnego i Raport Okresowy ..................................................................... 267 technika Sterowanie zmianami......................... 350 grupa dostawcw ............................................ 37, 234 grupa produktw......................32729, 333, 344, 346 grupa u ytkownikw.......... 4, 37, 234, Patrz te : Best Practice User Group Grupa Zada ..............................13751, 263, 419 20 Bibliotekarz Konfiguracji..................111, 138, 150 definicja ............................................................ 365 dziaania korygujce ................................. 109, 130 Dziennik ............................................146, 147, 270 Elementy sterowania .................................. 67, 263 etapy zarzdcze i ......................................... 113 jako ............................................................... 304 kontrakt ............................................................ 113 kryteria jakoci ..................................113, 143, 145 Lista Kontrolna Produktw .............................. 112 monitorowanie i raportowanie. 149, 254, Patrz te : Raport z Punktu Kontrolnego

E
elementy planu (Rys.) ........................................ 246 Elementy sterowania .... 19, 6670, 25177, Patrz te : Zarzdzanie konfiguracj; kontrola jakoci Dokument Inicjujcy Projekt...69, 74, 88, 256, 257 Komitet Sterujcy..............67, 80, 83, 88, 252, 253 Nadzr Projektu................................................ 239 ograniczenia dotyczce czasu ............................. 91 zale no od zdarze ........................................ 252 Elementy sterowania zale ne od czasu 252, Patrz te : punkty kontrolne; Raport Okresowy etap ............................................................19, 27377 definicja.................................................... 273, 364 Diagram Struktury Produktw.......................... 346 Grupa Zada. 11213, Patrz te : punkty decyzyjne podzia na 48, 59, 81, 91, 257, Patrz te : zakres etapu etap technicz ny ..................................................... 275 etap zarz dczy............................................ Patrz: etap

F
Faza....................................................................... 364 finanse............................... Patrz: koszt; finansowanie

469

PRINCE2
Nadzr Projektu........................................ 111, 112 ocena postpw.109, 113, 115, 116, 143, 144, 145, 147, 148, 239, 240 odbieranie wykonanej ....................... 106, 113, 138 oddanie wykonanej Grupy Zada ...............14951 okrelenie ..........................................................109 Opis Produktu ........... 110, 112, 113, 145, 263, 264 Plan Etapu......................... 111, 112, 145, 150, 291 Plan Nadzwyczajny...........................................111 podwykonawcy .................................................263 Przegld jakoci........................ 138, 148, 264, 352 przegld stanu etapu.................. 122, 123, 124, 126 przyjmowanie Grupy Zada do wykona nia 14346, 262, 263 Kierownik Zespou ................. 14346, 249, 291 Nadzr Projektu.................................... 145, 240 Plan Zespou................. 144, 145, 249, 264, 291 planowanie ...................................................190 Przegld jakoci............................................264 Zarzdzanie ryzykiem ..................................291 zgoda na wykonanie Grupy Zada 111, 144, 146 punkt kontrolny.................................................265 Rejestr Ryzyka .......................................... 112, 145 Rejestr Zagadnie .............................................112 sterowanie etapem....................... 16, 106, 107, 108 Sterowanie zmianami........................ 111, 113, 138 tolerancje 147, 254, 258, Patrz te : Rejestr Jakoci; Grupa Zada Wsparcie Projektu..................................... 111, 138 wykonywanie Grupy Zada113, 14649, 240, 254, 264, 352 Zapis Obiektu Konfiguracji .............. 110, 111, 138 zarzdzanie jakoci . 110, 112, 145, 147, 148, 254 Zarzdzanie ryzykiem ....... 110, 146, 147, 287, 291 zarzdzanie wytwarzaniem produktw ......16, 109, 14151 zawarto .................... 144, 254, 262, 263, 419 20 zgoda na wykonanie Grupy Zada..............10913 dziaania korygujce............................. 109, 130 Kierownik Projektu ................ 16, 254, 262, 291 Kierownik Zespou ......... 11011, 112, 113, 291 Nadzr Projektu............................ 111, 112, 239 oddanie wykonanej Grupy Zada......... 149, 150 Opis Produktu...............................................262 Plan Etapu ............................................ 112, 291 Plan Zespou......................................... 110, 254 przegld stanu etapu ..................... 122, 124, 126 przyjmowanie Grupy Zada do wykonania . 111, 144, 146 sterowanie etapem ................................ 106, 107 zarzdzanie jakoci ..................... 110, 304, 352 Zarzdzanie konfiguracj .............................313 Zarzdzanie ryzykiem .......................... 110, 291

DODATKOWE INFORMACJE
inicjowanie .... 11, 14, 5175, 25657, 274, 275, Patrz te : Dokument Inicjujcy Projekt inicjowanie projektu...................... 14, 5175, 25657 badanie Zaga dnie Projektowych .....................120 Dokument Inic jujcy Projekt ..... 15, 52, 53, 54, 72, 256 dostawca ............................................................. 84 finansowanie przez stron trzeci ....................... 85 Formua Realizacji Projektu.................... 44, 49, 84 Gwny Dostawca............................................... 85 interesariusze ...................................................... 54 Kierownik Projektu. 52, 53, 5254, 83, 84, 85, 289 Komitet Steruj cy ocena ryzyka.................................................289 poziomy uprawnie ......................................319 poziomy zarzdzania ....................................319 zezwolenie na ... .14, 49, 52, 53, 79, 8285, 253, 255 Nadzr Projektu ............................................49, 84 opracowanie Rejestru Jakoci ...........................303 Plan Jakoc i Projektu opracowanie .................................................301 planowanie.................. 49, 4750, 52, 81, 239, 244 planowanie jakoci............................................304 Przewodniczcy .......................................... 85, 231 przygotowanie projektu .................... 28, 43, 53, 83 Rejestr Jakoci opracowanie .................................................303 Rejestr Ryzyka............................................ 84, 289 Sterowanie zmianami........................................319 struktura ze spou zarzadzajcego projektem ....... 84 Uzasadnienie Biznesowe ... 14, 49, 53, 63, 81, 222, 223 Wsparcie Projektu............................................... 49 Zagadnienie Projektowe i .....................120, 319 zakres obowizkw............................................. 84 Zao enia Projektu .............. 43, 48, 49, 53, 84, 255 zarzdzanie programem .......................... 54, 84, 85 Zarzdzanie ryzykiem ................................. 85, 289 zesp za rzdzania projektem ............................. 84 zezwolenie na ............. 28, 8285, 253, 255, 289 zgodno z PRINCE2 ....................... 8285, 8285 integralno zmian .......................................... 32021 interesariusze......... 10, 365 , Patrz te : strony umowy; klient, Komitet Sterujcy; dostawca; u ytkownik Elementy sterowania ........................................... 68 inicjowanie projektu ........................................... 54 Nadzr Projektu ................................................238 Uzasadnienie Biznesowe ..........................223, 224 Zao enia Projektu ...................................... 41, 255 zesp za rzdzania projektem ............................. 36 ISO ........................................................ 295, 299, 300 Istotne odchyle nie ................................................. 365

H
harmonogramowanie .69, 91, 203, 20510, 212, te : terminy Patrz jako ...........................19,

J
365 , 442, Patrz te : ocena

I
identyfikacja produktw....... 310, 311, 312, Patrz te : kontrola wersji informacja o stanie etapu............... 115, 116, 125, 128 informowanie o projekcie................................79, 231 infrastruktura wspierajca 83, 85, 103, 177, 178, 180, Patrz te : Wsparcie Projektu

K
kategorie ryzyka ...................................... 283, 43335 Kierownik Projektu ................... 23537, 365 , 426 27 analiza zagro e........................................211, 292 audyt konfiguracji.............................................312 bud et z mian....................................................... 60 decyzje dorane ....3133, 96, 97, 98, 99, 100, 292, 349

4 70

PRINCE2
Diagram Nastpstwa Produktw ...................... 335 Diagram Struktury Produktw.......................... 327 Dokument Inicjujcy Projekt 5254, 74, 87, 88, 90, 235, 289 Dokumentacja Projektu ...................................... 71 Dziaania Nastpcze ..........................176, 182, 224 Dziennik ................14, 42, 124, 270, 284, 294, 304 Elementy sterowania .................................. 68, 254 etapy ................................................................. 273 Grupa Zada odbir wykona nej Grupy Za da................... 138 oddanie wykonanej Grupy Zada..149, 150, 151 przyjmowanie Grupy Zada do wykonania . 146 wykonywanie Grupy Zada ..........147, 149, 254 zawarto ..................................................... 263 zgoda na wykonanie Grupy Zada.17, 254, 263, 291 harmonogramowanie ........................................ 209 inicjowanie projektu ..................5254, 83, 85, 289 Kierownik Zespou i .....................236, 237, 258 Komitet Sterujcy i ......81, 93, 9799, 122, 231, 235, 258 kompletowanie planu................................ 214, 215 Lista Kontrolna Produktw .............................. 196 mianowanie .........................................81, 231, 236 monitorowanie.......................................... 232, 254 Nadzr Projektu i ......35, 39, 236, 238, 239, 241 Ocena kocowa etapu................................. 26869 Ocena nadzwyczajna ........................................ 269 Odstpstwo ....................................................... 349 okrelenie dziaa i wspzale noci ................ 201 okrelenie i analizowanie produktw ............... 197 okrelenie i analizowanie produtw ................. 196 okrelenie i wybr etapw................................ 277 Opis Produktu........................................... 262, 333 opracowanie Formuy Realizacji Projektu.... 46, 47 Plan Etapu ....... 9293, 96, 201, 203, 244, 248, 277 plan i bud et rezerwowy..................60, 64, 12932 Plan Jakoci Projektu........................................ 302 Plan Komunikacji ............................................... 88 Plan Nadzwyczajny .............93, 247, 250, 269, 350 opracowanie ............................93, 169, 170, 171 Plan Projektu .......................89, 159, 201, 203, 244 Plan Przegldu Poprojektowego ....................... 224 planowanie etapu...................................16, 81, 155 planowanie Etapu inicjowania ............................ 49 planowanie projektu ........................................... 60 plany i .......................................................... 244 profil ryzyka ..................................................... 288 projektowanie planu ................................. 194, 195 Przegld jakoci... 264, 353, 354, 355, 35658, 361 przegld oceniajcy projekt ...................... 185, 186 przegld sta nu etapu .....92, 122, 12324, 124, 269, 293 przekazywanie produktu................................... 311 przygotowanie projektu.........................14, 30, 255 przygotowanie projektu do z amknicia ... 134, 177, 178, 179, 180 Raport Kocowy Etapu ...............15, 166, 168, 269 Raport Kocowy Projektu ...........15, 166, 175, 185 Raport o Dowiadczeniach............................... 272 Raport o Istotnych Odchyleniach ..93, 98, 134, 268 Raport Okresowy...16, 98, 232, 266, 267, 282, 292 Raport z Punktu Kontrolne go ......17, 147, 254, 266 Rejestr Jakoci.......................................... 254, 264 Rejestr Ryzyka .... 64, 164, 254, 284, 288, 289, 291 rola Bibliotekarza Konfiguracji........................ 242

SOWNIK ANGIELSKO POLSKI

rola Kierownika Zespou ....35, 108, 142, 143, 146, 354 sterowanie etapem ...................16, 23, 10539, 277 Sterowanie zmianami ........282, 321, 347, 349, 350 strategiczne zarzdzanie projektem ..77, 78, 79, 80, 81, 82 struktura organizacyjna .............226, 228, 232, 235 szacowanie ....................................................... 203 tolerancje .............................................254, 25862 tolerancje dla ryzyka ........................................ 281 Uzasadnienie Biznesowe ......64, 87, 162, 222, 224, 254, 289 wasno zagro enia ................................. 282, 293 Wsparcie Projektu .........................35, 39, 236, 241 Zagadnienie Projektowe ........................... 282, 321 ocena wpywu .............................................. 120 przekazywanie.... 9799, 13235, 254, 265, 292, 349 wychwytywanie ................................... 117, 118 zakres etapu...........................................15, 81, 155 zakres obowizkw .................................32, 35, 36 zalecenie zamknicia projektu.......................... 178 zao enia Projektu .............................................. 42 Zao enia Projektu............................................ 255 zamknicie projektu .....17, 93, 101, 103, 175, 253, 271 zarzdzanie jakoci ........17, 56, 58, 235, 302, 304 Zarzdzanie ryzykiem .....64, 65, 100, 282, 28992 zarzdzanie wytwarzaniem produktw.16, 14143, 235 zatwierdzenie Planu Zespou .............244, 249, 254 zesp zarzdzania projektem ....................... 35, 39 Zestawienie Statusu Produktw........................ 312 zezwolenie na realizacj projektu ......87, 88, 89, 90 Zlecenie Przygotowania Projektu ............... 32, 255 zmiana planu .................................................... 266 kierownik przegldu jakoci 249, 264, 302, 353, 356 59, 360 Kierownik Zespou ................................237, 365 , 428 Diagram Nastpstwa Produktw ...................... 335 Diagram Struktury Produktw.......................... 327 dziaania korygujce ......................................... 131 Dziennik ................................................... 270, 304 Grupa Zada odbir wykonanej Grupy Zada................... 138 oddanie wykonanej Grupy Zada .......... 14951 przyjmowanie Grupy Zada do wykonania 143 46, 249, 291 wykonywanie Grupy Zada............14649, 254 zawarto ..................................................... 262 zgoda na wykonanie Grupy Zada.......111, 112, 113, 291 harmonogramowanie ........................................ 209 Kierownik Projektu i ....................236, 237, 258 Kierownik Projektu jako 35, 108, 142, 143, 146, 354 kompletowanie planu ....................................... 214 mianowanie ........................................................ 38 ocena postpw .................................114, 115, 116 okrelenie dziaa i wspzale noci ................ 201 okrelenie i analizowanie produktw ............... 197 Opis Produktu........................................... 262, 333 organizowanie zespou zarzdzania projektem... 35 Plan Nadzwyczajny .......................................... 247 Plan Zespou ..............................201, 203, 244, 249 planowanie etapu .............................................. 156 projektowanie planu ......................................... 194

471

PRINCE2
Przegld jakoci.......... 264, 353, 354, 355, 35658 punkt kontrolny.................................................265 Raport o Istotnych Odchyleniach......................268 Raport z Punktu Kontrolnego .....................17, 254 Rejestr Jakoci .................................. 254, 264, 303 sterowanie etapem.............................................108 Sterowanie zmianami................................ 111, 113 struktura organizacyjna.......................35, 226, 227 sygna do podjcia prac.....................................110 szacowanie ........................................................203 tolerancje .................................................. 254, 258 Zagadnienie Projektowe............................ 265, 268 zarzdzanie jakoci ................................. 301, 304 Zarzdzanie ryzykiem ....................... 144, 212, 291 zarzdzanie wytwarzaniem produktw 16, 23, 142, 14143, 236 zarzdzanie zakresem etapu..............................249 klient .10, Patrz te : Oczekiwania jakociowe klienta; interesariusze; u ytkownicy analiza wpywu zmiany.....................................350 definicja ........................................................ 6, 365 finansowanie projektu.........................................66 Formua Realizacji Projektu.................. 45, 47, 300 funkcja nadzoru jakoci ............................ 238, 301 Komitet Sterujcy reprezentacja..................... 99, 22829, 230, 234 kryteria jakoci.................................. 302, 333, 334 ocena Zagadnienia Projektowego .....................121 okrelenie i analizowanie produktw................197 Opis Produktu ........................... 250, 302, 333, 334 polityka jakoci.................................................300 przygotowanie projektu do zamknicia.... 177, 178, 179 rola Gwnego Dostawca ..................................230 struktura organizacyjna i ..............................228 system zarzdzania jakoci........ 55, 196, 299, 300 Uzasadnienie Biznesowe ....................................66 zamykanie projektu............. 17, 102, 104, 175, 176 zesp zarzdzania projektem ....................... 37, 40 zesp zarzdzannia projektem ...........................36 zezwolenie na realizacj projektu ................. 89, 90 Komisja ds. zmian.. 100, 120, 31920, 322, Patrz te : Wniosek o wprowadzenie zmiany Komitet Sterujcy......37, 228, 23035, 421 22 , Patrz te : Przewodniczcy; zarzdzanie odchyleniami; Nadzr Projektu; zezwolenie na realizacje projektu; strategiczne zarzdzanie projektem; Gwny Dostawca; Gwny U ytkownik analizowanie zagro e...................... 212, 281, 292 bud et zmian............................................. 100, 320 czonkostwo .................................. 23042, 22835 dostawca ......................... 99, 228, 229, 230, 233 dostawca .........................................................85 u ytkownik ............... 37, 85, 228, 229, 231, 234 zarzdzanie programem ...... 33, 37, 69, 100, 235 zmiany .......................................... 9, 98, 99, 100 delegowa nie obowiazkw .................................228 delegowa nie obowizkw ...................................37 Komisja ds. zmian ........................ 120, 349, 350 monitorowanie rde zewntrznych............100 Nadzr Projektu.. 35, 39, 90, 228, 234, 237, 262 waciciel ryzyka ..........................................282 Diagram Nastpstwa Produktw.......................336 Diagram Struktury Produktw ..........................327 Dokument Inicjujcy Proje kt ..... 54, 83, 86, 90, 98, 256 dziaania korygujce ................................. 129, 131

DODATKOWE INFORMACJE
Dziaania Na stpcze.................... 82, 181, 183, 272 dziaania zwizane z zakupami .............................9 Dziennik............................................................270 Elementy sterowania ......... 67, 80, 83, 88, 252, 253 Formua Realizacji Projektu................................ 47 Gwny Dostawca i .................................... 9, 37 Gwny U ytkownik i .................................... 37 harmonogramowanie ................................206, 207 informowanie otoc zenia o projekcie ........... 79, 232 inicjowanie projektu Dokument Inicjujcy Projekt.......................... 15 ocena ryzyka.................................................289 poziomy uprawnie ......................................319 zezwolenie na ... ...................................253, 255 zezwolenie na .............. 14, 49, 53, 79, 8285 Kierownik Projektu i . 81, 93, 96100, 122, 235, 258 Kierownik Ze spou i ....................................237 kompletowanie planu ................................213, 215 liczebno ........................................................... 37 Lista Kontrolna Produktw.......................192, 267 mianowanie przez Przewodniczcego............. 34, 35, 37, 235 przez zarzdzajcych programem 29, 34, 37, 81, 231, 235 zatwierdzenie i pniejsze mominacje ........... 88 monitorowanie prze z .... 14, 67, 78, 98, 100, 248 Nadzr Ja koci..................................................302 Nadzr Projektu ........................................231, 240 Ocena kocowa etapu ......................... 88, 253, 268 Ocena nadzwyczajna .................................253, 269 ocena ryzyka ....................................................... 87 Odstpstwo .......................................................349 Opis Produktu ...................................................262 Plan Etapu.................................................266, 275 zezwolenie 9196, 223, 231, 245, 255, 268, 269, 291 Plan Etapu inicjowania ............. 47, 48, 49, 83, 255 plan i bud et rezerwowy ...............................60, 87 Plan Jakoci Projektu .................................. 87, 302 Plan Komunika cji ................................... 78, 88, 99 Plan Nadzwycz ajny...........................................253 Uzasadnienie Biznesowe i ...............223, 270 Zarzdzanie ryzykiem ..................................291 zatwierdzenie .......................... 93, 250, 269, 291 zlecenie opracowania ................... 93, 98, 169 Plan Projektu....61, 81, 88, 158, 160, 244, 245, 248 planowanie projektu......................................58, 59 plany i .................................. 194, 195, 244, 245 podzia na etapy ................................................257 profil ryzyka......................................................288 przegld oceniajcy projekt ........................ 80, 185 przegld poprojektowy................ 82, 103, 183, 273 przegld stanu etapu..................................122, 125 przepyw informac ji......................................78, 82 przygotowanie proje ktu .................. 28, 29, 30, 255 przygotowanie proje ktu do za mknicia.... 177, 178, 179 Raport Kocowy Etapu............... 15, 165, 168, 269 Raport Kocowy Projektu.........................102, 273 Raport o Dowiadczeniach ............... 102, 186, 187 Raport o Istotnych Odchyleniach93, 124, 134, 253, 268, 292 Raport Okresowy .93, 100, 129, 12729, 253, 266 67, 288, 292 Rejestr Ryzyka..................................................289 reprezentacja dostawcy . 85, 99, 228, 229, 230, 234

4 72

PRINCE2
reprezentacja klienta ..............99, 22829, 230, 234 sterowanie etapem 16, 107, 108, 156, 273, 274, 277 Sterowanie zmianami ...10, 100, 31920, 321, 347, 349 szacowanie ............................................... 203, 205 tolerancje ............. 203, 258, 260, 261, 25862, 267 tolerancje dla ryzyka......................................... 281 udzia u ytkownikw ....37, 85, 228, 229, 231, 234 Ustpstwo.. 102, 124, 125, 132, 134, 136, 137, 350 Uzasadnienie Biz nesowe kontrola odc hyle........................................... 10 przegld przez ....................18, 219, 223, 253 przekazanie do programu ....................... 64, 162 waciciel za gro enia ................................ 282, 290 Wniosek o Wprowadzenie Zmiany .......... 272, 349 Wsparcie Proje ktu .............................................. 83 Zagadnienie Projektowe ........ Patrz te : Ustpstwo analizowanie ........................................ 119, 349 przekazywanie.........122, 124, 135, 137, 13237 szybko reakcji ........................................... 100 uprawnienia do wprowadzania zmian .. 319, 349 wychwytywanie ........................................... 117 zamknicie projektu ..................................... 103 zakres etapu.....................15, 81, 95, 153, 154, 155 zakres obowizkw ...................................... 35, 99 Zao enia Projektu.............................41, 43, 83, 87 zamknicie projektu ..14, 78, 93, 188, 253, 27173 zatwierdzenie ..................................... 82, 1014 zarzdzanie programem czonkostwo ........................33, 36, 69, 100, 235 mianowanie .............29, 34, 37, 39, 81, 231, 235 przepyw informac ji ................................. 78, 82 Zarzdzanie ryzykiem .....64, 66, 81, 280, 291, 292 zarzdzanie strategiczne projektem 14, 23, 77104, 230 zawieranie umw czynnoci ......................................................... 9 kompletowanie planu...............................21316, 240 komponenty ...........................1819, 2021, 217322 komponenty (Rys.).................................................. 12 komunikacja. Patrz te : Plan Komunikacji; Elementy sterowania; raporty i raportowanie mianowanie zespou zarzdzania projekte m....... 39 obowizek Przewodniczcego.......................... 232 projektu z programem............37, 54, 69, 78, 82, 99 struktura organizacyjna i ....................... 90, 227 Zarzdzanie ryzykiem ...................................... 281 zarzdzanie strategiczne ............................... 78, 79 kontrakt serwisowy ............................................... 180 kontrakty, umowy DIP....................................................................... 9 dostawcy zewntrzni ........................................ 322 PRINCE2 i ....................................................... 9 przygotowanie projektu do z amknicia ............ 180 sprawdzanie jakoci.......................................... 301 Sterowanie zmianami ........................121, 322, 350 struktura organizacyjna i ............................. 228 Zagadnienie Projektowe ................................... 121 zgoda na realizacj projektu ............................... 89 zgoda na wykonanie Grupy Zada ................... 113 kontrola jakoci..263, 303, Patrz te : kryteria jakoci; przegld jakoci definicja............................................................ 296 Formua Realizacji i .................................... 301 Gwny Dostawca ............................................ 233 kompletowanie planu........................................ 214 kontrakt ............................................................ 301

SOWNIK ANGIELSKO POLSKI

Nadzr Projektu........................................ 241, 301 Opis Produktu................................................... 296 planowanie jakoci ............................................. 55 Raport Kocowy Projektu................................ 166 Zarzdzanie konfiguracj ................................. 308 kontrola postpw232, 25862, Patrz te : Sterowanie zmianami; punkt kontrolny; Dziennik; Ocena kocowa etapu; Ocena nadzwyczajna; Raport Kocowy Etapu; Raport o Istotnych Odchyleniach; Raport Okresowy; Raport o Dowiadczeniach; Opis Produktu; Zagadnienie Projektowe; kontrola jakoci; Rejestr Jakoci; Rejestr Ryzyka; tolerancje; Grupa Zada kontrola wersji 10, 149, 30910, 310, 313, 315, Patrz te : ustalenie stanu odniesienia; sterowanie zmianami; audyt konfiguracji; dokumentacja projektu korzyci.... 365 , Patrz te : przegld oceniajcy projekt okrelenie ................................................. 221, 223 PRINCE2.......................................................... 24 realizacja ...................61, 65, 66, 79, 222, 232, 370 stan odniesienia dla pomiaru korzyci .............. 224 wpyw zagadnienia projektowego .................... 120 z Przegldu jakoci........................................... 351 zagro enia dla dostarczenia produktw a zagro enia dla korzyci................................ 293 zdefiniowanie w Uzasadnieniu Biznesowym .... 10, 63, 87, 162, 220, 222 koszt......... Patrz te : bud et zmian; bu et rezerwowy; patnoi; bud et na Zarzdzanie ryzykiem dziaania korygujce ......................................... 132 rwnowa enie ryzyka ....................................... 286 Sterowanie zmianami ............................... 320, 321 termin rozliczeni............................................... 103 tolerancje .................................................. 259, 261 Uzasadnienie Biznesowe .63, 65, 87, 221, 222, 223 Zagadnienie Projektowe ................................... 120 Kryteria Akceptacji...............299, 365 , 376 , Patrz te : Oczekiwania jakociowe klienta Grupa Zada ..................................................... 138 Opis Produktu................................................... 334 Plan Jakoci Projektu.............................42, 57, 412 przygotowanie projektu do zamknicia .... 178, 179 przygotowanie Zao e Projektu.....41, 42, 57, 402 Sterowanie zmianami ....................................... 319 zamykanie projektu .................................. 102, 175 zarzdzanie jakoci ..............................54, 55, 299 kryteria jakoci. Patrz te : kontrola projektu; przegld jakoci definiowanie ..................................................... 304 Grupa Zada ......................................113, 143, 145 klient..........................................302, 305, 333, 334 Nadzr Projektu................................................ 240 okrelenie i analizowanie produktw ............... 197 Opis Produktu............262, 296, 302, 304, 334, 345 Plan Etapu ................................................ 296, 302 planowanie jakoci ............................................. 57 Rejestr Jakoci.................................................. 303 kwalifikacje zawodowe..................................... 4, 464

L
leksykon terminw PRINCE2......................... 36373 linia tolerancji ryzyka ................................... 288, Lista Kontrolna Produktw................................... 396 definicja ...................................................... 18, dziaania korygujce ......................................... 131 366 366

473

PRINCE2
Komitet Sterujcy ..................................... 192, 267 kompletowanie planu ................................ 214, 215 ocena postpw......................................... 113, 115 okrelenie i analizowanie produktw........ 196, 197 opracowanie ................................................18, 196 planowanie ........................................................192 przegld stanu etapu.................................. 123, 125 Raport Okresowy .............................. 128, 196, 267 zgoda na wykonanie Grupy Zada....................112 listy kontrolne .. Patrz te : Lista Kontrolna produktw Przegld jakoci................................................360 zgodno z PRINCE2 .................................43744

DODATKOWE INFORMACJE
komunikacja........................................................ 90 kontrola jakoci......................... 239, 240, 241, 301 mianowanie ................................. 38, 231, 234, 237 nadzr ja koci ............................. 55, 296, 301, 302 Ocena nadz wyczajna .........................................269 ocena post pw.........................................115, 239 okrelenie dziaa i wspzale noci ................201 okrelenie i analizowanie produktw ........197, 240 Opis Produktu ...........................................240, 262 Plan Nadzwyczajny..................... 93, 170, 239, 240 Plan Projektu..................................... 159, 239, 240 Plan Zespou ............................. 240, 249, 301, 302 planowanie........................................ 192, 194, 240 planowanie eta pu ........ 93, 156, 192, 240, 249, 302 planowanie Etapu inicjowania .................... 49, 239 planowanie jakoci................ 55, 56, 239, 249, 302 planowanie projektu.................................... 60, 239 Przegld jakoci ................................................240 przegld stanu etapu.......................... 124, 239, 292 przygotowanie projektu do zamknicia.....178, 240 przygotowanie Zao e Projektu................. 42, 239 Raport Kocowy Etapu.............................166, 240 Raport Okresowy .............................. 128, 239, 267 Rejestr Jakoci .................................. 115, 239, 240 Rejestr Ryzyka.................................. 164, 239, 240 tester jakoci .............................................240, 302 Uzasadnienie Biznesowe ...... 49, 64, 162, 239, 241 Zagadnienie Projektowe.................... 120, 135, 239 zakres obowizkw...............................................9 zarzdzanie dostarczaniem produktw..............145 zarzdzanie jakoci .................................240, 302 Zarzdzanie ryzykiem ......... 49, 211, 239, 240, 292 zatwierdzenie zamknicia projektu ...................103 zesp za rzdzania projektem ............... 36, 38, 228 zesp za rzdzania projektu ..............................238 narada Przegldu jakoci.......................................355 narzdzia planistyczne..................... 59, 193, 194, 215 nominacja ...................................... Patrz : mianowanie

M
macierz umiejtnoci.............................................210 mianowanie Bibliotekarz Konfiguracji ......................... 131, 241 Kierownik Projektu............................... 3133, 231 Nadzr Projektu................................................238 obowizek ...........................................................39 Przewodniczcy ............................................ 3133 przez program .....................................................34 Wsparcie Projektu.............................................241 zesp zarzdzania projektem ..... 29, 3840, 81, 88 modyfikacje planu........... 266, Patrz te : zakres etapu monitorowanie...... Patrz te : ocena postpw; Nadzr Projektu; Elementy sterowania; sterowanie etapem analiza zagro e........................................ 211, 212 oszacowania czasu............................................210 Plan Projektu.....................................................248 zada nia Kierownika Projektu .................... 232, 254 zada nia Komitetu Sterujcego . 14, 67, 78, 98, 100, 248 zada nia Przewodniczcego ...............................232 Zarzdzanie ryzykiem ............................... 282, 287 monitorowanie ryzyka ...........................................287

N
nadzr jakoci....238, 296, Patrz te : Nadzr Projektu dostawca ..................................... 36, 238, 299, 301 klient ...................................................36, 238, 301 Plan Jakoci Projektu ........................................302 planowanie jakoci........................................ 56, 58 Raport o Dowiadczeniach ...............................272 zamknicie projektu..........................................188 zesp zarzdzania projektem ....................... 36, 37 Nadzr Projektu ........237, 239, 23741, 366 , 429 30 , Patrz te : nadzr jakoci audyt konfiguracji..................................... 166, 312 decyzje dorane ..................................................99 delegowanie obowiazkw ...................................39 delegowanie obowizkw ...................90, 237, 262 delegowanie odpowiedzialnoci .................35, 234 Dokument Inicjujcy Projekt ................ 49, 74, 239 Dokumentacja Projektu...............................71, 239 dziaania korygujce .........................................131 Elementy sterowania...........................68, 239, 252 Formua Realizacji Projektu........................46, 239 Grupa Zada ............. 111, 112, 145, 148, 239, 240 harmonogramowanie ........................................207 inicjowanie projektu ...........................................84 Kierownik Projektu i 35, 39, 236, 238, 239, 241 Komisja ds. zmian.............................................322 Komitet Sterujcy ............. 231, 234, 237, 238, 240 kompletowanie planu ........................ 214, 215, 240

O
obiekt odniesienia.................................. 221, 309, 366 obiekty cie ki krytycznej .............................126, 147 ocena ........ Patrz te : analiza wartoci wypracowanej; Raport Kocowy Projektu; Raport Kocowy Etapu; ana liz a wpywu; dowiadczenia; przegld poprojektowy; analiza zagro e; przegld stanu etapu projekt................................................... 80, 18488 ryzyko.......................................................281, 284 Uzasadnienie Biznesowe .............. 58, 92, 193, 221 Ocena kocowa etapu.............................. 26869, 366 Komitet Sterujcy ............................... 88, 253, 268 punkty decyzyjne ..............................................274 terminy................................................................ 95 Uzasadnienie Biznesowe .................. 219, 253, 269 zarzdzanie programem ....................................294 Ocena nadz wyczajna ..................... 169, 253, 269, 366 ocena opacalnoci inwestycji ................. 63, 221, 222 ocena post pw..10, 115, 11316, Patrz te : Raport z Punktu Kontrolnego, zarzdzanie wytwarzaniem produktw, Plan Projektu, uaktualnianie, przegld stanu etapu Grupa Zada ............. 109, 113, 115, 143, 148, 149 harmonogramowanie .......................................... 69 Nadzr Projektu ................................................115 Rejestr Ja koci .......... 113, 114, 115, 116, 264, 352

4 74

PRINCE2
Wsparcie Proje ktu .................................... 115, 254 Zagadnienie Projektowe ................................... 119 zarzdzanie jakoci ................................. 304, 352 ocena ryzyka .....45, 49, 59, 62, 85, 87, 239, Patrz te : analiza zagro e oczekiwania jakociowe... Patrz: Kryteria Akceptacji; Oczekiwania jakoc iowe klienta Oczekiwania jakociowe klienta ................... 366 , 382 Formua Realizaji Projektu............................... 300 Gwny U ytkownik .......................................... 41 Plan Jakoci Projektu.............................42, 87, 301 planowanie etapu.............................................. 156 przegld poprojektowy ..................................... 182 przygotowanie projektu.........................14, 29, 296 przygotowanie Zao e Projektu ........................ 41 zarzdzanie ja koci ......54, 57, 296, 298, 299, 302 odbir Grupy Zada.................... Patrz: Grupa Zada, wykonywanie; Grupa Zada, odbieranie wykonanej; Grupa Zada, oddanie odchylenia...... Patrz: Sterowanie zmianami; dziaania korygujce; Raport o Istotnych Odchyleniach; Zagadnienia Projektowe; tolerancje oddanie Grupy Zada..14951, Patrz te : zarzdzanie wytwarzaniem produktw odpowiedzialno za jako .................55, 56, 87, 301 odpowiedzialno za ryzyko .............. Patrz: wasno zagro enia Odstpstwo .........349, 366 , 393 , Patrz te : Ustpstwo decyzje dorane ...........................98, 322, 347, 349 przegld oceniaj cy projekt .............................. 187 Sterowanie zmianami ....................................... 319 Zagadnienie Projektowe ....................117, 137, 349 zarzdzanie ja koci ................................. 261, 303 Office of Government Commerce..................... 1, 464 ograniczenia dotyczce czasu Elementy sterowania i ................................... 91 okres ycia produktu ..................................... 7, 8, 366 Rys ....................................................................... 8 okrelanie produktw ...................... Patrz te : kontrola wersji okrelenie dziaania nastpcze ........................................... 292 Dziaania Nastpcze ............18084, 185, 224, 240 dziaa i wspzale noci ..................198202, 335 produkt ..............................................310, 311, 325 okrelenie i analizowanie produktw ......19698, 240, 32546, Patrz te : Diagram Struktury Produktw opis planu...............................................213, 215, 245 Opis Produktu ....................262, 33334, 367 , 39798 Diagram Nastpstwa Produktw .............. 335, 336 Diagram Struktury Produktw i ...262, 326, 330, 331, 332, 345 dostawca ................................................... 250, 333 Grupa Zada..............110, 111, 113, 145, 262, 264 klient..........................................250, 302, 333, 334 kontrola jakoci ................................................ 296 kryteria jakoci..........262, 296, 302, 304, 334, 345 Nadzr Projektu........................................ 240, 262 okrelenie dziaa i wspzale noci ........ 201, 336 okrelenie i analizowanie produktw ............... 197 Plan Etapu kryteria jakoc i............................................. 302 Planowanie oparte na produktach....325, 326, 333 34, 343, 345 pomoc w szacowaniu........................................ 203 produkt integracji ............................................. 327 Przegld jakoci.........264, 353, 355, 356, 359, 360

SOWNIK ANGIELSKO POLSKI

stadia produktw .............................................. 330 Sterowanie zmianami ................296, 333, 334, 347 u ytkownik........................................262, 333, 345 Zagadnienie Projektowe ................................... 303 zakres obowizkw i ....................................... 9 zestawienie DIP.................................................. 75 zorganizowanie konferencji (Rys.) ................ 338 oszacowanie ryzyka .......... Patrz te : analiza za gro e

P
ptla sterowania (Rys.)....................................... 252 plan Elementy sterowania ........................................ 213 Plan Etapu..........15558, 163, 246, 248, 274, 41718 analiza wpywu Zagadnienia Projektowego ..... 349 Diagram Nastpstwa Produktw (Rys.)......... 343 Diagram Struktury Produktw.......................... 346 Diagram Struktury Produktw (Rys.) ............ 342 Dokument Inicjujcy Projekt.............................. 94 dostawca ............................................................. 95 dziaania korygujce ................................. 131, 132 Grupa Zada .....111, 112, 145, 150, 291, Patrz te : Ocena kocowa e tapu; Plan Etapu inicjowania; sterowanie etapem harmonogramowanie ........................................ 207 inicjowanie projektu ..................................... 15, 52 Kierownik Projektu 9293, 96, 201, 203, 244, 248, 277 Komitet Sterujcy..................................... 267, 275 zezwolenie . 14, 9196, 223, 231, 245, 255, 268, 291 kompletowanie planu ............................... 214, 215 kontrola wersji.................................................. 313 kryteria jakoci ......................................... 296, 302 Nadzr Projektu...........................93, 192, 249, 302 Ocena nadzwyczajna ........................................ 269 ocena postpw .................................113, 114, 115 okrelanie i analizowanie produktw ............... 197 okrelenie dziaa i wspzale noci ................ 201 Opis Produktu................................................... 302 Plan Komunikacji ............................................... 94 Plan Nadzwyczajny ...........................170, 250, 367 Plan Okresowy ....................................93, 128, 267 Plan Projektu ...........9293, 94, 158, 159, 248, 274 planowanie ............................................... 192, 358 planowanie jakoci ......56, 192, 249, 296, 302, 304 prezentacja........................................................ 245 projektowanie planu ......................................... 195 Przegld jakoci.........................249, 302, 303, 358 przegld stanu etapu ..................123, 124, 125, 291 Raport Kocowy Etapu .......................94, 165, 167 Rejestr Jakoci.................................................. 303 Rejestr Ryzyka ................................................... 94 szacowanie ........................................202, 203, 205 tolerancje .................................................93, 95, 96 Uzasadnienie Biznesowe .........92, 93, 94, 163, 223 wykres Gantta................................................... 302 Zagadnienie Projektowe ....................120, 121, 349 zarzdzanie programem.......................95, 158, 168 Zarzdzanie ryzykiem .................248, 287, 29192 zarzdzanie zakresem etapu.........15, 153, 154, 248 zesp zarzdzania projektem ............................. 94 zezwolenie .............................9196, 231, 255, 268 przegld Uzasadnienie Biznesowego i ..... 93, 223 wersja sumaryczna ....................................... 245

475

PRINCE2
Zarzdzanie ryzykiem ..................................291 zarzdzanie zakresem etapu..........................153 zgodnoc z PRINCE2 .................................44041 Plan Etapu inicjowania ...................................... 4750 Elementy sterowania.........................................255 Komitet Sterujcy ......... 47, 48, 49, 50, 83, 84, 255 Nadzr Projektu................................................239 przygotowanie projektu .................. 14, 28, 29, 255 Zao enia Projektu........................................ 41, 48 zgoda na .........................................................81 Plan Jakoci Projektu ............................ 301, 367 , 412 Dokument Inicjujcy Projekt 74, 87, 248, 296, 301 Dokumentacja Projektu.......................................71 dostawcy .............................................................58 Elementy sterowania...........................................68 Formua Realizacji Projektu................................44 Komitet Sterujcy .......................................87, 302 Kryteria Akceptacji.............................................42 Nadzr Projektu................................................239 Oczekiwania jakociowe klienta ........... 42, 87, 301 okrelenie i analizowanie produktw................197 opracowanie ................................................55, 301 planowanie etapu .............156, 157, Patrz te : Plan Zarzdzania Konfiguracj planowanie jakoci.......................... 55, 57, 58, 296 planowanie projektu...................................... 58, 61 projektowa nie planu..........................................194 przegld oceniajcy projekt ..............................187 uaktualnie nie Planu Projektu ............................160 zarzdzanie jakoci ................................. 296, 302 zarzdzanie zakresem etapu.............. 155, 156, 157 Plan Komunikacji....................................99, 367 , 379 DIP......................................................................74 Dokumentacja Projektu.......................................71 Dziennik............................................................270 Elementy sterowania............................. 68, 69, 257 inic jowanie projektu ...........................................54 Kierownik Projektu.............................................88 mianowanie zespou zarzdzania projektem .......39 podejmowanie decyzji bie cych........................99 powiadomienie o zamykaniu projektu ..............104 przygotowanie projektu do zamknicia.... 178, 179, 180 Raport Kocowy Projektu.................................273 Raport Okresowy ...................................... 127, 128 raportowanie koca etapu .................................166 utworzenie .................................................... 68, 69 Uzasadnie nie Biznesowe ..................................223 zarzd programu i Komitet Sterujcy .....78, 88, 99 zatwierdzenie Planu Etapu ..................................94 zawarto .................................................. 257, 379 Plan Nadzwyczajny ................. 246, 24950, 367 , 386 analiza wpywu .................................................270 Biblioteka rz Konfiguracji .................................170 decyzje dorane ................................................100 DIP....................................................................170 Kierownik Projektu............. 93, 247, 250, 269, 350 Komitet Sterujcy Uzasadnienie Biznesowe i ............... 223, 270 Zarzdzanie ryzykiem ..................................291 zatwierdzenie.................. 93, 250, 253, 269, 291 zlecenie opracowania........................ 93, 98, 169 Nadzr Projektu..................................93, 170, 240 Ocena nadzwyczajna................................. 169, 269 opracowanie .................. 81, 93, 134, 153, 171, 350 Plan Etapu......................................... 170, 250, 367 Plan Projektu93, 158, 159, 169, 170, 171, 250, 367

DODATKOWE INFORMACJE
Plan Zespou ..................................... 247, 250, 367 Raport Kocowy Etapu.............................166, 167 Raport o Istotnych Odc hyleniach......................169 Rejestr Jakoci ..................................................170 Rejestr Ryzyka.................................................... 93 Rejestr Zagadnie .............................................170 Sterowanie zmianami........................................350 tolerancje .................................... 93, 168, 169, 171 Uzasadnienie Biznesowe ............ 92, 161, 170, 270 Zagadnienie Projektowe.............. 95, 132, 134, 136 zarzdzanie programem ...................... 93, 171, 284 Zarzdzanie ryzykiem ....................... 170, 270, 291 zarzdzanie zakresem etapu ........................ 15, 153 zezwolenie .....9196, 153, 223, 250, 253, 269, 291 zgoda na wykonanie Grupy Zada....................111 plan programu .......................................................247 Plan Proje ktu ............................. 24648, 367 , 410 11 analiza wpywu ................................. 160, 162, 349 Diagram Nast pstwa Produktw (Rys.) .........341 Diagram Struktury Produktw ..........................339 Diagram Struktury Produktw (Rys.) ............340 Dokument Inic jujcy Projekt .... 58, 73, 74, 89, 248 Dokumentacja Projektu.................................70, 71 Elementy sterowania ........................................... 68 Formua Realizacji Projektu.................. 44, 46, 159 Kierownik Projektu..................... 89, 159, 201, 244 Komitet Steruj cy ...61, 81, 88, 158, 160, 244, 245, 248 kompletowanie..................................................215 korekty .............................................. 169, 248, 257 Nadzr Projektu ................................ 159, 239, 241 Ocena kocowa etapu .......................................269 Ocena nadz wyczajna .........................................269 okrelenie dziaa i wspzale noci ........201, 202 okrelenie i analizowanie produktw ................197 opracowanie .................... 47, 48, 52, 53, 58, 59, 61 Plan Eta pu..................... 9293, 158, 159, 248, 274 Plan Nadzwyczajny..... 93, 158, 169, 171, 250, 367 plan rezerwowy................................................... 64 planowanie eta pu .............................. 156, 157, 158 planowanie projektu...................... 5862, 239, 277 projektowanie ...................................................195 projektowanie ...................................................194 przegld oceniajcy projekt ......................185, 187 przegld stanu etapu.......................... 124, 125, 291 Przewodniczcy i Kierownik Projektu mianowanie .................................................... 32 przygotowanie projektu ...................................... 30 Raport Kocowy Etapu..... 159, 165, 166, 168, 269 Raport Kocowy Projektu.................................272 Raport o Istotnych Odc hyleniach........................ 93 Rejestr Ryzyka..........................................160, 164 Rejestr Zagadnie .............................................160 sterowanie etapu ...............................................106 szacowanie........................................ 202, 203, 205 uaktualnianie................................. 65, 135, 15860 Uzasadnienie Biznesowe wejcie do .................... 58, 87, 221, 223, 248 wpyw na ....... 58, 6265, 160, 161, 162, 163 wymagania dotyczce terminw i zasobw........ 58 wymagania dotyczce zasobw ...... 58, 65, 68, 248 Zagadnienie Projektowe... 118, 121, 124, 134, 247, 349 zakres etapu .................................. 15, 81, 153, 155 Zapis Obiektu Konfiguracji ..............................257 Zarzdzanie konfiguracj ..................................314 zarzdzanie programem ................ 61, 88, 168, 250

4 76

PRINCE2
Zarzdzanie ryzykie m ...........61, 64, 248, 287, 291 zatwierdzenie .................................................... 244 zezwolenie na realizacj projektu................. 61, 89 zgodno z PRINCE2....................................... 440 Zlecenie Przygotowania Projektu....................... 32 Plan Przegldu Poprojektowego ................... 273, 394 Dziaania Nastpcze ................................. 183, 185 Kierownik Projektu .......................................... 224 Komitet Sterujcy..................................... 103, 273 Nadzr Projektu................................................ 240 Przewodniczcy........................................ 103, 273 Uzasadnienie Biznesowe .............63, 181, 223, 224 zamykanie projektu .............................17, 103, 104 Plan Zarzdz ania Konfiguracj ..................... 310, 381 Dokumentacja Projektu ................................ 70, 71 okrelenie i analizowanie produktw ............... 197 przygotowanie projektu do z amknicia .... 178, 179 Sterowanie zmianami ....................................... 321 utworzenie .......................................................... 56 Plan Zespou ................................................. 246, 249 aktualizacja Planu Projektu .............................. 160 analiza wpywu Zagadnienia Projektowego ..... 349 definiowanie etapw......................................... 277 Grupa Zada przyjmowanie Grupy Zada do wykonania 144, 145, 249, 254, 264, 291 wykonywanie Grupy Zada ......................... 148 zgoda na wykonanie Grupy Zada............... 110 harmonogramowanie ........................................ 209 Kierownik Projektu .......................................... 244 Kierownik Zespou........................................... 249 kompletowanie planu........................................ 214 okrelenie dziaa i wspzale noci ................ 201 okrelenie i analizowanie produktw ............... 197 Plan Nadzwyczajny ...........................247, 250, 367 planowanie ................................141, 144, 192, 358 planowanie jakoci ......................56, 192, 249, 302 Przegld jakoci.........................249, 264, 302, 358 Rejestr Jakoci.......................................... 264, 303 sporzdzanie ............................................... 17, 249 szacowanie ............................................... 202, 203 wykres Gantta................................................... 302 Zagadnienie Projektowe i ............................ 349 zarzdzanie jakoci ................................. 148, 302 Zarzdzanie ryzykie m .............................. 287, 291 zarzdzanie zakresem etapu........................ 16, 249 zatwierdzenie .....................................244, 249, 254 Planie Zarz dzania Konfiguracj okrelenie i analizowanie produktw ............... 197 planowanie18, 189216, Patrz te : plany; planowanie oparte na produktach; Plan Projektu; planowanie jakoci, planowanie etapu Etap inicjowania ................................................. 49 Etapu inicjowania ..............49, 4750, 81, 239, 244 Formua Realizacji Projektu .....46, 49, 59, 60, 191, 193, 194 modyfikacje planu ............................................ 266 Nadzr Projektu.................................192, 194, 240 ocena postpw ................................................ 116 Opis Produktu................................................... 262 Plan Zespou..............................141, 144, 192, 358 przegldw jakoci ................................... 351, 358 ustalenie toleranc ji............................................ 258 Zarzdzanie konfigura cj ................................. 310 Zarzdzanie ryzykiem .............................. 245, 287 zarzdzanie wytwarzaniem produktw............. 142 zarzdzanie zakresem etapu.............................. 153

SOWNIK ANGIELSKO POLSKI

planowanie etapu .. 15558, 237, 240, 264, 304, Patrz te : plan Etapu inicjowania planowanie jakoci....... 5458, 3013, Patrz te : Plan Jakoci Projektu definiowanie ..................................................... 296 Formua Realizacji Projektu............46, 54, 57, 301 Nadzr Projektu.......55, 56, 58, 239, 249, 301, 302 Oczekiwania jakociowe klienta ...54, 57, 296, 302 Plan Etapu ...................................56, 249, 296, 302 Plan Zespou ........................................56, 249, 302 Planowanie oparte na produktach .....19, 20, 189, 191, 277, 323, 32546, 367 , Patrz te : Diagram Struktury Produktw; Opis Produktu; Diagram Nastpstwa Produktw plany18, 191, 24350, Patrz te : Plan Na dzwyczajny; planowanie; Plan Projektu; Plan Jakoci Projektu; Plan Etapu; Plan Zespou Elementy sterowania .......................................... 68 obowizek Przewodniczcego.......................... 232 prezentacja.........................193, 213, 214, 215, 245 plany rezerwowe . 60, 64, 87, 95, 164, 287, 367 , Patrz te : Zarzdzanie ryzykiem patnoci dla dostawcw ................................... 66, 90 podwykonawcy .................... 195, 249, 263, Patrz te : interesariusze polityka jakoci ..................................................... 300 powiadomienie o koczeniu etapu..................................... 126, 157 o rozpoczciu projektu ............................... 84, 368 o zamykaniu projektu ..17, 103, 104, 179, 271, 368 poziomy planw.........................................18, 24650 poziomy produktu ................................................. 314 poziomy uprawnie............................................... 235 wprowadzanie zmian........................................ 320 poziomy zarzdzania............................................... 23 prace specjalistyczne.......... 9, 47, 275, 277, Patrz te : dostawca prawdopodobiestwo.............................283, 284, 288 prezentacja Dokument Inicjujcy Projekt.............................. 75 planowanie jej .................................................... 59 planw...............................193, 213, 214, 215, 245 PRINCE2......... 24, 721, 252, 368 , 43744, 46465 projekt zgodny z PRINCE2 .............................. 368 priorytet Zagadnienia Projektowego ............. 120, 348 procesy.........................................1318, 23216, 368 produkt.. Patrz te : Zarzdzanie konfiguracj; produkt poredni; produkty zarzdcze; planowanie oparte na produktach; produkt prosty; produkt specjalistyczny definicja .................................................6, 325, 368 etapy i .......................................................... 275 etapy i - (Rys.) ............................................. 276 rodzaje ........................................................ 32930 produkt integracji...................................327, 328, 345 produkt poredni ............................................. 32729 produkt prosty........................327, 328, 332, 333, 345 produkt specjalistyczny 329, 330, 331, 336, 344, 347 50, 368 , Patrz te : dostawca produkt zewntrzny ...............................331, 344, 345 produkty zarzdcze ................................329, 336, 368 produkty zarzdcze dotyczce jakoci (Rys.)..... 330 profil ryzyka ............................................66, 288, 368 program, definicja ............................................. 6, 368 projekt......................................... Patrz te : PRINCE2 definicja ........................................................ 7, 368 PRINCE2 relacje z biznesem (Rys.) ..................... 9

477

PRINCE2
projektowanie planu ................................... 191, 19295, 197, 240 zespou zarzdzania projektem 13, 29, 23042, 39, 237, 238 PROMPTII ................................................................1 protokolant .................... 353, 356, 357, 358, 361, 432 Prowadzenie dokumentacji projektu, zgodno z metodyk ..........................................................444 przedmiot dostawy ................................................ 368 przedwczesne zamknicie projektu .... 80, 82, 94, 175, Patrz te : zamknicie projektu decyzje dorane ................................................100 przegld oceniajcy projekt ..............................186 przekazywanie zagadnie projektowych.. 132, 134, 136 przekroczenie tolerancji ......................................95 przygotowanie projektu do zamknicia.... 177, 178, 179 Raport o Dowiadczeniach ...............................186 przegld .............. Patrz: przegld partnerski; przegld poprojektowy; Przegld jakoci; przegld stanu etapu Przegld jakoci 20, 263, 303, 323, 35161, Patrz te : Kontrola jakoci definicja .................................................... 351, 368 Grupa Zada ..................................... 138, 264, 352 Nadzr Projektu................ 240, 249, 264, 354, 358 okrelenie i analizowanie produktw................198 Plan Etapu................................. 249, 302, 303, 358 Plan Zespou ............................. 249, 264, 302, 358 wykres Gantta ...................................................302 zgodno z PRINCE2 .................................44243 przegld kontynuacyjny (Gate review)274, 369, Patrz te : Ocena kocowa etapu przegld oceniajcy projekt...... 80, 18488, Patrz te : Raport Kocowy Projektu; dowiadczenia (zdobyte); przegld Poprojektowy przegld partnerski (peer review) .................. 274, 369 przegld poprojektowy.. 273, 369 , Patrz te : przegld oceniajcy projekt funkcja ..............................................................182 Komitet Sterujcy ....................... 82, 103, 183, 273 okrelenie dziaa nastpczych ......... 181, 182, 183 przedwczesne zamknicie projektu.....................82 Przewodniczcy ................................ 103, 233, 273 przygotowanie projektu do zamknicia.............178 termin..................................................82, 181, 184 Uzasadnienie Biznesowe ............ 63, 182, 224, 232 zamknicie projektu..........................................175 przegld stanu etapu .......................12226, Patrz te : powiadomienie o koczeniu etapu; ocena postpw Dziennik.................................................... 270, 294 Kierownik Projektu............. 92, 122, 124, 269, 291 Nadzr Projektu................................ 124, 239, 292 Plan Etapu................................. 123, 124, 125, 291 Plan Projektu..................................... 124, 125, 291 planowanie etapu ..............................................157 przygotowanie projektu do zamknicia.............177 Raport Okresowy ...................... 122, 125, 126, 128 Rejestr Jakoci .......................... 123, 124, 125, 264 Rejestr Ryzyka .................................. 124, 125, 291 sterowanie etapem.............................................107 Uzasadnienie Biznesowe .................. 124, 125, 291 Zagadnienie Projektowe.... 120, 121, 125, 126, 291 Zarzdzanie ryzykiem ....................... 124, 126, 291 zarzdzanie zakresem etapu...................... 126, 153

DODATKOWE INFORMACJE
przekazywanie problemu...............................232, 288 przekazywanie Zagadnie Projektowych ........ 13237 Elementy sterowania ........................................... 67 Kierownik Projektu..................... 13235, 292, 349 Komitet Steruj cy ............... 122, 124, 13235, 137 Nadzr Projektu ........................................135, 239 Odstpstwo ...............................................137, 350 Plan Projektu..................................... 134, 135, 136 przegld stanu etapu.......................... 122, 124, 134 Raport o Istotnych Odc hyleniach..... 134, 135, 137, 292, 350 sterowanie etapem.............................................107 Sterowanie zmianami........................................350 Uzasadnienie Biznesowe ............ 64, 134, 135, 136 Zarzdzanie ryzykiem ....................... 135, 136, 292 przeniesienie, reakcja na zagro enie .....................285 Przewodniczcy-Komitetu Sterujcego..23133, 369 , 423 inicjowanie projektu ................................... 85, 231 mianowanie ..................................... 3133, 81, 235 mianowanie Komitetu Sterujcego .. 33, 35, 37, 39, 235 Oczekiwania jakociowe klienta ......................... 41 przegld poprojektowy...................... 103, 233, 273 Raport o Istotnych Odc hyleniach......................268 reprezentacja klienta .........................................229 strategiczne zarzdzanie projektem..................... 77 tolerancje ..........................................................258 Uzasadnienie Biznesowe .... 221, 22223, 232, 369 waciciel ryzyka ......................................282, 288 zakres obowizkw................................. 32, 36, 90 Zao enia Projektu .............................................. 42 zesp za rzdzania projektem .......................35, 39 Zlecenie Przygotowania Projektu .................31, 33 przygotowanie projektu ................. 13, 2750, 25558 Formua Realizacji Projektu............ 13, 29, 30, 301 inicjowanie projektu ......................... 28, 43, 53, 83 Oczekiwania jakociowe klienta ........... 14, 29, 296 planowanie jakoci............................................296 powiadomienie o rozpoczciu projektu....... 84, 368 Uzasadnienie Biznesowe ...................... 14, 29, 220 zgodno z PRINCE2 .......................................437 przygotowanie projektu do zamknicia ..134, 17680, 186, 240 przygotowanie, Zao enia Projektu ......................... 41 punkt kontrolny ....114, 116, 207, 246, 248, 257, 265 66, 369 , Patrz te : punkty decyzyjne ; zakres etapu punkty decyzyjne 14, 59, 78, 198, 219, 274, Patrz te : punkt kontrolny; zakres etapu punkty przegldu .................. Patrz: punkty decyzyjne

R
Raport Koc owy Etapu ........... 16568, 269, 369 , 385 harmonogramowanie ........................................207 Kierownik Projektu..................... 15, 166, 168, 269 Komitet Steruj cy ....................... 15, 165, 168, 269 kompletowanie planu ........................................214 Nadzr Projektu ........................................166, 240 obowiazek wa ciciela zagro enia ....................282 Plan Projektu..................... 159, 165, 166, 168, 269 Uzasadnienie Biznesowe .. 165, 166, 167, 223, 269 zarzdzanie zakresem etapu ................................ 15 Zestawienie Statusu Produktw........................312 zezwolenie na realizacj etapu ............................ 94 Raport Koc owy Projektu ............... 27273, 369 , 384 Kierownik Projektu...................................175, 185

4 78

PRINCE2
Komitet Sterujcy..................................... 102, 273 ocena me tod szacowania .................................. 194 ocena wpywu zman ................................. 185, 272 przedwczesne zamknicie projektu .................... 82 przegld oceniajcy projekt ...............185, 187, 188 zamykanie projektu .....................17, 102, 103, 175 zawarto .................................................. 185, 384 Zestawienie Statusu Produktw........................ 312 Raport o Dowiadczeniach ....................271, 369 audyt konfiguracji............................................. 186 inicjowanie projektu ........................................... 54 Komitet Sterujcy..............................102, 186, 187 planowanie ....................................................... 192 przedwczesne zamykanie projektu ............. 82, 186 przegld oceniajcy projekt .......185, 186, 187, 188 przygotowanie projektu...................................... 30 szacowanie ............................................... 194, 205 zamykanie projektu .....................17, 102, 104, 176 zarzdzanie programem .................................... 188 zawarto ...........................................186, 272, 392 Raport o Istotnych Odchyleniach...........268, 369 analiza wpywu........................................... 93, 134 decyzje dorane ...............93, 98, 99, 268, 292, dziaania korygujce ......................................... 131 Kierownik Projektu ............................................ 93 Komitet Sterujcy........93, 124, 134, 253, 268, 292 Plan Nadzwyczajny .......................................... 169 Plan Projektu ...................................................... 93 raportowanie koc a etapu................................. 166 Sterowanie zmianami ....................................... 350 Uzasadnienie Biznesowe .................................... 93 Zagadnienie Projektowe Kierownik Projektu .........................98, 134, 268 przegld........................................................ 268 przegld stanu etapu............................. 124, 125 przekazywanie 95, 134, 135, 137, 170, 268, 292, 350 sterowanie etapem .......................................... 16 tolerancje.............................................. 259, 268 Zarzdzanie ryzykiem .................................. 288 Zarzdzanie ryzykie m ........................................ 93 zarzdzanie strategiczne ..................................... 81 zawarto ............................................................ 93 Raport Okresowy . 12729, 26667, 26667, 370 decyzje dorane .......................................... 99, 100 dziaania korygujce ..........................128, 131, 214 Gwny U ytkownik ........................................ 267 Kierownik Projektu .......16, 98, 232, 266, 282, 292 Komitet Sterujcy...93, 100, 12729, 253, 26667, 288, 292 Lista Kontrolna Produktw ...............128, 196, 267 Nadzr Projektu.................................128, 239, 267 okrelenie i analizowanie produktw ............... 196 Plan Etapu .................................................. 93, 128 przegld sta nu etapu ..................122, 125, 126, 128 przekazywanie Zagadnie Projektowych ......... 137 sterowanie etapem ...................................... 16, 108 Zarzdzanie ryzykie m .......................282, 288, 292 Raport z Punktu Kontrolnego ................266, 370 Gwny U ytkownik ........................................ 267 Grupa Zada............................................. 147, 254 Kierownik Projektu .....................17, 147, 254, 266 Kierownik Zespou..................................... 17, 254 kompletowanie planu........................................ 214 ocena postpw .................................114, 115, 116 Raport Okresowy i ................................... 128, 266 waciciel za gro enia ........................................ 282

SOWNIK ANGIELSKO POLSKI

zarzdzanie dostarczaniem produktw ............... 17 raporty i raportowanie..... Patrz te : Raport w Punkcie Kontrolnym; Raport Kocowy Projektu; Raport Kocowy Etapu; Raport o Istotnych Odchyleniach, Raport Okresowy; Raport o Dowiadczeniach; monitorowanie, Elementy sterowania Grupa Zada ............................................. 148, 254 mianowanie czonkw zespou zarzdzania projektem ....................................................... 38 planowanie Etapu inicjowania...................... 48, 50 proba o rad .............................................. 99, 132 wymagane zasoby..................................... 214, 245 Zarzdzanie ryzykiem ...................................... 287 reakcje na zagro enie............................................ 285 redukowanie, reakcja na zagro enie ..................... 285 Rejestr Dowiadcze..............................271, 370 , 391 Dokument Inicjujcy Projekt............................ 257 oddanie wykonanej Grupy Zada ..................... 150 opracowanie ..........................15, 71, 185, 186, 271 przegld oceniajcy projekt...............185, 186, 187 raportowanie koca etapu..................166, 167, 168 Sterowanie zmianami ....................................... 321 zamykanie projektu .......................................... 176 Zarzdzanie konfiguracj ................................. 314 zarzdzanie zakresem etapu................................ 15 zawarto...........................185, 186, 187, 271, 391 Rejestr Jakoci ...............................264, 303, 370 , 413 Grupa Zada ..................................................... 254 odbir wykonanej Grupy Zada........... 138, 139 oddanie wykonanej Grupy Zada ................ 150 przyjmowanie Grupy Zada do wykonania . 145 wykonywanie Grupy Zada......................... 147 zgoda na wykonanie Grupy Zada110, 112, 145 Kierownik Projektu .................................. 254, 264 Kierownik Zespou............................254, 264, 303 Nadzr Projektu.........................115, 239, 240, 254 ocena postpw .........113, 114, 115, 116, 264, 352 opracowanie ....................................................... 15 Plan Nadzwyczajny .......................................... 170 planowanie etapu ...............................156, 157, 264 Przegld jakoci.........264, 352, 355, 356, 357, 358 przegld oceniajcy projekt.............................. 187 przegld stanu etapu ..................123, 124, 125, 264 Raport Okresowy.............................................. 129 raportowanie koca etapu................................. 167 utworzenie ...............................15, 56, 57, 264, 303 Zarzdzanie konfiguracj ................................. 314 zarzdzanie wytwarzaniem produktw....... 17, 145 Rejestr Ryzyka.......................................265, 370 , 415 analiza zagro e ........................212, 213, 284, 291 blisko zagro enia........................................... 284 Dokument Inicjujcy Projekt...................48, 74, 87 dziaania korygujce ......................................... 131 Elementy sterowania .................................. 68, 254 Grupa Zada ............................................. 112, 145 inicjowanie projektu ........................................... 84 Kierownik Projektu ...........164, 254, 284, 288, 289 Komitet Sterujcy..................................... 289, 290 Nadzr Projektu.................................164, 239, 240 ocena rzyka....................................................... 284 okrelenie dziaa i wspzale noci ........ 198, 201 okrelenie dziaa nastpczych................. 181, 183 okrelenie Formuy Realizacji Projektu.............. 46 oszacowanie ..................................................... 205 Plan Nadzwyczajny .................................... 93, 170 Plan Projektu ............................................ 160, 164 planowanie etapu .............................................. 157

, 392

, 387 387

, 389

, 378

479

PRINCE2
planowanie Etapu inicjowania ............................48 planowanie projektu............................................61 profil ryzyka......................................................288 przegld oceniajcy projekt ..............................187 przegld stanu etapu.......................... 124, 125, 291 przegld/aktualizacja ..... 62, 63, 162, 16364, 256, 290, 291 przygotowanie projektu .................. 14, 29, 30, 164 przygotowanie Zao e Projektu....... 40, 42, 43, 62 Raport Okresowy ..............................................128 raportowanie koca etapu .................................167 Reje str Zagadnie .............................................164 sterowanie etapem...............................................16 utworzenie ...................................... 18, 29, 42, 289 Uzasadnienie Biznesowe .................. 220, 221, 222 aktualizacja ................... 62, 63, 64, 65, 162, 164 Zagadnienie Projektowe... 120, 121, 135, 164, 319, 320 zarzadzanie zakresem etapu................................15 Zarzdzanie konfiguracj.......................... 257, 314 zarzdzanie programem ......................................66 Zarzdzanie ryzykiem .......................................291 zarzdzanie wytwarzaniem produktw ...............17 zezwolenie na realizacj planu etapu ..................94 zezwolenie na realizacj projektu .....................290 zezwolenie na zainicjowanie projektu ..............289 Rejestr Zagadnie.......................................... 370 , 390 aktualizacja Uzasadnienia Biznesowego...........162 Bibliotekarz Konfiguracji .................................120 dziaania korygujce .........................................131 ocena postpw.................................................115 okrelenie dziaa nastpczych ................. 181, 183 opracowanie .................................................. 15, 71 Plan Nadzwyczajny...........................................170 planowanie etapu ..............................................157 przegld oceniajcy projekt ..............................187 przegld stanu etapu..........................................125 przygotowanie projektu do zamknicia.............179 Raport Okresowy ..............................................128 raportowanie koca etapu .................................167 sterowanie etapem...............................................16 Sterowanie zmianami................ 318, 347, 349, 350 uaktualnienie Planu Proje ktu ............................160 uaktualnienie Rejestru Zagadnie .....................164 Zagadnienie Projektowe analiza .......................................... 119, 121, 318 przekazywanie ..............................................135 wychwytywanie............ 117, 118, 318, 347, 349 Zarzdzanie konfiguracj..................................314 zgoda na wykonanie Grupy Zada....................112 role w zespole zarzdzania projektem 9, 22735, 421 32 , Patrz te : zakres obowizkw rozpowszechnianie informacji...... Patrz: komunikacja rwnowaga pomidzy czasem,kosztem i ryzykiem ..........................................................................320 rwnowa enie zagro enia i kosztw reakcji ..................... 286, 320 ryzyko blisko zagro enia ................................... 284, 363 definicja .................................................... 279, 370 reakcje na .....................................................285 zgodno z PRINCE2 .................................43940 ryzyko dla dostarczenia produktw a ryzyko dla korzyci..................................................... 293, 294

DODATKOWE INFORMACJE

S
skalowalno ................................................... 25, 274 inicjowanie projektu ........................................... 53 planowanie........................................................192 przygotowanie projektu ...................................... 30 sterowanie etapem.............................................108 strategiczne zarzdzania projektem..................... 80 zamykanie projektu...........................................176 zarzdzanie wytwarzaniem produktw.............143 zarzdzanie zakresem etapu ..............................155 specjalista ds. jakoci ............................................334 specyfikacja ........................................................... 370 sponsor .................................................................. 371 spjno zmian ......................................................320 stadia produktu ......................................................330 standardy jakoci .55, 57, 58, 61, 120, 147, 240, Patrz te : Kryteria Akceptacji; Plan Jakoci Projektu standardy planowania .............................. 59, 194, 195 sterowanie 44142, Patrz te : Sterowanie zmianami; sterowanie konfiguracj; plan, Elementy sterowania; kontrola postpw; Elementy sterowania; kontrola jakoci; sterowanie etapem; kontrola wersji wiele zmia n.......................................................315 sterowanie etapem .......16, 23, 10539, 141, 143, 169, 27377, Patrz te : Ocena koc owa etapu; Plan Etapu; przegld stanu etapu sterowanie konfiguracj ........................ 310, 311, 371 Sterowanie zmianami ..... 10, 19, 20, 98, 31722, 323, 34750, 371 , Patrz te : Zagadnienie projektowe; kontrola wersji decyzje bie ce ................................................... 98 Grupa Zada .............................................111, 113 Kierownik Projektu........... 282, 321, 347, 349, 350 Kierownik Zespou ...................................111, 113 Komitet Steruj cy ...10, 98, 100, 31920, 321, 347, 350 kontrakty ........................................... 121, 322, 350 obiekt odniesienia .............................................315 Opis Produktu ................................... 296, 333, 347 planowanie jakoci........................................55, 57 Uzasadnienie Biznesowe ..............................10, 93 Zagadnienie Projektowe 26465, 315, 31920, 349 Zarzdzanie konfiguracj ..........................315, 321 zarzdzanie programem ........ 62, 70, 320, 321, 350 Zarzdzanie ryzykiem ...............................100, 320 zezwolenie na realizacj projektu ....................... 85 zgodno z PRINCE2 .......................................443 strony umowy....... 263, 301, Patrz te : interesariusze; podwykonawcy Struktura konfiguracji (Rys.) ..............................314 struktura opisu procesw......................................... 24 struktura organizacyjna .... 18, 22542, 438, Patrz te : zarzdzanie programem; Komitet Sterujcy; zesp zarzadzajcy projektem Dokument Inicjujcy Projekt .............................. 73 komunikacja i ......................................... 90, 227 warstwy.....................................................226, 258 warstwy (Rys.) ...............................................259 struktura organizacyjna zarzdzania jakoci ........300 struktura organizacyjna: .......................................... 34 struktura zarzdzania projektem......... Patrz: struktura organizacyjna studium wykonalnoci....................... 11, 30, 223, 367 sygna ... Patrz: sygna do zamykania projektu; sygna do podjcia pracy

4 80

PRINCE2
sygna do podjcia prac ..................110, 111, 126, 132 sygna do zamykania projektu............................... 126 symbole................................................................... 25 symbole stosowane w tekcie i diagramach............ 25 system jakoc i............. Patrz te : zarzadzanie jakoci system za rzdzania jakoci ................................. 371 szacowanie.................................193, 2025, 241, 247 szkolenia dla Komitetu Sterujcego ................................. 234 dotyczce PRINCE2............................................. 4 potrzeby u ytkownikw ..................................... 45 przegld oceniaj cy projekt .............................. 188 przewidywany cz as w ha rmonogramie na ... 210 zgaszanie Zagadnienia Projektowego.............. 254

SOWNIK ANGIELSKO POLSKI

ustalanie.................................................... 203, 258 Uzasadnienie Biznesowe .................................. 222 Zagadnienie Projektowe ....132, 133, 134, 135, 136 Zarzdzanie ryzykiem ...................................... 291 zarzdzanie strategiczne projektem .................... 80 zarzdzanie zakresem etapu........................ 15, 154 transformacja ........................................................ 199 tworzenie rezerw, reakcja na zagro enie............... 285

U
uaktualnienie Plan Projektu .................................65, 135, 15860 Rejestr Ryzyka ........62, 63, 162, 16364, 256, 291 Uzasadnienie Biznesowe ....158, 16163, 223, 240, Patrz te : Uzasadnienie Biznesowe, korekta udostpnianie kopii produktu................................ 312 udostpnianie produktu......................................... 311 ukad graficzny .............................. Patrz: pre zentacja ustalenie stanu odniesienia 66, 310, Patrz te kontrola wersji Dokument Inicjujcy Projekt...........87, 8687, 256 Ocena kocowa etapu....................................... 269 odbieranie Grupy Zada ................................... 138 Opis Produktu................................................... 333 Plan Projektu ............................................ 248, 257 pomiar korzyci ................................................ 224 Przegld jakoci................................................ 303 Sterowanie zmianami ....................................... 315 wydanie ............................................................ 309 Zao enia Projektu.............................................. 84 Ustpstwo ............................... Patrz te : Odstpstwo analiza wpywu................................................. 124 definicja .................................................... 350, 371 Komitet Sterujcy......102, 124, 125, 134, 136, 350 przegld stanu etapu ................................. 124, 125 tolerancja dla jakoci........................................ 261 Zagadnienie Projektowe ............132, 134, 137, 303 zamknicie projektu ......................................... 102 utrzymanie ................. Patrz: akceptacja, przez su by eksploatacji i utrzymania kontrakt serwisowy........................................... 180 Uzasadnienie Biznesowe ...........11, 21924, 372 , 377 analiza GAP...................................................... 222 analiza wpywu..................160, 162, 224, 320, 349 analiza zagro e ........................................... 64, 65 definicja ........................................................ 6, 372 deklaracja korzyci..........10, 63, 87, 162, 220, 222 DIP ..............................42, 62, 64, 74, 87, 223, 289 dostawca ..................................................... 66, 230 dziaania korygujce ......................................... 132 Dziaania Nastpcze ................................. 182, 224 formua realizacji.....................................45, 63, 65 Gwny Dostawca .................................... 233, 234 inicjowanie projektu ................14, 53, 63, 222, 223 Kierownik Projektu64, 87, 162, 222, 224, 254, 289 klient....................................................66, 221, 230 Komitet Sterujcy kontrola odchyle........................................... 10 przegld...................................18, 219, 223, 253 przekazanie do programu ....................... 64, 162 korekta.........................10, 42, 6266, 21924, 289 czas na ......................................................... 244 Zarzdzanie konfiguracj ............................. 257 zarzdzanie zakresem etapu......................... 153 koszt ........................................63, 65, 87, 221, 222 nadzr ..................................................64, 162, 240

cie ka krytyczna ......210, 371 , Patrz te : sie dziaa rodowisko klient dosta wca ......................... 22930 rodowisko klient dostawc a......................... 10, 225 Nadzr Projektu................................................ 241 okrelenie i analizowanie produktw ............... 198 rola Kierownika Projektu ................................. 236 zao enie w podrczniku PRINCE2 ........... 10, 253

T
techniki ............1921, 32361, Patrz te : Sterowanie zmianami; Planowanie oparte na produktach; Przegld jakoci terminy....................... Patrz te : harmonogramowanie planowanie projektu ..................................... 58, 59 Uzasadnienie Biz nesowe .................................. 221 Zagadnienie Projektowe ................................... 120 zarzdzanie zakresem etapu.............................. 277 tester ............................................ Patrz: tester jakoci tester jakoci ...303, 351, 353, 354, 35659, 360, 361, 371 Nadzr Projektu........................................ 240, 302 plan jakoci etapu lub zespou .......................... 302 tolerancja dla jakoci ............................................ 261 tolerancja dla korzyci .......................................... 261 tolerancja dla ryzyka ..................................... 260, 280 tolerancja dla zakresu.................................... 260, 262 tolerancje .........25862, 371 , Patrz te : tolerancja dla korzyci; toleranc ja dla jakoc i; tolerancja dla ryzyka; toleranc ja dla za kresu; przegld stanu etapu diagram koszt/czas (Rys.) .............................. 260 Dokument Inicjujcy Projekt........................ 75, 88 Elementy sterowania .................................... 67, 69 Grupa Zada..............................144, 147, 254, 258 inicjowanie projeku............................................ 83 Kierownik Projektu .............................254, 25862 Kierownik Zespou................................... 254, 258 Komitet Sterujcy........................203, 25862, 267 kompletowanie planu................................ 213, 215 Ocena kocowa etapu....................................... 269 Plan Etapu .............................................93, 95, 258 Plan Nadzwyczajny .....................93, 168, 169, 171 Plan Projektu .................................................... 248 planowanie etapu.............................................. 156 projektowanie planu ......................................... 195 przegld sta nu etapu ..................122, 124, 125, 291 Raport o Istotnych Odchyleniach ............. 259, 268 raportowanie koc a etapu................................. 166 szacowanie ....................................................... 203

481

PRINCE2
Nadzr Projektu..........................................49, 239 obowizki waciciela zagro enia .....................282 ocena ..................................................... 58, 92, 221 Ocena kocowa etapu ....................... 219, 253, 269 Plan Etapu....................................... 92, 93, 94, 163 Plan Nadzwyczajny....................... 92, 93, 161, 171 Plan Projektu wejcie do .................... 58, 87, 221, 223, 248 zwizek z ... .58, 6266, 158, 162, 163, 222, 289 planowanie etapu inicjowania .............................49 planowanie Etapu inicjowania ............................81 plany .................................................................244 przegld ......................................................16163 przegld oceniajcy projekt ...................... 185, 187 przegld poprojektowy........ 63, 182, 223, 224, 232 przegld stanu etapu.......................... 124, 125, 291 Przewodniczcy .................. 221, 22223, 232, przygotowanie projektu ..............................29, 220 Raport Kocowy Etapu..... 165, 166, 167, 223, 269 Raport Kocowy Projektu.................................272 Raport o Istotnych Odchyleniach........................93 Reje str Ryzyka .................................. 220, 221, 222 aktualizacja ................... 62, 63, 64, 65, 162, 164 Reje str Zagadnie .............................................162 sprawdzian zgodnoci z PRINCE2 ...................439 sterowanie etapem.............................................106 Sterowanie zmianami.................................... 10, 93 rodowisko klient/dostawca ...................... 229, 230 tole rancja dla ryzyka .........................................281 tole rancja korzyci............................................261 Wsparcie Projektu.......................................64, 162 Zagadnienie Projektowe ocena ............................................ 120, 121, 224 przekazywanie ........................ 64, 134, 135, 136 wpyw..................................... 98, 224, 320, 349 Zao enia Projektu..............................42, 223, 289 zamykanie projektu.............................80, 223, 271 Zarzdzanie konfiguracj.................. 222, 257, 314 zarzdzanie programem ................ 64, 93, 162, 222 Zarzdzanie ryzykiem .. 6266, 221, 222, 280, 287, 289, 293 zarzdzanie strategiczne................................ 79, 81 zarzdzanie zakresem etapu........................15, 153 zawarto ............................................21924, zezwolenie na realizacj projektu .. 85, 89, 90, 223, 253, 290 Zlecenie Przygotowania Projektu .......93, 220, 223 u ytkownik10, Patrz te : klient; Gwny U ytkownik analiza wpywu .................................................350 czonkostwo w Komitecie Sterujcym . 37, 85, 228, 229, 230, 234 czonkostwo w zespole zarzdzania projektem ...33 definicja ........................................................ 6, okrelenie i analizowanie produktw................197 Opis Produktu ................................... 262, 333, 345 przekazywanie Zagadnie Projektowych..........137 przygotowanie projektu do zamknicia.............180 przygotowanie Zao e Projektu.........................41 Uzasadnie nie Biznesowe ..................................221 zarzdzanie jakoci ................................. 263, 351

DODATKOWE INFORMACJE
struktura organizacyjna (Rys.) .......................259 warstwy struktury zarzdzania .....226, 258, Patrz te : zarzdzanie programem; Komitet Sterujcy; Kierownik Projektu; Kierownik Ze spou warstwy struktury zarzdzania (Rys.) ................259 warunki realizacji .......29, 41, 110, Patrz te : Kryteria Akceptacji; Zao enia Projektu; Zlecenie Przygotowania Proje ktu wersje kolejne, a Diagram Struktury Produktw...330 weryfikacja................. Patrz te : zarzdzanie jakoci wiele zmian sterowanie .........................................................315 wasno za gro enia .................. 9, 164, 282, 290, 293 Wniosek o Wprowadzenie Zmiany ..... 372 , 414 , Patrz te : Komisja ds. zmian; bud et zmian decyzje dorane .......................................... 98, 100 Komitet Steruj cy .....................................272, 349 sterowanie z mianami ................ 319, 322, 347, 349 Zagadnienie Projektowe........................ 1, 117, 134 Zalecenia Dziaa Nastpczych na podstawie ......................................................................272 wpyw oddziaywanie definicja ............................................................284 Wsparcie Projektu ..........24142, 372 , 430 , Patrz te : Bibliotekarz Konfiguracji; Zarzdzanie konfiguracj Dokument Inic jujcy Projekt .............................. 74 Dokumentacja Projektu....................................... 71 dziaania korygujce .........................................131 Elementy sterowania ........................................... 68 harmonogramowanie ........................................209 inicjowanie projektu ........................................... 83 Kierownik Projektu....................... 35, 39, 236, 241 Komitet Steruj cy ............................................... 83 kompletowanie planu ........................................214 mianowanie ......................................................... 38 ocena post pw.........................................115, 254 okrelenie dziaa i wspzale noci ................201 okrelenie Formuy Realizacji Projektu .............. 46 opracowanie Planu Nadzwyczajnego................170 planowanie eta pu ..............................................156 planowanie Etapu inicjowania ............................ 49 planowanie projektu............................................ 60 Przegld jakoci ........................................303, 355 przegld stanu etapu..........................................124 przygotowanie projektu do zamknicia.............178 Raport Okresowy ..............................................128 raportowanie koca etapu .................................166 szacowanie................................................203, 241 uaktualnianie Planu Projektu ............................159 uaktualnienie Rejestru Ryzyka..........................164 Uzasadnienie Biznesowe ............................ 64, 162 Zagadnienie Projektowe............................118, 120 Zao enia Projektu .............................................. 42 zespl za rzdzania projektem ............................. 36 zesp za rzdzania projektem ................. 34, 35, 39 wydanie .................................................................309 wykonywanie Grupy Zada ... 113, 14649, 240, 254, 264, 352 wykres Gantta 192, 207, 214, 215, 302, 323, 326, 372 wykres Gantta (Rys.)..........................................209 wymagania ............................................................ 372 wymagania dotyczce zasobw doprecyzowanie Uzasadnienia Biznesowego 62, 65 Elementy sterowania .....................................68, 69 harmonogramowanie ........................................210 oszacowanie ......................................................247

369

377

372

W
warstwy struktura organizacyjna............226, 258, zarzdzanie programem. Komitet Sterujcy, Kierownik Projektu, Kierownicy Zespow Patrz te :

4 82

PRINCE2
Plan Projektu ...................................58, 65, 68, 248 planowanie projektu ..................................... 58, 59 raporty o .............................................. 214, 245 Zarzdzanie ryzykiem ...................................... 287 wynik/ rez ultat ...................................................... 372 wyszukiwanie informacji ............. Patrz: archiwizacja, dokumentacja projektu, re jestry wytwrca .........................353, 35758, 359, 360, 361

SOWNIK ANGIELSKO POLSKI

przegld stanu etapu......................122, 124, 134 Raport o Istotnych Odchyleniach ...95, 134, 135, 137, 170, 292, 350 sterowanie etapem........................................ 107 Sterowanie zmianami ................................... 350 Uzasadnienie Biznesowe.........64, 134, 135, 136 Zarzdzanie ryzykiem ...................135, 136, 292 przygotowanie projektu do zamknicia ............ 134 Raport Kocowy Projektu................................ 272 Raport Okresowy.............................................. 137 raportowanie koca etapu......................... 166, 167 Rejestr Ryzyka ..........120, 121, 135, 164, 319, 320 sterowanie etapem ...............................16, 107, 108 szkolenie w sprawie zgaszania ........................ 254 terminy ............................................................. 120 tolerancje ...........................132, 133, 134, 135, 136 uprawnienia do wprowadzeniu zmian ...... 120, 319 Ustpstwo..........................132, 134, 136, 137, 303 Uzasadnienie Biznesowe ..120, 121, 134, 135, 136, 224 doprecyzowanie ............................................. 64 wpyw ...........................................224, 320, 349 u ytkownik....................................................... 137 Wsparcie Projektu .................................... 118, 120 wychwytywanie...........................107, 11618, 318 wychwytywanie (Rys.) .................................. 348 zamknicie projektu ..........102, 103, 175, 176, 179 Zapis Obiektu Konfiguracji...................... 134, 136 zarzdzanie jakoci ..........120, 303, 358, 359, 361 Zarzdzanie konfiguracj ..........308, 313, 315, 321 zarzdzanie programem.........64, 98, 118, 119, 183 Zarzdzanie ryzykiem120, 135, 137, 282, 292, 319 Zlecenie Przygotowania Projektu ..................... 183 zagro enia wewntrzne ......................................... 293 zagro enia zewntrzne .......................................... 293 zagro enie, wybr reakcji - (Rys.) ....................... 286 zakres etapu ........ Patrz te : punkty kontrolne; punkty decyzyjne; Raport Kocowy Etapu; etapy defniowanie .................................................. 59, 81 Diagram Nastpstwa Produktw ...................... 335 Dokument Inicjujcy Projekt...................... 72, 155 Dziennik ........................................................... 155 Elementy sterowania .......................................... 67 Kierownik Projektu ...............................15, 81, 155 Kierownik Zespou........................................... 249 Komitet Sterujcy......1516, 81, 95, 153, 154, 155 modyfikacja...................................................... 266 Plan Etapu ...........................................15, 153, 154 Plan Jakoci Projektu........................................ 155 Plan Nadzwyczajny .................................... 15, 153 Plan Projektu .................................15, 81, 153, 155 Plan Zespou ............................................... 16, 249 produkty i .................................................... 276 przegld oceniajcy projekt................................ 80 przegld stanu etapu ................................. 126, 153 Raport Kocowy Etapu ...................................... 15 Rejestr Dowiadcze .......................................... 15 Rejestr Ryzyka ................................................... 15 ryzyko............................................................... 153 terminy realizacji .............................................. 277 tolerancje .................................................... 15, 154 Uzasadnienie Biznesowe ............................ 15, 153 zarzdzanie ........1516, 72, 126, 15371, 248, 277 zarzdzanie strategiczne ..................................... 81 zesp zarzdzania projektem ............................. 15 zakres obowizkw Dokument Inicjujcy Projekt...................73, 74, 75

Z
Zagadnienie Projektowe. 31722, 373 , 407 , Patrz te : Sterowanie zmianami; Rejestr Zagadnie; Odstpstwo; Wniosek o Wprowadzenie Zmiany analizowanie............................................... 11922 Komitet Steruj cy ................................ 120, 349 Nadzr Projektu ................................... 120, 239 przekazywanie...................................... 133, 134 Raport o Istotnych Odc hyleniach................. 268 sterowanie etapem ........................................ 107 Uzasadnienie Biznesowe ...............120, 121, 224 Zarzdzanie ryzykiem ...................120, 291, 319 analizowanie wpywu.11922, 134, 137, 224, 320, 349, 350 Bibliotekarz Konfiguracji ..118, 120, 135, 313, 315 bud et zmian ............................................ 121, 124 decyzje dorane .............................9799, 100, 134 Dokument Inicjujcy Projekt.................... 121, 135 dziaania korygujce ................................. 130, 131 Dziaania Nastpcze ..................102, 103, 181, 183 Elementy sterowania .......................................... 67 Grupa Zada..................................................... 147 inicjowanie projektu ................................. 120, 319 interes klienta ................................................... 121 Kierownik Projektu .................................. 282, 321 ocena wpywu .............................................. 120 przekazywanie....9799, 13236, 254, 265, 292, 349 wychwytywanie ........................................... 118 Komitet Sterujcy analizowanie ......120, 349, Patrz te : Ustpstwo przekazywanie.........122, 124, 13235, 135, 137 szybko reakcji ........................................... 100 uprawnienia do wprowadzania zmian .. 319, 349 wychwytywanie ........................................... 117 zamykanie projektu ...................................... 102 kontrakty .......................................................... 121 korzyci .................................................... 120, 320 korzyci projektu i ....................................... 120 koszt ................................................................. 120 mianowanie zespou zarzdzania proje ktem ....... 39 Nadzr Projektu.................................120, 135, 239 obowizek Przewodniczcego.......................... 232 ocena postpw ................................................ 119 Opis Produktu................................................... 303 Plan Etapu ................................................ 121, 349 Plan Nadzwyczajny .....................95, 132, 134, 136 Plan Projektu .............118, 121, 124, 134, 248, 349 Plan Zespou..................................................... 349 priorytet.................................................... 120, 348 przedwczesne zamknicie projektu ...132, 134, 136 przegld sta nu etapu ..120, 121, 124, 125, 126, 291 przekazywanie ............................................ 13237 Kierownik Projektu .................13235, 292, 349 Komitet Steruj cy ...122, 124, 13235, 136, 137 Nadzr Projektu ................................... 135, 239 Odstpstwo........................................... 137, 350

483

PRINCE2
Elementy sterowania..................................... 68, 69 Gwny Dostawca...............................................90 inicjowanie..........................................................84 Kierownik Projektu....................................... 32, 36 Komitet Sterujcy ......................................... 35, 99 Nadzr Projektu....................................................9 Opis Produktu .......................................................9 planowanie etapu ..............................................156 planowanie jakoci..............................................57 Przewodniczacy ............................................ 32, 36 Sterowanie zmianami........................ 314, 319, 350 waciciel ryzyka ..................................................9 Zarzdzanie konfiguracj..................................313 zesp zarzdzania projektem .. 36, 39, 57, 75, 156, 227, 314 zakupy zaopatrzeniowe .............................................9 Zalecenia Dziaa Nastpczych............. 272, 373 , 388 dziaania nastpcze okrelenie .....................................................292 Dziaania Nastpcze okrelenie ............................................. 181, 183 Kierownik Projektu...........................................176 Komitet Sterujcy ....................... 82, 102, 181, 272 przegld oceniajcy projekt ..............................188 Zagadnienie Projektowe.................... 102, 103, 183 zamykanie projektu............. 17, 102, 103, 175, 176 zarzdzanie programem ....................................102 Zarzdzanie ryzykiem ............................... 272, 292 zale noci................................................................11 analiza zagro e................................................212 Diagram Nastpstwa Produktw 201, 326, 33536, 346 harmonogramowanie ................................ 206, 209 identyfikacja ............................................. 198202 kompletowanie planu ........................................213 ograniczenia jako .........................................201 okrelenie Formuy Realizacji Projektu..............45 planowanie ........................................................245 planowanie etapu ..158, Patrz te : wspzale noci produkty zewntrzne.........................................331 zale noci wzajemne ..................... 158, 284, 292, 294 Zao enia Projektu ....... 43, 46, 373 , 402 3, Patrz te : Kryteria Akceptacji analiza wpywu ...................................................40 Dokument Inicjujcy Proje kt ............ 43, 48, 74, 87 Dziennik........................................................ 42, 43 Gwny U ytkownik...........................................41 inic jowanie projektu ................. 43, 53, 83, 84, 255 inte resariusze ..............................................41, 255 Kierownik Projektu.....................................42, 255 Komitet Sterujcy ........... 40, 41, 42, 43, 83, 84, 87 Kryteria Akceptacji.............................................41 Nadzr Projektu..........................................42, 239 obiekt odniesienia ...............................................84 okrelenie Formuy Realizacji Projektu i 44, 45, 46 Plan Etapu inicjowania ................................. 48, 49 planowanie projektu...................................... 60, 61 projektowa nie planu..........................................194 przygotowanie inicjowanie projektu.......................................53 Nadzr Projektu......................................42, 239 planowanie Etapu inicjowania ........................47 Rejestr Ryzyka ............................. 40, 42, 43, 62 cie ka jakoci..............................................298 Uzasadnienie Biznesowe .......... 41, 42, 223, 289 Zarzdzanie ryzykiem ..................................289

DODATKOWE INFORMACJE
przygotowanie proje ktu .................... 13, 28, 29, 30 przygotowanie Zao e Projektu........... 4044, 255 Rejestr Ryzyka.................................... 1, 40, 42, 62 tolerancje ..........................................................258 Wsparcie Projektu............................................... 42 wymagania formalne ........................................... 41 wymagania u ytkownika .................................... 42 zarzdzanie jakoci ....................... 41, 56, 57, 298 zarzdzanie programem .................. 29, 40, 84, 255 Zarzdzanie ryzykiem .......................................289 zatwierdzenie Zao e Projektu.................. 83, 255 zawarto Zao e Projektu .................... 41, 402 3 zesp za rzdzania projektem .......................35, 40 Zlecenie Przygotowania Projektu ........... 40, 41, 43 zamknicie projektu .............. 17, 1014, 176, 17388 Dokument Inic jujcy Projekt ...... 17, 103, 175, 253 Kierownik Projektu17, 93, 101, 103, 175, 253, 271 Komitet Steruj cy ..... 14, 80, 93, 188, 253, 27173 zatwierdzenie ...................................... 82, 1014 kontrolowane zamknicie ........................... 27173 obowizek Prz ewodniczcego ..........................232 powiadomienie o .......... 103, 104, 179, 271, 368 przegld stanu etapu..........................................126 Uzasadnienie Biznesowe ..........................223, 271 zalecenie ...........179, 373 , Patrz te : przedwczesne zamknicie projektu zarzdzanie strategiczne projektem......... 14, 78, 82 zatwierdzenie ..82, 1014, 177, 179, 183, 185, 253, 273 zmiana definicji projektu .................................... 87 zamykanie projektu ......... Patrz: zamknicie projektu Zapis Obiektu Konfiguracji................................... 380 dziaania korygujce .........................................131 Grupa Zada ............................. 110, 111, 138, 139 ocena post pw.................................................115 okrelenie i analizowanie produktw 196, 197, 311 opracowanie Planu Nadzwyczajnego................170 przegld oceniajcy projekt ..............................187 przegld stanu etapu..................................123, 125 przekazywanie Zagadnie Projektowych..134, 136 przygotowanie projektu do zamknicia.....178, 179 raportowanie koca etapu .........................166, 167 utworzenie ........................................ 196, 197, 311 Uzasadnienie Biznesowe, zmiana .....................257 zmiana Planu Projektu ......................................257 zapobieganie (prewencja), reakcja na zagro enie ..285 zarzd firmy .......................... Patrz: zarzd programu zarzdzanie.............. Patrz: Zarzdzanie konfiguracj; struktura organizacyjna; zarzdzanie wytwarzaniem produktw; zarzdzanie programem; za rzdzanie projektem; zarzdzanie jakoci; za kres etapu, zarzdzanie; Zarzdzanie ryzykiem zarzdzanie dokumentacj projektu................. 44547 zarzdzanie jakoci ...............29596, 300, Patrz te : Oczekiwania jakociowe klienta; Plan Jakoci Projektu; nadzr jakoci; kontrola jakoci; planowanie jakoci dostawca ............................................. 55, 300, 304 Dziennik............................................................304 Formua Realizacji Projektu i ..... 46, 54, 57, 301 Grupa Zada ..................... 110, 112, 145, 147, 148 ISO....................................................................299 Kierownik Projektu..................... 17, 235, 302, 304 Kierownik Zespou ...................................301, 304 klient ..................................... 10, 55, 196, 299, 300 Kryteria Akce ptacji................. 54, 55, 57, 298, 299

4 84

PRINCE2
Nadzr Projektu.................................240, 241, 301 ocena postpw ........................................ 304, 352 Odstpstwo ............................................... 261, 303 okrelenie dziaa i wsplzale noci ................ 203 Opis Produktu................................................... 262 Plan Zespou............................................. 148, 302 planowanie etapu...............................156, 157, 158 przegld oceniajcy projekt .............................. 188 przegld sta nu etapu ......................................... 124 Raport Kocowy Etapu .....................166, 167, 168 Zagadnienie Projektowe ................................... 303 zarzdzanie programem .............................. 56, 300 zesp zarz dzajcy projektem ............... 36, 37, 57 Zarzdzanie konfiguracj ... 10, 19, 30715, Patrz te : archiwizacja;zarzdzanie wytwarzaniem produktw;dokumentacja projektu;Akta Projektu definicja...................................................... 19, 373 Grupa Zada..............................138, 145, 149, 150 ocena postpw ................................................ 114 Przegld jakoci................................................ 303 przygotowanie projektu do z amknicia ............ 180 Rejestr Ryzyka ................................................. 257 Sterowanie zmianami i ........................ 315, 321 Uzasadnienie Biznesowe .......................... 222, 314 Zagadnienie Projektowe ............308, 313, 315, 321 Zestawienie Statusu Produktw........................ 114 zgodno z PRINCE2................................. 44344 zarzdzanie odchyleniami .......14, 78, 79, 80, 81, 231, Patrz te : Plan Nadzwyczajny; Raport o Istotnych Odchyleniach definicja.................................................. 4, 19, 252 Raport Okresowy.............................................. 267 zarzdzanie programem .......................................... 23 decyzje dorane .................................................. 98 Dokument Inicjujcy Projekt.............53, 74, 75, 85 Dokumentacja Projektu ...................................... 71 Dziaania Nastpcze ................................. 103, 183 Elementy sterowania .................................... 68, 69 Formua Realizacji Projektu ......................... 29, 30 inicjowanie projektu ....................48, 53, 54, 84, 85 Komitet Sterujcy czonkostwo ..................32, 33, 36, 69, 100, 235 mianowanie .............29, 34, 37, 39, 81, 231, 235 przepyw informacji ................................. 78, 82 mianowanie Kierownika Projektu ................ 3133 mianowanie Przewodniczcego.................... 3133 Ocena kocowa etapu....................................... 294 ocena ryzyka............................................. 281, 284 opracowanie planu.................................... 192, 195 Plan Etapu ...........................................95, 158, 168 Plan Komunikacji ............................78, 88, 99, 100 Plan Nadzwyczajny .............................93, 171, 250 Plan Projektu .................................61, 88, 168, 250 planowanie ....................................................... 192 planowanie Etapu inicjowania ............................ 48 przegld oceniaj cy projekt .............................. 188 przegld stanu etapu ......................................... 126 przygotowanie projektu................................ 29, 30 Raport Kocowy Etapu ............................ 168, 269 Raport Kocowy Projektu ................................ 272 Raport o Dowiadczeniach............................... 188 Raport o Istotnych Odchyleniach ..................... 268 Rejestr Ryzyka ............................................. 64, 66 Sterowanie zmianami .....62, 69, 70, 320, 321, 347, 350 struktura organizacyjna .................................... 226 tolerancje .................................................. 258, 259

SOWNIK ANGIELSKO POLSKI

Uzasadnienie Biznesowe .........63, 64, 93, 162, 222 Zagadnienie Projektowe ........64, 98, 118, 119, 183 zale noci....................................................... 912 Zao enia Projektu...........................29, 40, 84, 255 zamknicie projektu ................................. 103, 104 zarzdzanie jakoci ..............................55, 56, 300 Zarzdzanie konfiguracj ................................. 310 Zarzdzanie ryzykiem ....62, 64, 66, 126, 280, 281, 294 zarzdzanie strategiczne projektem .............. 78, 79 zesp zarzdzania projektem ............36, 37, 39, 81 zezwoleniena realizacj projektu........................ 85 Zlecenie Przygotowania Projektu ........28, 183, 258 zarzdzanie projektem .. 1, 2, 373 , Patrz te : poz iomy zarzdzania; PRINCE2; zarzdzanie strategiczne projektem Zarzdzanie ryzykiem........ 11, 19, 27994, Patrz te : bud et rezerwowy; Rejestr Ryzyka Formua Realizacji Projektu............................... 46 Grupa Zada ................110, 146, 147, 287, 28992 inicjowanie projektu ..............................84, 85, 289 Kierownik Projektu .........64, 65, 100, 282, 28992 klient................................................................... 66 Komitet Sterujcy............64, 66, 79, 280, 291, 292 kompletowanie planu ............................... 213, 215 Nadzr Projektu...................49, 211, 239, 240, 292 okrelenie i analizowanie produktw ............... 197 Plan Etapu ...................................248, 287, 28992 Plan Nadzwyczajny ...........................171, 270, 291 Plan Projektu .................61, 64, 247, 248, 287, 291 planowanie ............................................... 245, 287 produkt zewntrzny .......................................... 332 przegld oceniajcy projekt...................... 185, 188 przegld stanu etapu ..........................124, 126, 291 Raport Kocowy Etapu .............165, 166, 168, 269 Raport Kocowy Projektu................................ 272 Raport o Istotnych Odchyleniach ........93, 288, 292 rwnowa enie......................................28586, 320 sterowanie etapem .............................................. 16 Sterowanie zmianami ............................... 100, 320 strategiczne zarzdzanie projektem .................... 79 Uzasadnienie Biznesowe ......6266, 221, 222, 280, 287, 289, 291 Zagadnienie Projektowe ...120, 135, 137, 282, 292, 319 Zalecenia Dziaa Nastpczych................ 272, 292 zarzdzanie programem..62, 64, 66, 126, 280, 281, 294 zarzdzanie zakresem etapu.............................. 155 zezwolenie na realizacj projektu ........89, 253, 291 zarzdzanie strategiczne projektem.....14, 23, 77104, 230, 236, 239, Patrz te : decyzje dorane zarzdzanie wytwarzaniem produktw .....16, 14151, Patrz te : Zarzdzanie konfiguracj; Grupa Zada; wykonywanie Grupa Zada ..................................16, 110, 14151 Kierownik Projektu .....................16, 141, 144, 235 Kierownik Zespou................16, 23, 141, 142, 236 Przegld jakoci................................................ 352 sterowanie etapem .....................106, 109, 141, 143 wytwrca .......................................................... 141 Zagadnienie Projektowe ............................. 17, 119 zatwierdzenie decyzji Kierownika Projektu .............................. 81 Dokumentu Inicjujcego Projekt................ 86, 256 funduszy dla projektu ......................................... 77 nominacji Komitetu Sterujcego ........................ 88

485

PRINCE2
nominacji zespou zarzdzania projektem...........35 obowiazki Komitetu Sterujcego ................ 421 22 Opisu Produktu ......................................... 262, 296 planu ......................................... 215, 244, 245, 291 Planu Etapu............................................... 106, 269 Planu Etapu (nastpnego) ............................. 73, 81 Planu Etapu inicjowania .....................................28 Planu Nadzwyczajnego.......................93, 250, 269 Planu pierwszego Etapu realizacji ......................86 Planu Projektu...................................................248 Planu Zespou ...................................................249 podziau projektu na etapy ..................................81 produktw Grup Za da.....................................113 produktu............................................ 311, 347, 351 projektu planu ...................................................194 Raportu Kocowego Projektu................... 185, 273 Raportu o Dowiadczeniach..............................272 Raportu o Istotnych Odchyleniach....................134 rezultatw projektu .............................................14 tolerancji .............................................................88 Uzasadnienia Biznesowego....................... 220, 222 wpisw w Rejestrze Jakoci..............................110 wykonania Grupy Zada...................................139 wykonanych produktw......................17, 143, 144 zakoczenia bie cego etapu ..............................15 Zalecenia zamknicia projektu..........................178 Zao e Projektu .....................................43, 83, 84 zamknicie projektu..... 1014, 177, 179, 183, 185, 253 zespou zarzdzajcego projektem ..........81, 83, 88 zmiany ........................................................98, 319 zmknicia projektu..............................................78 zrealizowania etapu...........................................268 zesp zarzdzania projektem ... 23042, 373 , 421 32 , Patrz te : Przewodniczcy; Nadzr Projektu; Komitet Sterujcy; Kie rownik Projektu; Wsparcie Projektu; Kierownik Zespou czonkostwo .................................................. 10, 33 Dokument Inicjujcy Projekt ............ 48, 73, 75, 88 dostawca .................................................34, 36, 37 drogi raportowania i komunikacji .......................39 dziaania zwizane z kontraktem ..........................9 dziaania zwizane z zakupami .............................9 Formua Realizacji Projektu.......................... 35, 37 funkcje audytu wewntrznego ............................36 Gwny Dostawca...............................................37 interesariusze ......................................................36 klient ............................................................. 36, 37 komunikacja ........................................................39 mianowanie........................... 13, 29, 30, 34, 3840 potwierdzenie .................................................81 Nadzr Projektu............................ 36, 38, 228, 238 Plan Nadzwyczajny...........................................171 planowanie etapu ...................................... 156, 157 planowanie projektu............................................60

DODATKOWE INFORMACJE
projektowanie ........... 13, 29, 23042, 39, 237, 238 Przewodniczcy ............................................35, 39 przygotowanie projektu ...................................... 13 struktura .................................. 36, 39, 171, 22628 Dokument Inicjujcy Projekt.............. 73, 74, 75 inicjowanie projektu ....................................... 84 planowanie etapu..................................156, 157 struktura organizacyjna .....................................226 u ytkownik ......................................................... 34 Wsparcie Projektu....................... 34, 35, 36, 38, 39 Zagadnienie Projektowe...................................... 40 zakres obowizkw... 36, 39, 57, 75, 156, 227, 314 Zao enia Projektu ........................................35, 40 zarzdzanie jakoci ............................... 36, 37, 57 zarzdzanie programem .................... 36, 37, 39, 81 zarzdzanie zakresem etapu ................................ 15 zatwierdzenie Planu Etapu.................................. 94 Zlecenie Przygotowania Projektu ....................... 36 zmiany skadu ....................................... 15, 94, 154 Zestawienie Statusu Produktw ............ 312, 373 , 400 ocena post pw.........................................114, 115 opracowanie Raportu o Istotnych Odchyleniach ......................................................................170 przygotowanie projektu do zamknicia.....178, 179 Zarzdzanie konfiguracj ..................................114 zezwolenie na realizacj projektu........ 14, 8591, 253 Dokument Inic jujcy Projekt ............ 72, 73, 8591 Plan Projektu....................................................... 89 Rejestr Ryzyka..................................................290 Uzasadnienie Biznesowe 85, 89, 90, 223, 253, 290 Zarzdzanie ryzykiem ......................... 89, 253, 290 zgodno z PRINCE2...................................... 43744 Zlecenie Przygotowania Projektu......... 408 , Patrz te : Uzasadnienie Biznesowe Bzasadnienie Biznesowe...................................222 Formua Realizacji Projektu..........................30, 45 Kierownik Projektu............................... 31, 32, 255 Komitet Steruj cy i ......................................231 mianowanie Przewodniczcego ....................32, 33 okrelenie .............................................. 28, 29, 373 Plan Projektu....................................................... 32 planowanie jakoci.............................................. 56 projektowanie zespou zarzdzania projektem .... 36 przygotowanie projektu ............ 13, 28, 29, 30, 255 przygotowanie Zao e Projektu............. 40, 41, 42 studium wykonalnoci ................................ 30, 223 tolerancje ..........................................................258 Uzasadnienie Biznesowe ..................................223 Zagadnienie Projektowe....................................183 zarzdzanie programem ...................... 28, 183, 258 Zarzdzanie ryzykiem .......................................289 zmiany planu ........... Patrz te : Sterowanie zmianami; dziaania korygujce; Raport o Istotnych Odchyleniach; Zagadnienie Projektowe; tolerancje

4 86