Spis treści

Spis rysunków
.
VI 4 Uzasadnienie Biznesowe 21

Spis tabel VIII

4.1 Przeznaczenie 21
4.2 Definicja Uzasadnienia
Przedmowa X Biznesowego 21
4.3 PodejściePRINCE2 do
Podziękowania XI
Uzasadnienia Biznesowego 22
Konwencja zapisu przyjęta 4.4 Obowiązki 28
w niniejszym podręczniku XIII
5 Organizacja 33
1 Wprowadzenie 3 5.1 Przeznaczenie 33
1. 1 Cel niniejszego podręczn i ka 3 5.2 Definicja organizacji 33
1.2 Znaczenie projektów 3 5.3 Podejście PRINCE2 do organizacji 35
1.3 Co wyróżnia projekty? 3 5.4 Obowiązki 46
1.4 Dlaczego potrzebna jest metodyka
zarządzania projektem?
6 Jakość 49
4
1.5 Wprowadzenie do PRINCE2 4 6.1 Przeznaczenie 49
1.6 Powiązane publikacje OGC 6 6.2 Definicja jakości 49
1.7 Korzyści z PRINCE2 7 6.3 Podejście PRINCE2 do jakości 51
6.4 Obowiązki 60
2 Pryncypia (zasady) 11
2.1 Ciągla zasadność biznesowa 11 7 Plany 65
2.2 Korzystanie z doświadczeń 12 7.1 Przeznaczenie 65
2.3 Zdefiniowane role i obowiązki 12 7.2 Definicja planów 65
2.4 Zarządzanie etapowe 13 7.3 Podejście PRINCE2 do planów 67
2.5 Zarządzanie z wykorzystaniem 7.4 Obowiązki 77
tolerancji 13
8 Ryzyko 81
2.6 Koncentracja na produktach 14
8.1 Przeznaczenie 81
2.7 Dostosowanie do warunków
projektu 14 8.2 Definicja ryzyka 81
8.3 Podejście PRINCE2 do ryzyka 82
3 Wprowadzenie do tematów
PRINCE2 17 8.4 Obowiązki 92

3.1 Czym są tematy? 17 9 Zmiana 97

3.2 Zastosowanie tematów 18 9.1 Przeznaczenie 97
3.3 Format tematów 18 9.2 Definicja zmiany 97
9.3 Podejście PRINCE2 do zmiany 98
9.4 Obowiązki 103
.
IV I Spis Treści

10 Postępy 107 16.3 Kontekst 195

10.1 Przeznaczenie 107 16.4 Dzialania 196

10.2 Definicja postępów 107 17 Zarządzanie Końcem Etapu 203

10.3 Podejście PRINCE2 do postępów 108 Przeznaczenie 203
17 .1
10.4 Obowiązki 116 17 .2 Cel 204

11 Wprowadzenie do procesów 121 17 .3 Kontekst 204

11 .1 Procesy PRINCE2 121 17.4 Działania 204

11.2 Ogólny przegląd procesów 18 Zamykanie Projektu 217

PRINCE2 121
18.1 Przeznaczenie 217
11.3 Model procesowy PRINCE2 124
18.2 Cel 217
11.4 Struktura rozdzia łów dotyczących
procesów 124 18.3 Kontekst 217
18.4 Działan i a 218
12 Przygotowanie Projektu 129
12.1 Przeznaczen ie 129 19 Dostosowanie metodyki PRINCE2
do warunków projektu 229
12.2 Cel 129
19.1 Na czym polega dostosowanie
12.3 Kontekst 130 metodyki? 229
12.4 Działania 130
19.2 Ogólne podejście do
dostosowania metodyki 229
13 Zarządzanie Strategiczne
Projektem 143 19.3 Przykłady dostosowania PRINCE2 231

13.1 Przeznaczenie 143 19.4 Projekty realizowan e w ramach

programu 231
13.2 Cel 143
19.5 Skala projektu 235
13.3 Kontekst 143
19.6 Środowisko komercyjne
13.4 Działania 144 klient/dostawca 239

14 Inicjowanie Projektu 157 19.7 Projekty obejmujące wiele

. ..
organ1zaq1 242
14.1 Przeznaczenie 157
19.8 Typ projektu 242
14.2 Cel 157
19.9 Różnice sektorowe 244
14.3 Kontekst 158
19.1 O Kompendia W iedzy
14.4 Dz i a łania 158 o zarządzaniu projektami 245

15 Sterowanie Etapem 177 Dodatek A: Zarysy Opisów Produktów 249

15.1 Przeznaczenie 177 A.1 Plan Przeglądu Ko rzyśc i 250
15.2 Cel 177 A.2 Uzasadnienie Biznesowe 251
15.3 Kontekst 178 A.3 Raport z Punktu Kontrolnego 253
15.4 Działania 178 A.4 Strategia Zarządzania
Komunikacją 253
16 Zarządzanie Dostarczaniem
Produktów 195 A.5 Zapisy Obiektu Konfiguracji 254
A.6 Strategia Zarządzania
16.1 Przeznaczenie 195
Konfiguracją 256
16.2 Ceł 195
A.7 Dziennik Projektu 257
 Spis Treści I V

A.8 Raport Końcowy Projektu 257 D.3 Przykłady struktury podz i ału
produktów 299
A.9 Raport Końcowy Etapu 258
D.4 Przykład Opisu Produktu 300
A.10 Raport Nadzwyczajny 260
D.5 Diagram następstwa produktów 301
A.11 Raport Okresowy 260
A.12 Rejestr Zagadnień 261 Dodatek E: listy kontrolne zgodności
projektu z PRINCE2 305
A.13 Raport o Zagadnieniu 262
A.14 Dziennik Doświadczeń 263 E.1 Przygotowanie Projektu 305
E.2 Zarządzanie Strategiczne
A.15 Raport Doświadczeń 264
Projektem 306
A.16 Plan 265
E.3 Inicjowanie Projektu 309
A.17 Opis Produktu 267
E.4 Sterowanie Etapem 309
A.18 Zestawienie Statusu Produktów 268
E.5 Zarządzan ie Dostarczaniem
A.19 Założe n ia Projektu 269 Produktów 31 0
A.20 Dokumentacja In icjowania E.6 Za rządzan i e Końcem Etapu 310
Projektu 270
E.7 Zamykani e Projektu 31 1
A.21 Opis Produktu Końcowego
Projektu 271 Dodatek F: Terminologia 315
A.22 Strategia Zarządza n ia Jakośc i ą 273 F.1 Zasady 315
A.23 Rejestr Jakości 274 F.2 Tematy 315
A.24 Strategia Zarządzania Ryzykiem 275 F.3 Procesy i dzia łania 315
A.25 Rejest r Ryzyk 276 F.4 Produktu zarząd cze PRINCE2 317
A.26 Grupa Zadań 277 F.5 Role 317

Dodatek B: Ład zarządzania F.6 Słownik angielsko-polski 318

projektami 283 F.7 Słownik polsko-angielski 321

Dodatek C: Role i obowiązki 287 Dalsze informacje 329

C.1 Komitet Sterujący 287 Wydawnictwa Office of Government
Commerce 329
C.2 Przewodniczący 288
Główny Użytkownik 288 Wydawnictwa The Stationery Office
C.3
(publikacje uzupe ł niające) 330
C.4 Główny Dostawca 289
Inne źródła 331
C.5 Kierownik Proj ektu 290
leksykon 335
C.6 Kierownik Zespołu 291
C.7 Nadzór Projektu 29 1 Indeks 353
C.8 Obsługa Zmian 293
C.9 Wsparcie Projektu 293

Dodatek D: Przykład planowania

opartego na produktach 297
D.1 Scenariusz 297
D.2 Przykład
Opisu Produktu
Końcowego Projektu 298
Spis rysunków

Rysunek 1.1 Zarządzanie projektem Rysunek 10.3 Prace specjalistyczne wykraczaj ące
poza końce etapów zarządczych
Rysunek 1.3 Publikacje OGC dotyczące najlepszych
praktyk Rysunek 10.4 Prace specjalistyczne dopasowane do
etapów zarządczych
Rysunek 4.1 Powiązanie pomiędzy wynikami,
rezultatami i korzyściami Rysunek 11.1 Procesy PRINCE2
Rysunek 4.2 Ścieżka opracowywania Uzasadnienia Rysunek 11.2 Model procesowy PRINCE2
Biznesowego
Rysunek 11.3 Relacje pomiędzy procesami,
Rysunek 5.1 Trzy strony interesów w projekcie dzialaniami i czynnościami
Rysunek 5.2 Cztery poziomy zarządzania Rysunek 12.1 Diagram procesu Przygotowanie
projektem Projektu
Rysunek 5.3 Struktura zespolu zarządzania Rysunek 12.2 M ianowanie Przewodn iczącego
projektem i Kierownika Projektu - schemat
dzialania
Rysunek 5.4 Możliwa struktura powiązań
z wykorzystaniem grup Rysunek 12.3 Zgromadzenie dotychczasowych
użytkowników i dostawców doświadczeń - schemat dzialania

Rysunek 5.5 Wiele aspektów roli Kierownika Rysunek 12.4 Projektowanie zespolu zarządzania
Projektu projektem i mianowanie jego
czlonków - schemat działania
Rysunek 6.1 Ścieżka audytu jakości
Rysunek 12.5 Przygotowanie zarysu Uzasadnienia
Rysunek 7.1 Poziomy planowania PRINCE2
Biznesowego - schemat dzialania
Rysunek 7.2 Podejście PRłNCE2 do planów
Rysunek 12.6 Wybieranie formu ly rea lizacji
Rysunek 7.3 Technika planowania opartego na projektu i zestawianie Założeń
produktach Projektu - schemat dzi ałan ia
Rysunek 7.4 Uproszczony diagram z działaniami Rysunek 12.7 Planowanie etapu inicjowania
w węzłach - schemat działania
Rysunek 8.1 Perspektywy organizacyjne Rysunek 13.1 Diagram procesu Zarządzanie
Rysunek 8.2 Procedura zarządzania ryzykiem Strategiczne Projektem

Rysunek 8.3 Przykład diagramu struktury podziału Rysunek 13.2 Zezwalanie na zainicjowanie
ryzyka projektu - schemat działania

Rysunek 8.4 Przyczyna, zdarzenie i skutek ryzyka Rysunek 13.3 Zezwalanie na realizację projektu
- schemat działania
Rysunek 8.5 Macierz prawdopodobieństwo/wplyw
Rysunek 13.4 Zezwalanie na realizację Planu Etapu
Rysunek 8.6 Sumaryczny profil ryzyka lub Planu Nadzwyczajnego - schemat
Rysunek 8.7 Reakcje na zagrożenia i szanse działan i a

Rysunek 9.1 Procedura sterowania zagadnieniami Rysunek 13.5 Podejmowanie decyzji doraźnej
i zmianami - schemat działania
Rysunek 9.2 Analiza możliwych rozwiązań Rysunek 13.6 Zezwalanie na zamknięcie projektu
- schemat działania
Rysunek 10.1 Delegowanie tolerancji
oraz raportowanie faktycznych Rysunek 14.1 Diagram procesu Inicjowanie
i prognozowanych postępów Projektu

Rysunek 10.2 Prace specjalistyczne przypisane Rysunek 14.2 Opracowanie Strategii Zarządzania
etapom technicznym Ryzykiem - schemat działania
 ••
Spis Rysunków I VII

Rysunek 14.3 Opracowanie Strategii Zarządzania Rysu nek 17.4 Uaktualnianie Uzasadnienia
Konfiguracją - schemat działania Biznesowego - schemat działania
Rysunek 14.4 Opracowanie Strategii Zarządzania Rysunek 17.5 Raportowanie zakończenia etapu
Jakością - schemat działania - schemat działania
Rysunek 14.5 Opracowanie Strategii Zarządzania Rysunek 17.6 Sporządzanie Planu Nadzwyczajnego
Komunikacją - schemat działania - schemat działania
Rysunek 14.6 Ustanowienie mechanizmów Rysunek 18.1 Diagram procesu Zamykanie Projektu
sterowania projektem - schemat Rysunek 18.2 Przygotowanie planowego
działania
zamknięcia - schemat działania
Rysunek 14.7 Sporządzanie Planu Projektu Rysunek 18.3 Przygotowanie przedwczesnego
- schemat działania zamknięci a - schemat działania
Rysunek 14.8 Doprecyzowanie Uzasadnienia Rysunek 18.4 Przekazywanie produktów - schemat
Biznesowego - schemat działania działania
Rysunek 14.9 Zestawianie Dokumentacji Rysunek 18.5 Ocenianie projektu - schemat
Inicjowania Projektu - schemat działania
działania
Rysunek 18.6 Rekomendowanie zamknięcia
Rysunek 15.1 Diagram procesu Sterowanie Etapem projektu - schemat dzi ałania
Rysunek 15.2 Zezwalanie na wykonanie Grupy Rysunek 19.1 Czynniki wplywające na wymogi
Zadań - schemat działania
dostosowania
Rysunek 15.3 Przeg l ądanie stanu Grupy Zadań Rysunek 19.2 Porównanie projektów i programów
- schemat dzia łan i a
Rysunek 19.3 Struktura organizacyjna, w której
Rysunek 15.4 Odbieranie zakończonych Grup Przewodniczący jest członkiem rady
Zadań - schemat działania
programu, a Głównego Użytkownika
Rysunek 15.5 Przeglądanie stanu etapu - schemat mianuje odpowiedni szef zmiany
działania biznesowej
Rysunek 15.6 Raportowanie okresowe - schemat Rysunek 19.4 Struktura organizacyjna,
działania w której dyrektor programu jest
Przewodniczącym projektu, a funkcję
Rysunek 15.7 Wychwytywanie i analizowanie
Głównego Użytkownika w projekcie
zagadnień i ryzyk - schemat działania
pelni odpowiedni szef zmiany
Rysunek 15.8 Przekazywanie zagadnień i ryzyk biznesowej
- schemat działania
Rysunek 19.5 Przykład cyklu życia projektu typu
Rysunek 15.9 Podejmowanie działań korygujących studium wykonalności
- schemat działania
Rysunek A.1 Fazy rozwoju bazowych produktów
Rysunek 16.1 Diagram procesu Zarządz.anie zarządczych
Dostarczaniem Produktów
Rysunek D.1 Struktura podzialu produktów
Rysunek 16.2 Przyjmowanie Grupy Zadań do w formie diagramu hierarchicznego
wykonania - schemat dzialania
Rysunek D.2 Struktura podzialu produktów
Rysunek 16.3 Wykonywanie Grupy Zadań w formie mapy myśl i
- schemat działania
Rysunek D.3 Przykład diagramu n astępstwa
Rysunek 16.4 Oddawanie wykonanej Grupy Zadań produktów dla projektu
- schemat działania „ Konferencja"
Rysunek 17. 1 Diagram procesu Zarządzanie
Końcem Etapu

Rysunek 17.2 Planowanie następnego etapu

- schemat działania
Rysunek 17 .3 Uaktualnianie Planu Projektu
- schemat działania
Spis tabel

Tabela 3.1 Tematy PRINCE2 Tabela 13.3 Zezwalanie na realizację Planu

Etapu lub Planu Nadzwyczajnego
Tabela 4.1 Obowiązki dotyczące tematu
- obowiązk i
Uzasadnienie Biznesowe
Tabela 13.4 Podejmowanie decyzji doraźnej
Tabela 5.1 Obowiązki dotyczące tematu
- obowiązki
Organizacja
Tabela 13.5 Zezwalanie na zamknięcie projektu
Tabela 6.1 Relacje pomiędzy Nadzorem Projektu
- obowiązki
a nadzorem jakości
Tabela 14.1 Opracowanie Strategii Zarządzania
Tabela 6.2 Przykładowy Rejestr Jakości
Ryzykiem - obowiązki
Tabela 6.3 Obowiązki dotyczące tematu Jakość
Tabela 14.2 Opracowanie Strategii Zarządzania
Tabela 7.1 Obowiązki dotyczące tematu Plany Konfiguracją - obowi ązki

Tabela 8. 1 Przyk ład

techniki pieniężnej wartości Tabela 14.3 Opracowanie Strategii Zarządzania
oczekiwanej Jakością - obowi ązki

Tabela 8.2 Reakcje na ryzyko Tabela 14.4 Opracowanie Strategii Zarządzania

Komunikacją - obowiązki
Tabela 8.3 Obowiązki dotyczące tematu Ryzyko
Tabela 9.1 Rodzaje zagadnień
Tabela 14.5 Ustanowienie mechanizmów
sterowania projektem - obowiązki
Tabela 9.2 Decyzje Komitetu Sterującego
Tabela 14.6 Sporządzanie Planu Projektu
Tabela 9.3 Obowiązki dotyczące tematu Zmiana - obowiązki
Tabela 10.1 Sześćobszarów tolerancji dla różnych Tabela 14.7 Doprecyzowanie Uzasadnienia
poziomów zarządzania Biznesowego - obowiązki
Tabela 10.2 Obowi ązk i dotyczące tematu Postępy Tabela 14.8 Zestawianie Dokumentacji Inicjowania
Tabela 11.1 Przykładowa tabela obowiązków Projektu - obowi ązki

Tabela 11.2 Symbole użyte na diagramach
Tabela 12.1 Mianowanie Przewodniczącego
i Kierownika Projektu - obowiązki
Tabela 12.2 Zgromadzenie dotychczasowych
doświadczeń - obowiązki
Tabela 12.3 Projektowanie zespołu zarządzania
projektem i mianowanie jego
członków - obowiązki
Tabela 12.4 Przygotowanie zarysu Uzasadnienia
Biznesowego - obowi ązk i
Tabela 15.1 Zezwalanie na wykonanie Grupy
Zadań - obowiązki
Tabela 15.2 Przeglądanie stanu Grupy Zadań
- obowiązki
Tabela 15.3 Odbieranie zakończonych Grup Zadań
- obowiązki
Tabela 15.4 Przeglądanie stanu etapu - obowiązki
Tabela 15.5 Raportowanie okresowe - obowiązki
Tabela 15.6 Wychwytywanie i analizowanie
zagadnień i ryzyk - obowi ązk i

Tabela 12.5 Wybieranie formu ly rea lizacji projektu Tabela 15.7 Przekazywanie zagadn i eń i ryzyk
i zestawianie Założeń Projektu - obowiązki
- obowiązki
Tabela 15.8 Podejmowanie działań korygujących
Tabela 12.6 Planowanie etapu inicjowania - obowiązki
- obowiązki
Tabela 16.1 Przyjmowanie Grupy Zadań do
Tabela 13.1 Zezwalanie na zainicjowanie projektu wykonania - obowiązki
- obowiązki
Tabela 16.2 Wykonywanie Grupy Zadań
Tabela 13.2 Zezwalanie na realizację projektu - obowiązki
- obowiązki
 •
Spis Tabel I IX

Tabela 16.3 Oddawanie wykonanej Grupy Zadań

- obowiązki

Tabela 17 .1 Planowanie następnego etapu

- obowiązki
Tabela 17 .2 Uaktualnianie Planu Projektu
- obowi ązki
Tabela 17.3 Uaktualnianie Uzasadnienia
Biznesowego - obowiązki
Tabela 17.4 Raportowanie zakończenia etapu
- obowiązki
Tabela 17.5 Sporządzanie Planu Nadzwyczajnego
- obowiązki
Tabela 18.1 Przygotowanie planowego zamknięcia
- obowiązki
Tabela 18.2 Przygotowanie przedwczesnego
zamknięcia - obowiązk i

Tabela 18.3 Przekazywanie produktów

- obowiązki
Tabela 18.4 Ocenianie projektu - obowiązk i
Tabela 18.5 Rekomendowanie zamknięcia projektu
- obowiązki
Tabela 19.1 Wdrożenie a dostosowanie
Tabela 19.2 Przykłady projektów o różnej skali
Tabela 19.3 Porównanie PRINCE2 i Kompendium
Wiedzy
Tabela A.1 Przykładowa lista kontrolna
produktów
Tabela B.1 Zasady ładu zarządzania projektami
stowarzyszenia Association for Project
Management
Tabela D.1 Przykład Opisu Produktu Końcowego
Projektu dla corocznej konferencji
Przedmowa

Metodyka PRINCE2'" jest szeroko wykorzystywana To nowe wydanie zawiera pryncypia (zasady)
w ponad 1SO krajach świata i popyt na nią stale metodyki PRINCE2, wzmacniające stosowanie
wzrasta. Uważa się ją powszechnie za wiodącą dobrych praktyk w projektach, które zakończyly
metodykę zarządzania projektami, co potwierdza się sukcesem. Tematy PRINCE2 opisują te aspekty
ponad 20000 organizacji już odnoszących korzyści zarządzania projektami, które wymagają
z tego pionierskiego i niezawodnego podejścia. szczególnego potraktowania, a procesy metodyki
PRINCE2 przedstawiają przebieg realizacji projektu
Niniejszy zaktualizowany podręcznik pomoże
przez caly cykl jego życia od przygotowania do
osobom prowadzącym projekty każdej wielkości
zamkn i ęcia. Rekomendowane jest korzystanie
i w każdym środowisku w efektywnym dostarczaniu
z niniejszego podręcznika w połączeniu
tego, czego si ę od nich wymaga poprzez właści we
z towarzyszącym mu podręcznikiem: Directing
zarządzanie kosztami, terminami, ja kości ą,
Successful Projects with PRINCE2 (TSO, 2009).
zakresem, ryzykami i korzyściami. Opracowanie
podręczn i ka poprzedzily szerokie konsultacje; Liczba osób zdobywaj ących kwalifikacje w zakresie
czerpie on z praktycznych doświ adczeń organizacji metodyki PRINCE2 rośnie corocznie o około 20o/o
sektora zarówno publicznego, jak i prywatnego. i pozostaje kluczowym czynnikiem mającym wplyw
na pomyślną real izację projektów. Jest to metodyka
W dzisiejszych czasach złożon e proj ekty często,
niezbędna w każdej organizacji, która chce
aby osiągnąć wyznaczone cele, angażują kilka
zapewnić sobie racjona lne i efektywne rezu ltaty
organizacji wspólpracujących partnersko lub
operacyjne.
w ramach umowy. Metodyka PRINCE2 dostarcza
wspólnego języka w kontaktach pomiędzy tymi
organizacjami i z zewnętrznymi dostawcami.
Pozwala także skupić się na Uzasadnieniu
Biznesowym, dostarczając mechanizmu do
określenia tego, co projekt zamierza osiągnąć oraz
powodów i sensu biznesowego podjęcia projektu.
Niniejsza, najnowsza wersja PRINCE2 - Skuteczne
zarządzanie projektami to wynik ewolucji
poprzednich podręczników. Podstawowa część
metodyki nie uległa zmianie, ale uwzględniając
komentarze użytkowników podjęto starania, Nigel Smith
aby ten nowy podręczn i k był łatwiejszy i bardziej
przystępny w dostosowaniu do konkretnych
Naczelny Dyrektor (Chief Executive)
indywidualnych potrzeb. Office of Government Commerce
Podziękowania
Niniejszy podręcznik jest kontynuacją prac Office of
Government Commerce (OGC) nad rozwojem i ulep-
szeniem definicji i sposobu prezentacji PRINCE2.
Zespolowi autorskiemu należą się podziękowania
za jego znaczący wkład, wniesiony na podstawie
kontraktu, w zaprojektowanie i opracowanie tego
podręcznika.
Wiodący autor
Outperform UK Ltd
Andy Murray
Zespół autorski
Sun Microsystems Ltd
Nigel Bennett
pearcemayfield
John Edmonds
Fujitsu Services
Bob Patterson
APMG PRINCE2 Examiner
Sue Taylor
Graham Williams GSW Consultancy Ltd
Główny recenzent i mentor
Colin Bentley PRINCE2 Chief Examiner 1998- 2008
Inne osoby, które wniosły wkład
W celu zapewnienia, aby podręcznik OGC PRINCE2 -
Skuteczne Zarządzanie Projektami (2009) nadal pra-
wid lowo odzwierci ed l ał aktualne i przyszle trendy na
międzynarodowym polu najlepszych praktyk zarzą­
dzania projektami oraz w celu opracowania poradni-
ka o trwałej wartości, OGC przeprowadziło zakrojone
na szeroką skalę konsultacje z glównymi interesariu-
szami i ekspertami na każdym etapie tego procesu.
OGC pragnie podziękować następującym osobom
oraz reprezentowanym przez nie organizacjom za ich
wkład w opracowanie tego nowego podręcznika:
Grupa referencyjna PRINCE2
Rob Brace, Department of Work & Pensions;
Andrew Bragg, Chief Executive, APM;
Prof. Christophe Bredillet, ESC Lille; Terry Cooke
Davis, Human Systems; Lynne Crawford, University
of Sydney; John Cutting, MOD (DPA - DE&S);
Prof. Darren Dalcher, Middlesex University,
National Centre for Project Management; Steve
Falkenkrog, PMI; Ruth Little, DTI Projects Centre;
Dusty Miller, Sun Microsystems Ltd; Bob Patterson,
Fujitsu; Philip Rushbrook, Cabinet Office; Beverley
Webb, BSI Project Management standard
committee; Jens Wandei, Director, UNDP.
Komitet Sterujący projektu PRINCE2: 2009
Mike Acaster, OGC, Przewodniczący; Eddie Borup,
BPUG, Glówny Użytkownik; Anne-Marie Byrne,
TSO, Kierownik Projektu; Janine Eves, TSO,
Główny Dostawca; Sandra Lomax, BPUG, Główny
Użytkownik; Richard Pharro, APMG, Główny
Dostawca.
Obsługa zmian
Coos Groot, Best Practice User Group (PRINCE2
ltaly); Peter Johnson, Peter Johnson PJ Ltd; Sheila
Roberts, Cupe Ltd; Martin Rother, Best Practice
User Group (PRINCE2 Germany); David Watson,
ADt Partnership.
Recenzenci
Robert Allen, PRS for Music; Adalcir da Silva Angelo,
Elumini IT & Business Consulting; Paul Askew,
Housing Corporation; Richard Aspden, Pathfinder
Project Management; Gareth Atwood, Foster
Wheeler Energy; Mare Baetens, Pronohau Ltd;
Andrew Bali, Aud it Commission; Jim Barker, Curtis
& Cartwright Consulting Ltd; Keith Batchelor, Foster
Wheeler Energy; Dick Bennett, APMG Chief Assessor;
Kate Blackall, APMG PRINCE2 examiner; Johan
Bleeker, Standard Bank; Eddie Borup, lbps solutions;
Chris Braithwaite, Wellstream; George Brooke,
Oak Lodge Consulting Ltd; Mark Canning, North
West Regional Development Agency; Tim Carroll,
Standard Chartered Bank; Jacqueline Chadwick,
VOSA; Sue Childs, APMG PRINCE2 examiner;
Alison Clack, Sean A lison Ltd; Jim Clinch, Clinch
Consulting; Brian Coombes, The Projects Group;
Arthur Coppens, Getronics Consulting Educational
Services; Bjarne Corvinius, Rovsing Management;
Anthony Dailey, MWH; Terry Dailey, Deliverables
Management Consultants; Bill Duncan, APMG
PRINCE2 examiner; Hassan El Meligy, IEEE; Darilyn
Evans, Adaptive Frameworks; Alan Ferguson, AFA;
Chris Ferguson, Novare Consulting Ltd; Ray Frew,
Aspen Management Training; Alvin Gardiner,
PR-02 (Scotland) Ltd; Emmanuel Gianquitto, APMG
(International); Colin Graham, Aylesbury Vale DC;
 ••
Xll I Podziękowania

John Greenwood, CSC; Angelika Hamilton, APMG Grupa pilotażowa PRINCE2 - Skuteczne
(Germany}; Gary RO Haran Doyle, Swiss Life; Simon Zarządzanie Projektami
Harris, Logical Model Ltd; Wietse Heidema, Opmaat The British Council; Capital Coast District Heałth
Consultancy & Training; Luis Herrera, Konsultant; Board; Department of Labour (New Zealand};
Terry Hewins, Land Registry; Emma Jones, APMG Fishserve; Metropolitan Police; M inistry of Economic
PRINCE2 Chief Examiner; Nigel Jones, AJS; Howard Development (New Zealand}; M inistry of Education
Joseph, Home Office; Ravi Joshi, Action For (New Zeałand); Staffordshire Metropolitan Borough
Children; Hans Kemper, APMG (Netherlands); Eddie
Council; Standard Bank; Suffołk County Council; Sun
Kilkelly, ILX Group pic; Lawrie Kirk, Tanner James Microsystems Ltd; Vietnamese Academy of Social
Management Consultants (Australia}; Wiesław Sciences.
Kosieradzki, P2ware; Eddie Lamont, Lothian
& Borders Police; Tony Levene, Quality Projects;
Martin Lewis, Lucid IT; David Lillicrap, London
Borough of Ealing; Steve Livingstone, BNFL; Tim
Lulham, Network Raił; Maria Maltby, Charnwood
Borough Council; Dusty Miller, Sun Microsystems
Ltd; Trevor Mirams, Parity; Adrian Newton, Quorum
ICT; Bruce Nicholls, Bryan Cave; Helen Nicoli, NHS;
Chris Price, Highways Agency; G. Raghunandan,
Satyam Computer Services Ltd; Geoff Rankins, Goal
Professional Services Pty Ltd; Lizz Robb,
Yellowhouse.net pty Ltd; Graham Robertson, Serco;
Eiłeen Roden, PM Professional Learning; Philip
Rushbrook, Cabinet Office; Ian Santry, Home Office;
Tłumaczenie i opracowanie wersji polskiej
Andrew Schuster, Department of Health; Noel Scott,
Symantec; John Sherwood, Highways Agency; Joy
Shewring, APMG (USA}; Jay M. Siegełaub, lmpact Koordynacja i nadzór merytoryczny
Strategies LLC; Raed M . Skat, Oger Systems Ltd; Tim Wiesław Kosieradzki, P2ware
Sneller, Southend-on-Sea Borough Council; Rod
Sowden, Aspire Europe Ltd; Phil Stephensen-Payne, Zespół redakcyjny
Remarc Group; Rob Sucher, Armstrong Webb;
Iwona Sem i k-Żbikowska, lnf ovide-Matrix;
Mark Sutton, SCOLL Methods Ltd; Ian Thomas, Piotr Górny, lnfovide-Matrix;
Liberty Network Consułtancy; Dot Tudor, TCC; Andrzej Golik, Centrum Rozwiązań Menedżerskich;
Bram de Vuyst, Getronics Consulting Management Krzysztof Maius, The PSO.
Services; Jens Wandei, United Nations Development
Program me; Geoff Ward, APMG PRINCE2 examiner;
Tłumaczenie
Sheryl Ward, Skandia; Peter Weaver, Corte-grande;
RWS Group, Wydział tłumaczeń
David Whelbourn, Xwave solutions inc; Stephen
Wierzbicki, Bristol Management Centre; Jorn Wigh,
APMG (Denmark}; Gerald Will iams, Projectlabs; Philip Opracowanie graficzne i skład
W ilson, Cabinet Office. Tomasz Białkowski, Studio Tobox
Konwencja zapisu przyjęta w niniejszym
podręczniku

W całym tekście niniejszego podręcznika następują­

ce pojęcia są pisane wielką literą:
• tematy PRINCE2
• procesy PRINCE2
• ro le PRINCE2
• zdefiniowane produkty zarządcze
Działania w procesach PRINCE2 są zawsze wskazy-
wane przy wykorzystaniu tych samych kluczowych
słów lub wyrażeń i nie są odróżniane w inny sposób,
ponieważ powinny w sposób oczywisty wynikać
z kontekstu. Na przykład: „w takich okol iczności ach
Komitet Sterujący podejmie decyzję doraźną".
W większości przypadków unikano stosowania
skrótów i akronimów, jednakże w przypadku ich
zastosowania ich pełne brzmienie podano przy
pierwszym zastosowaniu.
Kluczowe kwestie zosta ły oznaczone w następujący
sposób:

Projekt PRINCE2 posiada ciągłą zasadność

biznesową.

Przyklady technik zostały przedstawione w następu­

jący sposób:

Przykład
techniki określania priorytetów
- MoSCoW
Każde kryterium akceptacji jest klasyfikowane
w skali jego ważności jako: „musi być spełnione",
„powinno być spełnione", „może być spełnione"
albo „nie będzie spelnione na razie" {ang. Must
have, Should have, Cou/d have lub Won't have -
w skrócie MoSCoW).
Wszystkie kryteria akceptacji zaklasyfikowane
jako „musi być spełnione" i „powinno być speł­
nione" powinny być wspólnie osiągalne.
 1 Wprowadzenie
1.1 CEL NINIEJSZEGO PODRĘCZNIKA
PRINCE2 (Projekty w sterowalnym środowi sku, ang.
PRojects IN Controlled Environments) to ustruktury-
zowana metodyka zarządzania projektami, oparta na
doświadczeniach pochodzących z tysięcy projektów
oraz na wkładzie wniesionym przez niezliczonych
sponsorów projektów, Kierowników Projektów,
zespoły projektowe, naukowców, szkoleniowców
i konsultantów. Niniejszy podręcznik przygotowano:
• d la osób początkujących w zarządzaniu projek-
tem, które chcą dowiedzieć si ę czegoś ogólnie
na temat zarzą dzania projektami i metodyki
PRINCE2 w szczegó l ności;
• dla doświadczonych Kierowników Projektów
i personelu, którzy chcą poznać metodykę
PRINCE2;
• jako szczególowe źródło wiedzy dla praktyków
PRINCE2;
• jako źródło informacji o PRINCE2 dla menedże­
rów zastanawiających się, czy wprowadzić tę
metodykę.
Podręcznik odpowiada na pytania zadawane często
przez osoby bezpośred nio za rządzaj ące projekta-
mi, bądź pełniącym i role wsparcia projektów. Są to
pytania, takie jak:
• Czego si ę ode mnie oczekuje?
• Co robi Kierownik Projektu?
• Co mam zrobić, jeżeli sytuacja nie rozwija się
zgodnie z planem?
• Jakich decyzji oczekuje się ode mnie?
• Jakich informacji potrzebuję lub muszę
dostarczyć?
• Do kogo mam się zwrócić po wsparcie,
wytyczne?
• Jak mogę dostosować metodykę PRINCE2
do mojego projektu?
1.2 ZNACZENIE PROJEKTÓW
Kluczowym wyzwaniem dla organizacji w dzisiej-
szym świecie jest pomyślne zrównoważenie dwóch
jednocześnie występujących, ale wzajemnie konku-
rencyjnych nakazów:
• Utrzymywać bieżące dzia łania biznesowe - ren-
towność, j akość usług, relacj e z klientami, lojal-
ność wobec marki, produktywność, zaufanie
rynku itd. To, co nazywamy „zwykłą dziala l nością
biznesową" .
• Przekształcić działania biznesowe tak, aby prze-
trwać i konkurować z innymi w przyszlości -
spoglądając w przyszlość i podejmując decyzje,
w jaki sposób wprowadzić zmiany w biznesie, by
ich efekty byly d la organizacji jak najlepsze.
Ponieważ tempo zmian (technicznych, biznesowych,
społecznych, regulacyjnych/prawnych itd.) stale
wzrasta, a kary za brak adaptacji organizacji do
zmian staj ą się coraz bardziej oczywiste, nieuniknio-
na staje si ę koncentracja zainteresowania kierow-
nictwa na osiągnięciu równowag i pomiędzy zwyklą
działalnością biznesową a zmianami biznesu.
Projekty są sposobem wprowadzania zmian.
I chociaż wiele z wymaganych umiejętności pozo-
staje takich samych, to istnieją zasadnicze różnice
pomiędzy zarządzaniem zwykłą działalnością bizne-
sową a za rządzaniem pracami projektu.
1.3 CO WYRÓŻNIA PROJEKTY?
Projekt to organizacja tymczasowa, powołana
w celu dostarczenia jednego lub więcej produk-
tów biznesowych według uzgodnionego Uza-
sadnienia Biznesowego.
Prace projektowe posiadają wiele cech odróżniają ­
cych je od zwykłej działalności biznesowej:
• Zmiany Projekty to sposoby wprowadzania
zmian.
• Tymczasowość Zgodnie z powyższą defin icją,
projekty z samej swojej natury są reali zowane
w skończonym czasie. Po wdrożen iu pożąda­
nej zmiany, kontynuowana jest zwykła działal­
ność biznesowa (w swojej nowej formie) i znika
potrzeba istnienia projektu. Projekty powinny
mieć określony początek i określony koniec.
• Wielofunkcyjność Projekty angażują zespoly
składające się z osób o różnych umiejętnościach,
współpracujących (przez pewien czas) w celu
4 I Wprowadzenie
wprowadzenia zmiany, która wpłynie na inne
osoby poza zespołem. Projekty często przekra-
czają zwykłe podziały funkcyjne w organizacji,
a czasami obejmują całkowicie różne organiza-
cje. Powoduje to często stresy i nap i ęcia zarów-
no wewnątrz organizacji, jak i pomiędzy nimi,
na przykład pomiędzy klientami i dostawcami.
Każdy ma odmienną perspektywę i motywacj ę
do zaangażowania si ę w zmianę.
• Unikalność Każdy projekt jest unikalny.
Organizacja może podjąć się wielu podobnych
projektów i wypracować znany, sprawdzo-
ny schemat dzia łań projektowych, ale każdy
projekt będz i e w jakiś sposób wyjątkowy:
inny zespół, inny klient czy inna lokalizacja.
Wszyst kie te czynniki składaj ą się na un i ka l ność
każdego projektu.
• Niepewność Jasne jest, że podane powyżej
cechy pociągną za sobą w iele zagrożeń i szans,
których zazwyczaj si ę nie spotyka. Projekty niosą
ze sobą wi ększą n i epewn ość niż zwykła działal­
ność biznesowa.
1.4 DLACZEGO POTRZEBNA JEST M ETO-
DYKA ZARZĄDZAN IA PROJEKTEM?
Zarządzanie projektem to planowanie, dele-
gowanie, monitorowanie i kontrolowanie
wszystkich aspektów projektu oraz motywowa-
nie zaangażowanych osób, aby osiągnąć cele
projektu w granicach docelowych wskaźników
wykonania dla czasu, kosztów, j akości, zakresu,
korzyści i ryzyk.
Rezultaty projektu uzyskiwane są dzi ęki wynikom
działań w proj ekcie (w PRINCE2 nazywanych pro-
duktami). Nowy dom buduj e si ę, wykonując rysunk i,
fundamenty, podłog i, ściany, okna, dach, instalacj ę
wodno-kanal i zacyjną i elektryczną oraz związa-
ne z tym usługi. Nic z tego nie jest zarządzaniem
projektem - dlaczego więc potrzebujemy w ogóle
zarządzania projektami? Celem za rządzania projek·
tern jest utrzymywanie kontroli nad specjalistyczny-
mi pracami wymaganymi do wytworzenia produk-
tów projektu lub, kontynuując ana l ogię z budową
domu, do zapewnienia, że fachowcy kładący dach
nie pojawią się zanim nie zostaną ukończone ścia ny.
Poza tym, b i orąc pod uwagę, że projekty są spo-
sobem wprowadzania zmian w biznesie i że prace
projektowe n i osą za sobą wyższe ryzyko niż inne
dzi ałan i a biznesowe, logiczne j est, że wdrażanie
bezpiecznego, spójnego, dobrze sprawdzonego
podejścia do zarządzania projektami jest cenną
inwestycją biznesową .
1.5 WPROWADZENIE DO PRINCE2
PRINCE2 jest metodyką niezastrzeżoną prawnie,
która na ca łym świeci e j est postrzegana jako jedna
z najszerzej akceptowanych metod zarządzania pro-
j ektami. Wynika to g łówn ie z faktu, że metodyka
PRINCE2 jest na tyle ogólna, że można j ą zastosować
w każdym projekcie niezależnie od skali i rodzaju
projektu, organizacji, położen i a geograficznego czy
kult ury.
PRINCE2 osiąga t e cele poprzez oddzielenie aspek-
tów zarządczych prac projektowych od prac specja-
listycznych, takich j ak projektowanie, konstruowa-
nie itp. Aspekty specjalistyczne każdego rodzaju
projektu można łatwo zi nteg rować z metodyką
PRINCE2 i wykorzystać łączn i e z nią, dosta rczaj ąc
bezpiecznej, całości owej platformy dla prac projek-
towych.
Pon i eważ metodyka PRINCE2 j est ogólna i oparta
na sprawdzonych pryncypiach (zasadach), organi-
zacje przyjmujące tę metodykę jako standard mogą
znacznie po l epszyć swoją zdolność organizacyj n ą
i dojrza łość w wielu sferach dzia ła l ności bizneso-
wej, takich jak zmiany w b iznesie, b udownictwo,
informatyka, fuzje i przej ęcia firm, badania, rozwój
produktu itd.
1.5.1 Co robi Kierownik Projektu?
Aby sprawować kontrol ę nad czymkolw iek, musi
istnieć plan. To właśnie Kierownik Projektu planuje
kolejność dzia łań w celu wybudowania domu, obli-
cza ilu będzi e potrzebnych murarzy itd.
Możl i we jest samodzielne wybudowanie domu
- jednakże bycie kierownikiem implikuj e oddele-
gowanie pewnych lub całości prac innym osobom.
Zdolność delegowania jest ważna w każdym rodzaju
zarządzan i a, ale szczególnie ważna jest (z powodu
wi elofunkcyjności i ryzyk) w za rządzaniu projektem.
Kiedy delegowane prace są j uż wykonywane, celem
jest „by przebiegały one wed ług planu", ale nie
możemy zakładać, że tak będ zie zawsze. Obowiąz­
kiem Kierownika Projektu jest monitorowanie tego,
na ile realizacja prac zgodna jest z planem.
Oczywi ści e, jeżel i
prace nie idą zgodnie z planem,
Kierownik Projektu musi coś z tym zrobić, czyli
odpowiednio tym sterować. Nawet, jeśli prace idą

dobrze, Kierownik Projektu może dostrzec nowe
możliwości przyspieszenia prac i zmniejszenia kosz-
tów, czy to poprzez podjęcie działań korygujących,
czy wdrożenie środków poprawy efektywności.
Celem PRINCE2 jest zapewnienie właściwych infor-
macji, we właściwym czasie, wlaściwym ludziom, aby
mogli podjąć wlaściwe decyzje.
" Planuj
I
Kontroluj Deleguj
Rysunek 1.1
Monitoruj
Zarządzanie
I
projektem
1.5.2 Co chcemy kontrolować?
W każdym projekcie występuje sześć zmiennych,
a co za tym idzie, sześć aspektów efektywności pro-
jektu, którymi trzeba zarządzać.
• Koszty Projekt musi mieścić się w zakresie moż­
liwości finansowych i, chociaż rozpoczniemy go
z konkretnym budżetem początkowym, to może
wystąpić wiele czynników, które doprowadzą do
nadmiernych wydatków, choć niewykluczone jest
ta k że pojawienie się okol iczności pozwalających
na zmniej szenia kosztów.
• Terminy Powiązane z tą zmienną pytanie:
„ Kiedy to będzie ukończone?", jest pewnie
pytaniem najczęściej zadawanyn Kierownikowi
Projektu.
• Jakość Zakończenie projektu na czas i w ramach
budżetu nie jest wystarczające, jeżeli rezultaty
projektu nie są zgodne z oczekiwaniami. Zgodnie
z terminologią PRINCE2, produkty projektu muszą
odpowiadać swojemu przeznaczeniu.
• Zakres Co tak na prawdę dostarczy projekt?
Bez tej w iedzy różne strony zaangażowane
w projekt mogą często mieć na ten temat bardzo
rozbieżne poglądy. Klient może przypuszczać,
że na przykład kuchnia i/lub łazienka z pełnym
wyposażeniem uwzględniona jest w cenie domu,
podczas gdy dostawca uważa je za „dodatki".
W dużych projektach, określenie ich zakresu
jest bardziej subtelne i złożone . Zakres projektu
musi być uzgodniony, a Kierownik Projektu musi
dokładnie rozumieć, co wchodzi lub nie wchodzi
w ten zakres. Kierownik Projektu musi starać się,
Wprow adzenie I 5
aby nie przekroczyć zakresu projektu, ponieważ
jest to częstym źródłem opóźnień, nadmiernych
wydatków oraz niekontrolowanych zmian {tzw.
„ pełzanie zakresu").
• Ryzyko Wszystkie projekty wi ążą s i ę z ryzy-
kiem, ale dokladnie jak w ielkie ryzyko możemy
zaakceptować? Czy powinniśmy zbudować dom
w pob l iżu opuszczonej kopalni, gdzie teren
może się zapadać? Jeżeli zdecydujemy się na to,
czy możemy coś zrobić w kwestii tego ryzyka?
Może powinniśmy się ubezpieczyć od takich
zdarzeń lub przeprowadzić dokladne badania
geologiczne?
• Korzyści Być może najczęściej pomijanym
pytaniem jest „Dlaczego to robimy?". Nie
wystarczy pomyśln i e wybudować dom na czas,
w ramach budżetu oraz zgodnie z wymagania-
mi j akości owymi, j eżel i w końcu nie możemy go
sprzedać czy wynająć z zyskiem lub szczęśliwi e
w nim zamieszkać . Kierownik Projektu musi
dokładnie znać i rozumieć cel projektu jako
inwestycji i zagwarantować, że to, co projekt
dostarcza, umożliwi osiągnięcie pożądanego
zwrotu z inwestycji.
PRINCE2 to zintegrowana struktura składająca się
z procesów i t ematów obejmujących planowanie,
delegowanie, monitorowanie oraz kontrolę wszyst-
kich tych sześciu aspektów efektywności projektu.
1.5.3 Struktura PRINCE2
Metodyka PRINCE2 przedstawia zarządzanie projek-
tem jako cztery zintegrowane elementy - pryncypia
(zasady), tematy, procesy i środowisko projektu
{Rysunek 1.2).
~RODOWISKO PROJEKTU
Uzas.dni~1t
PROCESY PRINCE2
lły')lkO Plany
TEMAlY PRINC(2
Rysunek 1.2 Struktura PRINCE2
6 I Wprowadzenie

1 Pryncypia (zasady) (Rozdział 2) 4 Dostosowanie PRINCE2 do środo wiska

To nakazy przewodnie i dobre praktyki określ ające, proj ekt u (Rozdział 19)
czy projekt jest rzeczywiście zarządzany z wykorzy- Rozdział ten odnosi się do potrzeby każdorazowe­
staniem metodyki PRINCE2. Istniej e siedem pryncy- go dostosowania PRINCE2 do konkretnego kontek-
piów i o ile wszystkie z nich nie zostaną zastosowa- stu projektu. PRINCE2 nie jest rozwiązaniem typu
ne, projekt nie jest projektem zgodnym z PRINCE2. „jedno rozwiązanie pasujące do wszystkiego", ale
jest to elastyczna struktura, którą można łatwo
2 Tematy (Rozdziały 3 do 10) dostosować do każdego rodzaju czy wie lkości
Opisuj ą one aspekty za rządzania proj ektem, którymi projektu.
na l eży się zajmować stale i równolegle w t rakcie
Istnieje osobna publikacja stowarzyszona z tym
ca łego projektu. Siedem tematów objaśnia, jakie
pod ręczn iki em pt. Directing Successful Projects
konkretne postępowanie jest wymagane przez with PRINCE2, która odnosi się do metodyki PRIN-
PRINCE2 dla różnych obszarów zarządzania projek- CE2 z punktu widzenia naczelnego kierownictwa,
tami oraz dlaczego jest ono konieczne. a konkretnie członków Komitetu Sterującego.

3 Procesy (Rozdziały 11 do 18)

1.6 POWIĄZAN E PUBLIKACJE OGC
Opisuj ąone krok po kroku dzia łania podejmowane
w całym cyklu życia projektu, od jego przygoto- PRINCE2 j est częścią zbioru wytycznych opracowa-
wania do zamkn ięcia. Każdy proces dostarcza listy nych przez brytyjskie biuro Office of Government
kontrolne zalecanych czynności, produkty zarządcze Commerce (OGC), których celem jest pomoc organi-
oraz związane z nimi obowiązki. zacjom i pojedynczym osobom w zarządzaniu pro-
jektami, programami oraz usługami w sposób spójny
i efektywny. Rysunek 1.3 przedstawia stru kturę tego
zbioru publikacji.

Wspólne nazewnictwo
, ------- '
I' Modele 'I /
Przewodniki '
r
Aktualizacja w toku
/
' ' ' /
'
Portfolio,
Programme
and Project Gateway® M_o_R® IT/L®
Portfolio,
Office
Programme and (P3Q®)
Project
Management r - '
Maturity Model Portfolio Guide (PfM)
(P3M3®) ,
'
I
- - - ....
\ I MSP"' (program)
'
1 PRINCEz® I ,li
I Maturity Model I I ,"
I (P2MM ) I I '

____, , "
PRINCEl® (projekt)
I I
I
I I „ ....
\ ' ,_ -
......._ - _, ,I \_ ,I \_ ,I \.. ,li
,
"--- -- --~ "

Rysunek 1.3 Publikacje OGC dotyczące najlepszych praktyk


Tam, gdzie jest to właściwe, do metod i wytycznych
OGC dodawane są programy zdobywania kwalifi-
kacji, a wszystkie aspekty wspierane są przez akre-
dytowane szkolenia i uslugi doradcze. Szczególowe
informacje o tych przewodnikach dotyczących naj-
lepszych praktyk i innych pow i ązanych przewodni-
kach zna l eźć można w rozdziale Dalsze Informacje.
1.6.1 Czego PRINCE2 nie obejmuje?
Nie jest zamierzone (ani możliwe), aby metodyka
PRINCE2 obejmowała wszelkie aspekty zarządzania
projektami. Trzy szerokie kategorie tematyczne celo-
wo pozostawiono poza zakresem PRINCE2:
• Aspekty specjalistyczne Mocną stroną meto-
dyki PRINCE2 jest j ej szeroka stosowalność - jest
to metodyka całkowicie ogólna. W konsekwen-
cji tego wykluczono dz i ała l ność specyficzną dla
danego prze m ysł u, bra nży czy rodzaju projektu.
Modele i nżyn iersk i e, cykle źycia proj ektu lub
konkretne techniki (takie jak zarządzanie zmia-
ną organizacyj ną czy zaopatrzenie) mogą być
fatwo użyte w połączeniu z PRINCE2. PRINCE2
kwalifikuje wszystkie te aspekty prac projekto-
wych jako „specjalistyczne" (co oznacza, że pro-
dukty specjalistyczne, których dotyczy projekt,
należy określić i włączyć do zakresu i planów
projektu).
• Szczegółowe techniki Istnieje w iele spraw-
dzonych t echnik planowania i kontroli, które
można wykorzystać, wspie rając nimi tematy
PRINCE2. Przyk ładam i są analiza ścieżki kry-
tycznej (w planowaniu) oraz analiza warto-
ści wypracowanej (w kontroli postępu prac).
Techniki takie są dobrze udokumentowane
gdzie indziej. Opisano tylko techniki zawierają­
ce podejście specyficzne dla PRINCE2, np. plano-
wanie oparte na produktach i technikę przeglą­
du jakości.
• Zd olności przywódcze Przywództwo, umie-
jętności motywacyjne i inne u miejętności inter-
personalne są ogromnie ważne w zarządza n i u
proj ektami, ale n iemożl i we do skodyfikowania
w jakiejś metodyce. Style przywódcze różnią
się znacznie. Styl, który dobrze sprawdza się
w jednej sytuacji, może być całkowicie nieod-
powiedni w drugiej. Fakt, że latwo jest wskazać
przywódców, którzy odnieśli sukces przyjmu-
jąc bardzo różne style, od autokratycznego do
opartego na konsensusie, tylko to potwierdza.
Z tego powodu PRINCE2 nie może bezpośrednio
uwzględniać tego aspektu zarządzan i a projek-
Wprowadzenie I 7
tarni. Istnieje wiele modeli przywództwa oraz
programów szkolenia umiejętności interperso-
nalnych, które spe lniają te wymagania.
1.7 KORZYŚCI Z PRINCE2
Przed przedstawieniem strukt ury tej metodyki warto
przejrzeć kluczowe korzyści z przyjęcia PRINCE2:
• PRINCE2 urzeczywistnia uznane i sprawdzone naj-
lepsze praktyki oraz ład zarządzania projektami;
• metodykę tę można zastosować w projekcie każ­
dego rodzaju i fatwo można ją wdrożyć wspól -
nie ze specjalistycznymi, właściwymi dla danego
przemysłu/branży modelami („modelami inżynie­
ryjnymi" czy „cyklami rozwojowymi");
• metodyka PRINCE2 jest szeroko rozpoznawalna
i rozumiana. wobec czego dostarcza wspólnego
języka wszystkim uczestnikom projektu, promu-
jąc efektywną komunikację;
• metodyka PRINCE2 jasno precyzuje obowiązki
w projekcie, dzięki czemu uczestnicy rozumieją
wzajemnie swoje role i potrzeby. Istnieje okre-
ślona struktura odpowiedzialności, delegowania,
uprawnień/wladzy i komunikacji;
• dzięki skoncentrowaniu na produkcie precyzuje
(wszystkim stronom), co projekt dostarczy, dla-
czego, kiedy, przez kogo i dla kogo;
• plany PRINCE2 są starannie opracowywane, aby
zaspokoić potrzeby różnych szczebli w zespole
zarządza nia, usprawniając komu nikację i kontrolę;
• metodyka opiera s i ę na koncepcj i „zarządza ­
nia z wykorzystaniem tolerancji", zapewn i ając
efektywne i ekonomiczne wykorzystanie czasu
kadry kierowniczej (na szczeblu organizacji,
programu, Komitetu Sterującego czy zarządza­
nia projektem);
• PRINCE2 gwarantuje, że uczestnicy w większym
stopniu koncentrują się na utrzymywaniu zasad-
ności projektu w nawi ązaniu do celów zawartych
w Uzasadnieniu Biznesowym, a nie postrzegaj ą
po prostu ukończen ia projektu j ako celu samego
w sobie;
• określa dog lębną, ale oszczędn ą stru kturę
raportów;
• gwarantuje, że interesariusze (łącznie ze sponso-
rami i udostępniającymi zasoby projektowe) są
odpowiednio reprezentowani podczas planowa-
nia i podejmowania decyzji;
• wdrożenie PRINCE2 promuje w organizacjach
uczenie się i ciągłe doskonalenie;
8 I Wprowadzenie

• PRINCE2 promuje spójność w realizacji prac

projektowych oraz możliwość ponownego
wykorzystania aktywów projektu; sprzyja także
mobilności personelu oraz zmniejsza wpływ
zmian i przesunięć personelu;
• PRINCE2 jest niezastąpionym narzędziem diagno-
stycznym, u łatwiającym nadzorowanie I ocenę
prac projektowych, rozwiązywanie problemów
oraz audyty;
• istnieje wiele akredytowanych organizacji szko-
leniowych (ATO) i akredytowanych organizacji
konsultingowych (ACO). działających na całym
świecie, które mogą udzielić wsparcia eksperc-
kiego projektom PRINCE2 łub organizacjom.
planującym wdrożenie PRINCE2.
2 Pryncypia (zasady)
Celem PRINCE2 jest dostarczenie metodyki zarządza­
nia projektami, którą zastosować można niezależnie
od zakresu projektu, rodzaju, organizacji, polożenia
geograficznego czy kultury. Jest to możliwe, ponie-
waż metodyka PRINCE2 oparta jest na pryncypiach.
Pryncypia scharakteryzowane są jako:
• uniwersalne, ponieważ mają zastosowanie
w każdym projekcie;
• samopotwierdzające, ponieważ sprawdzily się
w praktyce przez wiele lat;
• i nspirujące, pon i eważ zwi ększaj ą pewność siebie
osób praktykujących tę metodykę i umożliwiają
im wplywanie na sposób zarządzan i a projektem
i kształtowan i e go.
Pryncypia, na których opiera się PRINCE2, wywodzą
si ę z doświadczeń projektów zarówno zakończo·
nych sukcesem, jak i porażką. Dostarczają one oso-
bom zaangażowanym w projekt strukturę opartą
na dobrych praktykach. Jeżeli projekt nie stosuje się
do któregokolwiek z tych pryncypiów, nie jest on
zarządzany zgodnie z PRINCE2, ponieważ pryncypia
te stanowią podstawę tego, co definiuje projekt
zgodny z PRINCE2.
Siedem pryncypiów (zasad) PRINCE2 to:
• ciągła zasadność biznesowa,
• korzystanie z doświadczeń,
• zdefiniowane role i obowiązki,
• zarządzanie etapowe,
• zarządzanie z wykorzystaniem tolerancji,
• koncentracja na produktach,
• dostosowanie do warunków projektu.
To wlaśnie zaadaptowanie tych pryncypiów decy-
duje o tym, że projekt stosuje metodykę PRINCE2,
a nie tylko samo formal ne przyjęcie procesów
i dokumentacji. Pryncypia ulatwiają dobre wykorzy-
stanie PRINCE2 poprzez zapewnienie, że met odyka
ta nie jest stosowana w sposób nadmiernie norma-
tywny lub że przywoluje się tylko jej nazwę, ale że
stosuje się ją w sposób wystarczający do tego, by
przyczyniła się do sukcesu projektu.
2.1 CIĄGŁA ZASADN OŚĆ BIZNESOWA
Projekt zgodny z PRINCE2 ma ciągle ważne
uzasadnienie biznesowe.
Wymogiem dla projektu zgodnego z PRINCE2 jest:
• istnienie uzasadnionego powodu jego
rozpoczęcia,
• uzasadnienie to powinno pozostawać ważne
przez cały czas trwania proj ektu,
• uzasadnienie jest udokumentowane
i zatwierdzone.
W PRINCE2 t o uzasadnienie jest przedstawiane
w dokumencie Uzasadnienie Biznesowe. Ponieważ
projekt jest nierozerwalnie związany ze swoim
uzasadnieniem b iznesowym, ukierunkowuje ono
procesy decyzyjne tak, aby zapewnić, że pozostaje
on zgodny z celami biznesu i oczekiwanymi korzy-
ściami.
Organizacje, które nie przestrzegają rygoru opra-
cowywania Uzasadnienia Biznesowego, mogą się
znaleźć w takiej sytuacji, w której niektóre projekty
realizowane są nawet wtedy, gdy przynoszą nie-
wiele faktycznych korzyści lub gdy mają tylko nie-
wielki związek ze strategią organizacji. Slaba zgod-
ność ze strategią organizacji może także dopro-
wadzić do sytuacji, w której organizacja posiada
portfel projektów o wzajemnie niespójnych lub
duplikujących się celach.
Nawet projekty, których przeprowadzenie jest obo-
wiązkowe (na przyklad w celu spełnienia nowych
wymogów prawnych), wymagaj ą uzasadnienia
wybranej opcji, gdyż może istnieć kilka dostępnych
opcji różn iących si ę kosztami, korzyści ami i ryzykam i.
Ch ociaż uzasadnienie powinno pozostawać ważne,
może się jednak zmien iać. Jest zatem istotne, aby
zapewn ić spójność projektu i zmieniającego si ę
j ego uzasadnienia. Jeżeli z jakiegokolwiek powodu
uzasadnienie projektu straci ważność, powinien on
zostać przerwany. Przerwanie projektu w takich
warunkach jest czymś pozytywnym dla organizacji,
ponieważ jej fundusze i zasoby mogą zostać zainwe-
stowane w inne, bardziej korzystne projekty.
12 I Pryncypia
2.2 KORZYSTANIE Z DOŚWIADCZEŃ
Zespoły projektowe stosujące PRINCE2 uczą się
z wcześniejszych doświadczeń: doświ adczen i a
są wyszukiwane, zapisywane i wykorzystywane
w trakcie całego projektu.
Projekty wiążą się z powołaniem na pewien określo­
ny czas tymczasowej organizacji w konkretnym celu
biznesowym. Wspólną ich cechą jest to, że projekt
zawiera element unikalności taki, który powoduje,
że nie można zarządzać nim, wykorzystując istnieją­
ce kierownictwo liniowe lub jednostki funkcjonalne.
To właśnie ten element unikalności powoduje, że
projekty są wyzwaniem, ponieważ zespół powoły­
wany na czas określony może nie mieć wcześniej­
szych doświadczeń wyniesionych z projektu podob-
nego do tego, jaki ma być podjęty.
Uczenie si ę na podstawie doświadczeń, przenika
całą metodykę PRINCE2:
• Na początku projektu Powinno się dokonać
przeglądu poprzednich łub podobnych projektów
w celu zorientowania się, czy można wykorzy-
stać zgromadzone w nich doświadczenia. Jeżeli
projekt jest pierwszym w swoim rodzaju dla pra-
cowników organizacji, jeszcze bardziej istotne jest
uczenie się od innych, a projekt powinien rozwa-
żyć poszukanie doświ adczeń także na zewnątrz
organizacji.
• W czasie trwania projektu Projekt powinien kon-
tynuować naukę z doświadczeń. Zgromadzone
własne doświadczenia powinny być uwzględniane
we wszystkich raportach i przeglądach. Celem jest
poszukiwanie możliwości wdrażania usprawnień
przez caly czas trwania projektu.
• W czasie zamykania projektu Projekt powinien
przekazać dalej swoje doświadczenia. O ile doświad­
czenia nie spowodują zmian, są tylko doświadcze­
niami zarejestrowanymi (a nie nabytymi).
Obowi ązkiem każdej osoby zaangażowanej w projekt
j est poszukiwanie doświ adczeń, a nie tyko czekanie,
aż ktoś inny ich dostarczy.
2.3 ZDEFINIOWANE ROLE I OBOWIĄZKI
Projekt zgodny z PRINCE2 posiada zdefiniowane
i uzgodnione role oraz obowiązki w swojej struk-
turze organizacyjnej, która uwzględnia interesy
biznesu, użytkownika i dostawcy.
Projekty są realizowane przez ludzi. Najlepsze
planowanie czy kontrola nie pomogą, jeżeli zaan-
gażowano nieodpowiednie osoby, j eżeli nie
zaangażowano właściwych osób lub jeżeli
osoby zaangażowane nie wi edzą, czego się od
nich oczekuje lub czego mogą oczekiwać od innych.
Projekt jest zwykle wielofunkcyjny, może obej-
mować więcej niż jedną organizację i angażować
zarówno zasoby w pełnym jak i w niepełnym
wymiarze czasu pracy. Struktury zarządzania stron
włączonych do projektu będą się prawdopodobnie
różnić - będą posiadać różne priorytety, cele i inte-
resy, których będą chronić. Zwykłe liniowe struktury
kierownicze mogą nie być zaprojektowane ani przy-
stosowane do prac projektowych.
Projekty, aby mog ły si ę udać, muszą posiadać jasną
strukturę zespoł u zarządzania projektem, skł adaj ą­
cą się z określonych i uzgodnionych ról i obowiąz­
ków osób zaangażowanych w proj ekt, oraz muszą
zapewnić środki efektywnej komunikacji pomiędzy
nimi.
Wszystkie projekty posiadają następujących głów­
nych interesariuszy:
• Sponsorów „biznesowych", którzy zatwierdzają
cele i gwarantują, że inwestycja biznesowa przy-
niesie oczekiwaną wartość odpowiadającą ponie-
sionym nakładom;
• „Użytkowników", którzy po ukończeniu projek-
t u użytkować będą produkty w celu osiągn i ęci a
zamierzonych korzyści;
• „Dostawców", którzy zapewniają wymagane
zasoby oraz kompetencje potrzebne w projekcie
(mogą oni pochodzić z wewnątrz lub z zewnątrz
organizacji).
Z tego powodu interesy wszystkich trzech stron
muszą być skutecznie reprezentowane w zespo-
le zarządzania projektem - re prezentacja dwóch
z trzech nie jest wystarczająca. Jeże l i koszty projektu
są większe niż korzyści , projekt poniesie porażkę.
Wszystko j edno, czy rezultaty proj ektu nie speł nia­
ją potrzeb użytkowników lub eksploatacji, czy nie
mogą być faktycznie dostarczone przez dostawców,
porażka jest nieuchronna.
Określona struktura zespołu zarządzania projektem
łączy różne strony we wspólnej realizacji celów pro-
jektu. Zdefiniowana struktura zespołu zarządzania
projektem udziela także każdej zaangażowanej
w projekcie osobie odpowiedzi na pytanie: „Czego
się ode mnie oczekuje?".

2.4 ZARZĄDZANIE ETAPOWE
Projekt zgodny z PRINCE2 jest p lanowany, moni-
torowany i kontrolowany etap po etapie.
Etapy zarządcze dostarczają naczelnemu ki erow-
nictwu punkty kontrolne w ważnych momentach
w trakcie całego projektu. Na końcu każdego etapu,
powinien zostać oceniony stan realizacji projektu,
należy dokonać przeglądu Uzasadnienia Biznesowe-
go i planów w celu upewnienia się, że kontynuacja
projektu jest zasadna oraz należy zdecydować, czy
kontynuować projekt.
Podzial projektu na kilka etapów pozwala zróżnico­
wać zakres kontroli naczelnego kierownictwa nad
projektami w za l eżności od priorytetu biznesowego,
ryzyka i zlożoności projektu. Krótsze etapy pozwa-
l ają na większą kontrolę, podczas gdy dluższe etapy
zmniejszają obciążenia naczelnego kierownictwa.
Planować należy tylko z taką szczególowością, jaka
umożliwi zarządzanie i jest możliwa do przewi-
dzenia. Można zmarnować wiele wysiłku na próby
planowania poza rozsądny horyzont planowania.
Na przyklad szczególowy plan pokazujący, co każdy
czlonek zespolu będzie robił przez następne 12 mie-
si ęcy prawdopodobnie stanie si ę nieaktualny już po
paru tygodniach. Szczegółowy Plan Zespolu na krót-
ki okres oraz ogólny plan na dlugi okres stanowią
bardziej efektywne pod ejście.
PRINCE2 rozwiązuje problem wlaściwego horyzontu
planowania w sposób następujący:
• dzieląc projekt na pewną liczbę etapów zarząd­
czych,
• opracowując ogólny Plan Projektu i szczególowy
Plan Etapu (dla bieżącego etapu),
• planując, delegując, monitorując i kontrolując
proj ekt etap po etapie.
PRINCE2 wymaga co najmniej dwóch etapów
za rządczych: etapu inicjowania i jednego lub wi ęcej
kolejnych etapów za rządczych.
2.5 ZARZĄDZANI E Z WYKORZYSTANIEM
TOLERANCJI
Projekt zgodny z PRINCE2 posiada tolerancje
określone dla każdego z celów projektu, slużą­
ce do ustanowienia granic dla delegowanych
uprawnień.
Pryncypia I 13
PRINCE2 tworzy odpowiedni lad zarządzania pro-
jektem, definiując wyraźne obowiązki związane
z zarządzaniem strategicznym, zarządzaniem
operacyjnym i dostarczaniem produktów projektu
oraz jasno określając odpowiedz i al n ość dla każde­
go szczebla. Odpowi edzia l ność ustanawiana jest
przez:
• Delegowanie uprawn i eń z jednego szczebla
zarządzania na drugi poprzez ustalanie toleran-
cji dla sześciu docelowych wskaźników wykona-
nia planu odpowiedniego poziomu:
• Czas Możliwość wydlużenia lub skrócenia
docelowego terminu wykonania.
• Koszt Możliwość przekroczenia lub
zmniejszenia planowanego budżetu.
• Ja kość Większy lub mniejszy stop i eń
osiągn i ęci a celu ja k ościowego (np. produkt
waży docelowo 300 g, z dozwo l oną
tolerancją od -5 g do + 1O g).
• Zakres Dopuszczalne odchylenia
zaplanowanych produktów (np. wymagania
uzgodnione plus/minus wymagania
pożądane).
• Ryzyko Granice dla zagregowanych ryzyk
związanych z planem (np. efekt kosztowy
zagregowanych zagrożeń powinien
pozostawać pon i żej 10°/o budżetu p lanu)
lub granice dla pojedynczych zag rożeń
(np. zagrożenia dla dziala ń operacyj nych).
• Korzyść Wi ększy lub mniej szy stopień
osiągnięcia docelowej poprawy (np. redukcja
kosztów o 30 - 40o/o).
• Ustanowienie takich mechanizmów sterowania,
że jeżeli przewidywane jest przekroczenie tych
tolerancji, informacja o tym jest natychmiast
przekazywana na następny poziom zarządzania
w celu uzyskania decyzji, jak dalej postępować.
• Ustanowienie takiego mechanizmu nadzoru,
aby każdy szczebel zarządczy mial pewność, że
wyżej wymienione mechanizmy sterowania są
skuteczne.
Wdrożenie „zarządzania z wykorzystaniem tole-
rancji" pozwala na bardzo efektywne wykorzy-
stanie czasu naczelnego kierownictwa, ponieważ
zmniejsza ciężar spoczywający na członkach naczel-
nego kierownictwa bez ograniczania sprawowa-
nej przez nich kontroli, poprzez zapewnienie, że
decyzje podejmowane są na wlaściwym poziomie
. ..
organ1zaq1.
14 I Pryncypia
2.6 KONCENTRAOA NA PRODUKTACH
Projekt zgodny z PRINCE2 koncentruje się
na zdefiniowaniu i dost arczeniu produktów,
a w szczególności na spelnieniu określonych dla
nich wymagań j a kości owych .
Projekt odnoszący sukces to projekt nakierowany
na wynik, a nie na działania. Projekt nakierowany
na wynik to projekt, który uzgadnia i definiuje pro-
dukty projektu przed rozpoczęciem dzialań wyma-
ganych do ich wytworzenia. Zestaw uzgodnionych
produktów określa zakres projektu oraz stanowi
podstawę planowania i kontroli.
Celem projektu jest spełn i enie oczekiwań interesa-
riuszy w zgod n ości z Uzasadnieniem Biznesowym.
Aby to osiąg n ąć, m uszą i stni eć wspólne ustalenia,
co do wymaganych produktów i oczekiwanej ich
jakości. Cel projektu może być interpretowany na
wiele sposobów, o ile nie istnieją jasno sprecyzowa-
ne ustalenia dotyczące produktów, które mają być
wytworzone, oraz kryteria, wedlug których zostaną
one indywidualnie zatwierdzone.
Aby uzyskać taką jasność, projekt zgodny z PRINCE2
korzysta z Opisów Produktów, definiujących prze-
znaczenie, skład, źródło pochodzenia, format, kryte-
ria jakości i metody sprawdzenia jakości d la każdego
produktu. Opisy te stanowią środek do określenia
szacowanych nakladów pracy, wymaganych zaso-
bów, zależności i harmonogramów dzialań.
„Skoncentrowanie na produkcie" wspiera prawie
wszystkie aspekty PRINCE2: planowanie, obowiązki,
raportowanie o statusie, jakość, sterowanie zmia-
nami, zakres, zarządzanie konfiguracją, akceptację/
zatwierdzanie produktów i zarządzanie ryzykiem.
Bez skoncentrowania na produkcie, projekty nara-
żone są na kilka poważnych ryzyk, takich jak: spory
dotyczące akceptacji, poprawki, niekontrolowane
zmiany (tzw. „ pełzanie zakresu "), niezadowolenie
użytkown i ka i niedocenianie dzi ałań związanych
z akceptacją produktów.
2.7 DOSTOSOWANIE DO WARUNKÓW
PROJEKTU
Metodyka PRINCE2 dostosowywana jest do
warunków konkretnego projektu, jego rozm iaru,
złożoności, znaczenia, możl iwości i ryzyka.
Wartość metodyki PRINCE2 polega na tym, że jest to
uniwersalna metodyka zarządzania projektami, którą
stosować można niezależnie od rodzaju projektu,
organizacji, położenia geograficznego czy kultury.
Może być ona użyta w każdym projekcie, ponieważ
metodyka ta jest tak zaprojektowana, aby można ją
było dostosowywać do jego konkretnych potrzeb.
Jeżeli metodyki PRINCE2 nie dostosowano, mało
prawdopodobne jest, aby pracochłonność zarządza­
nia projektem i zastosowane podejście były odpo-
wiednie d la potrzeb projektu. Może to doprowadzi ć
do sytuacji skrajnych, w których albo za rządza si ę
projektem w sposób „mechaniczny" (metodę stosuje
się zgodnie z literą, w pełnym wymiarze, absolut-
nie bez żadnych wątpliwości), albo z drugiej strony
dochodzi do zarządzania „partyzanckiego" (meto-
dyki w ogóle się nie stosuje).
Celem dostosowania jest:
• Zapewnienie, że metodyka zarządzania pro-
j ektem powiązana jest z otoczeniem projektu
(np. dostosowując metodyk ę do procesów biz-
nesowych - które mogą wplywać na projekt
i go wspierać - takich jak zarządzan i e zasobami
ludzkimi, finansami i zakupami).
• Zapewnienie, że mechanizmy sterowania pro-
jektem uwzględniają skalę, złożoność, ważność,
możliwości i ryzyko projektu (np. częstotliwość
i stopień sformalizowania raportowania i prze-
glądów) .
Dostosowanie wymaga, aby Kierown ik Projektu
i Komitet Sterujący po analizie podjęli decyzję odno-
śn ie tego, jak będz i e stosowana metodyka, dla któ·
rej przygotowuj ą wytyczne. Dostosowuj ąc metodykę
PRINCE2, ważne jest, aby pamiętać, że wymaga ona
informacji (niekonieczne dokumentów) i decyzji
(niekoniecznie zebrań/narad).
Aby zapewnić, ie wszystkie osoby zaangażowane
w projekt rozumieją, jak należy stosować PRINCE2,
Dokumentacja Inicjowania Projektu powinna stwier-
dzać, jak dostosowano metodykę do potrzeb tego
konkretnego projektu.
3 Wprowadzenie do tematów PRINCE2

3.1 CZYM SĄ TEMATY?

Temat y PRINCE2 opisują te aspekty zarządza nia
proj ektami, którymi należy ci ągle się zaj mować
w t rakcie projektu. Kierownik Projektu poświ ęcają­
cy n ależytą uwagę tym tematom, spelni swoją rolę
w sposób profesj onalny.
Mocną stroną metodyki PRINCE2 jest sposób i nte-
g racji wszystk ich siedmiu tematów, co osiągn i ęte
zostało dzi ęki specyficznemu dla PRINCE2 potrakt o-
waniu każdego tematu, tj. przez to, że zostaly one
starannie opracowane ta k, aby efektywnie się ze
sobą lączyly.

Tabela 3.1 Tematy PRINCE2

Temat Opis Odpowiada Rozdzi ał

na pytanie
Uzasadnienie Projekt zaczyna się od pomyslu, o którym sądzi się, że ma potencjalną wartość dla Dlaczego? 4
Biznesowe zainteresowanej organizacji. Ten temat PRINCE2 dotyczy sposobu. w jaki ten pomysl
jest przeksztalcany w zasadną propozycję inwestycji dla organizacji oraz tego, jak
zarządzanie projektem utrzymuje koncentrację na celach organizacji w trakcie całego
projektu.
Organi zacja Organizacja sponsorująca projekt musi przekazać związane z nim prace Kto? 5
menedżerom. którzy będą za niego odpowiedzialni i będą nim kierowali aż do
jego zakończenia. Projekty są wielofunkcyjne, więc zwykła funkcjonalna struktura
organizacyjna nie jest dla nich właściwa. Temat ten opisuje role i obowiązki,
w powolanym na pewien czas zespole zarządzania projektem zgodnym z PRINCE2,
niezbędne dla efektywnego zarządzania tym projektem.

Jakość Początkowo pomysł jest rozumiany jedynie w ogólnym zarysie. Ten temat PRINCE2 Co' 6
pokazuje. jak taki zarys jest rozwijany, aby wszyscy uczestnicy uzgodnili jakościowe
atrybuty produktów. które mają być dostarczone, a następnie także. w jaki sposób
zarządzanie projektem zapewni, że uzgodnione wymagania zostaną spełnione.

Plany Projekty PRINCE2 przebiegają zgodnie z szeregiem zatwierdzonych planów. Temat Jak? 7
ten jest uzupełnieniem tematu Jakość opisując kroki wymagane do sporządzenia
planów oraz techniki PRINCE2, które powinny zostać zastosowane. W PRINCE2 Za ile?
plany są dopasowane do potrzeb osób na różnych poziomach organizacji. Są one
podstawą komunikacji i kontroli w trakcie projektu.
Kiedy?

Ryzyko Z projektami związane jest zwykle większe ryzyko niż z ustabilizowanymi działaniami Co, jeżeli? 8
operacyjnymi. Ten temat dotyczy sposobu, w jaki kierownictwo projektu zarządza
niepewnościami zawartymi w planach i w szeroko rozumianym środowisku projektu.

Zmiana Temat ten opisuje, w jaki sposób ocenia się i postępuje z zagadnieniami, które Jaki jest wpływ? 9
mają potencjalny wplyw na dowolny zatwierdzony aspekt projektu Gego plany lub
wytworzone produkty). Zagadnieniami mogą być nieprzewidziane problemy ogólne,
wnioski o wprowadzenie zmiany lub przypadki wad jakościowych produktu.
Postępy Ten temat PRINCE2 dotyczy oceny bieżącej zasadności planów. Wyjaśnia on proces Gdzie teraz 1O
decyzyjny dotyczący zatwierdzania planów, monitorowanie faktycznego wykonania jesteśmy'
oraz proces przekazywania spraw na wyższy szczebel zarządzania w przypadku,
Dokąd
gdy zdarzenia przebiegają niezgodnie z planem. W efekcie, temat Postępy pozwala
zmierzamy?
określić, czy i jak projekt powinien być dalej realizowany.
Czy powinniśmy
kontynuować?
18 I Wprowadzenie do tematów PRINCE2

Procesy PRINCE2 uwzględn i ają chronologiczny prze- 3.3 FORMAT TEMATÓW

bieg projektu, zawi eraj ąc wymieszane ze sobą dzia-
Każdy z rozdzi ałów poświęconym tematom ma
łan i a odnoszące si ę do różnych tematów. W przed-
następującą strukturę:
stawionej tabeli naświetlono załeżniści logiczne,
występujce w każdym temacie oraz podano bardziej • Przeznaczenie Dlaczego temat jest ważny dla
szczegółowe wytyczne pozwalające zwiększyć efek- pomyślnej realizacji projektu?
tywność działań w procesach. Tabela 3.1 wyszcze- • Definicj a tematu Używane określenia i definicje.
gólnia siedem tematów PRINCE2 oraz dotyczące ich • Podejście PRINCE2 do t ematu Specyficzne
rozdzia ły. potraktowanie tego konkretnego aspektu zarzą­
dzania projektem wymagane dla uzyskania pel-
3.2 ZASTOSOWANIE TEMATÓW nej efektywności procesów PRINCE2.
• Obowiązki Specyficzne dla danego tematu
Wszystkich siedem tematów musi zostać zastoso-
główne obowiązki każdej roli PRINCE2.
wanych w projekcie, ale muszą być one dostoso-
wane do skali, charakteru oraz złożoności danego
projektu.
Tematy moż na dostosowywać „poszerzając" łub
„zawężaj ąc" je w sensie formalnym, tj. dla proj ek-
tów złożonych i o wysokim stopniu ryzyka można
wprowadzić dodatkową szc.zegółową dokumentację
i dyscyplinę procesów, podczas gdy zwięzłe wypunk-
towane prezentacje i bardziej nieformalne procesy
mogą być odpowiednie dla prostych projektów
o niskim stopniu ryzyka.
 4 Uzasadnienie Biznesowe
4.1 PRZEZNACZENIE
Przeznaczeniem tematu Uzasadnienie Bizneso-
we jest ustanowienie mechanizmów oceny czy
proj ekt jest (i pozostaje) korzyst ny, wykonalny
i potrzebny, jako środka wsp ierającego podej-
mowanie decyzji o (dalszym) inwestowaniu
w projekt.
Zasadą metodyki PRINCE2 jest to, że projekt musi
mieć ciągłą zasadność biznesową.
Zasadność biznesowa jest powodem podjęcia pro-
jektu. Bez niej nie powinien się rozpocząć żaden
projekt. Jeżeli projekt jest zasadny na początku, ale
traci swoją zasadność w trakcie realizacji, powinien
zostać przerwany lub zmieniony.
W metodyce PRINCE2 zasadność biznesowa udo-
kumentowana jest w Uzasadnieniu Biznesowym
opisującym powody podjęcia projektu oparte na
szacunkowych kosztach, ryzyku oraz oczekiwanych
korzyściach.
Powody podjęcia projektu muszą stale ukierunko-
wywać proces decyzyjny. Kiedy projekty stają w obli-
czu zmian lub ryzyka, analiza ich wpływu powinna
skoncentrować się na Uzasadnieniu Biznesowym,
pamiętając o tym, że projekt jest jedynie środkiem
do osi ągnięcia celu, a nie celem samym w sobie.
Decyzje odnoszące się do Uzasadnienia Bizneso-
wego muszą w sposób nieprzerwany zawsze brać
pod uwagę odpowiedź na pytanie, czy projekt jest
(nadal pozostaje) zasadny. Opiera s i ę o na na tym,
czy projekt jest korzystny (wyważenie kosztów/
korzyści/ryzyka), wykonalny (projekt może dostar-
czyć produkty) i potrzebny (produkty projektu
mogą dosta rczyć korzyści).
Glówny Użytkownik(-cy) odpowiedzialny jest za
określenie korzyści, a następnie za ich zrealizowanie
poprzez wykorzystanie produktów dostarczonych
przez projekt. Przewodn i czący odpowiedzialny j est
za zapewnienie, że korzyści określone przez Glów-
nego Użytkownika(-ów) przedstawiają wartość
odpowiadającą poniesionym nakładom i są zgodne
z_ celami organizacji oraz moż l iwe jest ich osiągn i ę­
oe.
W metodyce PRINCE2 Uzasadnienie Biznesowe
opracowywane j est na samym początku projektu
i utrzymywane przez caly czas jego trwania. Jest ono
formalnie weryfikowane przez Komitet Sterujący
w każdym kluczowym punkcie decyzyjnym, takim
jak ocena końcowa etapu, a korzyści potwierdzane
są w miarę ich osiągania. W niektórych przypadkach
projekt może być zainicjowany z istniejącym już
wcześniej Uzasadnieniem Biznesowym (przekaza-
nym przez kierownictwo organizacji lub programu)
i w takim przypadku zostanie ono doprecyzowane
w trakcie inicjowania.
4.2 DEFINICJA UZASADNIENIA
BIZNESOWEGO
4.2.1 Czym jest Uzasadnienie Biznesowe?
Uzasadnienie Biznesowe przedstawia optymalny
zestaw informacji wykorzystywanych w celu sformu-
lowania opinii czy projekt j est (i pozostaje) korzyst-
ny, wykonalny i potrzebny, a wobec tego czy warto
inwestować w jego realizację.
Komitet Sterujący oraz interesariusze muszą przez
cały czas mieć pewność, że proj ekt pozostaj e zasad -
ny. W metodyce PRINCE2 Uzasadnienie Biznesowe
odgrywa rolę podstawowego testu zasadności pro-
j ektu. Odpowiada ono na pytanie: czy inwestowanie
w projekt jest w dalszym ciąg u oplacalne?
Ponieważ kwestia zasadności jest stale istotna, Uza-
sadnienie Biznesowe nie jest statyczne. Nie powinno
być ono u żywane tylko do pozyskania początko­
wych funduszy dla proj ektu, ale powinno być aktyw-
nie utrzymywane przez cały czas trwania projektu
i ciągle aktualizowane bieżącymi informacjami
o kosztach, ryzyku i korzyści ach.
Przy podejmowaniu decyzji na temat inwestycji,
ważne jest, aby ustalić, jakie korzyści można osią­
gnąć, kiedy, przy jakim poziomie ryzyka i przy jakim
poziomie inwestycji. Projekty powinno się oceniać
pod kątem tego, jak bardzo przyczynią się do reali-
zacji celów organizacji. Analiza taka umożliwia
porównanie j ednego projektu z drugim tak, że
organizacja może wybrać inwestowanie w naj lepszy
zestaw projektów.
22 I Uzasadnienie Biznesowe
4.2.2 Wyniki, rezultaty, korzyści
w metodyce PRINCE2:
• Wynik projektu jest to dowolny produkt specjali-
styczny (materialny lub niematerialny).
• Rezultat jest to efekt zmiany spowodowanej
wykorzystaniem wyników projektu.
• Korzyścią j est mierzalna poprawa osi ągnięta
dzięki rezu ltatowi uznawana przez jednego lub
więcej interesariuszy za zaletę.
Przykład wyniku, rezultatu i korzyści
Wynik: Nowy system sprzedaży.
Rezultat: Zamówienia są przetwarzane szybciej
i dokladniej.
Korzyści:Koszty zostały zredukowane o 1Oo/o,
ilość zamówi eń wzrosła do 15%, a roczne docho-
dy wzrosly o 10%.
Ponieważ rezultaty i korzyści z projektu są często
możliwe do osiągnięcia dopiero po jego zakończe­
niu, bardzo latwo jest niestety projektom skoncen-
trować się wylącznie na wytwarzaniu produktów
(wyników). Powiązanie wyników z rezultatami i ko-
rzyściami powinno być jasno określone i uwidocz-
nione wszystkim zaangażowanym stronom, bowiem
w przeciwnym wypadku pierwotne przeznaczenie
projektu może zostać zagubione.
Zml•ny
bftnesowe
Efekty ubo<tn~
I kon1ekwt'ocjt' Kotzy.kl
Rysunek 4. 1 Powiązanie pomiędzy wynikami,
rezultatami i korzyściami
4.2.3 Rodzaje Uzasadnienia Biznesowego
Przyczyny podejmowania projektów różnią się bar-
dzo i w dużej mierze wynikają z warunków, w jakich
są podejmowane. Ze specyfiki projektu wyn i kną
cele, które będą używane do zweryfikowania atrak-
cyjności projektu, a następn ie d o potwierdzenia, że
produkty projektu spe lniły te cele. Cele t akie będą
mierzone w różny sposób w zależności od rodzaju
projektu. Przykladowe rodzaje projektów to:
• projekt obligatoryjny,
• projekt realizowany nie dla zysku (ang. not-for-
profit project ),
• projekt ewoluuj ący,
• projekt realizowany w środowisku klient/dostawca,
• projekt rea lizowany przez w iele organizacji.
Niektóre z tych projektów można m ierzyć g łównie
„zwrotem z inwestycji" (ang: return on investment,
ROI), ale inne (szczególnie projekty obligatoryjne
lub te rea lizowane nie dla zysku) można mierzyć
innymi korzyścia mi niefinansowymi.
Niezależnie od rodzaju używanej miary, pozostaje
pytanie: czy dla t ego poziomu inwestycj i, przewi-
dywane korzyści są większe, bardziej potrzebne
i latwiejsze do osiągnięcia niż w przypadku innych
dostępnych rozwiązań? Więcej informacji szcze-
gólowych na temat tego, jak warunki projektu
wp lywaj ą na Uzasadnienie Biznesowe, znajduj e s i ę
w Rozdziale 19.
4.3 PO D EJŚCI E PRINCE2 DO
UZASADNIENIA BIZNESOWEGO
W metodyce PRINCE2, Uzasadnienie Biznesowe jest
opracowywane na początku projektu, ut rzymywane
przez cały czas trwania projektu, podlega formalnej
weryfikacji przez Komitet Sterujący w kluczowych
punktach decyzyjnych, takich jak oceny końcowe
etapu, oraz jest potwierdzane przez cały okres
uzyskiwania korzyści.
W tym kontekści e:
• Opracować - znaczy uzyskać wlaściwe informa-
cje, na podstawie których można podejmować
decyzje;
• Weryfikować - znaczy ocenić czy projekt (w dal-
szym ciągu) oplaca się;
• Utrzymywać - oznacza aktualizować
Uzasadnienie Biznesowe, uwzględniając faktyczne
koszty i korzyści oraz bieżące prognozy dotyczące
kosztów i korzyści;

Przed Etap
Kolejny ctap(·y) realizacyjny(·•)
p rojektem inicjowania
/j.
Weryfikuj zarys Weryfikuj
Uzasadnienia szczególowe
Biznesowego Uzasadnienie
Biznesowe
Opracuj
Uzasadnienie Biznesowe
Rysunek 4.2 Ścieżka opracowywania Uzasadnienia Biznesowego
• Potwierdzić znaczy ocenić, czy zamierzone
korzyści zostaly (lub zostaną) zrealizowane.
Potwierdzenie korzyści będzie miale zwyk le
miejsce po zakończeniu projektu.
Uzasadnienie Biznesowe pozostaje w centrum
każdej oceny wpływu ryzyka, zagadnień i zmian
poprzez stawianie pytania: w jaki sposób t o ryzyko,
zagadni enie c.zy zmiana wpłyn i e na zasadność Uza-
sadnienia Biznesowego oraz cele biznesow e i o cze-
kiwane korzyści?
4.3.1 Opracowywanie Uzasadnienia
Biznesowego
W metodyce PRINCE2 za Uzasadnienie Biznesowe
odpowiada Przewodniczący. Nie oznacza to koniecz-
nie, że Przewodniczący sam opracowuje Uzasad-
nienie Biznesowe, a raczej, że Przewodniczący jest
odpowiedzialny za zapewnienie, i ż Uzasadnienie
Biznesowe zostanie opracowane i zatwierd zone.
Opracowanie Uzasadnienia Biznesowego może być
zlecone na przykład analitykowi bi znesowemu czy
nawet Kierownikowi Projektu. W niektórych przy-
padkach kierownictwo programu dostarczy zatwier-
dzone Uzasadnienie Biznesowe j ako część Założeń
Projektu. Nieza l eżnie od tego, komu powierzono
zadanie opracowania Uzasadnienia Biznesowego,
ważne jest, aby zagwarantować, by osoby t e miały
odpowiednie wymagane umiejętności biznesowe
(na przykład rozumiały różnicę pomiędzy progno-
zowanymi przepływami pieniężnym i, rachunkiem
zysków i strat oraz bilansem). Jeżeli t ak nie jest,
wtedy Komitet Sterujący powinien rozważyć skorzy-
stanie z Nadzoru Projektu w celu pomocy w opraco-
waniu Uzasadnienia Biznesowego.
Uzasadnienie Biznesowe I 23
Potwierdt Potwierdź Potwierdt
korzyki korzyki korzyki
V V V
Ostatni etap
Po projekcie
realizacyjny
/j.
Weryfikuj
uaktualnione
Uzasadnienie
Biznesowe
Utrzymuj
Uzasadnienie Biznesowe
Zarys Uzasadnienia Biznesowego wywodzi się ze
zlecenia przygotowania projektu. Opracowywany
j est w przedprojektowym procesie Przygotowanie
Projektu w celu uzyskania w procesie Zarządzanie
Strategiczne Projektem zezwolenia Komitetu Steru-
jącego na zainicj owanie projektu.
Szczegółowe uzasadnienie Biznesowe wywodzi się
z zarysu Uzasadnienia Biznesowego, Planu Proj ek-
tu (koszty, terminy, produkty) i Rejestru Ryzyk. Ze
względu na informacje potrzebne do opracowania
Uzasadnienia Biznesowego, jego rozwój będzie miał
charakter iteracyjny. Musi istn i eć początkowe uza-
sadnienie, aby rozpocząć proj ekt, ale dopóki projekt
nie zostanie zaplanowany szczegó łowo, zarys Uza-
sadnienia Biznesowego oparty jest na kosztach i ter-
minach, które są w najlepszym razie przybliżone .
Kiedy koszty i terminy są lepiej zrozumiałe, może to
zwiększyć lub zmniejszyć korzyści, potrzebę i wyko-
nalność proj ektu, a wobec tego może zmien ić się
formuła realizacji projektu, prowadząc do zmiany
planów.
4.3.2 Weryfikowanie i utrzymywanie
Uzasadnienia Biznesowego
Uzasadnienie Biznesowe ukierunkowuje ca ły pro-
ces decyzyjny, zapewn i ając, że projekt pozostaje
zasadny oraz będzi e można osiągnąć cele biznesowe
i oczekiwane korzyści.
Aby ukierunkować proces decyzyjny, Uzasadnienie
Biznesowe pow inno być poddane przeglądowi :
• Na końcu procesu Przygotowanie Projektu - przez
Komitet Sterujący w celu wydania zezwolenia na
inicjowanie projektu w oparciu o rozsądne
uzasadnienie.
24 I Uzasadnienie Biznesowe
• Na końcu procesu Inicjowanie Projektu - przez
Komitet Sterujący w celu wydania zezwolenia na
rea l izację proj ektu.
• Jako część każdej oceny wpływu wszystkich
nowych czy zaktualizowanych zagadnień lub
ryzyk - przez Kierownika Projektu.
• W powiązaniu z Planem Nadzwyczajnym - prze~
Komitet Sterujący w celu wydania zezwolenia na
rea l izację skorygowanego etapu oraz kontynu-
acj ę projektu.
• Na końcu każdego etapu - przez Kierownika
Projektu, aby określić, czy nie należy zaktualizo-
wać kosztów, terminów, ryzyk lub korzyści.
• Na końcu każdego etapu - przez Komitet
Sterujący w celu wydania zezwolenia na rea liza-
cję następnego etapu i kontynuację projektu.
• W trakcie ostatniego etapu - przez Kierownika
Projektu, aby ocen i ć wykonanie projektu
w porównaniu z postawionymi mu wymaga-
niami oraz prawdopodobieństwo, że rezultaty
dostarczą oczekiwanych korzyści.
• Jako element przeglądu korzyści - (realizowa-
nego zwykle przez kierownictwo organizacji lub
programu) w celu określe nia, j ak wiele korzyści
osiągnięto dz i ęki rezultatom projektu.
Przewod ni czący odpowiedzialny jest za upewnienie
interesariuszy projektu, że projekt pozostaje przez
cały czas potrzebny, wykonalny i korzystny. Aby to
stwierdzić, Przewodniczący nie powinien polegać
wyłącznie na ocenach końcowych etapów i powi-
nien korzystać z pomocy Nadzoru Projektu.
Sekcja dotycząca oceny inwestycj i w Uzasadnieniu
Biznesowym jest dla Komitetu Sterującego źródłem
informacji pozwalających zweryfikować, czy Uzasad-
nienie Biznesowe usprawiedliwia wydanie zezwole-
nia na realizację łub kontynuację projektu.
Przykład niezweryfikowanego Uzasadnienia
Biznesowego
Proj ekt wybudowania atrakcji t urystycznej
w Londynie uzasadniono możl iwością przycią­
gnięcia 12 milionów zwiedzających w pierwszym
roku jej działania. Przewidywana liczba zwiedza-
jących określała przychody z wystawy i w sytu-
acji, gdy zespół projektowy znalazł się pod presją
wybudowania „wystawy klasy światowej", usta-
lono budżet projektu na poziomie progu ren-
towności projektu przy 11 milionach zwiedzają­
cych. Prognozowane 12 milionów zwiedzaj ących
stanowiło niesprawdzone założen i e, znacznie
zawyżone w stosunku do faktycznego 4,5 milio-
na zwiedzaj ących. W kategoriach wyniku pro-
jektu odniósł on sukces - wystawę otworzono na
czas, nie przekroczono budżetu kosztów o wię­
cej niż 5% i wykonano wszystkie żądane obiekty
(tak, że spełniono kryteria akceptacji). Jednakże
dużo mniejsza liczba zwiedzających znacznie
ograniczyła przychód, co oznaczało, że koniecz-
na dotacja rządowa wzrosła z 399 milionów
do 628 milionów f untów. Była to wielka kata-
strofa komercyjna i w zakresie public relations,
pokazująca, że zrealizowanie projektu na czas,
w ramach budżetu i zgodnie ze specyfikacją, ale
opartego na błędnych założeniach co do korzy-
ści, niweczy pomyślną reali zację projektu.
4.3 .3 Potwierdzanie korzyśc i
Podejście do potwierdzania korzyści polega na:
• określeniu korzyści;
• wybraniu obiektywnych miar, które wiarygodni e
dowiodą osiągnięcia korzyści;
• zebraniu miar i wielkości odniesienia (wzg l ę­
dem których stopień poprawy będzie oceniony
liczbowo);
• zadecydowanie, j ak, kiedy i kto dokona pomia-
rów korzyści.
Główny U żytkownik(-cy) określa korzyści i ponosi
odpowiedzialność za wykazanie kierownictwu
organi zacji lub programu, że prognozowane
korzyśc i , na których opierała się akceptacja pro-
jektu, zostały fa ktycznie os i ągn i ęte. Może się
z tym wiązać zaa ngażowan i e poza okres trwania
proj ektu, pon i eważ prawdopodobne j est, że wiele
korzyści zostanie osiągniętych dopiero po zakoń ­
czeniu projektu.
Oznacza to pewien dylemat, ponieważ, kiedy
nastąpi zamknięcie, „ tymczasowa organizacja"
zostaje rozwiązana wraz z jej struktu rą (a w szcze-
gólności wraz z f inansowaniem i zasobami), zatem
nie mogłaby wykon ać żadnych pomiarów korzyści.
Metodyka PRINCE2 rozwiązuje ten dylemat defi-
niując Plan Przeglądu Korzyści . Plan Przeglądu
Korzyści projektu korzysta ze szczegółowego Uza-
sadnienia Biznesowego, aby określić zakres, termi-
ny oraz obowiązek przeprowadzenia pewnej liczby
przeglądów w oparciu o terminy pojaw iania się
i charakter oczekiwanych korzyści.

Domyślnie to Przewodniczący odpowiedzialny jest
za zapewnienie, że przeglądy korzyści są zaplano-
wane i przeprowadzone, ale w pewnych przypad-
kach nie zawsze tak będzie:
• Dla projektów w ramach programu, Plan
Przeglądu Korzyści w projekci e może zostać
opracowany i wykonany przez program, ponie-
waż jedną z ról programu jest koordynowanie
osiągania korzyści z jego projektów.
• Jeżeli w organizacji istnieje centrum doskonało­
ści lub jakaś forma jednostki monitorującej wyni-
ki, może ona podjąć się obowiązku pomiarów
korzyści uzyskiwanych ze wszystkich projektów
realizowanych przez tę organizację.
• Dla pomiarów możl iwych dopiero po zakończeniu
projektu, odpowi edzia l ność za przeg l ądy korzyści
przeniesiona będzi e, kiedy projekt już się skończy,
z Przewodniczącego na kierown ictwo organizacji
lub programu (pon i eważ przeglądy będą musialy
być f inansowane i korzystać z zasobów).
Plan Przeglądu Korzyści jest najpierw opracowy-
wany przez Kierownika Projektu podczas etapu
inicjowania i jest przedkładany przez niego Komi-
tetowi Sterującemu do zatwierdzenia, aby uzyskać
zezwolenie na realizację projektu. Jeżeli kierow-
nictwo organizacji lub programu ma zarządzać lub
uczestniczyć w przeglądach korzyści, Komitet Ste·
rujący może potrzebować akceptacji kierownictwa
organizacji lub programu. Plan Przeglądu Korzyści
aktualizowany jest pod koniec każdego etapu przez
uwzględnienie faktycznie osiągniętych korzyści,
a dla pozostalych do przeprowadzenia przeglądów
sporządzany jest zrewidowany plan, niezależnie od
tego, czy będą one przeprowadzane w trakcie trwa-
nia projektu, czy po jego zakończeniu.
Ponieważ Planem Przeg lądu Korzyści może zarzą­
dzać kierownictwo projektu, organizacji lub progra-
mu, metodyka PRINCE2 zaleca, aby byl on trakto-
wany jako plan od rębny od Planu Proj ektu i Planów
Etapów.
Korzyści , które zm i erzyć można w czasie t rwania
projektu, powinny być raportowane przez Kierowni-
ka Proj ektu w Raporcie Końcowym Etapu. Wszelkie
korzyści rezydualne powinno się ponownie przeana·
l i zować, a ich prognozy zaktua l izować w ramach
procesu Zarządzanie Końcem Etapu.
Poprojektowe przeglądy korzyści wiązać się będą
z tym, że kierownictwo organizacji lub programu
uczyni Głównego Użytkownika(-ów) odpowie·
dzialnym(-i) za dostarczenie dowodów na to, jak
Uzasadnienie Biznesowe I 25
poszczególne im przypisane korzyści zostaly osią­
gnięte w porównaniu z korzyściami obiecywany-
mi przy uzasadnianiu kosztów i ryzyka projektu,
kiedy zezwolono na jego realizację. Poprojektowe
przeglądy korzyści obejmą także przegląd osiągów
produktów projektu w eksploatacji i określą, czy
wystąpily jakieś efekty uboczne (korzystne lub nie-
korzystne), które mogą dostarczyć doświadczeń uży­
tecznych dla innych projektów.
4.3.4 Zawartość Uzasadnienia
Biznesowego
Uzasadnienie Biznesowe powinno opisywać powody
podej mowania projektu w oparciu o szacunkowe
koszty, ryzyko i oczekiwane korzyści . Zwykle zawie-
ra ono:
• podsumowanie,
• powody podj ęcia projektu,
• moż l iwe rozwiązan ia biznesowe,
• oczekiwane korzyści,
• przewidywane niepożądane skutki,
• terminy,
• koszty,
• ocenę inwestycji,
• glówne ryzyka.
Opis Produktu dla Uzasadnienia Biznesowego
znajduje się w Dodatku A. Poniżej przedstawiono
wytyczne, dotyczące zawartości niektórych pozycji
Uzasadnienia Biznesowego.
4.3.4. 1 Powody p odjęcia projektu
Uzasadnienie Biznesowe powinno wyjaśnić powo-
dy, dla któ rych należy powolać projekt. W idealnej
sytuacji powinno być ono powiązane z kontekstem
organizacyjnym i wyjaśniać, w jaki sposób projekt
umożl iwi osiągnięcie celów i real i zację strategii
organizacji.
Powody będą prawdopodobnie określ one w zie·
ceniu przygotowania projektu. Jeże l i nie, na l eży
j e określić. Na przykład powodem przeprowadzki
biura mogą być zmien i ające si ę czynniki demogra·
f iczne lub zwi ększone koszty wynajmu, ponieważ
f irma potrzebuje większego biura niż obecnie albo
musi spelnić nowe wymagania prawne, takie jak
zapewnienie dostępu do biura osobom niepelno-
sprawnym.
26 I Uzasadnienie Biznesowe
4.3.4.2 Możliwe rozwiązania biznesowe
Istnieją
trzy podstawowe możliwe rozwiązania biz-
nesowe dotyczące każdej inwestycji:
• nie robić
nic,
• zrobić minimum,
• zrobić coś ponad niezbędne minimum.
„Nie robić
nic" powinno być zawsze rozwiązaniem
wyjściowym, od którego wychodzi się do oceny
ilościowej pozostałych rozwiązań - różnica pomię­
dzy „nie robić nic" a „zrobić minimum"/„zrobić coś
ponad niezbędne minimum" to korzyść, którą przy-
niesie inwestycja.
Analiza każdego rozwiązania dostarcza Komi -
tetowi Sterującemu i interesariuszom projektu
wystarczających informacji, aby podjąć decyzj ę,
które rozwiązanie jest dla organizacji najbardziej
wartościowe. Dostarcza odpowiedzi na pytanie:
czy dla danego poziomu inwestycji, przewidywane
korzyści są bardziej potrzebne, zasadne i łatwiejsze
do osiągnięcia n iż w przypadku innego dostępnego
rozwiązania?
Uzasadnienie Biznesowe dla wybranego rozwiąza­
nia powinno być ciągle oceniane pod kątem jego
potrzeby, korzyści i wykonalności, ponieważ nowe
ryzyka i/lub zmiany mogą sprawić, że jedno z pozo-
stałych rozwiązań stanie się bardziej zasadne.
4.3.4.3 Oczekiwane korzyści
Uzasadnienie Biznesowe powinno wyszczegó l niać
każdą korzyść, o której twierdzi się, że osiągnięta
zostanie dzięki rezultatom projektu (dla wybra-
nego rozwiązania biznesowego). Ważne jest, aby
określić bieżący stan każdej korzyści w kategoriach
wymiernych tak, aby można było ocenić mierzalną
poprawę po zakończeniu projektu. Uzasadnienie
Biznesowe powinno określić, jak i kiedy można
przeprowadzić pomiary stopnia poprawy. Na przy-
kład jedną z korzyści z przeniesienia biura mogłoby
być zaoszczędzenie kosztów prowadzenia konfe-
rencji w hotelach, ale tylko wtedy, gdy nowa sie-
dziba ma więcej sal konferencyjnych niż obecna.
Korzyści mogą być finansowe i pozafinansowe
(czasami określane jako zamienne i niezamien-
ne na pieniądze). Niezależnie od tego, czy są to
korzyści finansowe czy pozafinansowe, powinny
być one:
• zgodne z celami i strategią organizacji,
• powi ązane z wynikami i rezultatami projektu,
• określ one i l ościowo (z tolerancją),
• mierzalne,
• przypisane komuś, kto za nie odpowiada.
Jasno określona odpowiedzialność za korzyści,
zbiorowa i indywidualna, j est kluczowym wymo-
giem pomyślnej real izacji korzyści . Główny U żyt­
kownik(-cy) odpowiedzialni są za zbiór korzyści
w ich konkretnych dziedzinach, ale odpowiedzial-
ność za poszczególne korzyści powinna zostać
przypisana odpowiedniej osobie, najlepiej komuś
z grupy użytkowników, na których te korzyści
wpłyną.
Lista oczekiwanych korzyści wpłynie na zestaw pro-
duktów, które dostarc.zy projekt. Projekt nie powi-
nien obejmować żadnych produktów, które bezpo-
średnio czy pośrednio nie umożliwiają osiągnięcia
poszukiwanych korzyści. Wiązanie produktów
z rezultatami, a następnie z korzyściam i pomaga
w podejmowaniu decyzji w planowaniu i kontroli
projektu. Powią zanie takie pozwala podejmować
decyzje na podstawie ich wpływu na realizację
oczekiwanych korzyści, czyli na podstawie uzasad-
nienia podjęcia projektu.
Kiedy tylko to możliwe, korzyści powinny być wyra-
żone w sposób konkretny. Główny Użytkownik lub
Przewodniczący mogą określić w iele korzyści jako
niematerialne (na przykład „bardziej zadowolony
personel"). Warto poczynić wysiłek i pomyśleć wni-
kliwie o korzyściach niematerialnych, żeby zoba-
czyć, czy można j e wyrazić w sposób mierzalny.
W tym przypadku „bardziej zadowolony personel"
może oznaczać mniejszą rotację pracowników i/lub
mniej zwolnień lekarskich z powodu stresu. W obu
tych przypadkach można to przeliczyć na prawdo-
podobne oszczędności pien iężne.
Ilościowe wyrażenie korzyści pozwala ustalić tole-
rancje korzyści (np. 1O- 150fc> wzrost sprzedaży),
a mierzalność korzyści zapewnia możliwość ich
udowodnienia. Jeżeli proj ekt obejmuje korzyści,
których nie można udowodnić, niemożliwa jest
wtedy ocena, czy projekt:
• odn i ósł sukces,
• dostarczył wartość odpowiadaj ącą poniesionym
nakładom,
• powinien zostać zainicjowany.
Istnieje wiele sposobów weryfikacji oczekiwanych
korzyści. Na przykład można użyć analizy wrażliwości
w celu określenia, czy Uzasadnienie Biznesowe jest
w dużym stopniu uzależnione od konkretnej korzy-
ści. Jeżeli tak jest, może to wpłynąć na planowanie,

monitorowanie i działania kontrolne w projekcie
oraz na zarządzanie ryzykiem, ponieważ należałoby
przedsięwziąć kroki w celu ochrony tej konkretnej
korzyści.
Innym przykładem jest odpowiedź na trzy pytania
na temat osiągania korzyści, tj.: czego naprawdę
oczekujemy, co możemy osiągnąć, jeżeli wszystko
dobrze pójdzie, i jaki może być najbardziej pesy-
mistyczny scenariusz? Na ten ostatni może mieć
wpływ uwzględnienie w kosztach poprawki na
niedokładności oszacowania, zmiany i ryzyka. Ana-
liza ta zwykle ujawnia, czy oczekiwania dotyczące
korzyści są rozsądne, czy może przesadnie opty-
mistyczne. Wynik tej analizy może doprowadzić
do zrewidowania decyzji o rozpoczęciu real izacji
projektu, co z kolei stanowiłoby podstawę do usta-
lenia ja k ich ś tolerancji korzyści .
Po określen i u korzyści, na l eży opisać
w Planie
Przeg l ądu Korzyści dział ania mające na celu usta-
nowienie i przeprowadzenie pomiarów korzyści.
4.3.4.4 Przewidywane niepożądane skutki
Niepożądany skutek to rezultat postrzegany jako
negatywny przez jednego lub więcej interesariuszy.
Niepożądane skutki są faktycznymi konsekwen-
cjami jakiegoś działania, podczas gdy z definicji
z ryzykiem jest związana jakaś niepewność co do
tego, czy się ono zmaterializuje.
Na przykład decyzja o połączeniu dwóch części
organizacji w nowej siedzibie może przynieść
korzyści (np. lepsza wspólna praca), koszty (np.
rozbudowa jednej z dwóch siedzib) i niepożądane
skutki (np. spadek wydajności produkcji w czasie
łączenia). Wszystkie te aspekty muszą być rozwa-
żone i oszacowane jako część oceny
inwestycji.
4.3.4.5 Terminy
Kierownictwo organizacji łub programu będzie
ch ciało wi edzieć:
• W j akim okresie będą ponoszone koszty pro-
j ektu?
• Na jakim okresie oparta będzie analiza kosztów
i korzyści?
• Kiedy organizacja może się spodziewać osi ągnię­
cia korzyści?
• Jaka jest najwcześniejsza/najpóźniejsza realistycz-
na data rozpoczęcia projektu?
Uzasadnienie Biznesowe I 27
• Jaka jest najwcześniejsza/najpóźniejsza realistycz-
na data zakończenia projektu?
Określenie
wymaganych terminów dla projektu
może dopomóc w określeniu tolerancji oraz termi-
nów przeglądów korzyści.
4.3.4.6 Koszty
Uzasadnienie Biznesowe powinno zawierać pod-
sumowanie kosztów wynikających z Planu Projek-
tu wraz z założeniami, na których są one oparte.
W pozycji „Koszty" powinny być także przedsta-
wione szczegóły dotyczące kosztów przyszłej dzia-
łalności operacyjnej i utrzymania oraz sposoby ich
f inansowania.
4.3.4.7 Ocena inwestycji
Na podstawie inf ormacji zawartych w Uzasadnieniu
Biznesowym, możl iwe i konieczne jest porównanie
kosztów wytworzenia, dzi a ła l ności operacyjnej
i utrzymania z wartości ą korzyści w pewnym okre-
sie (często porównanie to nazywane jest oceną łub
ana l izą inwestycji). Okres oceny inwestycji może
obejmować usta l oną l iczbę łat łub czas użytkowa­
nia produktów. Organ z l ecający projekt może mieć
zdefiniowane zasady kalkulacji, określające sposób
oceny inwestycji.
Ocena inwestycji powinna obejmować zarówno
koszty projektu (wytworzenia wymaganych pro-
duktów oraz koszty zarządzania projektem) jak
i koszty przyszłej działalności operacyjnej i utrzy-
mania. Na przykład szacowane koszty przepro-
wadzki biura mogłyby obejmować koszty projektu
związane z samą przeprowadzką, koszty nowych
materiałów biurowych, kary za zerwanie umowy
na świadczenia usług w aktualnej siedzibie i wyższy
czynsz/raty oraz koszty usług w nowym lokum.
4.3.4.8 Główne ryzyka
Z każdaą możl i wością może się wiązać jak iś ele-
ment ryzyka. Wobec tego, aby zweryfikować
„uzasadnienie biznesowe", Komitet Sterujący musi
zrozumieć nie tylko korzyści i koszty projekt u, ale
też ryzyka, które mogą albo zmn i ej szyć/zwi ększyć
korzyści, albo zmniejszyć/zwiększyć koszty.
Uzasadnienie Biznesowe powinno zawi erać zesta·
wienie zagregowanych ryzyk (sugerowane jest,
aby to było w formie sumarycznego profilu ryzy-
ka) i uwypuk l ić główne ryzyka, które wpływać
będą na cele biznesu i korzyści (obejmując w ten
sposób zarówno realizację projektu, jak i przyszłą
28 I Uzasadnienie Biznesowe

eksploatację i utrzymanie). Na przykład ryzyka

Techniki oceny inwestycji przeniesienia biura mogłyby obejmować nieprze·
Techniki oceny inwestycji obejmują: widziane koszty przeprowadzki (np. usuwanie
azbestu) lub wpływ na kontynuację biznesu (np.
Pełne koszty Przeanalizowanie calkowitego
utratę kluczowych pracowników, którzy nie chcie-
kosztu wdrożen i a oraz j akichkolwiek narastają­
liby s i ę przeprowadzić).
cych kosztów eksploatacj i i utrzymania.
Korzyści netto Przeanalizowanie calkowitej
4.4 OBOWIĄZKI
wartości korzyści pomniejszonej o koszty wdroże­
nia i przyszłej działalności operacyjnej obliczone Tabela 4.1 przedstawia obowiązki dotyczące
dla określonego okresu. tematu Uzasadnienie Biznesowe. Więcej szczegó-
lów na temat ról zespołu za rządzania projektem
Zwrot z inwestycji (ROI) Zyski lub oszczędności
i powiązanych z nimi obowiązków przedstawiono
wynikające z inwestycji (równe korzyściom netto
w Dodatkium C.
jeżeli korzyści są wyłącznie finansowe).

Okres zwrotu Obliczenie okresu czasu wymaga-

nego, by zwrot z inwestycji (ROI) „spłacił" sumę
pierwotnej inwestycji.
Zdyskontowany przepływ pieniądza Środek
wyrażania przyszłych korzyści oparty na aktual-
nej wartości pieniądza. Czasami zdyskontowane
przepływy pieniężne obejmują poprawki na ryzy-
ko, ponieważ biznes może nie mieć pewności, że
wszystkie korzyści się zmaterializują.
Aktualna wartość netto Calkowita wartość
zdyskontowanych przyszłych przypływów pienią­
dza minus początkowa inwestycja. Na przyk ład
jeżel i inflacja utrzymuje się na poziomie 6°/o,
wartość pieniądza spada o polowę mniej więcej
co 12 lat. J eżel i projekt prognozuje, że korzyść
w wysokości 500 OOO złotych zmaterializuje się
w roku 12., to będzie ona warta tylko 250 OOO
złotych w dzisiejszej wartości pieniądza.

Analiza wrażliwośc.i Uzasadnienia Biznesowe są

oparte na niepewnych prognozach. W celu okre-
ślenia, jak solidne jest Uzasadnienie Biznesowe,
użyteczne jest zrozumienie związku pomiędzy
uwzględnianymi czynnikami (np. kosztami pro·
jektu, term inami, j akości ą, zakresem, ryzykiem
projektu) a rezultatem (np. kosztami eksploatacji
i utrzymania, korzyści ami biznesowymi i ryzykiem
biznesowym). Analiza wrażliwości przyjmuje takie
odchylenie czynników w niej uwzględnianych,
aby zamodelować stan, w którym wyniki już nie
uzasadniają inwestycji. Na przykład projekt jest
zasadny, jeżeli można go przeprowadzić w ciągu
czterech miesięcy, ale przestaje się opłacać, jeżeli
miałby trwać sześć miesięcy.
 Uzasadnienie Biznesowe I 29

Tabela 4.1 Obowiązki dotyczące tematu Uzasadnienie Biznesowe

Rola Obowiązk i

Kierown ictwo organizacj i Dostarcza zlecenie przygotowania projektu i określa standardy dla opracowania Uzasadnienia
lub programu Biznesowego.
Czyni Glównego Użytkownika(-ów) odpowiedzialnym za zrealizowanie korzyści poprojektowych
umożliwionych przez produkty projektu.

Odpowiada za Plan Przeglądu Korzyści (po zakończeniu projektu).

Przewodniczący Odpowiada za Uzasadnienie Biznesowe przez cały czas trwania projektu.
Odpowiada za Plan Przeglądu Korzyści (przez cały czas trwania projektu), o ile nie zarządza nim
kierownictwo organizacji lub programu.
Nadzoruje opracowanie zasadnego Uzasadnienia Biznesowego, gwarantując, że projekt jest zgodny
ze strategiami organizacji oraz zabezpiecza finansowanie dla projektu.
Główny Użytkown i k(-cy) Odpowiada za określenie korzyści. na podstawie których zatwierdzane jest Uzasadnienie
Biznesowe.
Zapewnia. że określony jest oczekiwany rezultat projektu.
Zapewnia, że projekt wytwarza produkty, które dostarczają pożądane rezultaty.
Gwarantuje, że realizowane są oczekiwane korzyści (wywodzące się z rezultatów projektu).
Na przeglądach korzyści przedstawia zestawienie korzyści faktycznych i prognozowanych.
Główny Dostawca(-cy) Odpowiada za Uzasadnienie(a) Biznesowe dostawcy fjeżeli taki istnieje)- patrz sekcja 19.6.1.1.
Potwierdza, że wymagane produkty mogą zostać dostarczone po oczekiwanych kosztach i są
realizowalne.
Kierownik Projektu Przygotowuje Uzasadnienie Biznesowe na rzecz Przewodniczącego.

Przeprowadza analizę wpływu

wszelkich nowych czy zrewidowanych zagadnień lub ryzyk, które
mogą mieć wpływ na potrzebę, korzyści czy możliwości realizacji zamierzeń projektu w porównaniu
z pierwotną podstawą zatwierdzenia projektu.
Ocenia i aktualizuje Uzasadnienie Biznesowe na końcu każdego etapu zarządczego.

Ocenia i raportuje wykonanie projektu przy zamykaniu projektu.

Nadzór Projekt u Pomaga w opracowaniu Uzasadnienia Biznesowego.
(obowi ązk i ze strony
Weryfikuje i monitoruje Uzasadnienie Biznesowe pod kątem wydarzeń zewnętrznych i postępów
nadzoru biznesu) projektu.
Zapewnia, że projekt pasuje do całościowego programu lub strategii organizacji.
Monitoruje finanse projektu z ramienia klienta.
Zapewnia, że cały czas ocenia się, czy tworzona wartość uzasadnia poniesione nakłady.
Monitoruje zmiany Planu Projektu. aby określić ich wpływ na potrzeby biznesu lub Uzasadnienie
Biznesowe.
Dokonuje przeglądów oceny wpływu potencjalnych zmian na Uzasadnienie Biznesowe i Plan
Projektu.
Weryfikuje i monitoruje Plan Przeglądu Korzyści pod kątem uzgodnienia go z kierownictwem
organizacji lub programu.
Wsparci e Projektu Uzasadnienie Biznesowe powinno posiadać obiekt odniesienia (wersję bazową) i podlegać wobec
tego zarządzaniu konfiguracją. Wsparcie Projektu powinno doradzać Kierownikowi Projektu
na temat wszelkich proponowanych lub faktycznych zmian produktów, które mają wpływ na
Uzasadnienie Biznesowe.
5 Organizacja
5.1 PRZEZNACZENIE
Przeznaczeniem tematu Organizacja jest określ e­
nie i ustanowienie struktury odpowiedzia l ności
i obowiązków w projekcie.
Metodyka PRINCE2 zakłada, że projekt jest reali -
zowany w środowisku klient/dostawca. Przyjmuje,
że istnieje klient, który określi oczekiwany rezultat
i prawdopodobnie zapłaci za projekt oraz dostaw-
ca, który dostarczy zasobów i umiejętności, aby ten
rezultat osi ągnąć.
Każdy projekt potrzebuje efektywnego zarządzan i a
strategicznego, zarządzan ia operacyjnego, kon-
troli oraz komunikacji. Ustanowienie efektywnej
struktury zespołu zarządzania projektem i strategii
komunikacji na początku projektu oraz ich utrzyma-
nie przez cały czas trwania projektu to niezbędne
elementy sukcesu projektu.
Jedną z zasad metodyki PRINCE2 jest to, że wszyst-
kie projekty muszą mieć zdefiniowaną strukturę
organizacyjną, jednoczącą różne strony we wspólnej
real izacji celów projektu i u możl iwiaj ącą efektywny
ład zarządzan i a projektem i podej mowanie decyzji.
Dobry zespól zarządzania projektem powinien:
• mieć reprezentantów interesów biznesu, użyt­
kownika oraz dostawcy;
• zapewniać odpowiedni ład projektu poprzez
określenie obowiązków dla zarządzania strate-
gicznego, zarządzania operacyjnego i zarz.ądza­
nia dostarczaniem produktów oraz przez jedno-
znaczne określenie zakresu odpowiedzialności
na każdym szczeblu;
• przeprowadzać przeglądy ról w projekcie przez
cały okres jego trwania, aby zagwarantować, że
są one ciągle skuteczne;
• posiadać efektywną strategię zarządzania komu-
nikacją do i od interesariuszy.
5.2 DEFINICJA ORGANIZACJI
5.2.1 Projekt
Metodyka PRINCE2 definiuje projekt jako „organi-
zację tymczasową, powołaną w celu dostarczenia
j ednego lub więcej produktów biznesowych wed ług
uzgodnionego Uzasadnienia Biznesowego". Musi
być ona elastyczna i może wymagać wykorzystania
szerokiego spektrum umiejętności w stosunkowo
krótkim czasie.
5.2.2 Program
Projekt można prowadzić jako odrębną jednostkę
albo w ramach programu powiązanych ze sobą
projektów. Program jest powołaną na określony
czas, elastyczną strukturą organizacyjną stworzoną
w celu koordynowania, zarządzania strategicznego
oraz nadzorowania rea lizacji zbioru powi ązanych
proj ektów i działań, w celu uzyskania rezultatów
oraz korzyści związanych z celami strategicznymi
organizacji. Jego okres trwania jest zwykle dłuższy
niż pojedynczego projektu. Na organizację projektu,
który stanowi część programu, może mieć wpływ
struktura programu oraz jego wymagania dotyczące
raportowania.
5.2.3 Przedsiębiorstwa i organizacje
Projekt może, ale nie musi sta n owi ć część progra-
mu, j ednakże zawsze istnieje w szerszym kontekści e
konkretnej organizacji. Struktury organizacyjne
przedsiębiorstw mogą być różne, zaczynając od
„tradycyjnych" struktur funkcjonalnych, w których
pracownicy zorganizowani są według rodzaju pracy
(na przykład: marketing, finanse, sprzedaż itd.,
gdzie istnieją jasne linie podległości służbowej), po
organizacje projektowe, w których normą jest praca
z zespołami projektowymi, z różnymi odmianami
pośrednimi pomiędzy tymi dwoma biegunami.
5.2.4 Role i stanowiska pracy
W celu zapewnienia el astyczności oraz zaspokoje-
nia potrzeb różnych środowi sk i projektów o różnej
wielkości, metodyka PRINCE2 nie definiuje sta-
nowisk zarządczych, które mają być przydzielane
pojedynczym osobom. Definiuje natomiast role,
z których każda określona jest przez związany z nią
zestaw obowiązków. Role mogą być dzielone lub
łączone zgodnie z potrzebami projektu, ale zwią ­
zane z nimi obowiązki zawsze muszą zostać komuś
przydzielone. Przy łączeniu ról powinno się wziąć
pod uwagę, czy nie istnieje konflikt obowiązków,
34 I Organizacja
czy jedna osoba ma możliwości podjęcia się połączo­
nych obowiązków i czy w rezultacie nie powstanie
j akieś wąskie gardło.
5.2.5 Trzy strony interesów w projekcie
Zasada metodyki PRINCE2 posiadania zdefiniowa-
nych ról i obowiązków stwierdza, że projekt zgodny
z PRINCE2 zawsze będzie miał trzy podstawowe
kategorie interesariuszy i że interesy tych trzech
stron muszą zostać zaspokojone, jeżeli projekt ma
odnieść sukces. Rysunek 5.1 pokazuje trzy podsta-
wowe strony interesów, które tworzą Komitet Ste-
rujący. Metodyka PRINCE2 zaleca, aby w celu zapew-
nienia kompletnej reprezentacji interesów stron,
w Komitecie Sterującym zawsze były reprezentowa-
ne interesy biznesu, użytkownika i dostawcy.
Biznes
Użytkownik Dostawca
Rysunek 5.1 Trzy strony interesów w projekcie
• Biznes Produkty projektu powinny zaspoka-
jać jakąś potrzebę biznesu, która uzasadnia
zainwestowanie w projekt. Projekt powinien
także dostarczyć korzyść/wartość uzasadnia-
jącą poniesione nakłady. W związku z tym
w Komitecie Sterującym powinien być repre-
zentowany punkt widzenia biznesu, aby
zapewn i ć spełnienie tych dwóch warunków
wstępnych przed rozpoczęciem projektu oraz
by były one dalej spełnian e w trakcie całego
projektu. Ro l ą Przewodn i czącego j est dbałość
o interesy biznesu.
• Użytkownik Metodyka PRINCE2 odróżnia inte-
resy biznesu od wymagań przyszłych użytkow­
ników produktów projektu. Punkt widzenia
użytkownika powinien być reprezentatywny
dla pojedynczych osób łub grup, do których
zastosowanie będą miały niektóre łub wszystkie
z poniższych punktów:
• Będą używać produktów projektu w celu
uzyskania korzyści po zakończeniu projektu.
• Będą eksp l oatować, utrzymywać lub
wspierać produkty projektu.
• Produkty projektu będą miały na nich wplyw.
Obecność użytkownika jest potrzebna, aby
określić pożądane produkty i zagwarantować,
że projekt je dostarczy. Główny Użytkownik(-cy)
będzie reprezentować interesy tych interesariu-
szy w Komitecie Sterującym.
• Dostawca Do wytworzenia produktów projek-
tu potrzebne będą zasoby z pewnymi umiejęt­
nościami. Punkt widzenia dostawcy powinien
być reprezentatywny dla tych, którzy dostarczą
koniecznych umiej ętności oraz wytworzą pro-
dukty projektu. Do wytworzenia produktów
projektu, mogą być potrzebne zarówno zespo·
ty dostawcy wewnętrznego, jak i zewnętrz·
nego. Interesy tych interesariuszy reprezento -
wać będzi e w Komitecie Sterującym Główny
Dostawca(-cy).
Stopień pokrywania się interesów biznesu, użyt·
kownika i dostawcy będzie się zmieniał zależnie od
rodzaju organizacji i projektu. Na przykład jeżeli
projekt korzysta z dostawcy wewnętrznego, to inte-
resy biznesu i dostawcy będą z większym prawdopo-
dobieństwem zbieżne niż w przypadku korzystania
z dostawcy zewn ętrznego.
Należy zauważyć, że w metodyce PRINCE2 używa
się także terminu „klient", zwykle w kontekście
komercyjnej re lacji klient/dostawca. „Klient" może
być zwykle interpretowany jako zbiorowe określe­
nie dla interesów biznesu i użytkownika. Jednakże
przykładem odstępstwa od tej szerokiej reguły jest
sytuacja, gdy organizacja rozwija nowy produkt
do wprowadzenia na rynek. W tym przypadku
interes biznesu pokrywa się z interesem dostawcy,
a „klient" tożsamy jest po prostu z „użytkownika­
mi" . Jednakże nawet tam, gdzie interes użytkow­
nika j est zewn ętrzny dla organizacji sponsorującej
opracowanie produktu, tak jak w powyższym przy·
padku, to również powinien on być w jakiś sposób
reprezentowany - prawdopodobnie przez przedsta·
wicieli sprzedaży/marketingu.
Poza podstawowymi kategoriami interesów biz·
nesu, użytkownika i dostawcy, które powinny być
reprezentowane w Komitecie Sterującym, istnieje
również szersza gama interesariuszy, którzy mogą
wpływać na projekt lub na których projekt wywrze
swój wpływ. lnteresariusze ci mogą być wewnętrzni

lub zewnętrzn i dla organizacji oraz mogą wspierać
projekt, przeciwstawiać si ę mu lub pozostawać obo-
jętni wobec niego. Skuteczne postępowan i e z tymi
interesariuszami jest kluczem do sukcesu projektu
(patrz sekcj a 5.3.5).
5.3 PODEJŚCI E PRINCE2 DO ORGANIZACJI
5.3.1 Poziomy organizacji
Osoby na stanowiskach kierowniczych, które będą
podejmowaly decyzje oraz zobowi ązania, mogą
być zbyt zajęte, aby angażować się ciągle w bieżące
sprawy projektu. Projekty potrzebują jednakże bie-
żącego zarządzania, aby odnieść sukces. Metodyka
PRINCE2 oddziela zarządzan i e strategiczne i zarzą­
dzanie operacyjne projektem od dostarczania pro-
duktów projektu, koncertując się na tych pierwszych
i wykorzystując zasadę zarządzania z wykorzysta -
niem tolerancji.
W st rukturze zarządzania proj ektem wyróżn i ono
cztery poziomy, z których trzy reprezentują zespół
zarządzan i a proj ektem, a czwarty, najwyższy, jest
poza projektem. Rysunek 5.2 przedstawia te cztery
poziomy zarządza nia.
Kierownictwo organizacji lub programu
„
E •
„
j;i Zarządzan ie strateg iczne - Komitet Sterujący
·o
=
"'c Zarządzanie operacyjne - Kierownik Projektu
N
"'
..,.
-o
N
-„
N
•O
a.
"'
Dostarczan ie produktów - Kierownik Zespołu
N
Rysunek 5.2 Cztery poziomy zarządzania
projektem
Cztery poziomy zarządzania to:
• Kierownictwo organizacji łu b programu
Poziom ten nie wchodzi w skład zespołu zarzą ­
dzania proj ektem, ale jego obowiązkiem jest
zlecenie projektu, łącznie z określ eniem osoby
Przewodniczącego oraz zdefiniowaniem toleran-
cji na poziomie proj ektu, w granicach których
będzie pracować Komitet Sterujący. Informacje
te powinny, o ile to możliwe, być zawarte w zle-
ceniu przygotowania proj ektu.
Organizacja I 35
• Zarządzanie strategiczne projektem
Komitet Sterujący odpowiedzialny jest za ogólne
ukierunkowanie i zarządzanie projektem w gra-
nicach wyznaczonych przez kierownictwo orga-
nizacji lub programu. Komitet Sterujący odpo-
wiada za sukces projektu. W ramach strategicz-
nego zarządzania proj ektem Komitet Sterujący
będzie:
• zatwierdzać wszystkie główne plany i zasoby,
• rozpatrywać i stniejące lub przewidywane
odchylenia wychodzące poza tolerancje
etapu,
• zatwi erdzać ukończen i e każdego etapu
oraz wydawać zezwolenie na rozpoczęcie
kolejnego etapu,
• komunikować się z pozostałymi
i nteresa riuszam i.
• Zarządzanie operacyjne
Kierownik Projektu odpowiedzialny j est za
codzienne zarządzanie projektem w grani-
cach wyznaczonych przez Komitet Sterujący.
Podstawowym obowi ązkiem Kierownika
Projektu jest zapewnienie, aby projekt wytwo-
rzy! wymagane produkty zgodnie z ustalonymi
docelowymi wskaźnikami wykonania, określ o­
nymi w kategoriach terminów, kosztów, jakości ,
zakresu, ryzyka i korzyści.
Dostarczanie produktów
Podczas gdy Kierownik Projektu odpowiedzialny
jest za b i eżące zarządzanie projektem, członko­
wie zespołu odpowiedzialni są za dostarczenie
produktów projektu o odpowiedniej j akości,
w granicach określonych terminów i kosztów .
W zależności od wie l kości i stopnia złożoności
projektu, uprawnienia i obowiązek planowania
wytwarzania pewnych produktów oraz zarzą­
dzanie zespo łem specjalistów w celu wytwo-
rzenia tych produktów mogą być delegowane
Kierownikowi Zespołu.
5.3.2 Zespół zarządzania projektem
5.3.2. 1 Struktura zespołu zarządzania
projektem
Zespól zarządzania proj ektem jest tymczasową
strukturą specjalnie zaprojektowaną do zarządza ­
nia projektem aż do j ego pomyśl nego ukończenia.
Struktura ta uwzg l ędnia kanały komunikacji z gre-
miami decyzyjnymi i powinny jej towarzyszyć opisy
ról wyszczególniające: obowi ązki, cele, zakresy
uprawnień, relacje, um iejętności, wi edzę i wymaga-
36 I Organizacja
Kierownictwo organizacji lub programu
Komitet Sterujący
Główny
Przewodniczący
Użytkownik(.cy)
--
------ ---
Nadzór ze strony
--
„ ••• •••• •
Biznesu, Użytkownika
i Dostawcy
•
·.
Kierownik Projektu ••• . , „
········.... ---~---
Kierownik(-cy)
Zespolu(-ów)
Czlonkowie zespołu
Rysunek 5.3 Struk tura zespołu zarządzania
ne doświadczenie, sporządzone dla wszystkich ról
występujących w zespole zarządzania proj ektem.
Rysunek 5.3 przedstawia stru kturę zespolu zarzą·
dzania projektem i powiąza n i a pomiędzy rolami.
Role Przewodniczącego (reprezentującego punkt
widzenia biznesu) i Glównego U żytkowni ka (repre·
zentuj ącego punkt widzenia u żytkown ików) często
mogą być łączon e. W takich przypadkach, aby unik-
nąć konfl iktu interesów, można m i anować dwie
różne osoby do wykonywania obowi ązków Nadzoru
Projektu, jedn ą chron iącą interesy u żytkowni ka
i drugą reprezentującą interesy biznesu.
Niektóre z obowiązków w metodyce PRINCE2 nie
mogą być rea lizowane przez kilka osób (współd zie­
lone) lub delegowane, jeżel i maj ą być efektywnie
w ykonywane. Na przyklad:
• Roli Kierownika Projekt u, jak równ i eż
roli Przewodn i czącego nie można dzie-
l ić. Przewodn iczący nie może być także
Kierownikiem Projektu i projekt nie może
mieć więcej n i ż jednego Przewodniczącego lub
Kierownika Projektu.
• Nie można p rzen ieść na kogoś innego odpo-
wi edzia l n ości za decyzje podejmowane przez
Kierownika Projektu i Komitet Ste rujący.
Metodyka PRIN CE2 dostarcza zarysy opisów ról
w Dodatku C, które t o opisy powinno si ę dostoso-
wać do potrzeb konkretn ego proj ektu i każd ej kon-
kretnej nominacj i.
Główny
Dostawca(-cy)
--- -- -
Obsługa Zmian
__
._··~·~---- D W zespole zarządzania projektem
Wsparcie Projektu D Ze strony klienta
Ze strony dostawcy
•••• •• • • •
Linie podleg łości
- --
•• •• ••
Obowiązki Nadzoru Projektu
Linie wsparcia/pomocy
proj ek tem
5.3.2.2 Komitet Sterujący
Przewodn i czący, Glówny Użytkowni k(-cy)
i Główny{-i ) Dostawca(-cy) stanowią łącznie
Komitet Sterujący. Komitet Sterujący posiada
uprawnienia i ponosi odpowi edzialność za projekt
zgodnie z instrukcj ami (początk owo zawartymi
w zleceniu przygotowania projektu) wydanymi
przez kierownictwo organizacji lub progra mu.
Metodyka PRINCE2 określa obowiązk i Komitetu
Sterującego, które obej m uj ą:
• Odpowi edzi a l n ość za sukces lub porażkę projektu
w kat egoriach interesów biznesu, u żytkown i ka
i dostawcy.
• Jednolite ukierunkowanie projektu. Pon ieważ
jednym z kluczowych obowiązków Komitetu
Sterującego jest ukierunkowanie Kierownika
Projektu, ważne jest, aby wszyscy członkowie
posiadali j ednolity pogląd, jaki to ma być kierunek.
• Efektywne delegowanie, z wykorzyst aniem
struktury organizacyjnej i mechanizmów stero-
wania PRINCE2 zaprojektowanych w tym celu.
• U łatwi anie integracji zespo łu za rządza nia pro-
jektem z jednostkami f unkcjonalnymi organizacji
real i zującej proj ekt lub organizacji zewnętrznych
uczestn i czących w projekcie.
• Dostarczanie zasobów i wydawanie zezwoleń na
wykorzystanie f unduszy koniecznych dla pomyśl ­
nego ukończenia projekt u.
• Zapewnianie efektywnego podejmowania decyzji.

• Dostarczanie widocznego i trwalego wsparcia
Ki erownikowi Projektu.
• Zapewnienie skutecznej komunikacji zarówno
wewnątrz zespolu proj ektowego, jak i z intere-
sariuszami zewnętrznymi.
Dalsze zalecenia dotyczące tych obowiązków zna-
l eźć można w publikacji OGC Directing Successful
Projects with PRINCE2 (TSO, 2009).
Dobry Komitet Sterujący powinien posi adać cztery
podstawowe cechy:
• Uprawnienia Członkam i Komitetu Sterującego
powinny być osoby posiadające w swych organi-
zacjach uprawnienia wystarczające do podejmo-
wania strategicznych decyzji dotyczących projek-
tu. Ponieważ Komitet Sterujący odpowied zialny
jest za projekt, wybrane osoby muszą posiadać
dostateczne uprawnienia do podejmowania
tych decyzji oraz do zapewnienia projektowi
zasobów, takich jak personel, pien i ądze i sprzęt.
Szczebel zarządzan i a wymagany do wypelniania
tych ról zależny będzie od czynników, takich jak
budżet, zakres i znaczenie projektu.
• Wiarygodność Wiarygodność członków
Komitetu Sterującego wewn ątrz swych organiza-
cji wpływać będzie na ich zdolność do zarządza­
nia strategicznego projektem.
• Zdolność delegowania K luczową części ą rol i
Komitetu Steruj ącego j est zagwarantowanie
tego, by Kierownik Projektu otrzyma ł wystarcza-
jąco dużo „swobody", aby ki erować projektem,
poprzez utrzymywanie aktywności Komitetu
Sterującego na właściwym poziomie. Członkowi e
Komitetu Steruj ącego nie powinni angażować
si ę w szczególowe zarządzanie projektem ani
w specjalistyczne prace projektu.
• Dostępność Członkowie Komitetu Steruj ącego,
którzy spełn iają wszystkie z powyższych kryte-
riów, maj ą niewiel ką wartość dla projektu, jeżeli
nie są dostępni, aby mogli podejmować decyzje
i uk i erunkowywać Kierownika Projektu.
Członkowie Komitetu Sterującego pochodzą czę­
sto z wyższych szczebli zarządzania i ich obowiązki
w Komitecie Sterującym będą dodatkowymi do
ich zwykłych obowi ązków. Koncepcja zarządzania
z wykorzystaniem tolerancji pozwala Kierownikowi
Projektu regu larnie i nformować ich o postępach
projektu i angażować ich w podejmowanie decyzji,
ale tylko w kluczowych punktach projektu.
Częstotl iwość
i poziom szczegółowości komunikacji
wymaganej przez Komitet Sterujący w czasie pro-
Organizacja I 37
jektu powinny być udokumentowane w Strategii
Zarządzania Komun i kacją. Czlonkowie Komitetu
Sterującego mogą wymagać bardziej szczegóło­
wych lub częstszych informacji na początku pro-
jektu. W m i arę postępów projektu i jeś l i Komitet
Sterujący będzie bardziej usatysfakcj onowany tymi
postępami, wymogi dotyczące częstych lub bardzo
szczegó łowych Raportów Okresowych mogą zostać
zlagodzone. Ważne jest, aby dokonywać przeglą ­
dów poziomu i częstotl iwości raportowan ia dla
k ażdego et apu w procesie Za rządzan i e Końcem
Etapu.
Przewodniczący
Chociaż Komitet Steruj ący odpowiedzialny jest za
projekt, Przewodn i czący (wspierany przez G łówn ego
Użytkown i ka(-ów) i Glównego(-ych) Dostawcę(-ów)
jest ostatecznie odpowiedzialny za sukces projektu
i j est głównym decydentem. Komitet Sterujący nie
j est cia łem demokratycznym podejmuj ącym decyzj e
większością g łosów.
Rol ą Przewodn i czącego jest zapewnienie, żeby pro-
jekt koncentrował si ę przez caly okres swego trwa-
nia na osi ąganiu swoich celów i dostarczaniu pro-
duktu, który zapewni osiągnięcie przewidywanych
korzyści. Przewodniczący musi zagwarantować, że
projekt przyniesie wartość uzasadniającą ponie-
sione naklady, zapewn i aj ąc efektywną kosztowo
formułę realizacji projektu, równoważąc potrzeby
biznesu, użytkownika i dostawcy.
Przewodniczący mianowany jest przez kierow-
nictwo organizacji lub programu w przedprojek-
towym procesie Przygotowanie Projektu. Rola
Przewodniczącego powierzana jest jednej osobie,
co zapewnia jednoosobową odpow i edzia ln ość za
projekt. Przewodniczący będzie więc odpowie-
dzialny za wyznaczenie i mianowanie pozostałych
człon k ów zespołu zarządzania proj ektem, łączn i e
z pozosta łymi człon kam i Komitetu Ste r uj ącego.
Jeżeli projekt jest części ą programu, kierownictwo
organizacj i lub programu może m i a nować niektó-
rych lub wszystkich członków Komitetu Ste rujące­
go.
Przez ca ły czas trwania projektu Przewodniczący
odpowiedzialny jest za Uzasadnienie Biznesowe.
Główny Użytkownik
Główny Użytkownik(-cy) odpowiada za określenie
potrzeb użytkowników produktów projektu, za
kontakty użyt kown i ków z zespołem zarządzania
projektem i za monitorowanie, czy przyjęte roz-
38 I Organizacja
wiązanie zaspokajać będzie te potrzeby w ramach
ograniczeń wynikających z Uzasadnienia Bizneso-
wego i dotyczących j akości, funkcjonalności i łatwo-
.# • • •
sc1 uzyc1a.
Rola ta reprezentuje interesy wszystkich tych,
którzy korzystać będą z produktów projektu (włą­
czając w to eksp l oatacj ę i utrzymanie}, tych, któ-
rym produkty pozwo l ą osi ągnąć ich cel lub tych,
którzy wykorzystają produkty w celu dostarczenia
korzyści . Rola Głównego Użytkownika udostępnia
zasoby użytkownika i monitoruje produkty pod
kątem ich zgodności z wymaganiami. Rola ta może
wymagać zaangażowania więcej niż jednej osoby,
aby zapewnić reprezentację interesów wszystkich
użytkowników. Przez wzgląd na efektywność, jed-
na k że, rola ta nie powinna być dzielona pomiędzy
zbyt wiele osób.
Główny Użytkownik(-cy) określa korzyści i wymaga
się od niego wykazania kierownictwu organizacji
lub programu, że przewidywane korzyści, które sta-
nowily podstawę zatwierdzenia realizacji projektu,
zostały faktycznie zrealizowane. Może to się wiązać
z jego zaangażowaniem po zakończeniu projektu.
Główny Dostawca
Główny Dostawca(-cy) reprezentuje interesy osób
projektujących, wytwa rzających, wspomagaj ących,
zaopatruj ących i wd rażających produkty projektu.
Rola ta jest odpowiedzialna za j akość produktów
dostarczanych przez Dostawcę(-ów) i za tech niczn ą
spójność projektu. Będzie ona obejmować dostar-
czanie projektowi zasobów dostawcy i zapewnienie,
by propozycje dotyczące projektowania i rozwoju
produktów byly wykonalne i realistyc.zne.
W większości wypadków Główny Dostawca repre-
zentuje także interesy tych, którzy utrzymywać będą
produkty specjalistyczne projektu po jego zamknię­
ciu, np. utrzymania technicznego i serwisu. Zdarza-
j ą się od tej reg u ły wyjątk i, np. ki edy zewnętrzny
dostawca dostarcza pro dukty klientowi, który
będzie je utrzymywał podczas eksploatacj i - w tym
przypadku interesy słu żb eksploatacji i utrzymania
będzie prawdopodobnie reprezentować Główny
Użytkownik. W rzeczywistości to rozróżnienie nie
jest naprawdę ważne. To, co jest istotne, to fakt, że
interesy eksploatacji, serwisu i wsparcia są reprezen-
towane odpowiednio od samego początku projektu.
Jeżeli to konieczne, kilka osób może być potrzeb-
nych do reprezentowan ia dostawców.
5.3.2.3 Nadzór Proj ektu
Komitet Sterujący odpowiedzialny jest, poprzez
swoją rolę Nadzoru Projektu, za monitorowanie
wszystkich aspektów rea lizacji projektu i produktów
nieza leżn i e od Kierownika Proj ektu.
Członkowi e Komitetu Sterująceg o odpowiedzialni
są za te aspekty Nadzoru Projektu, które są zgodne
z ich obszarami zainteresowania - biznesu, użytkow­
nika lub dostawcy. Jeżel i mają wystarczająco dużo
czasu i odpowiedni poziom umiejętności i wiedzy,
mogą wykonywać sami zadania Nadzoru Projektu,
w innym przypadku mogą mianować inne osoby do
ich wykonywania.
Komitet Sterujący może także wykorzystać innych
człon ków organizacji do podjęcia konkretnych ró l
Nadzoru Proj ektu, np. wyznaczając kierownika ds.
j a kości w organizacji do monitorow ania aspektów
ja k ościowych projektu. Członkowie Komitetu Ste-
rującego odpowiedzialni są za dz i ałania Nadzoru
Projektu odpowiednio do ich obszarów zaintereso-
wania, nawet jeżeli delegują je innym osobom.
Nadzór Projektu nie jest jednak tylko niezależną
kontrolą. Pracownicy zaangażowani w Nadzór Pro-
jektu odpowiedzialni są także za wspieranie Kierow-
nika Projektu, poprzez udzielanie rad i wskazówek
dotyczących takich zagad nień, jak wykorzystanie
standardów organizacji czy właściwego personelu,
który ma być zaangażowa ny w różn e aspekty pro-
j ektu, np. inspekcje albo przeg l ądy j akości.
Kiedy zadania Nadzoru Projektu dzielone są pomię­
dzy członków Komitetu Sterującego i inne osoby,
ważne jest, aby sprecyzować obowiązki każdej
osoby. Każda osoba wyznaczona do roli Nadzoru
Projektu odpowiedzialna jest bezpośrednio przed
członkiem Komitetu Sterującego nadzorującym
odpowiedni obszar zainteresowania i musi być nie-
za leżna od Kierownika Projektu. Komitet Steruj ący
nie powinien przydzi elać żadnych ró l Nadzoru Pro-
jektu Kierownikowi Projekt u.
Pon ieważ do fu nkcji Nadzoru Projektu n a l eży moni-
t orowanie wszystkich aspektów wykonania projektu
i produktów nieza l eżnie od Kierownika Projektu,
powinien on angażować się we wszystkie procesy
PRINCE2.
5.3.2.4 Obsługa Zmian
Kwestią rozważaną przy inicjowaniu projektu
powinno być ustalenie, kto posiada uprawnienia do
akceptacji wniosków o wprowadzenie zmiany czy

odstępstw. Obowiązkiem Komitetu Sterującego jest
udzielenie zgody na każdą potencjalną zmianę przed
jej wdrożeniem. W projekcie, w którym przewiduje
się niewiele zmian, może być rozsądne pozostawienie
tych uprawnień w rękach Komitetu Sterującego. Ale
projekty mogą przebiegać w środowi sku dynamicz-
nym, gdzie możliwe są na przyklad liczne wnioski
o wprowadzenie zmiany początkowo uzgodnionego
zakresu projektu. Może być także potrzebna wiedza
techniczna do oceny potencjalnych zmian.
Komitet Sterujący musi zadecydować zanim pro-
jekt wyjdzie poza etap inicjowania, czy chce dele-
gować pewne uprawnienia do zatwierdzania lub
odrzucania wniosków o wprowadzenie zmiany czy
odstępstw.
Aby ulatwić ten proces, Komitet Sterujący powinien
określić w Strategii Zarządzania Konfiguracją skalę
oceny wagi wniosków o wprowadzenie zmiany.
W za l eżności od znaczenia wniosku, móglby on być
obsłużony przez/poprzez:
• Kierownictwo organizacji lub programu,
• Komitet Sterujący,
• delegowanie Obsłudze Zmian,
• delegowanie Kierownikowi Projektu.
Te delegowane uprawnienia muszą być zapisa-
ne w odpowiednich opisach ról. Dla projektów
w ramach programu, kierownictwo programu
powinno określić poziom uprawnień Komitetu
Steruj ącego, aby mógł on zatwi e rd zać zmiany.
Kierownik Projektu i/lub osoby pelniące delegowa-
ne obowiązki Nadzoru Projektu mogą występować
jako Obsługa Zmian. Więcej informacji na temat
zmian przedstawiono w Rozdziale 9.
Przykład określenia uprawnień Obsługi Zmian
Kierownikowi Projektu udzielono uprawnienia
zatwierdzania zmian w pojedynczych produk-
tach tylko, jeżeli zmiany te:
• kosztowalyby mniej n iż ustalony uprzednio
limit,
• nie spowodują zmian terminów projektu
o więcej niż jeden tydzień,
• nie wymagają żadnych zmian w Opisie
Produktu Końcowego Projektu ani w żadnym
innym produkcie.
W takiej sytuacji wszelkie zmiany, które wycho-
dziłyby poza te granice muszą zostać przekazane
Komitetowi Sterującemu.
Organizacja I 39
5.3.2.5 Wielkość Komi tetu Sterującego
Przewodniczący, wspierany przez Kierownika
Projektu, odpowiedzialny jest za uzgodnienie
odpowiedniej struktury zespołu i dostosowanie jej
do wi el kości, ryzyka i złożoności projekt u. Komitet
Sterujący musi reprezentować wszystkie zaintereso-
wane strony w organizacji i a ngażować wszelkich
zidentyfikowanych dostawców (wewnętrznych
i zewnętrznych).
W dużych projektach, dostosowanie zespolu zarzą­
dzania projektem może oznaczać rozdzielenie ról
PRINCE2 pomiędzy wiele osób - na przykład, moglo-
by być mianowanych kilku Głównych Użytkowników
czy Głównych Dostawców. Dobrą praktyką jest jed-
nakże utworzenie możl iwie najmniejszego Komitetu
Sterującego, który j ednocześn ie reprezentuje wszyst-
kie interesy biznesu, użytkown i ka i dostawcy. Aby
uniknąć powiększania Komitetu Sterującego, można
wykorzystać grupy użytkowników lub dostawców
w celu utrzymania szerokiego zaangażowania kie-
rownictwa wyższego szczebla w tych projektach,
które mają wplyw na duże społeczności użytkowni ­
ków czy dostawców. Grupy te omawiają zagadnie-
nia i ryzyka użytkownika łub dostawcy i przekazują
zalecenia Glównemu Użytkownikowi(-om) lub Głów­
nemu Dostawcy(-om) w Komitecie Sterującym. Jeżeli
wprowadzono grupę użytkowników czy dostawców,
ważne jest określenie na początku, kto ma upraw-
nienia do reprezentowania ich zbiorowego punktu
widzenia i jak to będzi e real izowane. Może być także
wlaściwe mianowanie czlonków tych grup do Nad-
zoru Projektu ze strony użytkownika lub dostawcy;
wiele osób może pełnić rolę Nadzoru Projektu. Kon-
tekst komercyjny będzie miał także wpływ na struktu-
rę organizacyjną projektu (np. jeżeli mianowany jest
naczelny wykonawca).
Rysunek 5.4 pokazuje możliwą strukturę powiązań
w projekcie, która obejmuje grupy użytkowników
i dostawców.
Stworzenie macierzy interesariuszy w odniesieniu
do produktów projektu także pomaga w oddzie-
leniu interesariuszy projektu (których trzeba zaan -
gażować w sprawy projektu w ramach rea lizacji
Strategii Zarządzania Komunikacją) od decydentów
w projekcie (którzy powinni zasiadać w Komitecie
Sterującym) .
Decyzja, czy wlączyć dostawców zewnętrznych do
Komitetu Sterującego, może być kwestią kultury,
może też wynikać z obawy przed udostępnieniem
informacji handlowych lub finansowych.
40 I Organizacja

Komitet Sterujący Grupa

Grupa
Użytkowników Dostawców
Główny
Przewodniczący
Użytkownik

I
Reprezentant
użytkownika
'' I
I
I
I Reprezentant
dostawcy
(obszar 1)
• ••
•• '''
..••··-· I
I I
I
•• •• •• •• •
(obszar 1)

Reprezentant I •••• • Reprezentant

użytkownika dostawcy
(obszar 2) Nadzó r Projektu Nadzór Projektu Nadzór Projektu (obszar 2)
ze strony Użytkownika ze strony Biznesu ze strony Dostawcy

c=J W zespole zarządzania projektem

CJ Ze strony klienta

Ze strony dostawcy

Linie podległości

---
••••••
Obowiązki Nadzoru Projektu

Linie wsparcia/pomocy

Rysunek 5.4 Możliwa struktura powiązań z wykorzystaniem grup użytkowników i dostawców

Wykluczenie ich z procesu Strategiczne Zarządza­
nie Projektem może spowodować opóźn i en i a wyni-
kaj ące z braku zasobów dostawcy do zajmowania
s i ę zmianami i zagadnieniami specjalistycznymi.
Decyzja, jak ten dylemat rozwiązać w p raktyce,
na l eży do Przewod n iczącego.
5.3.2.6 Kierownik Projektu
Kierownik Projektu jest j edyną rolą koncentrującą
si ę na codziennym zarządzan iu projektem. Osoba
ta posiada uprawnienia do prowad zenia proj ektu
w imieniu Komitetu Steruj ącego w ramach ograni-
czeń ustanowionych przez ten Komitet. W środowi­
sku PRINCE2 rola Kierownika Projektu nie może być
dzielona pomiędzy kilka osób - jest to rola jedno-
osobowa.
Ki erownik Projektu pochodzi zwykle z organizacji
klienta, ale mogą istn i eć projekty, w których Ki e-
rownik Projektu pochodzi z organizacj i dostawcy.
Więcej informacj i na temat relacji klient/dostawca
przedstawiono w Rozdziale 19.
Kierownik Projektu odpowiedzialny jest za wszystkie
procesy PRINCE2, poza procesem Zarządzan i e Stra-
t egiczne Projektem oraz mianowaniem Przewodni-
czącego i Kierownika Projektu w przedprojektowym
procesie Przygotowanie Projekt u. Kierownik Projek-
tu deleguje ta kże Kierownikowi(-om) Zespołu(-ów)
odpowi edz i alność za proces Zarządzanie Dostarcza-
niem Produktów.
Kierownik Projekt u zarządza operacyjnie Kierowni-
kami Zespołów i Wsparciem Projektu oraz odpowia-
da za kontakty z Nadzorem Projektu i Komitetem
Sterującym. W projektach, w których żadnej osobie
nie przydzielono roli Kierownika Zespolu, Kierow-
nik Proj ektu odpowiedzialny będzie za bezpośred­
nie kierowanie pracą zaangażowanych członków
zespołu. W proj ektach, w których nie istnieje rola
Wsparcia Projektu, zadania wsparcia także przypa-
dają Kierownikowi Projektu, chociaż mogą być one
rozdzielone pomiędzy czlonków zespolu.
Poniewa ż ro la Kierownika Projektu koncentruje się
na codziennym operacyjnym zarządzani u projek-
tem, obejmuje ona wiele różnych aspektów. Rysu-
nek 5.5 pokazuje n iektóre z nich.
5.3.2.7 Kierownik Zespołu
Podstawowym obowiązkiem Kierownika Zespolu
jest zapewnienie wytworzenia produktów przydzie-

Kierownictwo liniowe
Strategia Zarządzanie kosztami
Praca zespołowa Komunikacja
~
Planowanie _ ___, Kierownik
Jakość
Projektu
Monitorowanie
Potrzeby Potrzeby produktu
utytkownika Zmiany a potrzeby projektu
Rysunek 5.5 Wiele aspektów roli Kierownika
Projektu
lonych mu przez Kierownika Projektu. Ki erownik
Zespolu odpowiada przed Ki erowniki em Projektu
i otrzymuje od niego polecenia.
Rol a Ki erownika Zespo łu może być przydzielona
Kierownikowi Projektu łub innej osobie. Istnieje
w iele powodów, dla których Ki erownik Projektu
może zdecydować się m ianować Kierownikami
Zespołów inne osoby zamiast pełnić tę funkcję
samemu. Może to być wielkość projektu, szczegól-
ne umiejętności specjalistyczne lub wiedza wyma-
gane dla wytworzenia jakichś produktów, lokali-
zacja geograficzna niektórych czlonków zespołu
i preferencje Komitetu Sterującego. Kierownik
Projektu powinien omówić potrzebę wyznaczenia
innych osób do pełnienia funkcji Kierowników
Zespołów z Komitetem Sterującym i, jeżeli to
konieczne, powinien zapl anować istnienie takich
ról na początku projektu w trakcie procesu Przygo-
towanie Projektu lub dla każdego etapu w procesie
Zarządzanie Końcem Etapu.
Metodyka PRINCE2 wykorzystuje Grupy Zadań, aby
przydzielić prace Kierownikom Zespołów lub człon­
kom zespołów. Mogą być one używane formalnie
lub n ieformalnie w za l eżności od potrzeb projektu.
Poza informacjami zaw artymi w Dodatku A, Grupa
Zadań może także obejmować dodatkowo pozycje
takie, jak: koszty zasobów, numery kont, przydzie-
lone zasoby i inne informacje zarządcze. Określ enie
produktów na odpowiednim poziomie pomoże
także nowym Kierownikom Zespołów w zwiększa­
niu swojej efektywności, pon ieważ wyjaśnia, co musi
być wytworzone, a przy określonej częstotliwości
i metodzie raportowania, informacje zwrotne od
Kierownika Zespołu mogą być lepiej kontrolowane.
Organizacja I 41
Jeżeli Ki erownik Zespołu pochodzi z organizacji
dostawcy, może on także pod legać Głównemu
Dostawcy. Ogromnie ważne jest, aby wszelkie takie
powiązania byly dobrze zrozumiane w celu unik-
nięcia konfliktu interesów i podważania autorytetu
Kierownika Projektu.
Struktura zespołu zarządzania projektem nie musi
odwzorowywać liniowych zależności funkcyjnych
czy szczebli władzy, ale przedstawia role w projek-
cie. Kierownik Zespołu na przykład może sprawować
w organizacji funkcję wyższego szczebla zarządza­
nia niż Kierownik Projektu lub może być przedstawi-
cielem wyższego szczebla organizacji zewnętrznego
dostawcy. W kontekście projektu jednakże Kierow-
nik Zespołu podlega Kierownikowi Projektu i przyj -
muje od niego polecenia.
5.3.2.8 Wsparcie Projektu
Wsparcie Projektu n ależy do obowiązków Kierowni-
ka Projektu. J eżel i to wskazane, Kierownik Projektu
może część tych prac del egować roli Wsparcie Pro-
jektu. Delegowanie to może obejmować: świadcze­
nie uslug administracyjnych lub rady i zalecenia na
temat wykorzystania narzędzi za rzą d zania projek-
tem łub zarządzania konfiguracją. Może ono także
pełnić na rzecz projektu specjalistyczne funkcje
zarządcze, takie jak planowanie czy zarządzanie
ryzykiem. O ile funkcja ta nie jest pełniona na pozio-
mie kierownictwa organizacji lub programu, Wspar-
cie Projektu jest zwykłe odpowiedzialne za admi-
nistrowanie wszelkimi procedurami i narzędziami
zarządzania konfiguracją, tak jak to określono
w Strategii Zarządzania Konfiguracją.
Istotne jest podkreślenie, że istnienie roli Wsparcia Pro-
jektu nie jest opcjonalne. Opcjonalne jest wyznaczenie
osoby czy grupy osób do wykonania wymaganych
zadań. Jeżeli nie rozwiązano tego inaczej, rolę Wspar-
cia Projektu pełni domyślni e Kierownik Projektu.
Niektóre organizacje mogą posi a d ać Biuro Projek-
tu (tymczasowe biuro utworzone w celu wspiera-
nia rea lizacji konkretnego projektu) lub podobną
strukturę, która może wypełn i ać część lub ca łość
ro li Wsparcia Projektu. Wi ęcej informacji na temat
wykorzystania biura projektu znajduje się w publi-
kacji OGC Portfolio, Programme and Project Offices
(PJO•).
Role Wsparcia Projektu i Nadzoru Projektu powinny
pozostawać rozdzielone, aby utrzymać nieza l eżność
Nadzoru Projektu.
42 I Organizacja
5.3.2.9 Postępo wa nie ze zmianami skła du
zespołu zarzą dza nia proj ektem
W idealnych warunkach Kierownik Projektu i człon­
kowie Komitetu Sterującego powinni pozostać
w projekcie przez cały czas jego trwania. W prak-
tyce jednakże nie zawsze może to być możliwe
i zespół zarządzania projektem może zmienić
si ę w czasie projektu. Jasno określona struktura
zespoł u, wraz z obszernymi opisami ról wyszczegól-
niającymi obowiązki każdej roli, powinny pomóc
w ograniczeniu zamieszania spowodowanego
zmianami w zespole zarządzania projektem.
Wykorzystanie etapów zarządczych także pozwala na
bezproblemowe przeprowadzenie zmian w zespole
zarządzania projektem. W procesie Zarządzanie Koń­
cem Etapu powinien zostać przeprowadzony prze-
g l ąd ról w projekcie dla następnego etapu. Wyko-
rzystanie Raportów Końcowych Etapów i Planów
Etapów może pomóc w zapewnieniu, że procedura
przekazania obowiązków jest całościowa i dobrze
udokumentowana. Chociaż w idealnych warunkach
Przewodniczący Projektu i Kierownik Projektu powin-
ni pozostać w projekcie przez caly czas jego trwania,
to koniec etapu daje sza nsę na przekazanie roli
w trakcie proj ektu, o ile jest to konieczne.
Przykład zmian w zespole zarządzania projektem
Projekt może zawierać etap zamówień, w czasie
którego wybierany jest dostawca mający wytwo-
rzyć niektóre z produktów projektu. Przed wybo-
rem dostawcy, przedstawiciel wyższego szczebla
z dzialu zaopatrzenia może reprezentować
w projekcie Głównego Dostawcę. Po wyborze
dostawcy i przejściu projektu do etapu rea lizacji,
przedstawiciel wyższego szczebla z organizacji
wybranego dostawcy może zostać dołączony do
zespołu zarządzania projektem, jako Główny
Dostawca.
5.3.3 Praca z zespołem projektowym
5.3.3. 1 znaczenia projektu,
Równoważenie
zespołu i poszczególnych osób
Aby projekt odniósł sukces, potrzebni są ludzie. Nie
wystarczy wprowadzić wymagane procesy i systemy.
Jeżeli ludzie w projekcie efektywnie nie wspólpra-
cują, wtedy szanse na sukces projektu są bardzo
ograniczone. Wiedza na temat różnych rodzajów
osobowości i jak współpracują one ze sobą może
dopomóc Kierownikowi Projektu w stworzeniu
zespołów, które będą skutecznie ze sobą współpra­
cować w czasie projektu.
Różni ludzie mają różne cechy charakteru, a n ie-
które typy osób bardziej się nadają do pewnych ról.
W danym środowisku niektóre połączenia typów
osobowości sprawdzają się lepiej niż inne.
Przykład budowania zespołu przy wykorzysta-
niu różnych osobowości
Niektóre osoby są bardzo towarzyskie i entu-
zjastyczne oraz mają wiele różnych pomysłów.
Inne mają bardziej analityczne umysly, posiadają
umiejętności pracy wymagającej uwagi w szcze-
gółach i zapewnienia, że żadne zadanie nie
zostanie pominięte. Choci aż zwykle nie można
zm i enić charakteru ludzkiego, możl iwy jest taki
dobór członków zespołu, że będzie on stanowił
odpowiednią mieszankę typów osobowości,
umożliwiającą efektywne wykonanie zadań.
Kierownicy Projektu, którzy znają naturalne role
członków zespołu, mogą wykorzystać tę wiedzę
do zbudowania efektywnych zespołów; w pro-
cesie Przygotowanie Projektu, gdy budowany
j est zespól za rządzan i a projektem, a w procesie
Inicjowanie Projektu, gdy dobiera się członków
zespołu . Ważne jest, aby osiągnąć właściwą rów-
nowagę: na przykład zespól składający się tylko
z „pomysłodawców" ryzykuje utratą umiejęt­
ności skupienia się na szczegółach zadań, które
trzeba wykonać. Z drugiej strony, zespól składa­
jący się wyłączn i e z osób „koncentrujących się na
szczegółach " może nie posiadać strategicznego
oglądu cał ego rozwi ązania.
5.3.3.2 Potrzeby szkoleniowe zespołów
projektowych
Na początku projektu członkowie zespołu mogą
potrzebować szkolenia. Może ono obej mować szko-
lenie w zakresie wszelkich procesów i standardów
wykorzystywanych w projekcie (takich jak procedu-
ry zarząd zania konfiguracją, metody zapewniania
jakości, raportowanie postępów i inne obszary wła­
ściwe dla danego projektu) lub może być to wpro-
wadzenie do projektu i jego celów, aby zmotywo-
wać członków zespołu . Członkowie Komitetu Steru-
jącego mogą także potrzebować szkolenia w zakre-
sie swoich ról, obejmującego wyjaśnien i e, czego
się od nich oczekuje oraz procedur potrzebnych do
wypełniania ich obowiązków. Szkolenie na temat

procesów i terminologii metodyki PRINCE2 może być
także konieczne dla Kierowników Zespolów i innych
czlonków zespołu zarządzania projektem.
W trakcie projektu członkowie zespolu mogą także
potrzebować specjalistycznego szkolenia, aby
umożl iwi ć im wykonanie przydzielonych im zada ń.
Kierownik Proj ektu powinien zapewnić wlączen ie
potrzeb szkoleniowych do odpowiednich planów.
5.3.3.3 Zesp oły pracujące w niepełnym
wymiarze czasu
Zespoły projektowe tworzone są na czas trwania
projektu, a następnie powracają do swojej normal-
nej pracy. Kierownik malego projektu może mieć
w zespole członków zespołu pracujących w projekcie
w niepełnym wymiarze swego czasu pracy. Człon ­
kowie zespołu zatrudnieni w n i epełnym wymiarze
czasu częściej są nieobecni i odrywani od pracy niż
członkowie zespołu pracuj ący w pełnym wymiarze,
gdyż jest to tylko część ich normatywnego czasu
pracy. Kierownik Projektu powinien to uwzględnić
przy tworzeniu planu - albo negocjując gwaranto-
waną obecność, albo większą tolerancję.
Jeżelipojedyncze osoby pracują w zbyt wielu pro-
jektach, nie będą efektywne w żadnym z nich,
pomimo wydatkowania dużej energii i wysiłku.
Rozwiązaniem tej sytuacji może być podejmowanie
mniejszej liczby równoległych projektów lub, gdzie
to możliwe, przydzielanie pracowników do projek-
tów w pełnym wymiarze ich czasu pracy w ograni-
czonych okresach czasu.
5.3.4 Współpraca z organizacją
realizującą projekt
5.3.4. 1 Zarzą dzanie liniowe/zarządzanie
f unkcjonaln e
W środowi sku o silnym zarządzaniu funkcjona lnym
Ki erownicy Projektów mogą napotkać trudności
przy zarządzaniu projektami z udz i ałem różnych
pionów funkcjona lnych z powodu n i emożności
uzgodnienia pomiędzy różnym i grupami, kto powi-
nien im przewodzić. W rezultacie Komitet Sterujący
będzie musiał być bardziej zaangażowany w prze-
wodzenie, zarządzanie strategiczne i ustalanie prio-
rytetów prac oraz rozwiązywanie zagadnień. Nie-
zależnie od środowiska Kierownik Projektu będzie
musiał dostosować się i współdziałać z organizacją
realizującą projekt, co będzie miało wpływ na spo-
sób zarządzania członkami zespołu.
Organizacja I 43
Przykład obowiązków Kierownika Projektu
wobec kierownictwa liniowego/funkcjonalnego
Kierownik Projektu może być odpowiedzialny
za przeprowadzenie oceny członków zespołu
w ramach projektu lub może wnieść swój wkład
do oceny przeprowadzanej przez pion funkcjo-
nalny organizacji, któremu podlega oceniany
człon ek zespołu.
Wzajemne zrozumienie i praca w ramach szerszej
organizacji może być dla Kierownika Projektu
wyzwaniem, szczególnie gdy pracuje on w niepeł­
nym wymiarze godzin łub na podstawie kontraktu.
Ustanowienie jasnych mechanizmów sterowania
projektem na jego początku oraz uzgodnienie ich
z Komitetem Sterującym pomoże w zapewnieniu
tego, że Kierownik Projektu rozumie poziom współ­
dzi ałan i a i wsparcia, jakiego może si ę spodziewać
w czasie trwania projektu, i że będzie właściwie
przedstawiony w innych obszarach organizacji reali-
zującej projekt.
5.3.4.2 Centrum doskonałości
Koncepcja centrum doskonałości to koncepcja cen-
tralnej jednostki organizacyjnej, która określa stan-
dardy (takie jak procesy, szablony i narzędzi a) oraz
dostarcza umiejętności, organizuje szkolenia i być
może pełn i funkcję nieza l eżnego nadzoru dla w ielu
projektów.
Przykład centrum doskonałości
Przykładowa organizacja ustanowiła centrum
doskonałości, które zapewnia:
• centralny system gromadzenia dokumentacji
dla wszystkich projektów,
• system zarządzania konfiguracją,
• wiedzę fachową w zakresie technik szaco-
wania,
• porady na temat przygotowywania planów,
• bazę danych historycznych o pracoch łonności
konkretnych działań (miary) i analizę produk-
• •
tywnosci,
• wiedzę fachową i porady w zakresie metodyki
PRINCE2,
• skonsolidowane raporty przedstawiające stan
wszystkich projektów w portfelu.
Centrum doskonałości może być przydatne w sytu-
acji, gdy:
44 I Organizacja
• niedostatki zasobów czy to liczbowe, czy umie-
jętności, utrudniają dostarczenie pracowników
do prowadzenia administracji projektu dla każ­
dego bieżącego projektu;
• istnieje pewna liczba małych projektów o różno­
rodnym charakterze, które indywidualnie wyma-
gają tylko ograniczonego wsparcia od Wsparcia
Projektu;
• istnieje duży program wymagający koordynacji
pojedynczych projektów;
• duży projekt wymaga kilku osób do pelnienia
funkcji Wsparcia Projektu.
Aby uzyskać więcej informacji na temat centrum
doskonałości i jego powiązań z projektami należy
zapoznać się z publikacją OGC Portfolio, Programme
and Project Offices (TSO, 2008).
5.3.5 Praca z interesariuszami
5.3.5. 1 Rodzaje interesariuszy
I stnieją
prawdopodobnie osoby lub grupy osób,
niebędące w zespole zarządzania projektem, z któ-
rymi projekt powinien utrzymywać kontakt lub na
które rezultat projektu będzie mial wplyw. Osoby
takie mogą:
• wspierać lub negować projekt;
• zyskać lub stracić coś wskutek realizacji projektu;
• postrzegać proj ekt jako zagrożenie lub czynnik
umacniający ich pozycję;
• być aktywnymi zwolennikami projektu lub blo-
kować projekt i utrudniać jego postępy;
• ważne jest, aby przeanalizować, kim są ci intere-
sariusze i odpowiednio z nimi postępować.
Przykład analizy interesariuszy
W wyniku analizy interesariuszy w projekcie
przeniesienia fabryki chemikaliów określ ono
następujących interesariuszy:
• różne związki zawodowe,
• grupę ochrony środowiska,
• branżowy organ regulacyjny,
• funkcje nadzoru jakości na poziomie programu,
• różne departamenty/wydziały organizacji
(np. audyt wewnętrzny, finanse, dział prawny),
• zewnętrzny kontrahent,
• osoby prywatne, na które projekt ma wpływ.
Należy zauważyć, że niektórzy z nich to interesa-
riusze zewnętrzn i dla zespolu zarządzania pro-
j ektem, ale wewnętrzni dla kierownictwa zarzą ­
dzaj ącego organizacją lub programem.
5.3.5.2 Angażowanie interesariuszy
Angażowanie interesariuszy jest to proces identyfi-
kacji i efektywnej komunikacji z tymi osobami czy
grupami, które zainteresowane są projektem lub
mogą wpłynąć na jego rezultat. Zwykle jest on prze-
prowadzany na poziomie programu. We wszystkich
projektach zachodzi jakaś potrzeba angażowania
interesariuszy, szczególnie gdy proj ekt nie jest czę­
ścią programu.
Strony pozostające poza zespołem zarządzania pro-
jektem mogą wywierać silny wplyw na projekt. Sku-
teczna komunikacja z kluczowymi interesariuszami,
zarówno wewnątrz, jak i na zewnętrz organizacji,
jest niezbędna dla sukcesu projektu.
Przykład angażowania interesariuszy
Publikacja OGC Managing Successful Program-
mes (MSP™) określ a sześci ostopn i ową procedurę
a ngażowan i a interesariuszy:
• Identyfikowanie interesariuszy (Kto?)
Określenie pojedynczych interesariuszy zaan-
gażowanych w projekt lub na których ma
on wpływ i możliwe pogrupowanie razem
podobnych interesariuszy tak, aby efektywnie
ukierunkowywać na nich główne przesłania.

• St worzenie i przeanalizowanie profili
interesariuszy {Co?)
Zrozumienie wplywów, interesów oraz postaw
interesariuszy wobec projektu oraz znacze-
nia i sily wpływów każdego interesariusza.
Na przykład czy konkretna grupa może mieć
negatywne nastawienie niezależnie od prze-
słania i wobec tego wymagać szczególnej
uwagi? Na leży wzi ąć pod uwagę wszystkie
wpływy i interesy interesariuszy, zarówno
racjona lne, j ak i emocjonalne. Mogą one
potencjalnie wpłynąć na sukces projektu.
Czyj eś postrzeganie może być błędne, ale
należy je uwzględn i ć i odnieść się do niego.
Postrzeganie korzyści przez interesariuszy
powinno, w przypadku gdy to jest możliwe,
zostać określone i l ościowo.
• Okreś l en iestrategii angażowania
interesariu szy {Jak?)
Określ en ie w jaki sposób projekt może sku-
tecznie postępować z interesariuszami, obej-
muj ące określ enie obowiązków komunikacji
oraz głównych przekazów, które na leży zako-
mun i kować. Dla każdej zainteresowanej stro-
ny n ależy uzgodnić:
• informacje, których ta strona potrzebuje
od projektu;
• metodę, format i częstotl iwość komunikacji;
• nadawcę i odbiorcę wiadomości.
• Planowanie angażowan ia {Kiedy?)
Określenie metod i terminów komunikacji.
Najlepiej planuje się po określeniu tego, w jaki
sposób projekt będzi e angażował różnych
interesariuszy. Przy wyborze nadawców infor-
macji ważne j est, aby wybrać osoby, które
posiadają szacunek i zaufanie odbiorców.
Ich pozycja w organizacji i fachowa znajomość
tematu będą m i ały ogromny wpływ na ich
wiarygodność. Wiele projektów zaczyna się
od forma lnego spotkania inauguracyjnego,
aby przedstawić organizacji projekt i jego cele.
J eżeli wykorzystuje się ten rodzaj spotkania,
ważne j est, aby wzięli w nim udzi ał człon­
kowie Komitetu Sterującego, by pokazać ich
wsparcie i zaangażowanie w projekt.
Organizacja I 45
• Angażowani e interesariuszy {Wykonać)
Przeprowadzanie zaplanowanych działań
i przekazywanie wi adomości . Pierwsze dwa
kroki w procesie postępowania z interesa-
riuszami - identyfikowanie i analiza - ta kże
w pewnym stopniu zaangażują interesariuszy.
• Pomiary efektywności {Rezultaty)
Sprawdzenie efektywności postępowania .
Nadzór Projektu może być zaa ngażowany
w sprawdzanie wszystkich kluczowych intere-
sariuszy, ich potrzeb informacyjnych oraz czy
wykorzystywane są najbardziej odpowiednie
kanały kom u n ikacj i.
5.3.5.3 Strategia Zarządzania Komunikacją
Strateg ia Za rządza n ia Komu n i kacją zawiera opis
środków i częstotliwości komunikowania ze stro-
nami zarówno wewnątrz, j ak i na zewn ątrz pro -
j ektu. Ułatwia ona angażowanie interesariuszy
poprzez ustanowienie kontrolowanego i dwu-
kierunkowego prze pływu informacji. W przypad-
ku, gdy projekt jest częścią programu, Strategia
Zarządzan i a Kom u n i kacj ą powinna ta kże określać,
j akich inf ormacji potrzebuj e program i jak mają
być one komunikowane.
Jeżeli zakończono forma l ną proced urę postępowa­
nia z interesariuszami, taką j ak opisana wcześn i ej ,
powinno to także zostać udokumentowane jako
część Strategii Zarządzania Komu n ikacj ą. Wi ęcej
szczegółowych informacj i na temat sugerowanej
zawartości Strategii Zarządzan i a Komun i kacją
przedstawiono w Dodatku A.
Kierownik Projektu powinien ponosić odpowie-
dzi a l ność za opracowanie Strategii Zarzą d za n ia
Komun i kacją w czasie procesu Inicjowanie Projek-
tu. Ważn e jest także, aby dokonywano p rzeglą­
dów i być może aktualizacji Strategii Za rządzania
Komun i kacją na końcu każdego etapu, w celu
upewnienia si ę, że w dalszym ciągu obej muje ona
wszystkich kluczowych interesariu szy. Przy pla-
nowaniu ostatniego etapu projektu należy ta kże
dokon ać przeg l ądu Strategii Za rządzan i a Komu-
n i kacją w celu upewnienia się, że uwzg l ęd n ia ona
wszystkie strony, które n ależy powi adom i ć o t ym,
że projekt jest zamykany.
W czasie trwania projekt u kierownictwo organiza-
cji lub programu utrzymuje kontrolę, otrzym uj ąc
informacje o projekcie, tak jak określa to Strategia
46 I Organizacja

Zarz.ą dzania Komunikacją, i podejmując decyzje na 5.4 OBOWIĄZK I

temat sytuacji nadzwyczajnych na poziomie projektu
Tabela 5.1 przedstawia obowiązki dotyczące tematu
przekazywanych przez Komitet Sterujący.
Organizacja. Więcej szczególów na temat ról zespo-
Jeżel i projekt stanowi część programu, potrzebne lu zarządzan i a projektem i powiązanych z n im i obo-
będzie zapewnien ie spój ności i komunikacji pom i ę­ wi ązków przedstawiono w Dodatku C.
dzy różnym i poziomam i zarządzania projektem
i programem. Bardziej szczególowe informacje na
temat ról w programie i tego, jak wspóldzialają one
z rolami w projekcie znajdują się w Rozdziale 19.

Tabela 5.1 Obowiązki dotyczące tematu Organizacja

Ro la Obowiązki

Kierowni ctwo organizacji lub programu Mianuje Przewodniczącego i (być może) Kierownika Projektu.
Dostarcza projektowi informacje zgodnie ze Stra tegią Zarządzania
Komunikacją.

Przewodn i czący Mianuje Kierownika Projektu Oeżeli nie zrobiło tego kierownictwo
organizacji lub programu).
Zatwierdza nominacje do zespolu zarządzania projektem oraz strukturę
zespołu zarządzania projektem.

Zatwierdza Strategię Zarządzania Komunikacją.

Gló w ny Użytkownik Dostarcza zasoby użytkownika.

Okr~la i weryfikuje wymagania oraz oczekiwania użytkownika.

Gló wny Dostawca Dostarcza zasoby dostawcy.
Kierownik Projektu Przygotowuje Strategię Zarządzania Komunikacją.
Dokonuje przeglądów i aktualizuje S trategię Zarządzania Komu nikacją .
Projektuje, przeprowadza przeglądy i aktualizuje strukturę zespolu
zarządzania projektem.

Przygotowuje opisy ról.

Kie rownik Zespolu Kieruje członkami zespolu projektowego.
Doradza w kwestiach czlonków zespołu projektowego i postępowania
z interesariuszami.
Nadzór Projektu Doradza w sprawie wyboru czlonków zespołu projektowego.
Doradza w kwestiach postępowania z interesariuszami.
Zapewnia, że Strategia Zarządzania Komunikacją jest odpowiednia i że
planowane dzialania komunikacyjne mają faktycznie miejsce.
Wsparcie Projektu Zapew nia wsparcie administracyjne zespolowi zarządzania projektem.
6 Jakość
6.1 PRZEZNACZENIE
Przeznaczeniem tematu Jakość jest określenie
i wdrożenie środków, za pomocą których projekt
wytworzy produkty i zweryfikuje, czy odpowia-
dają one swojemu przeznaczeniu.
Temat Jakość określa podejście metodyki PRINCE2
do zapewnienia, że produkty projektu:
• spelniają oczekiwania biznesowe;
• umożliwią w efekcie uzyskanie pożądanych
korzyści.
Zasada koncentracji na produktach ma fundamen-
talne znaczenie d la podejścia metodyki PRINCE2 do
kwestii jakości. Dostarcza wyraźnego, wspólnego dla
wszystkich zrozumienia tego, co projekt wytworzy
(zakres projektu) oraz kryteriów do oceny produk-
tów projektu Gakość). Bez tego zrozumienia projek-
ty narażone są na kilka rodzajów ryzyka (takich jak
spory dotyczące akceptacji, konieczność poprawek,
niekontrolowane zmiany, niezadowolenie klienta),
które mogą osłabić lub unieważn i ć Uzasadnienie
Biznesowe.
Dopiero po ustaleniu kryteriów jakości dla produk-
tów i dzialań dotyczących zarządzan i a jakością,
które muszą być uwzględnione w planach projektu,
można oszacować całkowite koszty i terminy wyko-
nania projektu. Niedoszacowanie lub pominięcie
działań dotyczących zarządzania jakością może
doprowadzić do opóźnień, nadmiernych wydatków
i/lub niskiej jakości wyników. Temat Jakość obejmuje
metody i obowiązki dotyczące jakości nie tylko na
potrzeby określenia, wytworzenia i zatwierdzenia
produktów projektu, ale także na potrzeby zarzą­
dzania projektem.
Temat Jakość obejmuje także wdrożenie „ciągłego
ulepszania" w czasie trwania projektu, na przykład
poszukiwania sposobów wprowadzenia większej
sprawności lub efektywności do zarządzania projek-
tem i produktami projektu. Zdobywanie doświad­
czeń i uczenie się z nich także ma wpływ na podej-
ście do kwestii jakości metodyki PRINCE2, gdyż jest
to sposób na osiąganie ciągłej poprawy.
6.2 DEFINICJA JAKO ŚCI
Pojęcia używane w kontekście j akości są czasami
różn i e lub zamiennie interpretowane przez różne
osoby. Może to prowadzić do nieporozumień. Ter-
minologia wykorzystywana w metodyce PRINCE2
wywodzi się ze standardów ISO 9000, ale nakiero-
wana jest konkretnie na prace projektowe.
6.2.1 Jakość
Jakość j est zwykle definiowana j ako ogól wlaściwo­
ści i cech inherentnych lub przypisanych produktowi,
osobie, procesowi, usłudze i/lub systemowi, które
u możl iwiają wykazanie, że spelnia o n oczekiwania
lub zaspokaja określone potrzeby, wymagania lub
specyfikacje.
W metodyce PRINCE2 produktem może być także
przeszkolona osoba, proces, usługa i/lub system,
a więc działania dotyczące jakości koncentrują się
na zdolności produktu do spelnienia określonych dla
niego wymagań.
6.2.2 Zakres
Zakres planu to ca łkowita suma j ego produktów.
Zakres ten określony jest przez strukturę podzialu
produktów planu i zwi ązane z nim Opisy Produk-
tów.
6.2.3 Zarządzanie jakością i systemy
zarządzania jakością
Zarządzanie jakością jest określane jako skoordyno-
wane dzialania służące zarządzaniu strategicznemu
i kontroli danej organizacji w odniesieniu do jakości.
System zarządzania jakością to pełny zbiór standar-
d ów jakości, procedur i obowiązków dla danej p la-
cówki lub całej organizacji.
W kontekście projektu „placówki" i „organizacje"
powinno się interpretować jako trwałe lub półtrwałe
organizacje sponsorujące prace projektowe, tj. są one
„zewnętrzne" względem projektu, będącego orga-
nizacją powolaną tylko na pewien czas. Na przykład
program można uważać za półtrwałą organizację
sponsorującą projekt i może on posiadać udokumen-
towany system zarządzania jakością.
50 I Jakość

Często zdarza się, że w projekt zaangażowana jest 6.2.6 Nadzór ja kości

więcej niż jedna trwała organizacja na przykład
oddzielne firmy klienta i dostawcy. z których każda
może m i eć swój własny system zarządzan i a jako·
ści ą. Z drugiej strony j eżel i projekt sponsoruje jedna
kluczowa organizacj a lub jest on częścią programu,
bardziej prawdopodobne jest istnienie j ednego
ustanowionego systemu zarządzan i a j akości ą. Przy
określaniu podejścia projektu do kwestii jakości
należy uwzględnić te różne uwarunkowania.
6.2.4 Planowanie jakości
Aby cokolwiek kontrolować, łącznie z jakością.
należy mieć plan. Planowanie jakości obejmuje zde-
finiowanie produktów, których wytworzenie jest
wymagane od projektu, z odpowiednimi kryteriami
jakości, metodami ja kości (obejmuj ącymi równ i eż
prace wymagane dla kontroli j akości i akceptacji
produktu) oraz obowi ązkam i zaangażowanych
osób w zakresie jakości.
6.2.5 Kontrola ja kości
Kontrola jakości koncentruje się na technikach
i działaniach operacyjnych stosowanych przez osoby
zaangażowane do projektu tak, aby:
• zaspokoić wymagania jakościowe (na przykład
przez inspekcje czy testowanie jakości);
• określ i ć sposoby eliminowania przyczyn niezado·
wa l ających wyników (na przykład przez wprowa-
dzenie usprawn i eń procesu w wyniku zdobytych
doświadczeń).
Do dobrych praktyk należy ustanowienie nadzoru
jakości nieza l eżnego od zespołu zarządzania pro-
jektem. Nadzór j akości sprawdza, czy zarządzanie
strategiczne i operacyjne projektem są odpowied-
nie dla charakteru projektu i czy są one zgodne
z odpowiednimi standardami i po l ityką kierowni-
ctwa organizacji lub programu. Działania nadzoru
jakości pozostają poza zakresem metodyki
PRINCE2, ponieważ należą do obowiązków
organizacji lub programu.
Nadzór jakości polega na niezależnym sprawdza-
niu, czy zostały ustanowione organizacja i procesy
pozwalające na planowanie i kontrolę jakości (a nie
na faktycznym planowaniu czy przeprowadzaniu
kont ro li jakości, które realizować będzie zespól
zarządzania projektem). Pozwala to interesariuszom
projektu nabrać pewności. że zaspokojenie wyma-
gań jakościowych jest możl i we.
Określenie „nadzór jakości" używane jest w dwóch
znaczeniach:
• jako funkcja w organizacji (lub w placówce czy
w programie), która zakłada i utrzymuje system
zarządzania jakością;
• jako działanie związane z przeglądem organi-
zacji, procesów i/lub produktów projektu w celu
n i ezależnej oceny, czy zostaną zaspokojone
wymagania dotyczące j akości .

Tabela 6.1 Relacje pomiędzy Nadzorem Projektu a nadzorem j akości

Nadzór Projektu Nadzór jakości

Gwarantuje mteresanuszom projektu, że projekt
Co robią?
prowadzony jest odpowiednio.
Musi być niezależny od Kierownika Projektu.
Jak si ę różn i ą?
Wsparcia Projektu. Kierowników Zespolów i zespolów
projektowych.
Gwarantuje szerszej organizacji. firmie lub
programowi, że projekt prowadzony jest
wlaściwie i stosuje się do odpowiednich
standardów czy polityki kierownictwa firmy
lub programu.
Sprawowany przez osoby niezależne od
projektu (tj. nie są one czlonkami zespolu
zarządzania projektem).

Jest obowiązkiem Komitetu Sterującego, zatem jest Jest obowiązkiem organizacji lub
pelniony w ramach projektu. kierownictwa programu. zatem jest
zewnętrzny w stosunku do projektu.

Nadzór jakoki jako funkcja kierownictwa organizaq1 Nadzór jakości może oczekiwać (lub
Jak są powiązane?
czy programu może być wykorzystany przez Komitet wymagać), efektywnego Nadzoru Projektu

Sterujący jako część Nadzoru Projektu (na przyklad jako jednego ze wskaźników, że projekt jest
nadzór jakości może przeprowadzić przegląd prowadzony wlaściwie.
partnerski).
 Jakość I 51

Należy zauważyć, że w obydwu znaczeniach tego
określenia, nadzór jakości zakłada dzialania niezależ­
ne od zespołu zarządzania projektem, podczas gdy
planowanie jakości oraz kontrola jakości przeprowa-
dzane są przez projekt. Niemniej j ednak, zapewnie-
nie zorganizowania odpowiedniego nadzoru jakości
należy do obowiązków zarządzania projektem.
tego obowiązek należący do zespolu zarządzania
projektem. Chociaż Nadzór Projektu jest niezależny
od Kierownika Projektu, to w przeciwieństwie do
nadzoru jakości nie jest on nieza l eżny od projek-
tu. Nadzór Projektu i nadzór ja kości mają obszary
wspólne, co przedstawia Tabela 6.1.

Nadzoru jakości n ie n ależy mylić z Nadzorem 6.3 PODEJ ŚCI E PRINCE2 DO JAKOŚCI
Projektu. Nadzór Projektu dotyczy w szczególno-
W metodyce PRINCE2 szczególne traktowanie
ści odpowiedzialności Komitetu Sterującego za
jakości polega na koncentracji na produktach od
zapewnienie, że projekt jest odpowiednio pro-
samego początku i wymaganiu systematycznych
wadzony we wszystkich aspektach. Jest to wobec
czynności w celu:

Ze strony klienta W projekcie

,.. - - - - - - „

Komponenty jakości
Planowanie "" - --- ---------------„
ja kości
•
Technika
planowania
opartego •
na produktach
PRINCE2

L------------------------ ____ J

~-------------- -----„
Technika PRODUKT
Przeglądu Kontrola
Jakości
jakości
PRINCE2

L-------------- - - - - -J
•

Rysunek 6. 1 Ścieżka audy tu jakości

52 I Ja kość
• określenia wszystkich produktów projektu (tj. do
poziomu, do którego projekt ma zamiar sprawo-
wać kontrolę);
• zdefiniowania ich w Opisach Produktów - łącz­
nie z kryteriami jakości, pod kątem których
produkty będą oceniane; metodami j akości
wykorzystywanymi podczas ich projektowania,
wytwarzania i akceptowania; oraz obowiązkami
zaangażowanych osób dotyczącymi jakości;
• wdrożenia i śledzenia metod jakości wykorzysty-
wanych w czasie trwania projektu.
Pierwsze dwa punkty są objęte przez planowanie
jakości (sekcja 6.3.1 ), a ostatni przez kontrolę jakości
(sekcja 6.3.2) i nadzór jakości (sekcja 6.2.6).
Podejście metodyki PRINCE2 do kwestii jakości
można przedstawić w prosty sposób jako ścieżkę
audytu jakości pokazaną na Rysunku 6.1. Określe­
nia przedstawione na tym schemacie wyjaśnione są
w dalszej części tego rozdzialu.
6.3.1 Planowanie jakości
Celem planowania jakości jest dostarczenie solid-
nych podstaw dla:
• uzgodnień Komitetu Sterującego odnośnie calo-
ściowych oczekiwań jakościowych, wymaganych
produktów z powi ązanymi z nimi kryteriami
jakości (lączn i e ze standardami firmowymi i inny-
mi, które należy zastosować), środków osi ąga­
nia i oceny jakości oraz, ostatecznie, kryteriów
akceptacji, pod kątem których oceniany będzie
produkt końcowy projektu;
• zakomunikowania tych uzgodnień w jedno-
znaczny sposób tak, aby wszyscy interesariusze
projektu tak samo zrozumieli to, co projekt ma
osiągnąć;
• kontroli, tj. ustanowienia efektywnego układu
odniesienia dla kontroli jakości w projekcie (łącz­
nie z tolerancjami jakości) oraz bezpiecznych
sposobów uzyskiwania produktów odpowi adają­
cych swoj emu przeznaczeniu.
J eżel i te aspekty planowania zostaną zaniedba-
ne, osoby zaangażowane w projekt mogą mieć
sprzeczne poglądy na takie tematy, jak: zakres
rozwiązania, co stanowi pomyślny rezultat, jakie
podejście ma być zastosowane, rozmiar wymaga-
nych prac, kogo powinno się zaangażować i jakie
powi n ny być ich role.
Planowanie jakości obejmuje:
• Zrozumienie oczekiwań jakościowych klienta
(sekcja 6.3.1.1 );
• Określenie kryteriów akceptacji projektu (sekcja
6.3.1.2);
• Udokumentowanie oczek iwań j akości owych
klienta i kryteriów akceptacji projektu w Opisie
Produktu Końcowego Projektu (sekcja 6.3.1 .3);
• Sformułowanie Strategii Zarządzania Jakością
(sekcja 6.3.1.4);
• Stworzenie jasnych Opisów Produktów zawiera-
jących kryteria jakości, tolerancje jakości, metody
jakości i obowiązki związane z jakością (sekcja
6.3.1.5);
• Zalożenie Rejestru J akości (sekcja 6.3.1.6).
6.3.1.1 Oczekiwania jakościowe klienta
Oczekiwania jakościowe klienta są oświadcze­
niem na temat jakości oczekiwanej od produktu
końcowego projektu. Są one początkowo okre-
ślone i uzgodnione w procesie Przygotowanie
Projektu. Oczekiwania określane są w rozmowa ch
z klientem, a następnie precyzowane dla potrzeb
umieszczenia ich w Opisie Produktu Końcowego
Projektu.
W celu uniknięcia blędnych interpretacji i niepo-
prawnych zalożeń na temat wymagań j akościo­
wych projektu, oczekiwania jakościowe klienta
powinny obejmować:
• kluczowe wymagania jakościowe dla produktu
końcowego projektu;
• wszelkie standardy i procesy, które trzeba
będzie zastosować, aby osiągnąć określone
wymagania jakościowe, łącznie z zakresem
wykorzystania systemu zarządzania jakością
klienta i/lub dostawcy;
• wszelkie pomiary, które mogą być przydatne
do oceny czy produkt końcowy projektu spelnia
wymagania jakościowe (na przyklad istn i ej ące
miary stopnia zadowolenia klienta).
Kluczowe wymagania jakościowe będą ukierun-
kowywać wybór rozwiązania i wpływać z kolei
na docelowe parametry efektywności projektu
określone dla terminów, kosztów, zakresu, ryzyka
i korzyści.

Przykłady oczekiwań jakościowych
Oczekiwanie jakościowe dla pompy wodnej
w oddalonej wiosce jest takie, że będzie ona
wystarczająco solidna, żeby wystarczyć na „cale
życie", podczas gdy pompa olejowa w samocho-
dzie wyścigowym musi być jak najlżejsza, więc
wystarczy, żeby wytrzymała tylko przez czas
jednego wyścigu .
Oczekiwania jakościowe klienta wyrażane są często
w kategoriach ogólnych jako środek prowadzący do
wspólnego zrozumienia ogólnych wymagań jako-
ściowych. Wykorzystywane są następnie do o kre-
ślenia bardziej szczególowych kryteriów akceptacji,
które powinny być konkretne i precyzyjne.
Kiedy to możl iwe, oczekiwania j a kości owe klienta
powinny mi eć określone priorytety, pon i eważ wyko-
rzystywane będą jako podstawa do zdefiniowania
tolerancji j akości d la produktów projektu.
Przy końcu każdego etapu zarządczego
powinno się
dokonać przeglądu oczekiwań jakościowych klienta,
na wypadek gdyby jakieś czynniki zewnętrzne spo-
wodowały ich zmianę .
6.3.1.2 Kryteria ak ceptacji
Kryteria akceptacji w projekcie tworzą listę mierzal-
nych definicji wymaganych atrybutów z określonymi
priorytetami, aby zestaw produktów projektu został
zaakceptowany przez głównych interesariuszy. Przy-
kłady to: łatwość użycia, łatwość wsparcia, łatwość
utrzymania, wygląd, glówne funkcje, koszty wytwo-
rzenia, koszty bieżące, zdol ność/wydajność, dostęp­
ność, niezawodność, bezpieczeństwo, dokładność
i wykonanie.
Kryteria akceptacji powinny m i eć określone prio-
rytety, ponieważ pomaga to w przypadku, gdy
pomiędzy pewnymi kryteriami na l eży zn a l eźć
komp romis - na przykład wysoka j akość, wczesna
dostawa i niski koszt, mogą nie być ze sobą zgodne
i trzeba będzi e poświ ęcić j edno z tych kryteriów,
aby spełnić pozostale dwa.
Jakość I 53
Przykład techniki priorytetowania - MoSCoW
Każde kryterium akceptacji jest klasyfikowane
w skali jego ważności jako: „musi być spełnione",
„powinno być spełnione", „może być spełnione"
albo „nie będzie spełnione na razie" (ang. M ust
have, Should have, Cou/d have lub Won't have -
w skrócie MoSCoW).
Wszystkie kryteria akceptacji zaklasyfikowane
jako „musi być spełnione" i „powinno być spełnio­
ne" powinny być wspólnie osiąga ln e (nie mogą
być sprzeczne ani wzajemnie wyk luczające si ę}.
Kiedy projekt może wykazać, że wszystkie kryteria
akceptacji zostały speł ni one, wtedy zobowi ąza n ia
projektu są wykonane i może on zostać zam knięty.
Kryteria akceptacji powinny zostać uzgodnione
pom i ędzy klientem i dostawcą w procesie Przygoto-
wanie Projektu i udokumentowane jako część Opisu
Produktu Końcowego Projektu. Ważne jest zrozu-
mienie, że na tak wczesnym etapie wiedza na temat
produktów projektu może być niewielka. W kon-
sekwencji często zdarza się, że kryteria akceptacji
są doprecyzowywane i uzgadniane w procesie Ini-
cjowanie Projektu oraz dokonuje się ich przeglądu
na końcu każdego etapu zarządczego. Po ich osta-
tecznym uzgodnieniu i zapisaniu w Opisie Produktu
Końcowego Projektu, kryteria akceptacji podlegają
sterowaniu zmianami i mogą zosta ć zmienione tylko
za zgodą Komitetu Sterującego.
Rozważając kryteria akceptacji, użyteczne jest
dobranie miar pomocniczych, które będą stanowić
dokładne i niezawodne wskaźniki tego, czy później
korzyści zostaną osiągnięte.
Przykład kryteriów akceptacji
Jeżel ioczekiwaniem j akościowym klienta co do
pompy wodnej jest jej trwa Iość „na ca łe życie",
to kryteria akceptacji powinny koncentrować s ię
na takich miarach, które z wystarczającą pewno-
ścią wskażą lub zagwarantują, że pompa może
rzeczywiście wytrzymać przez całe życie (określo­
ne jako konkret na liczba lat}. Może to się wiązać
ze spełnieniem pewnych norm technicznych
odnoszących się do trwałości produktu.
Określenie kryteriów akceptacji jest niezwykle istot-
ne, ponieważ odpowiadają one na pytanie: w jaki
sposób udowodnimy, czy i kiedy produkt projektu
został ukończony i jest akceptowalny dla klienta?
54 I J akość
6.3.1.3 Opis Produk t u Końcowego Projektu
Opis Produktu Końcowego Projektu opracowywany
jest w procesie Przygotowanie Projektu jako część
początkowego działania określającego zakres pro·
j ektu i może zostać doprecyzowany w procesie lni·
cjowanie Projektu podczas tworzenia Planu Projektu.
Podlega on forma lnej kontroli zmian i powinien być
sprawdzany przy końcach etapu (w procesie Zarzą·
dzanie Końcem Etapu), aby stwierdzić, czy wymagane
są jakieś zmiany. Wykorzystywany jest w procesie
Zamykanie Projektu jako część weryfikacji tego, czy
projekt dostarczył oczekiwane produkty i korzyści,
oraz czy zostały spełnione kryteria akceptacji.
Opis Produktu Końcowego Projektu obejmuje:
• ogólne przeznaczenie produktu;
• jego zawartość (tj. zestaw produktów, które musi
on zawi erać);
• oczekiwania jakościowe klienta;
• kryteria, metody i obowiązki dotyczące akceptacji;
• tolerancje jakości na poziomie projektu.
Zatwierdzony Opis Produktu Końcowego Projektu
stanowi część Założeń Projektu i jest wykorzystywa·
ny do tego, aby pomóc w wyborze formuły reali·
zacji projektu. Opis Produktu Końcowego Projektu
określa, czego oczekuje klient od projektu, a for·
muła rea lizacji projektu określa rozwiązanie lub
metodę, z której skorzysta dostawca, aby wytwo·
rzyć produkt końcowy proj ektu.
Opis Produktu Końcowego Projektu jest szczegól·
ną formą Opisu Produktu pod tym względem, że
obejmuje on oczekiwania jakościowe klienta, ale
na tym poziomie kryteria i metody jakości stanowią
kryteria akceptacji oraz metody akceptacji dla całe·
go projektu.
6.3.1.4 Strat egia Zarządza nia Jakością
Strategia Zarządzania Jakością przygotowywana jest
w procesie Inicjowanie Projekt u i następn i e zatwier·
dzana przez Komitet Steruj ący. Poszerza ona formu-
łę rea lizacji projektu i można j ą uważać za propozy-
cję zespolu zarządzan i a projektem w odpowiedzi na
oczekiwania jakościowe klienta i kryteria akceptacji.
Strategia Zarządzania Jakością opisuje, w jaki spo·
sób w projekcie stosowane będą systemy zarządza­
nia jakością organizacji uczestniczących w projekcie
i potwierdza wszelkie normy jakości, procedury,
techniki i narzędzia, które będą użyte. Jeśli stan·
dardy i modele mają zostać dostosowane, sposób
tego dostosowania powinien zostać przedstawiony
w Strategii Zarządzania Jakością do zatwierdzenia.
Strategia Zarządzania Jakością dostarcza także środ ·
ków, za pomocą których można skalować i uzgad·
niać stopnie forma lizmu, jakie mają być zastosowa-
ne w planach i kontrolach jakości, zgodnie z kon·
kretnymi potrzebami projektu.
Powinna ona także zawierać ogólne ustalenia doty·
czące nadzoru jakości, łącznie z niezależnymi audy·
tarni, gdy są one wymagane przez politykę organi·
zacji uczestn i czących w projekcie.
Powinny zostać w niej określone kluczowe obowiąz·
ki dotyczące jakości (zarówno wewnątrz, jak i na
zewnątrz zespołu zarządzania projektem), lącznie
z omówieniem podejścia do Nadzoru Projektu.
W przypadku gdy istnieje już ustalony system zarzą ·
dzania jakością dla projektów, na przykład system
ustalony w ramach programu, konieczne może być
tylko udokumentowanie w Strategii Zarządzania
Jakością miar specyficznych dla tego projektu.
Strategia Zarządzania Jakością utrzymywana jest
przez caly czas trwania projektu, podlegając proce·
durze sterowania zmianami.
6.3.1.5 Opisy Produkt ó w
Po rozpoczęciu szczegółowego planowania,
powinny zostać opracowane Opisy Produktów dla
wszystkich produktów projektu. Tworzenie Opisów
Produktów jest obowiązkowe. To na ich podstawie
produkty są wytwarzane, a następnie przeg l ądane
i zatwierdzane.
Stopień szczegółowości Opisu Produktu jest kwestią
indywidualnej oceny, przy czym podstawowym celem
jest wybór takiego poziomu, który dostarcza bez·
piecznego i wlaściwego sposobu kontroli wystarczają­
cej do spelnienia oczekiwań jakościowych klienta.
Zawartość Opisu Produktu przedstawiona jest
w całości w Dodatku A. Sekcja „Przeznaczenie"
Opisu Produktu powinna jasno wyrażać, kto potrze·
buje produktu, d laczego i czemu on będzie slużył.
Poza sekcją „Przeznaczenie", inne sekcje specyficzne
dla jakości to: Kryteria jakości, Tolerancje jakości,
Metody jakości, Wymagane umiejętności kontrolera
jakości oraz Obowią zki dotyczące jakości . Określają
one mechanizmy sterowania jakością, które muszą
być stosowane w czasie wytwarzania produktu oraz
w procedurach przeglądu i zatwierdzania ukończo­
nego produktu.

Powinno się uważać, aby nie tworzyć zbyt szczegóło­
wych Opisów Produktów. Istnieją one po to, by dopo-
móc w planowaniu, wytwarzaniu, stosowaniu metod
jakości i metod zatwierdzania. Zbyt szczegółowe
Opisy Produktów mogą prowadzić do niepotrzebne-
go wzrostu kosztów jakości w projekcie. Niepełne łub
nieprecyzyjne Opisy Produktów prowadzić mogą do
sporów związanych z akceptacją produktów, jeżeli
dostarczone wyniki nie pokrywają się z oczekiwa-
niami klienta. Jeśli to konieczne, Opisy Produktów
powinny odnosić się do informacji dodatkowych,
takich jak wszelkie mające zastosowanie standardy
czy specjalistyczna dokumentacja projektowa.
Czas potrzebny na opracowanie dobrych Opisów
Produktów zależny będzi e od takich czynników, jak
znaczenie, stopień złożoności i wyjątkowości produk-
tu, od liczby interesariuszy dokonujących przeg l ądów
i zatwierdzających produkt oraz tego czy organizacj a
posiada bi bl iotekę standardowych Opisów Produk-
tów do ponownego wykorzystania. Biblioteki Opisów
Produktów są często wdrażane przez użytkowników
metodyki PRINCE2 w celu promowania spójności opi-
sów i ponownego ich wykorzystywania.
Kryteria jakości
Przykład kryteriów jakości
Rozpatrzmy projekt, który ma na celu zaprojek-
towanie i wyprodukowanie nowego aparatu
fotograficznego. Jednym z kryteriów jakości jest
to, że aparat ten wraz z opakowaniem nie może
ważyć więcej niż 1 kg. W strukturze podziału
produktów występuje produkt: instrukcja dla
użytkownika. Wynika z tego, że wielkość i waga
broszury z instrukcjami jest ważnym czynnikiem,
a nie na przykład liczba jej stron.
Pytania, które t rzeba tu zadać to: Jaki jest rynek
docelowy dla tego aparatu? Czy wynika z tego
także, że instrukcje trzeba będzi e napi sać w kilku
językach? Czy oznacza to, że broszura będzi e
cięższa? Czy wystarczą instrukcje zawarte na
płycie CD? Mogłoby to zmniej szyć wagę broszury
z instrukcjami, a pozwolić na zwiększenie ci ężaru
samego aparatu.
Rozważenie kryteriów jakości często uwypukla
powiązania i czynniki takie, jak te, które są póż­
niej wykorzystywane w procesie planowania.
Opis Produktu powinien obejmować wymogi jako-
ściowe, które musi spełniać produkt oraz miary
J akość I 55
jakości, które stosowane będą
przez kontrolerów
sprawdzających ukończony produkt.
Kryteria jakości powinny być wystarczająco szczegó-
łowe i jasne, aby umożliwić osobom dokonującym
przeglądu produktu jednoznaczne potwierdzenie,
czy produkt spełnia określone dla niego wymagania.
Tolerancje jakości
Tolerancje jakości dla produktu mogą być zawarte
w kryteriach jakości poprzez określenie akceptowal-
nego zakresu ich wartości. Na przykład: „Czy czas
trwania prezentacji wynosi 30 minut (+/- 5 minut)?",
„Czy utrzymywana j est temperatura w przedziale od
1 do s°C?".
Metody jakości
Sekcja opisująca metody jakości w Opisie Produktu
wykorzystywana jest do określenia dzi ałań dotyczą­
cych j akości, które mają być realizowane podczas
wytwarzania produktu, przeglądów i zatwierdzenia
po ukończeniu. W przypadku gdy metody ja kości
za kładaj ą umiejętności specjalistyczne, powinny one
także zostać wyszczególnione. I stn i eją dwa podsta-
wowe rodzaje metod jakości: metody stosowane
w trakcie procesu wytwarzania produktu oraz meto-
dy oceny gotowego produktu (patrz sekcja 6.3.2.1).
Obowiązki dotyczące jakości
W celu uniknięcia wątpliwości,
powinny zostać okre-
ślone obowiązki dotyczące jakości produktu. Będą
one mieścić się w jednej z trzech kategorii:
• Wytwórca - osoba lub grupa odpowiedzialna za
wytworzenie produktu;
• Kontroler(-rzy) - osoba lub grupa niezależna
od wytwórcy, która ocenia, czy produkt spełn ia
wymagania określ one w Opisie Produktu;
• Zatwierdzający - osoba lub grupa, na przy-
kład Komitet Steruj ący, która określona zosta -
ła jako posiadająca kwalifikacje i uprawnienia
do zatwierdzenia produktu jako ukończonego
i odpowi adającego swojemu przeznaczeniu.
6.3.1.6 Rej estr Jakości
Rejestr Jakości jest faktycznie terminarzem plano-
wanych i przeprowadzonych dzialań dotyczących
jakości (na przykład warsztatów, przeglądów,
inspekcji, testów, działań pilotażowych, akceptacji
i audytów). Tworzony jest w trakcie procesu Ini-
cjowanie Projektu, gdy definiowane są produkty
i miary kontroli jakości. Utrzymywany jest następnie
56 I Jakość

(zgodnie z obowią zującymi planami bazowymi) 6.3.2.1 Metody jakości

przez caly czas trwania projektu. Koszt poprawiania usterek w produktach rośn i e tym
W miarę postępów projektu, kiedy otrzymywa- bardziej, im dł użej pozostają niewykryte. O w iele
ne są dokumenty dotyczące działań związanych łatwiej i taniej jest poprawić dokumentację projek-

z jakością, Rejestr Jakości jest aktualizowany tak,
aby pokazywał on (sumarycznie) faktyczne wyniki
tych działań. Rejestr Jakości dostarcza kluczowych
informacji dla audytu i nadzoru, wi ążąc to, co było
planowane i uzgodnione (w Strategii Zarządza nia
Jakością i w Opisach Produktów) z faktycznie prze-
prowadzonymi działaniam i dotyczącymi j akości.
Ilośćinformacji włączonych do Rejestru Jakości
może się znacznie zmieniać, zależnie od stopnia,
w jakim należy analizować miary jakości
(np. „l i czbę usterek") w celu usprawnienia procesu.
Przykład Rejestru Jakości pokazuje Tabela 6.2.
6.3.2 Sterowanie jakością
Sterowanie jakością jest real izowane poprzez wdra-
żanie, monitorowanie i rejestrowanie realizacji
metod jakości oraz obowiązków określonych w Stra-
tegii Zarządzania Jakością i Opisach Produktów
(oraz następnie uzgodnionych w Grupach Zadań).
Sterowanie jakością obejmuje:
• stosowanie metod jakości (sekcja 6.3.2.1 );
• utrzymywanie zapisów dotyczących jakości
i zatwierdzeń (sekcje 6.3.2.2 i 6.3.2.3);
• uzyskiwanie akceptacji (sekcja 6.3.2.4).
tową w początkowej fazie projektu niż poprawić
wadę konstrukcyjną, którą odkrywa się dopiero
wtedy, gdy ukończony produkt jest testowany lub,
nawet gorzej, kiedy produkt już jest eksploatowany.
Wynika z tego to, że kontrole j akości, przeprowa-
dzane wcześnie w procesie proj ektowania i rozwoju,
są potencjalnie naj bardziej efektywnymi kosztowo
metodami jakości, które są dostępne.
Istnieją dwa rodzaje metod jakości:
• Metody zapewniania jakości stosowane w trakcie
procesu wytwarzania
Są to środki, za pomocą których jakość można
„ wbudować" w produkty w czasie ich wytwa-
rzania. M ogą one obejmować wykorzystanie
specjalistycznych metod i/lub technik, łącznie ze
statystyczną kontrolą procesu, automatyzacją (np.
robotyką, sterowaniem numerycznym), wdro-
żeniami pilotażowymi, warsztatami, ankietami
i konsultacjami, albo, prościej, wykorzystanie
kontroli jakości zarówno w czasie wytwarzania
produktu, jak i po jego u kończeniu.
• Metody oceny jakości gotowych produktów
Są to środki, za pomocą których ukończone pro-
dukty oceniane są pod względem ich komplet-
ności i tego, czy odpowiadają swojemu przezna-

Tabela 6.2 Przykładowy Rejestr Jakości

.·o.,.o
..:,;; ·-
..,. ~ ...."' ...."' ...."'
~ "'
V IO'
"' ....
·~
li) ::i o ·~
~
' "'
-o
-o
li)
"' "'
-o ·-c li) · -
-o cQ)
·-c ..:,;; ~

>-
li)
"'m-o::i
c
li) Q)

-li)
li)
·-N
..:,;;

-o
o
::i

....
....
..:,;;
::i
"'
·~

"'o
-o
"'~
·O
....
N

....'
~
-o
N
....
Q) ~~
oc
"' ::i
c -o
N
v-
>-
f1I'
C
"'
~ -o
o ·-
Q;
N 111 N
C-0
N._
u Q) ~

o
o
Cl.
o
-o
o
....
....
Q) l~ Q)
~ ~ -
111 N
Ol
Q)
.... ~N
"'
Ol
.... Q)
c~
~·-
..:,;; ~ c
~
- - Cl. ~ {!!. N"' Cl. a. u. ....a. .!!!
Cl. "'
N U.
"' "'N

1 121 Plan Inspekcja Jan Paweł Andrzej, 14-Lut 21 -Lut 21-Lut 28-Lut Ode br.
testów Iwona
2 124 Pompa Test Paweł Jan, Piotr 20·Mar 20·Mar 27-Mar nd. Nieodebr.
wodna wydajności Wiesław

3 124 Pompa Test Paweł Jan, Iwona 21 -Mar 21-Mar 27·Mar 27-Mar Ode br.
wodna utrzymania Roman

. . . . . . . . . . .
. . . . . . . . . . .
9 124 Pompa Test Paweł Jan, Piotr 14-Cze 14-Cze
wodna wydajności Wiesław

czeniu. Istnieją w zasadzie dwa rodzaje metod
oceny końcowej, zależnie od stopnia, w jakim
możliwe jest określenie obiektywnych kryteriów
jakości: testowanie Qeżel i kryteria jakości są
rzeczywiście obiektywne i mierzalne) albo kon-
trola ja kości Qeżeli wymagany jest pewien osąd
subiektywny).
Kontrola jakości jest systematyczną, ustrukturyzo-
waną oceną produktu przeprowad zaną w sposób
zaplanowany, udokumentowany i zorganizowany.
Systematyczne, ale elastyczne podejście do kontroli
jakości może mieć zastosowanie:
• w czasie wytwarzania produktów danego typu
formalnie (tzn. zgodnie z tym, co uzgodniono
w czasie planowania jakości) lub nieformal-
nie (po prostu jako środek oceny j akości „prac
w toku");
• w celu potwierdzenia ukończenia i zatwierdze-
nia produktów;
• do testowania uzupełniającego, np. dla spraw-
dzenia wyników poprzednich testów.
Techniki inspekcji jakości mają szczególnie zastoso-
wanie, gdy wymagany jest profesjonalny osąd w celu
oceny, czy produkt odpowiada swojemu przeznacze-
niu. Techniki te mogą być stosowane w samym pro-
j ekcie jako elementy sterowania j akością oraz przez
niezależnych ekspertów jako część nadzoru jakości.
Przeglądy partnerskie i przeg l ądy kontynuacyjne są
przykladami działań nadzoru j akości, które wdrożyć
można, wykorzystując lub adaptując ogólną technikę
inspekcji. Poza wykorzystaniem inspekcji przez zespól
zarządzania projektem jako elementu sterowania,
przeprowadzanie systematycznych inspekcji jakości
może przynieść także cenne korzyści dodatkowe,
wspomagając budowanie zespołu.
Nawet jeżeli testowanie jest podstawową meto-
dą kontroli jakości, często zdarza si ę, że ktoś musi
sprawdzić, czy wyniki testu spełniaj ą kryteria sukcesu,
wobec czego nadal potrzebna jest prosta inspekcj a.
Istnieje wiele różnorod nych technik systematycznej
inspekcji, n iektóre wlaści we dla pewnych branży czy
rodzajów produktów. Metodyka PRINCE2 pozwala
na użycie tych technik, ale dostarcza także poży­
teczną technikę przeglądu jakości, która uzupelnia
wykorzystanie Opisów Produktów tworzonych
zgodnie z PRINCE2.
Formalne zatwierdzenie produktu może, ale nie
musi wynikać z przeglądu jakości. Może jednak ist·
nieć obowiązek, że produkty, które zostaly uznane
Jakość I 57
jako kompletne w czasie kontroli czy przeglądu,
muszą być przedstawione do zatwierdzenia odręb­
nemu organowi.
Technika przeglądu jakości według PRINCE2
Cele
• Ocena zgodności z ustalonymi kryteriami pro-
duktu w postaci dokumentu (lub w podobnej
formie, np. prezentacji czy wyników testu).
• Zaangażowanie kluczowych zainteresowa-
nych stron w sprawdzanie jakości produktu
i dzialania na rzecz szerszej akceptacji
produktu.
• Dostarczenie potwierdzenia, że produkt
został ukończony i jest gotowy do zatwier-
dzenia.
• Ustanowienie obiektu odniesienia dla produk-
tu na potrzeby sterowania zmianami.
Role w zespole przeglądu j akości
• Kierownik przeglądu - rola ta odpowiada za
całościowe przeprowadzenie przeglądu.
• Prezenter - rola ta przedstawia produkt do
przeglądu i reprezentuje wytwórcę(-ów) pro-
duktu. Prezenter koordynuje także i śledzi
działania następcze po przeglądzie, tj. wpro-
wadzenie w produkcie zmian uzgodnionych
przez zespół przeglądu jakości .
• Kontroler/Recenzent - rola ta dokonuje prze-
g l ądu produktu, przedstawia zastrzeżenia
i potwierdza wprowadzenie poprawek i/lub
ulepszeń.
• Administrator - rola ta zapewnia wsparcie
administracyjne kierownikowi przeglądu i zapi-
suje wynik przeglądu i dzialania następcze.
Minimalna forma przeglądu (wykorzystywana dla
prostych inspekcji, np. wyników testu) zaklada
tylko dwie osoby: jed n ą pełniącą role kierownika
przeglądu i kontrolera, dru gą pełn iącą role pre-
zentera i administratora.
Uwaga: przeg l ąd j akości jest techniką ogólnego
stosowania, którą wykorzystywać można poza
kontekstem projektu. Dlatego role występują­
ce w przeglądzie jakości nie mają konkretnego
związku z rolami w strukturze zespołu zarzą­
dzania projektem. W przypadku gdy Kierownicy
Projektów i Zespołów regularnie przewodniczą
przeglądom j akości, można osiągnąć dodatko-
we korzyści zwi ązane z budowaniem zespolu.
58 I J akość
Przewodniczenie przeglądom jakości wymaga
umiejętności mediacyjnych i zachowania nieza-
l eżności od wytwórcy produktu poddawanego
przeglądowi (podstawowym obowiązkiem jest
zapewnienie, żeby przegląd był przeprowadzony
prawi dłowo).
W celu przygotowania przegl ą du należy:
• przygotować przegląd pod względem admini-
stracyjnym (kierownik przeglądu/administrator);
• sprawdzić, czy produkt jest gotowy do prze-
glądu i potwierdzić dostępność kontrolerów
(kierownik przeglądu);
• rozpowszechnić kopie produktu i odpowied-
nie Opisy Produktu wśród zespołu przeprowa-
dzającego przegląd, pozostawiając kontrole-
rom wystarczająco dużo czasu na przygoto-
wanie si ę do przeglądu (prezenter);
• przeprowadzić przeg l ąd produktu zgodnie
z kryteriami jakości zawartymi w związanym
z nim Opisie Produktu (kontrolerzy);
• przedstawić listę zastrzeżeń kierownikowi
przeglądu i prezenterowi przed naradą prze-
glądu jakości (kontrolerzy);
• dokonać adnotacji na kopii produktu w przy-
padku stwierdzenia błędów ortograficznych/
gramatycznych i zwrócić j ą prezenterowi
(kontrolerzy);
• opracować skonsolidowaną l i stę zastrzeżeń
(kierownik przeglądu) i przesiać ją prezente-
rowi przed naradą.
Porządek narady przeg lądu jakości
• Przedstawienie uczestników, jeżeli to
konieczne (kierownik przeglądu).
• Przedstawienie produktu (prezenter) Bardzo
krótkie omówienie, obejmujące przeznacze-
nie produktu: kto go pot rzebuje, dlaczego
i j ak będzie działać.
• Najważniejsze/ogólne zastrzeżen ia (kierow-
nik przeglądu) Należy popros i ć każdego
kont rolera, aby przedstawił stwierdzone
przez siebie najważniejsze/ogólne zastrzeże­
nia dotyczące produktu. Zastrzeżenia ogól-
ne to takie, które występują wielokrotnie
w odniesieniu do produktu. Zespól przeglądu
jakości uzgadnia wszelkie działania związa­
ne z każdym przedstawionym zastrzeżeniem.
Protokolant zapisuj e te działania i obowiązki
związane z ich realizacją.
• Omówienie produktu (prezenter) Należy
przedstawić zespołowi przeglądu jakości
caly produkt, sekcja po sekcji lub strona po
stronie, za l eżnie od przypadku, przegląda ­
jąc skonsol i dowaną l istę zastrzeże ń i prosząc
o wyj aśnienia, gdzie to konieczne. Zespól
przeg l ąd u jakości uzgadnia działania zwią­
zane z każdym omawianym zastrzeżeniem.
Protokolant zapisuje działania i obowiązk i
związane z ich realizacją.
• Odczytanie uzgodnionych działań (admini-
strator) Potwierdzenie działań następczych
i związanych z nimi obowiązków.
• Ustalenie wyniku przeglądu (kierownik prze-
glądu) Należy doprowadzić zespół prze-
glądu j akości do podjęcia zbiorowej decyzji.
M ożliwe statusy produktu po przeg l ądzi e
j a kości to:
• Odebrany (przedstawiony produkt
w obecnym stanie odpowiada swojemu
przeznaczeniu).
• Odebrany warunkowo (przedstawiony
produkt odpowiada swojemu
przeznaczeniu pod warunkiem wykonania
pewnych uzgodnionych działań).
• Nieodebrany (produkt wymaga kolejnego
cyklu przeglądu j akości ).
• Zam knięcie przegląd u (kierownik przeglądu).
• Poinformowanie zainteresowanych stron
o wyniku (kierownik przeglądu).
Działania po naradzie przegląd u ja kości:
• Koordynowanie działań następczych
(prezenter).
• Potwierdzenie wykonania poszczególnych
działań (kontrolerzy wskazani w trakcie nara-
dy przeg l ądu).
• Po zakończeniu działań, potwierdzenie,
że produkt został odebrany (kierownik
przeg ląd u) .
• Zakomunikowanie wyniku przeglądu jako-
ści odpowiednim kierownikom/personelowi
wspierającemu (administrator).
• Przekazanie do akt projektu zapisów jakości
(administrator).
• Złożenie wniosku o zatwierdzenie produktu
(prezenter).

Wskazówki i porady
• Kontrolerzy Należy dokonać przeglądu pro-
duktu, a nie osoby prezentującej produkt.
Oznacza to unikanie personalizacji („ Ty „. ")
i występowa nie jako zespól („ My„. ").
• Kontrolerzy Powinni działać jako zespól,
ale odwolywać się do specjalistycznych kom-
petencji. Niektórzy kontrolerzy mogą zostać
wybrani, aby zająć się konkretnymi aspektami
produktu i ich uwagi mogą mieć większe zna-
czenie w dziedzinach ich specjalizacji.
• Kontrolerzy Podczas przeglądu jakości
nie należy przedstawiać spraw trywialnych
{ortografia, interpunkcja itp.), o ile nie jest
to zastrzeżen i e glówne/ogólne (np. jeżeli
dokument zostanie przedstawiony ważnemu
gronu osób, takiemu jak opinia publiczna).
• Kierownik przeglądu Powinien zachęcać
prezentera, aby utrzymywał równe tempo
w czasie omawiania produktu. Kontrolerzy
muszą mieć szansę na przedstawienie swo-
ich zagadnień, ale pozostawienie im zbyt
wiele czasu zachęca do czynienia uwag, któ-
rych by w innym przypadku nie poczyniono.
Prezenter nie powinien otwierać niepotrzeb-
nych dyskusji.
• Kierownik przeglądu Powinien doprowadzić
do zamknięcia każdego omawianego punktu
przez uzyskanie decyzji od zespolu przeg l ą du
jakości. Czy produkt na l eży zmienić, czy nie?
Nie powinien dopuszczać do zbaczania dys-
kusji na tematy uboczne. Musi pamiętać, że
celem przeglądu jest określenie usterek, a nie
znajdowanie rozwiązań prowadzących do
ich usunięcia. Należy unikać pokusy formulo-
wania i uzgadniania rozwiązań. Powinno to
zostać dokonane po przeglądzie.
• Kierownik przeglądu Powinien koncentro-
wać si ę na produkcie poddanym przeglądowi.
Nie pozwalać, by dyskusja przesuwala się na
inne powiązane produkty. Jeże l i wydaje się,
że mógl za istnieć problem związany z powią­
zanym produktem, na l eży si ę nim zająć jako
zagadnieniem poza naradą przeglądu jakości.
• Kierownik przeglądu Powinien upewnić się,
że kontrolerzy efektywnie uczestniczą w prze-
glądzie. Jego obowiązkiem jest zagwaranto-
wanie, że odebrany produkt odpowiada swo-
jemu przeznaczeniu.
Jakość I 59
• Kierownik przeglądu Jeżeli
kontroler nie
może uczestniczyć w przeglądzie, kierownik
przeglądu powinien przejąć od niego listę
zastrzeżeń i albo samemu je przedstawić
w jego imieniu, zaakceptować oddelegowa-
nego zastępcę, albo zastąpić go nowym kon-
trolerem.
• Prezenter Może się zdarzyć, że dzialania
następczego nie można wdrożyć albo nie
można go przeprowadzić w ramach uzgod-
nionych tolerancji, w takim wypadku pre-
zenter powinien przekazać zagadnienie
Kierownikowi Projektu.
• Zatwierdzający Jeżeli osoba {albo grupa),
która odpowiada za zatwierdzenie produktu,
uczestniczy w przeg l ądzie jakości, może być
moż l iwe zatwierdzenie produktu w ram ach
przeglądu.
Technika przeglądu jakości w PRINCE2 (i inne tech-
niki kontroli jakości) mogą dać dodatkowo znaczne
korzyści szczególnie w obszarach:
• Zaangażowania interesariuszy Kontrole jako-
ści są szansą na efektywną komunikację pomię­
dzy różnymi jednostkami funkcjona lnymi. Wielu
ważnych interesariuszy może m i eć bezpośredn i
kontakt z projektem tylko w trakcie przeg l ądów,
tak że stanowią one „okno" do projekt u. Jest to
szczególnie prawdziwe w przypadku użytkowni­
ków. Ustrukturyzowane kontrole jakości na l eżą
do najbardziej skutecznych sposobów angażo­
wania interesariuszy w sprawy projektu. Ogólnie
mówiąc, im bardziej systematyczne i efektywne
przeglądy, tym lepsze wrażenie wywierane na
interesariuszach.
• Przywództwo W wielu przypadkach skoncen-
trowanie się na jakości (jak w przypadku „bada-
nia, czy produkt odpowiada swojemu przezna-
czeniu") powoduje lepsze reakcje czlonków
zespolu przeg l ądu jakości (i użytkowni ków) n i ż
proste skoncentrowanie się na budżetach i har-
monogramach. Techniki kontroli jakości dostar-
czają często istotnych wskazówek i sposobów
„miękkiego wplywania" na efektywność zacho-
wań i podejmowania decyzji w czasie narad.
• Budowanie zespołu Formalne i nieformalne
kontrole jakości są szansą na skoncentrowanie
się na budowaniu efektywnego zespolu pro-
jektowego, którego czlonkowie rozum ieją swój
wzajemny wklad, potrzeby i priorytety.
60 I Jakość
• Rozwój osobowy uczestników Nowi pracowni-
cy uczą się od bardziej doświadczonych i dostrze-
gają pominięcia, których inni już nie dostrzegają.
Doświadczeni pracownicy korzystają z nowej
perspektywy, którą wnoszą nowicjusze.
• Dokumentacja jakości Spójne i ogólnie znane
zapisy jakości pozwalają na poprawę komunika-
cji oraz sposobów analizy miar jakości.
• Kultura jakości Technika przeglądu jakości
metodyki PRINCE2 jest techniką ogólnego stoso-
wania. Można jej używać w programach, projek-
tach i usługach w calej organizacji, co prowadzi
do pozytywnie odbieranej oraz powszechnie
znanej „kultury jakości".
6.3.2.2 Zapisy ja kości
Ważne jest gromadzenie dowodów pokazujących,
że zaplanowane dzialania dotyczące jakości zostaly
przeprowadzone. Te zapisy stanowią podstawę dla
wpisów w Rejestrze Jakości, dostarczając Kierowniko-
wi Projektu i Komitetowi Sterującemu pewności, że:
• produkty są rzeczywiście zakończone (i w kon-
sekwencji, że powiązane z nimi działania zostały
zakończone);
• produkty spelniają związane z nimi kryteria
jakości i odpowiadają swojemu przeznaczeniu
(alternatywnie - że istnieją zapisy wszelkich
wad jakościowych i dzialań korygujących);
• uzgodnione procesy byly przestrzegane;
• organy zatwierdzające i kluczowi dla produktu
interesariusze są usatysfakcjonowani;
• przeprowadzono planowane audyty i przekaza-
no stosowne raporty.
Zapisy jakości powinny zawierać odniesienia do
dokumentacji inspekcji jakości, takiej jak plan testów;
szczególy na temat wszelkich danych o „usterkach"
i szczególy dzi a lań wymaganych w celu naprawie-
nia blędów i pominięć w produktach pod legających
inspekcji oraz wszelkie związane z jakością raporty (na
przyklad z audytu). Gdy Wsparcie Projekt u otrzyma
te zapisy, może wprowadzić do Rejestru Jakości wpisy
dotyczące odnośnych produktów. W trakcie trwania
projektu oraz podczas jego zamykania, zapisy jako-
ści są cennym źródlem informacj i dla analiz zgodnie
z zasadą metodyki PRINCE2, że projekty powinny
„korzystać z doświadczeń". Na przykład miary jakości,
takie jak rodzaje usterek i występujące trendy, można
wykorzystać jako źródło nowych doświadczeń oraz do
usprawniania procesów.
6.3.2.3 Zapisy zatwierdzeń
Podczas gdy zapisy jakości dostarczają dowodów
na to, że każdy produkt spelnia wymagania, które
określono w jego Opisie Produktu, dobrą praktyką
jest uzyskanie zapisu, że produkt zostal zatwier-
dzony.
Metodyka PRINCE2 nie określa formatu ani treści
zapisów zatwierdzenia, ponieważ będą one zależ­
ne od wymaganego stopnia formalizmu, relacji
klient/dostawca oraz systemów zarządzania jako-
ścią zaangażowanych organizacji. Format zapisów
zatwierdzenia mógłby na przykład obejmować,
notatkę w protokole zebrania, mail, list, podpis na
dokumencie lub certyfikat.
6.3.2.4 Zapisy akceptacji
Produkty zatwierdzane są przez caly czas trwa-
nia projektu i odpowiedzialność za produkt może
nawet zostać przekazana klientowi jako część
stopniowego przekazywania produktów projektu.
Jednakże w procesie Zamykanie Projektu, ważne
jest sprawdzenie, czy uzyskano wszystkie ustalone
formy zatwierdzenia, a zapisy są przechowywane
dla celów audytu i/lub na potrzeby kontraktu.
Metodyka PRINCE2 używa określenia „akceptacja",
aby opisać ostateczne zatwierdzenie produktu koń­
cowego projektu. Akceptacja jest często wymagana
od więcej niż jednej grupy interesariuszy, np. osób,
które używają produktów projektu i osób, które je
utrzymują (w którym to przypadku obie kategorie
interesariuszy powinny być zaangażowane w defi-
niowanie odnośnych produktów, uczestniczenie
w inspekcjach jakości i ich zatwierdzanie w trakcie
projektu).
Akceptacja może być niepelna i mogą być przyzna-
wane udokumentowane „ustępstwa" (np. jeże li
w rozwi ąza n iu są blędy lub n ie spelniono w pelni
jakichś kryteriów wydajnościowych). W przypadku
gdy Komitet Sterujący przyzna! u stępstwa, może
być konieczn e zarekomendowanie dzialań n astęp­
czych dla później szych poprawek czy też napraw
dla odnośnych produktów.
6.4 OBOWIĄZKI
Tabela 6.3 przedstawia obowi ązki dotyczące tema-
tu Jakość. Więcej szczególów na temat ról zespolu
zarządzania projektem i powiązanych z nimi obo-
wiązków przedstawiono w Dodatku C.
 Jakość I 61

Tabela 6.3 Obowiązki dotyczące tematu Jakość

Rola Obowiązki

Kierownictwo organizacji lub Udostępnia szczególy systemu zarządzania jakością organizacji lub programu.
programu Zapewnia nadzór jakości.
Przewodniczący Zatwierdza Opis Produktu Końcowego Projektu.
Zatwierdza Strategię Zarządzania Jakością.

Potwierdza akceptację produktu końcowego projektu.

G łówny U żytkownik Dostarcza oczekiwania jakościowe klienta i kryteria akceptacji.
Zatwierdza Opis Produktu Końcowego Projektu.
Zatwierdza Strategię Zarządzania Jakością.
Zatwierdza Opisy Produktów dla produktów o kluczowym znaczeniu dla użytkownika.

Dostarcza zasobów dla przeprowadzenia przez użytkownika czynności związanych z jakością

i zatwierdzaniem produktów.
Akceptuje produkt końcowy projektu.
Główny Dostawca Zatwierdza Opis Produktu Końcowego Projektu Geżeli to właściwe).
Zatwierdza Strategię Zarządzania Jakością.

Zatwierdza metody jakości, techniki i narzędzia przyjęte w wytwarzaniu produktu.

Kierownik Projektu
Kierownik Zespolu
Nadzór Projektu
Dostarcza zasobów dla przeprowadzenia przez dostawcę czynności związanych z jakością .
Zatwierdza Opisy Produktów dla kluczowych produktów specjalistycznych.
Dokumentuje oczekiwania jakościowe klienta oraz kryteria akceptacji.
Przygotowuje Opis Produktu Końcowego Projektu (z użytkownikami).
Przygotowuje Strategię Zarządzania Jakością.
Przygotowuje i utrzymuje Opisy Produktów.
Zapewnia, że Kierownicy Zespołów wdrażają sposoby kontroli jakości uzgodnione w Opisach
Produktów i Grupach Zadań.
Wytwarza produkty zgodne z Opisami Produktów.
Zarządza sterowaniem jakością produktów dotyczących zespołu.
Kompletuje zapisy jakości.
Informuje Kierownika Projektu o statusie jakości produktów.
Doradza Kierownikowi Projektu w sprawach związanych ze Strategią Zarządzania Jakością.

Wspólpracuje z Komitetem Sterującym i Kierownikiem Projektu, dokonując przeglądów

Opisów Produktów.
Doradza Kierownikowi Projektu w sprawie doboru właściwych kontrolerów jakości/osób
zatwierdzających.

Nadzoruje w imieniu członków Komitetu Sterującego wdrożenie Strategii Zarządzania Jakością,

Wsparcie Projektu
tj. właściwe przeprowadzenie procedur zarządzania projektem i zapewniania jakości projektu.
Dostarcza wsparcia administracyjnego dla mechanizmów sterowania jakością.
Utrzymuje Rejestr Jakości i zapisy jakości.
Współpracuje z Kierownikami Zespołów i członkami zespolów w stosowaniu w projekcie proce-
sów dotyczących jakości.
•
 7 Plany
7.1 PRZEZNACZENIE
Przeznaczeniem tematu Plany jest ułatwienie
komunikacji oraz sterowania poprzez określenie
sposobów dostarczania produktów (gdzie, jak
i przez kogo oraz oszacowanie kiedy i za ile).
Skuteczne zarządzan i e projektami opiera si ę na
efektywnym planowaniu, ponieważ bez planu ta
kont rola nie j est możl iwa. Planowanie dostarcza
ca łemu personelowi zaangażowanem u w rea lizację
projektu informacj i o tym:
• co j est wymagane;
• jak zostanie to osiągn i ęte i przez kogo, przy
wykorzystaniu jakiego specj alistycznego sprzętu
i zasobów;
• kiedy wystąp i ą określ one zdarzenia;
• czy planowane wartości docelowe (dla czasu,
kosztów, jakości, zakresu, ryzyka i korzyści) są
osiągalne.
Opracowywanie i utrzymywanie wiarygodnych
planów dostarcza poziomu odniesienia, względem
którego można mierzyć postępy. Umożliwiają one
rozpowszechnianie informacji planistycznych wśród
interesariuszy w celu uzyskania ich zaangażowania
wspierającego realizację planu.
Sama czynnośćplanowania pomaga zespołowi
zarządzania projektem wybiegać myślą w przyszłość
w celu przeprowadzenia „myślowej symulacji reali-
zacji projektu". Taka próba umożliwia identyfiko-
wanie pominięć, powtórzeń, zagrożeń i szans oraz
zarządzenie nimi.
Temat Plany dostarcza ram służących do proj ekto-
wania, opracowywania i utrzymywania planów uży­
wanych w projekcie (Planu Projektu, Planów Etapów
i Planów Zespołu).
7.2 DEFINICJA PLANÓW
7.2.1 Czym jest plan?
Gdy prosi się o opisanie p lanu, wiele osób myśli zwy-
kle o diagramie paskowym Gantta.
Plan zgodny z PRINCE2 jest pojęciem obszerniej-
szym. Jest to dokument opisujący, jak, kiedy i przez
kogo ma być osiągnięty konkretny cel lub zbiór
celów. Cele te mogą dotyczyć produktów projektu,
terminów, kosztów, jakości i korzyści.
Dlatego plan musi zawierać wystarczające infor-
macje i szczegóły, aby potwierdzić, że te cele są
osiągalne.
Plany stanowią podstawową część systemu infor-
macji zarządczej, niezbędnego w każdym projekcie.
Ważn e jest, aby przez cały czas utrzymywać plany
w zgodności z Uzasadnieniem Biznesowym. Plan
wymaga zatwierdzenia i zaa ngażowan i a odpowied-
nich szczebli zespołu zarządza n i a projektem.
7.2.2 Czym jest planowanie?
Planowanie jest czynności ą lub procesem tworzenia
i utrzymywania planu. Terminem tym można także
posługiwać się do określ ania forma lnych procedur
wykorzystywanych w tym procesie, takich jak sporzą­
dzanie dokumentów i diagramów. Planowanie jest
niezbędne, niezależnie od rodzaju c.zy wielkości pro-
jektu; planowanie nie jest banalnym działaniem, lecz
ma kluczowe znaczenie dla powodzenia projektu.
Bez efektywnego planowania rezultat złożonych
projektów nie może być przewidziany w katego-
riach zakresu, jakości, ryzyka, terminów, kosztów
i korzyści. Bez planowania osoby zaangażowane
w zapewnienie zasobów nie mogą optymalizować
swoich działań.
Slabo zaplanowane projekty są powodem frustracji,
marnotrawstwa i przeróbek. W związku z tym nie-
zbędne jest poświęce n i e wystarczającego czasu na
etap planowania.
Metodyka PRINCE2 wymaga, by planowanie bylo
oparte na produktach.
7.2.3 Poziomy planu
Wszystkie aspekty planowania stają się tym trudniej-
sze, im bardziej plan wybiega w przyszłość. Okres,
dla którego możliwe jest dokładne planowanie,
nazywany jest „horyzontem planowania" . Szczegó-
łowe planowanie całego projektu na samym począt­
ku jest rzadko wskazane, a nawet jest niemożliwe.
66 I Plany
r- - - - - -----,
Plan organizacji
lub programu
L-- - - - -.-
••
- - - _,
-•
Plan Projektu
.I.
(Inicjowanie) (Dostarczanie)
Plan Etapu Plany Etapów
Plany Zespołów
Rysunek 7. 1 Poziomy planowania PRINCE2
W związku z tym plany powinny być sporządzane
na różnych poziomach ich zakresu i szczególowości
(patrz sekcja 2.4).
PRINCE2 zaleca trzy poziomy planowania w celu
odzwierciedlenia potrzeb różnych szczebli zarzą­
dzania zaangażowanych w projekt, etap lub pracę
zespolu. Opis Produktu dla planu przedstawiono
w Dodatku A.
Poziomy planowania występujące w metodyce
PRINCE2 pokazano na Rysunku 7 .1.
Plan Projektu jest tworzony w procesie Inicjowanie
Projektu.
Plan Etapu inicjowania jest tworzony w procesie
Przygotowanie Projektu, natomiast każdy kolejny
Plan Etapu jest tworzony w procesie Zarządzanie
Końcem Etapu. Należy pamiętać, że ponieważ Plan
Etapu inicjowania jest tworzony przed Planem Pro-
jektu, ma na niego wplyw plan firmy lub programu
(lub im równoważny) pochodzący z organizacji zle-
caj ącej projekt.
Plany Zespolów są tworzone w procesie Zarządzanie
Dostarczaniem Produktów.
Jedynym innym produktam zarządczym o nazwie
plan w PRINCE2 jest Plan Przeglądu Korzyści (więcej
szczególów na ten temat można znaleźć w Rozdzia-
le 4). Obejmuje on dzialania w trakcie rea lizacji pro-
jektu oraz po jego zakończeniu i w związku z tym
może być częścią planu organizacji lub programu.
Plan Przeglądu Korzyści obejmuje szczeble zarządza­
nia organizacji, projektu i etapu.
. -......
••
••
•
••
•
•••••••••••••••••• ~ Plany Nadzwyczajne
gdy konieczne
7.2.4 Plan Projektu
Plan Projektu przedstawia deklarację tego, jak
i kiedy mają być osiągnięte docelowe wska źni ki
wykonania dotyczące czasu (terminów), kosztów,
zakresu i jakości, określ ając także glówne produkty,
dzialania i zasoby potrzebne do realizacji projektu.
Plan Projektu:
• dostarcza planowanych kosztów projektu i ter-
minów na potrzeby Uzasadnienia Biznesowego
oraz identyfikuj e g lówne punkty kontrol ne,
takie jak etapy zarządcze i kamienie milowe;
• jest wykorzystywany przez Komitet Sterujący
jako obiekt odniesienia (bazowy), względem któ-
rego monitorowane są postępy projektu etap po
etapie;
• powinien być zgodny z planem kierownictwa
organizacji lub programu.
7 .2.5 Plany Etapów
Plan Etapu jest wymagany d la każdego etapu
zarządczego. Plan Etapu podobny jest w swej
zawartości do Planu Projektu, lecz k ażdy z elemen-
tów powinien być sprowadzony do poziomu szcze-
gólowości wymaganego do stworzenia wystarczają­
cej podstawy do sprawowania codziennej kontroli
przez Kierownika Projektu.
Ka żdy Plan Etapu dla n astępnego etapu zarząd­
czego j est tworzony pod koniec bieżącego etapu
zarządczego. Takie podejście pozwala na to, by
Plan Etapu:

• był
przygotowywany w momencie n iezbyt odle-
głym od czasu, w którym planowane zdarzenia
będą mieć miejsce;
• obejmowa ł dużo krótszy okres niż Plan Projektu
(łagodząc tym samym problem horyzontu plano-
wania);
• był przygotowywany ze znajomości ą wyników
wcześniejszych etapów zarządczych.
Dalsze informacje dotyczące podziału projektu na
etapy zarządcze można zna l eźć w Rozdziale 10.
7 .2.6 Plany Zespołów
Plan Zespołu jest przygotowywany przez Kierownika
Zespołu w celu ułatwi enia real izacji jednej lub ki lku
Grup Zadań. Plany Zespołów nie są obowiązkowe,
a ich potrzebę i l i czbę określ a wie l kość i złożoność
projektu oraz liczba zaangażowanych zasobów.
PRINCE2 nie określa formatu ani zawartości Planu
Zespołu. Może istnieć więcej n i ż jeden zespół w pro-
j ekcie i każdy zespół może pochodzi ć z odrębnych
organizacji stosujących różne standardy zarządzania
projektami (niekoniecznie PRINCE2). W niektórych
relacj ach klient/dostawca poznanie przez Kierown ika
Projektu szczegółów Planu Zespołu dostawcy mogło­
by nawet być niewskazane; zamiast tego należy
dostarczyć wystarczających informacji sumarycznych
w celu umożliwienia Kierownikowi Projektu sprawo-
wania kontroli. W związku z tym formalizm Planu
Zespołu może się zmieniać poczynając od harmono-
gramu dołączonego po prostu do Grupy Zadań aż po
w pełni sformułowany plan podobny do Planu Etapu.
Kierownik Zespołu lub Kierownicy Zespołów mogą
tworzyć swoje Plany Zespołów równo legle z two-
rzeniem przez Kierownika Projektu Planu Etapu d la
etapu zarządczego .
7.2.7 Plany Nadzwyczajne
Plan Nadzwyczajny jest planem przygotowywanym
dla odpowiedniego szczebla zarządzania w celu
przedstawienia działań wymaganych do wyjścia
z sytuacji, w której doszłoby do odchylenia wycho-
dzącego poza tolerancję. Po zatwierdzeniu Plan
Nadzwyczaj ny zastąpi plan, którego dotyczy sytuacja
nadzwyczaj na i stanie się nowym obiektem odnie-
sienia Planu Projektu lub, odpowiednio, Planu Etapu
bieżącego.
Jeżel iPlan Etapu ma być zastąpiony przez Plan Nad-
zwyczajny, wymaga to zatwierdzenie przez Komi-
tet Steruj ący. Kwestia zastąpienia Planu Projektu
Planem Nadzwyczajnym powinna być przedłożona
Plany I 67
przez Komitet Sterujący kierownictwu organizacji
lub programu, jeżeli wprowadzana zmiana wykra-
cza poza uprawnienia Komitetu Sterującego.
Plan Nadzwyczaj ny jest opracowywany na tym
samym poziomie szczegółowości, co plan, który
będzi e zastąpiony. Plan Nadzwyczajny przej muj e
dane o wykonaniu z aktualnego planu i obejmu-
j e okres do końca zastępowanego planu. Planów
Nadzwyczajnych nie sporządza się dla Grup Zadań.
Jeżeli Kierownik Zespołu przewiduje, że zlecona
Grupa Zadań może przekroczyć tolerancje, powinien
on zawi adomić o tym Kierownika Projektu poprzez
zgłoszenie zagadnienia. Jeżeli zagadnienie dotyczą­
ce Grupy Zadań można rozwi ązać w granicach tole-
rancji etapu, Kierownik Projektu podejmie działania
korygujące, aktua l izując Grupę Zadań lub wydając
nową Grupę(-y) Zadań i odpowiednio i nstruując Kie-
rownika Zespołu(ów).
Dalsze wyjaśnienia dotyczące rodzaj ów i wykorzy-
stania tolerancji w metodyce PRINCE2 znajdują si ę
w Rozdziale 1O.
7.3 PODEJ ŚCI E PRINCE2 DO PLANÓW
7 .3.1 Filozofia planowania
Filozofia dotycząca opracowywania planów
w PRINCE2 polega na tym, że w pierwszej ko lej no-
ści identyfikuje się wymagane produkty, a dopiero
potem są identyfikowane dz i ałan i a, zależności
i zasoby wymagane do dostarczenia tych ziden-
tyfikowanych produktów. Podej ście to jest nazy-
wane planowaniem opartym na produktach i jest
wykorzystywane do przygotowania Planu Projektu,
Planu Etapu i ewentualnie Planu Zespołu . Rysunek
7 .2 przedstawia kroki wymagane do przygotowa-
nia planu w sposób zgodny z metodyką PRINCE2.
Każdy krok w procedurze planowania może wyma-
gać powtórzenia po wykonaniu następujących po
nim kroków (na przykład, podczas przygotowania
harmonogramu w przypadku zidentyfikowania
dodatkowych działań lub za l eżności).
7.3.2 Warunki wstępne planowania
- projektowanie planu
Należy podjąć decyzj ę,
jak najlepiej zaprezentować
plan, biorąc pod uwagę określone audytorium i spo-
sób wykorzystania planu, wraz z prezentacją i uk ła­
dem graficznym planu, narzędzi ami planistycznymi,
metodami szacowania, poziomami planu i meto-
dami monitorowania, które będą wykorzystane
68 I Plany

Projektowanie planu
Warunki wstępne
(7.3.2)

Okreś l an i e i analizowanie produktów

(7 .3.3)

.><
>-
N
Identyfikowanie dzialań i zależności
2':' (7.3.4)
QI
·-
c ,.._~

ro ,..;
~ .
oC
N Szacowanie
·-
-ro (7.3.S)
Powtarzane dla:
c • Planu Projektu
<(
• Planu Etapu
• Planu Zespołu (opcjonalnie)
Harmonogramowanie
(7.3.6)

Dokumentowanie planu
(7.3.8)

Rysunek 7.2 Podejście PRINCE2 do planów

w projekcie. Decyzje te mogą przykładowo dotyczyć
wykorzystania wykresów zamiast opisów teksto-
wych I będą częściowo podporządkowane standar-
dom przyj ętym w projekcie.
Jeżel iprojekt j est częścią programu, program może
posiadać wspólne podejście do planowania pro-
jektu. Może to obejmować standardy, takie jak np.
poziom planowania oraz narzędzia. Sędą one punk-
tem wyjścia dla opracowania każdego Planu Projek-
tu. Wszelkie zmiany specyficzne dla konkretnego
projektu powinny być uwypuklone i przedstawione
do zatwierdzenia kierownictwu programu. Mogą
również istn i eć standardy firmowe dotyczące pla-
nowania i narzędzi kontroli albo klient może sobie
zastrzec zastosowanie określonego zestawu narzę­
dzi. Wybór narzędzia planowania może zależeć od
stopnia złożoności projektu, stąd też może zaistnieć
potrzeba odroczenia tego wyboru do chwili, gdy
poziom złożoności będzie znany.
Metody szacowania, które mają być wykorzystane
w planie, mogą mieć wpływ na konstrukcję planu,
więc decyzje w sprawie tych metod należy podejmo-
wać jako część proj ektowania planu.
Wykorzystanie narzędzi planistycznych nie jest
obowi ązkowe, ale może zaoszczędz ić dużo czasu,
jeśli plan ma być regularnie aktualizowany i zmie-
niany. Właściwe narzędzie może równ i eż umożl iwi ć
potwierdzenie, że prawidłowe zależności zosta ły
uwzględnione i że nie uległy one zniekształceniu
wskutek aktualizacji planu.
7 .3.3 Okreś l an ie i analizowanie
produktów
PRINCE2 wykorzystuje technikę znaną jako plano-
wanie oparte na produktach w celu identyfikowa-
nia, określ ania i analizowania produktów ujętych
w planie, jak to pokazano na Rysunku 7.3.
Planowanie oparte na produktach zwykle przebiega
iteracyjnie. W przypadku Opisów Produktów ozna-
cza to, że początkowo opis może obejmować po
prostu nazwę i określenie przeznaczenia. W związku
z tym w poniższym opisie termin „utworzyć" (np.
„utworzyć Opis Produktu") powinien być interpreto-
wany jako „rozpocząć tworzenie, a następnie kom-
pletować dalej na tyle, na ile jest to właściwe, i tak
szybko, jak to jest wystarczające". Format i sposób
przedstawienia struktury podzi ału produktów i dia-

Sporządzanie Opisu
Produktu Końcowego Projektu (7.3.3.1)
Tworzenie struktury podzia łu produktów
(7.3.3.2)
Tworzenie Opisów Produktów
(7.3.3.3)
Tworzenie diagramu następstwa produktów
(7.3.3.4)
Rysunek 7.3 Technika planowania opartego na produktach
gramu następstwa produktów jest uzależniony od
indywidualnych preferencji. Przykłady zostały poda-
ne w Dodatku D.
Korzyści wynikające z planowania opartego na pro-
duktach obejmują:
• Jednoznaczne i spójne identyfikowanie oraz
dokumentowanie produktów ujętych w planie
i wzajemnych za l eżności między nimi. Zmniejsza
to ryzyko zaniedbania lub pom i nięci a ważnych
aspektów zakresu planu.
• Usuwanie wszelkich niejasności dotyczących
oczekiwań stron projektu.
• Angażowanie użytkowników w określanie
wymagań dla produktu, zwiększając w ten spo-
sób ich zaangażowanie i zmniejszając prawdo-
podobieństwo wystąpienia sporów w trakcie
zatwierdzania produktu.
• Poprawę komunikacji: struktura podziału pro-
duktów i diagram następstwa produktów sta-
nowią proste i efektywne środki podzia łu zadań
oraz omawiania opcji dotyczących zakresu i for-
muły rea lizacj i, które na l eży przyjąć dla projektu.
• Wyjaśnian i e granic zakresu planu: określ anie
produktów, które wchodzą w zakres planu
i tych, które znajdują się poza jego zakresem
oraz stwarzanie podstaw dla sterowania zmia-
nami, unikając w ten sposób wprowadzania nie-
kontrolowanych zmian lub „pełzania zakresu".
• Identyfikowanie produktów, które są zewnętrz­
ne wzg l ędem zakresu planu, ale które są nie-
zbędne do j ego realiz.acji i przydzielenie ich
innym projektom łub organizacjom.
Plany I 69
Tylko dla Planu Projektu
Dla wszystkich poziomów planu
• Umożliwienie opracowywania Grup Zadań dla
dostawców.
• Uzyskanie jednoznacznego uzgodnienia zakresu
obowiązków dotyczących wytworzenia, przeglą­
du i zatwierdzania produktów.
7.3.3. 1 Sporządzanie Opisu Produktu
Końcowego Projektu
Pierwszym zadaniem w planowaniu opartym na
produktach jest sporządzenie Opisu Produktu
Końcowego Projektu. Główny Użytkownik jest co
prawda odpowiedzialny za określenie produktu pro-
jektu, w praktyce jednak Opis Produktu Końcowego
Projektu zazwyczaj sporządza Kierownik Projektu
w porozumieniu z Głównym Użytkownikiem i Prze-
wodniczącym. Należy dołożyć wszelkich wysiłków,
aby ten Opis Produktu był od samego początku
możliwie jak najbardziej kompletny. Sugestie doty-
czące zawartości Opisu Produktu Końcowego Pro-
jektu przedstawiono w Dodatku A.
7.3.3.2 Tworzenie struktury podziału
produktów
W p lanie wydziela si ę jego główne produkty, które
można dalej podzielić aż do osiągnięcia odpowied-
niego poziomu szczególowości planu. Produkt
niższego poziomu może wchodzić w skład tylko
jednego produktu wyższego poziomu. Wynikająca
z tego hierarchia produktów jest znana pod nazwą
struktury podziału produktów.
Podczas tworzenia struktury podziału produktów
na l eży rozważyć następujące kwestie:
70 I Plany
• W tworzenie struktury podziału produktów
angażuje się zazwyczaj zespół osób, które mogą
reprezentować odmienne interesy i różne umie-
jętności związane z wynikiem planu.
• W celu zidentyfikowania produktów przeprowa-
dza się zwykle w sposób zorganizowany burzę
mózgów (na przykład przy wykorzystaniu karte-
czek samoprzylepnych łub tablicy konferencyjnej)
w celu zapisania każdego zidentyfikowanego
produktu zaraz po jego zidentyfikowaniu.
• Kiedy zespół tworzy strukturę podziału produk-
tów, będzie to prawdopodobnie obejmować dys-
kusję na temat sposobu podziału produktów. Dla
przykładu, jeżeli wynikiem planu ma być skom-
puteryzowany system księgowy, użytkownicy
mogą chcieć podzielić ten system na Należności,
Wierzytelności, Księgę Główną itp. Dostawcy
mogą natomiast preferować podział na Ekrany,
Raporty, Bazy Danych itp. Żaden z tych podziałów
nie jest nieprawidłowy, ale zespół zarządzania
projektem musi osiągnąć porozumienie, które
podejście zostanie wykorzystane w strukturze
podziału produktów (a tym samym w planie).
• Przydatne jest zidentyfikowane produktów
zewnętrznych wymaganych w planie. Produkty
zewnętrzne albo już istnieją, albo są tworzone
lub aktualizowane poza zakresem planu, a są
potrzebne do wytworzenia jednego lub kilku
produktów p lanu. Dla przykładu, projekt doty-
czący zamówień publicznych będzi e obejmować
oferty uczestników przetargu jako produkty
zewnętrzne. Kierownik Projektu nie ponosi
odpowiedzialności za tworzenie produktów
zewnętrznych, pon ieważ będą one dostarcza-
ne przez strony zewnętrzne wzg l ędem zespolu
zarządzania projektem. Dla każdego produktu
zewnętrznego powinien i stnieć odpowiadający
mu wpis w Rejestrze Ryzyk opisujący szczegó-
łowo zagrożenie dla planu w przypadku opóź­
nień lub niezgodności z wymaganą specyfika-
cją. N a l eży rozważyć, czy produkty zewnętrzne
wymagają spo rządzenia Opisów Produktów
w celu zmniejszenia prawdopodobieństwa,
że nie spełnią one oczekiwań.
• Podczas stosowania planowania opartego na
produktach, ważne jest rozważenie, czy należy
uwzględnić różne stadia wytwarzania konkretne-
go produktu. Przykładem stadiów produktu może
być „maszyna rozmontowana, maszyna przetrans-
portowana i maszyna powtórnie zmontowana".
Wskazane może być zidentyfikowanie różnych
stadiów jako oddzielnych produktów, tam gdzie
każde stadium wymagałaby własnego Opisu
Produktu z różnymi kryteriami jakości i kontro-
lami jakości. Może to być szczególnie przydatne,
gdy odpowiedzialność za wytworzenie każdego
stadium produktu zostanie przekazana przez
jeden zespół innemu zespołowi . Można ewentual-
nie zastosować j eden Opis Produktu, obejmujący
kryteria jakości, które produkt musi spelniać, aby
uzyskać zatwierdzenie każdego stadium.
• Podczas przedstawiania diagramu struktury
podzialu produktów, należy rozważyć wykorzy-
stanie różnych ksztaltów, stylów lub kolorów dla
różnych typów produktów. Dla przykładu, pro-
stokąty mogą być wykorzystane na diagramie
struktury podziału produktów do oznaczenia
większości rodzajów produktów, ale przydatne
może być zastosowanie innych kształtów, takich
jak elipsy lub kółka dla od różnien i a produktów
zewnętrznych . Kolory można wykorzystać do
oznaczenia, który zespół jest odpowiedzialny za
produkt lub na którym etapie produkt zostanie
wytworzony.
• Jeże l i projekt jest podzielony na szereg etapów,
produkty dla każdego etapu zostają pobrane
ze struktury podzia łu produktów w celu stwo-
rzenia struktury podziału produktów dla etapu.
Struktury te można rozszerzyć o dodatkowe
poziomy szczegółowości i w ten sposób „dodat-
kowe produkty" mogą być dodane w celu
uzyskania poziomu szczegółowości wymaga-
nego w Planie Etapu. Na l eży pamiętać, aby na
diagramach Planu Etapu stosować takie samo
nazewnictwo, co na diagramach, które zosta-
ły wykorzystane w Planie Projektu. Stworzenie
diagramów Planu Etapu może doprowadzić do
przemyśl eń wymagających dalszych modyfikacji
diagramów Planu Projektu w celu zachowania
spójności.
• W niektórych przypadkach stosowany w organi-
zacji model cyklu życia produktu może posiadać
z góry usta l oną strukturę podziału produktów
i diagram następstwa produktów dla najczęściej
spotykanych typów projektów, a także zbiór zary-
sów Opisów Produktów dla typowych produktów.
W takich przypadkach nie należy pomijać kroków
przewidzianych w technice PRINCE2 planowania
opartego na produktach, lecz nal eży je wykorzy-
stać w celu zweryfikowania kompl etności wszel-
kich materiałów z takiego zbioru. Ponieważ każdy
projekt jest niepowtarzalny, mogą występować
dodatkowe wymogi dla produktów konkretne-
go projektu lub nieznaczne różnice w kryteriach

jakości; lokalizacj e mogą się różn ić albo zaanga-
żowane osoby i zakresy obowi ązków mogą być
różn e. Ponadto modele cyklu życia często obej-
mują tylko jeden aspekt zakresu projektu.
7.3.3.3 Tworzenie Opisów Produktów
Sporządzan i e Opisu Produktu jest wymagane dla
każdego zidentyfikowanego produktu. Podczas
tworzenia Opisu Produktu na l eży rozważyć n astępu­
j ące kwestie:
• Opisy Produktów powinny być tworzone możl i ­
w ie jak najszybciej po zidentyfikowaniu potrzeby
produktu. Początkowo mogą to być „szkielety"
zawi erające niewiele informacji poza nazwą
i identyfikatorem. Będą one doprecyzowa-
ne i zmieniane w m i arę, jak produkt stanie się
bardziej zrozumialy i zostaną wykonane dalsze
kroki planistyczne.
• Opis Produktu powinien zostać uznany za obiekt
odniesienia wraz z zatwierdzeniem planu prze-
widującego wytworzenie tego produktu. Jeżeli
produkt zostanie następnie zmieniony, Opis
Produktu musi równ i eż być poddany procedurze
sterowania zmianami.
• Co prawda odpowi edzia l ność za stworzenie
Opisów Produktów of icjalnie spoczywa na
Kierowniku Projektu lub Kierowniku Zespolu,
lecz wskazane jest zaangażowan i e przedsta-
w icieli danej dziedziny, posiadających specjali-
styczną wiedzę na temat produktu oraz osób,
które będą korzystać z przedmiotowego pro-
duktu. Te ostatnie osoby z pewnością powinny
być objęte procesem konsultacji przy określaniu
kryteriów jakości dla produktu.
• Sporządzone Opisy Produktów mogą być wyko-
rzystane do innych projektów w tym samym pro·
gramie lub organizacj i. W tym celu należy stwo-
rzyć zbiór Opisów Produktów do ponownego
wykorzystania, a także wdrożyć mechanizm służą·
cy do wprowadzania Opisów Produktów do tego
zbioru. Kierownik Projektu powinien w zwi ązku
z tym korzystać z tego zbioru w celu sprawdze-
nia, czy któreś ze znaj duj ących si ę tam Opisów
Produktów nadają się do ponownego wykorzysta-
nia i/łub modyfikacji dla potrzeb projektu.
• J eże l i istnieje już szczegółowa specyfikacja
wymagań dla danego produktu, można j ą wyko-
rzystać jako odpowiednik Opisu Produktu, pod
warunkiem, że specyfikacja wymagań obejmuje
składniki i spełnia kryteria j akości oczekiwane od
Opisu Produktu. Można też ewentualnie stwo-
Plany I 71
rzyć Opis Produktu z odniesieniami do treści spe-
cyfikacji wymagań tam, gdzie jest to właściwe.
• W przypadku małych projektów n i ezbędne
może być jedynie stworzenie Opisu Produktu
Końcowego Projektu.
• Kryteria jakości, maj ące na celu odróżnienie pro-
duktu, który można odebrać, od produktu, któ-
rego nie można odebrać, wymagają rozważnego
przemyślenia. Jednym ze sposobów sprawdzenia
wystarczalności kryteriów jakości j est zadanie
pytania: „Na podstawie czego poznam, czy prace
nad produktem zostały ukończone, czy tylko
wstrzymane?".
7.3.3.4 Tworzenie diagramu następstwa
produktów
Diagram następstwa produktów powinien być stwo-
rzony w celu zidentyfikowania i określen i a kolejno-
ści wytwarzania produktów ujętych w planie oraz
za l eżności m i ędzy nimi.
Diagram następstwa produktów identyfikuje rów-
nież powiązania z wszelkimi produktami, które
wykraczają poza zakres planu. Prowadzi to w natu·
ra lny sposób do uwzględn i enia niezbędnych dzia łań
i dostarcza informacji dla innych technik planistycz-
nych, takich jak szacowanie i harmonogramowanie.
Podczas tworzenia diagramu następstwa produktów
należy rozważyć następujące kwestie:
• Chociaż odpowiedzialność za stworzenie dia-
gramu następstwa produktów ponosi Kierownik
Projektu lub Kierownik Zespołu, wskazane jest
włączenie do tych prac osób, które mają wytwo-
rzyć lub przyczynić si ę do wytworzenia produk-
tów ujętych w planie.
• Zamiast przygotowania diagramu następstwa
produktów dopiero po sporządzeniu struktu-
ry podziału produktów, niektórzy planiści wolą
tworzyć diagram następstwa produktów równo-
legle ze strukturą podzia łu produktów.
• Diagram następstwa produktów wymaga zasto-
sowania bardzo niewielu symboli. Każdy pro-
dukt, który ma być wytworzony w ramach planu,
jest identyfikowany (na przykład może być wpi-
sany w prostokąt), a następnie pokazana jest
kolejność wytwarzania tych produktów (prosto·
kąty mogą na przykład być po łączone ze sobą za
pomocą strzałek). Wszelkie produkty, które już
istnieją lub które pochodzą z prac wykorzysty-
wanych poza zakresem danego planu, powinny
być wyraźnie zidentyfikowane jako produkty
72 I Plany
zewnętrzne
(na przykład mogą być wpisane
w figurę o innym kształcie, powiedzmy elipsę).
• Przydatne może być dodanie punktu począt­
kowego na diagramie następstwa produktów,
z którego będą wychodzić połączenia z wszyst-
kimi produktami wejściowymi. Diagram następ­
stwa produktów posiada zawsze tylko jeden
punkt początkowy, jeżeli jednak istnieje w iele
produktów wejściowych, pokazanie tego punktu
pozwala zapobiec pominięciu niektórych z tych
produktów. Symbol ten staje się poprzednikiem
wszystkich produktów wejściowych i będzie jedy-
nym symbolem na diagramie następstwa pro-
duktów, który nie jest uwzględniony w struktu-
rze podziału produktów.
7.3.4 Identyfikowanie działań i zależności
7.3.4. 1 Działania
Samo zi dentyfikowanie produktów może nie być
wystarczające dla celów harmonogramowania
i kontroli. Działania wymagane do stworzenia lub
przekształcenia każdego z planowanych produktów
należy zidentyfikować, aby uzyskać pełniejszy obraz
obciążenia pracą w tworzonym planie.
Istnieje szereg sposobów identyfikowania działań,
w tym m.in.:
• Sporządzenie od rębnej listy dzialań, przy jedno-
czesnym wykorzystaniu diagramu następstwa
produktów jako źród ła informacji.
• Pobranie produktów ze struktury podzialu pro-
duktów i stworzenie struktury podziału prac
(ang. Work Breakdown Structure - WBS) w celu
zdefiniowania wymaganych działań.
Działania powinny obejmować zarówno działania
zarządcze i dotyczące kontroli jakości, jak i działania
potrzebne do wytworzenia produktów specjalistycz-
nych. Działan i a powinny obejmowa ć także wszelkie
dzialania wymagane do współdziałania ze stronami
zewnętrznymi. Na przykład uzyskanie produktu
z zewnętrznego źród ła lub przekształcen i e produk-
tów zewnętrznych w coś, czego plan wymaga.
Należy się wystrzegać „eksplozji" dzialań poza
poziom szczegółowości odpowiedni dla konkretne·
go poziomu planu. W razie wątpliwości należy trzy-
mać się prostych rozwiązań.
7.3.4.2 Zależności
Wszelkie zależności pomiędzy działaniami (i produk-
tami) powinny również być zidentyfikowane. Istnieją
dwa rodzaje zależności: wewnętrzne i zewnętrzne.
Przykładem zależności wewnętrznej jest to, że dzia-
łanie C nie może się rozpocząć, dopóki działania A i B
nie zostaną zakończone. Za l eżnościami zewnętrzny­
mi mogą być przykładowo:
• dostawa produktu wymaganego przez ten pro·
jekt z innego projektu;
• dostarczenie zamówienia przez użytkownika;
• podjęcie decyzji przez kierownictwo programu.
7.3.5 Szacowanie
Decyzję o tym, ile czasu i zasobów potrzeba na
wykonanie danej pracy o odpowiednim standardzie
wykonania na l eży podjąć poprzez:
• Zidentyfikowanie rodzaj u wymaganego zasobu.
Mog ą być potrzebne specyficzne umiejętno­
ści, w za l eżności od rodzaju i złożoności planu.
Wymagania mogą obejmować zasoby inne niż
zasoby osobowe, takie jak np. sprzęt, koszty
podróży łub zasoby pieniężne.
• Oszacowanie nakładów pracy wymaganych dla
każdego działania z podziałem na poszczególne
rodzaje zasobów. W tym momencie oszacowania
będą przybliżone, w związku z czym będą mieć
charakter tymczasowy.
Przykłady technik szacowania
• Szacowanie od góry Po uzyskaniu dobrego
ogólnego oszacowania dla planu (cokolwiek
to oznacza), można j e podzielić na poziomy
wynikające ze struktury podzi ału produktów.
Dla przykładu, zwyczajowo przyjmuje się, że
wytworzenie może stanowić SOo/o, a testowa-
nie - 25% ogółu nakładów. Należy podzielić
wytworzenie i testowanie na ich części skła­
dowe, a następnie odpowiednio rozdzielić
nakłady pracy.
• Szacowanie z dołu Każda indyw idualna
praca jest szacowana według swojej własnej
wartości. Prace są n astępnie sumowane w celu
znalezienia oszacowanej wartości nakładów
działań sumarycznych na różnych poziomach
oraz dla całego planu.
• Szacowanie od góry i z dołu Najpierw
oblicza się ogólne oszacowanie dla planu.
Indywidualne oszacowania są następnie obli-
czane łub pobierane z poprzednich planów,
reprezentując relatywne wagi zadań. Ogólne
oszacowanie zostaje wówczas rozpisane na
poszczególne zadania sumaryczne i szczegó-

lowe przy wykorzystaniu liczb z szacowania
z dolu do góry jako wag.
• Szacowanie przez analogię Istnieje wiele
danych na temat wymaganych nakladów
pracy oraz okresu trwania poszczególnych
prac. W miarę upływu czasu organizacja może
zebrać swoje własne dane historyczne doty-
czące przeprowadzonych przez nią projektów
(wcześniejsza praktyka łub zdobyte doświad­
czenia). Jeżeli takie dane istnieją, przydatne
może być odniesienie ich do podobnych pro-
jektów oraz wykorzystanie tych danych do
oszacowań.
• Szacowanie parametryczne Opieranie osza-
cowań na danych pomiarowych/empirycznych,
jeżeli to możliwe (dla przykładu, w sektorze
budowlanym i stn i eją modele szacowania,
które pozwalają przewi dzieć zapotrzebowa-
nie na materiały, nakłady pracy i czas trwania
budowy na podstawie specyfikacji budynku).
• Szacowanie jednopunktowe Wykorzystanie
przykładowych danych do obliczenia jednej
wartości, która ma służyć jako „najlepsze
przybliżenie" dla czasu trwania działania.
• Szacowanie trzypunktowe Poproszenie
odpowiednio wyszkolonych osób o podanie
ich najbardziej optymistycznych, najbardziej
prawdopodobnych i najbardziej pesymistycz-
nych szacunków. Wartość, którą Kierownik
Projektu powinien wybrać, to średn ia ważona
tych trzech szacunków.
• Metoda Delphi Polega na uzyskaniu pomy-
slów i rozwiązań problemów od grupy osób
bez konieczności ich bezpośredniego spo-
tkania. W celu uzyskania oszacowania wyko-
rzystuje się szereg kwestionariuszy uzupeł­
nianych sumarycznymi informacjami i infor-
macjami zwrotnymi z wcześniej uzyskanych
odpowiedzi.
Szacowanie nie może zagwarantować w pełn i
dokładności, ale daje w praktyce ogólny obraz
kosztów i czasu wymaganych do wykonania planu.
Oszacowania będą się z pewnością zmieniały,
w miarę jak wiedza o projekcie będzie wzrastala.
Oszacowania mogą i powinny być kwestionowa-
ne, ponieważ te same prace wykonywane w tych
samych warunkach mogą być różnie oszacowane
przez różne osoby łub przez tę samą osobę w róż­
nym czasie.
Plany I 73
Podstawowe zasady dotyczące szacowania
Wiele wydawnictw książkowych i programów
komputerowych obejmuje pewne podstawo-
we zasady pozwalające zapewnić sporządzenie
dokładnego i rea listycznego oszacowania. Przy-
kłady takich zasad planowania obejmują:
• Należy przyjąć za łożen i e, że
zasoby będą pro-
duktywne przez, przykładowo, okolo soo;., ich
normatywnego czasu pracy.
• Zasoby pracujące nad wieloma projektami
potrzebują więcej czasu na wykonanie zadań
z uwagi na czas stracony na przechodzenie od
jednego projektu do drugiego.
• Ogólnie rzecz biorąc, ludzie często zbyt opty-
mistycznie zakładają, że wykonanie zadań zaj-
mie im mniej czasu niż w rzeczywistości.
• Należy wykorzystać doświadczenia własne
i innych osób.
• Na l eży zapewnić, że osoba odpowiedzialna za
stworzenie produktu będzie również odpowie-
dzialna za przygotowanie oszacowań nakła­
dów pracy.
• Należy zawsze uwzględnić rezerwę na roz-
wiązywanie problemów, spotkania i inne nie-
oczekiwanie zdarzenia.
• Należy raczej określić koszt każdego działa­
nia, a nie usiłować ustalić koszt całego planu
• Przekazać użytkown i kowi/użytkownikom
posiadane informacje o wszelkich za łoże­
niach, wyjątkach lub ograniczeniach.
7.3.6 Harmonogramowanie
Plan tylko wtedy może przedstawić realistycznie
możliwość osiągnięcia jego celów, gdy działania są
zestawione razem w harmonogram, który określa,
kiedy każde działanie będzie realizowane. Istnieje
wiele różnych podejść do harmonogramowania.
Harmonogramowanie może być wykonywane ręcz­
nie albo przy wykorzystaniu komputerowego narzę­
dzia do planowania i kontroli.
7.3.6.1 Określenie kolejności działań
Po zidentyfikowaniu działań i ich współzależności
oraz po oszacowaniu ich czasów trwania i nakładów
pracy, następne zadanie polega na ustaleniu opty-
malnej kolejności ich realizacji.
Jest to zadanie o charakterze iteracyjnym, ponieważ
przydzielenie faktycznych zasobów może mieć wpływ
na oszacowaną pracochłonność i czas trwania.
74 I Plany

Czas, o jaki można opóźnić dane działanie bez

wpływu na czas wykonania całego planu, jest
zwany zapasem czasu (niekiedy zwany również
luzem czasowym). Zapas czasu można traktować
jako rezerwę w ramach p lanu lub jako czas, w któ-
rym dane dzi a łan i e nie jest wykonywane.
Ści eżk a lub ścieżk i krytyczne na diagramie to ci ąg
działań z zerowym zapasem. W związku z tym,
jeżeli dane działanie na ścieżce lub ścieżkach kry-
tycznych zostanie zakończone z opóźnieniem, cały
plan również zakończy się z opóźnieniem (dla przy-
kładu, jeżeli zadanie nr 4 na Rysunku 7.4 będzie
opóźnione, ukończenie realizacji planu również
ulegnie opóźnieniu).
Zidentyfikowanie ścieżki krytycznej planu umożliwia
Kierownikowi Projektu monitorowanie tych działań,
które:
• muszą być ukończone w terminie, aby caly plan
został ukończony zgodnie z harmonogramem;
• można opóźnić o pewien czas, jeżel i trzeba
dokonać ponownego przydziału zasobów w celu
nadrobienia innych niewykonanych dzialań.
Przykład sieci działań
Diagram przedstawiający sieć działań z „działa­
niami w węzłach" (niekiedy zwany również dia-
gramem strza łkowym) może być wykorzystany
do harmonogramowania ni eza leżnych dzi ałań
w ramach planu. Pomaga to Kierownikowi Pro-
jektu ustalić najbardziej efektywną kolejność zda-
rzeń niezbędnych do ukończenia planu i umożl i­
wia stworzenie realistycznego harmonogramu.
Diagram z działaniami w węzłach przedstawia
wzajemne zależności pomiędzy działaniami za
pomocą prostokątów i strzałek. Początki strzałek,
których groty wskazują prostokąt z danym dzia-
łaniem wychodzą z poprzednich działań, które
muszą być zakończone, zanim to d ane działanie
się rozpocznie. Strza łki wychodzące z prostokąta
danego dzia łania są skierowane do prostokątów
działań następczych, które nie mogą się roz-
począć, dopóki przynajmniej to dane działanie
nie zostanie zakończone. Uproszczony diagram
z działaniami w węzłach p rzedstawiono na
Rysunku 7 .4.

Strzałki pokazują zależności

Ozialania są pokazane jako prostokąty Zadanie 3 nie może się rozpocząć

do czasu zakończenia Zadań 1 i 2

-+! Zadanie 1 i - - - . i Zadanie31 - - -

Start t--+ł Zadanie s t--H Koniec

.___-+ł Zadanie 2 ..----+I Zadanie 4

•
• ••
•• •••
Zadanie 4 jest poprzednikiem Zadania 5 • •• •••
i następnikiem Zadań 1 i 2 :
••
•• ••
•• • • WS= najWcze~niejszy Start
WS = 18 CT= 5 WK=23 CT = Czas Trwania
WK= najwcześniejszy Koniec
PS = najPóźniejszy Start
Zadanie 4
CZ = Całkowity Zapas
PK = najPóźniejszy Koniec
PS = 18 CZ=O PK = 23

Rysunek 7.4 Uproszczony diagram z działaniami w węzłach


7.3.6.2 Ocena dostępności zasobów
Należy usta l ić liczbę
osób, które będą dostępne do
wykonania prac (lub koszt nabycia tych zasobów).
Należy odnotować wszelkie szczegółowe informa-
cje (na przykład nazwiska, doświadczenie, procent
dostępności, daty dostępności).
7.3. 6.3 Przydzielenie zasobów
Znajomość dostępności zasobów oraz informacji
dotyczącej kolejności działańpozwala Kierownikowi
Projektu na przydzielenie zasobów do poszczegól-
nych dzia łań. Rezultatem tego będzie harmonogram
pokazuj ący obciążenie pracą każdej osoby oraz
wykorzystanie zasobów innych n i ż zasoby osobowe.
Przydatne podejści e polega na przydzieleniu zaso-
bów najpierw do dzi ałań z zerowym zapasem czasu
(kt óre z definicji znajdują si ę na ścieżce krytycznej).
Dzi a łan i a z największym zapasem czasu maj ą w kolej-
ności przydzielania zasobów najniższy priorytet.
Ważne j est określ enie właścicieli zadań . Jeżel i grupa
osób ma wykonać dane zadanie, należy poprosić
j edną osobę z grupy o przyj ęcie odpowiedzi alności
wobec grupy za wykonanie tego zadania.
Jeżeliniektórzy właściciele zadań nie uczestniczą
w tworzeniu harmonogramu, należy pamiętać,
aby najpierw sprawdzić ich dostępność i gotowość
do przyjęcia odpowiedzialności za dane zadanie.
Nie można zakładać, że wpisanie ich nazwiska do
planu lub harmonogramu będzie automatycznie
oznaczać, że praca zostanie wykonana. Należy
współpracować z każdym właścicielem zadania,
komunikować się z nim i sprawdzić, czy rozumie
on, na czym polega wykonanie zadania.
Podczas przydziału zasobów należy pamiętać
o ponownym sprawdzaniu ścieżki krytycznej,
ponieważ przydzielone faktyczne zasoby mogą być
bard ziej lub mniej produktywne n iż przyjęto w zało­
żen i ach przy obliczaniu n a kładów pracy i okresu
t rw ania d anego dzia łania .
7.3.6.4 Wyrównywanie obciążenia
zasobów
Pierwszy przydz i ał zasobów może skutkować nie-
równym wykorzystaniem lub przeciążen i em niektó-
rych z nich. W takich przypadkach konieczna może
być zmiana przydziału zasobów, która nazywana
jest wyrównywaniem obciążeni a.
Plany I 75
Działa ni a mogą byćponownie przydzielone albo ich
daty rozpoczęcia lub czasy trwania mogą ulec zmia-
nie w granicach dostępnych zapasów.
Wynikiem końcowym jest ostateczny harmonogram,
w którym wszystkie działania zostały przydzielone
zasobom, a wykorzystanie zasobów odpowiada ich
dostępności.
Technika łańcucha krytycznego
Metoda planowania oparta na łańcuchu kry-
tycznym przypisuje większą wagę zasobom
wymaganym do realizacj i planu oraz ich dostęp­
ności. Stanowi to przeciwieństwo metod tra-
dycyjnych, które stawiaj ą nacisk na kolej n ość
zadań i sztywne harmonogramowanie. Łańcu ch
krytyczny zapewni równomierne obciążenie
zasobów, lecz będ zie o d nich wymagać elastycz-
ności pod wzg l ęde m dat rozpoczęcia o raz szyb-
kich zmian po mi ędzy zadaniami i łańcuch am i
zadań w celu realizacji całego planu zgodnie
z harmonogramem.
7.3.6.5 Uzgodnienie punktów kontrolnych
Szkic harmonogramu pozwala uzyskać potwierdze-
nie punktów kontrolnych przez Komitet Sterujący.
Działania związane z końcami etapów zarządczych
(np. przygotowanie Raportu Końcowego Etapu
i Planu Etapu następnego) powinny być dołączone
do sieci działań, a harmonogram powinien zostać
skorygowany.
Jednym z częstych błędów podczas tworzenia
harmonogramu jest niezarezerwowanie czasu na
zatwierdzanie produktów lub kolej nych wydań pro-
duktów.
7.3.6.6 Określenie kamieni milowych
Kamień milowy to zdarzenie ujęte w harmonogra-
mie, które oznacza za kończenie kl uczowych dzia-
łań . Może t o być ukończeni e Gru py Zada ń, et apu
t echnicznego lub et apu zarządczego. W środowisku
kom ercyj nym osi ąg n ięci e kamienia milowego może
być sygnałem do dokonania p łatności na rzecz
dostawcy.
Podziałplanu na części związane z kamieniem
milowym pozwala Kierownikowi Projektu uzyskać
wczesne informacje o zagadnieniach związanych
z samym harmonogramem, a także lepszy obraz
76 I Plany
działań, których ukończenie ma krytyczne znaczenie
dla terminów planu.
Chociaż nie istnieje „prawidłowa" liczba kamieni
milowych ani długość okresów pomiędzy nimi, to
tracą one swoją wartość, jeżeli jest ich zbyt dużo lub
zbyt mało. Kamieni milowych powinno być dużo
mniej niż produktów, które trzeba dostarczyć albo
Grup Zadań, ale liczba kamieni milowych rozmiesz-
czonych w wybranych odstępach czasu powinna
być wystarczająca do ustalenia, czy rea lizacja planu
przebiega zgodnie z oczekiwaniami.
7.3.6.7 Obliczenie całkowitej wartości
zasobów i kosztów
Wymagania dotyczące zasobów mogą być ujęte
tabelarycznie, a koszty zasobów i inne koszty
powinny być obliczone w celu opracowania budżetu
planu.
Budżet powinien obejmować:
• koszt działań związanych z wytworzeniem
i weryfikacją produktów specjalistycznych oraz
koszt działań związanych z zarządzaniem projek-
tem;
• budżet ryzyka {patrz Rozdział 8);
• budżet zmian {patrz Rozdział 9);
• tolerancje kosztów.
Tworzenie budżetu ryzyka i budżetu zmian nie jest
obowiązkowe.
7.3.6.8 Przedst awienie harmonogramu
Harmonogram najlepiej przedstawić w formie gra-
ficznej . Istnieje szereg sposobów przedstawienia
harmonogramu, przy czym wybór formatu będzie
uzależniony od skali i złożoności planu oraz potrzeb
osób, którym będzie on przedstawiony. Większość
narzędzi planistycznych oferuje różne formaty
przedstawienia harmonogramu.
Przykłady formatów przedstawienia harmono-
gramu
Wykres Gantta
Wykres Gantta jest graficznym odzwierciedle-
niem okresu trwania zadań wzg l ędem upływu
czasu. Umożliwia to Kierownikowi Projektu:
• ocenę, jak długo powinna trwać realizacja
planu;
• ustalenie wymaganej kolejności realizacji
zadań;
• zarządzanie zależnościami pomiędzy zada -
niami;
• ustalenie, co powinno już być osiągnięte
w danym momencie;
• ustalenie sposobu, w jaki działania naprawcze
mogą przywrócić realizację planu na właściwą
drogę.
Diagram ścieżki krytycznej
Diagram ścieżki krytycznej uwypukla te zada-
nia, których nie można opóźnić bez opóźnienia
terminu rea lizacji planu oraz te zadania, które
można opóznić bez wpływu na datę zakończenia
realizacji planu. Pomaga to przy monitorowaniu
i komunikacji.
Arkusze kalkulacyjne
Na arkuszu kalkulacyjnym możl i we jest stworze-
nie listy zadań w uk ładzie: wiersze - zadania,
kolumny - terminy, a następnie pokolorowanie
rubryk w celu pokazania terminów realizacji
zadań oraz postępów prac. W przypadku pro-
stych projektów, w których terminy prawdopo-
dobnie się nie zmienią, może to być wystarczają­
ce. Dla dużych lub skomplikowanych projektów
terminy mogą ulegać częstym zmianom. Oznacza
to, że Kierownik Projektu musiałby poświęcić
znaczną ilość czasu na zmianę harmonogramu,
zaniedbując jednocześnie bieżące prace związa­
ne z zarządzaniem projektem.
Lista kontrolna produktów
Lista kontrolna produktów to lista głównych pro-
duktów planu, wraz z kluczowymi datami doty-
czącymi ich dostawy. Przykład listy kontrolnej
produktów jest przedstawiony w zarysie Opisu
Produktu dla planu w Dodatku A.
7.3.7 Analizowanie ryzyk
To działanie planistyczne przebiega zazwyczaj rów-
nolegle z pozostałymi działa n iami, ponieważ ryzyka
mogą zostać zidentyfikowane w dowolnym momen-
cie podczas tworzenia lub korekty planu.
Każdy zasób i działanie, a także wszystkie informa-
cje planistyczne powinny być oceniane pod kątem
związanego z nimi potencjalnego ryzyka. Wszystkie
zidentyfikowane ryzyka należy wpisywać do Reje-
stru Ryzyk {lub do Dziennika Projektu podczas pla-
nowania etapu inicjowania).
 Plany I 77

Przykłady ryzyk związanych z planowaniem

7.3.8 Kompletowanie planu
Po pomyślnym opracowaniu harmonogramu, należy
• Pominięcie planów na właściwym złożyć w jedną całość plan, jego koszty, wymagane
poziomie(-ach) za rządzania. mechanizmy sterowania oraz towarzyszące części
• Jednoczesne przystą pien ie dużej liczby zaso- opisowe, zgodnie z konstrukcją planu.
bów do projektu może zwolnić postęp prac
Część opisowa powinna być dodana w celu obja-
i spowodować problemy z komunikacj ą
śn i enia
planu, jego ogran i czeń, zewnętrznych
(można to zidentyfikować, wyznaczając
zależn ości, przyjętych założeń, wymaganego moni-
„krzywą S" dla profilu zasobów w funkcj i
czasu - należy unikać linii o dużym nachyle- torowania i kontroli, zidentyfikowanych ryzyk oraz
niu). wymaganych reakcji na nie.
• Plan obejmuje nienazwane zasoby, w wyniku Dobrą praktyką jest utrzymanie planów w odpo-
czego produktywność rzeczywistych zasobów wiednio prostej formie. Należy rozważyć zastoso-
będzie różnić się od produktywności oszaco- wanie diagramów sumarycznych, jeżeli plan ma być
wanej w planie. przedstawiony Komitetowi Steruj ącemu.
• Plan zawiera relatywnie dużo za l eżności Wskazane może być stosowanie jednego formatu
zewnętrznych. planu przedstawianego do zatwierdzenia i bardziej
• Plan wykorzystuj e niesprawdzonych dostaw- szczegółowego formatu dla celów bieżącej kontroli.
ców lub jest uza l eżn i ony od nowych techno- Na l eży również rozważyć różne poziomy przed-
logi i. stawienia planu dla różnych adresatów. Większość
• Duża część działań znajduje się na ścieżce komputerowych programów planistycznych oferuje
krytycznej - opóźnienie w realizacji jednego takie możliwości .
z nich spowoduje opóźnienie realizacji planu.
Proponowana zawartość planu została przedstawio-
• Plan nie przewiduje wystarczającej liczby
na w Dodatku A.
zarządczych punktów decyzyjnych, np. takich
j ak końce etapów.
• Plan nie przewiduje wystarczającego zapasu 7 .4 OBOWIĄZKI
czasu (stworzenie histogramu pokazującego Tabela 7.1 przedstawia obowiązki dotyczące tematu
l iczbę działań według ich zapasu czasu j est Plany. Wi ęcej szczegółów na temat ró l w zespole
pożytecznym sposobem zidentyfikowania za rządza ni a projektem oraz powi ązanych z nimi
tego ryzyka). obowiązków przedstawiono w Dodatku C.
• Duża liczba produktów ma być ukończona
w tym samym czasie.
• Plan jest ograniczony czasowo przez ograni-
czenia finansowe (np. budżet nie może być
przeniesiony na następny rok) lub ogranicze-
nia kalendarzowe (np. projekty dotyczące
problemu roku 2000 były ograniczone kalen-
darzowo).
• Harmonogram poka zuje wiele ści eżek prze-
biegających bardzo blisko ści eżk i krytycznej,
które prawdopodobnie staną się ścieżkam i
krytycznymi w przypadku nawet drobnego
pośl izgu.

Po sporządzeniu planu, należy go nadal traktować

jako szkic, dopóki ryzyka związane z tak opracowa-
nym planem nie zostaną zidentyfikowane i ocenio-
ne, a plan ewentualnie zmodyfikowany.
Więcej szczegółów na temat identyfikowania i anali-
zowania ryzyk można znaleźć w Rozdziale 8.
78 I Plany

Tabela 7 .1 Obowiązki dotyczące t emat u Plany

Rola Obowiązki

Kierownictwo firmy lub Ustala tolerancje dla projektu i dokumentuje je w zleceniu przygotowania projektu.
-
programu Zatwierdza Plany Nadzwyczajne, w przypadku gdy przewiduje się przekroczenie tolerancji
na poziomie projektu.
Dostarcza standardy planistyczne obowiązujące w organizacji lub programie.
Przewodniczący Zatwierdza Plan Projektu.
Określa tolerancje dla każdego etapu i zatwierdza Plany Etapów.
~~~~....:.._~'--~~~~~~~~~-

Zatwierdza Plany Nadzwyczajne. w przypadku gdy przewiduje się przekroczenie tolerancji

na poziomie etapu.
~'--~~~~~~~~-

Zapew nia zasoby biznesowe do realizacji P1anów Etapu (np. finansowanie).

Główny Użytkownik Zapewnia, aby P1any Projektu i Plany Etapów były spójne z perspektywy użytkownika.
Zapewnia zasoby użytkownika do realizacji Planów Etapów.
G łówny Dostawca Zapewnia, aby Plany Projektu i Plany Etapów byly spójne z perspektywy dostawcy.
Zapewnia zasoby dostawcy do realizacji Planów Etapów.
~~~~~~~~~~- -~~~~~~~~~~~-

Kierown ik Projektu Opracowuje plany.

-'-~~....;_...:.....__:~~~~~~~~~~~~~~~~~~~~~~~~~

Przygotowuje Plan Projektu i Plany Etapów.

Decyduje, jak będą zastosowane etapy zarządcze i techniczne oraz opracowuje Plany
Etapów.
Zleca działania korygujące. w przypadku gdy przewidywane jest przekroczenie granic
tolerancji na poziomie Grupy Zadań.
Przygotowuje Plan Nadzwyczajny w celu wykonania decyzji kierownictwa organizacji,
kierownictwa programu lub Komitetu Steruj<1cego w odpowiedzi na Raporty
Nadzwyczajne.
~~~~~~~~~~-

Kierownik Zespołu Sporządza Plany Zespołów.

Sporządza hannonogramy dla każdej Grupy Zadań.

Nadzór Projektu Monitoruje zmiany Planu Projektu w celu ustalenia, czy mają one wplyw na potrzeby
biznesowe lub Uzasadnienie Biznesowe projektu.
Monitoruje postępy prac etapu i projektu w odniesieniu do ustalonych tolerancji.
Wsparcie Projektu Pomaga przy opracowywaniu Planów Projektu, Planów Etapów i Planów Zespołów.
Wnosi fachową wiedzę i umiejętności (np. w zakresie narzędzi planistycznych).
Nada1e P1anom Projektu, Planom Etapów i Planom Zespołów status obiektów odniesienia
(bazowych), przechowuje je i dystrybuuje.
8 Ryzyko
8.1 PRZEZNACZENIE
Przeznaczeniem tematu Ryzyko jest zidentyfi-
kowanie, ocena i sterowanie niepewnością, by
w rezultacie zwiększyć szansę powodzenia pro-
jektu.
Podejmowanie ryzyka w projektach j est nieunik-
nione, ponieważ projekty prowadzą do zmiany,
a zmianie towarzyszy niepewność i - co za tym idzie
- ryzyko.
Zarządzan i e
ryzykiem powinno m i eć charakter sys-
tematyczny, a nie przypadkowy. Dotyczy ono pro-
aktywnego identyfikowania, oceniania i sterowania
tymi ryzykam i, które mogą m i eć wpływ na osiągan i e
celów projektu.
W projekcie powinna być ustanowiona i utrzymy-
wana efektywna kosztowo procedura za rządzania
ryzykiem. Celem jest wspomaganie podejmowania
lepszych decyzji poprzez dobre zrozumienie ryzyk
- ich przyczyn, prawdopodobieństwa wystąpienia,
wpływu, przewidywanego czasu wystąpienia oraz
wyboru reakcji na nie.
Zarządzanie ryzykiem jest działaniem o charakterze
ciągłym, wykonywanym przez cały okres życia pro-
jektu. Bez ciągłej, efektywnej procedury zarządzania
ryzykiem nie można zapewnić, że projekt będzie
w stanie spełnić swoje cele i że w związku z tym
warto go kontynuować. Efektywne zarządzanie
ryzykiem jest więc wymogiem wynikaj ącym z zasa-
dy utrzymania ciągłej zasadności bi znesowej.
8.2 DEFINICJA RYZYKA
8.2.1 Czym jest ryzyko?
Ryzyko to niepewne zdarzenie lub zbiór zda rzeń,
które w przypadku ich wystąpien i a będą mieć
wpływ na osiągnięcie celów. M ia rą ryzyka jest ilo-
czyn prawdopodobieństwa wystąpienia dostrzeżo­
nego zag rożenia lub szansy oraz wielkości jego/jej
wpływu na cele, przy czym:
• zagrożeni e oznacza niepewne zdarzenie, które
może mieć niekorzystny wpływ na cele;
• szansa (okazja) oznacza niepewne zdarzenie,
które może mieć korzystny wpływ na cele.
8.2.2 Co jest narażone na ryzyko?
W kontekście projektu na ryzyko narażone są cele
projektu. Obejmują one ukończenie projektu z osią ­
gnięciem szeregu wartości docelowych, dotyczących
zazwyczaj czasu, kosztów, jakości, zakresu, korzyści
i ryzyka.
Więcej informacji na temat tych wartości docelo-
wych przedstawiono w punkcie 2.5.
8.2.3 Na czym polega zarządzanie
ryzykiem?
Określ enie „zarządzanieryzykiem" odnosi się do
systematycznego stosowania procedur dotyczących
zadań identyfikowania i oceniania ryzyk, a następ­
nie planowania i wdrażan i a reakcj i na nie. To stwa-
rza uporządkowane środowisko dla proaktywnego
podejmowania decyzji.
Żeby zarządzanie ryzykiem było skuteczne, ryzyko
musi być:
• Zidentyfikowane Obejmuje to rozważenie
ryzyk, które mogą wpływać na osiąganie celów
projektu, a następnie ich opisanie w celu zapew-
nienia wspólnego rozumienia tych ryzyk.
• Ocenione Obejmuje to zapewnienie, że każde
ryzyko może być sklasyfikowane według oszaco-
wanego prawdopodobieństwa jego wystąpien ia,
stopnia j ego wplywu i bliskości jego materializa-
cji, oraz zrozumi enie ogólnego poziomu ryzyka
związanego z projektem.
• Sterowane Obejmuje to zidentyfikowanie
odpowiednich reakcj i na ryzyko, przydzielenie im
właściciel i ryzyka, a następnie wykonanie, moni-
torowanie i kontrolowanie tych reakcj i.
Zarządzanie ryzykiem stosowane jest z perspektywy
strategicznej, operacyjnej, programu oraz projektu.
Podejście do zarządzania ryzykiem może być wspól-
ne dla wszystkich tych perspektyw, ale procedury
zarządzan ia ryzyk iem powinny być dostosowane do
każdej z nich. Te perspektywy organizacyjne przed-
stawiono na Rysunku 8.1.
82 I Ryzyko

Dłu g i termin
Strategiczna

::"'o Programu
Ili
OJ
c:
Ś redni termin ·-
N
..c
"'c:
·-"'E Projektu
N

Krótki term in Operacyjna

Rysunek 8. 1 Perspektywy organizacyjne

8.3 PODEJŚCIE PRINCE2 DO RYZYKA 8.3.2 Zarządzanie ryzykiem w projektach

Punktem wyj ści a dla wszystkich projektów będzi e
8.3.1 Pryncypia Zarządzania Ryzykiem ustalenie, czy istnieją jakieś zasady polityki i procesy
(M_o_R®) organizacji lub programu, które muszą być zasto-
Podejście
PRINCE2 do za rządzania ryzykiem jest sowane. Informacje te mogą m i eć formę polityki
oparte na publikacji OGC zatytulowanej Manage- zarządzan i a ryzykiem i/lub wytycznych dotyczących

ment of Risk: Guidance for Practitioners (TSO, 2007). procesu zarządzan i a ryzykiem (lub podobnych doku-
Zarządzanie ryzykiem jest oparte na szeregu pryn- mentów).
cypiów zarządzania ryzykiem, z których następujące • Polityka za rządzan i a ryzykiem danej organiza-
mają zastosowanie w kontekście projektu: cji powinna określać, w jaki sposób zarządza ni e

• zrozumienie kontekstu projektu; ryzykiem będzie realizowane w całej organiza-

cji, aby wspiera ło osi ąganie przez organ i zację
• ustalenie jasnychinteresariuszy;
zaangażowanie
jej celów strategicznych. Będzi e ona obejmować
• opracowanie celów doprojektu; ryzykiem takie informacje, jak: akceptowalne ryzyko, okre-
• w projekcie; podejścia zarządzania
śl ane ta kże jako „apetyt na ryzyko" (indywidu-
alne nastawienie danej organizacji do podejmo-
• jasne
regularne raportowanie o ryzykach; wania ryzyka, które z kolei wyznacza poziom
• ustalenie
zdefiniowanie ról i obowiązków; ryzyka, jaki ta organizacja uważa za możl iwy do
• struktury wsparcia oraz
wspieraj ącego zarządzan i e
ryzykiem;
środowiska zaakceptowania), tolerancje ryzyka, procedury
przekazywania ryzyka na wyższy szczebel zarzą­
• monitorowanie wskaźników
wczesnego ostrze- dzania oraz określ one role i obowi ązk i .
gania;
• Wytyczne organizacji dotyczące procesu zarzą­
• ulepszania.
ustalenie cyklu przeg l ądów
i do dążenie ci ągłego dzania ryzykiem powinny zawierać opis szeregu
kroków oraz związanych z nimi odpowiednich
dzia łań niezbędnych do wdrożenia zarządzan i a

ryzykiem. Wytyczne te powinny dostarczać opar-
tego na najlepszych praktykach podejścia, które
będzie wspierać spójną metodę zarządzania
ryzykiem w calej o rganizacji.
Jeżeli projekt j est części ą programu, podejście pro-
gramu do zarządzani a ryzykiem będz i e określone
przez Strategię Zarządzan i a Ryzyki em programu.
Metodyka PRINCE2 zaleca, aby każdy projekt posiada!
swoją wlasną Strategię Zarządzania Ryzykiem (okre-
ślającą procedury zarządzania ryzykiem w projekcie,
począwszy od identyfikacji aż do wdrożenia reakcji
na ryzyko) oraz narzędzie kontroli, tj. Rejestr Ryzyk.
Więcej informacji na temat polityki zarządzania
ryzykiem i dokumentów zawierających wytyczne
dotyczące tego procesu można zna leźć w publikacji
OGC zatytułowanej Zarządzanie ryzykiem: Poradnik
dla praktyków (TSO, 2007).
8.3.3 Strategia Zarządzania Ryzykiem
Po dokonaniu przeglądu dokumentów na poziomie
organizacji i programu, a przed podjęciem dzialań
dotyczących zarządzania ryzykiem, należy opraco-
wać Strategię Zarządzania Ryzykiem dla projektu.
Celem tej strategii jest opisanie sposobu, w jaki
zarządzanie ryzykiem zostanie wlączone w dzialania
zarządzania projektem.
Przykład tolerancji ryzyka
Duża f irma zajmująca się sprzedażą detal i czn ą
sprzętu elektrycznego nie będzie dopuszczala
żadnych niekoniecznych zaklóceń w swoich sys-
temach wsparcia w okresie szczytowego zapo-
trzebowania na energię, który trwa od polowy
listopada do końca stycznia. Nie dopuszcza się,
aby projekty wprowadzały jakiekolwiek zmiany
do systemów wsparcia w tym okresie. W związku
z tym wszelkie ryzyka zawarte w Rejestrze Ryzyk,
oznaczające zm i anę systemów wsparcia w okresie
szczytowego zapotrzebowania na energię musia-
łyby być przekazane Komitetowi Steruj ącemu.
Kluczową decyzją, którą na l eży zapisać w Strate-
gii Zarządzania
Ryzykiem, jest podejście Komitetu
Sterującego do podejmowania ryzyka, które z ko-
lei będzie dyktować stopień ryzyka, jaki uważa on
za możliwy do zaakceptowania. Informacje te są
rejestrowane w formie tolerancji ryzyka reprezentu-
jących taki poziom wystawienia na ryzyko, którego
przekroczenie doprowadzi do sporządzenia Raportu
Ryzyko I 83
Nadzwyczajnego w celu powiadomienia Komitetu
Sterującego o zaistniałej sytuacji.
Opis Produktu dla Strategii Zarząd zania Ryzykiem
przedstawiono w Dodatku A.
8.3.4 Rejestr Ryzyk
Rej estr Ryzyk przeznaczony j est do rejestrowania
i przechowywania informacji dotyczących wszystkich
zidentyfikowanych zagrożeń i szans dotyczących
projektu. Każdemu ryzyku w Rejestrze Ryzyk jest
przypisany indywidualny identyfikator, a także zapi-
sywane są następujące informacje:
• kto zgłosił ryzyko;
• kiedy ryzyko zostało zgłoszone;
• kategoria ryzyka;
• opis ryzyka (przyczyna, zdarzenie związa n e
z ryzykiem, skutek);
• prawdopodobieństwo, wplyw i wa rtość oczeki-
wana;
• bliskość;
• kategoria reakcji na ryzyko;
• działania dotyczące reakcji na ryzyko;
• status ryzyka;
• właściciel ryzyka;
• wykonawca reakcji na ryzyko.
Zazwyczaj to Wsparcie Projektu prowadzi Rejestr
Ryzyk w imieniu Kierownika Projektu. Strategia
Zarządza n ia Ryzykiem powinna zawierać opis pro-
cedury rej estrowania ryzyk i prowa dzenia Rejestru
Ryzyk.
Opis Produktu dla Rejestru Ryzyk przedstawiono
w Dodatku A.
8.3.5 Procedura zarządzania ryzykiem
PRINCE2 zaleca procedurę zarządzania ryzykiem
obejmującą pięć następujących kroków:
• Identyfikuj (kontekst i ryzyka).
• Oceniaj (tj. oszacowanie i ewaluacja).
• Planuj.
• Wdrażaj .
• Komunikuj.
Pierwsze cztery kroki mają charakter sekwencyjny,
natomiast krok „Komunikuj" przebiega równolegle
do nich, ponieważ być może trzeba będzie komu-
nikować ustalenia innych kroków przed zakończe­
niem ca łego procesu. Wszystkie kroki mają charak-
ter iteracyjny, tzn. kiedy dodatkowe
84 I Ryzyko
informacje będą dostępne, często może być
kon ieczne powtórzenie wcześn i ejszych kroków
i ponowne ich wykonanie w celu osiągnięcia naj-
bardziej efektywnego rezu ltatu.
Rysunek 8.2 przedstawia elementy procedury zarzą­
dzania ryzykiem, które zostały opisane w sekcjach
8.3.5.1-8.3.5.5.
Identyfikuj
Komunikuj
Planuj
Rysunek 8.2 Procedura zarządzania ryzykiem
8.3.5.1 Identyfikowanie
Identyfikowanie kontekstu
Glównym celem kroku „ Identyfikuj kontekst" jest
uzyskanie informacji na temat projektu pozwalają­
cych zrozumieć konkretne cele, które są narażone
na ryzyko, oraz opracować Strategię Zarządzan i a
Ryzykiem dla projektu. Strategia Zarządzania Ryzy-
kiem opisuje sposób, w jaki ryzyka będą zarządzane
w trakcie projektu. Jest tworzona podczas etapu ini-
cjowania, a następnie j est poddawana przeglądowi
i ewentualnej aktualizacji na końcu każdego etapu.
Strategia Za rządzan i a Ryzykiem w proj ekcie powin-
na być oparta na polityce za rządzania ryzykiem
organizacji lub na Strategii Zarządzan i a Ryzykiem
programu.
Następujące elementy będą mieć wplyw na Strate-
gię Za rządzania Ryzykiem d la projektu:
• Oczekiwania j akości owe klienta.
• Liczba organizacji zaangażowanych w projekt
i relacje m i ędzy nimi.
• Potrzeby interesariuszy zaangażowanych
w projekt.
• Znaczenie, złożoność i skala projektu.
• Założen i a, które zosta ły przyjęte.
• Środowisko własne organizacji (tj . wymogi usta-
wodawcze lub dotyczące ladu korporacyjnego).
• Podejście organizacji do zarządzania ryzykiem,
zgodnie z opisem zawartym w jej polityce zarzą­
dzania ryzyk iem.
Informacje te będą pochodzić ze zlecenia przygoto-
wania projektu, Założeń Projektu i Opisu Produktu
Końcowego Projektu. Strategia Zarządzania Ryzy-
kiem będzi e zawi erać decyzje dotyczące:
• Procedury za rządzania ryzyk iem.
• Narzędzi i technik, które maj ą być wykorzystane.
• Zapisów, które mają być prowadzone.
• Raportowania ryzyka.
• Ustalania terminów czynności dotyczących za rzą­
dzania ryzykie111.
• Ról i obowiązków zwią zanych z procedurą zarzą­
dzania ryzykiem.
• Skal ryzyka, które mają być wykorzystane
(w odniesieniu do prawdopodobieństwa, wpływu,
bl iskości).
• Kategoryzacji ryzyk (i ewentualnie stosowania
diagramu struktury podz i ału ryzyka).
• Kategorii reakcj i na ryzyko, które mają być
wykorzystane.
• Syg n ałów wczesnego ostrzegania.
• Wszelkich tolerancji ryzyka.
• Ustanowienia budżetu ryzyka oraz sposobu,
w jaki sposób będzie on kontrolowany.
Sygna ły wczesnego ostrzegania (istotne dla projek-
t u) będą z wyprzedzeniem dostarczać ostrzeżeń, że
j eden lub więcej z celów projektu może być narażo­
ny na ryzyko. Sygna ł y wczesnego ostrzegania mogą
obejmować dane o postępach projektu (patrz Roz-
dział 1O), takie jak:
• Procent Grup Zadań ukończonych/n i eukończo­
nych zgodnie z hannonogramem.
• Procent zatwierdzeń uzyskanych/nieuzyskanych
zgodnie z harmonogramem.
• Liczbę zgłoszonych zagadnień (tygodniowo/
m i esięczn i e).
• Procent zagadn i eń, które pozostają n ierozwi ą­
zane.
• średnią liczbę dni potrzebnych na rozwiąza n i e
zagadnień.

• Średnią liczbę błędów wykrytych podczas kontroli
jakości.
• Zgodność z budżetem (np. poziom wydatków
poniżej lub powyżej planowanego poziomu).
• Zgod ność z harmonogramem (np. l i czbę dni
opóźn i enia
lub wyprzedzenia w stosunku do
harmonogramu).
Inne sygna ły wczesnego ostrzegania mogą obejmo-
wać dane spoza projektu, takie j ak poziom zadowo-
lenia klienta, poziom absencji, poziom wyczerpania
zasobów osobowych itp., jeżeli są one istotne dla
projektu. Przydatne jest również analizowanie
i raportowanie kierunku zmian sygnałów wczesnego
ostrzegania (tzn. czy się poprawiają, czy pogarszają),
ponieważ może to być bardziej istotne niż ich war-
tość zarejestrowana w danej chwili.
Identyfikowanie ryzyk
Głównym celem kroku „Identyfikuj ryzyka" jest roz-
poznanie zagrożeń i szans, które mogą wp ływać na
cele proj ektu.
PRINCE2 zaleca wykonanie następujących czynności:
• Zarejestrować zidentyfikowane zagrożenia
i szanse w Rejestrze Ryzyk.
• Przygotować sygnały wczesnego ostrzegania
w celu monitorowania aspektów projektu o kry-
tycznym znaczeniu i dostarczenia informacji
o potencjalnych źródłach ryzyka.
• Poznać i zrozumieć opinię interesariuszy na
temat konkretnych zarejestrowanych ryzyk.
Efektywnym sposobem identyfikowania ryzyk j est
wykorzystanie tzw. warsztatów ryzyka. Jest to sesja
grupowa, zaprojektowana w celu zidentyfikowania
zagrożeń i szans. Sesję tę powinien poprowadzić
ktoś, kto umie korzystać z szeregu technik identyfi-
kacyjnych, takich jak te podane poniżej. Warsztaty
powinny prowadzić do zidentyfikowania szerokiego
wachlarza ryzyk i potencjalnych właścicie l i ryzyka.
Techniki identyfikowania ryzyka
Ryzyka można identyfikować za pomocą szeregu
technik, takich jak:
• Przegląd doświadczeń Ryzyka są związane
z niepewnością, stąd też jednym z najbardziej
skutecznych sposobów zredukowania nie-
pewności jest dokonanie przeglądu wcześniej­
szych podobnych projektów, w celu ustalenia,
j akie zag rożenia i szanse wpływały na nie.
Ryzyko I 85
• listy kontrolne ryzyka Są to wewnętrzne
listy ryzyk, które albo zostaly zidentyfikowa-
ne, albo wystąpiły we wcześniejszych podob-
nych projektach. Listy kontrolne ryzyka są
pożytecznym środkiem do zapewnienia, by
ryzyka zidentyfikowane we wcześniejszych
projektach nie zostały pominięte.
• Listy kategoryzujące ryzyka Są to ogól-
nie dostępne listy, które dzielą ryzyka na
poszczególne rodzaje lub dziedziny i które są
zazwyczaj istotne dla szerokiego asortymen-
tu projektów. Listy kategoryzujące ryzyka są
pożytecznym środkiem pomagającym myśleć
o źródłach ryzyka w najszerszym kontekście.
• Burza mózgów Technika ta umożliwia
myślenie grupowe, które może być bardziej
produktywne niż myśl enie indywidualne.
Wa żne jest jednak, aby unikać krytycyzmu
podczas burzy mózgów, ponieważ może to
zniechęcić uczestników do wniesienia ich
wkładu. Poza identyfikowaniem ryzyk, burza
mózgów może być również wykorzystywana
w celu zrozumienia poglądów interesariuszy
na temat zidentyfikowanych ryzyk.
• Diagram struktury podziału ryzyka
Jest to hierarchiczny podział otoczenia pro-
jektu w celu zilustrowania potencjalnych źró­
de ł ryzyka. Każdy niższy poziom reprezentuje
coraz bardziej szczegółową defi nicję źródeł
ryzyka dla proj ektu. Struktura ta j est sygna-
łem i środkiem wspierającym dla zespołu
zarządzania projektem, służącym do przemy-
ślenia potencjalnych źródeł ryzyka dotyczą­
cych celów projektu. Istnieje wiele sposobów
podziału ryzyka i użyteczne może być sporzą­
dzenie więcej niż jednej listy. Dla przykładu,
diagram struktury podziału ryzyka może być
podzielony według kryteriów „PESTLE" (poli-
tycznych, ekonomicznych, socjologicznych,
technologicznych, prawnych/ustawodawczych
i środowi skowych), struktury podzia łu pro-
duktów, etapów, korzyści/celów itp. Rysunek
8.3 przedstawia diagram struktu ry podziału
ryzyka w odniesieniu do ryzyka finansowego.
Te struktury pomogą zidentyfikować odpo-
wiednich właścicieli ryzyka w celu przygoto-
wania reakcji na ryzyko.
86 I Ryzyko

Ryzyko f inansowe

Niezabezpieczony Ryzyka związane

Ryzyko kursowe kredyt z klientem

Niezapłacone Zerwanie
Bankructwo kontraktu
należności

Rysunek 8.3 Przykład diagramu struktury podziału ryzyka

Istotnym aspektem identyfikowania ryzyk jest moż­
l iwość jasnego i j ednoznacznego opisania każdego
ryzyka. Pożytecznym sposobem opisywania ryzyka
jest rozważenie następujących aspektów każdego
ryzyka:
• Przyczyna ryzyka Powinna zawi erać opis
źródła ryzyka, tj. zdarzenia lub sytuacji, która
prowadzi do wystąpie nia ryzyka. Są one czę­
sto zwane czynnikami wyzwalającym i ryzyko.
Nie są to ryzyka same w sobie, lecz potencj alne
miejsca/zdarzenia in icjujące ryzyko. Mogą one
być wewnętrzn e lub zewnętrzne w stosunku do
projektu.
• Ryzykowne zdarzenie Powinno zawiera ć opis
obszaru n i epewności w kategoriach zagrożenia
lub szansy.
• Skutek ryzyka Powinien zawierać opis wpływu
ryzyka na cele projektu, jeżeli ryzyko to zmate-
rializuje się.
Relacja pomiędzy przyczyną, zdarzeniem i skutkiem
ryzyka jest przedstawiona na Rysunku 8.4.
Przyczyna ryzyka
może
spowodować
Niepewne zdarzenie
'
które może
Relację pomiędzy przyczyną, zdarzeniem i skutkiem
można również wyrazić w f ormie zdania, na
przykład:
• ZagrożenieZ powodu ulewnych opadów desz-
czu (przyczyna ryzyka), istnieje zagrożenie, że
rzeka przepływająca przez pole rolnika może
wylać z brzegów (ryzykowne zdarzenie), co
może spowodować poważne szkody w zbiorach
tego rolnika (skutek ryzyka).
• Szansa Ponieważ zima była w tym roku szcze-
gólnie łagodna (przyczyna ryzyka), istnieje szan-
sa, że mniej osób znajdzie się w szpitalu z obja-
wami grypy (ryzykowne zdarzenie), co oznacza,
że będzie mniej zakłóceń w zaplanowanych ruty-
nowych operacjach (skutek ryzyka).
8.3.5.2 Ocenianie
Oszacowywanie
Głównym celem kroku „Oszacuj" jest dokonanie
oceny zagrożeń i szans dotyczących proj ektu w kate-
goriach prawdopodobieństwa i wpływu . Bliskość
ryzyka będzie również istotna w celu określenia, jak
szybko ryzyko może si ę zmaterializować, jeżeli nie
zostaną podjęte żadne dzia łania.
PRINCE2 zaleca rozpatrzen ie następujących kwestii:
• Prawdopodobieństwo zagrożeń i szans w kate-
goriach tego, na ile możl iwe
j est ich wystąp i enie.
• Wpływ każdego zagrożenia i każdej szansy pod
kątem celów projektu. Dla przykładu, jeżel i cele

I
wpłynąć na mają być mierzone w kategoriach czasu i kosz-
Cel
tów, wpływ równ ież należy zmierzyć w katego-
riach czasu i kosztów.
• B l iskość tych zagrożeń i szans, to znaczy, kiedy
Rysunek 8.4 Przyczyna, zdarzenie i skutek ryzyka mogą się one zmateri al i zować.

• Zakres zmian wpływu zagrożeń i szans w okresie
życia projektu.
Techniki szacowania ryzyka
Ryzyka można szacować przy wykorzystaniu sze-
regu technik, takich jak:
• Drzew a prawdopodobieństwa (drzew a decy-
zyjne) Są to graficzne prezentacje prawdo-
podobnych zdarzeń wynikających z określo­
nych okoliczności. Drzewo prawdopodobień­
stwa, nazywane także drzewem decyzyjnym,
może być wykorzystane do przewidzenia
wyniku w kategoriach jakościowych, gdy
wykorzystuje się dane historyczne do oblicza-
nia prawdopodobieństwa wystąpienia każdej
okoliczności. Drzewa prawdopodobieństwa
pomagają zakom un ikować uczestnikom pro-
jektu lub decydentom prawdopodobieństwo
wystąp i en ia różnych możl iwych rezultatów
dla danego zbioru okol i czności.
• Pieniężna wartość oczekiwana Technika
ta kwantyfikuje ryzyko jako iloczyn kosz-
tu wpływu ryzyka i prawdopodobieństwa
wystąpienia tego ryzyka. Pieniężna wartość
oczekiwana jest przydatna, gdy potrzebna
jest konkretna miara ryzyka, aby można było
ustalić priorytety ryzyk. Dla przykładu, jeże l i
koszt, który trzeba będzi e ponieść w przy-
padku zmaterializowania s i ę ryzyka wyno-
si 160 OOO złotych a prawdopodob i eństwo
wystąpienia tego ryzyka jest szacowane na
25o/o, pieniężna wartość oczekiwana będzie
wynosić 40000 złotych.
• Zasada Pareto Technika ta klasyfikuje lub
porządkuje ryzyka po dokonaniu ich oceny,
w celu ustalenia porządku, w którym mają
być rozpatrywane. Analiza Pareto może być
wykorzystywana w celu skoncentrowania
wysilków kierownictwa na tych ryzykach,
które potencjalnie mogą m i eć najwi ększy
wp ływ na cele proj ektu.
• Macierz prawdopodobieństwo/wpływ
Macierz ta zawiera wartości klasyfikacyjne,
które mogą być wykorzystane do sklasyfiko-
wania zagrożeń i szans w ujęciu jakościowym.
Skale prawdopodobieństwa są miarami praw-
dopodobieństwa pochodzącymi z wartości
procentowych, natomiast skale wpływu są
wybrane w celu odzwierciedlenia wplywu na
cele projektu. Wartości w komórkach macie-
Ryzyko I 87
rzy są funkcją określonego prawdopodobień­
stwa i wpływu i są obliczane przez pomnoże­
nie prawdopodobieństwa i wpływu. Macierz
prawdopodobieństwo/wpływ może być
wykorzystywana do oceny wagi (dotkliwości)
ryzyka, umożl iwiając kl asyfikację ryzyk, aby
możn a było usta l ić priorytety dla zarządzania
czasem i działan i am i . Dla przykładu, Komitet
Sterujący może usta l ić tolerancję dowolnego
ryzyka na poziomie 0, 18 (to znaczy ryzyko
powyżej tego poziomu nie jest akceptowalne)
i może wymagać proaktywnej reakcji na ryzy-
ko o wartości większej niż 0,045, jak przed-
stawiono za pomocą zaciemnionych części na
Rysunku 8.5.
U żyteczny sposób sumarycznego przedstawiania
zbioru ryzyk i ich oszacowań polega na naniesieniu
ich na sumaryczny profil ryzyka, którego przyklad
przedstawiono na Rysunku 8.6. Profil ten przedsta-
wia sytuację w określonym momencie, tj. aktualny
obraz sytuacji ryzyka. Ponumerowane znaczniki
reprezentują indywidualne identyfikatory ryzyka
nadane w Rejestrze Ryzyk, na którym ten profil jest
oparty. Ryzyka znajdujące się powyżej i po prawej
stronie przerywanej linii tolerancji ryzyka reprezen-
tuj ą ryzyka, których organizacja nie będzie tole-
rować, chyba że wystąp i ą szczególne oko l iczności .
W przedstawionym przypadku Kierownik Projektu
przekazałby informacje o ryzykach nr 1, 3 i 4 do
Komitetu Sterującego.
Sumaryczny profil ryzyka może być również wyko-
rzystany do przedstawienia trendów. Dla przykładu,
ryzyko nr 6 mogło być wcześniej zarejestrowane
jako „małe prawdopodobieństwo, duży wpływ", co
oznacza, że prawdopodobieństwo wystąpienia tego
ryzyka wzrasta.
Ewaluowanie
Głównym celem kroku „Ewaluuj" jest dokonanie
oceny efektu netto wszystkich zidentyfikowanych
zagrożeń i szans w projekcie, gdyby je połączyć.
Umożliwia to przeprowadzenie oceny ogólnej
dotkliwości wagi ryzyk dotyczących projektu i usta-
lenie, czy ten poziom ryzyka netto mieści się w gra-
nicach tolerancji ryzyka określonych przez Komitet
Sterujący oraz czy projekt nadal zachowuje zasad-
ność biznesową.
88 I Ryzyko

0,9 B. wysokie 0,045 0,09

71- 900/o

o Wysokie
3 0,7
51-70%
0,035 0,07 o, 14
t:
•C
QI
·-
.D
o średnie
"O 0,5 0,025 0,05 O, 10
o 3 1-50°/o
a.
o
"O
3
....
CV
0,3 Niskie 0,015 0,03 0,06 O, 12
<l.
11-300fc.

B. niskie
O, 1 0,005 0,01 0,02 0,04 0,08
poniżej 10%

B. mały M ały Śred n i Duży B. duży

0,05 o, 1 0,2 0,4 0,8

Wpływ

Rysunek 8.5 Macierz prawdopodobieństwo/wpływ

Tabela 8.1 Przykład techniki pi eniężnej wartości

Techniki ewaluacji ryzyka
oczekiwanej
Ocenę ryzyka można przeprowadzać przy wyko-
rzystaniu technik takich jak: Identyfikator Prawdopo- Wpływ Wartość
ryzyka dobieństwo oczekiwana
• Modele ryzyka Przykładem jest analiza (%) (zl) (zl)
Monte Carlo. Ten modeł umożliwia symu- 1 60 20000 12000
lację wariantów „co by było, gdyby" przy 2 30 13000 3900
wykorzystaniu losowych liczb w celu ustale-
3 10 4000 400
nia, czy każde ryzyko w danym przedziale
4 5 10000 500
wystąpi, czy nie. Symulacje te są powtarzane
w celu przewidzenia „średniego" pozio- Pieniężna wartość oczekiwana 16800
mu ryzyka dla czasu lub kosztów projektu.
Tak określone scenariusze można również
wykorzystać do zamodelowania przypadków
skrajnych (np. jeżeli prawie wszystkie ryzyka
B. wysokie oe
wystąpią). Wysokie o o
• Pieniężna wa rtość
oczekiwana Technika ta
wykorzystuje pieniężne wartości oczekiwa- średnie e 0
ne poszczególnych ryzyk i sumuje je w celu
uzyskania ich łącznej wartości. Umożliwia to Niskie ~ 8
szybką i łatwą ocenę grupy ryzyk w celu zro-
zumienia ich połączonego skutku. Przykład 0 f) 0
pz
8. niskie
został przedstawiony w Tabeli 8.1.
B. maly Maly Średni Outy 8. duży
Wol••„

- - • •- - • •• Linia tolerancji ryzyka

Rysunek 8.6 Sumaryczny profil ryzyka


Reakcje na zagrożenia
Unikanie
Redukowan ie
(prawdopodobieństwa i/lub wplywu)
Plan rezerwowy
(redukuje tylko wpływ)
Przeniesienie
(redukuje t ylko wpływ, a często tylko
skutki finansowe)
Wspóldzielenie
Akceptowanie
Rysunek 8.7 Reakcj e na zagrożenia i szanse
8.3.5.3 Planowanie
Glównym celem kroku „Planuj" jest przygotowanie
określonych reakcji za rządczych na zidentyfikowane
zagrożen i a i szanse, naj lepiej w celu usu n i ęci a lub
zmn iejszenia zagrożeń o raz maksymalizacji szans.
Poświęcen i e uwagi krokowi „Planuj" zapewnia, na
ile to możliwe, że zmaterializowanie się ryzyka nie
będzie dla projektu zaskoczeniem.
W ra mach kroku „ Planuj" identyfikuje się i ocenia
szereg moż liwych rea kcj i na zagrożen ia i szanse.
Ważne jest, aby wybra na reakcja na ryzyko była pro-
Tab ela 8.2 Reakcje na ryzy ko
Reakcja Def inicja
~~~~~~~~~-'-~~~~~~~~~~~~~~
Unikanie Obejmuje zazwyczaj zmianę jakiegoS aspektu
(zagrożenia) projektu. np. zakresu, trybu zaopatrzenia,
dostawcy lub kolejnoSci dzialań tak. aby
zagrożenie nie mogło już wpływać albo aby nie
mogło zaistnieć.
~~~~~~~~~~~~~~~~~~~~~~~~
Redukowanie Proaktywne dzialania podjęte w celu:
(zagrożenia) • zmniejszenia prawdopodobieństwa
wystąpienia zdarzenia przez zastosowanie
pewnej formy sterowania;
• ograniczenia wpływu zdarzenia
w przypadku wystąpienia tego zdarzenia.
Plan rezerwowy Przygotowanie planu rezerwowego dla dzialań,
(dla zagrożeń) które będą podjęte w celu zredukowania
skutków zagrożenia, gdy ryzyko się
zmateńalizuje. Jest to reaktywna forma reakcji
. redukowania". która nie ma wpływu na
prawdopodobieństwo wystąpienia ryzyka.
Ryzyko I 89
Reakcj e n a szan se
Wykorzystanie
Wzmocnienie
Odrzucenie
porcjonałna do wielkości ryzyka i aby dała wartość
uzasadniającą poniesione nakłady. Kluczowym czyn-
nikiem podczas wyboru reakcji będzie bilansowanie
kosztów wdrożen ia reakcji oraz prawdopodob i eń­
stwa i skutków do puszczenia do wystąpien ia ryzyka.
Wszelk ie wybrane reakcje powinny być wbudowane
w odpowiedni poziom planu, z zabezpieczeniem
środków dla wszelkich planów rezerwowych .
Różne typy rea kcj i na zagrożen i a i szanse przedsta-
w ion o w sk rócie n a Rysunku 8.7.
Typy reakcji zostały dalej wyjaśnione w Tabeli 8.2.
Przyklad
Narada o bardzo dużym znaczeniu może być zagrożona
zaklóceniami w podróżach lotniczych, a więc zamiast
tego, podejmuje się decyzję o przeprowadzeniu tej narady
w drodze telekonferencji.
W celu zmniejszenia prawdopodobieństwa. że użytkownicy
nie będi) korzystać z produktu, zwiększa się liczbę szkoleń .
W celu zmniejszenia wplywu na terminy w przypadku
uszkodzenia prototypu podczas transportu, wykonuje się
dwa prototypy.
Firmowe stanowisko do testów jest dostępne tylko przez
dwa tygodnie w sierpniu. W celu ograniczenia skutków na
wypadek, gdyby produkt nie byl gotowy na czas, istnieje
plan rezerwowy wynajęcia zastępczego stanowiska do
testów (przy większych kosztach).
90 I Ryzyko
Reakcja Definicja
Przeniesienie Strona trzecia przejmuje odpowiedzialność za
(zagrożenia) część finansowych skutków zagrożenia (na
przykład przez ubezpieczenie lub za pomocą
odpowiednich klauzul umownych). Jest to forma
reakcji „redukowanie", która redukuje wyłącznie
skutki finansowe zagrożenia.
Akceptowanie Podjęcie świadomej i przemyślanej decyzji
(zagrożenia) o braku reakcji na dane zagrożenie po
rozpoznaniu, że powstrzymanie się od działania
jest bardziej ekonomiczne niż próba reagowania
na ryzyko. Zagrożenie takie powinno być
następnie monitorowane w celu upewnienia się.
że pozostaje ono na tołerowałnym poziomie.
Współdziel enie Nowoczesne metody współpracy z dostawcami
(zagrożenia zazwyczaj obejmują współdzielenie ryzyka
lub szansy) w pewnej formie poprzez zastosowanie formuły
podziału zysków/pokrycia strat: obie strony dzielą
się zyskami (w ustalonych z góry granicach), jeżeli
koszty są niższe niż w planie kosztów, i wspólnie
pokrywają straty (również w ustalonych z gó1y
granicach) w przypadku przekroczenia planu
kosztów. W wielu sektorach przemysłu zasady
współdzielenia ryzyka są włączane do kontraktów
z osobami trzecimi.
Wykorzystanie Wykorzystanie szansy w celu zapewnienia,
(wyeksploatowanie że ona zaistnieje, a jej potencjał zostanie
szansy) wykorzystany.
Wzmocnien ie Proaktywne działania podejmowane w celu:
(rozwinięcie szansy) • zwiększenia prawdopodobieństwa
wystąpienia zdarzenia;
• zwiększenia wplywu zdarzenia, jeżeli ono
wystąpi .
Odrzucenie Podjęcie świadomej i przemyślanej decyzji
(szansy) o niewyeksploatowaniu lub nierozwijaniu
szansy po ustaleniu, że jest to bardziej
ekonomiczne niż próba podejmowania jakiejś
reakcji. Taka szansa powinna być nadal
monitorowana.
Przykład
W celu redukcji skutków finansowych w przypadku
uszkodzenia prototypu podczas transportu, jest on
ubezpieczony.
W celu redukcji skutków finansowych w przypadku,
gdyby produkt nie był gotowy do wdrożenia na czas
przed targami handlowymi, kontrakt z dostawcą
zawiera klauzule przewidujące odszkodowanie umowne
w przypadku opóźnień.
Istnieje zagrożenie, konkurent może pierwszy
że
wdrożyć rywalizujący produkt, co będzie mieć wpływ na
oczekiwany udzial produktu w rynku. Można przyspieszyć
realizację projektu, zwiększając zasoby, ograniczyć zakres
produktu, aby można go było uko1\czyć wcześniej. albo
nie podejmować żadnych działań. Przyspieszenie realizacji
projektu może doprowadzić do powstania problemów
z jakością produktu, natomiast ograniczenie zakresu może
sprawić, że produkt będzie 1nniej atrakcyjny, tak więc
ryzyko zostaje zaakceptowane, a wybrana zostaje opcja
niepodejmowania żadnych działań.
Wahania cen ropy naftowej mogą mieć niekorzystny
wpływ na koszt realizacji projektu. Klient i dostawca
uzgadniają, że podziela. się po równo kosztami podwyżek
cen lub kwotami zaoszczędzonymi w przypadku obniżki
cen względem punktu środkowego ustalonego w czasie
uzgadniania kontraktu.
Istnieje ryzyko, że projekt będzie opóźniony. Ale, jeżeli
projekt będzie opóźniony, można będzie wdrożyć nowszą
wersję oprogramowania, co powinno ograniczyć koszty
bieżącego utrzymania. Komitet Sterujący zgadza się
zmienić harmonogram i zakres projektu, umożliwiając
zakup i wdrożenie nowszej wersji oprogramowania.
Możliwe jest, że produkt zaliczy testy akceptacyjne
użytkownika w trakcie jednego cyklu testów zamiast
planowanych dwóch. Pozwoli to dostarczyć produkt
wcześniej i przed rywalizującym produktem konkurenta.
Komitet Sterujący podejmuje decyzję o przeprowadzeniu
testu próbnego, aby zwiększyć prawdopodobieństwo, że
produkt zaliczy pierwsze testy akceptacyjne użytkownika,
oraz o przygotowaniu się na możliwość wcześniejszego
przekazania produktu.
Możliwe jest. że
produkt zaliczy testy akceptacyjne
użytkownika w trakcie jednego cyklu testów zamiast
planowanych dwóch. Pozwoli to dostarczyć produkt
wcześniej, przed rywalizującym produktem konkuren ta.
Komitet Sterujący zdecyduje się jednak nie skorzystać
z wcześniejszego wydania i pozostać przy planowanej
dacie przekazania produktu.

Reakcje na ryzyko niekoniecznie usuwają ryzyko
inherentne w całości, a w zwi ązku z tym pozosta·
wiają ryzyko rezydualne. Jeżeli ryzyko inherentne
było istotne i reakcja na to ryzyko zakończyła się
tylko częściowym powodzeniem, ryzyko rezydualne
może być znaczne. Wskazany może być wybór wię­
cej niż jednej reakcji na ryzyko.
W niektórych przypadkach wdrożenie reakcji na
ryzyko spowoduje zmniej szenie lub u sunięcie innych
powi ązanych ryzyk. Jest również możliwe, że reak-
cje na ryzyka, po ich wdrożeniu, zmienią jakiś aspekt
projektu, co z kolei może doprowadzić do powsta-
nia ryzyk wtórnych, tj. ryzyk, które mogą wystąpić
jako skutek zastosowania reakcji na ryzyko. Jest nie-
zwykle istotne, żeby ryzyka te zostały zidentyfiko-
wane, ocenione i kontrolowane w taki sam sposób,
co ryzyko inherentne.
Zaleca si ę dokonanie przeg l ądu doświadczeń
z wcześniejszych podobnych projektów podczas
planowania reakcji na ryzyko. Pomoże to zidenty-
fikować obszar dostępnych reakcji oraz ocenić ich
prawdopodobną skuteczność.
Należy również rozważyć wpływ, jaki potencjalne
rea kcje mogą m i eć na:
• Plan Projektu, Plan Etapu i Grupy Zadań;
• Uzasadnienie Biznesowe;
• Zarządzanie organizacją i/lub programem.
8.3.5.4 Wdrożenie
Głównym celem kroku „Wdrażaj" jest zapewnienie,
aby planowane reakcje na ryzyko zostały zrealizo-
wane, ich efektywność byla monitorowana oraz aby
zostały podjęte działania korygujące, w przypadku
gdyby reakcje te nie spełniały związanych z nimi
oczekiwań.
Istotnym elementem kroku „Wdrażaj " jest zapew-
nienie jednoznacznego przydziału ról i obowiązków
mających na celu wspierania Kierownika Projektu
w za rządzaniu ryzykami związa nymi z projektem.
Główne role w tym zakresie to:
• Właściciel ryzyka Wskazana imiennie osoba,
która jest odpowiedzialna za zarządzan ie, moni-
torowanie i kontrolowanie wszystkich aspektów
przypisanego jej konkretnego ryzyka, łącznie
z wdrożen i em wybranych reakcji na zagrożenia
lub w celu maksymalizacji wykorzystania szans.
Ryzyko I 91
• Wykonawca reakcji na ryzyko Osoba wyzna-
czona do wykonania działania lub działań zwią­
zanych z reakcją na konkretne ryzyko lub grupę
ryzyk. Osoby te wspierają właściciela ryzyka
i otrzymują od niego polecenia.
Przykład właściciela ryzyka i wykonawcy reakcji
na ryzyko
Istnieje ryzyko, że kluczowy dostawca może być
postawiony w stan upadłości. Dyrektor handlowy
został wyznaczony jako właścici el ryzyka. Ziden-
tyfikowano i wybrano szereg reakcji na ryzyko.
Jedną z tych reakcji na ryzyko (plan rezerwowy)
jest zidentyfikowanie potencjalnych dostawców
zastępczych, którzy będą w stanie szybko prze-
jąć zagrożone Grupy Zadań, oraz uzyskanie od
nich kosztorysów. Kierownik ds. Zamówień jest
wykonawcą reakcj i na ryzyko dla tej konkretnej
reakcj i na ryzyko.
W wielu przypadkach właściciel ryzyka i wykonawca
reakcji na ryzyko będą prawdopodobnie jedną i tą
samą osobą. Właściciel ryzyka powinien być osobą
najbardziej odpowied nią do zarządzania ryzykiem.
Należy unikać przydzielania zbyt wielu ryzyk jednej
osobie.
8.3.5.5 Komunikacja
Komunikacja to krok, który jest realizowany cią­
gle. Krok „Komunikuj" powinien zapewnić, aby
informacje o zagrożeniach i szansach dotyczących
projektu byly przekazywane zarówno w ramach
projektu, jak i na zewnątrz, do interesariuszy.
Ryzyka są komunikowane w ramach następujących
produktów zarządczych:
• Raporty z Punktów Kontrolnych;
• Raporty Okresowe;
• Raporty Końcowe Etapów;
• Raporty Końcowe Projektu;
• Raporty Doświadczeń.
Należy zachować ostrożność przy wykorzystaniu
tych raportów do przekazywania informacji o ryzy-
kach interesariuszom zewnętrznym, przy czym
należy odwołać się do Strategii Zarządzania Komu-
nikacją w sprawie wyboru najbardziej odpowiedniej
metody.
92 I Ryzyko
Istnieje wiele innych metod komunikacji, takich jak
biuletyny, tablice informacyjne, tablice zbiorcze
wybranych wskaźników, listy dyskusyjne, narady itp.,
które można rozważyć równolegle z produktami
zarządczymi PRINCE2.
Należy rozpoznać i zastosować szereg aspektów
komunikacji, aby zarządzanie ryzykiem bylo sku-
teczne:
• Narażenie projektu na ryzyko nigdy nie jest sta-
tyczne: skuteczna komunikacja jest kluczem do
identyfikacji nowych ryzyk lub zmian istniejących
ryzyk. Zależy to od utrzymania dobrej sieci infor-
macyjnej, obejmującej odpowiednie kontakty
i źródła informacji, ulatwiającej identyfikację
zmian, które mogą wplywać na ogólne naraże­
nie projektu na ryzyko.
• Skuteczne zarządza nie ryzykiem jest uza l eżnione
od wspóluczestnictw a, które z kolei j est uzależ­
nione od skutecznej komunik acji.
8.3.6 Budżet ryzyka
Budżet ryzyka, jeże l i jest wykorzystywany, jest
kwotą p i eniężną uwzględnioną w budżecie projek-
tu, zarezerwowaną na finansowanie określonych
reakcji kierownictwa na zagrożenia i szanse projek-
tu (np. na pokrycie kosztów wszelkich planów rezer-
wowych, jeżeli trzeba będzie je wdrożyć).
W celu ustalenia budżetu ryzyka dla projektu, nale-
ży zastosować podejście do zarządzania ryzykiem
oparte na pieniężnej wartości oczekiwanej. Każde
ryzyko należy w pełni przeanalizować pod kątem
kosztów wplywu, kosztów reakcji i prawdopodo-
bi eństwa. Suma kosztów (reakcji i wplywu), ważona
w kategoriach prawdopodobieństwa każdego ryzy-
ka, daje pieniężną wartość oczekiwaną zbioru ryzyk.
Pieniężna wartość oczekiwana może być wykorzy-
stana do ustalenia budżetu ryzyka. Zakłada się, że
budżet ryzyka będzie mógł być wykorzystywany
w trakcie całego projektu. Należy zachować ostroż­
ność, aby suma uwzględnionych kosztów nie byla
znieksztalcona przez niewielką liczbę dużych ryzyk.
W takich wlaśnie przypadkach pomocne mogą być
techniki analityczne, takie jak analiza Monte Carlo
i związane z nimi oprogramowanie narzędziowe.
Ponieważ budżet ryzyka jest częścią budżetu pro-
jektu, może pojawi ć się tendencja, aby traktować
go po prostu jako dodatkową kwotę pien i ężn ą,
którą Kierownik Projektu może dysponować. Do
takiego podejścia powinna skutecznie zn i echęcać
Strategia Zarządzania Ryzykiem, określając mecha-
nizmy kontroli i dostępu do tego budżetu. W miarę
postępu real izacji projektu, niektóre wcześn iej
zidentyfikowane ryzyka mogą wystąpić, a inne nie.
W okresie trwania projektu mogą być zidentyfi-
kowane nowe ryzyka i koszty reakcji na te ryzyka
mogą nie być uwzg l ęd n ione w budżecie projektu.
Zawsze roztropnie jest usta l ić budżet ryzyka obej-
mujący ryzyka znane (zidentyfikowane) oraz rezer-
wę na ryzyka nieznane (które nie zostały jeszcze
zidentyfikowane). I
8.4 OBOWIĄZKI
Tabela 8.3 przedstawia obowiązki dotyczące tema-
tu Ryzyko. Więcej szczególów na temat ról zespolu
zarządzania projektem i powiązanych z nimi obo-
wiązków przedstawiono w Dodatku C.

Tabela 8.3 Obowiązki dotyczące
Rola
Kierownictwo organizacji lub
programu
Przewodniczący
Główny Użytkownik
Glówny Dostawca
Kierownik Projektu
Kierownik Zespolu
Nad zór Projektu
Wsparcie Projektu
Ryzyko I 93
tematu Ryzyko
Obowiązki
Ustanawia politykę zarządzania ryzykiem w organizacji oraz przedstawia wytyczne dotyczące
procesu zarządzania ryzykiem (lub podobne dokumenty).
Ponosi odpowiedzialność za wszystkie aspekty zarządzania ryzykiem. a w szczególności za
zapewnienie, by istniala Strategia Zarządzania Ryzykiem dla projektu.
Zapewnia, aby ryzyka związane z Uzasadnieniem Biznesowym byly identyfikowane, oceniane
i kontrolowane.
Przekazuje ryzyka kierownictwu organizacji lub programu w razie potrzeby.
Zapewnia, aby ryzyka dotyczące aspektów związanych z użytkownikami byly
identyfikowane, oceniane i kontrolowane (np. wplyw na korzyści, eksploatację i utrzymanie).
Zapewnia, aby ryzyka dotyczące aspektów związanych z dostawcą byly identyfikowane,
oceniane i kontrolowane (np. wplyw na wytwarzanie produktów projektu}.
Opracowuje Strategię Zarządzania Ryzykiem.
Zakłada i prowadzi Rejestr Ryzyk.
Zapewnia, aby ryzyka w projekcie byly identyfikowane, oceniane i kontrolowane przez caly
okres życia projektu.
Uczestniczy w identyfikowaniu, ocenie i kontroli ryzyk.
Dokonuje przeglądu praktyk zarządzania ryzykiem w celu zapewnienia, by byly one
stosowane zgodnie ze Strategią Zarządzania Ryzykiem.
Wspólpracuje z Kierownikiem Projektu w utrzymywaniu Rejestru Ryzyk dla projektu.
9 Zmiana
9. 1 PRZEZNACZENIE
Przeznaczeniem tematu Zmiana jest identyfika-
cja, ocena oraz sterowanie wszelkimi potencjal-
nymi i zatwierdzonymi zmianami obiektu odnie-
sienia (np. zatwierdzonego produktu).
Zmiany są nieuniknione w okresie życia projektu
i każdy projekt wymaga systematycznego podejścia
do identyfikacji, oceny i sterowania zagadnieniami,
które mogą prowadzi ć do zmian.
Po n i eważ propozycje zmiany m ogą pochodzi ć o d
członków zespołu projektowego, z wniosków inte-
resariuszy, skarg lub szerokiego wachlarza innych
czynników, PRINCE2 dostarcza wspólnego pod ejścia
do sterowania zagadnieniami i zmianami.
PRINCE2 dostarcza wspólnego, systematycznego
podejścia, które zapewnia właściwe zarządzanie
zagadnieniami mającymi potencjalnie wpływ na
docelowe wskaźn iki wykonania projektu (czas,
koszt.• j akość, zakres, ryzyko i korzyści).
Sterowanie zagadnieniami i zmianami to dzialanie
ciągłe, wykonywane przez cały okres życia projek-
t u. Bez bi eżącej, skutecznej procedury sterowania
zagadnieniami i zmianami, projekt albo całkowi cie
przestanie reagowa ć na potrzeby swoich interesa-
riuszy, albo szybko wymknie si ę spod kontroli.
Celem procedur sterowania zagadnieniami i zmiana·
mi nie jest zapobieganie zmianom, lecz zapewnie-
nie, by każda zmiana była zatwierdzona przez odpo-
wiedni organ przed jej wprowadzeniem. Zmianę
można rozważać j edynie w odniesieniu do ustalone-
go stanu rzeczy, tj. obiektu odniesienia (np. zatwier-
dzonego produktu). W zwi ązku z tym warunkiem
wstępnym skutecznego sterowania zagadnieniami
i zmianami j est ustanowienie wlaściwego systemu
za rządzan i a konfi g uracj ą, kt óry rej estruje obiekty
odniesienia dla produktów proj ektu i zapewnia, aby
klientowi zostały dost arczone właściwe wersje.
9.2 DEFINICJA ZMIANY
9.2.1 Sterowanie zagadnieniami
i zmianami
Procedury sterowania zagadnieniami i zmianami
zapewniają, że wszystkie zagadnienia i zmiany,
które mogą wplywać na uzgodnione obiekty odnie·
sienia projektu, są identyfikowane i ocenianie,
a następnie zatwierdzane, odrzucane lub odraczane.
9.2.2 Zarządzanie konfiguracją
Zarząd za n ie konfig uracj ą jest d ziała n ie m technicz-
nym i administracyjnym, dotyczą cym tw orzenia,
utrzymania i kontrolowanej zmiany konfiguracji
przez cały okres życia produktu (lub j ego elementu
składowego).
Obiekt konfiguracji to element, który podlega
zarządzaniu konfiguracją. Element ten może być
częścią produktu, produktem lub zbiorem produk-
tów stanowiących wydanie. Na przykład:
• część produktu: silnik elektryczny, który jest czę­
ścią maszyny;
• produkt: maszyn a;
• wydanie - zbiór produktów: maszyna, w yremon-
towana maszynownia, materialy szkoleniowe
oraz n iezbędne zaświadczenia dotyczące bezpie-
czeństwa i higieny pracy.
Wydanie jest kompletnym i spójnym zbiorem pro·
duktów, który jest zarządzany, testowany i insta-
lowany jako jedna jednostka, którą przekazuje się
użytkownikowi(-om).
Procedury sterowania zagadnieniami i zmianami
powinny być zintegrowane z syst emem zarządzan i a
konfiguracją wykorzystywanym przez proj ekt.
9.2.3 Zagadnienia
Termin „zagadnienie" jest używany w PRINCE2 dla
określenia istotnego zdarzenia, które wystąpiło,
które nie bylo planowane i które wymaga podję­
cia czynności zarządczych . Może to być problem,
obawa, zapytanie, wniosek o wprowadzenie zmia-
ny, sugestia lub odstępstwo zgłoszone w trakcie
projektu. Zagadnienia proj ektowe mogą dotyczyć
w szelkich kwestii związa nych z projektem.
98 I Zmiana

Tabela 9.1 Rodzaje zagadnień

Rodzaje zagadnień Definicja Przykłady

Wniosek o wprowadzen ie Propozycja zmiany obiektu odniesienia
zmiany (obiektu bazowego).
Odstępstwo Coś.co powinno być dostarczone przez
projekt, ale w chwili obecnej nie jest
dostarczane (lub przewiduje się, że nie
będzie dostarczone). Może to być brakujący
produkt lub produkt niezgodny ze swoją
specyfikacją.
Główny Użytkownik chciałby zwiększyć
dostępność produktu z dotychczasowych 1OO do
150 użytkowników.
Wiadomość od dostawcy, że nie jest on w stanie
dostarczyć jednego z produktów określonych
przez klienta.

Problem/obawa Każde inne zagadnienie, które Kierownik Wiadomość od Kierownika Zespołu, że jeden
Projektu musi rozwiązać łub przekazać na z członków zespołu zachorował i w wyniku tego
wyższy szczebel zarządzania. docelowy termin ukończenia Grupy Zadań może
opóźnić się o tydzień.

Zawiadomienie, że jeden z dostawców

zbankrutował, w wyniku czego zachodzi
potrzeba zidentyfikowania i zaangażowania
nowego dostawcy.

9.2.4 Rodzaje zagadn i eń Znaczenie i wykorzystanie ka żdego z tych produk-

Zagadnienia mogą być zglasza ne w dowolnym cza-
sie w trakcie projektu, przez dowolną osobę zainte-
resowaną projektem lub jego wynikiem.
Tabela 9.1 przedstawia podsumowanie różnych
rodzajów zagadn i eń, którymi należy zaj mować się
w trakcie projektu.
9.3 PODEJŚCIE PRINCE2 DO ZMIANY
9.3.1 Ustanowienie mechan izmów
sterowania
Mechanizmy sterowania zagad nieniami, zm ianami
i zarządzaniem konfiguracją w proj ekcie będą defi-
niowane i ustalane w procesie Inicjowanie Projek-
tu, a następnie poddawane przeg l ądowi i Oeśl i to
konieczne) aktualizacji pod koniec każdego etapu
zarządczego w procesie Zarządzanie Końcem Etapu.
Następujące produkty zarządcze są wykorzystywane
do ustalania i utrzymania mechanizmów sterowania
zagadnieniami, zmianami i zarządzaniem konfigura-
cj ą w projekcie:
• Strategia Zarządzania Konfig uracją;
tów zarządczych zostalo opisane w sekcjach 9.3.1.1-
9.3.1.6.
9.3. 1. 1 Strategia Zarządzania Konfigura cją
Skuteczne sterowanie zagadnieniam i i zmianami
jest możliwe wyłączn i e wtedy, gdy jest wspierane
przez system zarządzania konfiguracją, który umoż­
liwia oceny oddziaływania (powiązania pom i ędzy
produktami) i utrzymuje obiekty odniesienia pro-
duktów (bazę, w stosunku do której określa si ę
zmia ny obiektów).
Punkt em wyjścia dla wszystkich projektów będzie
ustalenie, czy organizacja lub program posiada poli -
tykę i procesy, które należy wykorzystać, a następnie
uwzg l ędnić je w indywidualnej Strategii Zarządza­
nia Konfiguracją projektu. Strategia ta powinna
określać:
• procedurę zarządzania konfiguracją (np. plano-
wanie, identyfikowanie, sterowanie, zestawienie
statusu, weryfikowanie i audyt);
• procedurę sterowania zagadnieniami i zmianami
(np. rej estrowanie, analizowanie, proponowanie
rozwiązań, podejmowanie decyzj i, wdrażan i e);

• Zapisy Obiektu Konfiguracj i;

• narzędzia i techniki, które będą wykorzystane;
• Zestawienia Statusu Produktów;
• zapisy, które będą prowadzone;
• Dziennik Projektu;
• sposób raportowania wyników procedur;
• Rejestr Zagadn i eń;
• terminy dzialań dotyczących zarządzan i a konfigu-
• Raporty o Zagadnieniach. racją oraz sterowania zagadnieniami i zmianami;

• Role i obowiązki dotyczące zarządzania konfigu-
racją oraz działań związanych ze sterowaniem
zagadnieniami i zmianami (łącznie z określe­
niem, czy będą zaangażowane jakieś role z kie-
rownictwa organizacji lub programu).
Strategia Zarządzania Konfiguracją powinna okre-
ślać sposób obsługi zagad nień. W trakcie etapu
inicjowania, Kierownik Projektu i Komitet Sterujący
powinni uzgodnić:
• skalę pozwalającą określać priorytety zagadnień;
• skalę pozwalającą określać wagę zagadnień;
• poziom zarządzania, na którym będą rozpatry-
wane zagadnienia w zależności od ich wagi.
Przykład priorytetu i wagi
Istnieje szereg sposobów ustalania priorytetu
zagadn i eń - jeden z tych sposobów, zwany „regu-
łą MoSCoW" (od angielskich słów: must, should,
could, won't), polega na tym, że (w odniesieniu
do wniosków o wprowadzenie zmian) zagadnie-
nie jest oceniane jako zmiana, która:
• Musi być wprowadzona Zmiana ma krytycz-
ne znaczenie dla zasadności projektu;
• Powinna być wprowadzona Zmiana jest
istotna i jej brak powoduje osłabienie
Uzasadnienia Biznesowego;
• Może być wprowadzona Zmiana jest poży­
teczna, ale jej brak nie powoduje osłabi enia
Uzasadnienia Biznesowego;
• Nie będzie wprowadzona (na razie)
Zmiana nie ma krytycznego znaczenia ani
nie jest istotna i można poczekać z jej wpro-
wadzeniem.
Istnieją liczne sposoby ustalania wagi zagadnień,
np. liczbowe (np. w skali od 1 do 4) lub opiso-
we (np. drobna, istotna, poważna, krytyczna).
Kierownik Projektu i Komitet Sterujący mogą
uzgod nić, że drobne zagadnienia może rozwią­
zywać Kierownik Projektu, istotne zagadnienia -
Obsługa Zmian, natomiast poważne zagadnienia
muszą być przekazywane Komitetowi Sterujące­
mu, a zagadnienia o krytycznym znaczeniu - kie-
rownictwu organizacji lub programu.
Podczas ustalania, jakiej wagi zagadnienia powinny
być rozpatrywane na jakim szczeblu zarządzania,
Komitet Sterujący może rozważyć możliwość po-
wierzenia Obsłudze Zmian podejmowania niektó-
rych decyzji dotyczących akceptowania/odrzucania
Zmiana I 99
wniosków o wprowadzenie zmiany lub odstępstw,
oraz zdecydować, czy ustanowić budżet na pokrycie
kosztów zmian:
• Obsługa Zmian Obowiązkiem Komitetu
Sterującego jest dokonywanie przeglądu
i zatwierdzanie wniosków o wprowadzenie
zmiany i odstępstw. W projekcie, w którym prze-
widywana jest niewielka liczba zmian, zasadne
może być pozostawienie tego upoważnienia
w rękach Komitetu Sterującego. Jednak dla pro-
jektów, w których będzie prawdopodobnie dużo
zmian, Komitet Sterujący może postanowić, żeby
powierzyć niektóre decyzje osobie lub grupie
osób pełniących rolę Obsługi Zmian. Kierownik
Projektu i/lub osoby, którym powierzono obo-
wiązki Nadzoru Projektu, mogą pełnić funkcję
Obsługi Zmian. Na przykład może być wskazane
mianowanie Kierownika Projektu do roli Obsług i
Zmian w odniesieniu do Grup Zadań tak, aby
wszelkie zmiany, które mieszczą się w granicach
udzielonego mu upoważnienia, mogły być wpro-
wadzane bez kierowania ich do zatwierdzenia
przez Komitet Sterujący.
• Budżet zmian Jest to kwota, co do której klient
i dostawca uzgodnią, że będzie wykorzystana
na pokrycie kosztów wniosków o wprowadze-
nie zmiany, a być może równ i eż kosztów ich
analizy. Wskazane jest ustalenie budżetu na
pokrycie kosztów zmian, chyba że przewidywa-
ny poziom zmian w danym projekcie jest niski.
Takie ustalenie może zmn iejszyć liczbę sytu-
acji nadzwyczajnych o trywialnych powodach
powstających w projektach, w których przewidu-
je się wysoką częstotliwość wniosków o wprowa-
dzenie zmiany. Uwzględnienie budżetu zmian
umożliwia bardziej realistyczne oczekiwania co
do ogólnych kosztów/ram czasowych projektu.
W przypadku, gdy budżet zmian zostanie przy-
dzielony Obsłudze Zmian, Komitet Sterujący
może zechci eć ustalić limit dla (a) kosztu poje-
dynczej zmiany oraz (b) kwoty, którą można
wydać na wprowadzenie zmian w każdym eta-
pie bez kon i eczności zwracania się do Komitetu
Sterującego. Procedura sterowania zmianami
powinna wówczas być określona w taki sposób,
aby dostęp do budżetu zmian był kontrolowany.
Jeżeli budżet zmian jest wykorzystywany, należy
go udokumentować w odpowiednim planie.
Opis Produktu dla Strategii Zarządzania Konfigura-
cją znajduje się w Dodatku A.
100 I Zmiana
9.3.1.2 Zapisy Obiektu Konfiguracji
Przeznaczeniem Zapisów Obiektu Konfiguracji jest
dostarczenie zbioru zapisów, które zawierają infor-
macje takie, jak status, wersja i wariant każdego
obiektu konfiguracji oraz szc.zegóły dotyczące istot-
nych powiązań pomiędzy obiektami.
Opis Produktu dla Zapisów Obiektu Konfiguracji
znajduje się w Dodatku A.
9.3.1.3 Zes tawienie Statusu Produktów
Przeznaczeniem Zestawienia Statusu Produktów jest
dostarczenie informacji o stanie wybranych produk-
tów. Kryteria ich wyboru mogą się różn i ć. Na przy-
klad raport może obejmować ca ły projekt, określ ony
etap, określ ony obszar projektu albo nawet h i sto rię
poj edynczego produktu. Jest to szczególnie przy-
datne, gdy Kierownik Projektu pragnie potwi erdzić
numery wersji produktów.
Opis Prod ukt u dla Zestawienia Statusu Produktów
znajduje się w Dodatku A.
9.3. 1.4 Dziennik Projektu
Dziennik Projektu jest wykorzystywany do rejestro-
wania problemów/obaw, które mogą być obsłużone
w sposób nieformalny przez Kierownika Projektu.
Zagadnienia zarejestrowane pierwotnie w Dzien-
niku Projektu mogą być następnie przeniesione do
Rejestru Zagadnień, jeżeli po ich przeanalizowaniu
zostanie podjęta decyzja, że należy je potraktować
w sposób bardziej formalny.
Dziennik Projektu może również służyć do rejestrowa-
nia wymaganych działań lub istotnych zdarzeń, nie-
zarejestrowanych w innych rejestrach lub dziennikach
PRINCE2. Pelni on więc funkcj ę terminarza projektu.
Opis Produktu dla Dziennika Projektu znajduje s i ę
w Dodatku A.
9.3.1.5 Rej estr Zagadnień
Rejestr Zagadn i eń jest przeznaczony do rejestrowa -
nia i utrzymywania informacji o wszystkich zagad-
nieniach, które są zarządzane w sposób forma lny.
Rejestr Zagadn i eń powinien być regularnie monito-
rowa ny przez Kierownika Proj ektu.
Opis Produktu dla Rejestru Zagadnień znajduje się
w Dodatku A.
9.3. 1. 6 Raport o Zagadni eniu
Raport o Zagadnieniu jest raportem zawierającym
opis, ocenę wpływu i zalecenia dotyczące wniosku
o wprowadzenie zmiany, odstępstwa lub problemu/
obawy. Jest on tworzony wyłącznie dla tych zagad-
nień, które trzeba obsłużyć w sposób formalny.
9.3.2 Procedura zarządzania konfiguracją
Procedury zarządzania konfiguracją mogą się różnić,
ale zazwyczaj obejmują pięć następujących głów­
nych działań:
• Planowanie Zdecydowanie, jaki poziom zarzą­
dzania konfiguracją będzie wymagany dla pro-
jektu i zaplanowanie, w jaki sposób ten poziom
ma być osiągnięty. Wymagany poziom sterowa-
nia będzie si ę różnić dla poszczególnych projek-
tów. Maksymalny możliwy poziom sterowania
jest ustalany przez rozbicie produktów projek-
tu aż do osi ągnięcia poziomu, na którym dany
komponent może być nieza l eżnie zainstalowa-
ny, wymieniony lub zmodyfikowany. Jednakże
zastosowany poziom sterowania będzie uzależ­
niony od znaczenia proj ektu i złożo ności powi ą­
za ń pom iędzy j ego produktami.
• Identyfikowanie Określanie i identyfikowanie
wszystkich komponentów produktów projektu
(zwanych obiektami konfiguracji) na wymaga-
nym poziomie sterowania. Należy wprowadzić
system kodowania, umożliwiający przydzielenie
indywidualnego identyfikatora każdemu obiek-
towi konfiguracji oraz pozwalający zarejestro-
wać różnorodne cechy produktu.
• Sterowanie Uprawnienia do zatwierdzania pro-
duktów projektu i nadawania im statusu obiek-
tów odniesienia oraz następnie do wprowa -
dzania zmian tylko i wyłącznie za zgodą odpo-
wiednich organów. Po zatwierdzeniu produktu
obowiązuje motto: „ Nic się nie dzieje i nic się nie
zmienia bez zezwolenia". Obiekt odniesienia jest
poziomem referencyjnym (bazowym), względem
którego dany obiekt jest monitorowany i kontro-
lowany. W kategoriach zarządzania konfigura-
cją, jest to „ fotog rafia" zbioru produktów, pro-
duktu i komponentów produktu, „ zam rożona "
w pewnym momencie w określonym celu. Celem
tym może być zarej estrowanie, kiedy produkt był
gotowy do przeglądu lub kiedy został zatwier-
dzony. Jeżel i produkt, który został zatwierd zo-
ny, ma być zmieniony, zostaje stworzona nowa
wersja w celu uwzględnienia zmiany, natomiast
poprzednia wersja obiektu odniesienia pozostaje
niezmieniona. Poprzednie wersje obiektu odnie-
sienia powinny być archiwizowane, jeśli to moż­
liwe, a nie usuwane. Sterowanie konfiguracją
 Zmiana I 101

Komitet Sterujący/Obsługa Zmian

Prośba o wytyczne/
Prośba o wytyczne
Raport Nadzwyczajny

• Określ rodzaj •
Ilf 11

Oceń
ł'

wplyw
J
- '
•
I

Określ
- ~

-
'
• Przekat wytej,
' I

• Podejmij
zagadnienia na cele możliwie jeśli poza działania

• Określ wagę/ projektu/ opcje reakcji delegowanymi korygujące

priorytet Uzasadnienie • Oceń opcje uprawnieniami • Uaktualnij
Biznesowe • Zatwierdź, zapisy i plany
• Zapisz • Rekomenduj
i profil ryzyka odrzul lub
w Dzienniku opqe
projektu odrocz
Projektu lub
Rejestrze • Sprawdź re komendowa-
wagę/ ną opcję

„ priorytet
... ... „ ...

. '

Dziennik Projektu lub Rejestr Zagadnień/Raport o Zagadnieniu

Rysunek 9.1 Procedura sterowania zagadnieniami i zmianami

obejmuje również: przechowywanie i odzyski- 9.3.3 Procedura sterowania

wanie wszelkich informacji istotnych dla zarzą­
dzania projektem; zapewnianie bezpieczeństwa
i ochrony obiektów konfiguracji i kontrolowanie,
kto ma do nich dostęp; dystrybucję kopii wszyst-
kich obiektów konfiguracji oraz archiwizowa-
nie całej dokumentacji stworzonej w cyklu życi a
projektu. Sterowaniu konfiguracją podlegaj ą
zarówno produkty zarządcze, jak i produkty spe-
cjalistyczne.
• Zestawienie statusu Raportowanie wszystkich
bieżących i historycznych danych dotyczących
każdego produktu w formie Zestawienia Statusu
Produktów. Kierownik Projektu może polecić
przygotowanie Zestawienia Statusu Produktów
pod koniec etapu, na zakończenie projektu lub
podczas analizowania zagadnień i ryzyk.
• Weryfikow anie i audyt Szereg przeglądów
i audytów konfiguracj i mających na celu porów-
nanie faktycznego statusu wszystkich produk-
tów z zatwierdzonym stanem produktów, zare-
jestrowanym w Zapisach Obiektu Konfiguracji,
w poszukiwaniu ewentualnych rozbieżności. Te
przeglądy i audyty polegają również na spraw-
dzeniu, czy procedura zarz.ądzania konfigura-
cją jest przeprowadzana zgodnie ze Strategią
Zarządzania Konfiguracją. Przeglądy są zazwy-
czaj przeprowadzane na końcu każdego etapu
i na końcu projektu.
zagadnieniami i zmianami
PRINCE2 dostarcza wspólnego podejścia do roz-
patrywania wn iosków o wprowadzenie zmiany,
odstępstw i problemów/obaw, jak to przedstawiono
na Rysunku 9.1.
9.3.3.1 Rejestrowanie zagadnień
Pierwszym krokiem w tej procedurze jest przepro-
wadzenie wstępnej analizy w celu ustalenia, jakiego
rodzaju zagadnienie zostalo zgloszone oraz czy
należy je rozwiązać w sposób formalny, czy niefor-
malny.
Kierownik Projektu będzie prawdopodobnie otrzy-
mywać wiele zagadnień, które można obsłużyć bez
kon ieczności potraktowania ich w sposób formalny,
zwlaszcza, jeżel i dane zagadnienie możn a rozwiązać
nat ychmiast - na przykład jeżel i członek zespołu
zglosi zagadnienie, że jego przepustka u możl iwiaj ą­
ca wstęp na teren projektu wkrótce utraci ważność.
W takich przypadkach Kierownik Projektu powinien
podjąć decyzję o najlepszym sposobie podjęcia dzia-
łania korygującego.
Odróżnienie zagadnień, którymi można zarządzić
nieformalnie, od tych, które wymagają formalnego
zarządzania, ma na celu:
102 I Zmiana

• Zapewnienie, aby decyzje w zespole zarządzania
projektem były podejmowane na odpowiednim
. .
poz1om1e.
• Uniknięcie przeciążenia Komitetu Sterującego
zbyt w ieloma zagadnieniami, co ogranicza jego
czas przeznaczony na rozwiązywanie kluczowych
zagadnień dotyczących projektu.
• Zmniejszenie obowiązków administracyjnych
obciążających Kierownika Projektu podczas
rozwiązywania pojawiających się bieżących
zagadnień.
Rejestr Zagadnień oraz Raport o Zagadnieniu
powinny być uaktualniane w celu uwzględnienia
powyższych informacji, a osoba, która zgłosiła dane
zagadnienie oraz osoba, która sporządziła Raport
o Zagadnieniu Oeżeli była to inna osoba), powinny
być informowane o jego statusie.
Konieczne może być zwrócenie się o wytyczne do
Komitetu Sterującego w celu sprawdzenia jego opi-
nii na temat priorytetu lub wagi danego zagadnie-
nia przed zaproponowaniem rozwiązań .

Zagadnienia zarządzane w sposób formalny powin- 9.3.3.3 Proponowanie rozwiązań

ny być wpisane do Rejestru Zagad nień i opatrzone
indywidualnym identyfikatorem. Należy przygoto-
wać Raport o Zagadnieniu w celu zarejestrowania
tego, co już wiadomo na temat danego zagadnie-
nia. Często przydatne j est poproszenie osoby, która
zgłosiła dane zagadnienie, o stworzenie wstępnego
Raportu o Zagadnieniu.
9.3.3.2 Analizowanie
Następnym krokiem jest zbadanie zagadnienia
przez przeprowadzenie analizy wpływu.
Kierownik Projektu powinien rozważyć,czy warto
przeprowadzić szczegółową analizę wpływu, ponie-
waż nakłady czasu i pracy potrzebne do przeprowa-
dzenia takiej analizy mogą same w sobie spowodo-
wać odchylenie od planu.
Po uzyskan iu pełnej w iedzy na temat wplywu
zagadnienia, następnym krokiem jest rozważenie
różnych opcji reakcji na to zagadnienie oraz zapro-
ponowanie sposobu dalszego dzialania.
Na l eży rozważyć wplyw każdej opcji na docelowe
wskaźniki wykonania projektu w kategoriach czasu,
kosztów, jakości, zakresu, korzyści i ryzyka. Należy
zachować równowagę pomiędzy korzyści ami plyną ­
cymi z zastosowania danej opcji a nakladami czasu,
kosztem i ryzykiem, związanym i z jej zastosowa-
niem, jak to przedstawiono na Rysunku 9.2.
Rozważenie ryzyka powinno obejmować zarówno
ryzyka związane z projektem {np. ryzyko nieukończe­
nia projektu w granicach tolerancji), jak i ryzyka zwią­
zane z użytkowaniem produktów {np. potencjalne

Analiza wplywu powinna uwzględniać wpływ, jaki

zagadnienie ma {lub będzie mieć) na: Koszty
Korzyści
i skutki
• docelowe wskaźniki wykonania projektu w kate-
goriach czasu, kosztów, jakości i zakresu;
• Uzasadnienie Biznesowe projektu, zwłaszcza
w kategoriach oddziaływan i a na korzyści;
• profil ryzyka proj ektu, tj. wplywu na ogólne
narażen i e projektu na ryzyko.

J eżel i
proj ekt jest części ą programu, na l eży
uwzględnić wplyw zmiany na ca łość programu.
Może również występować wplyw na inne projekty,
które niekoniecznie muszą być częścią programu.
Anali za wplywu zagadnień bywa ni eprawidłowo
interpretowana jako określenie wpływu wyłącznie
na klienta. Anal iza wplywu musi obejmować t rzy
obszary: biznes, u żytkownika i dostawcę, na przykład
koszty i nakłady pracy dostawcy, wymagane w celu
wprowadzenia zmiany, oraz ustalenie, które produk-
ty muszą być zmienione. Po przeprowadzeniu analizy
wplywu należy przeprowadzić ponowną ocenę wagi
lub priorytetu zagadnienia. Rysunek 9.2 Analiza możliwych rozwiązań
 Zmiana I 103

zagadnienia zwią zane z efektywnością po rozpoczę­ Prawdopodobne reakcje Komitetu Sterującego na

ciu użytkowania produktów projektu). przekazane mu zagadnienia i sytuacje nadzwyczajne
zostały przedstawione w Tabel i 9.2.
Jeżeli proponowane rozwiązanie oznaczałoby prze-
kroczenie granic. tolerancji dla etapu lub projektu,
9.3.3.5 Wdrażanie
należy rozważyć możliwość sporządzenia Raportu
Nadzwyczajnego dla tego rozwiązania jako załącz­ W tym kroku Kierownik Projektu:
nika do Raportu o Zagadnieniu. • podejmie niezbędne działanie korygujące (takie
jak aktualizacja Grupy Zadań lub wydanie nowej
9.3.3.4 Podejmowanie decyzji Grupy Zadań) albo
Kierownik Projekt u może być w stanie rozwią- • sporządzi Plan Nadzwyczajny do zatwie rdzen ia
zać zagadn ienia bez potrzeby przekazywania ich przez Komitet Sterujący.
Komitetowi Sterującemu. Dla przykładu, Kierownik
W obu przypadkach Kierownik Projektu uaktualni
Projektu może się zająć drobną zmianą zatwierdzo-
Rejestr Zagadnień i Raport o Zagadnieniu, uwzględ­
nej szczegółowej dokumentacji projektowej, która
niając swoją decyzję i poinformuj e o tym wszystkie
nie wpływa na żadne inne produkty Ueżeli jest to
zainteresowane strony.
dozwolone w Strategii Zarządza n ia Konfiguracją),
pod warunkiem, że zosta nie to oficjaln ie zareje- Po zamknięciu zaga dnienia Kierown ik Projektu
strowane. powinien uaktualn i ć Rejestr Zagadn i eń oraz Raport
o Zagadnieniu (odnotowując fakt zamkn ięcia).
Inne zagadnienia mogą wymagać przekazania
Komitetowi Sterującemu (lub powołanej przezeń
Obsłudze Zmian) w celu podjęcia decyzji. Przeka - 9.4 OBOWIĄZKI
zanie na wyższy poziom może nastąpić w formie
Tabela 9.3 przedstawia obowiązki dotyczące
Raportu o Zag adnieniu Uako część prośby o wytycz-
tematu Zmiana. Więcej szczegółów na temat ró l
ne) lub w form ie Raportu Nadzwyczajnego (jeżeli
w zespole zarządza nia projektem o raz związanych
opcja wybrana w ce lu rozwi ąza nia zagadn ienia
z nimi obowiąz ków przedstawiono w Dodatku C.
doprowadziłaby do sytuacji nadzwyczajnej - patrz
Rozdział 1O).

Tabela 9.2 Decyzje Komitetu Sterującego

Wniosek Reakcja Komitetu Sterującego Kwestie do rozważenia

(lub Obsługi Zmian)
Wniosek • Zatwierdzić zmianę. Jeżeliwniosek o wprowadzenie zmiany pociąga za
o wprowadzenie • Odrzucić zmianę. sobą dodatkowe koszty, istnieją trzy główne sposoby
zmiany sfinansowania takich kosztów:
• Odroczyć decyzję.
• Poprosić o więcej informacji. • Wykorzystanie budżetu zmian ijeżeli istnieje
i jest wystaraająco duży).
• Polecić opracowanie Planu Nadzwyczajnego
ijeżeli wniosek o wprowadzenie zmiany • Zwięk.szenie budżetu projektu.
nie może być zrealizowany w granicach • Usunięcie innych elementów z zakresu projektu.
upoważnienia Obslugi Zmian).
Dla finansowania wniosków o wprowadzenie zmiany
nie należy wykorzystywać tolerancji.

•
~~~~~~~~~~~~~~~~~ -~~~~~~

Odstępstwo Zgodzić się na ustępstwo. Komitet Sterujący może podjąć decyzję o zaakce-

• Zażądać rozwiązania kwestii odstępstwa . ptowaniu odstępstwa bez natychmiastowych działań

• Odroczyć decyzję . korygujących. Takie postępowanie jest nazywane

ustępstwem. Jeżeli w odniesieniu do produktu
• Poprosić o więcej informacji.
zostanie wyrażona zgoda na ustępstwo, Opis
• Polecić opracowanie Planu Nadzwyczajnego
fjeżeli ustępstwa nie można udzielić
Produktu należy skorygować przed przekazaniem
produktu Użytkownikowi.
w granicach upoważnienia Obsługi Zmian).
Problem/obawa
• Wydać instrukcję/wytyczne . Czy problem lub sprawę obawy można załatwić

• Polecić opracowanie Planu Nadzwyaajnego. zwiększając granice tolerancji dla etapu?

104 I Zmiana

Tabela 9.3 Obowiązki dotyczące tematu Zmiana

Rola Obowiązki

Kierown ictwo fi rmy lub programu Dostarcza strategię organizacji lub programu dotyczącą sterowania zmianami,
rozwiązywania zagadnień i zarządzania konfiguracją.

Przewodn iczący Ustala Obsługę Zmian i budżet zmian.

Ustala skalę dla wagi zagadnień .
Ustala skalę do określania priorytetu wniosków o wprowadzenie zmiany i odstępstw.
Udziela odpowiedzi na prośby o wytyczne od Kierownika Projektu.
Podejmuje decyzje w sprawie zagadnień przekazanych na wyższy szczebel,
koncentrując się szczególnie na zachowaniu ciągłej zasadności biznesowej.

Główny U żytkownik Udziela odpowiedzi na prośby o wytyczne od Kierownika Projektu.

Podejmuje decyzje w sprawie zagadnień przekazanych na wyższy szczebel,
koncentrując się szczególnie na ochronie oczekiwanych korzyści.

Główny Dostawca Udziela odpowiedzi na prośby o wytyczne od Kierownika Projektu.

Podejmuje decyzje w sprawie zagadnień przekazanych na wyższy szczebel,
koncentrując się szczególnie na zachowaniu spójności całego rozwiązania.

Kierownik Projektu Realizuje procedurę zarządzania konfiguracją przy pomocy Wsparcia Projektu, jeżeli
zostało ono powołane.

Realizuje procedurę sterowania zagadnieniami i zmianami przy pomocy Wsparcia

Projektu. jeżeli zostalo ono powołane.
Zakłada i prowadzi Rejestr Zagadnień przy pomocy Wsparcia Projektu, jeżeli zostało
ono powołane.
Podejmuje dzialania korygujące.

Kierownik Zespolu Podejmuje działania korygujące.

Nadzór Projektu Doradza przy analizowaniu i rozwiązywaniu zagadnień.

Wsparcie Projektu Administruje zarządzaniem konfiguracją oraz procedurami sterowania zagadnieniami

i zmianami:
• prowadzi Zapisy Obiektów Konfiguracji;
• sporządza Zestawienia Statusu Produktów;
• pomaga Kierownikowi Projektu prowadzić Rejestr Zagadnień.
•
10 Postępy
10.1 PRZEZNACZENIE
Przeznaczeniem tematu Postępy jest ustano-
wienie mechanizmów monitorowania i porów-
nywania faktycznych osiągnięć z planowanymi,
dostarczania prognozy dotyczącej możl iwości
osiągnięcia celów projektu i utrzymania jego
ciąglej zasadności oraz kontrolowania wszelkich
nieakceptowalnych odchyl eń.
Dwie spośród zasad metodyki PRINCE2 to za rzą­
dzanie etapowe oraz ciągła zasadność biznesowa.
Temat Postępy dostarcza mechanizmów monitoro-
wania i kontrolowania, umożliwiających krytyczną
ocen ę, czy projekt jest nadal zasadny.
Temat Postępy dostarcza tych mechanizmów wszyst-
kim szczeblom zarządczym (zarządzanie dostarcza-
niem produktów, zarządzanie operacyjne i zarzą­
dzanie strategiczne) w zespole zarządzania projek-
tem oraz kierownictwu organizacji lub programu
poza projektem.
Kolejną zasadą metodyki PRINCE2 jest zarządzanie
projektami z wykorzystaniem tolerancji, zgodnie
z którą ustalane są tolerancje dla celów projektu.
Tolerancje te z kolei slużą do ustanawiania granic
delegowanych uprawnień. Tolerancje określają sto-
pień swobody dzialania, jaką posiada każdy szcze-
bel zarządzania bez potrzeby zatwierdzania jego
dzialań przez wyższy szczebel zarządzan i a. Temat
Postępy dostarcza mechanizmów monitorowania
zaawansowania rea lizacji planów w odniesieniu
do ustanowionych tolerancji oraz mechanizmów
sterowania służących przekazywaniu zagadnień na
wyższy szczebel, w przypadku gdy j akaś prognoza
przewiduje, że jedna lub więcej tolerancji zostanie
przekroczonych.
Kontrola postępów jest ściśl e związana z podej mo-
waniem decyzji i ma ona kluczowe znaczenie dla
za rządzan ia projektem, gwarantując, że proj ekt
pozostaj e zasadny w odniesieniu do zatwierdzone-
go Uzasadnienia Biznesowego.
10.2 DEFINICJA POSTĘPÓW
10.2.1 Czym są postępy?
Postępy są miarą osiągnięcia celów planu. Mogą
być one monitorowane na poziomie Grupy Zadań,
etapu i projektu.
10.2.2 Czym są kontrole postępów?
Kontrole postępów zapewniają, że każdy szczebel
zespołu zarządzania projektem, może w stosunku
do szczebla bezpośrednio podległego:
• monitorować postępy prac;
• porównywać uzyskany poziom realizacji z planem;
• dokonywać przeglądu planów i proponowanych
opcji pod kątem sytuacji w przyszłości;
• wykrywać problemy i określać ryzyka;
• inicjować działania korygujące;
• udzielać zezwolenia na dalsze prace.
10.2.3 Sytuacje nadzwyczajne i tolerancje
Sytuacja nadzwyczajna to taka sytuacja, w której
można prognozować, że wystąpi odchylenie poza
uzgodnione tolerancje.
Tolerancje to dopuszczalne odchylenia powyżej
i poniżej zaplanowanych wartości celów danego
planu, określonych dla terminów i kosztów, bez
potrzeby przekazywania zarządzania takimi odchy-
leniami na kolejny wyższy szczebel zarządzania.
Tolerancje mogą być także ustanowione dla jakości,
zakresu, korzyści i ryzyka.
Jeżel inie stosuje się tolerancji, to nie istnieje jasna
miara swobody działania w przypadku, gdy sytu-
acj a rozwija się niezgodnie z planem. Na przykład
jeżeli każde niewielkie odchylenie przekazywane
jest Komitetowi Sterującemu, to Kierownik Projektu
zaledwie monitoruje prace i nie podej muj e żadnych
wysi łków, aby wdrażać działa nia korygujące - taka
sytuacja j est wyraźnie niezadowalająca z punktu
widzenia członków Komitetu Sterującego. W efek-
cie, Komitet Sterujący musi wykonywać pracę Kie-
rownika Projektu. Z drugiej strony, jeżeli Kierownik
Projektu sam ciągle naprawia sytuację, wdrażając
działania korygujące, istnieje ryzyko, że członkowie
Komitetu Sterującego postrzegać to będą jako
108 I Postępy

Tabela 10.1 Sześć o bszarów tolerancj i d la różnych poziomów zarządzania

Tolerancj e Tolerancje Tolerancje na Tolerancje

Obszary tolerancji na poz1om1e na poziomie poziomie na poziomie
projektu etapu Grupy Zadań produktu

Czas Grupa Zadań nd.

Plan Projektu Plan Etapu
+I- ilości czasu względem terminu zakończenia.

Koszt Plan Projektu Plan Etapu Grupa Zadań nd.

+/-kwoty planowanego budżetu.
Zakres
Dopuszczalne zmiany zakresu realizowanego rozwiązania, Plan Projektu Plan Etapu Grupa Zadań
nd.
np. priorytety dla wymaga1\: musi być. powinno być, może być, (uwaga 1) (uwaga 1) (uwaga 1)
nie będzie teraz.

Ryzyko
limit dla zagregowanej wartości zagrożeń (np. pieniężna wartość Strategia
Plan Etapu Plan Etapu
oczekiwana musi być niższa od I0% planowanego budżetu); Zarządzania nd.
(uwaga 2) (uwaga 2)
i limit dla pojedynczego zagrożenia (np. żadnych zagrożeń Ryzykiem
dla dzialalności produkcyjnej}.

Jakość Opis Produktu

nd. nd.
Określanie celów dla jakości z podaniem przedzialów. np. ciężar Końcowego Opis Produktu
(uwaga 3) (uwaga 3)
produktu 300g +/- 1Og. Projektu
Korzyści
Określanie korzyściz podaniem przedzialów, np. osiągnięcie Uzasadnienie
nd. nd. nd.
oszczędności kosztów minimum 5% na oddzial. 7% średnio Biznesowe
dla wszystkich oddzialów.
Uwaga 1 - zakres planu jest określony przez zbiór produktów, które mają być dostarczone. Tolerancja zakresu Geśli zastosowano) powinna mieć
formę uwag lub odniesień do struktury produktów planu. Tolerancja zakresu na poziomie etapu lub Grupy Zadań jest szczególnie użyteczna. gdy
stosuje się iteracyjny rozwój produktu w ograniczonych przedzialach czasu. tak jak w zwinnych (Agile} metodach zarządzania projektem.

Uw aga 2 - bardziej konkretne poziomy tolerancji ryzyka może ustanowić Komitet Sterujący. kiedy wydaje zezwolenie na realizację etapu, lub
Kierownik Projektu, kiedy zleca Grupy Zadań, a szczególnie, gdy je zleca dostawcom zewnętrznym.
Uwaga 3 - tolerancje jakości nie są określane sumarycznie dla etapu lub Grupy Zadań, lecz sq określane w poszczególnych Opisach Produktów
należących do zakresu danego planu.

przekroczenie (nieopisanego) zakresu uprawnień dzi alań koryg uj ących.

Metodyka PRINCE2 zapewnia
Kierownika Projektu i będą dochodzić, d laczego pro- kontrol ę postępów poprzez:
blemy nie zostały przekazane im wcześni ej. W tym
• delegowanie uprawnień z wyższego poziomu na
przypadku, Kierownik Projekt u post rzega ny j est jako
n i ższy poziom za rządzan i a;
ten, który przejmuje rol ę Komitetu Steruj ą cego.
• podzi ał proj ektu na etapy zarządcze i wydawa-
Tabela 10.1 przedstawia przypadki u żytecznego nie zezwole ń na kontyn uację projekt u sukcesyw-
zastosowania tolerancj i i pokazuje, w którym pro- nie et ap po etapi e;
dukcie zarządczym są one dokument owane. • raportowanie i przeglą dy postępów za l eżne od
czasu oraz za l eżne od zdarzeń;
10.3 PODEJ ŚCI E PRINCE2 DO POSTĘPÓW • zglaszanie sytuacji nadzwyczajnych.

Kontrolowanie postępów obej muje pomiary f aktycz- Mechanizmy st erowan ia proj ektem powinny być
nych wyników w odniesieniu do docelowych wskaź­ udokumentowane w Dokumentacji Inicjowania
ników wykonania w kategoriach czasu, kosztów, Projektu.
jakości, zakresu, korzyści i ryzyka, a następnie wyko -
rzystanie tych informacji do podjęcia decyzji (takich 10.3.1 Delegowanie uprawnień
jak: czy zatwierdzić etap lub G ru pę Zadań, czy prze-
kazać odchylenia na wyższy szczebel, czy przedwcze-
10.3.1.1 Cztery poziomy zarządzania
śnie zam knąć projekt, itd.) o raz podjęcia pot rzebnych Zasada za rzą d zan i a z wykorzystaniem tolerancji
wykorzystuje sześć rodzajów tolerancji, pod k ątem
 Postępy I 109

których można kontrolować projekt. Rodzaj przy-

Kierownictwo organizacji lub programu
dzielanych tolerancji odpowiada czterem pozio-
mom organizacji zespolu zarządzania projektem,
j ak przedstawiono to na Rysunku 10.1 i opisano
Tolerancje Projekt
poniżej :
Projektu postępy/sytuacje nadzwyczajne

• Kierownictw o organizacji lub programu usytu-

owane jest poza projektem, ale ustala calościo­
we wymagania i poziomy tolerancji dla projektu. Komitet Sterujący
Trzy poziomy zarządzania wewnątrz projektu
{odpowiedzialne za zarządzanie strategiczne,
zarządzanie operacyjne i zarządzanie dostarcza- Tolerancje Etap
niem produktów) zarządzają i realizują projekt Etapu postępy/sytuacje nadzwyczajne
w ramach tych tolerancji oraz przekazują na
wyższy szczebel wszelkie prognozowane prze-
kroczenia tolerancji projektu. Kierownik Projektu
• Komitet Sterujący sprawuje ca lościową kontrolę
na poziomie projektu tak d ługo, jak prognozy
pozostają w granicach tolerancji projektu, i przy- Tolerancje Grupa Zadań
dziela tolerancje dla każdego etapu zarządczego Grupy Zadań postępy/zagadnienia

Kierownikowi Projektu. Komitet Sterujący ma

możliwość dokonywania przeglądów postępów
i podejmowania decyzji, czy kontynuować, zmie- Kierownik Zespolu
nić lub przerwać projekt. W czasie wykonywania
Planu Projektu, jeżeli jakieś prognozy wskazu-
ją, że projekt może prawdopodobnie przekro- Rysunek 10.1 Delegowanie tolerancji oraz raportow-
czyć granice uzgodnionych tolerancji, wtedy anie faktycznych i prognozowanych postępów
Komitet Sterujący powinien przekazać informa-
cje o odchyleniu kierownictwu organizacji lub
programu w celu uzyskania decyzji dotyczących
dzialania koryguj ącego. 10.3.1.2 Mechanizmy sterowania
• Kierownik Projektu na bieżąco kontroluje etap wykorzystywane przez Komitet Sterujący
zarządczy w granicach tolerancji ustanowio- Główne mechanizmy sterowania dostępne Komite-
nych przez Komitet Sterujący. W czasie realizacji towi Sterującemu to:
Planu Etapu, jeżeli jakieś prognozy wskazują, że
• Zezwolenia Komitet Sterujący wykorzystuje
etap prawdopodobnie przekroczy uzgodnione
proces Zarządzanie Strategiczne Projektem do
tolerancje, Kierownik Projektu powinien prze-
wydawania zezwoleń na inicjowanie, realizację
kazać informacje o przewidywanym odchyleniu
projektu, realizację każdego etapu i w końcu
Komitetowi Sterującemu w celu uzyskania decy-
zezwala na zamknięcie projektu:
zji dotyczących dzialania korygującego.
• Po przedprojektowym procesie Przygotowanie
• Kierownik Zespołu sprawuj e kontrol ę nad Grupą
Projektu, Komitet Steruj ący wydaj e zezwolenie
Zadań, ale tylko w granicach tolerancji dla Grupy
na przejście do etapu inicjowania, co stanowi
Zadań uzgodnionych z Kierownikiem Projektu.
oficjalny „początek" projekt u.
W czasie wykonywania Grupy Zadań, jeżeli
• Po procesie Inicjowanie Projektu, Komitet
jakieś prognozy wskazuj ą, że prawdopodob-
Sterujący dokonuje przeglądu informa-
ne jest przekroczenie uzgodnionych tolerancji,
cji zawartych w Dokumentacji Inicjowania
Kierownik Zespolu powinien przekazać informa-
Projektu i, jeżeli jest przekonany, że istnieją
cje o przewidywanym odchyleniu Kierownikowi
wystarczające powody, aby kontynuować
Projektu w celu uzyskania decyzji dotyczących
projekt, może zatwierdzić Dokumentację
dzialania korygującego.
Inicjowania Projektu i wydać zezwolenie na
rea l izację projektu.
11 O I Postępy
• Po procesie Zarządzanie Końcem Etapu,
Komitet Sterujący przeprowadza przegląd
Planu Etapu lub Planu Nadzwyczajnego
i może albo zatwierdzić plan z odnośnymi
tolerancjami dla następnego etapu zarząd­
czego, albo, jeże l i nie istnieje wystarczające
uzasadnienie kontynuacji projektu, zdecydo-
wać o przedwczesnym zamkn i ęciu projektu.
• Po procesie Zamykanie Projektu, Komitet
Sterujący dokonuje przeglądu Raportu
Końcowego Projektu i, jeżeli będzie przeko-
nany, że projekt zostal zakończony albo że
nie ma już nic więcej do zaoferowania, może
wydać zezwolenie na jego zamknięcie.
• Aktualizacje informacji o postępach Włączając
w to Raporty Okresowe i Raporty Końcowe
Etapów.
• Obsługa sytuacji nadzwyczajnych i zmian
Włączając w to Raporty Nadzwyczajne i Raporty
o Zagadnieniach.
O ile Komitet Sterujący uzgodni tolerancje dla eta-
pów z Kierownikiem Projektu, jest on informowany
o postępach za pomocą Raportów Okresowych. Nie
ma potrzeby regularnych narad w sprawie postę­
pów w trakcie etapu, chociaż osoby sprawujące obo-
wiązki Nadzoru Projektu zwykle będą potrzebować
regu larnych kontaktów z Ki erownikiem Projektu
i członkami zespołu.
10.3.1.3 M echanizmy sterow ania
wykorzystyw ane przez Kierownika Proj ektu
Główne mechanizmy sterownia dostępne Kierowni-
kowi Projektu to:
• Zezwolenia Zezwolenia są wydawane przez
Kierownika Projektu w procesie Sterowanie
Etapem (patrz Rozdział 15). Kierownik Projektu
odpowiedzialny jest za uzgodnienie i wydanie
zezwoleń na rozpoczęcie Grup Zadań oraz za
ustanowienie tolerancji dla Grup Zadań.
• Aktualizacje informacj i o postępach Włączając
w to Raporty z Punktów Kontrolnych opracowy-
wane przez Kierowników Zespołu albo członków
zespołu.
• Obsługa sytuacji nadzwyczajnych i zmian
Wykorzystanie rejestrów projektu i dzienni-
ków w celu dokonania przeglądu postępów
oraz określenia ryzyk i zagadnień które mogą
wymagać rozwiązania. Omówione są one pełniej
w sekcji 10.3.3.2.
10.3.2 Wykorzystanie etapów zarządczych
do sterowania projektem
Etapy zarządcze są częściami projektu wyzna-
czonymi przez zarządcze punkty decyzyjne. Etap
zarządczy j est zbiorem d ziałań i produktów, których
real i zacją i dostarczaniem zarządza się jako ca łością.
Jako taki, etap zarządczy jest podzbiorem projektu
i w kategoriach metodyki PRINCE2 j est tym frag-
mentem prac, którym na co dzień zarządza Kierow-
nik Projektu w imieniu Komitetu Sterującego.
Etapy zarządcze :
• określają punkty, w których prowadzone są prze-
glądy oraz punkty, w których podejmowane są
decyzje, dając Komitetowi Sterującemu szansę
oceny zasadności projektu w regularnych odstę­
pach czasu, zamiast zezwalania na postępowan i e
w sposób niekontrolowany;
• umożliwiają zagwarantowanie, że kluczowe
decyzje podejmowane są przed szczegółowymi
pracami potrzebnymi do ich wdrożenia;
• pozwalają na wyjaśnienie, jaki będzie wpływ
określonego czynnika zewnętrznego, takiego jak
cykl budżetowy organizacji czy zmiana prawa;
• ułatwiają stosowanie zasady zarządzania z wyko-
rzystaniem tolerancji przez delegowanie upraw-
nień Kierownikowi Projektu etap po etapie.
Komitet Sterujący zezwala każdorazowo tylko na
jeden etap zarządczy projektu. Pod koniec każdego
etapu, w procesie Zarządzanie Końcem Etapu, Kie-
rownik Projektu dokonuje przeglądu Uzasadnienia
Biznesowego i Planu Projektu, aktualizuje doku-
mentację projektu, włączając do niej wyniki bieżą­
cego etapu i opracowuje Raport Końcowy Etapu
oraz Plan Etapu dla następnego etapu zarządczego,
aby wnioskować o zezwolenie na rozpoczęcie jego
realizacji. Raport Końcowy Etapu i Plan Etapu dla
następnego etapu, powinny zawierać wszystkie
informacje niezbędne do umożliwienia Komiteto-
w i Steruj ącemu przeprowadzenia oceny końcowej
bieżącego etapu oraz podjęcia decyzji, czy kontynu -
ować projekt. Komitet Sterujący wydaje zezwolenie
na realizację następnego etapu zarządczego tylko
wtedy, gdy istnieje wystarczające Uzasadnienie
Biznesowe dla kontynuacji projektu. Jeżeli projekt
nie posiada już dalej ważnego Uzasadnienia Bizne-
sowego, Komitet Sterujący ma uprawnienia, aby go
przedwcześnie zakończyć.
Komitet Sterujący deleguje uprawnienia do bieżą­
cego sterowania etapem, w ramach uzgodnionych
tolerancji, Ki erownikowi Projektu. Tak długo, jak

przewiduje się, że etap pozostanie w granicach
tolerancji, Kierownik Projektu ma swobodę wpro-
wadzania potrzebnych modyfikacji działań. Pozwala
to Komitetowi Sterującemu zarządzającemu z wyko-
rzystaniem tolerancji zachować poziom kontroli,
jakiego wymaga, przy jednoczesnym zmniejszeniu
ogólnych kosztów administrowania projektem.
10.3.2 .1 Liczba etapó w
Wykorzystanie etapów w projekcie zgodnym
z PRINCE2 jest obowiązkowe, ale liczba etapów jest
elastyczna i zależy od wielkości i ryzyka projektu.
Każdy projekt zgodny z PRINCE2 składa się z przy-
najmniej dwóch etapów zarządczych. Etap inicjo-
wania jest obowiązkowy, ponieważ zapewnia on
istnienie solidnej podstawy dla projektu, która jest
zrozum iała dla wszystkich stron. Powinien też wystę­
pować przynaj mniej jeden inny etap za rządczy obej-
mujący resztę projektu. Dla większych projektów
mogą być potrzebne dodatkowe etapy zarządcze,
aby umożliwić zespołowi zarządzania projektem
optymalny poziom planowania i kontroli.
Definiowanie etapów zarządczych jest w swej istocie
procesem równoważenia następujących czynników:
• z jakim wyprzedzeniem i na jaki czas można sen-
sownie planować projekt?
• Gdzie n ależy ustanowić kluczowe punkty decy-
zyjne w projekcie?
• Poziom ryzyka w projekcie.
• Dylemat, czy ustanowić wiele krótkich etapów
zarządczych (zwiększając koszty ogólne zarzą ­
dzania projektem), czy mniej długich etapów
(zmniejszając stopień możliwej kontroli).
• Stopień przekonania Komitetu Sterującego i Kie-
rownika Projektu co do możliwości kontynuowa-
nia projektu.
Liczba wymaganych etapów zarządczych podykto-
wana zostanie przez charakter projektu i j ego czas
trwania. Dla projektów krótkotrwałych (gdzie przy-
kładowo proj ekt można ukończyć w granicach hory-
zontu planowania) wprowadzenie wielu etapów
zarządczych mogłoby spowodować niepotrzebne
komplikacje i dodatkowe koszty.
10.3.2.2 Długość etapów
Metodyka PRINCE2 nie określa, jak długo powinien
trwać etap zarządczy. Etapy powinny być krótsze,
gdy występuje większe ryzyko, niepewność łub
złożona sytuacja, na przykład na początku i końcu
projektu. Mogą być dłuższe, kiedy ryzyko jest
Postępy I 111
mniejsze, zwykłe w środku projektu. Poza tym dłu­
gość etapów zarządczych może różnić się zależnie
od punktu w cyklu życia projektu. Czynniki wpły­
wające na tę decyzję obejmuj ą:
• Horyzont planowania w danej chwili Horyzont
planowania może zmieniać się zależnie od cha-
rakteru podejmowanych prac. Na przykład prace
związane z instalacj ą nowego systemu kompute-
rowego w projekcie migracji aplikacji mogą być
bardziej zrozumiałe i mniej ryzykowne niż prace
związane z wymianą aplikacji.
• Etapy techniczne w projekcie Koniec eta-
pów zarządczych nie musi koniecznie zbiegać
się z końcem etapów technicznych, ale często
korzystne jest, jeżeli taka zbi eżność występuje.
Na przykład Komitet Sterujący może chcieć zro-
zum i eć wpływ na Uzasadnienie Biznesowe wyni -
ków „sprawdzenia koncepcji" przed zaangażo ­
waniem środków we wdrożenie na pełną ska l ę.
• Dopasowanie do działań programu Może być
wymagane dopasowanie końca etapu zarząd­
czego do przeg l ądu końca transzy w programie.
Pozwoli to projektowi na wniesienie pełnego
wkładu do oceny ciągłej zasadności samego
programu.
• Poziom ryzyka Etapy zarządcze mogą być bar-
dzo pożyteczne jako środek sprawowania kon-
troli Komitetu Sterującego nad ryzykownymi
projektami. Końce etapów mogą m i eć miejsce
w kluczowych punktach, kiedy to należy doko-
nać przeg l ądu ryzyka w projekcie zanim zaanga-
żowane zostaną znaczne nakłady pieniężne czy
zasoby.
10.3.2.3 Etapy techniczne
Inną metodą grupowania prac w projekcie jest gru-
powanie ich według zestawu zastosowanych technik
lub wytwarzanych produktów. Wynikiem tego są
etapy obejmujące elementy takie, jak projekto-
wanie, konstruowanie i wdrożenie. Etapy takie to
etapy techniczne, które są od rębnym pojęci em od
przedstawionych wyżej etapów zarządczych.
W tym samym czasie może być realizowanych kilka
etapów technicznych Gak pokazano na Rysunkach
10.2 i 10.3), podczas gdy równocześnie nie można
realizować kilku etapów zarządczych. Etapy tech-
niczne cechuje wykorzystanie konkretnego zestawu
umiejętności specjalistycznych. Etapy zarządcze
odpowiadają zaangażowaniu zasobów oraz zezwo-
leniu na ich wykorzystanie.
112 I Postępy

Często końce tych dwóch rodzajów etapów są zbież­ Rysunek 10.4 pokazuje, jak etap techniczny „projek-
ne, na przykład gdy decyzja zarządcza oparta jest towanie" zostal podzielony na trzy grupy produk-
na wyniku etapu technicznego. W innych sytuacjach tów. Projekt ogólny przypada teraz na etap zarząd­
jednakże końce etapów nie będą się pokrywać, na czy nr 1, projekt szczegółowy i program szkolenia
przykład na jeden etap zarządczy może przypadać tworzą drugi etap zarządczy, a projekt wyposażenia
więcej niż jeden etap techniczny. zaplanowano na etap zarządczy nr 3 wraz ze zbudo-
wanymi urządzeniami i przeszkolonym personelem.
Kiedy etap techniczny przekracza koniec etapu
zarządczego, stopień ukończenia produktu(-ów) Projekt
etapu technicznego na końcu etapu zarządczego
powinien być jasno wyrażony w stosownym Opisie
Produkt(-ów).
Rysunki 10.2, 10.3 i 10.4 pokazują przykłady rozróż­
nienia pomięd zy etapami technicznymi a zarządczy­
mi. Rysunek 10.2 pokazuje projekt z pięcioma etapa-
mi technicznymi.
Projekt

Rysunek 10.4 Prace specjalistyczne dopasowane

Rysunek 10.2 Prace specjalistyczne przypisane
etapom technicznym
Rysunek 10.3 pokazuje ten sam projekt, co Rysunek
10.2, ale z podzialem na cztery etapy zarządcze.
Dwa etapy techniczne są realizowane w więcej niż
j ednym etapie zarządczym.
Projekt
Et<'lp zar14d<1v 2
Etap tarzcldCly 1
do etapów zarządczych
Podejście metodyki PRINCE2 zak łada skoncentrowa-
nie zarządzania projektem na etapach zarządczych,
poni eważ tworzą one podstawy procesów planowa-
nia i kontroli opisywanych w calej metodyce. Inne
podejście oznacza ryzyko, że projekt kierowany
będzie przez zespoly specjalistyczne, zamiast być
kierowanym przez klienta.
10.3.3 Mechanizmy sterowania zależne od
zdarzeń i czasu
Metodyka PRINCE2 dostarcza dwóch rodzajów
mechanizmów kontroli postępów w czasie trwania
Et•p lłlr1ądc1y l Etap lar14dczy 4
projektu:

• Mechanizmy uruchamiane przez zdarzenia

Specyf iko\vanic I I I
Są stosowane, gdy wystąpi konkretne zdarze·
I I I
nie, na przykład: koniec etapu, ukończenie
I ProjcklowanlC' I I
Dokumentacj i Inicjowania Proj ektu albo opra-
I
I I I cowanie Raportu Nadzwyczajnego. M ogą także
Budov\fanie
obejmować wydarzenia w organizacji, które
I I I
I I mogą wpłynąć na projekt, np. koniec roku finan-
I Szkolenie
I I sowego.
I I I • Mechanizmy uruchamiane za l eżn ie od czasu
I I I Przekazyi.vanie
do eksploatacji
Są stosowane okresowo w uprzednio określo­
I I I nych odstępach czasu. Może to być na przy-
kład opracowywanie comiesięcznych Raportów
Rysunek 10.3 Prace specjalistyczne wykraczające Okresowych dla Komitetu Sterującego albo coty-
poza końce etapów zarządczych godniowych Raportów z Punktów Kontrolnych
pokazujących postępy Grupy Zadań.

Monitorowanie i raportowan ie wymaga podejścia
opartego na czasie, podczas gdy sterowanie {podej-
mowanie decyzji} jest działaniem opartym na zda-
rzeniach.
Kolejne podrozdziały opi sują produkty zarządcze,
które wykorzystywane są w celu ustanowienia oraz
wykorzystywania mechanizmów uruchamianych
zdarzeniami oraz zależnie od czasu.
10.3.3.1 Obiekty bazowe dla kontroli
postępów
Kontrola jest możliwa
tylko na takim poziomie
szczegółowości, na jakim opracowano plan, tzn. jeśl i
oczekuje się cotygodniowych Raportów z Punktu
Kontrolnego, to należy określić {w Planie Etapu},
jakich osiągnięć oczekuje się tydzień po tygodniu.
Następuj ąceprodukty zarządcze pomagają Kierow-
nikowi Projektu w ustanowieniu obiektów odniesie-
nia {bazowych} dla kontroli postępów:
• Plan Projektu Obejmuje on docelowe wskaź­
niki wykonania i tolerancje na poziomie pro-
jektu. Jakiekolwiek zagrożenie dla tol erancji
na poziomie proj ektu musi zostać przekazane
Komitetowi Sterującemu, który zwróci si ę do kie-
rownictwa organizacji łub programu w sprawie
działań korygujących.
• Plany Etapów Sta nowi ą one podstawę bieżą ­
cej kontroli etapu. Powinny zawie rać szczegóły
działań, które mają być przeprowadzone w trak-
cie etapu zarządczego, ich terminy oraz zasoby
konieczne do ich przeprowadzenia.
• Plan Nadzwyczajny Komitet Sterujący może
zażądać Planu Nadzwyczajnego po rozwa-
żen iu Raportu Nadzwyczajnego w proce-
sie Zarządzanie Strategiczne Projektem. Plan
Nadzwyczajny powinien być opracowany na tym
samym poziomie co plan, który ma on zastąpić.
• Grupy Zadań Kierownik Projektu wyda-
je zezwolenie na wykonanie Grupy Zadań
w celu spowodowania, by jeden z czło nków
zespołu albo Kierownik Zespołu wykonał jakąś
pracę w trakcie etapu. Oznacza to, że praca ta
nie powinna być rozpoczęta o ile Kierownik
Projektu nie wydal konkretnego zezwolenia
na jej wykonanie. Szczegóły dotyczące prac
do wykonania oraz tolerancji dla nich muszą
zostać uzgodnione pomiędzy Kierownikie1n
Projektu a Kierownikiem Zespołu lub członkiem
zespołu i udokumentowane w Grupie Zadań.
Zezwolenie na wykonanie Grupy Zadań jest
Postępy I 113
szczególnie przydatnym mechanizmem stero-
wania w kontaktach z wykonawcami lub pod-
wykonawcami. Osoby lub zespoły monitorują
postępy w odniesieniu do Grupy Zadań i skła­
dają raporty Kierownikowi Projektu za pomocą
Raportów z Punktów Kontrolnych. W projekcie
mogą uczestniczyć zarówno zespo ły wewnętrz­
ne, jak i zewnętrzne. Może być wobec tego
zasadne wykorzystanie zarówno formalnych,
jak i nieformalnych Grup Zadań różnych wiel-
kości, o wi ększych lub mniejszych tolerancjach
w za l eżności od potrzeb proj ektu.
10.3.3.2 Przeglądy postępów
W ramach Sterowania Etapem, Kierownik Projektu
dokonuje regularnie przeglądu postępów prac na
podstawie Raportów z Punktów Kontrolnych oraz
utrzymuje rejestry i dzienniki projektu. Kierownik
Projektu wykorzystuj e zawarte w nich informacje,
aby aktualizować Plan Etapu faktycznymi postę­
pami. Wymagana częstotliwość raportowania
z punktów kontrolnych może się zmieniać zgodnie
z potrzebami poszczególnych Grup Zadań.
Korzystne jest także przyjrzenie si ę trendom w celu
uzyskania oglądu całościowej „ kondycji" etapu.
Na przykład może się wydawać, że etap postępuje
dobrze w kategoriach produktów kończonych na
czas zgodnie z harmonogramem. Rejestr Zagadnień,
jednakże może wykazać rosnącą l iczbę zagadn i eń,
które nie są rozwiązywane i które mogą stanowi ć
powód do niepokoju. Podobnie duża liczba nieza-
łatwionych pozycji w Rejestrze Jakości, dotyczących
jakiegoś produktu, może wskazywać na zagadnie-
nia, które odnoszą si ę do projektu konstrukcyjnego
tego produktu.
Następujące produkty zarządcze pomagają Kierow-
nikowi Projektu w przeglądach postępów:
• Dziennik Projektu Jest to użyteczne narzędzie
do odnotowywania działań. Działania w projekcie
mogą wynikać z wielu źródeł, takich jak punk-
ty kontrolne, przeglądy jakości, oceny końców
etapów oraz doraźne rozmowy. Istnieje niebez-
pieczeństwo, że działania mogą się „zagubić",
jeżeli zostały odnotowane tylko w protokołach
czy raportach postępów. Proste dzia łania można
odnotować po prostu w Dzienniku Projektu
i odhaczyć po ich wykonaniu. Dzi a łania wymaga-
jące znacznych wysiłków mogą wymagać dołącze­
nia ich do istniejącego Planu Etapu. Jeżeli takie
działania nie mogą zostać włączone do planu
w granicach tolerancji, wtedy powinno zostać
114 I Postępy
zgloszone zagadnienie, aby przeanalizować ich
wplyw na etap i projekt. Dziennik Projektu można
także wykorzystywać do rejestrowania zagadnień
nieformalnych oraz wszelkich innych notatek
czy obserwacji, które nie są zapisywane w żad­
nych innych rejestrach czy dziennikach. Dziennik
Projektu jest pożytecznym sposobem rejestrowa-
nia pojedynczych obserwacji, które same w sobie
mogą wydawać się nieznaczące, ale w masie
mogą zwrócić uwagę Kierownika Projektu na
nowe zagadnienie lub ryzyko.
• Rejestr Zagadnień Zawiera on szczególy
wszystkich formalnych zagadnień zgloszonych
w czasie projektu, które mogą przybierać postać
wniosków o wprowadzenie zmiany, odstępstw
lub problemów/obaw. Przegląd Rejestru
Zagadn ień może doprowad z i ć do odkrycia
zagadn i eń dotyczących realizacji, na przyklad
nagiego wzrostu liczby wniosków o wprowa-
dzenie zmiany albo rosnącej liczby niewykona-
nych dzia lań korygujących.
• Zestawienie Statusu Produktów Dostarcza
ono informacji w ujęciu migawkowym o statu-
sach produktów projektu, etapu zarządczego
lub związanych z konkretnym obszarem pro-
jektu. Może ujawnić zagadnienia związane
z postępami, ponieważ pokazuje planowane
i faktyczne daty kluczowych punktów związa ­
nych z wytwarzaniem, przeg l ądam i i zatwierdza-
niem produktów, obj ętych planem. Zestawienie
Statusu Produktów opracowuje się na podstawie
Zapisów Obiektów Konfiguracji.
• Rejestr Jakości Jest to zapis wszystkich plano-
wanych i przeprowadzonych dzialań związa­
nych z jakością. Rejestr Jakości może ujawnić
zagadnienia związane z postępami, ponieważ
Kierownik Projektu może ocenić, czy są jakieś
zaległe działania dotyczące jakości lub czy wyniki
dotyczące jakości nie wskazują na jak i eś istotne
trendy, na przykład rosnąca liczba produktów,
które nie przeszly przeg l ądu jakości lub wzrost
średn iej liczby dzialań związanych z przeg l ądami
jakości.
• Rejestr Ryzyk Jest to zapis wszystkich zidenty-
fikowanych ryzyk. Kierownik Projektu powinien
przeglądać Rejestr Ryzyk w ramach przeglądu
stanu etapu. Ponieważ ryzyka związane są z nie-
pewnością, liczba ryzyk powinna ogólnie z.m niej-
szać się w miarę postępów projektu i wzrostu
poziomu pewności odnośnie wyników projektu.
Rejestr Ryzyk powinien być przeglądany w celu
ustalenia, czy skumulowane ryzyka mogą m i eć
wplyw na postępy w pozostalej części etapu
i projektu, np. może wystąpić duża liczba ryzyk,
które mogą zmaterializować się w podobnym
czasie, wskazując na okres, w którym postępy
mogą być zaklócone.
Techniki oceny postępów
Pomiary postępów etapu za rządczego pol egają
na ocenie dotychczasowych postępów w stosun-
ku do planów, oraz na spojrzeniu w przyszlość,
aby ustalić co jeszcze trzeba wykonać, w jakim
terminie i z jakimi zasobami. Istnieje wiele
dostępnych technik pomiaru postępów, łącznie
z następującymi :
• Diagram kamieni milowych Jest to graficz-
ne przedstawienie kluczowych planowanych
i faktycznie osiągniętych kamieni milowych
etapu.
• Krzywa S Jest to wykres pokazujący skumu-
lowane faktyczne wartości liczbowe (na przy-
kład kosztów czy pracochłonności) w funkcji
czasu. Krzywa ta ma zwykle kształt litery „S",
który odzwierciedla fakt, że projekt typowo
zużywa mniej zasobów i ma mniejsze kosz-
ty na początku i końcu projektu, a więcej
w środku. Im bardziej stroma jest ta krzy-
wa, tym więcej zasobów jest potrzebnych
w danym momencie. Kiedy liczby planowa-
ne i faktyczne pokazane są na tym samym
wykresie, może być on wykorzystany do okre-
ślenia potencjalnych nadmiernych wydatków
lub prognozowanych obszarów, gdzie mogą
zostać przekroczone tolerancje.
• Metoda wartości wypracowanej Jest to
metoda pomiaru wyników odnoszących się
do wykonanego zakresu, harmonogramu
i kosztów w porównaniu do planów, poprzez
porównanie faktycznych terminów i kosz-
tów ukończenia produktów z ich szacowa-
nym harmonogramem i kosztem. Podejście
metodyki PRINCE2 do planowania oparte na
produktach dostarcza warunków wstępnych
koniecznych dla zarządzania z wykorzysta -
niem wartości wypracowanej.
10.3.3.3 Rejestrow anie i raportowani e
doświadczeń
Następujące produkty zarządcze wykorzystywane
są do rejestrowania i raportowania doświadczeń
w trakcie przeglądów postępów:

• Dziennik Dośw i adczeń Jedną z zasad projek-
tu zgodnego z metodyką PRINCE2 jest zasa-
da korzystania z doświadczeń, oznacza to, że
przez cały czas trwania projektu poszukuje się
doświadczeń, rejestruje je i wykorzystuje. Często
doświ adczenia są identyfikowane w czasie prze-
glądów postępów. Doświadczen ia mogą obej-
mować informacje na temat procesów zarząd­
czych i specjalistycznych, produktów, technik czy
procedur, które albo wnoszą wkład do osiągnięć
projektu, albo spowodowały problem, przykła­
dowo: wyniki zespołu zarząd zania projektem,
powodzenie w dostosowaniu metodyki PRINCE2
do projektu albo analiza danych i pomiarów
dotyczących jakości .
• Raport Doświadczeń Chociaż można określić
i zarejestrować doświadczenia w czasie projek-
tu, uczenie się z doświ adczeń łączy się z pod-
jęciem działań w celu wdrożenia u lepszeń.
Działania te mogą mieć zastosowanie w bieżą­
cym projekcie, w którym to przypadku powin-
ny zostać włączone do odpowiednich planów
i Grup Zadań lub mogą być istotne dla innych
projektów. Jeżel i doświadczen i e jest wa żn e
i istotne dla przyszłych projektów, powinno
zostać włączone do Raportu Doświadczeń.
Ważne jest, by zauważyć, że działania wynika-
jące z doświadczeń mogą zostać wprowadzone
w życi e w każdym odpowiednim momencie.
Dlatego Raport Doświ adczeń możn a sporządzi ć
w każdym momencie w trakcie projektu. Jako
minimum jednakże Raport Doświadczeń powi-
nien zostać sporządzony w procesie Zamykanie
Projektu.
10.3.3.4 Raportowanie postępów
Częstotliwość raportowania powinna odzwiercie-
dlać wymagany stopień kontroli, a ten prawdopo-
dobnie będzie zmieniać się w czasie projektu. Na
przykład:
• W t rakcie etapu projektowania konstrukcji,
mogą być wymagane rzadsze kontrole n iż
w późniejszych etapach zarządczych .
• Jeżeli zespół ma duże doświadczenie, wtedy
bardziej odpowiednie może być rzadsze rapor-
towanie, podczas gdy dla niedoświadczonego
zespołu Kierownik Projektu może chcieć zwię k­
szyć częstotliwość raportowania, dopóki nie
uzyska wystarczającej pewności co do możliwo­
ści zespołu.
Postępy I 115
Następujące produkty zarządcze wykorzystywane są
do raportowan ia postępów:
• Raport z Punktu Kontrolnego Kierownik
Zespołu opracowuje go, aby dostarczyć
Kierownikowi Projektu szczeg ółów na
temat postępów dotyczących Grupy Zada ń .
Częstotliwość sporządzan ia wymaganych
Raportów z Punktu Kontrolnego jest określona
w Grupie Zadań. Kierownik Projektu zestawia
Raporty z Punktów Kontrolnych i wykorzystuje
je j ako część oceny postępów podczas przeglą­
du stanu etapu.
• Raport Okresowy Kierownik Projektu opra-
cowuje ten raport dotyczący postępów etapu
zarządczego dla Komitetu Sterującego. Komit et
Sterujący określa częstotliwość wymaganych
Raportów Okresowych albo dla całego projektu,
albo etap po etapie, i dokumentuje to w Strategii
Zarządzania Komunikacją. Raport Okresowy
pozwala członkom Komitetu Sterującego na
zarządzanie z wykorzystaniem tolerancji pomię­
dzy ocenami końców etapów, ponieważ znają oni
tolerancj e uzgodnione z Kierownikiem Projektu
w Planie Etapu. Raport Okresowy powinien
potwierdzać, że czynione są postępy w granicach
tych tolerancji i dostarczyć sygnałów wczesne-
go ostrzegania o możliwych problemach, które
wymagać mogą dalszych działań. W ramach
Strategii Za rządzania Komunikacją, Komitet
Sterujący może wymagać, aby kopie Raportów
Okresowych przesyłane byly innym zainteresowa-
nym stronom poza projektem. Komitet Sterujący
może także przekazać Raport Okresowy (albo
jego streszczenie) kierownictwu organizacji łub
programu.
• Raport Końcowy Etapu Jest on opracowywany
przez Kierownika Projektu pod koniec każde­
go etapu zarządczego, dostarczając Komitetowi
Sterującemu informacji na temat postępów
uzyskanych do określonego dnia, całościowej
sytuacji projektu i (w połączen iu z następnym
Planem Etapu) przekazuj ąc wystarczające infor-
macje, pozwalające zwróci ć się do Komitetu
Sterującego o decyzję dotyczącą tego, jak dalej
postępować z projektem.
• Raport Końcowy Projektu Jest on opracowy-
wany przez Kierownika Projektu pod koniec
projektu w procesie Zamykanie Projektu i wyko-
rzystywany jest przez Komitet Sterujący do
oceny projektu i wydania zezwolenia na jego
zamknięcie.
116 I Postępy

10.3.4 Zgłaszanie sytuacji nadzwyczajnych 10.4 O BOWIĄZ KI

Wynikiem przeglądu postępów jest decyzja, czy Tabela 10.2 przedstawia obowiązki dotyczące tema-
Grupa Zadań, Plan Etapu lub Plan Projektu pozostają tu Postępy. Więcej szczegółów na temat ról zespołu
lub prognozowane jest ich pozostanie w granicach zarządzania projektem i powiązanych z nimi obo-
uzgodnionych tolerancji: wiązków przedstawiono w Dodatku C.
• Sytuacj e nadzwyczajne na poziomie Grupy
Zadań Po uzgodnieniu tolerancji dla Grupy
Zadań z Kierownikiem Zespołu, Kierownik
Projektu powinien być informowany o postę­
pach regularnymi Raportami z Punktów
Kontrolnych. Jeże l i prognozowane jest prze-
kroczenie tolerancji Grupy Zadań, Kierownik
Zespołu powinien poinformować Kierownika
Projektu zgłaszając zagadnienie. Kierownik
Projektu, poinformuje wtedy o wszelkich nie-
zbędnych działaniach korygujących.
• Sytuacje nadzwyczajne na poziomie etapu
J eżel i prognozowane jest przekroczenie tole -
rancji etapu, Kierownik Projektu powinien
opracować Raport o Zagadnieniu, aby zareje-
strować i przeanalizować szczegóły odchylenia
i dostarczyć następn i e Raport Nadzwyczajny
Komitetowi Sterującemu. W oparciu o informa-
cje zawarte w tym raporcie, Komitet Sterujący
może polecić Kierownikowi Projektu opracowa-
nie Planu Nadzwyczajnego w celu zastąpienia
planu, w którym prognozowano przekroczenie
tolerancji. Komitet Sterujący może także usunąć
przyczynę, zaa kceptować i skorygować toleran-
cje albo poprosić o więcej czasu na rozważenie
lub odrzucenie rekomendacji przedstawionej
w Raporci e o Zagadnieniu. Jeżeli polecono
opracowanie Planu Nadzwyczajnego, Komitet
Sterujący przeprowadza ocenę nadzwyczajną,
podobną do oceny końcowej etapu w celu prze-
g l ądu i zatwierdzenia Planu Nadzwyczajnego.
• Sytuacje nadzwyczajne na poziomie projektu
Jeżeli prognozowane jest przekroczenie tolerancji
projektu, Komitet Sterujący nie posiada upraw-
nień do zarządzania proj ektem w t akiej sytuacji
i musi przekazać sprawę kierownictwu organizacji
lub programu w celu podjęcia decyzji. Komitet
Sterujący może zażądać, aby Kierownik Projektu
opracował Plan Nadzwyczajny dla projektu.

Więcejinformacji na temat procedur sterowania

zagadnieniami i zmianami znajduje si ę w Rozdziale 9.
 Postępy I 117

Tabela 10.2 Obowiązki dotyczące tematu Postępy

Ro la Obowiązki

Kierownictwo organizacji lub programu Wyznacza tolerancje dla projektu i dokumentuje je w zleceniu przygotowania
projektu.
Podejmuje decyzje dotyczące Planów Nadzwyczajnych, gdy prognozowane jest
przekroczenie tolerancji na poziomie projektu .

Przewodn i czący Wyznacza tolerancje dla etapu.

Gwarantuje. że postępy zmierzające do wyniku końcowego są nadal spójne
z perspektywy biznesowej.
Podejmuje decyzje dotyczące Planów Nadzwyczajnych, gdy prognozowane jest
przekroczenie tolerancji na poziomie etapu.
Rekomenduje przyszle dzialania odnoszące się do projektu kierownictwu
organizacji lub programu, jeżeli prognozowane jest przekroczenie tolerancji na
poziomie projektu.
G łówny Użytkownik Gwarantuje. że postępy zmierzające do wyniku końcowego pozostają spójne
z perspektywy użytkownika .
Główny Dostawca Gwarantuje. że postępy zmierzające do wyniku końcowego pozostają spójne
z perspektywy dostawcy.
Kierownik Projektu Wydaje zezwolenia na wykonanie Grup Zadań.

Monitoruje postępy względem Planów Etapu.

Opracowuje Raporty Okresowe, Raporty Końcowe Etapu, Raporty o Zagadnieniach.
Raporty Doświadczeń i Raport Końcowy Projektu.
Opracowuje Raporty Nadzwyczajne dla Komitetu Sterującego, gdy prognozowane
jest przekroczenie tolerancji na poziomie etapu.
Utrzymuje rejestry i dzienniki w projekcie.
Kierownik Zespołu Uzgadnia Grupy Zadań z Kierownikiem Projektu.
Informuje Wsparcie Projektu o ukończonych dzialaniach dotyczących jakości.

Opracowuje Raporty z Punktów Kontrolnych.

Zawiadamia Kierownika Projektu o jakichkolwiek prognozowanych odchyleniach
poza tolerancje Grupy Zadań.
Nadzór Proj ektu Weryfikuje Uzasadnienie Biznesowe pod kątem wydarzeń zewnętrznych
i postępów projektu.
Weryfikuje zmiany w Planie Projektu, aby stwierdzić, czy mają one jakiś wplyw
na potrzeby biznesu lub Uzasadnienie Biznesowe.
Potwierdza postępy etapu i projektu w odniesieniu do uzgodnionych tolerancji.

Wsparcie Projektu Pomaga w sporządzaniu raportów.

Wnosi wiedzę o narzędziach specjalistycznych (na przykład o narzędziach
planowania i kontroli).
Numeruje, rejestruje, przechowuje i dystrybuuje Raporty o Zagadnieniach oraz
Raporty Nadzwyczajne.
Pomaga Kierownikowi Projektu w utrzymywaniu Rejestru Zagadnień i Rejestru
Ryzyk.
Utrzymuje Rejestr Jakości na rzecz Kierownika Projektu.
11 Wprowadzenie do procesów

11.1 PROCESY PRINCE2 procesem Zarządzanie Strategiczne Projektem (patrz

PRINCE2 to podejście do zarządzania projektami
oparte na procesach. Proces to ustrukturyzowany
zbiór działań zaproj ektowany w celu osiągnięcia
konkretnego celu. Proces wykorzystuje j eden lub
większą l iczbę określonych elementów wejściowych
i przekształca je w określone elementy wyjściowe.
PRINCE2 wyróżnia siedem procesów, które dostar-
czają zbioru działań wymaganych w celu pomyślne­
go zarządzania strategicznego, zarządzania opera-
cyjnego i dostarczenia produktów projektu.
Rysunek 11 .1 przedstawia sposób wykorzystania
procesów w całym cyklu życia projektu.
11.2 OGÓLNY PRZEGLĄD PROCESÓW
PRINCE2
Komitet Sterujący wyznacza kierunki działania
i podejmuje kluczowe decyzje przez cały czas życia
projektu. Działan i a Komitetu Sterującego są objęte
Rozdział 13), który trwa od działań przedprojekto-
wych do etapu końcowego włącznie.
11.2. 1 Przed projektem
Na początku ktoś ma pomysł lub potrzebę. Może
to wynikać z nowych celów biznesowych, reakcj i
na presję ze strony konkurencji, zmian w ustawo-
dawstwie łub zalecenia zawartego w raporcie albo
wynikach audytu. Uruchomienie projektu może
być spowodowane przez niemal dowolny sygnał.
W metodyce PRINCE2 ten sygnał uruch am iający jest
nazywany „zleceniem przygotowania projektu".
Zlecenie przygotowania projektu j est dostarczane
przez organizację zamierzającą uruchomić projekt
(kierownictwo organizacji łub programu) i może
mieć różną formę, począwszy od ustnego polecenia,
a skończywszy na dokładnie określonej i uzasadnio-
nej definicji projektu.
Przed podjęciem działania polegaj ącego na ustale-
niu pe łnego zakresu projektu na l eży zweryfikować,

Przed )
projektem
Etap
inicjowania
) Kolejny(-e)
etap(-y) realizacyjny(-e) ) Ostatni etap " "
realizacyjny /

Zarządzanie Strategiczne Projektem

Zarządzanie
strateg iczne pp

Zarządzanie
KE
~ ~
operacyine
I IP
I Sterowanie Etapem Sterowanie Etapem

Zarządzanie Zarządzanie
Dostarczanie
Dostarczaniem Produktów Dostarczaniem Produktów
produktów

Legenda
PP = Przygotowanie Projektu
IP = Inicjowanie Projektu
KE = Zarządzanie Końcem Etapu
ZP = Zamykanie Projektu
Uwagi
• Proces Przygotowanie Projektu jest wykorzystywany przez poziomy zarządzania strategicz·
nego i zarządzania operacyjnego.
• Powinny by( przynajmniej dwa etapy zarządcze, pierwszy
z nich to etap inicjowania.
• Proces Zarządzanie Końcem Etapu jest wykorzystywany pierwszy raz na końcu etapu
inicjowania i powtarzany na końcu każdego kolejnego etapu za wyjątkiem ostatniego
etapu. Jest także wykorzystywany do sporządzenia Planu Nadzwyczajnego, który może by(
sporządzony w dowolnym momencie, łącznie z ostatnim etapem.
• Ola złożonych lub dlugich etapów inicjowania, procesy Sterowanie Etapem i Zarządzanie
Dostarczaniem Produktów mogą by( użyte opcjonalnie do zarządzania etapem inicjowania.

Rysunek 11.1 Procesy PRINCE2

122 I Wprowadzenie do procesów
czy projekt jest zasadny i czy jest WYkonalny. Dzia-
lania t e są objęte procesem Przygotowanie Projektu
(patrz Rozdzial 12), którego punktem kulminacyj-
nym jest przygotowanie Zalożeń Projektu i Planu
Etapu d la inicjowania projektu.
Komitet Steruj ący dokonuje przeg l ądu Za łożeń
Projektu i decyduje, czy n ależy zain icjować projekt
oraz określa poziom uprawnień, jakie maj ą być
nadane Kierownikowi Projektu dla etapu inicjowa-
nia projektu.
11 .2.2 Et ap inicj owania proj ektu
Po podjęciu decyzji o rozpoczęciu projektu, należy
go szczegółowo zaplanować. Należy uzyskać finan-
sowanie i określić mechanizmy sterowania w celu
zapewnienia rea lizacji projektu zgodnie z ocze-
kiwaniami osób finansujących projekt oraz osób,
które będą korzystać z tego, co projekt dostarczy.
Szczegółowe planowanie, ustalenie strategii zarzą­
dzania projektem i mechanizmów sterowania,
opracowanie solidnego Uzasadnienia Biznesowe-
go ora z sposobu dokonywania przeglądu korzyści
są o bjęte procesem Inicjowanie Projektu (patrz
Rozd zia ł 14). Ponadto podczas etapu inicjowania
projektu wykorzystywany jest proces Zarządzanie
Końcem Etapu (Rozdział 17) w celu szczegó łowego
zaplanowania następnego etapu.
Etap inicjowania projektu kończy się sporządzen i em
Dokumentacji Inicjowania Projektu, którą Komitet
Steruj ący poddaje przeglądowi w celu podjęcia
decyzji, czy zezwolić na realizację projektu. Z uwagi
na fakt, że treść Dokumentacji Inicjowania Projektu
prawdopodobnie będzie się zmieniać w trakcie reali-
zacji projektu (zgodnie z zasadami sterowania zmia-
nami), ta pierwotna wersja Dokumentacji Inicjowa-
nia Projektu zostaje zachowana i WYkorzystywana
w późniejszych przeg l ądach WYkonania projektu.
11 .2.3 Kolejne etapy realizacyj ne
Kom itet Sterujący powierza Kierownikowi Projektu
etap po etapie bieżące sterowanie poszczególnymi
etapami. Kierownik Projektu musi przydziel ić prace
do WYkonania i zapewnić, aby WYniki tych prac
(produkty) były zgodne z odpowiednimi specyfika-
cjami oraz uzyskać odpowiednie zatwierdzenia tam,
gdzie jest to właściwe. Kierownik Projektu powinien
również zapewnić, aby postępy prac były zgodne
z zatwierdzonym planem, a prognozy dotyczące
doceloWYch wskaźników WYkonania projektu mieściły
się w uzgodnionych tolerancjach. Kierownik Projektu
w celu umożliwien i a kontroli postępów zapewnia,
aby prowadzone były zapisy dotyczące projektu
(Dziennik Projektu, Dziennik Doświadczeń, Rejestr
Zagadnień, Rejestr Ryzyk, Rejestr Jakości i Zapisy
Obiektów Konfiguracji). Kierownik Projektu infor-
muje Komitet Sterujący o osi ąganych postępach za
pomocą regu larnych Raportów OkresoWYch. Działania
związane ze sterowaniem każdym etapem są objęte
procesem Sterowanie Etapem (pat rz Rozdział 15).
W procesie Zarządzanie Dostarczaniem Produktów
(patrz Rozdział 16), Kierownik(-cy) Zespołu(-ów)
lub członkowie zespołu WYkonują przydzielone im
Grupy Zadań (które dostarczą jeden lub więcej pro-
duktów) i informują Kierownika Projektu na bieżąco
o postępach za pomocą Raportów z Punktu
Kontrolnego.
Pod koniec każdego etapu zarządczego Kierownik
Projektu występuje z wnioskiem o zezwolenie na
przejście do następnego etapu, składając raport
z wyników etapu, dostarczając aktualizację Uzasad-
nienia Biznesowego i pl anując szczegółowo następ­
ny etap zarządczy. Kierownik Projektu dostarcza
informacji WYmaganych przez Komitet Sterujący
w celu oceny dalszej zasadności projektu i podjęcia
decyzji o zezwoleniu na realizację następnego etapu
zarządczego. Działania realizowane pod koniec każ­
dego etapu są objęte procesem Zarządzanie Koń­
cem Etapu (patrz Rozdział 17).
11.2.4 Ostatn i etap realizacyjny
Projekt jest przedsięwzięciem o ograniczonym cza-
sie trwania, dlatego podczas ostatniego etapu (po
uzyskaniu przez Kierownika Projektu zatwierdzeń
wszystkich produktów projektu) zachodzi koniecz-
ność zakończenia projektu. Komitet Sterujący
powinien być przekonany, że odbiorcy produktów
projektu mogą je przejąć i użytkować. W takim
przypadku produkty mogą być przekazane do ope-
racyjnego WYkorzystania w działalności biznesowej
organizacji i proj ekt można zamknąć. Dokumen-
tacja projektu powinna zostać uporządkowana
i przekazana do archiwum, projekt na l eży ocenić
pod kątem osiągnięć w porównaniu z pierwotnym
planem, a zasoby przydzielone do projektu należy
uwolnić. Działania związane z zamykaniem projektu
obejmują planowanie poprojektOWYCh przeglądów
korzyści, jakie należy przeprowadzić w odniesieniu
do tych korzyści, które można ocenić dopiero po
jakimś okresie użytkowania produktów (a więc po
zamknięciu projektu). Działania związane z zamyka-
niem projektu są objęte procesem Zamykanie Pro-
jekt u (patrz Rozdział 18).
 Wprowadzenie do procesów I 123

.!l!. E
u ..."'Ol
"'c e
.!:!
Zftcente
p1-zygotow;w1ia
p1o{tktu
Wyty<.tnt
org:al'llr.c1I
I de<yJjt
"' a.
e' .D
o .a
P'o>V>~fttł
ounctow...,.,
PfO~tu
. . . . . . „.,
Ott•f.tę
PIOl•ltu ....,..,...,.
l(C)ł'l'O

)lłf'14otclf90
t„\i
'°'"-N')
o um)'km.u
ptotfltu

·-cGI GI
cN
"'
N ·-
"O Ol
u

IO' GI
Zarządzanie Strategiczne Projektem
N
"' ..."'
+'
...N~
.'
l•l~fflo·
Nłlf ł l<ICW
.,„""'
Z•rwolt ni.t
N lł•l\l(JOWł l'I~
l""'V'ł<t'n•it

'P<ln•dtt:n1:J
Pl•nu
„••
z„1.....,d1ony

łładtwtU•Jny
W'f<YUM
lli: OIYll\ł1 U
Sttfuj~•go
Pr1H>\ueme
1•m\l'l"f<••
ptOJt ktu .Jłłd l'<'IJU•Jn~
"
~
....::>
QI
„....„,
w •••
o 1al\vlt1ditnlt
.N Mftwyałj RtO
:;J
·~

Q.
...
o I Wn+~k
O 1'.t1f\Kte>Wfn "
Wl'Hcwtk
O U l\-..OltAlt f\I
Wnlo\c-1.
o 1.ttmie-1dltl'llł
l't\:omtnd~• i
1•m1tnif(.ia
\ P1"01tl lu Nłitaqt PfOJł\t u Pl.Anu (t•pu p ro;tklu
QI
·-
c
ro
s:o
....o Inicjowanie Zarządzanie Zamykanie
.!!! GI
c .s..
~~
O\
>.
...
N • Projektu Końcem Etapu
Zglcnzon.t
Projektu
„.."'.
"O
N GI
Q.

T
\ytUł(;J.l
nilod1\vyttajna
T
... a.
o
N"' Zbltta)ł<'Y
~!f l Ol'll« Wl)U
I P1ołlMI
o wytyu~
Zbłlt•;•cy
i •t koni«
PIO,tlt.tu

I T

............... Sterowanie Etapem

...
Zf'l\YOle-i1!e
I n a wylon.anlt
G1upy Z.cł•1'

.....„ ......
~\ Oń(ron41

QI
·;:: ;: T
... '0
t:l .!<
... ::>
~"8
o ....
Zarządzanie Dostarczaniem Produktów
o a.

Uwagi:
Uwaga 1: na końcu etapu inicjowania proces Inicjowanie Projektu jest utywany do przekazania Komitetowi Sterującemu
wniosku o zezwolenie na realizację projektu (wraz z przedstawieniem Dok umentacj i Inicjow ania Projektu) oraz równolegle
proces Zarządzanie Końcem Etapu używany jest do przekazania Komitetowi Sterującemu wniosku o zatwierdzenie Plan Etapu
dla drugiego etapu zarządczego.
Uwaga 2: d zialania związane z zamykaniem projektu są planowane i zatwierdzane w ramach zatwierdzania ostatniego Etapu,
dlatego proces Zamykanie Projektu jest realizowany w trakcie ostatniego etapu.

Rysunek 11.2 M odel procesowy PRINCE2

124 I Wprowadzenie do procesów

Każdy zawiera
Procesy

Działa n ia
Każde zawiera

'

Rekomendowane L

czynności

Rysunek 11.3 Relacje pomiędzy procesami, działaniami i czynnościami

11 .3 M ODEL PROCESOWY PRINCE2 11.4.2 Cel

Model procesowy PRINCE2 zestal przedstawiony na Ta sekcja zawiera opis konkretnych celów, j akie pro-
Rysunku 11.2. ces ma osi ągnąć.

Procesy są dostosowane do poziomów zarządzania 11.4.3 Kontekst

organizacją lub programem, zarządzania strategicz-
Ta sekcja umieszcza każdy proces w kontekście
nego, zarządzania operacyjnego i rea lizacji projektu.
innych procesów i dzialań realizowanych w ramach
Przedstawiono sygnaly występujące pomiędzy
projektu lub z polecenia kierownictwa organizacji
poszczególnymi procesami, uruchamiające kolejne
lub programu.
procesy.

11.4.4 Działania
11.4 STRUKTURA ROZDZIAŁÓW Procesy PRINCE2 obejmują zbiór działań, które
DOTYCZĄCYCH PROCESÓW mogą być rea lizowane kolejno lub równo legle.

Każdyproces w ra mach PRINCE2 opisano, stosując
następuj ącą strukturę i format.
11 .4 . 1 Przeznaczenie
Ta sekcja zawiera opis uzasadnienia procesu.
Dzialania PRINCE 2 zawi erają zbiór rekomendow a-
nych czynności zaprojektowanych w celu os i ągnię­
cia konkretnego wyniku.
Relacje pomiędzy procesami, dzialaniami i czynno-
ściami przedstawiono na Rysunku 11.3.

Tabela 11 .1 Przykładowa ta bela o bowiązków

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezalezny od wytwórcy
Zatwierdzaj ący- potwierdza odbiór
>.
c:
Q.
E .>of. Cli-
....
"'oOl
~
.,,.
c:
o
~ "'
u
~
....
::i
.>of.

·-....o
Cli
-
o
::i

....::i
....::i
.>of.
t:
o
'tJ

·-....o ·-....o
.... Q.
Cli
a..
'ii> N
.>of.

>. "'o
t:
VI
Cli
.>of.
Cli ....::i
·-
u
u
·-
c:
·N
::::> o
a..
.>of.
N
.>of.
·-c: a..
a..
.>of.
::i
'tJ
"'
N
·-
c:
'tJ
o >.
c:
>.
c:
c:
~ ~
....
-o
Cli
·-
u
....
o
....
a..
~ o o....
"'....Ol ~ ~ .... N
"' ·-"'Q.
Pro dukt Czynność o a..
Cli
....
N
- -
•O
\!)
•O
\!) ~
Cli
~
Cli
"O
z"' ~
Q.

o
Plan Etapu Wytworzyć (Z) (Z) (Z) w K A16
 Wprowadzenie do procesów I 125

Dla każdego działania przedstawiono schemat
pokazujący elementy wejściowe i wyjściowe, lącznie
z tymi produktami, które są tworzon e lub aktualizo-
wane przez to dzialanie. Opisano rekomendowane
czynności, które należy podjąć, aby osiągnąć cele
danego działania.
Każde działanie jest podsumowane w formie
tabeli pokazującej obowiązki związane z każdym
produktem wytworzonym lub zaktualizowanym
w trakcie tego dzialania, w sposób przedstawiony
wTabeli 11.1.
Należy pamiętać, że produkty zarządcze wytworzo-
ne w trakcie jednego procesu mogą być zatwier-
dzane w ramach innego procesu (np. Plan Etapu
jest tworzony w procesie Zarządzanie Końcem
Etapu, ale jest zatwierdzany w procesie Zarządza­
nie Strategiczne Projektem). Dlatego przedsta-
wiono kompletny zbiór obowiązków, z tym, że
obowiązki objęte innym procesem zostaly podane
w nawiasie, np. (Z).

Tabela 11.2 Symbole użyte na diagramach

Symbol Legenda

To jest proces PRINCE2.

Przygotowanie
Projektu

To j est dzialanie. Każdy proces zawiera kilka dzialań.

Zezwalanie
na inicjowanie

To jest zdarzenie lub decyzja, która uruchamia inny proces lub sluży
do powiadomienia kierownictwa organizacji lub programu. Strzałka
/ Po Iecenre
. sporzą d zenra
. "
wskazuje proces uruchamiany przez to zdarzen ie.
Planu Nadzwyczajnego
'-.. ,,j
Podwójny symbol zdarzenie wskazuje, gdzie mogą być alternatywne
sygnały z jednego do drugiego procesu (np. wniosek o zatwierdzenie
Planu Etapu lub wniosek o zatwierdzenie Planu Nadzwyczajnego).
Symbole narysowane przerywaną linią są sygnałami wewnętrznymi
dla procesu (np. działanie korygujące oznacza sygnał plynący z jednej
czynności w procesie Sterowanie Etapem do innej).

To są produkty zarządcze, które są wykonywane lub uaktualniane

Uzasadnienie Biznesowe w działaniach procesu.
Produkty zaznaczone ciągłą linią są produktami zarządczymi, dla
których zarysy Opisu Produktu przedstawiono w Dodatku A.

r -- -----· I Produkty zaznaczone przerywaną linią są elementami wchodzącymi

Zalecenia dzi alań w sklad jakiegoś produktu zarządczego lub są produktami
I
n astępczych I zarządczymi, co do których PRINCE2 nie wymaga konkretnej
I
I
... -- - - ,,, _.. zawartości lub kryteriów jakości.
12 Przygotowanie Projektu

12.1 PRZEZNACZENIE 12.2 CEL

Przygotowanie Projektu sluży do zapewnienia, że
zosta n ą spelnione warunki dla Inicjowania Projektu,
poprzez udzielenie odpowiedzi na pytanie: „czy
mamy za sadny i w art rea lizacji projekt?".
Nie na l eży podej mować żad nych dziala ń rea lizacyj-
nych dopóki nie zostaną określone pewne podsta-
wowe informacje konieczne do podjęcia racjonal-
nych decyzji w sprawie rozważanego projektu, nie
zostaną obsadzone kluczowe role i przydzielone im
obowiązk i oraz nie będzie dostępna podstawa do
szczególowego p lanow ania.
Przeznaczeniem procesu Przygotowanie Projektu
jest zarówno zapobieganie inicjowaniu nieprze-
myślanych projektów, jak i zezwalanie na inicjo-
wanie projektów zasadnych. Proces Przygotowanie
Proj ektu sam w sobie jest mniej skomplikowany
w porównaniu do bardziej szczególowego i wnikli-
wego procesu Inicj ow anie Projektu. Zamierzeniem
tego procesu jest wykonanie minimum prac nie-
zbędnych do podjęcia decyzji, czy projekt w ogóle
warto i n icjować.
r----------
, I
Zlecenie
I p rzygotow.tn1a ) . ..
l'lroi'tktu
Celem procesu Przygotowanie Projektu jest zapew-
nienie, że:
• istnieje uzasa dnienie biznesowe dla zainicjo-
w ania projekt u (udokumentowane w zarysi e
Uzasadnienia Biznesowego);
• powołano wszystkie organy niezbędne do zaini-
cjowania projektu;
• są dostępne wystarczające informacje potrzebne
do określenia i potwierdzenia zakresu projektu
(w formie Za lożeń Projektu);
• oceniono różne sposoby, jakimi można projekt
zrealizować, i wybrano formulę realizacji projektu;
• wyznaczone zostały osoby, które podejmą prace
potrzebne podczas inicjowania projektu i/lub
które obejmą ważne role za rządcze w projekcie;
• prace potrzebne do inicjowania projektu zostały
zaplanowane (udokumentowane w Planie Etapu);
• nie straci się czasu na inicj owanie proj ekt u
opartego na b łędnych założeniach d otyczących
zakresu projekt u, t erminów, kryteriów akceptacji
i ograniczeń.
- ,
Kierownictwo
I
o rgan1zacJ 1 I
lu b programu I
I Zarządzanie

I Strategiczne
Projektem
I
r - -- - - - - - - ---- --- - + --- - - - - -,
I Mianowanie
I I
Pl•IY<Od•kzł<t90 I
' I Kltrownika Pro;ektu I
I
I I
- - - - I- - -- -- - - - - - - - - - - - - "
I
I Zgromadzenie PtoJcktowanie I
dotychczasowy<.h I n'lnnowanie zespołu
I do,wiadczeń Złt l4'd zańi 3 projektem I
I I
I
1 I
Pnygotow•nir lilt)'SU Wybieranie formuly
I Vt• il<Mit-nia r tłhZił<:J• r><o;t:ktu I
I ttstawiin.ie ZMoień
I B•lMsowego
Projektu I
I 1 I
I I WntostK
Planowanie o :Cdinlcfowanie
I ctltpu inicjowania ' orolektu I
I Przyg otowanie Pro j ekt u I
L--------------------------~

Rysunek 12.1 Diagram procesu Przygotow anie Projektu

130 I Przygotowanie Projektu
12.3 KONTEKST
Projekty można zdefin i ować na w iele sposobów,
a zatem informacje dostępne w momencie przy-
gotowywania projektu mogą być bardzo różne.
W PRINCE2 sygnal urucham i ający prace nad pro-
jektem j est nazywany zleceniem przygotowania
projektu. Jest ono dostarczane przez uprawniony
organ, który zdecydowal o potrzebie uruchomienia
proj ektu - zazwyczaj jest to kierownictwo organiza-
cji lub programu. Termin „zlecenie przygotowania
projektu" odnosi się do wszelkich informacji wyko-
rzystywanych do uruchomienia projektu, n i eza l eżnie
od tego, czy będzie to studium wykonalności, czy
otrzymane przez dostawcę „zaproszenie do sk łada­
nia ofert". Zlecenie przygotowania projektu powin-
no określać wymagania i ograniczenia dla projektu
oraz powinno zawierać wystarczaj ące informacje
do zidentyfikowania przynajmniej przyszłego Prze-
wodniczącego Komitetu Steruj ącego. Zlecenie jest
doprecyzowywane w celu opracowania Założeń
Projektu.
Komitet Sterujący powinien otrzymać inf ormacje
wystarczaj ące do podjęcia decyzji o zainicjowaniu
projektu. W tym celu opracowywane są Założenia
Projektu.
Praca związana z Przygotowaniem Projektu może
być istotnie różna dla poszczególnych projektów.
Jeżeli projekt jest częścią programu, to program
powinien dosta rczyć Założenia Projektu oraz wyzna-
czyć niektórych, j eżeli nie wszystkich, członków
Komitetu Sterującego, e l iminując tym samym znacz-
ną część prac wymaganych w tym procesie. W takich
przypadkach Kierownik Projektu powinien zwery-
fi kować to, co zosta ło dostarczone przez program
i w razie potrzeby zaproponować modyfikacje.
Przygotowanie zarysu Uzasadnienia Biznesowe-
go i zestawianie Założeń Projektu (są to dzi ałan i a
prowadzone równoleg le i mają charakter iteracyj-
ny) wymagają regu larnych i częstych kontaktów
oraz konsultacji pomiędzy Kierownikiem Proj ektu,
członkami Komitetu Steruj ącego i innymi interesa-
ri uszami. Im więcej czasu zostanie poświęconego na
wyraźne określen i e wymagań w procesie Przygo-
towanie Projektu, tym wi ęcej czasu zostanie zaosz-
czędzonego podczas realizacji proj ektu dzięk i moż­
l i wości uniknięcia zagadn i eń proj ekt owych, sytuacji
nadzwyczajnych i zmian planu.
Treść Założeń Projektu zostanie następnie rozsze-
rzona i doprecyzowana w Dokumentacj i Inicjowania
Proj ektu w procesie Inicjowanie Projektu.
12.4 DZIAŁANIA
Działania w procesie Przygotowanie Projektu będą
prawdopodobnie rozdzielone pomiędzy kierowni-
ctwo organizacji lub programu, Przewodniczącego
oraz Ki erownika Projektu. W ich ramach na l eży:
• m i anować Przewodniczącego i Kierownika
Projektu;
• zgromadzić dotychczasowe doświadczen i a;
• zaprojektować i mianować zespół zarzą d zania
projektem;
• przygotować zarys Uzasadnienia Biznesowego;
• wybrać formułę realizacj i projektu i zestawić
Za łożenia Projektu;
• zapl anować etap inicjowania.
12.4.1 Mianowanie Przewodniczącego
i Kierownika Projektu
Aby cokolw iek zrealizować w projekcie, potrzeba
decydenta posiadającego odpowiednie uprawnie-
nia, czyli Przewodniczącego Komitetu Steruj ącego,
który reprezentuje interesy interesariusza(-y) bizne-
sowego(-ych). Mianowanie Przewod niczącego j est
warunkiem wstępnym do zapewnienia, że projekt
ma uzasadnienie.
Mianowanie Kierownika Projektu pozwala na
zapewnienie b i eżącego zarządzania operacyjne-
go projektem w imieniu Przewod niczącego. Przy
mianowaniu Kierownika Projektu może za i stn i eć
potrzeba skonsultowania się Przewod niczącego
z kierownictwem organizacji lub programu i uzyska-
nia ich zgody.
Na rysunku 12.2 przedstawiono elementy wejści owe
i wyj ści owe t ego działania. Więcej szczegółów na
temat organizacj i proj ektu można znaleźć w Roz-
dziale 5.
PRINCE2 zaleca wykonanie następujących czynności :
• Przeprowadzić przegląd zlecenia przygotowania
projektu i sprawdzić, czy jest ono zrozum i ałe.
• M i anować Przewodniczącego (nominacji doko-
nuje organizacj a powołująca projekt - zazwyczaj
jest to kierownictwo organizacj i lub programu).
W tym celu na l eży:
• usta l ić obowi ązki Przewodniczącego;
• przygotować opis rol i Przewodniczącego na
podstawie opisu roli zawartego w Dodatku C;
• oszacować nakłady czasu i pracy wymagane
dla roli Przewodniczącego (będz i e to dopre-
cyzowane w późn i ej szym terminie);
 Przygotowanie Projektu I 131

/
Zlecenie
przygotowania projektu "'
~
Mianowanie
Przewodniczącego
i Kierownika Projektu
Zaloi enia Projektu
(część)

r
Wytworzy< I Opis roli •
I Przewodniczącego I
'„ - „ „• - -4
„ -
-Wytwoo.y(
I Opis roli
I Kierownika Projektu I
• „ - „ „ •• ._.
•

Potwierdzić
r
I
- - -
Miano wany
-
- •

- -
I Przewodniczący
I
'„ „ • -4
r -
•
- - - -
Potwierdzi( I M ianowany •

Za loży(
I Kierownik Proj ektu I
' „
- „ „ • - -4

Dziennik Projektu

Rysunek 12.2 Mianowanie Przewodniczącego i Kierownika Proj ektu - schemat działania

• zidentyfikować kandydatów na stanowisko • potwi erdzić nominację z kierownictwem

Przewodniczącego spośród interesariuszy organizacji lub programu.
projektu i wybrać osobę najbardziej odpo-
• Założyć Dziennik Projektu jako repozytorium
wiednią do tej roli;
informacji dotyczących projektu, które nie są na
• potwierdzić dostępność wybranej osoby,
razie rejestrowane gdzie indziej.
uzyskać akceptację na pełnienie przez nią tej
roli oraz zaangażowanie się w jej wypełnie­ Tabela 12. 1 przedstawia obowiązki związane z tym
nie; działaniem.

• powierzyć wybranej osobie rolę

Przewodniczącego .
• Mianować Kierownika Projektu (nominacji doko-
nuje Przewodniczący). W tym celu należy:
• ustalić obowiązki Kierownika Projektu;
• przygotować opis ro li Kierownika Projektu
na podstawie opisu roli zawartego
w Dodatku C i uzyskać zgodę kierownictwa
organizacji lub programu;
• zidentyfikować kandydatów na stanowisko
Kierownika Projektu i wyb rać osobę najbar-
dziej odpowi ednią do tej rol i;
12.4.2 Zgromadzenie dotychczasowych
doświadczeń
Szereg doświadczeń, dotyczących wad lub zalet
stosowanych procesów, procedur, technik i narzędzi
oraz tego, kiedy, jak i przez kogo były używane,
może pochodzić z innych projektów, od kierow-
nictwa organizacji lub programu i od organizacji
zewnętrznych.
Doświadczen i a uzyskane podczas wcześniejszych
projektów mogą wpłyn ąć na strukturę zespo łu
zarządza n i a projektem, zarys Uzasadnienia Bizne-

• oszacować nakłady czasu i pracy wymaga-
ne dla ro li Kierownika Projektu (będzi e to
doprecyzowane w późn i ejszym terminie);
• potwierdzić dostępność wybranej osoby, uzy-
skać akceptację na pełnienie przez nią tej roli
oraz zaangażowanie się w jej wypełnienie;
• powierzyć wybranej osobie rolę Kierownika
Projektu;
sowego, treść Założeń Projektu oraz na Plan Etapu
1n1qowan1a.
Przydatne może być zorganizowanie sesji warszta-
towej, jako sposobu gromadzenia odpowiednich
doświadczeń. Uczestnikami warsztatów mogą być
wszelkie zainteresowane strony oraz osoby, które
pracowały nad wcześniejszymi podobnymi projek-
tami. Jeżeli organizacja nie zrealizowała przedtem
projektu tego typu, pomocne może być włączenie
132 I Przygotowanie Projektu

Tabela 12.1 Mianowanie Przewodniczącego i Kierownika Projektu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej nieza l eżny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c
a.
E .:.! ....Cl>-
·-
ro
.....
Ol
o..... ~
c
;:
o
ro
u
;:
....
:i
.:.!
(IJ
·~
-:i
o
a. ....
:i
....
:i
.:.!
(IJ
"'
o
"O
o.. .:.!
....ro o..... "'(IJ .:.!
....
:i

--
IO' ·~

ro N
>. o.. N
(IJ o
..... .:.!
·~
u
u
·-c ·N "'o .:.! .:.!
·~
o
..... o.. :i
IO
N "O
:J
>.
Cl
>.
·-c ·-c o..
.....
(IJ
·-u.....
"O
o
.....
o c c ;: ;: -o
c
ro ;: ;: ;: o o N <O
o..
..... ..... a.
Produkt Czy nność
Ol
.....
o
QI
N
.....
o.. -..., -...,
·O -o QI
·-
~
QI
·-
~
"O
z
IO
$"' o
"'a.

Zlecenie przygotowania projektu Dostarczyć w

Opis ro li Przewodni czące go Wytworzyć w
Mianowany Przewodniczący Potwierdzić w
Opis ro li Kierownika Projektu Wytworzyć z w
Mianowany Kierownik Projektu Potwierdzić z w
Dziennik Projektu Założyć w A7

osób spoza tej organizacji, posiadających odpowied- wykorzystać w tym projekcie. M oże to obejmo-
nie doświadczenie. wać np. wyniki audytów i przeg l ądów projektu.

W trakcie przechodzenia od ogólnego spojrzenia • Dokonać przeg lądu doświadczeń kierownictwa

w procesie Przygotowanie Projektu do bardziej organizacji, kierownictwa programu i organizacji

wnikliwego spojrzenia w procesie Inicjowanie Pro- zewnętrznych.

jektu i obrazu uaktualnionego w procesie Za rzą­ • Przeprowadzić konsultacje z osobami łub zespo-
dzanie Końcem Etapu, może być konieczne wyjście lami posi adającym i doświadczenia z real izacji
poza Dziennik Doświadcze ń, aby przez powtórze- podobnych projektów.
nie tego dzia łan i a wychwycić wszelkie inne zwi ąza­ • J eże l i jest to właściwe - zarejestrować ziden-
ne z projektem doświadczenia zewnętrzn e. tyfikowane doświadczenia w Dzienniku
Doświadczeń.
Rysunek 12.3 przedstawia elementy wejściowe i wyj-
ściowe tego działania .
Tabela 12.2 przedstawia obowiązki związane z tym
działaniem.
PRINCE2 zaleca wykonanie następujących czynności:

• Za lożyć Dziennik Doświadczeń. 12.4.3 Projektowanie zes połu za rządza nia

• Dokonać przeg lądu Raportów Doświadczeń projektem i mianowanie jego czło nków
z podobnych wcześniejszych projektów w celu Do terminowego podejmowania decyzji w projekcie
zidentyfikowania doświadczeń, które można potrzebni są właściwi ludzie, posi adający odpowiednie

, . - - - - - - -I
1 Wcześniejsze Zgromadzenie dotychczasowych Założyć Dziennik
1 raporty doświ adczeń
• doświadczeń Doświadczeń
l _ ......
.... - „
Rysunek 12.3 Zgromadzenie dotychczasowych doświadczeń - schemat działania
 Przygotowanie Projektu I 133

Tabela 12.2 Zgromadzenie dot ychczasowych doświa dczeń - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej nieza l eżny od wyt wórcy
Zatwierdzający - potwierdza odbiór
>-
c
E o.
.><!
·-c ....°"
....
-oo.
IO ::;)
..... ::;) V>
O"> ;: IO
u .><! ....
::;)
o
o..... >- o ;: QI
....
::;)
.><! "O

-
u ·~ QI
o._ llJ' .><! IO o
.....
V> .><! ·~ ....
::;)

IO
N
u >- t; o._ N
QI QI
·~
o
..... .:.I.
·~
u ·-c ·N o o
..... o._ ::;)
IO "O
::> o .:.I.
·-c .:.I.
·-c o._ QI "O
o
N
o >- >- ..... ·-u ....
c ;: c c ;: ;: ·O ..... o._
IO ;: ;: o
.... o
..... N IO
o. ·-o.
- -
QI V>
"O
....O"> N •O ·O QI QI
5"'
..... IO
Produkt Czynn ość o o._ \.!] \.!] ~ ~ z o
Dziennik Doświ adczeń Założyć K w A14

uprawnienia, obowiązki i wiedzę. Zespól zarządzania PRINCE2 zaleca wykonanie następujących czynności :
projekt em musi odzwiercied l ać interesy wszystkich
• Dokonać przeglądu Dziennika Doświadczeń pod
stron, które będą w nim uczestniczyly, w tym interesy
kątem doświ adczeń dotyczących struktury zespo-
biznesu, użytkownika i dostawcy.
łu zarządza n i a
projektem.
Dla prawidlowo zarządzanego projektu niezbęd n e • Zaproj ektować zespól za rządzania projektem.
j est, aby każda osoba zaa n gażowa na w zarzą d zanie W tym celu należy:
projektem zrozum iała i zgodz iła się, kto odpowiada • opracować struktu rę zespołu za rządza n ia
przed k im i za co, kto ma j akie obowiązki oraz jakie proj ektem;
są drogi raportowa nia i komunikacji.
• stworzyć opisy ró l dla pozostalych ró l
Rysunek 12.4 przedst awia element y wejści owe i wyj- w Komitecie Steruj ącym, na podstawie opi -
ści owe tego dzialania. Więcej szczegółów na temat sów ró l zawartych w Dodatku C;
o rganizacji projektu możn a znaleźć w Rozdziale 5. • ustal i ć, czy czlonkowie Kom itetu Steruj ącego
za m ie rzają del egować swoje obowiązki

Pfojektowanie
Dziennik Doświa dczeń zespoł u za rządzan i a Uak tua l nić
Dziennik Projektu
projektem i mianowanie
jego czlonków

Za l ożenia Projektu
Za l ożenia Projektu
(częsc)
(część)

- .• ...
r - - - -
•
......
Opis ro li • Wyt\vorzyć I Opisy ról zespolu

1
„ -
Pr zewodniczącego

„ „ -
,. - - - -
Opis roli
-- ....
.
•
I zarządzania projekte1n

'... „ -. _
Struktura zespolu
I

•
• Wyt\voriyć. 1

-....
Kierownika Proje ktu zarządzania projektem I
1

„ - „ „ • ' „ - „ „ • - ....
... -
Potv1i erdzić I
- -
M ianowany zespól
- •
zarządzania projekt em I

„ - „ „ - - ....
Rysunek 12.4 Projektowanie zespołu zarządzania projektem i mianowanie j ego członków- schemat działania
134 I Przygotowanie Projektu

dotyczące nadzoru i stworzyć opis(-y) ról • wskazane może być przeprowadzenie

Nadzoru Projektu (tam, gdzie jest to wła­
ściwe) na podstawie opisu roli zawartego
w Dodatku C;
• rozważyć, czy będą potrzebne odrębne osoby
do pełn i en ia ro li Kierownika(-ów) Zespołu(­
ów), czy też Kierownik Projektu będzie pe łnić
tę rol ę osobiście. Jeże l i będzi e to właściwe,
należy stworzyć opisy ról dla Kierownika(-ów)
Zespołu(-ów) na podstawie opisów ról zawar-
tych w Dodatku C;
• rozważyć, czy Kierownik Projektu będzie
pełnić rolę Wsparcia Projektu, czy potrzeb-
na będzie odrębna(-e) osoba(-y). Jeżeli rola
ta ma być powierzona innej osobie, na l eży
stworzyć opis roli Wsparcia Projektu na pod-
stawie opisu rol i zawartego w Dodatku C;
• potwierdz i ć drogi raportowania i komuni-
kacji w opisach ról.
• Mianować zespół zarządzania proj ektem. W tym
celu należy:
• oszacować nakłady czasu i pracy wymaga-
ne dla każdej z określonych ról (będzie to
doprecyzowane w późniejszym terminie);
• zidentyfikować kandydatów do każdej z ról
i zaproponować osoby najbardziej odpo-
w iednie do nich:
analizy interesariuszy (patrz sekcja 5.3.5)
w celu zidentyfikowania odpowiednich
kandydatów do tych ró l;
• możl iwe jest, że kandydaci nie będą jesz-
cze znani w tym momencie, w takim przy-
padku należy ich wybrać późn i ej (patrz
sekcje 14.4.5 i 17.4.1). Ma to w szcze-
gólności zastosowanie, jeże l i Kierownicy
Zespołów mają być wybrani spośród pod-
wykonawców;
• należy rozważyć, czy wskazani kandy-
daci posiadają kompetencje wymaga-
ne do pelnienia danej roli, a jeśli nie,
czy potrzebne jest jakieś szkolenie lub
wsparcie (np. coaching).
• potwi erdz i ć dostępność wybranych osób
U eżel i są one znane), uzyskać ich zrozumie-
nie i akceptację ró l oraz zaangażowa n ie
w ich pelnienie;
• wyznaczyć wybrane osoby do każdej ze
zidentyfikowanych ról i uzyskać ich miano-
wania przez kierownictwo organizacji lub
programu.
• Jeżeli zostaną zidentyfikowane jakieś ryzyka,
na l eży je dodać do Dziennika Projektu.
Tabela 12.3 przedstawia obowiązki związan e z tym
dzialaniem.

Tabela 12.3 Projektowanie zespołu za rządzania projektem i mianowanie jego członków - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>-
c:
Q.
E ~ Cl>-
ro
....
Cl
o
.... Ci'
c:
~
o
ro
V
~
....
::i
..>L
Q)
·~
o
-
::i
o
a. ....
::i
....
::i
..>L
Q)
t:
o
"O
::i
a.
...... nr ..>L ro .... "'
Q)
..>L ·~
o ~
Q)
.~ t: ....
N
ro a. N ·~
·~
V ·-c:
V
o
o ~ ~
o
.... a. ::i
ro "O
:::::> ·-c ·-c: a. Q)
·-
"O
o
N
o >.
c:
>.
c: ~ ~
'-
....
V ....
c ~ o o
·O a..
ro ~ ~ .... N
'°a. ·-"'Q.
Produkt
. Czynność o
....
Cl
Q)
....
N
a. - -
•O
~
•O
~
'-
Q)
·-
~
Q)

~
"O
z'° 3"' o
Dziennik Projektu Uaktualnić w A7

Opisy ról zespolu zarządzania projektem Wytworzyć z w

Struktura zespołu za rządzania projektem Wytworzyć z w
Mianowany zespól zarządzania projektem Potwierdzić z w

,,ecen1e Przygotowanie zarysu
I przygotowania ' Uzasadnienia
Biz..nesowego
nro•ektu
'
Dziennik Oo~wia d czeń
Rysunek 12.5 Przygotowanie zarysu Uzasadnienia Biznesowego - schemat działania
12.4.4 Przygotowanie zarysu Uzasadnienia
Biznesowego
Podczas przygotowania projektu, a zwłaszcza pod-
czas jego prowadzenia, łatwo jest koncentrować się
na tym, co powinno być zrobione i w jaki sposób,
zapominając jednocześnie o tym, d laczego ma to
być zrobione. Uzasadnienie Biznesowe ok reśla dla-
czego prace są warte realizacji i w związku z tym
jest kluczowym elementem projektu.
J eże l i projekt jest częścią programu, wówczas Uza-
sadnienie Biznesowe mogło już zostać zdefiniowane
na poziomie programu.
Biorąc pod uwagę dostępne inform acje, zarys Uza-
sadnienia Biznesowego będzie prawdopodobnie
j edynie spojrzeniem uZ lotu ptaka". Stanowić będzie
ono uzgodnioną podstawę do opracowania rozsze-
rzonego Uzasadnienia Biznesowego w procesie Ini-
cjowanie Projektu.
Rysunek 12.5 przedstawia elementy wejściowe i wyj-
ściowe tego działania. Więcej szczegółów na temat
Uzasadnienia Biznesowego możn a zna l eźć w Roz-
dziale 4.
PRINCE2 zaleca wykonanie następuj ących czynności :
• Przewodn iczący powinien sporząd zić zarys
Uzasadnienia Biznesowego na podstawie akt ual-
nych informacj i o projekcie. W tym celu powinien:
• zrozumieć cele i przyczyny realizacji pro-
jektu, określone w zleceniu przygotowania
projektu;
• zrozumieć sposób, w jaki projekt przyczyni
się do osiąg n ięcia celów organizacji i/lub
programu;
Przygotowanie Projektu I 135
Zalotenia Projektu
(czfl()
Wytworzyt
Uzasadr'licr1ic
Biznesowe (zarys)
Wytwo1~yl
Opis Produktu
Końcowego Projektu
Uakt ualnk
Dziennik. Projektu
• zrozum i eć sposób, w jaki projekt będ zie
finansowany;
• dokonać przeglądu Dziennika Doświ adczeń
pod kątem doświ adczeń związanych z uza-
sadnieniem biznesowym;
• sprawdzić standardy obowiązujące dla for-
matu i sposobu przedstawienia Uzasadnienia
Biznesowego (szablony, miary kosztów itp.);
• zgromadzić wszelkie odpowiednie informacje
dodatkowe, np. kontrakty, ra porty dotyczące
wykonalności, umowy dotyczące poziomu
j a kości usług (SLA) itp.;
• j eśl i to konieczne, uzyskać akceptacj ę kierow-
nictwa organizacji lub programu d la zarysu
Uzasadnienia Biznesowego.
• Kierownik Projektu powinien skonsultować się
z Głównym Użytkowniki em i Przewodniczącym
w celu ustalenia, co projekt ma dostarczyć, i stwo-
rzenia Opisu Produktu Końcowego Projektu
(patrz Rozdział 6). W tym celu powinien:
• ustalić oczekiwania jakości owe kl ienta;
• ustalić i uzgodnić kryteria akceptacji dla
projektu;
• sprawd zi ć możliwość sprostania wymaganym
terminom określonym w zleceniu przygoto-
wania projektu łub wymaganym w zarysie
Uzasadnienia Biznesowego;
• ustalić główne kamienie milowe;
• zarejestrować ewentualne nowe ryzyka
w Dzienniku Projektu.
• Dokonać przeglądu ryzyk zarejestrowanych
w Dzienniku Projektu i w zarysie Uzasadnienia
Bi znesowego podsumować główne ryzyka mające
wpływ na zasad ność projektu.
136 I Przygotowanie Projektu

Tabela 12.4 Przygotowanie zarysu Uzasadnienia Biznesowego - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

.
Kontroler - najlepiej n i eza l eżny od wytwórcy
Zatwierdzający - potwierdza odbiór >.
c
a.
E aJ.
..>t.
·- ...
::J
- t:
... ...
"'....Ol c
~ "'~
V ..>t.
::J
o
::J o
o
.... ~ o tli
a. ::J ..>t. 'O
a.
--"' 111"
N
V
..>t.
>.. ..."'o
Vl
·~
o
....
a. N
Vl
tli
..>t.
tli
·~
tli
·~
o
....
...
::J
..>t.
·~ ·-
c
·N o
.... a. ::J
V
::> o ..>t. ..>t.
a. "O
·-"'c
c c tli
N "O
o >. >. .... ·- o
....
c c ~ ~ ·O ....
V
a.
~ o o
"'....Ol ~ ~ .... .... N
"'a. ·-a.
- -
tli Vl
·O ·O "O
....
N tli
·- tli
·- "'
Vl

Produkt Czynność o a. 1.9 1.9 :><: :><: 2 5 o

Zarys Uzasadnienia Biznesowego Wytworzyć z w K K K K A2
Opis Produktu Końcowego Projektu Wytworzyć (Z) (Z) (Z) w K A21
Dziennik Projektu Uaktua l n i ć w A7

Tabela 12.4 przedstawia obowi ązki związane
działaniem.
12.4.5 Wybieranie formuły realizacji
projektu i zestawianie Założeń Projektu
Zanim można będz i e wykonać jakiekolwiek prace
planistyczne w projekcie, na l eży podjąć decyzje
usta l ające sposób, w jaki będą realizowane prace
projektu. Na przykład czy rozwi ązanie zostanie
wytworzone we własnym zakresie, czy zlecone stro·
nom trzecim? Czy rozwi ązanie będz i e modyfi kacją
istn i ej ącego produktu, czy zostanie zbudowane od
podstaw? Czy rozwiązan i e będzie oparte na han-
dlowej wersji produktu „ z półk i " (zwanym zazwy-
czaj COTS - Commercial Off-The-Shelf Product), czy
zostanie wykonane „na m i arę"?
Sposób prowadzenia prac będzi e za l eżeć od stan·
dardów, praktyk i wytycznych klienta lub dostawcy,
na przykład konkretnych cykli wytwarzania produk-
tów, które mogą mieć zastosowanie. Informacja
o tym powinna być zawarta w Założen i ach Projektu
jako część formuly rea lizacji projektu, ponieważ
będzie m i ała wplyw na strategie projektu, które
mają być opracowane w procesie Inicjowanie Pro-
jektu. Zapewnia to również, że formuła realizacji
proj ektu j est jednoznacznie i j ednakowo rozumiana
zarówno przez klienta jak i dostawcę oraz nie nara-
ża ona projektu w żaden sposób na niebezpieczeń­
stwo.
z tym Uzgodnione Zależenia Projektu zapewn i ają, że pro-
j ekt uzyskuje powszechnie zrozum i ały i ściśl e okre·
śl ony punkt wyjściowy.
Rysunek 12.6 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Ocen i ć możliwe sposoby dostarczenia produk-
tów projektu i zadecydować o formu le rea li·
zacji projektu właści wej dla dostarczenia pro-
duktu końcowego projektu zgodnie z zarysem
Uzasadnienia Biznesowego. W tym celu należy:
• dokonać p rzeglądu Dziennika Doświ adczeń
pod kątem doświadczeń zwi ąza nych z for-
mułą realizacji projektu;
• rozważyć wszelkie strategie organizacji lub
programu, które dotyczą projektu i um i eścić
projekt w kontekści e innych prac lub inicja-
tyw organizacj i przez ustalenie zewnętrz­
nych uzal eżn ień i warunków wstępnych;
• rozważyć wszelkie standardy organizacji
lub programu bądź praktyki, które powinny
m i eć zastosowanie (w komercyjnym kontek-
ści e klient/dostawca będ ą prawdopodobnie
istn i eć różne standardy i praktyki, które
należy zaadaptować);
• rozważyć aktualne tendencje rea lizacji roz-
wi ąza ń w sektorach gospodarki objętych
projektem i obszary umiej ętności specjali-
stycznych, angażowane do projektu (w tym
wszelkie warianty techniczne dla cyklu
wytwórczego produktu proj ektu);
 Przygotowanie Projektu I 137

Załoienia Projektu Wybieranie formuly realizacji Zfitawii

(cz ęśc1 projektu i zesta\vianie Założenia Projektu
Założeń Projektu

' r -
Opis Produktu •
-
I Formula realizacji
Ko rlcowego Projektu
. I
0J)f3(0\Y3C/
wyl>ra( .' projektu

Uzasadnienie
Biznesowe (zarys) Wytworzył
I

r
I
„
- - „ ....
•
oodatkowe
,,.

I opisy ról I

r
I
- - -
Opis roli
.
•
I
„
- „ „ • - ...

-
•
Przewodnicz4cego
I
'r „
--- - „ „ „
- -
.... Uo1.ktualnil
Dziennik Ptojektu

I Opis roli •

-
•
Kierownika Projektu
I
'„
r -- - - - ...
„ „ „ .•
1 Opisy ról zespołu

•„
r
I
-
1zarz11dza1,ia projektem •

Struktura
...
„ „ •
-- - - - . zespołu
•
1 zarządzania projektem •

'„
- - ...
„ „ •
Dziennik OoSwiadczeń

Rysunek 12.6 Wybieranie formuły realizacji projektu i zestawianie Założeń Projektu - schemat działania

Tabela 12.5 W ybieranie formuły realizacji projektu i zestawianie Założeń Projektu - obowiązk i

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c
E a.
QI-
-"
·-c ..,:J
ro
....
Cl
o
.... ~
~
o
ro
V
~
-"
Cl/
o
-
:J
o
a. ..,:J ~
:J t:
o
"O
a..
..... nr -" ro
·~
.... VI
Cl/ -"
Cl/
Cl/
·~
o ..,
:J

.~ t: ....
N a..
ro N ·~ -"
·~
V
ro
·-c:
V

::::>
o
Cl -" -"
o
....
a..
a..
Cl/
:J
"O
N "O c: c: .... ·-.... o
....
·-c: o
~
>.
c:
>.
c: ~ ~ ·O
V
a..
ro ~ ~ ....o o
.... N ro
....
Cl Cl/
N
.... - -
·O •O
·- Cl/ Cl/
·-
"O
ro
a. ·-"'a.
Pro dukt Czynność o a.. ~ ~ ~ ~ z ~ o
Formuła realizacji projektu Opracować/wybrać (Z) (K) (K) w K
Dodatkowe opisy ról Wytworzyć (Z) (K) (K) w K
Założenia Projektu Zestawić (Z) (K) (K) w K A 19

Dziennik Projektu Uaktua l n ić w A7

138 I Przygotowanie Projektu
• określić środowisko operacyjne, do którego
rozwiązanie musi być dopasowane (włą­
czając implikacje i ograniczenia wynikające
z uwarunkowań eksploatacji łub utrzyma-
n ia), oraz sposób wprowad zenia produktu
projektu do tego środowiska;
• rozważyć ewentualne ograniczenia zwi ązane
z bezpieczeństwem, które mają zastosowa-
nie do projektu lub eksploatacji jego pro-
duktów;
• rozważyć ewentualne potrzeby szkoleniowe
personelu użytkownika.
• Zestawić Założenia Projektu. W tym celu należy:
• zdefi niować projekt, tzn.:
• potwierdzić aktualny status projektu
(np. tło projektu i wszelkie przeprowadzo-
ne dotychczas prace przygotowawcze);
• potwierdzić cele i pożądane rezu ltaty;
• potwierdzić zakres projektu i wyłączenia;
• zidentyfikować wszelkie ograniczenia
i założenia;
• zidentyfikować tolerancje dla projektu;
• zidentyfikować użytkownika(-ów) oraz
wszelkie inne zainteresowane strony;
• zidentyfikować punkty styku, które projekt
musi utrzymywać;
• dołączyć zarys Uzasadnienia Biznesowego;
• do łączyć Opis Produktu Końcowego Projektu;
• dołączyć formułę rea lizacji projektu;
• dokonać przeglądu struktury zespołu zarzą­
dzania projektem i opisów ról w celu ziden-
tyfikowania wszelkich dodatkowych ról lub
Zalo t enia Projektu Planowanie
etapu inicjowania
Dziennik Projektu
Dziennik Doświadczeń
Rysunek 12. 7 Planowanie etapu inicjowania - schemat działania
umiejętności wymaganych do prowadzenia
prac. Sporządzić dodatkowe opisy ról w razie
potrzeby;
• dołączyć strukturę zespołu zarządzania pro-
jektem i opisy ról.
• Wykorzystać Dziennik Projektu do zarejestrowa -
nia wszelkich nowych zagadnień łub ryzyk.
Tabela 12.5 przedstawia obowiązki zwi ązane z tym
działaniem.
12.4.6 Planowanie etapu inicjow ania
Inicjowanie Projektu wymaga czasu i zużywa zaso-
by. Ta praca powinna być zaplanowana i zatwier-
dzona, j ak każda inna praca w projekcie. Pozwoli to
zapewnić, że inicjowanie projektu j est zasadne i nie
będzie przebiegać chaotycznie.
Jeżel i projekt jest częścią programu, termin zakoń­
czenia etapu inicjowania powinien być uzgodniony
z terminem zapisanym w planach programu. Plan
Etapu dla etapu inicjowania przekaże także kierow-
nictwu programu informację o wymaganiach wobec
programu.
Częścią procesu Przygotowanie Projektu jest roz-
ważenie wykorzystania innych procesów PRINCE2
w trakcie Inicjowania Projektu. Na przykład projekt
może przewidywać zastosowanie procesów Stero-
wanie Etapem i Zarządzan i e Dostarczaniem Produk-
tów w trakcie procesu Inicjowanie Projektu.
Rysunek 12.7 przedstawia elementy wejściowe i wyj-
ściowe tego działania. Więcej szczegółów na temat
planowania można znaleźć w Rozdziale 7.
Wytwo,•yć Plan Etapu
Uaktualnit
Dziennik Projektu
/ Wniosek
o zainicjowanie
'
nroiektu ,
 Przygotowanie Projektu I 139

Tabela 12.6 Planowanie etapu inicjowania - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierd za odbiór
>-
c
a.
E ~ Cl>-
·-c
....
"'oOl
.... .,.~
~ "'~ ·-o
V
:i
j;ł
QI
-a.
:i
o :i
:i
+'
~
t:
o
"O

·-c......o ·-c......o
o +' QI
:i
c.. ~
......
tl
~

>. "' c......

t: "'
QI QI
~
·-
111
V ·-c ·N
:::> o
o ~
·-c
N
~
·-c
:i
"O
"'c
N "O
o >-
c >-
c ~ ~
....
•O
QI
....
V
o
....
c..
~ o o
"'.... ~ ~ .... .... N
"'"'a. ·-a.
-"' -"'
QI VI
Ol N •O •O QI QI
"O
....
Produkt Czynność o o.. ~ ~ z"' s: o
Plan Etapu Wytworzyć (Z) (Z) (Z) w K A16
Dziennik Projektu Uaktualnić w A7

PRINCE2 zaleca wykonanie następujących czynności: • Dokonać przeg l ądu wszelkich ryzyk w Dzienniku
Projektu i ocenić ich wpływ na Plan Etapu inicjo-
• Na podstawie formuły realizacji projektu podjąć
decyzję o odpowiednich mechanizmach sterowa-
wania.
nia projektem, wystarczających dla zainicjowania • Jeżeli zostaną zidentyfikowane nowe ryzyka (lub
projektu. W tym celu należy: istniejące ryzyka ulegną zmianie), dokonać aktu-
• dokonać przeglądu Dziennika Doświadczeń alizacji Dziennika Projektu.
pod kątem doświadczeń związanych • Wystąpić z wnioskiem o zezwolenie na zainicjo-

z mechanizmami sterowania projektem; wanie projektu.

• okreś l ić sposoby raportowania i kont roli d la Tabela 12.6 przedstawia obowiązki związane z tym
etapu inicjowania. działaniem.
• Zidentyfi kować wszelkie ograniczenia czasowe
i kosztowe dla etapu inicjowania oraz opraco-
wać Plan Etapu dla tego etapu, zgodnie z zasa-
dami i technikami zawartymi w Rozdziale 7.
 13 Zarządzanie Strategiczne Projektem

13.1 PRZEZNACZENIE • plany dotyczące osiągn i ęcia korzyści poprojekto·

wych podlegaj ą zarząd za n iu i przeglądom .
Proces Zarządza nie Strategiczne Projektem u moż­
liwia Komitetowi Sterującemu przyjęcie odpowie-
dzialności za powodzenie projektu, poprzez podej-
13.3 KONTEKST
mowanie kluczowych decyzji i sprawowanie ogólnej Proces Zarządzanie Strategiczne Projektem rozpo-
kontroli, podczas gdy bieżące zarządzanie projek- czyna się z chwilą zakończenia procesu Przygotowa-
tem delegowane jest Kierownikowi Projektu. nie Projektu i jest uruchamiany wnioskiem o zezwo-
lenie na zainicjowanie projektu.
13.2 CEL Proces Zarządzanie Strategiczne Projektem nie
obejmuje codziennych zadań Kierownika Projek-
Celem procesu Zarządzanie Strategiczne Projektem
tu, natomiast obejmuje d ziałania osób na szczeblu
jest zapewnienie, że:
zarządzania ponad Kierown ikiem Projektu, czyli
• istniej e organ uprawniony do zainicjowania pro- Komitetu Steruj ącego. Komitet Sterujący za rządza,
jektu; wykorzystując tolerancje. Monitoruje projekt, korzy-
• istnieje organ uprawniony do dostarczania pro- stając z raportów, i steruj e nim, wykorzystując nie-
duktów projektu; wielką liczbę punktów decyzyjnych. Komitet Sterują­
• zarządcze ukierunkowan ie i sterowanie są reali- cy nie powinien odczuwać potrzeby organizowania
zowane przez caly czas życia projektu, a projekt dodatkowych narad „dla oceny postępów". Kierow-
pozostaje zasadny; nik Projektu będzie informował Komitet Sterujący
• istnieje punkt styku pomiędzy kierownictwem o wszelkich sytuacjach nadzwyczajnych. Jest również
organizacji lub programu a projektem; ważne, aby poziomy uprawn i eń i procesy podejmo-

• istniej e organ uprawniony do zamknięcia projektu; wania decyzji byly jasno określone.

I
I

( ołfiwolen.~r.,: ~) ( "f~"} (
. ,,.,," •)
"""""' ) o:~.iql
I •• - ._tu

r----- -------------- - - - - ----------------- - - - - - - _ł_ - - --------- - - - -----„ ------ •

Zarządzanie Stra tegiczne Projektem
Z•zwa.I.Anie N tt:łlillł<)t ptojtktu

•
Ze:włlanlt ne ttłłlt~łt Pl•nu Etapu
tub Płenu N1d:wyu.1Jr'lego

Podejmownnle de<yzjl dorainel

Zetwalanit n.o
tamkni«ie p1oj1?ktu
„ _____
----- -- - ------- -·----· ------ ------- --- •
·-----
- - - - „ - - - -

- --
rvmlowli; o 1.łiw..,
ltlWOlł~•
[W fff"t.U<llf fU~ I ·~~ 'W. I ; ; rłWIWll„... ' ł
.•„
• N )
~
,..~.,.,
rWtwp.vPf
"-- 11 •··~
.....
~(,~~.} ~ I ~( ............ '" ...~
~ ..,.,„.)
"'""'''
1
Zaną<f1anie
Końcem Ei.pu .__......„
Sterowanie Etapem

Rysunek 13.1 Diagram procesu Zarządzanie Strategiczne Projektem

144 I Zarządzanie Strategiczne Projektem
W trakcie realizacji projektu niezbędny jest dwukie-
runkowy przepływ informacji między Komitetem
Sterującym a kierownictwem organizacji lub progra-
mu. K l uczową rol ą Komitetu Sterującego jest zaan-
gażowanie się w kontakty z kierownictwem orga -
nizacji lub programu oraz działani e w charakterze
kanału komunikacyjnego. Ten wymóg i sposób jego
spe łnienia powinny być udokumentowane w Strate-
gii Zarządzan i a Komunikacją.
Komitet Sterujący powinien zapewnić Kierownikowi
Projektu ujednolicone ukierunkowanie i wytyczne.
Jeżel i Komitet Sterujący nie jest w stanie osiągnąć
wspólnego punktu widzenia lub jeżeli przekazywa-
ne są niezależne, a może nawet sprzeczne wytyczne,
wówczas ryzyko niepowodzenia proj ektu znacznie
wzrasta. W takich przypadkach Kierownik Projektu
powinien podporządkować się wytycznym Przewod-
n i czącego .
Komitet Steruj ący jest odpowiedzialny za zapew-
nienie, aby istnialo ciąg l e ważne uzasadnienie biz-
nesowe. Proces Zarządzanie Strategiczne Projektem
dostarcza Komitetowi Sterującemu mechanizmu
umożliwiającego zapewnienie tego bez nadmierne-
go obciążenia działaniami dotyczącymi projektu.
Jedną z funkcji Komitetu Sterującego jest udzielanie
Kierownikowi Projektu nieformalnych rad i wskazó-
wek, a także formalnych wytycznych. Kierownik Pro-
jektu powinien zasi ęgnąć rady zawsze wtedy, kiedy
będzi e to potrzebne w trakcie rea lizacji proj ektu.
13.4 DZIAŁAN IA
Dzialania w procesie Zarządzanie Strategiczne Pro-
jektem dotyczą glównie Komitetu Sterującego i są
prowadzone po to, by:
Zezwalanie na
( Wniosek
o zainicjowanie projektu zainicjowanie projektu
Zalotenla Projektu
Plan Etapu
(Et ap inicjowania)
Rysunek 13.2 Zezwalanie na zainicjowanie projektu - schemat działania
• zezwolić na zainicjowanie projektu;
• zezwolić na rea l izację projektu;
• zezwolić na realizację Planu Etapu lub Planu
Nadzwyczajnego;
• podjąć decyzję doraźną;
• zezwolić na zamknięcie proj ektu.
13.4.1 Zezwalanie na zainicjowanie
projektu
Inicjowanie projektów wymaga czasu i środków
finansowych, a więc dzialania dotyczące inicjowa-
nia powinny podlegać planowaniu, monitorowaniu
i sterowaniu. Działanie Komitetu Sterującego pole-
gające na zezwoleniu na zainicjowanie projektu
zapewnia, że taka inwestycja będzie warta poniesio-
nych n a kładów.
Po otrzymaniu wniosku o zainicjowanie projektu
z procesu Przygotowanie Projektu, Komitet Steru-
jący musi zadecydować, czy powinien zezwol i ć, aby
projekt przeszedł do etapu inicjowania. Można to
zrobić na formalnej naradzie Komitetu Sterującego .
Jednakże Komitet Sterujący może się zdecydować
na podjęcie tej decyzji bez konieczności odbycia for-
malnej narady, o ile wszyscy jego członkowie się na
to zgodzą, a Kierownik Projektu otrzyma od Prze-
wodniczącego udokumentowane polecenie rozpo-
częcia inicj owania projektu.
Komitet Sterujący może wyznaczyć Nadzór Projektu,
aby podją ł niektóre czynności przeg l ądu i oceny
(np. analiza Planu Etapu inicjowania w celu potwier-
dzenia, że jest on wykonalny}.
w przypadku komercyjnych relacji klient/dostawca,
Glówny Dostawca może jeszcze nie zostać miano-
wany do tego momentu i/lub zatwierdzenie przez
Zatwierdzić
Zaloienia Projektu
Za twierdzić Plan Etapu
(Etap inicjowania)
„ Zezwolenie na
~
, zainicjowanie projektu ~ I
Powiadomienie "'
o zainicjowaniu projektu
 Zarządzanie Strategiczne Projektem I 145

niego Założeń Projektu i ich części składowych może
nie być konieczne dla zezwolenia na zainicjowanie
projektu.
Rysunek 13.2 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następuj ących czynności :
• Dokonać przeglądu i zatwierdzić Zalożenia
Projektu. W tym cel u na leży:
• potwierdzić definicję projektu (włącznie
z kluczowymi kamieniami milowymi);
• potwi erdzić fo rmu łę realizacj i proj ektu;
• of icjalnie potwi erdz i ć nominacje dla zespołu
zarządzania projektem i potwierdzić, że wszy-
scy członkowie zgodzili się na swoje role.
• Dokonać przeglądu i zatwierdzić Opis Produktu
Końcowego Proj ektu. W tym celu na l eży:
• potwierdzić oczekiwania jakościowe klienta.
• potwierdzić kryteria akceptacji.
• Sprawdzić, czy zarys Uzasadnienia Biznesowego
przedstawia zasadny projekt. W tym momencie
zarys Uzasadnienia Biznesowego może zawierać
tylko informacje wystarczające do racjonalnego
uzasadnienia ce lowości projektu. Szczegółowe
Uzasadnienie Biznesowe zostanie opracowane
w trakcie etapu inicjowania projektu.
• Dokonać przeglądu i zatwierdzić Plan Etapu ini-
cjowania. W tym celu na leży:
• zrozumieć wszelkie ryzyka, które mają
wpływ na decyzję o zezwoleniu na rozpoczę­
cie etapu inicjowania;
• pozyskać lub zaang ażować zasoby potrzebne
do realizacji Planu Etapu inicjowania;
• zapewnić, aby podczas etapu inicjowania
istniały odpowiednie mechanizmy raporto·
wania i kontroli oraz ustalić tolerancje dla
tego etapu.
• Poinformować wszystkich interesariuszy i jed-
nostki, w których siedzibach projekt będzie
realizowany, że zainicjowano projekt i wystąpić
o niezbędne wsparcie logistyczne (np. urządze­
nia do komunikacji, wyposażenie i ewentualne
wsparcie dla proj ektu), wystarczające dla etapu
inicjowania.
• Zezwolić Kierownikowi Projektu na przejście do
etapu inicjowania.
Tabela 13.1 przedstawia obowi ązki związane z tym
działaniem.
13.4.2 Zezwalanie na realizację projektu
Działanie to zostanie uruchomione na podstawie
wniosku Kierownika Projektu o zezwolenie na reali-
zację projektu i powinno być wykonywane równo-
legle z zatwierdzaniem Planu Etapu lub Planu Nad-
zwyczajnego (patrz sekcja 13.4.3).
Celem zezwolenia na realizację projektu jest podję­
cie decyzji, czy należy przystąpić do realizacji projek-
tu. Komitet Sterujący musi potwierdzić, że:
• istnieje wystarczające i odpowiednie
Uzasadnienie Biznesowe, które przedstawia
zasadny projekt;

Tabela 13.1 Zezwalanie na zainicjowanie projektu - obowiązki

Wytwórca - odpowiediialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c:
a.
E ..>< ar
·-c:
Cl)
....
O'l
o
.... ~
;::
o
Cl)
u
;::
....
:i
..><
QI
-:i
o
a. ....
:i
....
:i
..><
t:
o
"O

....
o.
Cl)
tir
N
u
..><
>'.. ....
Cl)
·~
o
....
o.
"'
QI
N
..><
QI
·~
QI
o
.... ...
:i
..><
·~
u c: •N "'
o ..>< ..><
·~
o
.... o. :i
Cl) :::> o ·-c: ·-c: o. "O
N
·-c:
"O
o >.
c:
>.
c: ::o ;:: .... ·-....uQI o
....
Cl)
;:: ;:: ;:: .... o
....
'0
N Cl)
o..
a. ·-"'a.
- -
QI "O
O'l •O
.... t:! '0 QI
·- QI
~
Cl)

Produkt Czynność o o. \.? \.? ~ ~ z o

Założenia Projektu Zatwierdzić (K) z z z (W) K A19
Plan Etapu inicjowania Zatwierdzić z z z (W) K A16
146 I Zarządzanie Strategiczne Projektem
ł ' k o zezwoIen1e
Wn1ose ' ' Zezwalanie na
'-"" realizację projektu _. realizację
Dziennik
Oołwiadczeń
Dokumentacja
lnkjowania Projektu
Plan
Przeglądu Korz~i
Rysunek 13.3 Zezwalanie na realizację projektu - schemat działania
• Plan Projektu jest wystarczający do zrealizowania
Uzasadnienia Biznesowego;
• strategie projektu i mechanizmy sterowania pro-
jektem wspierają realizację Planu Projektu;
• mechanizmy służące do mierzenia i przeglądu
oczekiwanych korzyści zostały ustalone i zapla -
nowane.
Jeżeli Komitet Sterujący nie zezwolił na realizację
projektu, wówczas powinien on zostać zamknięty
przedwcześnie (patrz Rozdział 18).
Komitet Sterujący może wyznaczyć Nadzór Projektu,
aby podjął niektóre czynności przeg lądu i oceny
(np. analiza Strategii Zarządzania Komunikacją
w celu potwierdzenia, że obejmuje ona wszystkich
interesa riuszy).
Rysun ek 13.3 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeg l ąd u i zatwierdzić Dokumentację
Inicjowania Projektu. W tym celu należy:
• potwierdzić, że definicja projektu jest dokład­
na i kompletna oraz że formuła realizacji pro-
jektu jest realizowalna;
• potwierdzi ć, że dokonano przeglądu
i uwzględniono doświadczenia z wcześniej ­
szych podobnych projektów;
• potwierdzić, że Strategia Zarządza n ia
Jakością j est wystarczająca do zapewnienia,
Dokumentacja
Z.atwiecdzil
Inicjowania Projektu
projektu
Zatwierdtil Plan
Przeglądu Korz~i
Powiadomienie
. o zezwoleniu na '
~ realizacl• orolektu
I
Przedwczesne '
zam knięci e
~'
że oczekiwania jakościowe zostaną spełnione,
i zatwierdzić ją;
• potwierdzi ć, że procedury określone
w Strategii Zarządzania Ryzykiem są wystar-
czające do utrzymania ryzyk pod kontrolą
i zatwierdzić ją. Potwierdzić, że przeprowa-
dzono przegląd ryzyk i że reakcje na ryzyko
zarówno w przypadku zagrożeń, jak i szans,
są właściwe i zaplanowane;
• potwierdzić, że Strategia Zarządzania
Konfiguracją przedstawia odpowiedni sposób
kontrolowania statusu (wersji i wariantów)
produktów projektu, i zatwierdzić ją;
• zapewnić, że potrzeby informacyjne interesa-
riuszy i terminy komunikowania się, określo­
ne w Strategii Zarządzania Komunikacją, są
odpowiednie i zatwierdzić ją;
• potwierdzić, że wszyscy człon kowie zespołu
zarządzania projektem zgodzili się na peł­
nienie swoich ról i uzgodnić zakres ewentu-
alnego delegowania uprawnień Komitetu
Sterującego (np. Obsłudze Zmian);
• zapewnić, że mechanizmy sterowania projek-
tem są odpowiednie dla specyfiki projektu;
• potwierdzi ć słuszność i rea lność Planu
Projektu (lącznie z wszelkimi kamieniami
milowymi i proponowanym podziałem na
etapy) i zatwierdzić go;
• dokonać przeglądu i zatwierdzić Opis(-y)
Produktu(-ów);
 Zarządzanie Stra tegiczne Projektem I 147

Tabela 13.2 Zezwalanie na reali zacj ę projektu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór >.
c
a.
E ~
... ..."'o
<I>-
..."'en
...
o
.,,.~
c
3:
o "'3:
u ~
::J

OJ
-
::J
o
a. ...
::J
...~
::J
"O
o..
..... ~
"'
·~
...
o "'
OJ
~ OJ
·~

...o ...
::J

"'u ·-uc ::>>. oo ·-

OJ
N t: o.. N ·~ ~
·~ ·N
~ ~ ...
o
o..
o.. ::J
"O
·-"'c 3:o >.
N "O
c
>.
c
c
3:
c
3:
...
·O
OJ
·o
... ...o..o
..."'en ... -3: 3: ...
o ...
o N
"'"'a.
Produkt Czynność
OJ
-o
-
·O
o o.. l!:l l!:l ·-
N
:.<: ·- OJ
:.<:
OJ
"O
z"' ~ o
"'
a.

Dziennik Doświadczeń Przejrzeć K K K (W) K A14

Dokumentacja Inicjowania Projektu Zatwi erdzi ć K z z z (W) K A20

Plan Przeg l ądu Korzyści Zatwi erd zi ć z z z z (W) K Al

• dokonać przeglądu tolerancji d la projektu, 13.4.3 Zezwalanie na realizację Planu

dostarczonych przez kierownictwo organizacji
lub programu, w celu zapewnienia, że są one
odpowiednie i rea listyczne;
• pozyskać lub zaangażować zasoby potrzebne
do realizacji projektu (będą one udostępniane
Kierownikowi Projektu etapami);
• potwierdzić propozycje dostosowania meto-
dyki zarządzania projektem stosowanej
w organizacji (programie) oraz wszelkie
dostosowania metodyki PRINCE2;
• sprawdzić, czy Uzasadnienie Biznesowe
przedstawia zasadny projekt i zatwierdzić j e.
• Dokonać przeglą du i zatwi erdz i ć Plan Przeglądu
Korzyści. Potwi erdzi ć, żeobejmuje on wszystkie
oczekiwane korzyści i spelnia potrzeby kierow-
nictwa firmy lub programu.
• Powiadomić kierownictwo organizacji lub pro-
g ramu oraz inne zainteresowane strony, że
zezwolono na rea lizację projektu.
• Udzielić Kierownikowi Projektu zezwolenia na
realizację projektu albo polecić Kierownikowi
Projektu, żeby zamknąl projekt przedwcześnie,
jeżel i Komitet Sterujący nie zezwoli! na kontynu-
owanie projektu.
Etapu lub Planu Nadzwyczajnego
Ważne jest, aby etap rozpocząć tylko wtedy, gdy
Komitet Sterujący uzna, że powinien się on zacząć.
Komitet Sterujący zatwierdza etap zarządczy,
dokonując przeglądu osiągnięć bieżącego etapu
i zatwierdzając Plan Etapu d la następnego etapu.
Zatwierdzanie Planów Etapów odbywa się na
za kończenie każdego etapu za rządczego z wyjąt­
kiem etapu ostatniego.
Jeżeliw trakcie etapu wystąpi sytuacja nadzwyczaj-
na, Komitet Sterujący może polecić Kierownikowi
Projektu sporządzeni e Planu Nadzwyczajnego,
który będz i e pod l egał zatwierdzeniu przez Komitet
Sterujący. Tylko sytuacje nadzwyczajne dotyczące
Planów Etapu lub Planów Projektu należy kierować
do zatwierdzenia na wyższym szczeblu. Odchylenia
od Planu Projektu mogą wymagać zatwierdzenia
przez kierownictwo firmy lub programu. Odchylenia
od Grupy Zadań są zarządzane przez Kierown ika
Projektu przy wykorzystaniu procesu Sterowanie
Etapem (patrz Rozdział 15). Jeżeli Plan Nadzwyczaj-
ny zostanie zatwierdzony, zastąpi on plan, które-
go dotyczą odchylenia i stanie się nowym planem
odniesienia.

Tabela 13.2 przedstawia obowiązki zwi ązane z tym Komitet Sterujący może wyznaczyć Nadzór Projektu,
działaniem. aby podjął niektóre czynności przeglądu i oceny
(np. analiza Planu Etapu w celu potwierdzenia, że
jest on wykonalny).
148 I Zarządzanie Strategiczne Projektem

Wnios-8
o z1~rdzenie Planu \
Zezwalanie na realizację
Planu Etapu lub Planu ............. Ootumtńto<j•
ln~łtlia Projektu
(j i uaktualniona)
NacłftAAH"„ain...,..... • Nadzwyczajnego

Wn10\ek
o zatwierdzenie
Planu Etarn1 ,' Z•lWl11•d1i( ~port Kollc:owy Etapu
(biet4cy etap)

Raport Kor\cowy Etapu

(biet ctcy etap)
Raport ()o~wlad<zeń
"01pows1ł<hnk Oelli pot„•bnyl

Rilpotl Ootwiadaeń
ljelto potoubny) r

...,,.....,_

--. -
I

z.te<onl• dziolMI
- - ....
„„~puy<h
'
' ~

-- --...
ljeltl poto•.00.)
„
I

""""""'
Plan Etapu
(na'>t ępny etap)

Pl.an Etapu
(na\tępny etap)
Z•twle1d1ie Plan Przeglądu Korzyici
(jetli uaktualniony)

Plan Nadz\vyuajny Zez:wolenie na

·( realitację etapu }
Pl<>n
Pn<glądu Kony;ci „( Pned\vaesne
zamknięcie I
Zezwolenie na
tealiza<Jt ~nu I
Dokumentacja Nadz ne o
Inicjowania P1o;ek1u

Rysunek 13.4 Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego - schemat działania

Rysunek 13.4 przedstawia elementy wejściowe i wyj- • j eżel i

podczas etapu nastąpiło częściowe
ściowe tego działania. przekazanie produktów, na l eży:
PRINCE2 zaleca wykonanie następujących czynności: • sprawdzić, czy przekazanie produktów
było zgodne ze Strategią Zarządzania
• Dokonać przeglądu i zatwierdzić Raport Konfiguracją, a w szczególności, czy ist-
Końcowy Etapu. W tym celu należy: nieje akceptacja użytkownika oraz akcep-
• ustalić dotychczasowe postępy projektu, tacja służb eksploatacji i utrzymania dla
prosząc Kierownika Projektu o wyjaśnienie każdego produktu;
wszelkich odchyleń od zatwierdzonych pla- • tam, gdzie jest to właściwe, zapewnić, że
nów i o dostarczenie prognozy wykonania wyn i kaj ące z tego zmiany biznesowe są
dla pozostałej części projektu; wspierane i t rwale;
• j eżel i będzie to wymagane, dokonać prze- • potwi e rdz i ć, kto powinien otrzymać
g l ądu Raportu Doświadczeń i uzgodn i ć, kto
i które z zaleconych działań następczych,
powinien go otrzymać. Zapewnić, aby odpo- jeśli takie będą zawarte w Raporcie
wiednie grupy (np. kierownictwo organizacji Końcowym Etapu, (w niektórych przy-
lub programu albo centrum doskonalości) padkach konieczne może być dokonanie
miały świadomość swojej odpowiedzialności
przeglądu szczegółowych zaleceń dla nie-
za wdrożenie ewentualnych zaleceń; których działań następczych) . Zapewni ć,
• sprawdzić zestawienie ryzyk w celu zapew- aby właściwe grupy (np. służby eksploata-
nienia, że narażenie na ryzyko jest nadal cji i utrzymania) miały świadomość swojej
akceptowalne i że reakcje na ryzyka, zarów- odpowi edzialności za wd rożenie ewentu-
no dla szans, jak i dla zagrożeń, są właściwe alnych za l eceń.
i zaplanowane;
 Zarząd zanie Strategiczne Projektem I 149

• Dokonać przeglądu Planu Etapu lub Planu
Nadzwyczajnego, o którego zatwierdzenie wnio·
skuje Kierownik Projektu. W tym celu naleźy:
• potwierdzi ć słuszność i moż l iwość rea lizacji
Planu Etapu/Planu Nadzwyczajnego;
• Podjąć jedną z trzech poniźszych decyzji doty-
czących:
• zatwierdzenia planu/planów i zezwolenia
Kierownikowi Proj ektu na rea l izację przed ło­
źonego(-ych) planu(-ów). W tym ce lu n ależy:

• do konać przegląd u i zatwierdzić wszelk ie • pozyskać lub zaangażowa ć zasoby

nowe Opisy Produktów;
• potwierdzić słuszność i moźliwość real izacji
Planu Projektu (w razie konieczności uzyskać
zatwierdzenie przez kierownictwo organiza -
cji lub programu);
• potwierdzić, źe strategie i mechanizmy stero-
wania projektem przedstawione w (zaktualizo-
wanej) Dokumentacji Inicjowania Projektu są
odpowiednie dla pozostałej części projektu;
• sprawdzić, czy (zaktualizowane) Uzasad-
nienie Biznesowe nadal przedstawia zasadny
projekt;
• dokonać przeglądu i zatwierdzić (zaktualizo·
wany) Plan Przeg lądu Korzyści w celu zapew-
nienia, źe wszelkie korzyści planowane do
osiągnięcia podczas następnego etapu będą
poddawane pomiarom i przeglądowi.
potrzebne do rea lizacji planu(-ów);
• usta l ić tolerancje dla zatwierdzanego
planu (dla ostatniego etapu Komitet
Sterujący powinien rozważyć, czy jakie-
kolwiek tolerancje pozostałe z poprzed-
nich etapów mogą być przydzielone do
planu, czy lepiej je zachować w rezerwie);
• polecenia Kierownikowi Proj ektu zmiany
odrzuconego planu, udzielając mu wskazó-
wek, jakie zmiany na l eży wprowadzić, aby
plan byl do zaakceptowania;
• polecenia Kierowni kowi Projekt u rozpoczęci a
przedwczesnego zamykania projektu.
• Poinformować kierownictwo organizacj i lub
programu o statusie projektu oraz informo-
wać inne zainteresowane strony na bieżąco

Tabela 13.3 Zezwalanie na rea lizację Planu Et apu lub Pl anu Nadzwyczaj nego - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór >.
c
Q.
E ~ Cl>-
..."'en ·-c
-
....:::i ::i
....::i t:
o
... ~ "'~
V ~
o
....
o ~ o ·-... "'
<li a. :::i ~ "O

·-...o ·-...o
<li
nr ~ o ~
....
:::i
Q..
-.. N
>. "'o
t: <li <li

·-"'
V
V
c ·N
::::> o
Q..
~
·-
N
~
·-
Q..
~
:::i
"O
·-"'c
N "O
o >.
c
>.
c
c
~
c
3:
... ·-...
Q..

•O
<li
V ...o
Q..
3: ...o ...o
..."' ~ ~ N
"'a.
- - ·-"'a.
<li "O
o
Cl
...
N •O
\!)
•O
\!)
<li
~ ~
<li
·- z"' 3 o
Czy nność
Q..
Produkt
Potwierdzić
Produkty specj alistyczne zatwierdzenie z z z (K) (W) (K)
Raport Końcowy Etapu Zatwi erdzi ć z z z (W) K A9
Raport Doświadczeń Rozpowszech nić z K K (W) K A15
Zalecenia działań następczych Rozpowszechnić z z z (W) K
Plan Etapu dla następnego etapu Zatwierdzić z z z (W) K A 16
Plan Nadzwyczajny Zatwierdzić z z z (W) K A 16
(Uaktualniona) Dokumentacja
Inicjowania Projektu
Zatwierdzić (K) z z z (W) K A20

(Uaktualniony) Plan Przeg lądu Korzyści Zatwierdzić z z K K (W) K A1

150 I Zarządzanie Strategiczne Projektem

r
I
Prołba Kierownika ' Podejmowanie Pro!ba Komitetu
Projektu o wytyane decyzji dorainej ·I
" SteruJ•cego o wytyczne I
"
r '
Zgłoszona sytuacja wytyczne
I I
"
nadzwyczajna
• "~ Komitetu Sterujęcego

•I Pole<enie sporzędzenia' I
Wytyane organizacjo ' " Planu Nadzwyczajnego •
I decyzje ,

r
. Przedwcze5ne '
Raport Okresowy
zamknięcie ,I
"
Zgłolll Nowe
zagadnienie
')
Raport Nadzwyczajny '

Raport o Zagadnieniu

Rysunek 13.5 Podejmowanie decyzji doraźnej- schemat działania

o postępach projektu (zgodnie ze Strategią • reakcja na zmiany składu Komitetu Sterującego

Zarządzania Komunikacją) .
Tabela 13.3 przedstawia obowiązki związane z tym
dzialaniem.
13.4.4 Podejmowanie decyzji doraźnej
Członkowie Komitetu Sterującego mogą przekazy-
wać nieformalne wskazówki lub formalnie odpo-
wiadać na prośby o wytyczne w dowolnym czasie
w trakcie projektu. Potrzeba częstych konsultacji
pomiędzy Kierownikiem Projektu a Komitetem Ste-
rującym będzie zachodzić szczególnie na etapie ini-
cjowania projektu oraz pod koniec każdego etapu.
Decyzje doraźne mogą być podejmowane zbiorowo
lub przez poszczególnych czlonków Komitetu Ste-
rującego. Istnieje szereg okol i czności, które mogą
wymagać pojęci a decyzji doraźnej , na przykład:
• odpowiedzi na wnioski (np. gdy trzeba wyj aśn i ć
opcje lub rozwiązać sytuacje konfliktowe);
• reakcja na raporty (np. Raport Okresowy, Raport
Nadzwyczajny, Raport o Zagadnieniu);
• reakcja na wpływy zewnętrzne (np. zmiany prio-
rytetów organizacji);
• indywidualne obawy członków Komitetu
Sterującego;
(może to wymagać także zatwierdzenia na
poziomie organizacji lub programu).
Jest również możliwe, że kierownictwo organizacji
lub programu zrewiduje zlecenie przygotowania
projektu w odpowiedzi na zdarzenia zewnętrzne
wobec projektu lub poinstruuje Komitet Sterujący,
aby zamknął projekt. Komitet Sterujący ma dwie
podstawowe opcje, jeżeli kierownictwo organizacji
lub programu zdecyduje się zmienić zlecenie przy-
gotowania projektu:
• potraktować to jako wniosek o wprowadzenie
zmiany (patrz Rozdzial 9), po l ecając Kierowni -
kowi Projektu ponowne zaplanowanie etapu
i/lub projektu;
• zamknąć projekt przez uruchomienie przedwcze-
snego zamkn i ęcia (patrz Rozdział 18), a następ­
nie ponownie go rozpocząć. Może to spowodo-
wać większe koszty w porównaniu z opcją doty-
czącą wniosku o wprowadzenie zmiany.
Komitet Sterujący może wyznaczyć Nadzór Projektu,
aby podjął niektóre czynności przeglądu i oceny
(np. analiza wniosku o wprowadzenie zmiany w celu
potwierdzenia, że przeprowadzono odpowiednią
analizę wpływu tej zmiany). Przy podejmowaniu
decyzji ważne jest, aby rozważyć ich wpływ na
 Zarządzanie Strategiczne Projektem I 151

wszystkich interesariuszy (zidentyfikowanych w Stra- • odstępstwa: zatwierdzić ustępstwo,

tegii Zarządzani a Komun ikacją).
Rysunek 13.5 przedstawia elementy wejści owe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• W odpowiedzi na nieformalne prośby o radę
i wytyczne:
• zwrócić się o wytyczne do kierownictwa orga-
nizacji lub programu, j eżel i to konieczne;
• udziel ić Kierownikowi Proj ektu pomo-
cy w razie potrzeby (może to obejmować
również zwrócenie się do Kierownika
Projektu z poleceniem sporządzenia
Raportu o Zagadnieniu i/lub Raportu
Nadzwyczajnego).
• W odpowiedzi na Raport o Zagadnieniu prze-
kazany na wyższy szczebel zarządzania (patrz
Rozdział 9):
• zwrócić się o wytyczne do kierownictwa orga-
nizacji lub programu, jeżeli to konieczne;
• podjąć decyzję w granicach upoważnie­
nia udzielonego Komitetowi Sterującemu .
Decyzja ta może dotyczyć:
• problemu/obawy: poprosić o Plan
Nadzwyczajny lub przekazać wytyczne;
• wniosku o wprowadzenie zmiany:
zatwierdzić, odroczyć, odrzucić lub popro-
sić o więcej informacji. Rozważyć, czy
wymagany jest Plan Nadzwyczajny;
odroczyć, od rzucić lub poprosi ć o więcej
informacji. Rozważyć, czy jest wymagany
Raport Nadzwyczajny.
• W odpowiedzi na Raport Nadzwyczajny (patrz
Rozdział 1O):
• zwrócić się o wytyczne do kierownictwa orga-
nizacji lub programu, jeżeli to konieczne;
• podjąć decyzj ę w granicach upoważn i e­
nia udzielonego Komitetowi Sterującemu.
Możl iwe decyzj e to:
• poszerzyć tolerancje etapu, których prze-
kroczenie jest przewidywane;
• polecić Kierownikowi Projektu sporządze­
nie Planu Nadzwyczajnego (określając, co
będzie możliwe do zaakceptowania);
• polecić Kierownikowi Projektu, aby
zamkną ł projekt przedwcześn i e;
• odroczyć rozpatrzenie sytuacji nadzwy-
czajnej na czas określony. Ta reakcja jest
przydatna w przypadku niskiego poziomu
zaufania co do prognozy (że tolerancje
zostaną przekroczone) lub jeżeli sytuacja
nadzwyczajna dotyczy wystąpienia ryzyka,
dla którego utworzono reze rwę na wypa-
dek, gdyby się zmateria l i zowało.
• W odpowiedzi na otrzymanie Raportu Okreso-
wego (patrz Rozdział 1O):
• dokonać przeglądu Raportu Okresowego
w celu ustalenia statusu projektu;

Tabela 13.4 Podejmowanie decyzji dora źnej - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
>-
Zatwierdzający - potwierdza odbiór c
a.
E -""
·- .,.Cl>'
.....
11)
.....
Ol
o
..... ~
~
o
c 11)
V
~
::i
.....
-""
QJ
·~
o
-
::::J
o
a. ~
::::J
....
::::J
-""
QJ
o
-o
a..
-. nr ~
1.;'.,
11)
..... ..... "'
QJ QJ
·~
o ....
::::J

·-ctl
11) V> a.. N ·~ ..... -""
· ~
u ·N o -"" -""
o
..... a.. ::::J
11)
-o :::> o ·- ·- a.. QJ -o
·-c
N
o c>- >-
c
c
~
c
~
.....
•O
·-.....
V
o
.....
a..
~ o o 11)
11)
~ ~ ..... ..... N
a.
-'° -
V>
Ol
.....
QJ
N •O QJ QJ -o V> a.
..... 11)

Produkt Czynność o a.. C) C) ~ ~ z $ o

Raport Okresowy Skontrolować K K K (W) K A11

Raport Nadzwyczajny Odpowiedzieć K K K (W) K A10

Nowe zagadnienie Zgłosić w w w w
152 I Zarządzanie Strategiczne Projektem
• upewnić się, że projekt nadal dąży do do
realizacji ustanowionych celów organizacji
lub programu i jest nadal zasadny zgodnie
z jego Uzasadnieniem Biznesowym;
• upewnić się, że postępy etapu są zgodne
z planem;
• informować na bieżąco kierownictwo orga-
nizacji lub programu oraz inne zaintereso-
wane strony o postępach projektu, zgodnie
ze Strategią Zarządzania Komunikacją;
• podjąć niezbędne dzialania. Dla przykladu:
polecić Kierownikowi Projektu sporządze­
nie Raportu o Zagadnieniu i/lub Raportu
Nadzwyczajnego.
• W odpowiedzi na wytyczne i decyzje kierownic-
twa organizacji lub programu:
• zapewnić, żeby zespól zarzą d za nia projek-
tem byl informowany na bieżąco o zdarze-
niach zewn ętrznych, jakie mogą mieć na
niego wplyw (dla przykladu: informowa-
nie Kierownika Projektu o zmianie skladu
Komitetu Sterującego);
• zawiadomić Kierownika Projektu o wszel-
kich zmianach w środowisku organizacji lub
programu, które mogą wplynąć na projekt
i zapewnić podjęcie wlaściwych czynności.
Mogą one obejmować:
• zgloszenie zagadnienia Kierownikowi
Projektu;
• polecenie Kierownikowi Projektu sporzą­
dzenia Plan Nadzwyczajnego;
• polecenie Kierownikowi Projektu przed-
wczesnego zamknięcia projektu.
Tabela 13.4 przedstawia obowiązki zwi ązane z tym
działaniem.
13.4.5 Zezwalanie na zamknięcie projektu
Kontrolowane zamkni ęci e proj ektu jest równ ie
ważne, jak jego kontrolowane rozpoczęcie. Musi ist-
nieć punkt, w którym cele określone w pierwotnych
i aktualnych wersjach Dokumentacji Inicjowania
Projektu oraz Planu Projektu będą ocenione w celu
ustalenia:
• czy cele zostały osiągn i ęte;
• jak daleko projekt odbiega od swych pierwot-
nych zalożeń;
• czy w projekcie nie trzeba czegoś jeszcze
wykonać.
Bez takiego podejścia projekt może się nigdy nie
skończyć; projekt może przeksztalcić się w zwykłą
dzialalność biznesową i pierwotna koncentracja na
korzyściach zostanie zaprzepaszc.zona.
Zezwolenie na zamknięcieprojektu jest ostatnią
czynnością wykonywaną przez Komitet Steru-
jący przed jego rozwiązaniem i może wymagać
zatwierdzenia przez kierownictwo organizacji lub
programu.
Komitet Sterujący może wyznaczyć Nadzór Projek-
tu, aby podjął niektóre c.zynności przeg l ądu i oceny
(np. analiza Raportu Końcowego Projektu w celu
potwierdzenia, że jest on prawidłowy).
Rysunek 13.6 przedstawia elementy wejściowe i wyj-
ściowe tego dzialania.
PRINCE2 zaleca wykonanie następujących czyn ności:
• Dokonać przeglądu pierwotnej i aktualnej wersji
Dokumentacji Inicjowania Projektu w celu zapo-
znania si ę z pierwotnie ustalonym poziomem
odniesienia dla projektu oraz aktualnymi strate-
giami i mechanizmami sterowania.
• Dokonać przeglądu i zatwierdzić Raport
Końcowy Projektu w celu:
• ustalenia faktycznego wykonania projektu
w porównaniu z jego pierwotnymi zaloże­
niami, wraz z podsumowaniem ewentual-
nych odchyleń od zatwierdzonych planów;
• potwierdzić, kto powinien otrzymać zalece-
nia działań następczych zawarte w Raporcie
Końcowym Projektu i które (w niektórych
przypadkach może okazać się konieczne
dokonanie przeglądu szczególowego zale-
cenia dla niektórych dzia lań następczych).
Zapewnić, że właściwe grupy (dla przykładu
służby eksploatacji i utrzymania) mają świa­
domość swojej odpowiedzialności za wdro-
żenie wszelkich zaleconych czynności;
• dokonać przeglądu Raportu Doświadczeń
i uzgodnić, kto powinien go otrzymać.
Zapewnić, że wlaściwe grupy (na przyklad
kierownictwo organizacji lub programu albo
centrum doskonałości) mają świ adomość
swojej odpowi edzialności za wdrożen i e
wszelkich zaleconych czynności;
• zweryfikować, czy przekazanie produk-
tów projektu bylo zgodne ze Strategią
Zarządzania Konfiguracją, a w szczególności,
czy istnieje akceptacja użytkownika oraz
akceptacja slużb eksploatacji i utrzymania
 Zarządza nie Strategiczne Projektem I 153

~ Rtkomtndo<i>
z•mknię<i.a ptojitktu
Zetwalanie na
zamknięcie projektu
........... Raport Końcowy
Projektu

Dokumentacja
Inicjowania Projektu Raport Oo!wiadczeń

(Uaktualnione) r -
Uzasadnienie! I Zalecenia d ziałań '
Biznesowe I nast ępCZyeh I
... - „ „ •
- Raport Końcowy
Projektu ~drl(
(Vaktua noone)
Uzasadnienie
Biznesowe

Raport
Dołwiackzcń l•MWt"dtl(
Plan Przeglądu
KorzySci
Ue!li uaktualniony)
r - - - -•
I Zale<enia dziDlań

- - -...
I następczych I Powiadomienie

' „ o t~n1ykanh..1 projektu

~
•
Plan Przeg l ądu
KorzyS<i

Rysunek 13.6 Zezwalanie na zamknięcie projektu - schemat działania

dla każdego
produktu. Tam, gdzie jest to • Dokonać przeglądu i rozpowszechnić powia-
właściwe, zapewnić, aby zmiany w biznesie domienie o zamykaniu projektu, zgodnie ze
wynikające z przekazania produktów byly Strategią Zarządzania Komunikacją. Komitet
wspierane i trwałe. Sterujący powiadamia tych, którzy udostępnili
projektowi wspierającą infrastrukturę i zaso-
• Zapewn i ć, że przegląd korzyścipoprojektowych
by, że teraz można j e wycofać z projektu.
obejmuje efektywność produktów projektu
Powiadomienie powinno wskazywać ostatecz-
w u żytkowaniu operacyjnym w celu przeana·
ny termin rozliczenia kosztów obciążających
lizowania, czy wystąpi ly j akieś efekty uboczne
projekt.
(korzystne lub niekorzystne).
• Dokonać przeglądu i uzyskać zatwierdzenie Tabela 13.5 przedstawia obowiązk i związane z tym
zaktualizowanego Planu Przeglądu Korzyści, działaniem .
zapewniając, że uwzględnia on te oczekiwane
korzyści, które nie mogą jeszcze być potwier-
dzone. Ponieważ Plan Przeglądu Korzyści obej·
muje wykorzystanie zasobów wykraczające
poza cykl życia projektu, odpowiedzialność za
ten plan powinna być przekazana kierownictwu
organizacji lub programu.
• Potw i e rd zić zaktualizowane Uzasadnienie
Biznesowe przez porównanie faktycznych
i przewidywanych korzyści, kosztów i ryzyk
z pierwotnym Uzasadnieniem Biznesowym,
które zostało wykorzystane do uzasadnienia
projektu (potwierdzenie uzyskania wszystkich
korzyści może być niemożliwe, ponieważ nie·
które z nich zostaną zrealizowane dopiero po
zamknięciu projektu).
154 I Zarządzanie Strategiczne Projektem

Tabela 13.5 Zezwalanie na zamknięcie projektu - obowiązki

Wytwórca - odpowiedzialny za wytworzen ie produktu

Kontroler - najlepiej niezależny od wytwórcy

Zatwierdzaj ący - potwierdza odbiór

>-
c:
a.
E .:,/.
....Cli-
11)
.....
CJ)
o
..... ~
c:
so 11)
V
s
....
:::J
.:,/.
QJ
·~
o
-o
:::J

a. ....
:::J
....:::J
.:,/.
QJ
"'
o
-o
a..
to
w
N
.:,/.
>. ....
11)
.....
a..
"'
N
QJ
.:,/.
QJ ·~
o..... ....:::J
.:,/.
·~
V
c:
·N "'
o .:,/. .:,/.
·~
o
..... a.. :::J
V
11)
-o ::> o ·-
c: ·-c: a.. QJ -o
o
N ..... ·-
·-
c: o
s
>-
c: >-
c: s s ·O
V
..... .....
a..
11)
s s o
..... o
..... N 11)
a. ·-
- - -o "'
QJ
CJ) •O •O
..... QJ QJ
·-~ a.
5"'
N 11)
.....
Produkt Czynn ość o a.. I..? I..? ~ z o
Raport Końcowy Proj ektu Zatwi erdzi ć z z z (W) K AS

Raport Doświadczeń Rozpowszechnić z z z (W) K A15

Zalecenia dzialań następczych Rozpowszechn ić z z z (W) K

(Uaktualnione) Uzasadnienie Biznesowe Potwi erdzi ć K z K K (W) K A2

(Uakt ualniony) Plan Przeg lądu Korzyści Zatwi erdzi ć z z K K (W) K A1

\
14 Inicjowanie Projektu

14.1 PRZEZNACZENIE
Proces Inicjowanie Projektu służy do stworzenia
solidnych podstaw dla projektu, co pozwala organi-
zacji, jeszcze przed zaangażowaniem się w znaczne
wydatki, zrozumieć jakie prace należy wykonać
w celu dostarczenia produktów projektu.
14.2 CEL
Celem procesu Inicjowanie Projektu jest zapewnie-
nie jednakowego rozumienia następujących kwestii:
• Powody rea lizacji projektu, oczekiwane
i związane z tym ryzyka.
• Zakres prac, które mają być wykonane oraz pro-
dukty, które mają być dostarczone.
• Jak, kiedy i jakim kosztem będą dostarczone pro-
dukty projektu?
• Kto ma być zaangażowany w podejmowanie
decyzji w projekcie?
• Jak będzie osiągnięta wymagana ja kość?
• Jak będą ustalane i kontrolowane obiekty odnie-
sienia?
• Jak będą identyfikowane, oceniane i kontrolo-
wane ryzyka, zagadnienia i zmiany?
korzyści • Jak będą monitorowane i kontrolowane postępy?
• Kogo należy informować, w jakiej formie
i w jakim terminie?

Zarządzanie Strategiczne Projektem

lf'~N

:•~""'·
... ttcu )
'
I ----------------------------------------------~
I
I
I

' ()p<acowanie
''
Op<a<owanie Strategii ()p<acowanie Strategii
Strategii Zanądzania
Zarządzania Ryzykiem Zar:<1dzania Jakokią
'' Konfigura<ją

'
''
'
'' Opracowanie
Strategii Zarządzania
I ' Komunikacją
I
I

'
Ustanowienie
Sporządzanie
mechanizmów Planu Projektu
stetowania pcojektem
I I

Doprecyzowanie
Uzasadnienia
Biznesowego

Zestawianie
"":J
Inicjowanie .r WnWk
Dokumentacji o lłl:'!!'~
\.i C'.t!ll.C
Projektu Inicjowania Projektu ' o tkt

___ ___,' I
------------·---- -- --- - - · --------------
Zb!l.ł•J,.cv "' Zarządzanie Końcem
l.ontte •tłJl'I Etapu

Rysunek 14.1 Diagram procesu Inicjowanie Projektu

158 I Inicjowanie Projektu
• W jaki sposób metoda zarządzania projektem
stosowana przez organizację lub program zosta-
nie dostosowana do projektu?
14.3 KONTEKST
Inicjowanie Projektu ma na celu stworzenie podstaw
dla pomyślnego zrealizowania projektu. W szcze-
gólności wszystkie strony, aby mogły się prawdziwie
zaangażować w projekt, muszą mieć jasne wyobra-
żenie tego, co zamierza się osiągnąć w projekcie,
dlaczego jest to potrzebne, jak ten rezultat ma być
osiągnięty oraz jakie są ich obowiązki.
Proces Inicjowanie Projektu umożliwia Komitetowi
Sterującemu podjąć decyzję w procesie Zarządza­
nie Strategiczne Projektem (patrz Rozdział 13), czy
projekt jest, czy nie jest zgodny z celami organizacji
lub programu, j eszcze przed zezwoleniem na jego
kontynu ację.
Jeżeli natomiast organizacja przejdzie bezpośredn i o
od Przygotowania Projektu (patrz Rozdział 12) do
Sterowania Etapem (patrz Rozdział 1S), wówczas
może być zmuszona do zaangażowania w projekt
znacznych zasobów finansowych bez pełnego zrozu-
mienia, w jaki sposób zostaną osiągnięte cele projek-
tu. Bez dokladnej definicji projektu Komitet Sterujący
będzie w sytuacji wykonywania skoku w nieznane.
Wszystkie działania podejmowane w procesie Inicjo-
wanie Projektu wymagają głębszego rozważenia,
jeżeli relacja pomiędzy klientem a dostawcą ma
charakter komercyjny (na przykład: przyczyny pod-
jęcia realizacji projektu, określone w Uzasadnieniu
Biznesowym dostawcy, mogą się różnić od tych zde-
fin iowanych w Uzasadnieniu Biznesowym klienta) -
patrz Rozdział 19, który zawiera więcej szczegółów.
W trakcie procesu Inicjowanie Projektu Kierow-
nik Projektu będzie tworzyć zestaw produktów
zarządczych niezbędnych d la zapewnienia pozio-
mu kont roli określonego przez Komitet Steruj ący.
Kierownik Projektu powinien wcześniej u zgodnić
(w ramach Planu Etapu inicjowania) sposób, w jaki
Komitet Sterujący będzie dokonywać przeglądu
i zatwierdzać produkty zarządcze - dwa możl iwe
skrajne przypadki to zatwierdzanie każdego z osob-
na łub wszystkich razem.
14.4 DZIAŁANIA
Działaniaw procesie Inicjowanie Projektu są reali-
zowane głównie przez Kierownika Projektu i w ich
ramach należy:
• Opracować Strategię Zarządzania Ryzykiem.
• Opracować Strategię Zarządzania Konfiguracją.
• Opracować Strategię Zarządzania Jakością .
• Opracować Strategię Zarządzania Komunikacją.
• Ustanowić mechanizmy sterowania projektem.
• Sporządzić Plan Projektu.
• Doprecyzować Uzasadnienie Biznesowe.
• Zestawić Dokumentację Inicjowania Projektu.
Działania, mające na celu ustalenie poszczególnych
strategii dla projektu, mogą być wykonywane rów-
nolegle, z tym że zaleca się. żeby Strategia Zarzą­
dzania Komunikacją została ukończona jako ostat-
nia, poni eważ będzie musiala obejmować wszelką
komunikację wymaganą przez pozostałe strategie.
Strategie projektu wywodzą się ze strategii, stan-
dardów lub praktyk organizacji i/lub programu,
z którymi projekt musi być zgodny oraz z oczekiwań
jakościowych klienta, przedstawionych w Opisie
Produktu Końcowego Projektu. Po zdefiniowaniu
strategii projektu, można ustalić właściwe dla nich
mechanizmy sterowania projektem i stworzyć Plan
Projektu. Są to dzialania prowadzone równolegle
i mają charakter iteracyjny, jako że:
• stosowanie każdego mechanizmu sterowania
wymaga czasu i zasobów, co musi być udoku-
mentowane w Planie Projektu;
• w miarę identyfikowania w Planie Projektu pro-
duktów i działań, mogą być potrzebne dodatko-
we mechanizmy sterowania.
Po ustaleniu mechanizmów sterowania i sporządze­
niu Planu Projektu, możliwe jest dokończenie Uza-
sadnienia Biznesowego, ponieważ przewidywane
nakłady czasu i kosztów na wytworzenie produktów
projektu i zarządzanie projektem będą wówczas
w pełni zrozumiale.
Ostatnim działanie m w procesie Inicjowanie Projek-
tu jest zestawienie Dokumentacji Inicjowania Projek-
tu. Jest to zebranie ca łej dokumentacji opracowanej
w t rakcie inicjowania projektu, która zostanie wyko-
rzystana do uzyskania zgody Komitetu Sterującego
na kontynuacj ę projektu.
14.4.1 Opracowanie Strategii Zarządzania
Ryzykiem
Strategia Zarządzania Ryzykiem opisuje cele zarzą ­
dzania ryzykiem, procedurę, która będzie przyjęta,
role i obowiązki, tolerancje ryzyka, terminy działań
dotyczących zarządzania ryzykiem, narzędzia i tech-
 Inicjowanie Projektu I 159

Dokumentacja
Z~zwole1llt n• Opracowanie Strategii Inicjowania Projekt\1
1
.calnlciowanie projektu Zarządzania Ryzykiem (<zęś"'
~

-
Załotenia Projektu
Oprkow.K Strategia Zarządzania
Ryzykiem

,...,,.
..__ l wypt'łni(
Rejeslr Ryzyk
Dziennik Doświadczeń

- Dziennik Projektu

Rysunek 14.2 Opracowanie Strategii Zarządzania Ryzykiem - schemat działania

niki, które będą wykorzystane, a także wymagania tów od k ierownictwa o rganizacji lub prog ramu
dotyczące raportowania. oraz od organizacj i zewnętrznych. Niektóre
z tych doświ adczeń mogą być już wcześniej
Więcej szczegółów na temat zarządzania ryzykiem
zarejestrowane w Dzienniku Doświadczeń.
można znaleźć w Rozdziale 8.
• Dokonać przeglądu Dziennika Projektu pod
Rysunek 14.2 przedstawia elementy wejściowe i wyj- kątem ryzyk i zagadnień związanych z zarządza­
ściowe tego dzialania. niem ryzykiem.
PRINCE2 zaleca wykonanie następujących czynności : • Zdefi niować Strateg i ę Za rządzan i a Ryzykiem,
aw szczegó l n ości u sta l ić:
• Dokonać przeg l ądu Zalożeń Projektu w celu
• procedurę zarządzan i a ryzykiem (np.
ustalenia, czy i które strategie, standardy lub
Identyfikowanie, Ocenianie, Planowanie,
praktyki zarządcze organizacji lub programu,
Wdrożenie, Komunikowanie);
dotyczące zarządzania ryzykiem, powinny być
• narzędzia i techniki, które będą wykorzystane;
zastosowane w projekcie.
• Pozyskać doświ adczenia dotyczące zarządzania • zapisy, które będą prowadzone;
ryzykiem z wcześniejszych podobnych proj ek-

Tabela 14.1 Opracow anie Strategii Za rządza ni a Ryzyki em - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzaj ący - potwierdza odbiór
>-
c
a.
E ~
....QI<
·-c
....
"'Ol
o
.... ~
,,,. o "';:
;: u
....
~
:i
-:i
o
·-....o "'
....Qj
a. :i
....:i
~
"'
o
"O
ll.
-...
>-
~
"'
t;
·- ·-
o
....
Qj
~
Qj
Qj
....
:i

·-"'"'u ·-c :::>>- oo>- ·-c ·-c ........o ·-

N N ll. ~
u
•N ~ ~ ll. :i
ll. Qj "O
N
o
"O o
....
c ;: c c ;: ;: ·O .... V
ll.
o o
"'....Ol .... -·O;: -;: .... "' N
Qj
·O
.... a. "O ·-
"'
N
·- z"' 5"'Qj Qj a.
Produkt Czynn ość o ll. 1.9 1.9 ~ ~ o
Strategia Zarządzan i a Ryzykiem Opracować (Z) (Z) (Z) w K A 24

Rejestr Ryzyk Założyć i wypelnić z K w A25

160 I Inicjowanie Projektu

• sposób raportowania efektywności procedu- również, że Komitet Sterujący zechce dokonać

ry zarządzania ryzykiem;
• terminy dzialań dotyczących zarządzania
ryzykiem;
• role i obowiązki dla dzialań dotyczących
zarządzania ryzykiem;
• skale, które mają być wykorzystane do osza-
cowania prawdopodobieństwa wystąpienia
ryzyka oraz jego wplywu;
• wskazówki dotyczące sposobu oceny blisko-
ści ryzyk;
• definicje kategorii ryzyka, jakie mają być sto-
sowane;
• wykorzystywane sygnaly wczesnego ostrze-
.
gania;
• tolerancje dotyczące ryzyka;
• czy zostanie utworzony budżet ryzyka, a j eśli
tak, to w j aki sposób będzie kontrolowany.
• Skonsultować się z Nadzorem Projektu w celu
sprawdzenia, czy proponowana Strategia
Zarządzania Ryzykiem zaspokaja potrzeby
Komitetu Sterującego i/lub kierownictwa organi-
zacji lub programu.
• Zalożyć Rejestr Ryzyk zgodnie ze Strategią
Zarządzania Ryzykiem i wypelnić go wszelkimi
ryzykami z Dziennika Projektu.
• Wystąpić do Komitetu Sterującego o zatwierdze-
nie Strategii Zarządzania Ryzykiem (możliwe jest
jej przeglądu później, jako części Dokumentacji
Inicjowania Projektu).
Tabela 14.1 przedstawia obowiązki związane z tym
dzialaniem.
14.4.2 Opracowanie Strategii Zarządzania
Konfiguracją
Zarządzanie konfiguracją jest niezbędne dla każ­
dego projektu w celu utrzymania kontroli nad jego
produktami zarządczymi i specjalistycznymi.
Wymagany poziom kontroli będzie si ę różn i ć dla
poszczególnych projektów. Maksymalny możl iwy
poziom kontroli jest wyznaczany przez podzial
produktów projektu aż do osiągnięci a poziomu, na
którym dany element produktu może być nieza l eż­
nie zainstalowany, wymieniony lub zmodyfikowany.
J ednakże na faktyczn ie realizowany poziom kont roli
będ zie wplywać znaczenie projektu oraz zlożoność
relacji pom i ędzy jego produktami.
W trakcie tego działania stworzony zostanie wstęp­
ny zbiór Zapisów Obiektów Konfiguracji. Strategia
Zarządzania Konfiguracją będzie określ ala format
i zawartość zapisów, które należy prowadzić (patrz
Dodatek A).
Więcej szczególów na temat zarządzania konfigura-
cją można znaleźć w Rozdziale 9.

Dokumentacja
( Zt~nltn• ", Opracowanie Strategii Inicjowania Projektu
uinl<iow•nie pro)cktv , Zarządzania Konfiguracią (<:

Strategia
Zalo1:enia Projektu Zarządzania
Konfiguracia

r
I Struktura zespołu I'
Dziennik Do~wiadczc1\
11--.,.
Unklu~kl&(

.......
1 zarządzania projektem
,,.
„ - „
r

-. -....
u11ktu111n1< I Opisy ról I
+1
Rejestr Ryzyk
„ - „
Vtwwl)'( Zapisy
Obiektu Konfiguracji

Dziennik Projektu
,_
l wypc411it.
Rejestr zagadnień

Rysunek 14.3 Opracowanie Strategii Zarządzania Konfiguracją - schemat działania

 Inicjow anie Projektu I 161

Rysunek 14.3 przedstawia elementy wejściowe i wyj-
ściowe tego działa ni a.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeg l ądu Zalożeń Projektu w celu
ustalenia, czy strategie, standardy lub praktyki
zarządcze organizacji lub programu, dotyczące
zarządzania konfiguracją, powinny być zastoso-
wane (w szczególności czy klient i/lub dostawca
posiada istniej ący system za rządzania konfigura -
cją, który na l eży zastosować) .
• Pozyskać doświadczen i a dotyczące zarządzan i a
konfiguracją z wcześniejszych podobnych pro-
• sposób raportowania efektywności procedur;
• terminy dziala ń dotyczących zarządza n ia
k onfi guracją o raz dzialań dotyczących stero-
wania zagadnieniami i zmianami;
• role i obowiązki dla tych procedur. Należy
rozważyć, czy powinna zostać powołana
rola Obsługa Zmian i/lub utworzony budżet
zmian;
• skale dla wagi i priorytetu zagadnień.
• Skonsultować się z Nadzorem Projektu w celu
sprawdzenia, czy proponowana Strategia
Zarządzania Konfiguracją zaspokaja potrzeby

jektów od kierownictwa organizacji lub progra -
mu oraz od organizacji zewnętrznych. Niektóre
z tych doświadczeń mogą być już wcześniej zare-
jestrowane w Dzienniku Doświ adczeń.
• Dokonać przeglądu Rejestru Ryzyk i Dziennika
Projektu pod kątem ryzyka i zagadn i eń związa­
nych z zarządzaniem konfiguracją.
• Określić Strategię Zarządzania Konfiguracją,
a w szczególności ustalić:
• procedurę zarządzania konfiguracją (np. pla-
nowanie, identyfikowanie, sterowanie, charak-
Komitetu Sterującego i/lub kierownictwa organi-
zacji lub programu.
• Utworzyć wstępne Zapisy Obiektów Konfiguracji
(w tym momencie będą istnialy tylko Zapisy
Obiektów Konfiguracji dla produktów zarząd­
czych, które zostaly już utworzone oraz dla istnie-
jącej wcześniej doku mentacji projektu, którą nale-
ży sterować i poddać kontroli, np. studium wyko-
nalności, zaproszenie do zlożenia oferty itp.).
• Zalożyć Rejestr Zagadnień i rozważyć, czy
jakieś zagadnienia zarejestrowane uprzednio

teryzowanie statusu, weryfikowanie i audyt); w Dzienniku Projektu muszą być formalnie

zarządzane i w zwi ązku z tym przeniesione do
• p rocedu rę dotyczącą sterowania zagadnie-
tego rej estru.
niami i zmianami (np. rejestrowanie, ana-
lizowanie, proponowanie, decydowanie, • W przypadku zidentyfikowania nowych ryzyk
wdrażanie);
lub zagadnień (lub zmiany istniejących), nale-
ży dokonać aktualizacji Rejestru Ryzyk, Rejestru
• narzędzia i techniki, które będą wykorzystane;
Zagadnień i/lub Dziennika Projektu.
• zapisy, które będą prowadzone;

Tabela 14.2 Opracowanie Strategii Zarządzania Konfig uracją - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler- najlepiej niezależny od wytwórcy
>.
Zatwierdzający - potwierdza odbiór c
a.
E -""
·-c ... ....,,
Cl>-
ro
-.,,a.
:;)
..... ro :J :J
en ~ u -"" o ..... o
-o
o
..... ~ o ~
QI :J
..... -""
o..
..._ ro- -""
>-
ro
t;;
·~
o
..... QI
-""
QI
QI
·~
o
....
...
:J

·-ctl
ro o.. N ·~ -""
·~ •N o -""
o
..... o.. :J
V
ro ::> o ·- -""
·- o.. -o
N -o c c .....
QI
·- o
c o >.
c
>.
c ~ ~ ·O
V
..... .....
o..
ro ~ o o .,,
~ ~ .,,"'a.
N
..... .....

Produkt Czynność
en
.....
o
QI
N
.....
o.. - -
·O
ID
-o
ID
QI
·-
:..,:
QI
·-:..,:
-o
z"' s o
a.

Strategia Zarządzan i a Konfi guracją Opracować (Z) (Z) (Z) w K A6

(Początkowe) Zapisy Obiektu Konfiguracji Utworzyć z K w AS

Rejestr Zagadnień Zalożyć i wypełnić z K w A12

162 I Inicjowanie Projektu

Dokumentacja
~ ~zwolenie n• Opr.>eowanie Strategii Inicjowania Projektu
inkjowani~ proft'ktu r Zarządzania Jakością (częlc1

Za łotenia Projektu Opra.cO\'Vłt Strategia

Zarządzania Jakolclą

Opis Produktu
Projektu
_;,"°"'-...i•[ Rejestr Jakoś<i J
Dziennik
Doświadczeń

Rejestr Ryzyk

Rejestr Zagadnień

Rysunek 14.4 Opracowanie Strategii Zarządzania Jakością - schemat działania

• Wystąpić do Komitetu Sterującego o zatwier- akceptacji projektu zostały wystarczająco zdefi-

dzenie Strategii Zarządzania Konfiguracją (moż­
liwe jest również, że Komitet Sterujący zechce
dokonać jej przeglądu później, jako części
Dokumentacji Inicjowania Projektu).
Tabela 14.2 przedstawia obowiązki
dz i a łaniem.
14.4.3 Opracowanie Strategii
Jakością
Kluczowym czynnikiem sukcesu projektu jest dostar-
czenie tego, czego użytkownik oczekuje i uznaje za
akceptowalne. Stanie się tak tylko wtedy, kiedy już
od samego początku projektu te oczekiwania zosta-
ną sprecyzowane i uzgodnione wraz ze standarda-
mi, które mają być użyte oraz metodami oceny ich
spełnienia. Celem Strategii Zarządzania Jakością jest
zapewnienie, aby te uzgodnienia zostały zarej estro·
wane i były aktualizowane.
Wi ęcej szczegółów na temat zarządzania jakością
można znaleźć w Rozdziale 6.
Rysunek 14.4 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeglądu Opisu Produktu Końcowego
Projektu w celu zrozumienia oczekiwań jako-
ściowych klienta oraz sprawdzenia, czy kryteria
niowane.
• Dokonać przeglądu Założeń Projektu w celu
ustalenia, czy strategie, standardy lub praktyki
zarządcze organizacji lub programu, dotyczące
zarządzania jakością, powinny być zastosowa-
zwi ązane z tym
ne w projekcie (w szczególności czy klient i/lub
dostaw ca posiada istn i ej ący system za rządza ni a
jakością, który na l eży zastosować w trakcie pro-
Zarządzania
jektu).
• Pozyskać doświadczenia dotyczące zarządzania
jakością z wcześniejszych podobnych projektów
od kierownictwa organizacji lub programu oraz
od organizacji zewnętrznych. Niektóre z tych
doświadczeń mogą być już wcześniej zarejestro-
wane w Dzienniku Doświadczeń.
• Dokonać przeglądu Rejestru Ryzyk i Rejestru
Zagadn i eń pod kątem ryzyk i zagadnień związa ­
nych z za rządzan i em j akością.
• Określ ić Strateg i ę Zarządzania J a kością, a w szcze-
gólności:
• procedurę zarządzan i a ja kością (np. planowa-
nie jakości, kontrola jakości, nadzór jakości);
• narzędzia i techniki, które będą wykorzystane;
• zapisy, które będą prowadzone;
• sposób raportowania efektywności procedury
zarządzania jakością;
• terminy działań dotyczących zarządzania
j akości ą;
 Inicjowanie Projektu I 163

Tabela 14.3 Opracowanie St rat egii Zarządzania Jakością - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwi erdzaj ący - potwierdza odbiór >.
c
a.
E ~
....<I>-
·-c:
ro
.....
m
o
.,.~
~
~
ro
u ~
-
::>
....
o
·- "'
Cll
::>
a. ::>
....
....::>
~
"'
o
"O

·--ro
o
·-a.o ·-.....o
..... Cll
o._ ~ ro o
..... Cll
~
....::>
ro
N
>. t; o._ N
Cll
~

u ·-uc: ·N o ~ ~ ..... o._ ::>

N -o ::>
>.
o
>.
·-c: ·-c .....
Cll
·-
"O
o
·-
c o c: c: ~ ~
V
..... .....
o._
ro ~ ~ ~ o
..... o
..... '°
N ro
a.
Pr o dukt Czynność o
m
.....
Cll
N
.....
o._ - -
•O
I.!)
·O
I.!)
Cll
:..::
Cll
:..::
-o
ro
z "'
?; o
"'
a.

Strategia Za rządzania Jakością Opracować (Z) (Z) (Z) w K A22

Rejestr Jakości Zalożyć z K w A23

• ro le i obowiązk i dla dz i ałań dotyczących i otrzymywać informacje do i od różnych organi zacji

zarządzania jakością (sprawdzić powiązania
z funkcją nadzoru jakości organizacji lub
programu i zapewnić, że wszystkie działania
projektu dotyczące jakości wspierają tę funk-
cję i są przez nią wspierane).
• Skonsultować się z Nadzorem Projektu w celu
sprawdzenia, czy proponowana Strategia
Zarządzania J a kości ą zaspokaja potrzeby
Komitetu Steruj ącego i/lub kierownictwa organi-
zacj i lub programu.
• Za łożyć Rejestr Jakości, gotowy do rej estrowa-
n ia szczegółów wszystkich dz i ałań dotyczących
jakości.
• W przypadku zidentyfikowania nowych ryzyk
lub zagadnień (lub zmiany istniejących), nale-
ży dokonać aktualizacji Rejestru Ryzyk, Rejestru
Zagadnień i/lub Dziennika Projektu.
• Wystąpić do Komitetu Sterującego o zatwierdze-
nie Strategii Zarządza n ia Jakością (możliwe
równ i eż, że Komitet Sterującyzechce dokonać
jej przeglądu późn i ej jako części Dokumentacji
Inicjowania Projekt u).
Tabela 14.3 przedstawia obowi ązki związane z tym
działaniem .
14.4.4 Opracowanie Strategii Zarządzania
Komunikacją
Strategia Zarządzania Komunikacją dotyczy zarów-
no komunikacji wewnętrznej, jak i zewnętrznej.
Powinna zawi erać szczegóły dotyczące sposobu,
w jaki zespól zarządza ni a projektem będz i e przesyłać
zaangażowanych w rea l izację projektu (w szerokim
rozumieniu) lub objętych jego oddzialywaniem.
W szczególności jeżeli projekt jest częścią programu,
należy podać szczególowe wytyczne dotyczące sposo-
bu przekazywania informacji do programu.
Jeżeli potrzebna będzie formalna procedura zaan -
gażowania interesariuszy (taka, jak np. procedura
opisana w Rozdziale 5), to powinna być ona równ i eż
udokumentowana jako część Strategii Zarządzan i a
Kom uni kacją, przy czym należy opisać rodzaje inte·
resariuszy, pożądane relacj e i główne informacj e,
strategie komunikacji oraz metody oceny powodze-
nia komunikacji.
Rysunek 14.5 przedstawia elementy wejściowe i wyj -
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeg l ądu Zalożeń Projektu w celu
jest ustalenia, czy strategie, standardy lub praktyki
zarządcze organizacji lub programu, dotyczące
zarządzania kom un ikacją, powinny być zastoso-
wane w projekcie.
• Pozyskać doświadczen ia dotyczące zarządzan i a
komunikacją z wcześniejszych podobnych pro-
jektów od kierownictwa organizacji lub progra -
mu oraz od organizacji zewnętrznych. Jakieś
doświadczenia mogą być już wcześniej zareje-
strowane w Dzienniku Doświadczeń.
• Dokonać przeglądu Rejestru Ryzyk i Rejestru
Zagadnień pod kątem ryzyk i zagadnień związa­
nych z zarządzaniem komuni kacją .
164 I Inicjowanie Projektu

DoKumentacJa
Założeni a Projektu
... Opracowanie
Strategii Zarządza nia
Komunikacją
Inicjowania Projektu
(część)

Dziennik Qfx.ac&.v.tl Strategia Zarządzan ia

Doświadczeń Komunikacją

Rejestr Ryzyk

Rejestr Zagadnień

Dokumentacja
Inicjowania Projektu
(części

Strategia Za rządzania
Ryzykiem

Strategia Zarządzania
Jakością

Strategia Zarządzania
Konfiguracją

Rysunek 14.5 Opracowanie Strategii Zarządzania Komunikacją - schema t działania

• Zi dentyfikować i/lub dokonać przeglądu

intere- • Skonsu ltować się z Nadzorem Projektu w celu
sariuszy oraz skonsultować z nimi ich potrzeby sprawdzenia, czy proponowana Strategia
informacyjne, a w szczególności : Zarządzan i a Komun ikacją zaspokaj a potrzeby

• z i dentyfikować pożądane relacj e; Komitetu Sterującego i/lub kierownictwa organi-

• określ ić kluczowe komunikaty/informacje; zacji lub programu.
• ustalić pożądane rezultaty skutecznej • W przypadku zidentyfikowania nowych ryzyk
komunikacji. lub zagadnień (lub zmiany istniejących), nale-
ży d okon ać aktualizacji Rejest ru Ryzyk, Rejestru
• Ustal i ć pot rzeby informacyjne związane ze Zagadnień i/lub Dziennika Projektu.
Strateg i ą Zarządza n ia Ja kością, Strategią
• Wystąpić do Komitetu Steruj ącego o zatwier-
Za rządzania Ryzykiem oraz Strateg i ą
dzenie Strat egii Zarządzania Komunikacją
Za rządzania Konfiguracją.
(możliwe jest również, że Komitet Sterujący
• Określ i ć Strategię Za rządzania Komunikacj ą,
zechce dokonać jej przeg lądu później jako części
a w szczególności : Dokumentacji Inicj owania Projektu).
• proced u rę zarzą d zan ia k om un i k acją;
Tabela 14.4 przedstawia obowi ązki związa n e z tym
• narzęd zi a i techniki, które będą wykorzystane;
działan i em.
• zapisy, które będą prowadzone;
• sposób raportowania efektywn ości procedury 14.4.5 Ustanowienie mechanizmów
za rządzania komunikacj ą;
sterowania projektem
• terminy dzi ałań dotyczących komunikacji;
Należy uzgodnić poziom kontroli wymagany przez
• role i obowi ązki dla działa ń d otyczących
Komitet Sterujący po zainicjowaniu projektu oraz
komunikacji;
należy ustal i ć sposoby stosowania mechanizmów
• wyniki analizy interesariuszy.
 Inicjowanie Projektu I 165

Tabela 14.4 Opracowanie Strategii Zarządzania Komunikacją - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezaleźny od wytwórcy
Zatwierd zający - potwierdza odbiór

>.
c
o.
E ~
....Cl>-
..."' ·-
c
~
::>
- ::> ::> o
V>
Ol
...
o ~
..,.
~ "'~
V

·-...
Q) o
o. ....
::> ~ -o

·-... ·-...
o o Q)
!:!:: ~
...."' V> ~
o ....::>
·-"'"'
N
·-c
V >-
•N
V>
o
a..
Q)
N
o
Q)

a..
~
::>
V
:::> o ~
·-c ~
·-c a.. -o
c
N -o
o >.
c c
>.
~ ~
...
•O
Q)

...
V ...o
a..
...o"'
~ ~ ~ ... ...
o o N
"'o.
- -
V>
Q)
-o
Ol
...
N
a..
·O
\!)
·O
\!) ~
Q) Q)
~ z"' ~
V>

o
o.
Produkt Czynność

Strategia Zarządzania Komunikacją Opracować (Z) (Z) (Z) w K A4

sterowania, a także poziom kontroli wymagany niu mechanizmów sterowania i zapewnieniu, że

przez Kierownika Projektu w odniesieniu do prac, będą one mialy sens jako spójny zbiór.
które mają być wykonane przez Kierowników
Rysunek 14.6 przedstawia elementy wej ści owe i wyj-
Zespo łów.
ści owe tego dzia łania .
Mechanizmy sterowania projektem umożl iwi ają
PRINCE2 zaleca wykonanie następujących czynności:
zarządzanie projektem w sposób skuteczny, spraw-
ny i zgodny ze skalą, ryzykami, złożonością i znacze- • Dokonać przeglądu Założeń Projektu w celu
niem projektu. Istnienie skutecznych mechanizmów ustalenia, czy strategie, standardy lub praktyki
sterowania projektem j est warunkiem wstępnym dla zarządcze organizacji lub programu, dotyczące
za rządzan i a z wykorzystaniem tolerancji. Mechani- mechanizmów sterowania, powinny być zasto-
zmy sterowania projektem mogą obejmować: sowane w projekcie. Należy określ i ć, czy któ-
reś z nich wymagają dostosowania metodyki
• częstotliwośći formę komunikacji pomiędzy róż­
PRINCE2.
nymi poziomami zarządzania projektem (patrz
• Dokonać przeglądu Strategii Zarządzania
Rozdział S);
Jakością, Strategii Zarządzania Konfi guracją,
• l iczbę etapów, a w konsekwencji liczbę ocen
Strategii Zarządzania
Ryzykiem i Strategii
końcowych etapu (patrz Rozdzi ał 7);
Zarządzania Komunikacją w celu zidentyfiko-
• mechanizmy służące do rejestrowania i analizo- wania mechanizmów sterowania, które należy
wania zagadnień i zmian {patrz Rozdział 9); ustanowić.
• mechanizmy służące do przekazywania informa- • Pozyskać doświadczenia dotyczące mecha-
cji o sytuacjach nadzwyczajnych na wyższy szcze- nizmów sterowania projektem z wcześniej­
bel zarządzania {patrz Rozdz i al 1O); szych podobnych projektów o d k ierownictwa
• tolerancje d la delegowanych uprawnień {patrz organizacji lub programu oraz od organiza-
Rozdział 1O); cji zewnętrznych. Niektóre z tych doświad­
• sposób, w jaki będzie monitorowana realizacja czeń mogą być już wcześniej zarejestrowane
uprawn i eń delegowanych z jednego szczebla w Dzienniku Doświadczeń.
zarządzania na inny (patrz Rozdział 1O). • Dokonać przegląd u Rejestru Ryzyk i Rejestru

Wiele z tych mechanizmów sterowania bywa zdefi- Zagadnień pod kątem ryzyk i zagadni eń zwią­

niowanych w strategiach projektu, ale niekoniecznie zanych z mechanizmami sterowania projektem.

są one ustanawiane w rzeczywistości. Omawiane Łączny zbiór ryzyk będzie mieć wplyw na skalę

działanie koncentruj e się na faktycznym ustanowie- i formalizm działań kontrolnych.

166 I Inicjowanie Projektu

r
Ustanowienie Dokumentacja
Dziennik Doświadcze ń ~ Inicjowania Projektu
mechanizmówsterowania - -
projektem (cz~.i.--.J

r - - -
1A1J1n0\vił 1 •
Mechan1z:my '
Założenia Projektu t---„.
-. -
1sterowania projektem I

r
- - „ .....

Dokumentacja U.ilttiulni< I '

„ - - ....
Opisy ró l I
Inicjowania Projektu I
(czę~)
- - „
r -
........., Struktura Zespołu '

-- - -. -
Strategia Zarządzania _ _..,, Zarządzania Projektem'
Jakolcią
....

Strategia Zarządzania
Kon figuracją

Strategia Zarządzania
Ryzykiem

Strategia Zarządzania
Komunikacją

Plan Projektu

Rejestr Ryzyk

Rejestr Zagadnień

Rysunek 14.6 Ustanowienie mechanizmów sterowania projektem - schemat działania

• Potwierdzić i udokumentować granice etapów przydzialu obsadzonych wcześniej ról, a w razie

zarządczych wymagane w celu zapewnienia wła­
ściwego poziomu sterowania.
• Przyporządkować różne poziomy podejmowania
decyzji wymaganych w proj ekcie do najbardziej
odpowiedniego poziomu zarządzania projek-
tem. Usta l ić wszelkie procedury podejmowania
decyzji, które mogą być właściwe, być może
poprzez dostosowanie procedur obowiązujących
w ramach istniejącego systemu zarządzania jako-
ścią lub innych standardowych procedur.
• Dołączyć uzgodnione uprawnienia i obowiązki
dotyczące podejmowania decyzji do struktury
zespołu zarządzania projektem i do opisów ról
tam, gdzie jest to właściwe; może to obejmować
dokończenie obsadzania wszelkich ról, które
nie zosta ły dotychczas przydzielone, zmianę
potrzeby, przeprojektowanie zespołu zarządza­
nia projektem.
• Potwierdzić tolerancje dla projektu i procedury
przekazywania spraw na wyższy szczebel zarzą­
dzania (przez Ki erowników Zespołów Kierowni-
kowi Projektu, przez Kierownika Proj ektu Komi-
tetowi Sterującemu i przez Komitet Steruj ący
kierownictwu organizacji lub programu).
• Zestawić mechanizmy sterowania projektem
w Dokumentacji Inicjowania Projektu.
• Skonsultować się z osobami pełniącymi obowiązki
Nadzoru Projektu w celu sprawdzenia, czy pro-
ponowane mechanizmy sterowania projektem
są zgodne z charakterem projektu i zaspokajają
potrzeby Komitetu Sterującego i/lub kierownic-
twa organizacji lub programu.
 Inicjowanie Projektu I 167

Tabela 14.5 Ustanow ienie mechanizmów sterowania projektem - obowi ązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c
a.
E .;,(.
....Cl>-
f1l
....
C'I
o.... >.
V
·-
c
5
o
f1l
V
5
....:i
.:,!.
<Il
·~
o
,_
-:i
o
a. ....
:i
....:i
.;,(.
<Il
V>
o
"O
....:i
....
CL
f1l
f1l"
N
.:,!.
1>- ....
f1l
V> CL N
V>
<Il
.:,!.
<Il
· ~
·~
o
,_ .;,(.
·~
c
V
·N o o
,_ CL :i
V
f1l :::> o .:,!.
·-
c
.:,!.
·-
c CL <Il "O
·-c
N "O
o >.
c c
>.
5 5
,_
•O
·-,_
V
o
,_
f1l 5 5 5 o
,_ o
,_ N f1l
CL
a.
- -
<Il V>
C'I
,_ •O •O "O
,_
N <Il <Il V>
a.
Produkt Czynność o CL (!:' (!:' ~ ~ z
f1l
s o
Mechanizmy sterowania projektem Ustanowi ć (Z) (Z) (Z) w K
Opisy ról Uaktualnić (Z) (Z) (Z) w K
Struktura Zespolu Zarządzania Projektem Uaktualnić (Z) (Z) (Z) w

• W przypadku zidentyfikowania nowych ryzyk Rysunek 14.7 przedstawia elementy wejściowe i wyj-
lub zagadn i eń (lub zmiany i stniejących), nale- ściowe tego działan i a.
ży dokonać aktualizacji Rej estru Ryzyk, Rejestru
PRINCE2 zaleca wykonanie następujących czynności :
Zagadnień i/lub Dziennika Proj ektu.
• Wystąpić do Komitetu Sterującego o zatwierdze- • Dokonać przegląd u Za leżeń Proj ektu w celu:
nie mechanizmów st erowania projektem (moż­ • ustalenia, co projekt ma dostarczyć i spraw-
liwe jest również, że Komitet Sterujący zechce dzenia wszelk ich wcześniej ustalonych
dokonać ich przeg l ądu później, jako części Doku- z góry „ kamieni milowych" , ok reślo nych
mentacj i Inicjowania Projektu). w Założen i ach Projektu;
• sprawdzenia, czy i stnieją ja kieś strategie,
Tabela 14.5 przedstawia obowiązk i związa n e z tym
standardy lub praktyki k ierownictwa organi-
dzialaniem.
zacji lub programu, dotyczące planowania,
do których projekt musi się dostosować;
14.4.6 Sporządzanie Planu Projektu
• sprawdzenia zrozumienia wszelkich warun-
Przed zaangażowaniem się w istotne wydatki na
ków wstę pnych, zależności zewnętrznych,
real izację projektu, n a leży u sta l ić wymagane ter-
og ran i czeń i założeń udokumentowanych
miny i potrzebne zasoby. Taka informacja zawarta
w Za łożen iach Proj ektu;
w Planie Projektu jest potrzebna, aby można bylo
• sprawdzenia zrozum ienia wybranego roz-
doprecyzować Uzasadnienie Biznesowe i aby Komi-
wiązan i a, zgodn ie z opisem zawartym
tet Steruj ący mógł kontrolować projekt.
w form ule realizacji projektu.
Planowanie nie jest dz i ałaniem wykonywanym przez
• Pozyskać doświadczenia dotyczące planowa-
Kierownika Projekt u w odizolowaniu - j est to dzia-
nia z wcześniejszych podobnych projektów od
lanie, które na l eży raczej wykonywać przy ścislym
kierownictwa organizacj i lub programu oraz
zaangażowan iu użytkownika(-ów) i dostawcy(-ów).
od organizacji zewnętrznych . Niektóre z tych
Często przydat ne jest przeprowadzenie warsztatów
doświadczeń mogly być j u ż zarejestrowane
d otyczących planowania, co pomaga zidentyfikować
w Dzienniku Doświ adczeń.
wszystkie wymagane produkty, ich szczególy oraz
• Dokonać przeg l ądu Rejestru Ryzyk i Rejest ru
zależn ości m iędzy nimi.
Zagadnień pod kątem ryzyk i zagadn i eń związa­
Więcej szczeg ółów na t emat planowania możn a nych z planowaniem.
zn aleźć w Rozdziale 7.
168 I Inicjowanie Projektu

• Ustalić format i sposób przedstawienia Planu • Zidentyfikować wszelkie narzędzia do planowa-

Projektu, biorąc pod uwagę odbiorców planu
i to, jak będzie on wykorzystywany (na przy-
kład: czy wystarczy wykorzystać l istę kontro-
lną produktów w celu przedstawienia planu
Komitetowi Sterującemu?) . Dalsze informacje
można zn aleźć w Opisie Produktu dotyczącym
Planu w Dodatku A.
nia i kontroli realizacji, które mają być wykorzy-
stane w projekcie.
• Wybrać metodę/metody szacowania dla planów
projekt u.
• Dokonać przeglądu Strategii Zarządzania Jako-
ścią, Strategii Zarządza nia Ryzykiem, Strategii
Zarządzania Konfiguracją i Strategii Zarządzan ia

Dokumentacja
Dziennik Doświadczeń Sporządzanie łnkjowania Projektu
Planu Projektu (cz~I

Sporządzi(
Rejestr Ryzyk Plan Projektu

r - - -
U•l:•u** 1 Struktura Zespołu •
Rejestr Zagadnień
•
r
' - • - -
r Zarządzania Projektem 1
„ ...
U*twht I
•
Opisy ról
„ - - ...
I
Załoienia Projektu
"• ' --
r IJW«wqłJ

I Formula
• U.llłwani( Zapisy Obiektu
I

'' - •
„ • -...
realizacji projektu I Konfiguracji

Opis
Produktu Projektu

Dokumentacja
Inicjowania Projektu
(aęSc1

Strategia Zarządzania
Jakol<ią

Strategia Zarządzania
Konfiguracją

- Strategia Za rządza nia

Ryzykiem

- Strategia Zarządzania
Komunikacją

r -
r Mechanizmy '

- . - - -.....
r sterowania projektem I

'
Rysunek 14.7 Sporządzanie Planu Projektu - schemat działania
 Inicjowanie Projektu I 169

Tabela 14.6 Sporządzanie Planu Proj ektu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej n i ezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>,
c
a.
E ~
....<IP
·-c
ro
.....
01
o
..... >,
V
~
o
ro
V
~
....
::i
~
QI
·~
o
-
::i
o
a. ::i
.....
....::i
~
QI
"'
o
"O
a..
-..
ro
fil'
N
~
~
ro
.... .....
a..
"'
QI
N
~
QI
·~
o
..... ~
....
::i

'U'
V
c ·N "'
o ~ ~
·~
o
..... a.. ::i
ro ::> o ·-c a.. "O
N
c
"O
o >,
c
>,
c
c
~ ~
.....
•O
·-.....QI
V
o.....
a..
ro ~ o o ro
~ ~ ..... ..... N
a.
- - "'a.
QI "O
01 •O •O QI QI
..... N

Produkt Czyn ność o .....

a.. l'.} l'.} ·-
~ ~ 2
ro
s "' o
Plan Projektu Sporządzić {Z) (Z) {Z) w K A16
Opisy Produktów Sporządzić {Z) {Z) {Z) w K A17
Utworzyd
Zapisy Obiektu Konfiguracji Uaktualnić
z K w AS

Struktura zespołu zarządzania projektem Uaktualnić (Z) (Z) (Z) w K

Opisy ró l Uaktual n ić (Z) (Z) (Z) w K

Komunikacją w celu zrozumienia potrzebnych
zasobów, standardów, metod oraz kosztów real i-
zacji prac, które mają być wykonane.
• Sporządzi ć strukturę podzialu produktów, dia-
gram następstwa produktów i Opisy Produktów
dla glównych produktów w Planie Projektu.
Określić ustalenia dotyczące przekazywania pro-
duktów projektu do użytku operacyjnego. Tam,
gdzie produkty projektu mogą wymagać poten-
cjalnie kosztown ego utrzymania po wprowadze-
niu do eksploatacj i, zaplanować sporządzen i e
odpowiedniej umowy serwisowej lub kontrak-
tu pomiędzy grupą utrzymania a użytkowni­
kiem. W takich przypadkach niezbędne będz i e
uwzg l ędnienie ewentualnej umowy jako produk-
t u w Planie Proj ektu.
• Rozważyć, czy trzeba zaktualizować Opis Pro-
duktu Końcowego Proj ektu {na przykład : jeżel i
zrozumienie kryteriów akceptacji zmienilo się
lub zostało doprecyzowane w t rakcie inicjowania
proj ektu).
• Utworzyć lub ua ktualn i ć Zapisy Obiektu Konfigu-
racji dla każdego produktu, który ma być dostar-
czony w ramach planu.
• Zidentyfikować i potwi erdzi ć wymagane zasoby.
Potwierd zić dostępność wybranych osób, ich
akceptację przypisanych im ról oraz zaangażo-
wanie w ich pelnienie. Więcej szczególów można
znaleźć w Rozdziale 5.
• Zidentyfikować działania, zasoby i terminy dla
mechanizmów sterowania projektem i wlączyć je
do planu.
• Zidentyfikować ryzyka związane z planem.
• Udok u mentować Plan Projektu.
• Skonsultować się z Nadzorem Projektu w celu
sprawdzenia, czy proponowany Plan Projektu
zaspokaja potrzeby Komitetu Sterującego i/lub
kierownictwa organizacji lub programu.
• W przypadku zidentyfikowania nowych ryzyk
lub zagadnień {lub zmiany istniejących), nale-
ży dokonać aktualizacji Rejestru Ryzyk, Rejestru
Zagadn i eń i/lub Dziennika Projektu.
• Wystąpić do Komitetu Sterującego o zatwier-
dzenie Planu Projektu (możl iwe jest równ i eż, że
Komitet Sterujący zechce dokonać jego przeg l ą­
du później jako części Dokumentacji Inicjowania
Projektu).
Tabela 14.6 przedstawia obowi ązki związane z tym
dzialaniem.
170 I Inicjowanie Projektu
Zaloźenia Projektu
Ooprecyzowanic
Uzasadnienia
~
Biz~o
zasaCłnlenfe
Biznesowe
(zarys)
.
Dokumentacja
lnkjoi..vania Projektu
(cz~
[ Plan Projektu ] I
-
Rejestr Ryzyłc
Rysunek 14.8 Doprecyzowanie Uzasadnienia Biznesowego - schemat działania
14.4. 7 Doprecyzowanie Uzasadnienia
Biznesowego
Zarys Uzasadnienia Biznesowego, wytworzony
w trakcie Przygotowania Projektu, należy zaktuali-
zować w celu odzwierciedlenia szacunkowych nakla-
dów czasu i kosztów, ustalonych w Planie Projektu
oraz zagregowanych ryzyk ze zaktualizowanego
Rejestru Ryzyk.
Szczególowe Uzasadnienie Biznesowe będzie wyko-
rzystywane przez Komitet Sterujący do zatwierdze-
nia projektu i będz i e stanowilo podstawę do spraw-
dzania na bieżąco, czy projekt jest nadal zasadny.
Więcejszczególów na temat Uzasadnienia Bizneso-
wego można znależć w Rozdziale 4.
Rysun ek 14.8 przedstawia elementy wejściowe i wyj-
ściowe tego dzialania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeglądu Zalożeń Projektu w celu
sprawdzenia, czy istnieją jak ieś wymagania kie-
rownictwa organizacji lub programu, dotyczące
formatu i zawartości Uzasadnienia Biznesowego.
• Pozyskać doświadczenia dotyczące opracowywa-
nia Uzasadnienia Biznesowego z wcześniejszych
podobnych projektów od kierownictwa organi-
zacji lub programu oraz od organizacji zewnętrz­
nych. Niektóre z tych doświadczeń mogą być
już wcześn i ej zarejest rowane w Dzienniku
Doświadczeń.
• Opracować szczególowe Uzasadnienie
Biznesowe z uwzg l ędnieniem uzyskanych dodat-
kowych szczególów, a mianowicie:
....,...,„ Plan Przeglądu
Korzyści
Dokumentacja
Inicjowania Projektu
(część\
• kosztów i terminów zawartych w Planie
Projektu;
glównych ryzyk, które mają wplyw na
zasad n ość projektu i osiągalność jego celów
(z Rejestru Ryzyk);
• korzyści do uzyskania;
tolerancji dozwolonych dla każdej z korzyści.
• Sporządzić Plan Przeglądu Korzyści. W tym celu
na l eży:
• dokonać przeglądu Uzasadnienia Bizne-
sowego i sprawdzić zrozumienie korzyśc i
oczekiwanych od projektu;
zidentyfikować sposób, w jaki będzie mie-
rzone osiągnięcie każdej korzyści oraz zare-
jestrować aktualne wie l kości jako poziomy
odniesienia;
• zidentyfikować terminy przeg l ą dów korzy-
ści (najprawdopodobniej będą one zbieżne
z końcami etapów);
• jeżeli projekt jest częścią programu, Plan
Przeg l ąd u Korzyści może być tworzony,
utrzymywany i realizowany na poziomie
programu.
• W przypadku zidentyfikowania nowych ryzyk
lub zagadnień (lub zmiany istniejących), nale-
ży dokonać aktualizacji Rejestru Ryzyk, Rejestru
Zagadn i eń i/lub Dziennika Projektu.
• Skonsultować si ę z Nadzorem Projektu w celu
sprawdzenia, czy proponowane Uzasadnienie
Biznesowe i Plan Przeglądu Korzyści zaspokajają
potrzeby Komitetu Sterującego i/lub kierownic-
twa organizacji lub programu.
 Inicjowanie Projektu I 171

Tabela 14.7 Doprecyzowanie Uzasadnienia Biznesowego - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c
a.
E .:.:. Q>o
·-c
A)
.....
Ol
o
..... ~
...,.
~
o
A)
V
~
....
:i
.:.:.
QI
·~
o
-o
:i

a. ....
:i
....
:i
.:.:.
QI
t:
o
"O
o..
.....
A)
N
V
.:.:.
>.
A)
t: .....
o.. N
"'
QI
.:.:.
QI
·~
·~
o
.....
....
:i
.:.:.
·~ -N o .:.:. .:.:. o
..... o.. :i
V
A) c :> o ·-c ·-c o.. "O
N
c
"O
o >.
c
>.
c ~ ~
..... ·-.....QI
V
o
.....
~ o o ·O IO
o..
IO ~ ~ ..... ..... N
a. ·-"'a.
Produkt Czynność o
Ol
.....
QI
N
.....
o.. - -
•O
\!)
•O
\!) ·-
~
QI
~
QI
"O
z
IO
5"' o
Plan Przeglądu Korzyści Sporządzić (Z) (Z) (Z) (Z) w K A1
Szczególowe Uzasadnienie Biznesowe Opracować (K) (Z) (Z) (Z) w K A2

• Wystąpić do Komitetu Sterującego o zatwierdze-
nie Uzasadnienia Biznesowego i Planu Przeglądu
Korzyści (możliwe jest również, że Komitet
Sterujący zechce dokonać ich przeglądu później
jako części Dokumentacji Inicjowania Projektu).
Tabela 14.7 przedstawia obowiązki związane
działaniem.
nie ona później wykorzystana jako podstawa do
porównania rzeczywistych osiągnięć projektu z pier-
wotnymi przewidywaniami, które stanowiły podsta-
wę do udzielenia zezwolenia na realizację projektu.
Rysunek 14.9 przedstawia elementy wejściowe i wyj-
z tym ściowe tego działania .
PRINCE2 zaleca wykonanie następujących czynności:

14.4.8 Zestawianie Dokumentacji • U zyskać,a w razie potrzeby również skorygować

Inicjowania Projektu informacje z Zależeń Projektu (def inicj a projektu
i formula rea lizacji projektu).
Konieczne jest istnienie w projekcie centralnego
• Dolączyć lub zam i eści ć odnośni ki do informacji
miejsca, w którym wszystkie informacje projektu
znajdujących się w:
odnoszące się do tego „co, dlaczego łub po co, kto,
jak, gdzie, kiedy i za ile" będą: • strukturze zespołu zarządzania projektem
i opisach ról;
• zebrane w celu ich uzgodnienia przez głównych
• Uzasadnieniu Biznesowym;
interesa riuszy;
• Strategii Zarządzania Jakością;
• dostępne w celu udzielania wskazówek i infor-
• Strategii Zarządzan i a Konfiguracją;
macji osobom zaangażowanym w projekt.
• Strategii Zarządzan i a Ryzykiem;
Informacj e te są zestawione w Dokumentacji Inicj o- • Strat egii Za rządzan i a Komunika cją;
w ania Projektu. Dokumentacja Inicjowania Projektu
• Planie Projektu.
j est zbio rem wielu produktów zarządczych stworzo-
• Dołączyć opisy mechanizmów sterowania proj ek-
nych podczas etapu inicjowania i wykorzystanych do
tem lub zamieścić odnośniki do takich opisów,
uzyskania zezwolenia na rea l izację projektu. Doku-
a także opis sposobu, w jaki projekt dostosował
mentacja Inicjowania Projektu niekoniecznie musi
metodykę PRINCE2.
stanowić jeden dokument (co zdarza się rzadko),
• Zestawić Dokumentację Inicjowania Projektu.
lecz może być zbiorem dokumentów.
• Przeprowadzić sprawdzenie krzyżowe informacji
Ta wersja Dokumentacji Inicjowania Projektu, która zawartych w różnych dokumentach, by zapew-
została zestawiona w t rakcie procesu Inicjowanie
n i ć, że są one spójne.
Projektu i wykorzystana do uzyskania zezwolenia na
rea l izację projektu, powinna być zachowana. Zosta-
172 I Inicjowanie Projektu

Założenia Projektu Zestawianie Dokumentacji z~i.\vi( Dokumentacja

. Inicjowania Projektu Inicjowania Projektu

.---- - .
• Wniosek o zezwolenie
Definicja proj ektu

-- .....
I na reali zację projektu I
' ... - „ -
•
,... ---
Form uł a
real izacji
•
Zblit.ają<:y się
koniec etapu I

„ - „
projektu
• • - ....
I

Uzasadnienie Biznesowe
(Szczegółowe)

r - - - - - -•
I Struktura Zespo łu Zarzą·
I

'„
r
dzania Projektem

-
• ....
- - - - - .•
„ • - I

I Opisy ról
I
I
'„
- „ • • - ....
Strategia Zarządzania
Jakością

Strategia Zarządzania
Konfiguracią

Strategia Zarządzania
Ryzykiem

Strategia Zarządzan ia
Kornunikacją

Plan Projektu

r ---
I Mechanizmy sterowania
- - .
•
I
'„
r
projektem

-
- - - -
„ •
I
• -- .....
I Dostosowanie •
PRINCE2 I
I
„ - „ ,,,-- .....

Rysunek 14.9 Zestawianie Dokumentacji Inicjowania Projektu - schemat działania

 Inicjowanie Projektu I 173

Tabela 14.8 Zestawianie Dokumentacji Inicjowania Projektu - obowiązki

Wytwórc<J - odpowiedzialny za wytworzenie produktu

Kontroler - n<Jjlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>-
c
a.
E ~
....Cl>-
·-c
ro
....
Ol
o
.... .,.>- o
;: ro
V
;:
~ -
....
::>

·- "'
Q)
::>
o
a. ....
::>
....::>
~
"'
o
"O
o..
..... N
V
~

>- ....
ro o
....
o..
Q)
~
·-
Q)

·-o......o o..
Q) o
....
....::>
·-
ro
V
ro
V
c
"O
•N
:::>
"'
o
o ~
·-c
N
~
·-c ....
Q)
·-....
~
::>
"O
o....
·-c
N
o
;:Q) c>-
c>- ;:
o
;:
o '0
V
ro o..
ro ;: ;: .... .... N
a. ·-"'a.
Produkt Czyn ność o
Ol
.... N
....
o.. - -
·O
\.9
•O
\.9
Q)
~
Q)
·-
~
"O
z
ro
3"' o
Dokumentacja Inicjowania Projektu Zestawić (Z) (Z) (Z) w K A20

• Skonsultować się z Nadzorem Proj ektu w celu • Wystąpić do Komitetu Steruj ącego o zezwolenie
sprawdzenia, czy zestawiona Dokumentacja na real i zację projektu.
Inicjowania Projektu zaspokaja potrzeby Tabela 14.8 przedstawia obowi ązki związane z tym
Komitetu Sterującego i/lub kierownictwa organi- działaniem .
zacji lub programu.
• Przygotować się do następnego etapu (czyli
uruchomić proces Zarządzanie Końcem Etapu).
 15 Sterowanie Etapem

15.1 PRZEZNACZENIE 15.2 CEL

Proces Sterowanie Etapem służy do przydzielania Proces Sterowanie Etapem ma na celu zapewnie-
pracy do wykonania i monitorowania j ej wykonania, n ie, że:
do obsług i pojawiaj ących si ę zagadn i eń, raporto -
• Uwaga skupiona jest na dostarczaniu produktów
wania Komitetowi Steruj ącem u o postępach oraz
etapu. Wszelkie odchylenia od kierunku i pro-
podejmowania d ziałań koryg ujących w celu zapew-
duktów uzgodnionych na początku etapu są
nienia, aby etap mieścił się w granicach t olerancji.
monitorowane, aby uniknąć niekontrolowanych
zmian („pełzania zakresu") oraz dekoncentracji.
• Ryzyka i zagadnienia są utrzymywane pod
kon trolą.

Zarządzanie Strategiczne Projektem

„
6._.,,,,
. . . .„...,.....) „
( ••--N
-'•pu )
rN1•l4<if l ...,J.;:") („ .......,.,.,..} I
\._
M 1ComrtflU)
Sitro;ł<t90

Zarządzanie Końcem
Etapu Zamykanie Projektu

( lblil•.lłCY t.łł
tonoteeupu ) "'!°'1
Zól&Ulj<ttY
"""""" _______ ,
r---------------- -------· --------1 ---- --- -- I
:Sterowanie Przekazywanie
Raportowanie
I
I
zagadnień i ryzyk I
•Etapem
I na wyiszy szczebel
okresowe I
I
I I
I I
I I
I I
. I
I
I
Podejmowanie działań Przeglądanie stanu •
k01Y9ujących etapu 'I
I

Wychwytywanie 'I
i badanie zagadnień
i ryzyk I
'' N0>.wugadl'll.....
I
I
I
I
I
Odbieranie
Zezwalanie na Przeglądanie stanu
zakończonych
I
I
wykonanie Grupy Zadań Grupy Zadań
I Grup Zadań I
I„ _______ ._ ______ „I
~----------------~ ~------------- --- 4

( Zuwd~N
„...
W)'\on.arie Grupy ) (z„~G"""}

Zarządzanie Dostarczaniem Produktów

Rysunek 15.1 Diagram procesu Sterowanie Etapem

178 I Sterowanie Etapem
• Uzasadnienie Biznesowe jest poddawane prze-
glądom.
• Produkty uzgodnione dla etapu są dostarcza-
ne zgodnie z ustalonymi standardami j akości,
w granicach uzgodnionych kosztów, nakładów
pracy i czasu oraz tak, aby w efekcie wspi erały
osiąganie zdefiniowanych korzyści.
• Zespół zarządza nia projektem skupia swoj ą
uwagę na realizacji projektu w granicach ustalo-
nych tolerancji.
15.3 KONTEKST
Proces Sterowanie Etapem opisuje pracę Kierow-
nika Projektu w trakcie codziennego zarządzan i a
etapem. Proces ten będ zie wykorzystywany dla
każdego etapu rea lizacyjnego w proj ekci e. Pod
koniec każdego etapu (z wyjątkie m etapu ostatnie-
go) zostaną wykonane dzialania w ramach procesu
Zarządzan i e Końcem Etapu (patrz Rozdział 17).
Proces Sterowanie Etapem jest zwykle stosowany po
raz pierwszy po zezwoleniu przez Komitet Sterujący
na realizację projektu, z tym że może on być opcjo-
nalnie zastosowany w trakcie etapu inicjowania pro-
jektu dla dużych lub złożonych projektów o dlugim
okresie inicjowania.
Do definiowania i kontrolowania prac, które nale-
ży wykonać, a także do ustalenia tolerancji dla
Kierownika(-ów) Zespolu(-ów) wykorzystywan e są
Grupy Zadań. W przypadku gdy Kierownik Projek-
tu pełni funkcję Kierownika Zespołu, Grupy Zadań
powinny być nadal wykorzystywane do definiowa-
nia i sterowania pracami poszczególnych czlonków
zespolu, którym przydzielono prace. W takim przy-
padku odniesienia do Kierownika Zespolu w poniż­
szym opisie procesu Sterowanie Etapem powinny
być traktowane jako odniesienia do poszczegól-
nych czlonków zespołu, którym przydzielono prace.
N ajwa żniejsze dla ostatecznego sukcesu projektu
jest co dzienne sterowanie prowadzonymi pracami.
W t rakcie ca łego etapu sk łada się to na cykl obej-
mujący:
• zezwolenie na wykonanie pracy;
• monitorowanie informacji o postępie tej pracy,
lącznie z zatwierdzaniem wykonanych Gru p
Zadań;
• dokonywanie przeglądu sytuacji (w tym doty-
czącej jakości produktu) i uruchamianie nowych
Grup Zadań;
• raportowanie okresowe;
• wychwytywanie, ocenę i postępowanie z zagad-
nieniami i ryzykami;
• podejmowanie wszelkich niezbędnych działań
korygujących.
Pod koniec ostatniego etapu rea lizacyjnego będz i e
uruchomiony proces Zamykanie Projektu (patrz
Rozdzial 18).
15.4 DZIAŁANIA
Dzialania w ramach Sterowania Etapem są realizo-
wane przez Kierownika Projektu i obejmują:
• Grupy Zadań:
• Zezwalanie na wykonanie Grupy Zadań.
• Przeg l ąda nie stanu Grupy Zadań .
• Odbieranie za kończonych Grup Zadań .
• Monitorowanie i raportowanie:
• Przeg l ądanie stanu etapu.
• Raportowanie okresowe.
• Zagadnienia:
• Wychwytywanie i analizowanie zagadnień
i ryzyk.
• Przekazywanie zagadnień i ryzyk na wyższy
szczebel zarządzan i a.
• Podejmowanie dzialań korygujących.
15.4.1 Zezwalanie na wykonanie Grupy
Zadań
Gdyby osoby zaa n gażowa ne w projekt same decy-
dowaly o momencie rozpoczęcia prac, prowadzilo-
by to do chaosu. Zespól{-ly) projektowy musi mieć
pewien poziom autonomii, ale w projekcie będzie
istnial szerszy krąg zagadnień, których świadomości
nie można oczekiwać od calego zespolu. Dlatego też
ważne jest, aby prace zaczynały się oraz byly konty-
nuowane wylącznie za zgodą Kierownika Projektu.
Środkiem służącym temu jest opracowywanie, wyko-
nywanie i dostarczanie wykonanych Grup Zadań .
Grupa Zadań może zawierać fragmenty Planu Pro-
jektu, Planu Etapu lub Dokumentacji Inicjowania
Projektu lub po prostu odniesienia do nich.
Grupa Zadań powinna obejmować prace służące
wytworzeniu jednego lub większej liczby p roduk-
tów. Jeżeli wytworzenie danego produktu wymaga
więcej niż jednej Grupy Zadań, należy go podzielić
na dalsze produkty i sporządzić dla nich osobne
Opisy Produktów.
 Sterowanie Etapem I 179

Plan E1apu Zezwalanie na UAtUłlniC Plan Elapu

wykonanie Grupy Zadań (bietący etap)

Opisy Produklów
.,,,._.,, Grupa (-y) Zada ń

Dokumentacja
....,.....,., Zapisy Obieklu
Inicjowania Projektu Konfiguracji
(część)

-
... - - - - .•
1Mechanizmy sterowania
Ullkt~
Rejestr Jakolci
1
'„
- -
projektem
....
„ „ •
I

StrategiaZa rządzania ""'"~ Rejestr Ryzyk

Jakolcią

Ulł\tułW(
Strategia Zarządzania Rejestr Zagadnień
Konfiguracją

·zczwófen1e na
Plan Zespolu ' r.wyko'.!a".i.'.'. a
ru-·· ad

,- -
-
,• Działania korygujące '
-,

'' - „ ____ ,
,- - -
' Nowa Grupa Zadań
--.
''
'- -- -
Zezwolenie na
- j
'
I realizację etapu I

Zatwierdzony Plan
I Nadzwyczajny I

Rysunek 15.2 Zezwalanie na wykonanie Grupy Zadań - schemat działania

Zdarzeniami, które zwykle powoduj ą wydanie przez lub zezwalania na zmiany Grup Zadań, na których
Kierownika Projektu zezwolenia na wykonanie wykonanie zezwolono.
Grupy Zadań są :
Rysunek 15.2 przedstawia elementy wejściowe i wyj-
• zezwolenie na realizację etapu - Komitet ściowe tego działania.
Sterujący zezwala na rea l izację Planu Etapu;
PRINCE2 zaleca wykonanie następujących czynności:
• zatwierdzenie Planu Nadzwyczajnego -
Komitet Sterujący zezwala na realizację Planu • Przejrzeć Plan Etapu dla bieżącego etapu zarząd­
Nadzwyczajnego; czego w celu sprawdzenia:
• konieczność zlecenia nowej Grupy Zadań - wynik • które produkty mają być wytworzone;
przeglądu stanu etapu (patrz sekcja 15.4.4); • przewidywanych kosztów i nakladów pracy
• dzialanie korygujące - w odpowiedzi na zagad- na ich wytworzenie;
nienie lub ryzyko. • dopuszczalnych tol erancji.
Dzialanie korygujące jest wykorzystywane do • Przejrzeć Dokumentację Inicjowania Projektu
zezwolemia na wykonanie nowych Grup Zadań w celu wyjaśnienia:
180 I Sterowanie Etapem

• wymag anych mechanizmów sterowania • zdefiniować wszelkie ograniczenia, które

projektem (na przykład ustaleń dotyczących
raportowania postępów);
• w ymaganych st andardów j akości, zdefinio-
w anych w Strategii Zarządzan i a Jakości ą;
• j eżel i j a kieś produkty maj ą być przekaza-
ne - sposobu ich przekazania (zgodnie ze
Strateg i ą Zarządzan ia Konfi guracją).
• Zdefi ni ować każd ą Grupę Zadań, która ma być
zatwierdzona do realizacj i (lub zmieniona).
W tym celu należy:
• uzyskać odpowiednie Opisy Produktów
w celu ich wlączenia do Grupy Zadań;
• ok reśl ić techniki, procesy i procedury do
zastosow ania;
• zdefiniować punkty styku z innymi produkta·
mi, które nale ży utrzym ać;
• zdefin iować punkty styku związane z eksplo-
mogą mieć zastosowanie;
• okreś lić sposoby raportowania, postępowa ­
nia z zagadnieniami oraz przekazywania ich
na wyższy szczebel zarzą dza nia;
• zdefin i ować metodę zatwierd zania;
• dostarczyć odpowiednie materi aly referen-
cyjne (np. Plan Etapu, Opisy Produktów).
• Dokonać przeg l ą du Grupy Zadań z Kierownikiem
Zespolu i upewnić się, że Kierownik Zespolu ją
zaakceptowal oraz zezwolić na rozpoc.zęcie prac
(patrz Rozdzial 16).
• Dokonać przeglądu Planu Zespolu Kierownika
Zespolu (lub tylko wyciągu z tego planu, obej-
mującego tzw. kamienie milowe, jeżeli z uwagi
na uwarunkowania komercyjne nie jest wskaza-
ne, aby Kierownik Projektu zapozna! s i ę z jego
treścią) i zaktua l izować Plan Etapu w celu odno-

atacją i utrzymaniem, które na leży zapewnić;
• określić wymogi zarządzania konfiguracją;
• określić wspólne uzgodnienia dotyczące
nakładów pracy, kosztów, dat rozpoczęcia
i zakończenia prac, kamieni milowych oraz
tolerancji;
towania terminów uzgodnionych dla wydanej
Grupy Zadań.
• Zaktualizować Zapisy Obiektu Konfiguracji w celu
odnotowania treści wydanej Grupy Zadań.
• Zaktualizować Rejestr Jakości planowanymi
czynnościami zarządzania jakością. Skonsulto-
wać z Nadzorem Projektu, czy zidentyfikowani

Tabela 15.1 Zezwalanie na wykonanie Grupy Zada ń - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwi erdzający - potwierdza odbiór >.
c
a.
E ..:.t. <»-
·- ....
....
11)

Ol
c
o::
11)
:i
..:.t. -a.o
:i
....:i t:
o
·-
V
o
.... ~ :: Cll ....
:i ..:.t. "O
o..
'ii!
11)•
N
..:.t.
~
11)
t:
o
.... "'
Cll
..:.t.
·- Cll

·-o......o o......o
Cll
~
:i

·-
V
11)
V
·-
c
-o :::>
o
o
o..
..:.t.
N
..:.t.
·-
:i
"O
·-c
N
o c>- >-
c
c
::
c
:: .... ·-....Cll
V
o
....
11) :: :: :: o
.... o
....
'0
N 11)
o..
a. ·-
Produkt Czyn ność
Ol
....
o
Cll
....
N
o.. - -
•O
\!)
•O
\!) ~
Cll
~
Cll -o
z
11)
~
"'a.
o
Gru pa Zadań Wytworzyć w (Z) K A26
Zapisy Obiektu Konfiguracji Utworzyć/Ua ktualnić z (K) K w AS
Rejestr Jakości Uaktualnić K (K) K w A23
Rejestr Ryzyk Uaktualnić w A25
Rej estr Zagadnier1 Uaktualnić w A12
Plan Zespolu Przej rzeć K (W)
Plan Etapu U a ktualn ić w (K) K A16
 Sterowanie Etapem I 181

Pian Etapu . Przeglądanie stanu U.Jktwlńtt Plan Etapu

Grupy Zadań

UllklUlllnl( Zapisy Obiektu

Grupa(·y) Zadań Konfiguracji

Ualo:.h.łołlnit
Raport(-y) z Punktu Rejestr Ryzyk
Kontrolnego

U4kt...loi(
Rejestr Zagadnień
Rejestr Jakoki

Ullktu31nl(
Grupa Zadań
Plan(-y) Zespolu(-ów)

Rejestr Ryzyk

Rysunek 15.3 Przeglą danie stanu Grupy Zadań -schemat działania

i wybrani kontrolerzy jakości są do zaakcepto-
w ania.
• W razie konieczn ości zaktual i zować Rejestr Ryzyk
zgodnie ze Strateg i ą Zarządzania Ryzykiem.
• W razie konieczności zaktua l izować Rejestr
Zagadnień.
Tabela 15.1 przedstawia obowiązki związane
działaniem .
15.4.2 Prze glądanie stanu Grupy Za d a ń
Dzia ła n i e
to umożl iwia przeprowadzanie regu-
larnej oceny stanu Grup(-y) Zadań. Częstot liwość
i forma lizm tego dzi ałan i a będą zwykl e dostoso-
w ane do częstotl iwości raportowania okreś l onej
w Grupie(-ach) Zadań i zgodne z Planern Etapu
bieżącego.
Rysunek 15.3 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności
dla każdej Grupy Zadań w trakcie jej realizacji:
• Zebrać i dokonać przeglądu informacji o postę­
pie prac zawartych w Raporcie z Punktu
Kont rolnego dla realizowanej Grupy Za d ań.
W tym celu na l eży:
• oszacować przyb l iżony czas i nakład pracy
potrzebny do ukończen i a n i ezakończonych
prac (w tym również prac j eszcze nierozpo-
czętych);
• dokonać przeglądu Planu Zespołu
z tym
z Kierownikiem Zespolu (lub wyciągu z tego
planu obejmującego tzw. kamienie milowe,
jeżeli z uwagi na uwarunkowania komercyj-
ne nie jest wskazane, aby Kierownik Projektu
za pozna ł się z jego treści ą) w celu upewni e-
nia si ę, że prace zostaną zakończone w ter-
minie oraz w granicach budżetu;
• dokon ać przeg lądu wpisów w Rejestrze
Jakości w celu zapoznania się z aktualnym
stanem dzia la ń dotyczących zarządzania
jakością;
• potwierdzić, żeZapisy Obiektu Konfiguracji
dla każdego produktu z Grupy Zada ń odpo-
wiadają faktycznemu statusowi produktu.
• W razie konieczności zaktua l izować Rejestr
Ryzyk i Rejestr Zagadnień.
182 I Sterowanie Etapem

Tabela 15.2 Przeglądanie stanu Grupy Zadań - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej nieza l eżny od wytwórcy
>.
Zatwierdzający - potwierdza odbiór c
a.
E .:,/; Cl>-
·-c
IO
.....
en
o ~
~
o
IO
u
~
....
:J
.:,/;
QI
-:J
o
a. ....
:J
....:J
.:,/;
t:
o
"tJ
.....
o..
.....
IO
IO'
N
u
.:,/;
>. t:o
IO
·~
o
.....
o.. N
V>
QI
.:,/;
QI
·~
QI
·~
o
.....
...
~
:J

·~
u ·-c •N
o .:,/; .:,/;
o
..... o.. :J
IO
N "tJ
::>
>. >.
·-c ·-c o..
.....
QI
·-
"tJ
e
c o c c ~ ~
u
..... o..
IO ~
~ ~ o
..... o
..... '°
N IO
a. ·-"'a.
Produkt Czynność o
en
.....
QI
N
.....
o.. - -
•O
\.!)
·O
\.!) ~
QI
~
QI
"tJ
z
IO V>

5: o
Raport z Punktu Kontrolnego Przejrzeć K (W) A3
Plan Zespołu Przejrzeć K (W)

Plan Etapu Ua ktua l n i ć w K A16

Zapisy Obiektu(-ów) Konfiguracji Uaktua l n i ć z (K) K w AS
Rejestr Ryzyk Uaktua l nić w A25
Rejestr Zagadnień Uaktualnić w A12

• Zaktualizować Plan Etapu dla bieżącego etapu, 15.4.3 Odbieranie za kończonych Grup
uwzględniając dotychczasowe dane o stanie Za dań
faktycznym, aktualne prognozy i korekty.
J eżel i
prace zosta ły przydzielone osobom lub zespo-
Tabela 15.2 przedstawia obowi ązki związa n e z tym łom, powinno istnieć odpowiednie potwierdzenie,
dzialaniem. że prace te zostały zako ńczone i zatwierdzone.

Po zatwi erdzeniu wszelkie później sze zmiany pro-

duktu(-ów) muszą być poddane procedurze stero-
wania zmianami (patrz Rozdział 9). To powinno być

/ 'I
Zakończona Grupa Zapisy Obiektu
Odbieranie zakończonych Potwietdzk .
Zadań Grup Zadań . Konfiguracji
\. .....

Uaktutilni<:
Plan Etapu Plan Etapu

Rejestr Jakości

Zapisy Obiektu
Konfiguracji

Rysunek 15.4 Odbieranie zakończonych Grup Zadań - schemat działania

 Sterowanie Etapem I 183

Tabela 15.3 Odbieranie zakończonych Grup Zadań - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej nieza leżny od wytwórcy
Zatwierdzający - potwierdza odbiór >-
c
o.
E ~
.....,,
G»
·-
m
.....
O">
o
..... >-
.,..
c
~
o
m
u
~
....:i
~
QJ
-:i
o
o. ....
:i
....
:i
~
o
"O

-
u ·~ QJ
o._ ~
....
m o
..... "' ~ ·~
:i
o
m
·~
u
N
u
·-c >-
·N "'
o
o._
~
N
~
QJ QJ
·~
o
.....
.....
o._
j;i
:i
m
N "O
::>
>-
Cl
>-
·-c ·-c o._
.....
QJ "O
o
c
o c c ~ ~ •O
u
..... .....
o._
m ~ ~ ~ o
..... o
..... N m
o. .,,
·-o.
- -
QJ
O"> •O •O "O
..... N QJ QJ

5"'
..... m
Produkt Czynność o o._ \!) \!) ~ ~ z o
Zapisy Obiektu Konfiguracji Potwi erdzić z (K) K w AS

Plan Etapu Uaktualnić w K A16

automatycznie elementem każdej stosowanej meto-
dy zarządzania konfiguracją.
Rysunek 15.4 przedstawia elementy wej ści owe i wyj-
ściowe tego działania .
PRINCE2 zaleca wykonanie następujących czynności:
• Upewnić się, że
Kierownik Zespołu zakończył
prace zdefiniowane w Grupie(-ach) Zadań.
• Sprawdzić, czy zapisy w Rejestrze Jakości doty-
czące produktu(-ów) są kompletne.
• Upewn ić si ę, że każdy produkt w Grupie Zadań
został zatwierdzony (zgodnie z obowiązkami
dotyczącym i jakości określonymi w jego Opisie
Produktu).
• Potwierdzi ć, że Zapisy Obiektu Konfiguracji dla
każdego odebranego produktu zostały zaktuali-
zowane.
• Zaktualizować Plan Etapu w celu zaznaczenia, że
Grupa Zadań została zakończona.
Tabela 15.3 przedstawia obowiązki związane
dzi ałaniem.
15.4.4 Przeglądanie stanu etapu
Jeżeli stan realizacji projektu nie jest sprawdzany
reg ularnie, istnieje n iebezpieczeństwo, że wymkn ie
si ę on spod kontroli. Należy zachować równowagę
pomiędzy planowaniem z wyprzedzeniem a reago-
waniem na wydarzenia.
się zda rzyćw przyszłości (łącznie z zagadnieniami
i ryzykami). Konieczne j est więc zapewnienie stałego
napływu informacji, dającego ogólny obraz fa ktycz-
nych postępów, oraz prostych, niezawodnych syste-
mów monitoringu do dostarczania tych informacj i.
Dlatego celem tego działania jest utrzymanie
dokladnego i aktualnego obrazu postępu realizowa-
nych prac oraz stanu zasobów.
Działanieto odbywa się z częstotl i wością określoną
w Planie Etapu, ale może być zainicjowane polece-
niem Komitetu Sterującego lub stanowić część anali-
zy nowych zagadnień i ryzyk.
Rysunek 15.5 przedstawia elementy wej ści owe i wyj -
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeglądu postępów rea lizacji etapu.
W tym celu należy:
• dokonać przeglądu Raportów z Punktu
z tym Kontrolnego za dany o kres;
• dokonać przegląd u przewidywanego i fak-
tycznego wykonania bi eżącego Planu Etapu;
• wystąpić do Wsparcia Proj ektu o przygo-
towanie Zestawienia Statusu Produktów
w celu określen ia wszelkich różnic po między
postępam i planowanymi i postępami uj ętymi
w raportach a postępami faktycznym i;
• sprawdzić zagadni enia związane z jakością,

W celu podejmowania świadomych decyzji i spra- przedstawione w Rejestrze J akości;

wowania racjonalnej kontroli trzeba wiedzieć, co • sprawdzi ć Rejestr Ryzyk pod kątem nowych
się faktycznie zdarzylo, aby móc to porównać z tym, lub zrewidowanych ryzyk i ocenić ich wpływ
czego oczekiwano i wziąć pod uwagę to, co może
184 I Sterowanie Etapem

Plan Etapu
, - - - -'
Przeglądanie stanu etapu : Ozialania korygując:)
"-----
- -
,- -,

Rejestr Jakości ..'Zagrożona

„(
'
'- ----
tolerancja)

Zbllż aj4cy się

I
koniec etapu
Zestawienie Statusu
Produktów
.I' Zbliżający s i ę
koniec projektu
"ł
,- - -, -
Raport(-y) z Punktu : Nowa Grupa Zadań )
Kontrolnego
"----- ...
,
... Prolba o wytyczne I
Rejestr Zagadnień

Uakt ualnił
. Rejestr Ryzyk

Rejestr Ryzyk

U.attuflni(
Rejestr Zagadnień
Dokumentacja
Inicjowania Projektu

Uaktualni( Plan Etapu

Uzasadnienie
Biznesowe
Ułkt1,.1;,lni( Dziennik
Doświadczeń

Plan Projektu

U<il:tualni( Raport
o Zagadnieniu
Plan Przeglądu
Korzyści

•
,, - - - --,
Dzia łania korygujł}Ce
'
"------
j Wytyczne Komitetu""
Steruj ącego I

Rysunek 15.5 Przeglądanie stanu etapu - schemat działania

na Uzasadnienie Biznesowe, Plan Etapu lub • ocenićWYkorzystanie zasobów w okresie,

Plan Projektu;
• sprawdzić Rejestr Zagadnień, czy nie WYda-
rzyło się coś w projekcie lub poza projek-
tem, co będzie mieć wplyw na Uzasadnienie
Biznesowe, Plan Etapu lub Plan Projektu;
• sprawdzi ć status wsze lkich dzia łań koryg ują­
cych;
którego dotyczy przegląd i ich dostępność na
pozostały czas trwania etapu (łub projektu).
Sprawdzić, czy nie WYstąpiły jakieś zmiany
dostępności zasobów oczekiwanej w przyszłości;
• sprawdzić Plan Przeg l ą d u Korzyści, czy nie
n a l eży przeprowadzić jak ichś przeglądów
korzyści oraz wykonać je w razie konieczności.
 Sterowanie Etapem I 185

Tabela 15.4 Przeglądanie stanu etapu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór >.
c
a.
E -" QI-
·-
ro
....
Ol
o
.... Ci'
c:
s:o ro
u
s:
::I
.....
.:.!
QI
·~
o
-
::I
o
a. ::I
.....
.:.!
::I
.....
.:.!
QI
t:
o
"O
::I
o..
..... -" ro .... "'
ro ""
N
u >. t:
o
o..
QI
N
QI
·~
o
·~
o
....
o..
~
·~
u
ro c ·N
:::> o -" -"
·- ....
o..
::I
"O
·-c
N "O
o >.
c
>.
c
c:
s:o
c:
s:o .... ·-u....QI o
....
ro s: s: s: .... ....
·O
N ro
a.
o..

Produkt Czynność o
....
Ol QI
N
....
o.. - -
•O
~
•O
~
QI
·-
~
QI
~
"O
z
ro
s"'
.~

o
a.

Rejestr Ryzyk Uaktualnić w A25

Rejestr Zagadn i eń Uaktua l nić w A12
Plan Etapu Uaktua l nić w K A16
Dziennik Doświadczeń Uaktualnić w A14
Raport o Zagadnieniu Uaktualnić w A 13

• W oparciu o powyższą analizę zdecydować, czy • wnioskować o sporządzenie Zestawienia

należy wykonać jakieś czynności, na przykład:
• zezwo l ić na wykonanie Grupy Zadań
(sekcja 15.4.1 );
• sporządzić Raport Okresowy (sekcja 15.4.5),
jeżeli wymaga t ego Strategia Zarządzan i a
Komunikacją;
• wychwycić oraz przeanalizować zagadnienia
i ryzyka (sekcja 15.4.6);
• przekazać zagadnienia i ryzyka na wyższy
szczebel zarządzania (sekcja 15.4. 7), jeżeli
zagrożone są tolerancje;
• podjąć dzialania korygujące (sekcja 15.4.8);
• zwrócić się do Komitetu Sterującego
o wytyczne (w razie potrzeby dostarczyć mu
Raport o Zagadnieniu);
• zanotować w Dzienniku Doświ adczeń wszel-
kie zidentyfikowane doświadczenia;
• kontynuować projekt zgodnie z planem.
• Przejrzeć i uaktualnić
Rejestr Ryzyk i Rejestr
Zagadnień, jeśli to konieczne.
• Zaktualizować Plan Etapu, jeżeli lączna ocena
zmienia jakieś dotychczasowe prognozy.
• Jeżeli odpowiedzialność za którykolwiek z pro·
duktów ma być przekazana klientowi w ramach
Statusu Produktów dla przekazywanego
wydania;
• upewnić się, że:
• produkty został y zatwierdzone przez
osoby wymienione w ich Opisie Produktu;
• produkty spełniają wszystkie kryteria
jakościowe lub są objęte zatwierdzonymi
ustępstwami;
• organizacje zajmujące się eksploatacją
i utrzymaniem są gotowe do przejęcia
odpowiedzialności za te produkty;
• przekazać produkty (patrz Rozdzial 18).
• Rozważyć, czy należy dokonać przeg l ądu
doświadczeń teraz, czy poczekać do późn i ejsze­
go przegląd u stanu etapu lub do zbl i żającego się
końca etapu.
• Jeże l i zb l iża się koniec bieżącego et apu Gak
wynika np. z Planu Etapu, zawartości Rejestru
Jakości, kamienia milowego itp.), przygotować
się do następnego etapu (patrz Rozdzial 17).
• Jeżeli zbliża się koniec ostatniego etapu, przygoto-
wać się do zamknięcia projektu (patrz Rozdział 18).
Tabela 15.4 przedstawia obowiązki związane z tym
dzia łaniem.

stopniowego przekazywania produktów, na l eży:

186 I Sterowanie Etapem

Raport(-y) z Punktu Raportowanie Spo1z4dlit Raport Okresowy

Kontrolnego okresowe (bieżący okres)

Rejestr Ryzyk

Rejestr Zagadnień

Rejestr Jakości

Dziennik
Doświadczeń

Zestawienie Statusu
Produktów

Plan Etapu

Dziennik Projektu

Raport Okresowy
(poprzedni okres)

Dokumentacja
Inicjowania
Projektu

Strategia
Zarządzania
Komunikacia

Rysunek 15.6 Raportowanie okresowe - schemat działania

15.4.5 Raportowanie okresowe Rysunek 15.6 przedstawia elementy wejściowe i wyj -

ściowe tego d ziałania.
Kierownik Projektu musi dostarczać Komitetowi Ste·
rującemu skrótowej informacji o stanie etapu i pro- PRINCE2 zaleca wykonanie n astępujących czynności:
jektu oraz przekazywać interesariuszom inne infor·
• Zestawić informacje z Raportów z Punktów
macje z częstotliwością określ oną przez Komitet Ste-
Kontrolnych, Rejestru Ryzyk, Rejestru Zagadnień,
rujący i udokumentowaną w Strategii Zarządzania
Rejestru Jakości, Dziennika Doświadczeń,
Komunikacją. Więcej szczegółów na temat kontroli
Zestawienia Statusu Produktów oraz wszelkie
postępów można znaleźć w Rozdziale 10.
istotne korekty Planu Etapu dla bieżącego okresu
 Sterowanie Etapem I 187

Tabela 15.5 Raportowanie okresowe - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej n i ezależny od wytwórcy
Zatwierdzający - potwierdza odbiór

c>-
a.
E Q).

...Ol
li)
.::.!
·-
~
c li)
V
...
:i
.::.! -o
:i
...
:i ~
o
...o ~ o ~ ·-...o
QI
a. ....
:i .::.! 'U

·-o... ·-...o
QI
Q. nr .::.!
>.
li)
~
"'
QI
.::.!
QI ....
:i

·-Iii
N Q.
u N .::.!
u c
·N o Q. :i
li) :J a .::.!
·-c .::.!
·-c Q. QI 'U
·-c
N 'U
o c>- >-
c ~ ~
...
•O
·-...u ...o
~ Q.
li)
~ ~ ...o ...o N li)
a. ·-"'a.
Produkt Czynność
...
Ol
o
QI
N
'-
Q. - -
'()

~
•O
~ ~
QI
~
QI 'U
li)
z s
"' o
Raport Okresowy Sporządzić w K A11

sprawozdawczego (informacje pochodzą z prze- Przed podjęciem

decyzji określającej kierunek dzia-
g l ądu stanu etapu - patrz sekcja 15.4.4). łania, każde zagadnienie czy ryzyko powinno zostać

• Zestawić l istę działań korygujących (odnotowa-
nych w Dzienniku Projektu i/łub zarejestrowa -
nych w Rejestrze Zagadnień), podjętych w okre-
sie sprawozdawczym. Upewni to przykladowo
Komitet Sterujący, że Kierownik Projektu dzi ała
w granicach uzgodnionych tolerancji (informacje
te wynikają z podejmowanych działań korygują­
cych - patrz sekcja 15.4.8).
• Przejrzeć Raport Okresowy z poprzedniego okre-
su sprawozdawczego.
• Sporządzić Raport Okresowy z bieżącego okresu
sprawozdawczego.
• Przekazać Raport Okresowy Komitetowi
Sterującemu oraz innym odbiorcom określonym
w Strategii Zarządza nia Komun i kacją.
Tabela 15.5 przedstawia obowiązki związane z tym
działaniem.
15.4.6 Wychwytywanie i analizowanie
zagadnień i ryzyk
Podczas zarządzania projektem wystąpią różne
zagadnienia oraz mogą być zidentyfikowane
różn e ryzyka. Będą się one pojawialy w sposób
przypadkowy i trzeba będzie j e wychwycić w spój-
ny i niezawodny sposób. Każdy członek zespołu
projektowego, kierownictwa organizacji lub
programu czy też inny interesariusz może zgłosić
zagadnienie lub ryzyko.
zarejestrowane, a następn ie ocenione pod kątem
jego wpływu na projekt.
Więcej szczegółów na temat zarządzania ryzykiem
można znaleźć w Rozdziale 8.
Więcej szczególów na temat procedur sterowania
zagadnieniami i zmianami można zna l eźć w Roz-
dziale 9.
Rysunek 15.7 przedstawia elementy wejściowe i wyj-
ściowe tego dzialania.
PRINCE2 zaleca wykonanie następujących czynności:
• Jeżeli Kierownik Projektu może rozwiązać
zagadnienie nieformalnie, powinien to uczynić
oraz odnotować w Dzienniku Projektu (wię­
cej informacji na ten temat można zna l eźć
w Rozdziale 9).
• W przypadku zagadnień, które wymagają postę­
powania formalnego (patrz Rozdział 9), na l eży:
• sp rawdz i ć wymagania procedury sterowa-
nia zagadnieniami i zmianami w Strategii
Zarządzania Konfiguracją;
• wpisać zagadnienie do Rejestru Zagadnień
od razu po jego wychwyceniu;
• określić kategorię zagadnienia (czy j est to
wniosek o wprowadzenie zmiany, odstęp­
stwo, czy problem/obawa?);
• ocenić wagę zagadnienia;
188 I Sterowanie Etapem

, - - - -, Wychwytywanie Uaktułlni( Dziennik

•' Nowe zagadnienie
'' -
,-
-- -
- -
- j
- ,
'
i analizowanie zagadnień
i ryzyk
Projektu

'
''
'- -----
Nowe Ryzyko '
Sp0<24<łti((
Raport
o Zagadnieniu

Plan Et apu
Uaktvttlflil
Rejestr
Zagadnień

Dokumentacja
Inicjowania Projektu Uaktua ł"I( Rejestr
Ryzyk

Uzasadnienie
Biznesowe Wniosek o poradę
I

Plan Projektu

Strategia Zarządzania
Komunikacją

Przeglądanie stanu
etapu

Rysunek 15. 7 Wychwytywanie i analizowanie zagadnień i ryzyk - schemat działania

• ocenićpriorytet zagadnienia (dla odstępstw • ocenić ryzyko w odniesieniu do Planu Etapu,

i wniosków o wprowadzenie zmiany);
• ocenić wpływ zagadnienia na Plan Etapu,
Plan Projektu i Uzasadnienie Biznesowe;
• ud okumentować zagadnienie, sporządzając
Raport o Zagadnieniu;
Planu Projektu i Uzasadnienia Biznesowego
oraz zaplanować wybra n ą reakcję na ryzyko;
• po in formować o stanie ryzyka zgodnie ze
Strateg i ą Zarządzania Ryzykiem i sprawdzić
Strategię Zarządzan i a Komunikacją w celu

• poinformować o statusie zagadnienia zgod-
nie ze Strategią Zarządzan i a Konfiguracją
i sprawdzić St rategię Zarządzania Komunika -
cją w celu ustalenia, czy i stnieją jakieś strony
zewnętrzne, które powinny zostać poinfo r-
mowane o zagadnieniu.
ustalenia, czy istnieją jakieś strony zewnętrz­
ne, które powinny zostać poinformowane
o tym ryzyku.
• J eżelikonieczne jest podjęci e działania kory-
gującego, uzyskanie wytycznych od Komitetu
Steruj ącego albo przekazanie zagadnienia lub

• W przypadku ryzyk należy (więcej informacji na ryzyka na wyższy szczebel zarządzania, nale-
ten temat można zna l eźć w Rozdziale 8): ży najpierw dokonać przeg l ądu stanu etapu,

• sprawdz i ć wymagania procedury zarządzania aby można było rozważyć pelny obraz sytuacj i
ryzyk iem w Strategii Zarządzania Ryzykiem; (patrz sekcja 15.4.4).
• wpisać ryzyko do Rejestru Ryzyk od razu po Tabela 15.6 przedstawia obowiązki zwi ązane z tym
jego wychwyceniu; dzialaniem.
• określić zdarzenie, z którym wiąże się ryzyko
i opisać j ego przyczyny oraz skutki;
 Sterowanie Etapem I 189

Tabela 15.6 Wychwytywani e i analizowanie zagadnień i ryzyk - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej n i eza l eżny od wytwórcy
Zatwierdzający- potwierdza odbiór >-
c
a.
E .:.'.
·- ... ...
41>-
ro
'-
Ol
o
'- ~
c
$
o
ro
V
$
~

.:.'.
QI
·~
o
-a.
~
o
....
~
....
~
.:.'.
QI
VI
o
"O
~
a..
..... CO' .:.'. ro
.....
VI .:.'. · ~
.....
o
ro
·~
V
N
V
c
>-
·N
VI
o
'-
a.. N
QI QI
· ~
o '-
a..
.:.'.
~
ro :::> o .:.'.
·- .:.'.
·- '-
a.. QI "O
N
c
"O
o >-
c >-
c
c
$
c
$ '-
•O
·-'-
V
o
'-
a..
ro $ $ $ o
,_ o
,_ N ro
a.
- -
QI VI
,_
Ol •O •O "O
,_
N QI QI
·- ro VI a.
Produkt Czynność o a.. \.? \.? ~ ~ z 3: o
Dziennik Projektu Uaktualn i ć w A7
Raport o Zagadnieniu Sporządz i ć w A13
Rejestr Zagadn ień Uaktua l nić w A12
Rejestr Ryzyk Uaktua l nić w A25

15.4.7 Przekazywanie zagadnień i ryzyk
Etap nie powinien przekraczać tolerancji uzgodnio-
nych z Komitetem Sterującym. Kierownik Projektu
może podejmować dzialania korygujące lub utrzy-
mywać status quo tylko wtedy, gdy prognozowane
w wyniku t ego zakończenie etapu (lub projektu)
pozostanie w granicach tolerancji ustalonych przez
Komitet Sterujący. Omawiane dz i ałan i e ma zastoso-
wanie tam, gdzie jakiekolwiek dzi ałan i e korygujące
pod kontrolą Kierownika Projektu nie uchroni etapu
(czy projektu) od wyjści a poza granice ustalonych
tolerancji. Ma ono zastosowanie w przypadku
wszelkich rodzaj ów zagadnień i ryzyk (bądź ich
połączenia), kt órych nie możn a rozwi ązać, pozosta-
jąc w g ran icach tolerancji określ onych przez Komitet
Sterujący.
Ponieważ zebranie informacji n i ezbędnych do
sporządzenia Raportu Nadzwyczajnego może być
czasochłonne, zaleca się j ak najwcześniejsze poinfor-
Kierownik Projektu powinien wykonać każdą decy-
zj ę Komitetu Sterującego podj ętą w odpowiedzi na
przekazaną i nformacj ę.
Przekazywanie zagadnień i ryzyk na wyższy szczebel
stanowi dobrą praktykę i nie powinno być postrze-
gane jako porażka. Im wcześniej przekazywane są
zagadnienia, tym więcej jest czasu na wprowadze-
nie wszelkich działań koryg ujących.
Więcej szczegółów na temat zarządzan ia ryzykiem
można znaleźć w Rozdziale 8.
Więcej szczegółów na temat sterowania zagadnie-
niami i zmianami można znaleźć w Rozdziale 9.
Więcej szczegółów na temat za rządzan i a z wykorzy-
staniem tolerancji można znaleźć w Rozdziale 10.
Rysunek 15.8 przedstawia elementy wej ściowe i wyj-
ściowe tego dzi ałan i a.
PRINCE2 zaleca wykonanie następujących czynn ości :

mowanie o za i stn i ałej sytuacji Komitetu Sterującego.
Ki erownik Proj ektu może wobec tego przeprowa-
dzić to działan i e dwuetapowo poprzez: wcześn i ejsze
powiadomienie Komitetu Steruj ącego o przewidy-
wanej sytuacji nadzwyczajnej w celu przygotowania
na nią Komitetu Steruj ącego, a następnie przekaza-
nie informacji dodatkowych w formie Raportu Nad-
zwyczajnego.
• Przeanalizować Plan Etapu w celu ok reślenia
wielkości występującego odchylenia i niezakoń­
czonych produktów oraz określenia możl iwych
konsekwencji w przypadku dalszego trwania
odchylenia.
• Przeana l izować Plan Proj ektu pod kątem stanu
realizacji projektu oraz całościowych skutków
wszelkich odchyleń (przy wykorzystaniu aktual-
nej wersji Dokumentacji Inicjowania Projektu).
190 I Sterowanie Etapem

,,.- - - -„
,' Zagrotona tolerancja ' J----.---... 1
Przekazywanie
Raport
Nadzwyczajny
'
"------ zagadnień i ryzyk

Uak:tuałni(
Dokumentacja Rejestr Zagadnień
Inicjowania Projektu

Uzasadnienie Rejestr Ryzyk

Biznesowe
•

Zgloszona sytuacja
nadzwyczajna
Plan Projektu

Raport
o Zagadnieniu
Plan Etapu
(bie~ący etap)

Raport
o Zagadnieniu

Rejestr
Zagadnień

Rejestr Ryzyk

Rysunek 15.8 Przekazy wanie zagadnień i ryzyk - schemat działania

Tabela 15.7 Przekazywanie zagadnień i ryzyk - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy

Zatwierdzający - potwierdza odbiór >.

c
a.
E ~
....
~
·-c
ł'O
....
O\
o
.... .,,.~
~
o
ł'O
u
~
....:i
~
Q) -o
:i

a. ....
:i ~
....:i "'
o
"O
c..
"13 N
~

>. ....
ł'O
·~

....o
c..
"'
Q)
N
~
Q)
·~
Q)
o
....
...
~
:i

·~
u
u
·-c ·N "'o ~ ~
·~
o
.... c.. :i
ł'O :J o ·-c ·-c c.. Q) "O
·-c
N "O
o >.
c
>.
c ~ ~
.... ·-....u o
....
~ o o •O
ł'O
a...
ł'O ~ ~ .... .... N
a.
Produkt Czynność
O\
....
o
N
Q)
....
a... - -
•O
I !)
<>
I!)
Q)
·-
~
Q)
·-
~
"O
ł'O
z 5
VI ·-
"'
a.
o
Raport Nadzwyczajny Sporządzić (Z) (K) (K) w K A10

Rejest r Zag adn i eń Uaktu a ln ić w A12

Rejestr Ryzyk Uaktua l nić w A2 5

Raport o Zagadnieniu Uaktua l nić w A 13

 Sterowanie Etapem I 191

• Określić możliwe sposoby uzdrowienia sytu-
acji i ocenić je w odniesieniu do Uzasadnienia
Biznesowego.
• Ocenić wpływ tych możliwych sposobów uzdro-
wienia sytuacji na Plan Etapu dla bieżącego
etapu. Należy rozważyć dostępność osób lub
grup osób posiadających umiejętności czy też
doświadczenie potrzebne do oceny tego
wpływu.
• Przedstawić sytuację, możliwe opcje i reko-
mendowane kierunki działania Komitetowi
Sterującemu w Raporcie Nadzwyczajnym.
Komitet Sterujący podejmie następnie decy-
zję, wybierając odpowiedni sposób działania
(który może zgadzać się lub nie z rekomen-
dacją Kierownika Projektu). Decyzja Komitetu
Sterującego może obejmować:
• prośbę o więcej informacji lub odrocze-
n ie terminu wyboru reakcji przez Komitet
Sterujący;
• zatwierdzenie, odłożenie decyzji lub odrzu-
cenie wniosku o wprowadzenię zmiany;
Więcej szczegółów na temat planowania można
znaleźć w Rozd ziale 7.
Więcej szczegółów na temat sterowania zagadnie-
niami i zmianami można znaleźć w Rozdziale 9.
Rysunek 15.9 przedstawia elementy wejściowe i wyj -
ści owe tego działania .
PRINCE2 zaleca wykonanie następujących czynności :
• Zebrać wszelkie n iezbędne informacje o odchy-
leniu (z Zapisów Obiektu Konfiguracji,
Rejestru Zagadnień, Rejestru Ryzyk, Raportu
o Zagadnieniu, Raportu Nadzwyczajnego,
wytycznych Komitetu Sterującego, Dziennika
Projektu).
• Zidentyfikować możliwe sposoby postępowania
z odchyleniem i wybrać najbardziej odpowiedni
sposób.
• Zainicjować działanie korygujące poprzez zezwo-
lenie na wykonanie Grupy Zadań (patrz sekcja
15.4.1).
• Zaktualizować Zapisy Obiektu Konfiguracji doty-

• udzielenie zgody na ustępstwo, odłożenie czące produktów, których dotyczy odchylenie.

decyzji lub odrzucenie wniosku o zgodę na • Zaktualizować Raport o Zagadnieniu (w razie

odstępstwo;
• zwi ększen ie tolerancji, których przekroczenie
jest przewidywane;
• polecenie Kierownikowi Projektu sporządze­
nia Planu Nadzwyczajnego, przy jednocze-
snym okreś l en i u, co Komitet Sterujący skłon ­
ny będzie zaakceptować (patrz Rozdział 17);
• polecenie Kierownikowi Projektu, aby przed-
wcześn i e zamknął projekt (patrz Rozdzial 18).
Tabela 15.7 przedstawia obowiązki związane z tym
działaniem.
15.4.8 Podejmowanie działań
potrzeby) w celu przedstawienia statusu działa­
nia koryg uj ącego .
• Zaktualizować Rejestr Zagadn ień, uwzględniając
wszelkie zmiany wynikające z działania korygują­
cego (lub w przypadku nieformal nego załatwie­
nia - za ktuali zować Dziennik Projektu, wp i sując
szczegóły i status działania korygującego).
• Zaktualizować Rejestr Ryzyk, uwzględniając
~sze lkie zmiany wynikające z działania korygu-
iącego.
• Zaktualizować Plan Etapu dla bieżącego etapu.
Tabela 15.8 przedstawia obowiązki związane z tym
działaniem.

korygujących
Zmian i poprawek projektu powinno się dokonywać
w sposób rozważny i racj onalny, nawet jeżel i wyda-
ją się one łatwe w zarządza niu i mieszczą si ę w gra-
nicach tolerancji.
Celem działania korygującego jest wybranie i (w gra-
nicach tolerancji etapu i projektu) wdrożenie działań,
które rozwiążą sprawę odchylenia od planu. Działa­
nia korygujące uruchamiane są w czasie przeglądu
stanu etapu (sekcja 15.4.4) i zwykle wiążą się z zale-
ceniami i wytycznymi otrzymywanymi od Komitetu
Sterującego oraz zagadnieniami zgłoszonymi przez
Kierowników Zespolów.
192 I Sterowanie Etapem

Dziennik Projektu Podejmowanie działań UaktualnK Dziennik Projektu

korygujących
~

Rejestr Zagadnień Uaktualni( Rejestr Zagadnień

Rejestr Ryzyk Uaktualni(. Rejestr Ryzyk

Raport o Zagadnieniu Uaktualnić Raport o Zagadnieniu

Plan Etapu Uaktua lnić Plan Etapu

Zapisy Obiektu Zapisy Obiektu

Uaktualnić
Konfiguracji Konfiguracji
~

t
,- - - -,
•
,- - - -,

____ )
Uaktualnić t

'.._ . '.._
.

- - -- -
I Dzia łania korygujące I Działan ia korygujące

Rysunek 15.9 Podejmowanie działań korygujących - schemat działania

Tabela 15.8 Podejmowanie działań korygujących - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej n ieza l eżny od wytwórcy >-

c:
a.
Zatwierdzający
E -"' ....W'
- potwierdza odbiór O)
,_
Ol
o
,_ >-
.,,,
u
·-c:
3
o
O)
u
3O)
....
::J
-"'
QI
·~
-o
::J

a. ....
::J
....
:i
-"'QI
VI
o
"O
o..
-.. N
-"'
>. 'I;;
o
,_
o..
VI
QI
N
-"'
QI
·~
o,_ ....
::J
-"'
O) u o ·~
o o..
· ~
u ·N ,_ ::J
c: => o -"'
·- ·- -"' o.. "O
·-.....QIu
O)
N "O
o >- >- c: c: ..... o
,_
c: 3 c: c 3 3
o •O o..
O)
3 3 o
..... ..... N O)
a. ·-a.
- -
VI
QI "O
Ol ·O ·O QI
..... N
..... QI O) VI

Produkt Czynność o o.. ~ ~ ~ ~ z 5 o

Rejestr Zagadn i eń Uaktualnić w A12

Rejestr Ryzyk Uaktualnić w A25

Raport o Zagadnieniu Uaktualnić w K A13

Plan Etapu Uaktua l nić w K A16

Zap isy Ob iektu Konfigu racj i Uaktua l nić w (K) K AS

Dzienn ik Projektu Uaktua l nić w A7

16 Zarządzanie Dostarczaniem Produktów

16.1 PRZEZNACZENIE 16.3 KONTEKST

Proces Zarządzanie Dostarczaniem Produktów służy
do zarządzania powiązaniami pomiędzy Kierowni-
kiem Projektu a Kierownikiem(-ami) Zespołu(-ów)
przez wprowadzenie formalnych wymagań doty·
czących przyjmowania do wykonania, wykonywania
i dostarczania wykonanych prac w projekcie.
Rola Kierownika(-ów) Zespołu(-ów) polega na koor-
dynowaniu obszaru prac, z którego zostanie dostar-
czony jeden lub więcej produktów projektu. Zespoły
mogą być wewnętrzne lub zewnętrzne w stosunku
do organizacji klienta.
16.2 CEL
Celem procesu Zarządzanie Dostarczaniem Produk-
tów jest zapewnienie, że:
• prace nad produktami, przydzielone zespołowi,
zostały zatwierdzone i uzgodnione;
• Kierownicy Zespołów, członkowie zespołów
i dostawcy mają jasny obraz tego, co ma być
wytworzone oraz oc.zekiwanych nakładów pracy
i kosztów oraz terminów;
• planowane produkty są dostarczane zgodnie
z oc.zekiwaniami i w granicach tolerancji;
• dokładne informacje o postępach są dostarcza-
ne Kierownikowi Projektu z uzgodnioną często­
tliwością, aby zapewnić, że oczekiwaniami się
zarządza.
Proces Zarządzanie Dostarczaniem Produktów
postrzega projekt z perspektywy Kierownika Zespo-
łu, podczas gdy proces Sterowanie Etapem postrze-
ga projekt z perspektywy Kierownika Projektu.
Kierownik Zespołu zapewnia, że zespół wytwarza
i dostarcza produkty na potrzeby projektu:
• przyjmując i sprawdzając Grupy Zadań, na któ-
rych wykonanie zezwol i ł Kierownik Projektu;
• zapewniając, że punkty styku (interfejsy) zidenty-
fikowa ne w Grupie Zadań są utrzymywane;
• tworząc Plan Zespołu dla przydzielanych Grup
Zadań (tam, gdzie może to być wykonywane
równolegle z tworzeniem przez Kierownika
Projektu Planu Etapu dla etapu zarządczego);
• zapewniając, że produkty są wytwarzane zgod-
nie z metodą(-ami) wytwarzania określonym i
w Grupie Zadań;
• wykazując za pomocą metod(-y) kontroli jako-
ści określonych(-ej) w Opisie Produktu, że każdy
produkt spełnia swoje kryteria jakości - może to
obejmować wykorzystanie techniki przeglądu
jakości PRINCE2 (patrz Rozdział 6);
• uzyskując zatwierdzenia wykonanych produktów
od organów wskazanych w Opisie Produktu;
• dostarczając produktów Kierownikowi Projektu
zgodnie z wszelkimi procedurami określonymi
w Grupie Zadań.

Sterowanie Etapem

"
-Ze:cwolonle Wykontino
nil wykonanie
Gru"'" Zadnń
) ~
Grupit Zi'ldOń J
r ------· -------------- -------------- ------
L

Przyjmowanie Grupy Wykonywanie Oddawanie wykonanej

Zadań do wykonania Grupy Zadań Grupy Zadań

Zarządzanie Dostarczaniem Produktów

~-------------------------------------------4

Rysunek 16.1 Diagram procesu Zarządzanie Dostarczaniem Produktów

196 I Zarządzanie Dostarczaniem Produktów

F Przyjmowanie Grupy Zadań Sporządzić Plan Zespołu

Zezwolenie na wykonanie' •
do wykonania
Grupy Zadań
"

Uaktualnić Rejestr Jakości

Grupa Zadań

Zat\vierdzit Grupa Zadań

Dokumentacja
Inicjowania Projektu
(część)

Rysunek 16.2 Przyjmowanie Grupy Zadań do wykonania - schemat działania

- Zglosić

c__) Nowe l)lzyko

Tabela 16.1 Przyjmowanie Grupy Zadań do wykonania - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej ni eza l eżny od wytwórcy
Zatwierdzający - potwierdza odbiór
c>-
a.
E ..>/. a>-
·-c
"'....
Ol
o
.... (;'
$
o "'$
V
:;,
+-'
..>/.
Cli
·~
o
-o
:;,

a.
:;,
+-'
..>/.
:;,
+-'
..>/.
Cli
+-'
"'
o
"O
:;,
co- ..>/.
.... "' .....
Cl.
-. N
>- "'"'
+-'
Cl. N
Cli Cli
·~
o
..... ..>/.
"'
·~
V
V
c
·N
::> o
o ..>/. ..>/.
·-c
·~

....o Cl. :;,

"O
"'c
N "O
o c>- >-
c
c
$ $
Cl.
....
•O
·-....Cli
V ....o
Cl.
$ o
"'....Ol $ $ .... ....o N
"'"'a. "'a.
- -
Cli "O
•O •O
....N Cli
·- Cli
Produkt Czynn ość o Cl. I,!) I,!) ~ ~ 2"' s o
Plan Zespołu Sporządzić (Z) (Z) w K
Ryzyko Zgłosić (K) w
Rejestr J akości Uaktua l nić (K) K (W) A23
Grupa Zadań Zatwierdz i ć (W) z K A26

J eże li
projekt zatru dnia zewnętrznych dostawców, 16.4 DZ IAŁANIA
którzy nie stosują metodyki PRINCE2, Za rządzan i e
Dzia łania
w procesie Zarządzanie Dostarczaniem
Dostarczaniem Produktów określa wymagany punkt
Produktów są prowadzone głównie przez Kierowni-
styku pomiędzy Kierown ikiem Zespołu a metodyką
ka Zespołu i obejmują :
PRINCE2, wykorzystywaną w projekcie przez Kie-
rown ika Projektu. Grupa Zadań może być częścią • Przyjmowanie Grupy Zadań do wykona nia.
umowy. Dlatego stopień sformalizowania Planu • Wykonywanie Grupy Zadań.
Zespolu może si ę wa h ać od załączni ka dołączonego • Oddawanie wykonanej Gru py Zadań.
do Grupy Zadań aż do sporządzen i a pełnoforma­
towego planu, który jest przedstawiany w formie
podobnej do Planu Etapu.

16.4.1 Przyjmowanie Grupy Zadań do
wykonania
Podstawową zasadąjest, że zanim Grupa Zadań
zostanie przydzielona zespolowi do wykonania,
Kierownik Projektu i Kierownik Zespo łu powinni
u zgodnić, co ma być dostarczone, wymogi dotyczące
raportowania, jakie ograniczenia obowiązuj ą, jakie
procedury mają być zastosowane i czy wymagania
postawione w Grupie Zadań są uzasadnione oraz
czy mogą zostać spełnione.
Rysunek 16.2 przedstawia elementy wejściowe i wyj-
ściowe tego dzi ałania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeglądu Grupy Zadań. W tym celu
należy:
• uzyskać wsze l ką powi ązaną dokumentację;
• wyjaśnić z Kierown ikiem Projektu, co ma być
dostarczone;
• wynegocjować z Kierownikiem Projektu
w imieniu zespołu warunki i ograniczenia,
w ramach których prace mają być wykonane;
• uzgodnić tolerancje dla Grupy Zadań;
• wyjaśn i ć wymagania dotyczące raportowania;
• wyjaśnić, jak i od kogo należy uzyskać
zatwierdzenie produktu(-ów);
• wyjaśnić, w jaki sposób zatwierdzony(-e) pro-
dukt(-y) mają być formaln ie przekazane;
• potwierdzić, w jaki sposób na l eży poinfor-
mować Kierownika Projektu o zakończeniu
Grupy Zadań.
• Stworzyć Plan Zespołu, by wykazać, że produkt(-y)
można wykonać w ramach istniejących ograni-
czeń . Skon sultować z Nadzorem Projekt u (ze
strony dostawcy), czy Plan Zespołu jest wyko-
nalny i zgodny z odpowiednimi standardami
dostawcy. Uzyskać niezbędne zatwierdzenie
Planu Zespołu (chociaż w komercyjnych relacjach
klient/dostawca dokonanie przeglądu i zatwier-
dzenie Planu Zespołu przez Ki erownika Projek-
tu może nie być właściwe i w takim przypadku
w Grupie Zadań zostaną zestawione tylko głów­
ne kamienie milowe, a Główny Dostawca może
dokonywać przeglądów i zatwierdzać Plany
Zespołów).
• Przeprowadz i ć przeglądryzyk w odniesieniu
do Planu Zespołu i poinformować Kierownika
Projektu o wszelkich dodatkowych lub zmo-
dyfikowanych ryzykach (a jeżeli Grupa Zadań
pozwala Kierownikowi Zespołu bezpośrednio
Zarzą dzanie Dostarczaniem Produktów I 197
rejestrować ryzyka, wówczas Kierownik Zespołu
powinien uaktua l nić Rejestr Ryzyk).
• Skonsultować z Nadzorem Projektu, c.zy potrzeb-
ni będą dodatkowi kontrolerzy i zapewnić, aby
Rejestr Jakości zosta ł odpowiednio zaktualizowa-
ny (sprawdzić Grupę Zadań pod kątem zgodności
z proced urą aktualizacji Rej estru J akości).
• Przyjąć Grupę Zadań do wykonania.
Tabela 16.1 przedstawia obowiązki związane z tym
działaniem.
16.4.2 Wykonywanie Grupy Zadań
Prace muszą być wykonywane i monitorowane
zgodnie z wymaganiami określonymi w zatwierdzo-
nej Grupie Zadań.
Podczas wytwarzania produktów Kierownik Zespołu
nie powinien przekroczyć tolerancji Grupy Zadań,
uzgodnionych z Kierownikiem Projektu. Kierownik
Zespołu może kontynuować wykonywanie Grupy
Zadań lub podjąć działania korygujące tylko wtedy,
gdy przewidywane jest ukończenie Grupy Zadań
w granicach toleran cji ustalonych przez Kierownika
Projektu. Gdy tylko Kierownik Zespo łu zacznie prze-
wi dywać, że tolerancje Grupy Zadań zostaną prze-
kroczone, powinien on zgłosić zagadnienie Kierow-
nikowi Projektu, który podejmie decyzję w sprawie
dalszego sposobu postępowania.
Rysunek 16.3 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Zarządzać wytwarzaniem wymaganych produk-
tów. W tym celu na l eży:
• wytworzyć produkt(-y) wymagany(-e) przez
G rupę Zada ń zgodnie z kryteriami j a kości
określonymi w Opisie(-ach) Produktu(-ów);
• zapewnić, że prace są prowadzone zgodnie
z wymaganymi technikami, procesami i pro-
cedurami określonymi w Grupie Zadań;
• utrzymać punkty styku (interfejsy) zw i ąza­
ne z wytwarzaniem, eksp l oatacją i utrzy-
maniem, określone szczegółowo w Grupie
Zadań;
• sprawdzić Grupę Zadań pod kątem zgodno-
ściz procedurą aktualizacj i Rejestru Ja kości
(dla p rzykładu w celu zarej estrowania ukoń­
czonych działań zarządzania jakością);
• wychwycić i zarejestrować wykorzystane
nakłady pracy;
198 I Zarządzanie Dostarczaniem Produktów

... - Produkt(·y)
- '
. -....
Wykonywanie Wytwony!. I
Grupa Zadań Grupy Zadań
~ specjalistyczny(-e) I
... - „ ,,.
u.ie
Rejestr Jako!<i
Plan Zespolu

Uał<I uolnl( Zapisy Obiektu

Konfiguracji
Dokumentacja
Inicjowania Projektu

Ułk.tualnlił Plan Zespolu

- Raport(·y) z Punktu
-
S1>o1ządzlt

r
Kontrolnego

1
Zapisy zatwierdzeń 1
'
-. -....
uzyska(

... - „
Zg łosic'.
( Nowe ryzyko )

ZgIO>l(
.j Nowe zagadnienie t
Rysunek 16.3 Wykonywanie Grupy Zadań - schemat działania

• monitorować i sterować wszelkimi zagad- • ustalićstan realizacji każdego produktu

nieniami i ryzykami związanymi z Grupą z Grupy Zadań;
Zadań i informować Kierownika Projektu • uaktualnić Plan Zespolu i w razie potrzeby
o ich statusie. skonsultować się z Nadzorem Projektu

• Powiadamiać Kierownika Projektu o wszelkich (ze strony dostawcy) w sprawie jego wyko-
nowych zagadnieniach, ryzykach lub doświad­ nalności;

czeniach. Kierownik Projektu może wówczas • przekazać Kierownikowi Projektu infor-

wybrać odpowiedni sposób postępowania. mację zwrotną o postępach w Raportach
Wykonywać czynności zlecane przez Kierownika z Punktów Kontrolnych, w sposób i z często­
Projektu. tl iwości ą określoną w Grupie Zadań;

• Uzyskać zatwierdzenia dla ukończonych produk- • jeże l i przewidywane j est przekroczenie tole-

tów, a w tym celu: rancji ustalonych dla Grupy Zadań, zawiado-

• sp rawdzi ć Grupę Zadań i postępować zgod-
nie z procedurą uzyskiwania i wydawania
zapisów dotyczących zatwi erdzeń;
• sp rawdzi ć Grupę Zadań i zastosować pro-
cedurę aktualizacji Zapisów Obiektu Konfi-
guracji (w celu zmiany statusu produktów,
które zostaly ukończone).
• Dokonać przeglądu i zgloszenia stanu realizacji
Grupy Zadań Kierownikowi Projektu, a w tym
celu:
m ić Kierownika Projektu poprzez zg łoszenie
zagadnienia.
Tabela 16.2 przedstawia obowiązki związane z tym
działaniem.
16.4.3 Oddawanie wykonanej Grupy
Zadań
Tak, jak Grupa Zadań jest przyjmowana do wykona-
nia od Kierownika Projektu, tak powiadomienie o jej
zakończeniu musi trafić do Kierownika Projektu.
 Zarządzanie Dostarczaniem Produktów I 199

Tabela 16.2 Wyko nyw anie Grupy Zadań - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy c>-
a.
E -"". Q)o
Zatwi erdzaj ący - potwierdza odbiór Cl)
....
Ol
o
.... Ci'
c
:::o
.,,. ."'- :::
Cl)
u
::i
+'
."'-
QI
·~
o
-o
::i

a. ::i
+'
:i
+'
-"".
Q)
t:
o
"....
::i
a.
-. ....Cl)
.... "'QI -"". ·~
o
·-u >.
QI
Cl)
N
"' a. N ·~
o .... -"".
·~
u c
·N o .... a. ::i
::> o -"". -"".
·-c
Cl)
N
cCl) ":::
o c>- c>-
c
:::o :::o
a.
....
-o
QI
·-....u "....o
Cl..
::: ::: .... .... N Cl)
a. ·-a.
- -
QI V\

Produkt Czynność
....Ol
o ....
N
Cl..
-o
\.?
-o
\.? ~
QI
~
QI
"z s
Cl) V\

o
Produkty specjalistyczne Wytworzyć (Z) (Z) (Z) (K) w K
Rejestr Jakości Uaktua l nić (K) R (W) A23
Zapisy Obiektu Ko nfig uracj i Uaktua l nić w w AS

Plan Zespo łu Uaktua l nić w K

Raport z Punktu Ko ntrolnego Sporządzić (K) w A3
Zagadnienie Zgłosić (K) w
Ryzyko Zgłosić (K) w
Zapisy zatwierdzeń Uzyskać (K) w K K

Rysunek 16.4 przedstawia elementy wejściowe wszystkie produkty, które mają być dostarczone
i wyjściowe tego dzialania. przez Grupę Zadań zostaly zatwierdzone.
• Ua ktua l n i ć Plan Zespołu w ce lu odnotowania,
PRINCE2 zaleca wykonanie następuj ących czynności:
że Grupa Zadań zestala za koń czon a.
• Dokonać przeglądu Rejestru Ja kości
w celu • Sprawdzić Grupę Zadań i postąp i ć zgodnie
sprawdzenia, czy zakończone zostały wszystkie z procedurą dostarczenia ukoń czonych pro-
działania dotyczące jakości, związane z Grupą
duktów. Powiadom i ć Kierownika Projektu, że
Zadań.
Grupa Zadań zostala ukończona.
• Dokonać przeglądu zapisów dotyczących
zatwierdzeń produktów w celu sprawdzenia, czy
Tabela 16.3 przedstawia obowiązki związane z tym
działaniem.

Oddawanie wykonanej Uaktualni(

Grupa Zadań
Grupa Zadań Grupy Zadań
'

U8klUłlni(
Rejestr Jakości ..... Plan Zespolu

, ...
Zapisy Obiektu
Konfiguracji
•
...Wykonana Grupa Zadań ł ~

Rysunek 16. 4 Oddawanie wykonanej Grupy Zadań - schemat działania

200 I Zarządza ni e Dostarczaniem Produktów

Tabela 16.3 Oddawanie wykonanej Grupy Zadań - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kont roler - najlepiej n ieza l eżny od wytwórcy

Zatwierd zający - potwierd za odbiór >.

c
a.
E -" .....,,
Q»
·-c
"'....Ol
o
.... >.
u
so s"'
u
....
:i
-"
QI
·~
o
-
:i
o
a. ....
:i
....
:i
-"
QI
o
"O
o..
-.. llt'
N
-"
!;'., "'
t: ....
o..
"'QI
N
-"
QI
·~
o
....
....
:i
-"
"'u ·-c
·~
u
•N
:::>
o
Cl -"
·-c -"
·-c
·~
o
....
o..
o.. :i
"O
"'c o
N "O
>.
c
>.
c so so .... ·-....u
QI
o
....
s s s .... ....
'0
N
"'a.
o..
"'....Ol ....
- - ·-"'a.
QI "O
N ·O '0 QI QI

Produkt Czynność o o.. \9 \9 ~ ~ z"' ~ o

Grupa Zada ń Ua kt ua l nić (Z) w K A26

Plan Zespolu Ua ktua l nić (K) w K

17 Zarządzanie Końcem Etapu

17.1 PRZEZNACZENIE ryzyk. Dlatego proces ten powinien być realizowany

Proces Zarządzanie Końcem Etapu ma zapewnić
Komitetowi Sterującemu dostarczanie mu przez
Kierownika Proj ektu informacji wystarczających
do tego, aby mógl do konać przeg l ą du osi ągnięcia
celów bieżącego etapu, zatwierdzić Plan Etapu
następnego, dokonać przeglądu uaktualnionego
Planu Projektu oraz potwierdzi ć dal szą zasad ność
bi znesową proj ektu i a kceptowal ność istn i ejących
na końcu albo tuż przed końcem każdego etapu
zarządczego.
Realizacja projektów nie zawsze przebiega zgodnie
z planem. W odpow iedzi na Raport Nadzwyczajny
Oeżeli przewidywane jest przekroczenie granic tole-
rancji etapu lub projektu) Komitet Sterujący może
po lecić zmia nę planu bieżącego etapu (i ewentu-
alnie projekt u). Wynikiem zmiany planu jest Plan

Zarządzanie Strategiczne Projektem

.
r ...
WniQłłk o iettwie<dienl•
Planu Nadzwyczajnego
'- •
r :.....
Wnlc»flc o Z.ftwierdzenl~
P'-'nu łt•pu (nastę-pnrgo)
/' ....
Pol.t<tnit s,pon.fdztnl1
'- • \..
Płlnu Nadl\vyczajnłgo

„ -- --- -----· --- ---- --- ----- ---- --- ------ ------------- ------- - ---- - - ----„

Uaktualnianie
Raportowanie Sporz~dzanie Planu
zakończenia etapu Uzasadnienia
Biz1lesowego Nadzwyczajnego

I
I
I
I Uaktualnianie I
I Planu Projektu I
I I
I I
I I
I I
I I
I I
I I
I I
I Planowanie I
I nastfpnego etapu I

'
I
I
I
I I
I
I
Zarząd zani e Końcem Etapu I
I

~ ---- - ------- - ------ ---- ----- -- ----- ~- ----- -- - - ---- ----- ------ - ------- - - 4
.,,
lbł,tają<y $if
koniec etapu
"

Inicjowanie Sterow anie

Projektu Etapem

Rysunek 17.1 Diagram procesu Zarządzanie Końcem Etapu

204 I Zarządzanie Końcem Etapu
Nadzwyczajny, który jest przedkładany Komitetowi
Sterującemu do zatwierdzenia w taki sam sposób,
w jaki składany jest do zatwierdzenia Plan Etapu.
17.2 CEL
Proces Zarządza ni e Ko ńcem Etapu ma na celu:
• zapewnienie Komitetu Sterującego, że wszystkie
produkty wykazane w Planie Etapu dla bieżącego
etapu zostały ukończone i zatwierdzone;
• przygotowanie Planu Etapu dla następnego
etapu;
• dokonanie przeglądu i w razie konieczności uak-
tualnienie Dokumentacji Inicjowania Projektu
(w szczegó ln ości Uzasadnienia Biznesowego,
Planu Proj ektu, formuły realizacji projektu, stra-
tegii, struktury zespołu zarządzania projektem
i opisów ról);
• dostarczenie informacji potrzebnej Komitetowi
Sterującemu do oceny dalszej zasadności projek-
tu - wraz z zagregowaną ekspozycją na ryzyko;
• zarejestrowanie wszelkich informacji lub
doświadczeń, które mogą pomóc przy reali-
zacji póżniejszych etapów tego projektu i/lub
w innych projektach;
• wystąpienie o zezwolenie na rozpoczęcie następ-
nego etapu.
W przypadku sytuacji nadzwyczajnych proces Zarzą­
dzanie Końcem Etapu ma na celu:
• sporządzenie Planu Nadzwyczajnego zgodnie
z wytycznymi Komitetu Sterującego;
• uzyskanie zgody na zastąpienie Planu Projektu
lub Planu Etapu dla bieżącego etapu Planem
Nadzwyczajnym.
Zarządzanie Końcem Etapu nie jest stosowane pod
koniec ostatniego etapu (chyba że istnieje potrzeba
sporządzenia Planu Nadzwyczajnego), ponieważ
działan i a mające na celu dokonanie przeglądu wyni-
ków ostatniego etapu są włączone do działań maj ą­
cych na celu dokonanie przeglądu całego projektu,
jako część procesu Zamykanie Projektu.
17.3 KONTEKST
Istnienie procesu Zarządzanie Końcem Etapu wynika
z podziału projektu na etapy zarządcze (patrz Roz-
dział 10).
Projekty, zarówno duże, jak i mate, muszą zapew-
nić, aby wytwarzane w nich produkty dostarczyły
pożądane korzyści albo samodzielnie, albo jako
część większego programu. Utrzymywanie prawi-
dłowej koncentracji projektu powinno być potwier-
dzane na końcu każdego etapu. Jeśli okaże się to
kon ieczne, projekt może być inaczej ukierunko·
wany lub wstrzyrnany d la uniknięcia marnowania
czasu i pieniędzy.
Należy równ i eż pamiętać, że projekty mogą się
nie udać łub mogą podlegać wpływowi czynników
zewnętrznych, które unieważniają ich zasadność
biznesową. Wczesnym wskaźnikiem potencjalnego
niepowodzenia projektu jest prognoza Kierownika
Projektu, że jakieś tolerancje projektu lub etapu
zostaną prawdopodobnie przekroczone. W takich
przypadkach ważne jest, aby w celu przywróce-
nia realizacj i projektu właściwego kierunku istniał
mechanizm dzia łań korygujących.
Pozytywna decyzja o zaniechaniu dalszej rea lizacji
projektu nie jest porażką. Porażką jest natomiast
dostarczenie Komitetowi Sterującemu niepełnych
informacji, niewystarczających do podjęcia decyzji
przy pelnej świadomości sytuacji, gdyż to może
doprowadzić do podjęcia niewłaściwej decyzji.
Proces Zarządzanie Końcem Etapu dostarcza także
środków, za pomocą których może być zrealizowany
proces postępowania w sytuacji nadzwyczajnej.
17.4 DZIAŁAN IA
Działan i aw procesie Za rządzan i e Końcem Etapu
dotyczą głównie Kierown ika Projektu i obejmują:
• Planowanie następnego etapu.
• Uaktualnianie Planu Projektu.
• Uaktualnianie Uzasadnienia Biznesowego.
• Raportowanie zakończenia etapu.
• Sporządzanie Planu Nadzwyczajnego.
17.4.1 Planowanie następnego etapu
Plan Etapu dla następnego etapu zarząd czego j est
tworzony pod koniec bieżącego etapu. Działan i a
związane z zamykaniem projektu powinny być
zaplanowane jako część Planu Etapu d la ostatniego
etapu rea lizacyjnego.
Planowanie nie jest działaniem podejmowanym
w odosobnieniu. Kierownik Projektu będzie musiał
skonsultować się z Komitetem Sterującym, Nadzo-
rem Projektu, Kierownikam i Zespołów, a być może
również z innymi interesariuszami, w celu stwo-
rzenia wykona lnego planu. Im więcej osób będzie
 Za rządzan ie Końcem Etapu I 205

Zbl1tający się
koniec elapu
Planowanie
następneg o etapu -·-- Dokumentacja
Inicjowania Projektu

Dokumentacja Spot7itdi!łt Plan Etapu

Inicjowania Projektu (następny etap)

Rejestr Zagadnień Wyt\\'Ołty(

Opisy Produktów
(następny etap)

u i -ey<1
Rejestr Ryzyk U.k1v.lnit Zapisy Obiektu
Konfiguracji

Dziennik U•ktualni(
Do~wiadczeń Rejestr Ryzyk

U1khM1lnl<
Rejestr Zagadnień

uaktu.1~
Rejestr Jakości

Rysunek 17.2 Planowanie następnego etapu - schemat działania

zaangażowa nych w planowanie, tym bardziej wia-
rygodny będzi e ten plan (pod warunkiem, że do
planowania zaa nga żowa ne będą wlaściwe osoby).
Wi ęcej szczegółów dotyczących planowania można
znaleźć w Rozdziale 7.
Rysunek 17.2 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Dokonać przeglądu składników Dokumentacji
Inicjowania Projektu. Konieczne może być skon-
sultowanie się z Komitetem Sterującym w spra-
wie wszelkich wymaganych zmian. Następujące
elementy powinny być poddane przeglądowi
i w razie kon i eczności uaktualnione:
• Wszelkie zmiany oczekiwań jakościowych
klienta, kryteriów akceptacji lub formuly
rea lizacji projektu.
• Znaczenie i przydatność strategii oraz
mechanizmów sterowania.
• Wszelkie zmiany w zespole zarządzania
projektem lub w opisach ról (zwlaszcza sytu-
acji dotyczącej zewnętrznych zasobów lub
dostawców, jako że może to mieć wplyw na
Plan Etapu).
• Przygotować Plan Etapu dla następnego etapu,
a w tym celu:
• Zdecydować, jak można ten plan najlepiej
przedstawić, biorąc pod uwagę jego odbior-
ców oraz j ak będz i e on wykorzystany.
• Dokonać przeg l ądu Planu Projektu w celu
określenia produktów, które mają być
dostarczone w trakcie następnego etapu.
• Przeanalizować Strategię Zarządzania
Jakością pod kątem wymaganych standar-
dów i procedur dotyczących jakości.
• Sporządzić (lub uaktualnić) strukturę podzia-
lu produktów, Opisy Produktów i diagram
następstwa produktów dla produktów, które
ma dostarczyć następny etap.
• Dok onać przeg l ądu Rejest ru Zag adnień,
poniewa ż może on zawierać zagadnieni a
przewidziane do oceny na końcu etapu lub
informacje mające wpływ na następny etap.
• Dokonać przeglądu Rejestru Ryzyk pod
kątem wszelkich ryzyk, które mogą mieć
wplyw na Plan Etapu dla następnego etapu
i sprawdzić status reakcji na ryzyko, konsul-
tując się z właścicielam i ryzyk.
206 I Zarządzanie Końcem Etapu

Tabela 17.1 Planow anie następnego etapu - obowi ązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej n iezależny od wytwórcy

Zatwi erdzaj ący- potwierdza odbiór >-
c
a.
E .;,e. 111'
,_
ro
Ol
o
,_ ~
c
;:
o
ro
V
;:
:i
+"'
-
.;,e.

·-o "'
Q)
:i
o
a. :i ~
:i t:
"O
o
Q.
...... nr
N
.;,e.
>..
ro
t:
,_ Q)
+"'
.;,e.

·-....o
Q) ·-
o
....
Q)
:i
+"'

·-
ro
V
ro
V
·-c ·N
:::> o
o
Q.
.;,e.
N
.;,e.
·-c Q.
Q.
Q)
.;,e.

"O
:i

N
·-c
"O
o >-
c
>-
c
c
;: ;:
,_ ·-,_
V
o
....
ro ;: ;: ;: o o
•O
ro Q.
.... .... N
a.
Produkt Czynność
....
Ol
o
N
Q)
....
Q. - -
•O
~
•O
~ ~
Q)

~
Q) "O
z
ro
~
•!!?
o
a.

Dokumentacja Inicjowania Projektu Uaktualn i ć (K) (Z) (Z) (Z) w K A20

Plan Etapu Sporządz i ć (Z) (Z) (Z) w K A16

Zapisy Obiektu Konfig uracj i Utworzyć/Uaktua l n ić w K K AS
Rejestr Ryzyk Uaktualn i ć w K A25
Rejestr Zagadnień Uaktua lnić w K A12
Rejestr Jakości Uaktualnić K K w A23

• Utworzyć (lub uaktualnić) Zapisy Obiektu Powinno to obejmować m.in. daty zaplanowa-
Konfiguracji dla produktów, które mają być nych przeg l ądów i zatwierdzenia produktów.
wytworzo ne w ramach następnego etapu.
Tabela 17.1 przedstawia obowiązki zwi ązane z tym
• Uaktua lnić Rej est r Zagadnień i Rejestr Ryzyk, j eże·
dzialaniem.
li zidentyfikowano jakieko lw iek nowe zagadnie-
nia lub ryzyka (lub jeżel i i stniejące zagadnienia
17.4.2 Uaktualnianie Planu Projektu
lub ryzyka muszą być zmodyfikowane).
W trakcie rea lizacji projektu Komitet Sterujący
• Uaktualnić Rejestr Jakości pod kątem planowa-
wykorzystuje Plan Projektu do mierzenia postępów.
nych dzialań dotyczących zarządzania jakością.

Dokumentacja
Uaktualnianie Planu
Plan Etapu
(bie~ący etap)
Projektu
• Inicjowania Projektu
(częśc'}

Uak1ualnll Plan Projektu

Plan Etapu
(następny etap)

U.ł:tułlnll
~ Rejestr Zagadnień
Dokumentacja
lnkjowania Projektu

Plan Nadzwyczajny
Ułktualnit
-łll Rejestr Ryzyk ]

Rysunek 17.3 Uaktualnianie Planu Proj ektu - schemat działania

 Zarząd zanie Końcem Etapu I 207

Plan Projektu jest aktualizowany w celu uwzg l ęd ­
nienia faktycznych postępów kończącego się etapu
o raz w celu uwzględn i enia przewidywanego czasu
trwania i kosztów z Planu Nadzwyczajnego lub
Planu Etapu dla etapu, który ma się rozpocząć.
Szczególy dotyczące skorygowanych kosztów lub
terminów zakończenia są wyko rzystywane podczas
uaktualniania Uzasadnienia Biznesowego.
Wi ęcej szczegółów dotyczących planowania można
zna leźć w Rozdziale 7.
Rysunek 17.3 przedstawia elementy wej ści owe i wyj-
ściowe tego dzia łania .
PRINCE2 zaleca wykonanie następujących czynności:
• wszelk ich zmienionych lub dodatkowych
produktów zatwierdzonych przez Komitet
Sterujący;
• wszelkich zmian w Dokumentacji Inicjowania
Projektu (np. zaktualizowanej formuły rea li-
zacji projektu, strategii, mechanizmów stero-
wania projektem, struktury zespolu zarządza­
nia projektem lub opisów ról).
• Uaktualn i ć Rejestr Zagadn i eń i Rejestr Ryzyk,
jeże l i zidentyfikowano nowe zagadnienia lub
ryzyka (lub jeżeli i stniejące zagadnienia lub ryzy-
ka muszą być zmodyfikowane).
Tabela 17.2 przedstawia obowi ązki związane z tym
działaniem.

• Sprawdzić, czy Plan Etapu dla bieżącego etapu

17.4.3 Uaktualnianie Uzasadnienia
jest uaktualniony faktycznym i postępami i uaktu-
a l nić go, jeśl i to konieczne.
Biznesowego
• Dokonać aktualizacji Planu Proj ektu w celu Jedną z zasad PRINCE2 jest to, że projekty powinny
odzwierciedlenia: posiadać ciąglą zasadność b i znesową.

• danych o stanie faktycznym z Planu Etapu
bieżącego;
• prognoz z Planu Etapu następn ego lub wply-
wu Planu Nadzwyczajnego;
• wszelkich zmian Opisu Produ ktu Końcowego
Projektu;
• wagi wszelkich zagadnień lub ryzyk;
• wszelkich nowych lub zmienionych wyma -
gań dotyczących dostosowania procesów
PRINCE2 do projektu;
Komitet Steruj ący jest zwykle upoważn i ony do kon-
tynuowania projektu tylko wtedy, gdy projekt pozo-
staj e zasadny (to znaczy, gdy korzyści będą zrealizo-
wane w granicach wskaźników ustalonych w aktu-
alnie uzgodnionym Uzasadnieniu Biznesowym dla
kosztów, czasu, j akości, zakresu i ryzyka).
Projekty nie są rea lizowane w statycznym środo­
wisku. Zewnętrzne otoczenie projektu zmienia się,
podobnie jak charakterystyki i terminy real izacji pro-
duktów projektu. Uzasadnienie Biznesowe powinno

Tabela 17.2 Uaktualnianie Planu Projektu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej nieza l eżny od wytwórcy
Zatwierdzający - potwierdza odbiór
>.
c:
Q.
E .>I! ..,
Cl>-
·- ...,
Ili
.....
Ol
o
.....
>.
c:
3
o
Ili
V
3
:i
.>I!
QI
-o
:i

Q. ..,
:i
..,
:i
.>I!
"'
o
"O
.....
Q_ w
V
.>I! Ili
· ~
o
..... "' .>I!
QI
·~
o ...,:i
Ili
·~
V
N
·-c
V >-
·N
t:
o
Q_
.>I!
QI
N
.>I!
QI
·~
o .....
Q_
.>I!
:i
Ili :::> o ·-c: ·- "-
Q_ QI "O
N "O
o >. >. c: ..... ·-
V
o
c: 3QI c: c: 3 3 ·O "-
"-
Q_
Ili 3 3 o
..... o
..... N Ili

Produkt Czyn ność o

Ol
..... N
.....
Q_ - -
·O
\.9
·O
\.9
QI
·-
:..:
QI
:..:
"O
z
Ili
Q.

s
"'
·-"'Q.
o
Plan Projektu Uaktua l n i ć (Z) (Z) (Z) w K A16
Rejestr Zagad n ień Uaktua l n i ć w K A12
Rejestr Ryzyk Uaktua l n i ć w K A25
208 I Zarządzanie Końcem Etapu

Uaktualnianie Dokumentacja
Rejestr Ryzyk Uzasadnie nia Inicjowania Projcktt1
Biznesowego (częić)

Rejestr Zagadnień
.__ -
U.kl~ Uzasadnienie
Biznesowe

Dokumenta9a
lnkjowania Projektu Wktu.1lnk Plan Przeglądu
(czę!t) Korz~cl

ua~ tualnll
Plan Projektu Rejestr Ryzyk

U..kt Ułłni(
Plan Przeględu
Rejestr Zagadn ień
Kon~ci

Rysunek 17.4 Uaktualnianie Uzasadnienia Biznesowego - schemat działania

odzwierciedlać te zmiany i musi być rewidowane Rysunek 17.4 przedstawia elementy wejściowe i wyj-
i poprawiane, aby byle użyteczne dla projektu. ściowe tego dzialania.

Ponieważ Przewodniczący jest odpowiedzialny za PRINCE2 zaleca wykonanie następujących czynności:

Uzasadnienie Biznesowe, Kierownik Projektu powi-
• Sprawdzić, czy zaszly jakieś zmiany dotyczące
nien ko nsultować się z Przewodn iczącym, gdy, przy-
skłonności do akceptacji ryzyka i zdolności pono-
gotowuj ąc je do zatw ierd zenia przez Komitet Steru -
szenia ryzyka przez o rganizacje zaa ng ażowane
j ący, dokonuj e j ego przeg l ądu i aktualizacji.
w projekt i czy n ależy ponownie zdefi niować
Więcejszczególów na temat zasadności biznesowej tolerancje ryzyka. Ocen i ć ryzyka związane z pro-
można znaleźć w Rozdziale 4. jektem, wykorzystując Rejestr Ryzyk w celu

Tabela 17.3 Uaktualnianie Uzasadnienia Biznesow ego - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
c>-
a.
E .>L ....
~
·-c
ro
....
m
o
.... ~
~
o
ro
u
~
....
::i
.:,,/.
<LI
·~
o
-::i
o
a. ....
::i
....:J
.:,,/.
<LI
"'
o
"O
::i
Cl.
'ii!
ro•
N
.>L
>. ....
ro ....
N
"'<LI .>L
<LI
·~
o
.... _t;
·~
u
u
·-c ·N "'o Cl.
.>L .>L
·~
o
.... Cl. :J
ro :i o ·- ·- Q. "O
N
c
"O
o >-
c: >-
c:
c
~
c:
~
....
•O
·-....u<LI o
....
~ Cl..
ro ~ ~ o.... ....o N ro
a.
Produkt Czynność o
m
....
<LI
....
N
Cl. - -
-o
I!)
-o
I!)
<LI
~ ~
<LI
·-
"O
z
ro
s
V> ·-"'a.
o
Uzasadnienie Biznesowe Uaktua l nić (K) (Z) (Z) {Z) w K A2
Plan Przeg l ądu Korzyści U aktua l n ić (K) (Z) (Z) (Z) w K A1
Rejestr Ryzyk Uaktua l nić w K A25
Rejestr Zagadnień Uaktua l nić w K A12

ustalenia zagregowanej ekspozycji na ryzyko dla
projektu oraz zidentyfikowania aktualnych glów-
nych ryzyk, które mają wplyw na Uzasadnienie
Biznesowe. Powinno to obejmować ocenę. czy
zagregowana ekspozycja na ryzyko pozostaje
w granicach tolerancji ryzyka.
• Uaktualnić Plan Przeglądu Korzyści wynikami
wszelkich przeglądów korzyści przeprowadzo-
nych w trakcie etapu.
• Przeanalizować i dokonać przeglądu:
• Planu Przeglądu Korzyści pod kątem wyni-
ków wszelkich przeg l ądów korzyści przepro-
wadzonych w trakcie etapu w porównaniu
do oczekiwanych rezultatów;
• wpł ywu zatwi erdzonych zm ian, ponie-
waż mogą one wpływać na przewidywane
korzyści;
• profilu ryzyka projektu oraz glównych ryzyk;
• Rejestru Zagadnień pod kątem wszelkich
zagadn i eń, które mogą m i eć wplyw na
Uzasadnienie Biznesowe;
• Planu Projektu w celu sprawdzenia, czy nie
zmienil się ostateczny termin wdrożenia
projektu (na późniejszy lub wcześniejszy), co
może mieć wplyw na niektóre lub wszystkie
przewidywane korzyści;
• Planu Projektu w celu sprawdzenia, czy nie
zmieni! się koszt dostarczenia produktów
projektu, co może mieć wplyw na analizę
kosztów/korzyści;
• otoczenia organizacji lub programu, do któ-
rego zostaną dostarczone produkty projektu,
ponieważ moglo ono ulec zrnianie;
• czy wymagane są jakieś przeglądy korzyści
w trakcie n astępnego etapu zarządczego.
• Dokonać rewizji Uzasadnienia Biznesowego
i, j eś l i to konieczne, Planu Przeg l ądu Korzyści,
przygotowując j e do zatwierdzenia przez
Komitet Steruj ący.
• W razie potrzeby uaktu a l nić Rejestr Ryzyk
i Rej estr Zagadnień.
Tabela 17.3 przedstaw ia obowiązk i związane z tym
dzialaniem.
17.4.4 Raportowanie zakończenia etapu
Raporty o wynikach etapu powinny być przekazy-
wane Komitetowi Sterującemu tak, żeby osiągn ięte
postępy byly wyraźnie widoczne dla zespołu zarzą­
dzania projektem.
Zarządzan i e Końcem Etapu I 209
Kierownik Projekt u wyraża swój pogląd na temat dal-
szej zdol ności projektu do wykonania Planu Projektu
i zasadności Uzasadnienia Biznesowego oraz ocenia
ogólną sytuację dotyczącą ryzyka.
Działanie to powinno być realizowane możliwie jak
najbliżej faktycznego końca etapu.
Rysunek 17.5 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• W odniesieniu do Planu Nadzwyczajnego:
• W zależności od punktu etapu, w którym
wystąp ila sytuacja nadzwyczajna, wskazane
może być sporządzen ie Raportu Końcowego
Et apu w odniesieniu do dotychczasowych
dzia ła ń . O t ym, czy jest to potrzebne,
Komitet Sterujący poinformuje w odpowie-
dzi na Raport Nadzwyczajny. J eżeli będz i e
wymagany Raport Końcowy Etapu, na l eży
postępować zgodnie z instrukcjami dotyczą ­
cymi Planu Etapu po niżej.
• W odniesieniu do Planu Etapu:
• Dokon ać przeglądu stanu uaktualnionego
Uzasadnienia Biznesowego, a w szczególno-
ści osiągnięcia wszelkich korzyści przewidy-
wanych dla etapu. Potwierdzić, czy działania
przewidziane w Planie Przeglądu Korzyści
dla bieżącego etapu zostaly zakończone.
• Dokonać przeglądu Planu Etapu w celu
zapewnienia, że cele etapu zostały osiągnię­
te oraz przeglądu Planu Projektu w celu
zapewnienia, że cele projektu są nadal moż­
liwe do osiągn ięcia.
• Dokonać przeg l ądu efektywności zespoł u
podczas realizacji kończącego się etapu.
• Dokonać przeg l ądu efe ktywności wykonania
produktów dla etapu w odniesieniu
do Zestawienia St atusu Produktów
(dostarczonego przez Wsparcie Proj ektu).
W t ym celu na leży :
• dokon ać przeg lą du dz i ałań d otyczących
za rządza n i a j akośc i ą dla etapu oraz ich
wyników;
• zapewn ić, że wszystkie produkty ziden-
tyfikowane w Planie Etapu dla bieżącego
etapu zostaly ukończone i zatwierdzone
lub zostaly przekazane do następnego
etapu;
• jeżeli na danym etapie miało miejsce
stopniowe przekazanie produktów,
21 O I Zarządzanie Końcem Etapu

Dokumentacja Raport Koncowy

Raportowanie Sporządzi<
Etapu
Inicjowania Projektu zakończenia etapu
(część) (biezący etap)

Uzasadnienie
Biznesowe
-·~ Raport Oo!wiadczeń

Spo~>il
r - - - -•
Strategia Zarząd zania I Zalecenia działań
I następczych
I
Komunikacją

,_ „„ n1ost~
'

o z•IWit.rdztnJe Pl•nu )
-- „ „ • • -A

Plan Przeglądu ' Elopu (nast ntQO)

Korzyki
r .... n1osex
o zatwierdzenie Planu )
\. NadzW'IKl'ajneqo

Rejestr Zagadnień

Rejestr Ryzyk

Rejestr Jako!ci

Plan Etapu
(bieżący etap)

Zestawienie Statusu
Produktów

Dziennik
DoSwiadczeń

Rysunek 17.5 Rap ortowanie zakończenia etapu - schemat działania

potwi erdzić akceptację użytkownika oraz
akceptację służb eksploatacji i utrzyma-
nia produktów przekazanych klientowi.
Zidentyfikować wszelkie zalecenia działań
następczych w odniesieniu do przekaza-
nych produktów.
• Dokonać przeglądu zagadnie ń i ryzyk zglo-
szonych w t rakcie etapu oraz wszelkich dzia-
łań podjętych w odpowiedzi na nie. Dołączyć
omówienie aktualnej zagregowanej ekspozy-
cji na ryzyko.
• Sporządzić Raport Końcowy Etapu dla bieżą­
cego etapu.
• Wskazane może być stworzenie w tym momen-
cie Raportu Doświadczeń, zwłaszcza dla dłuż­
szych projektów, w których pośrednie przeglą­
dy doświadczeń lub samego projektu mogłyby
przyn i eść korzyścikierownictwu organizacji lub
programu. Sprawdzić Dziennik Doświadczeń pod
kątem znalezienia odpowiednich doświadczeń
do uwzględnienia w raporcie.
• Uzyskać akceptację Komitetu Sterującego dla
Planu Nadzwyczajnego lub Planu Etapu (oraz
jeże l i jest to właściwe - skorygowanego Planu
Projektu, skorygowanego Planu Przegląd u
Korzyści i skorygowanego Uzasadnienia
Biznesowego (patrz Rozdział 13).
• Dokonać przeglądu Strategii Zarządzania
Komunikacją w celu sprawdzenia, czy istnie-
j e wymóg przesłania w tym momencie kopii
Raportu Końcowego Etapu (oraz jeżel i jest t o
właściwe - Raportu Doświadczeń) zainteresowa-
nym stronom zewnętrznym.
Tabela 17.4 przedstawia obowiązki związane z tym
działaniem.
 Zarządzanie Końcem Etapu I 211

Tabela 17.4 Raportowanie zakończenia etapu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
>.
Zatwierdzający - potwierdza odbiór c:
Cl.
E .....: <I>-
ro
....
Ol
c:
~
ro
V
...
:i
.....: -:i
o
:i
+-'
t:
o
o >. ~
QJ
a. :i .....: "O
.... o
a..
.....
ro
V
ra-
V
N
.....:
>.
ro
t:
·~
o
....
a.. N
"'
QJ
+-'
.....:
QJ
·~
QJ
·~

....o ...
:i
.:.t.
·~ •N o .....: .....: ....o a.. :i
V
ro c ::::> o ·- ·- a.. QJ "O
·-cN
"O
o >.
c
>.
c
c
~
c
~
.... ·-....
V
o
....
~
·O
ro a..
ro ~ ~ o
.... o
.... N
a.
Produkt Czynność o
Ol
....
QJ
....
N
a.. - -
·O
\.!:)
•O
\.!:)
QJ
·-
:..::
QJ

:..::
"O
z
ro "'
~
.~

o
a.

Raport Końcowy Etapu Sporządzić (Z) (Z) (Z) w K A9

Raport Doświ adczeń Sporządzi ć (Z) (Z) (Z) w K A15

Zalecenia dzia lań następczych Sporządzić (Z) (Z) (Z) w K

17.4.5 Sporządzanie Planu Plany Nadzwyczajne sporządzane są na prośbę

Nadzwyczajne go
Jeżeliprzewiduje się, że etap lub projekt przekro-
czy ustalone granice tolerancji, to traci on od tego
momentu akceptację Komitetu Sterującego.
Komitetu Sterującego w odpowiedzi na Raport
Nadzwyczajny. Chociaż Plan Nadzwyczajny zostanie
sporządzony przed planowanym końcem etapu,
zatwierdzenie tego Planu przez Komitet Sterujący
będzie oznaczać koniec etapu skorygowanego.

SporządzaniePlanu Uaktualni(
Polt<(!nfc $por;cądzenia Rejestr Zagadn i eń
I Planu Nadzwyczajnego r Nadzwyczajnego

Plan Etapu
(bielący etap)
....
Uak·1ualnl( Dokumentacja
Inicjowania Projektu

Rapo<t Nadzwyczajny Sj>ou'l'it~

Plan Nadzwyczajny

Rejestr Zagadnień WytWO<rf( Opis(·y)

Produktu(-ów)

UtworzvłJ
Rejestr Ryzyk Uaktu.atnll Zapisy Obiektu
Konfiguracji

Dokumentacja
Ułtt Ułln.i(
Inicjowania Projektu Rejestr Jakolci

U•ktwlnk!
Rejestr Ryzyk

Rysunek 17.6 Sporządzanie Planu Nadzwyczajnego - schemat działania

212 I Zarządzanie Końcem Etapu
Planowanie nie jest działaniem podejmowanym
w odosobnieniu. Kierownik Projektu będzie musiał
skonsultować się z członkami Komitetu Sterujące­
go, Nadzorem Projektu, Kierownikami Zespołów,
a być może równ i eż z innymi interesariuszami
w celu stworzenia wykonalnego planu. Im wi ęcej
osób będzie zaangażowanych w planowanie, tym
bardziej wiarygodny będzie ten plan. Więcej szcze-
gólów dotyczących planowania można zna l eźć
w Rozdziale 7.
Rysunek 17.6 przedstawia elementy wejściowe i wyj-
ściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności:
• Uaktualnić Rejestr Zagadnień (oraz jeśl i to
konieczne - Raport o Zagadnieniu) w celu zare-
jestrowania polecenia Komitetu Sterującego spo-
rządzen i a Planu Nadzwyczajnego.
• Dokonać przeg l ądu i w razie potrzeby uaktualnić
Dokumentację Inicjowania Projektu. Konieczne
może być skonsultowanie się z Komitetem
Sterującym w sprawie ewentualnych wyma-
ganych zmian. Przegląd powinien obejmować
następujące kwestie:
• Oczekiwania ja kościowe klienta - czy pozo-
stają one niezmienione?
• Znaczenie i przydatność formuły realizacji
projektu, strateg ii i mechanizmów stero-
wania.
• Wszelkie zmiany w zespole zarządza nia
projektem lub ich opisach ról (zwłaszcza
sytuacji dotyczącej zewnętrznych zasobów
lub dostawców, ponieważ może to wpływać
na Plan Nadzwyczajny).
• Sporządzić Plan Nadzwyczajny. W tym celu
należy:
• przeanalizować Plan Etapu w celu określe­
nia produktów, które mają być dostarczone
w trakcie etapu;
• przeana l izować Raport Nadzwyczajny
pod kątem szczegółów (takich jak zale-
cane działania), które wejdą do Planu
Nadzwyczajnego;
• jeżeli Plan Nadzwyczajny wymaga stwo-
rzenia nowych produktów, wówczas nale-
ży przeanalizować Strategię Zarządzania
Jakościąpod kątem standardów jakości
i wymaganych procedur;
• uaktualn i ć strukturę podziału produktów,
Opisy Produktów i diagram następstwa pro-
duktów o produkty, które mają być dostar-
czone przez Plan Nadzwyczajny;
• uaktualnić Rejestr J akości pod kątem pla-
nowanych dz i ałań dotyczących zarządzan i a
jakością .
• Utworzyć (lub uaktualnić) Zapisy Obiektu
Konfiguracji dla produktów, które mają być
wytworzone przez Plan Nadzwyczajny.
• Uaktualnić Rejestr Zagadnień i Rejestr Ryzyk,
jeżel i zidentyfikowano jakieś nowe zagadnienia
lub ryzyka (lub jeże l i istn iejące zagadnienia lub
ryzyka muszą być zmodyfikowane).
• Uaktualn i ć Rejestr J akości pod kątem planowa-
nych działań dotyczących za rządzan i a jakością.
Powinno to obejmować m.in. przeg l ąd zamie-
rzeń i dat zatwierdzenia produktów.
Tabela 17.5 przedstawia obowiązki związane z tym
działaniem.
 Zarządzanie Końcem Etapu I 213

Tabela 17.5 Sporządzan ie Planu Nadzwyczajnego - obowiązki

Wytwórca - odpowiedzialny za wytworzen ie produktu

Kontroler - najlepiej niezależny od wytwórcy

Zatwierdzający - potwierdza odbiór :>.
c
a.
E .Y. (!).
·-
Cl)
.....
Ol
o
..... ~
c
~
o
Cl)
V
~
::::i
.....
.Y.
QJ
·~
o
-o
::::i

a. ::::i
.....
.Y.
::::i
.....
.Y.
QJ
t:
o
-o
::::i
a.. CO" .Y. Cl)
...... .....
V>
·~
o .....
co
·~
N
V >-
·N o
V> a.. N
QJ QJ
·~
o
.....
.....
a..
.Y.
::::i
V
Cl)
c ::> o .Y.
·- .Y.
·-c a.. -o
N -o :>. :>. c .....
QJ
·- o
.....
·-
c o c c ~ ~ •O
V
..... a..
Cl) ~ ~ ~ o
..... o N Cl)
QJ ..... -o a. ·-a.
V>

Produkt Czyn ność o

Ol
..... N
.....
a.. - -
•O
~
•O
~
QJ
::..,:
QJ
::..,: z
Cl)
s
V>

o
Dokumentacja Inicjowania Projektu Uaktual n ić (K) (Z) (Z) (Z) w K A20

Plan Nadzwyczajny Sporządzić (Z) (Z) (Z) w K A16

Zapisy Obiektu Konfiguracji Utworzyć/Uaktu aln i ć K K w AS

Rejestr Ryzyk Uaktu alnić w K A25

Rejestr Zagadnień Uaktualn i ć w K A12

Rejestr J akości Ua ktualn i ć K (K) K w A23

'
•
.., ••••
-~
18 Zamykanie Projektu

18.1 PRZEZNACZENIE • Dokonanie przegląd u efektywności rea lizacji

Proces Zamykanie Projektu służy do wskazania usta-
lonego punktu, w którym zostanie potwierdzona
akceptacja produktu końcowego projektu, oraz
potwierdzenia, że cele określone w pierwotnej
Dokumentacji Inicjowania Projektu zostały osiągnię­
te (lub że zostały osiągnięte zatwierdzone zmiany
tych celów) albo że projekt nie ma już nic więcej do
wniesienia.
18.2 CEL
Celem procesu Zamykanie Projektu jest:
• Zweryfikowanie, czy użytkowni k zaakceptował
produkty projektu.
• Zapewnienie, że organizacja, w której zrealizo-
wano projekt, jest w stanie wspierać produkty
projektu po jego zakończeniu.
projekt u w odniesieniu do przyjętych dla niego
punktów odniesienia.
• Dokonanie oceny wszelkich korzyści, które
zostały już osi ągnięte, uaktualnienie prognozy
dotyczącej pozostałych korzyści oraz zaplano-
wanie przeglądu korzyści, których dotąd nie
zrealizowano.
• Zapewnienie, że przewidziano rozpatrzenie
wszystkich nierozwiązanych zagadnień i ryzyk,
wraz z zaleceniami dzi ałań następczych.
18.3 KONTEKST
J edną z cech cha rakteryz uj ących projekt PRINCE2
jest jego skończony czas trwania - ma on początek
i koniec. Jeżeli projekt traci tę wyróżniaj ącą cechę,
traci część swej przewagi nad podejściem pole-
gającym na bieżącym, operacyjnym zarządzan iu
organizacją.

Zarządzani e Strategiczne
Projektem

, ,
Przedwue,ne zamkntecie
,

~-------- -- - - ------------
" --------.
I I

„
I
I
I
Przygotowanie I

I Zbl•UJ~ \lf
' I
PrzygotOY1anie pnedW0:<!$0e90 I
'I
Sterowanie Etapem •" kONK ptO,tklU
, I
planowego zamknięcia zamknięcia I
I
I
I
• •••••••• I
I
•
••
I
I
I
I
I
I
... Przekazanie
produktów
I
I
I
I
I
I
I
I Ocenianie projektu
„ I
I I
I
I
I I
I
: Zamykanie I
I
I
Projektu I
I
I
I
„
I
I
Rekomendowanie
I
I '
Rekotnend6tjl z.amknt~łł
I zamknięcia projektu • ptojeklu
.
I
I
I
I "
~----- - -------------------------- ~
Rysunek 18.1 Diagram procesu Zamykanie Projektu
218 I Zamykanie Projektu
Jednoznaczne zakończenie projektu:
• zawsze daje lepszy wynik niż powolne przecho-
dzenie do użytkowania produktów, ponieważ
jest to uznanie przez wszystkich zainteresowa-
nych, że:
• pierwotne cele zostaly osiągnięte (z zastrze-
żeniem wszelkich zatwierdzonych zmian);
• realizowany obecnie projekt zakończy! się;
• eksploatacja musi teraz przejąć produkty od
projektu albo produkty te staną się elemen-
tami wejściowymi do kolejnego projektu lub
kolejnego większego programu;
• zespól zarządzania projektem może zostać
rozwiąza ny;
• koszty projektu nie powinny być nadal
ponoszone;
• daje sza n sę na zapewnienie, że wszystkie nie-
osiągnięte cele i zamierzenia zosta ną zidenty-
fikowa ne tak, aby można bylo zająć się nimi
w przyszlości;
• przekazuje klientowi odpowiedzial n ość za pro-
dukty i kończy odpowiedzialność zespolu za rzą­
dzania projektem.
Czynności zwi ązane z zamykaniem projektu należy
zaplanować jako część Planu Etapu dla ostatniego
etapu zarządczego. Podczas zamykania projektu
należy wykonać prace slużące przygotowaniu mate-
riałów dla Komitetu Sterującego, aby uzyskać od
niego zezwolenie na zamknięcie projektu. Przewod-
niczący powinien następnie powiadomić kierownic-
two firmy lub programu, że projekt został zamknię­
ty (patrz Rozdzial 13).
Możliwe jest także, że Komitet Sterujący zechce
przedwcześnie zamknąć projekt w pewnych
( Zblllojqcy si~
konftc pro)oktu
Przygotowanie planowego
zamknięcia
Zestawienie Statusu
Produktów
Dokumentacja
Inicjowania Projektu
Plan Projektu
Rysunek 18.2 Przygotowanie planow ego zamknięcia - schemat działania
oko l icznościach (np. jeżel i Uzasadnienie Biznesowe
przestało być nadal zasadne). Jeżeli projekt jest
zamykany przedwcześnie, proces Zamykanie Pro-
jektu należy mimo wszystko przeprowadzić, z tym,
że należy go dostosować do faktycznej sytuacji
projektu.
Po zakończeniu projektu konieczne może być wyko-
nanie szeregu działań dotyczących przekazanych już
produktów, które to działania należy udokumento-
wać i zaplanować w formie zaleceń dzialań następ­
czych. Mogą one być skierowane do różnych odbior-
ców i w związku z tym na leży je wydawać indywi-
dualnie. Potrzeby odbiorcy będą dyktować sposób
prezentacji i treść tych zaleceń - niektórzy odbiorcy
mogą zażądać oficjalnego raportu, inni - wpisu do
dziennika w systemie, a jeszcze inni - spotkania.
18.4 DZ IAŁANIA
Dzia łaniaw procesie Zamykanie Proj ektu realizowa-
ne są głównie przez Kierownika Projektu i obejmują:
• Przygotowanie planowego zamknięcia;
• Przygotowanie przedwczesnego zamknięcia;
• Przekazywanie produktów;
• Ocenianie projektu;
• Rekomendowanie zamknięcia projektu.
18.4.1 Przygotowanie planow ego
za mknięc ia
Zanim będzie można zarekomendować zamknię­
cie projektu, Kierownik Projektu musi upewnić się,
że osiągnięto i dostarczono wszystkie oczekiwane
wyniki.
Rysunek 18.2 przedstawia elementy wejści owe
i wyjści owe t ego dzialania.
Ookurncntacja
Inicjowania Projektu
~
UakhJ11lnl(
Plan Projektu
 Zamykanie Projektu I 219

Tabela 18.1 Przygotowanie planowego zamknięcia - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór >.
c
a.
E
....m
.Y.
·- .., ..,G>-
O)
c
~
m
V
:i
.Y. -oa.
:i

..,
..,
:i "'o
o
....
o..
~ o
.Y.
~
..,m ·-o......o
<U
"'<U
:i
.Y.
.Y.

·-
<U
"O
..,
:i
'<il
·-ro
V
"" >.
·-ctJ ·N
::>
"'
o
o .Y.
·-
N
.Y.
·-c
·-o......o o..
<U o
.... .Y.
:i
"O
N
c
"O
o >-
c
>-
c
c
~ ~
....
•O
·-....<U
V
o
....
o..
~ o m
m ~ ~ .... ....o N
a. ·-"'a.
Produkt Czynność
....Ol
o
<U
....
N
o.. - -
•O
\.!)
o()
\.!) ~
<U <U
~
"O
z
m
3"' o
Plan Projektu Uaktualnić w K A16

Zestawienie Statusu Produktów Sporządzić K K w A18

PRINCE2 zaleca wykonanie następujących czynności: Tabela 18.1 przedstawia obowiązk i zwi ązane z tym
działaniem .
• Uaktualnić Plan Projektu danymi faktycznymi
z ostatniego etapu.
18.4.2 Przygotowanie przedwczesnego
• Poprosi ć Wsparcie Projektu o sporządzenie
zamknięcia
Zestawienia Statusu Produktów. Na podstawie
tego zestawienia zapewnić, aby produkty pro- W niektórych przypadkach Komitet Sterujący może
jektu: polecić Kierownikowi Projektu, aby zamkną ! projekt

• zostaly zatwierdzone przez organy wskazane przedwcześnie. W takich okolicznościach Kierownik

w poszczególnych Opisach Produktów;
• spelniają wszystkie kryteria jakościowe lub są
objęte zatwierdzonymi ustępstwami.
• Potwierdzi ć, żeprojekt dostarczy! to, co określo­
no w Opisie Produktu Końcowego Projektu i że
kryteria akceptacji zostaly spelnione.
• Uzyskać zgodę na powiadomienie kierownictwa
organizacji lub programu, że zasoby mogą być
(lub wkrótce będą) zwolnione.
Projektu musi zapewnić, że prace w toku nie zosta-
ną po prostu porzucone, ale że w projekcie zostanie
uratowane wszystko to, co wytworzono dotychczas,
a co ma jakąś wartość. Należy sprawdzić, czy wszel-
kie luki (brakujące elementy), wynikające z przerwa-
nia projektu, zostaly zgloszone kierownictwu orga-
nizacji lub programu.
Rysunek 18.3 przedstawia elementy wejści owe
i wyjściowe tego działania.

Przygotowanie
I Pne<łwa:esne
zamknltclt
przedwczesnego
zamknięcia
." Rejestr Zagadni eń

'
Zestawienie Statusu
Produktów Dokumentacja
Inicjowania Projektu

Dokumentacja u.t1Ułlno(
Inicjowania Projektu Plan Projektu
-4

Plan Projektu Wytworzył

„ ---
Oszacowania •
.

- -.... -...
I
1 dodatkowych prac I

~
Rysunek 18.3 Przygotowanie przedwczesnego zamknięcia - schemat działania
220 I Zamykanie Projektu

PRINCE2 zaleca wykonanie następujących czynności
• Uaktualn i ć Rejestr Zagadn i eń (i jeśl i to konieczne
- Raport o Zagadnieniu) w celu zarej estrowania
polecenia przedwczesnego zamknięcia projektu.
• Uaktualn i ć Plan Projektu danymi faktycznym i
z ostatniego etapu.
• Pol ecić Wsparciu Projektu sporządzen i e Zesta -
wienia Statusu Produktów. Na podstawie tego
zestawiania ustalić, które produkty projektu:
• został y zatwierdzone przez organy wskazane
w poszczególnych Opisach Produktów;
• są obecnie wykonywane (i które z nich
muszą być zakończone);
• są obj ęte zatwierdzonymi ustępstwami;
• n ie zostaly jeszcze rozpoczęte;
• m u szą być zabezpieczone;
• mogą być przydatne w innych projektach.
• Uzgodn i ć sposób wykorzystania produktów,
które zostaly ukończon e lub których wytwarza-
nie jest w toku (jeżeli j est to właściwe). Będzi e
to wymagać konsu ltacji z Komitetem Sterującym
i może obejmować dodatkowe prace w celu
wytworzenia, zabezpieczenia lub ukończe-
nia produktów, które mogą być przydatne dla
innych projektów (na przykład zapewnienie, że
częściowo ukończony budynek jest bezpieczny
i zabezpieczony przed dzialaniem czynników
atmosferycznych). W niektórych przypadkach
: dodatkowe prace mogą wymagać sporządzen i a
Planu Nadzwyczajnego.
• Uzyskać zgodę na powiadomienie kierownictwa
organizacji lub programu, że zasoby mogą być
(lub wkrótce będą) zwolnione przedwcześn i e.
Tabela 18.2 przedstawia obowiązk i związane z tym
dzialaniem.
18.4.3 Przekazywanie produktów
Produkty proj ektu muszą być przekazane do środo­
wiska eksploatacj i i utrzymania przed zamkn i ęci em
projektu. Może to nastąpi ć w formie jednorazowe-
go wydania na końcu projektu albo formuła real i-
zacji projektu może obej mować stopniowe dostar-
czanie produktów, w ramach którego produkty są
przekazywane w formie ki lku wydań (zestawów
produktów).
W przypadku przedwczesnego zamk nięci a proj ek-
tu, niektóre produkty mogą już być zatwierdzone,
lecz jeszcze nie przekazane i w zależności od decyzji
Komitetu Sterującego wlasność, czyli odpowiedzial-
ność za niektóre lub wszystkie te produkty, będzie
musiala być przeniesiona na klienta.
Podczas przekazywania produktów Plan Przeglą­
du Korzyści może wymagać uaktualnien ia w celu
uwzględnienia poprojektowego przeglądu(-ów)
ko rzyści dotyczącego efektywności produktów
projektu w użytkowan i u operacyj nym. Takie prze-
glądy k orzyści mogą wskazywać, czy wystąpily

Tabela 18.2 Przygotowanie przedwczesnego zamknięcia - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontrol er - najlepiej niezależny od wytwórcy
Zatwi erdzaj ący- potwierdza odbiór
>.
c
a.
E ~
....
QI<
....
<1l
en
o
.... >.
V
·-

s
c
s
o
<1l
V
....
~
::i

QI
·~
o
-
o
::i

a. ....
::i ~
....::i
QI
V\
o
-o
a..
"" >. ....o
~ ::i
..... ~ <1l .... V\
-~
.....
....o
N QI QI
<1l V V\ a.. N ·~ ~
·u- c ·N
~ ~
o
.... a.. ::i
<1l -o ::> o ·-c a.. -o
·-c
N
o >.
c
>.
c s
c
s .... ·-....QI
V
o
....
<1l s s s o
.... o
....
•O
N <1l
a.
a..

- -
V\
en
....
QI
·O •O QI QI -o a.
N
s
V\
.... <1l
Produkt Czynność o a.. l9 l9 ~ ~ z o
Rejestr Zagadn ień Uaktua l n i ć w A12
Plan Projektu Uaktua l n ić w K A16
Zestawienie Statusu Produktów Sporządzić K K w A18
Oszacowania dodatkowych prac Wytworzyć (Z) (Z) (Z) w K w
 Zamykanie Projektu I 221

Rejestr Zagadnień Raport K ońcowy

Przekazywanie Projektu
f>rOdllkt6w (czę!')

Rejestr Ry?yłc _._ , r

zalecenia dtialań

- ---
I następczy<h 1
• - „ ....
- Dokumentacja -
Inicjowania Projektu U•klualnic! Zapisy Obiektu
Konfiguracji

Strategia Zarządza ni a
Konfiguracją Vitktuałol(
Plan Przeglądu
~
Korzyści

r - -
Uzyska(
..._ I Zapis akcePtac'i
J I
„ •• ...,,
- - „
Rysunek 18.4 Przekazywanie produktów - schemat działania

jakieśskutki uboczne (korzystne lub niekorzystne), je utrzymywać w trakcie ich użytkowania. W tym
co może dostarczyć pożytecznych doświadczeń dla celu należy:
innych projektów. • potwierdzić, że istnieje odpowiednie środo­
Przeprowadzenie przeglądów korzyści po zakończe­ wisko eksploatacji i utrzymania;
niu projektu nie jest dzialaniem należącym do projek- • rozważyć wymagania dotyczące wsparcia każ­
tu, jest nim natomiast planowanie przeprowadzenia dego przekazywanego produktu w począt­
takich przeg lądów korzyści. J eżeli projekt jest częścią kowym okresie j ego eksploatacji, ponieważ
programu, wówczas poprojektowe przeglądy korzy- wczesny okres życia produktu jest często
ści muszą być objęte działaniami dotyczącymi zarzą­ okresem największego zapotrzebowania na
dzania korzyściami w ramach programu. wsparcie;
• tam, gdzie produkt wymaga znacznego,
Rysunek 18.4 przedstawia elementy wejściowe i wyj-
potencjalnie kosztownego wsparcia i utrzy-
ściowe tego działania.
mania, Kierownik Projektu powinien zapew-
PRINCE2 zaleca wykonanie następujących czynności: nić podpisanie odpowiedniej umowy serwi-

• W porozumieniu z zespołem zarządzania pro-
jektem opracować zalecenia działań następczych
dla produktów projektu w celu uwzględnienia
wszelkich niezakończonych prac, zagadn i eń
i ryzyk. Mogą istnieć oddzielne zalecenia działań
następczych dla każdego produktu lub specyficz-
nej grupy użytkowników (na przykład dla działu
zasobów ludzkich, finansów, operacyjnego).
• Sprawdzić, czy Plan Przeglądu Korzyści obejmuje
działania poprojektowe w celu potwierdzenia
korzyści, które można zmierzyć dopiero wtedy,
kiedy produkty projektu będą w użytkowani u
przez pewien czas (na przykład wymagania doty-
czące niezawodności).
• Strategia Zarządza nia Konfiguracją powinna być
przeanalizowana w celu potwierdzenia sposobu
przekazania produktów tym osobom, które będą
sowej lub kontraktu pom i ędzy jednostkami
eksploatacji i utrzymania a użytkownikami
końcowymi (w takich przypadkach umowa
serwisowa powinna być uwzględniona
jako produkt, który zostanie dostarczony
w ramach planu);
• potwierdzić akceptację produktu(-ów) przez
j ednostki eksploatacji i utrzymania;
• poprosić o świadectwa akceptacji i uzyskać j e;
• przekazać odpowiedzialność za produkty
projektu na jednostki eksploatacji i utrzy-
mania oraz uaktualnić Zapisy Obiektu
Konfiguracji dla produktów.
Tabela 18.3 przedstawia obowiązki związane z tym
działa nie m.
222 I Zamykanie Projektu

Tabela 18.3 Przekazywanie produktów - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
>.
Zatwi erdzaj ący - potwierdza odbiór c
a.
E .»t. Cli-
·-c
ro
,_
O'I
o
,_ ~
3:
o
ro
u
3:
:J
-
....
.»t.
·- "'
<li ....
:J
o....
a. :J
:J
.»t.
t:
o
"O
a..
.....
ro
tO'
N
.»t.
>. ....ro o
,_
a.. ·- ·-
<li
.»t.
<li
<li
o
,_ ....
:J
.»t.
·-
u
ro
u
·-c •N
:::> o
"'
o .»t.
·- ·-
N
.»t. o
,_
a..
a..
<li
:J
"O
·-c N "O
o >.
c
>.
c
c
3:
c
3:
,_ ·-u,_ o
...
3: •O
ro a..
ro 3: 3: o
,_ o
,_ N
a. ·-"'a.
Produkt Czynność o
O'I
,_
<li
,_
N
a.. - -
•O
19
•O
19
<li
:><:
·-<li
:><:
"O
ro
z ~ o
Zalecenia dzia lań następczych Sporządzić/Uaktualnić (Z) (Z) (Z) w K

Zapisy Obiektu Konfiguracji Uaktualnić z K w AS

Plan Przeglądu Korzyści U aktu al nić (Z) (K) (K) (K) w K A1

Zapis akceptacji Uzyskać (Z) (Z) (Z) w K

18.4.4 Ocenianie projektu szacunkowych i danych faktycznych o postępach

Organizacje odnoszące sukcesy uczą się na swoich
doświadczeniach z projektów. Podczas oceny pro-
jektu celem jest ocenienie, jak dużym sukcesem czy
też porażką zakończył się projekt. Analiza danych
projektu może także umożliwić sporządzenie lep-
szych oszacowań dla przyszłych projektów.
Rysunek 18.5 przedstawia elementy wejściowe
i wyjściowe tego działania.

Dokumentacja
Inicjowania Projektu Raport Końcowy
Ocenianie projektu Projektu

Raport Końcowy
Projektu
(częśt)
- Sporządrić
Raport Doswiadczeń

r
1

~ -
następczych

„ „ „
-
Zalecenia dzialań
J
-"'
Rejestr Zagadnień

Rejestr Ryzyk

Rejestr Jakoki

Dziennik Doświackz:eń

Rysunek 18.5 Ocenianie projektu - schemat działania

 Zamykanie Projektu I 223

PRINCE2 zaleca wykonanie następujących czynności: wykorzystać w przyszłych projektach i wystąpić

• Dokonać przeglądu pierwotnych zamierzeń pro-
jektu uzgodnionych w trakcie etapu inicjowania
i zdefiniowanych w Dokumentacji Inicjowania
Projektu, którą uznano za obiekt odniesienia.
• Dokonać przeg l ądu zatwierdzonych zmian zde-
finiowanych w aktualnych wersjach skladników
Dokumentacji Inicjowania Projektu.
• W porozumieniu z zespolem zarządzania projek-
tem sporządzić Raport Końcowy Projektu, obej-
mujący:
• podsumowanie osiągnięć projektu przez
Kierownika Projektu;
• ocenę wyników projektu w porównaniu
z oczekiwanymi korzyści ami określonymi
w Uzasadnieniu Biznesowym;
• przeg l ąd wyników projektu w porównaniu
z planowanymi wartościami i tolerancjam i;
• przegląd efektywności zespolu;
• przegląd produktów projektu, który powinien
obejmować podsumowanie wszelkich zaleceń
działań następczych;
• jeśli
to konieczne - udokumentowane przy-
czyny przedwczesnego zamknięcia projektu.
• W porozumieniu z zespołem zarządzania
o zgodę Komitetu Sterującego na przesłanie go
kierownictwu organizacji lub programu. Raport
ten powinien obejmować:
• przeg l ąd tego, co się udało, tego, co się nie
uda ło oraz wszelkich za l eceń do rozważenia
przez kierownictwo organizacji łub progra-
mu, a w szczególności metodyki zarządzania
projektem, wszelkich zastosowanych metod
specjalistycznych, strategii i mechanizmów
sterowania projektem, a także zdarzeń nad-
zwyczajnych powodujących odchylenia;
• przegląd przydatnych miar, takich jak: jakie
nakłady pracy były wymagane do wytworze-
nia produktów, jak skuteczna była Strategia
Zarządzania Jakością przy projektowaniu,
opracowywaniu i dostarczaniu produktów
zgodnych z przeznaczeniem (na przykład ile
błędów wykryto po przeprowadzeniu kontroli
jakości produktów), a także danych statystycz-
nych dotyczących zagadnień i ryzyk;
• wszelką uzyskaną przydatną wiedzę dotyczącą
dostosowania metodyki PRINCE2 do danego
projektu.
Tabela 18.4 przedstawia obowiązki związane z tym
działaniem.

projektem, sporządzić Raport Doświadczeń

w odniesieniu do doświ adczeń, które można

Tabela 18.4 Ocenianie projekt u - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór

>.
c
a.
E ~ Q>o
....
C1l
Ol
o
.... ~
c
:::o C1l
u
:::
::i
.....
~
Q)
·~
o
-
::i
o
a. ~
::i
..... ~
::i
.....
Q)
t:
o
"O
::i
o.. ~ .... "'
--
C1l
·~
u
C1l'
N
u
·-c >.
·N
:::>
C1l
t:
o
o
o..
~
·-c
Q)
N
~
·-
Q)
·~
o
....
o..
·~
o
....
o..
Q)
.....
~
::i
"O
C1l
N
·-c
"O
>. >.
c .... ·-....u ....o
o:::
o c c ~
C1l ::: ::: ::: .... o....
·O
N C1l
a.
Cl.
·-"'a.
Produkt Czynność
....Ol
o
Q)
....
N
o.. - -
-o
\!)
·O
\!) ~
Q) Q)

~
"O
z"' "'
~ o
Raport Końcowy Projektu Sporządzić (Z) (Z) (Z) w K AS

Raport Doświadczeń Sporządzić (Z) (K) (K) (K) w K A15

224 I Zamykanie Projektu

Dokumentacja Inicjowania
Projektu 1-..-.----... I
Rekomendowanie
zamknięcia proj ektu
Z;)ntknlt( Rejestr Zagadnień

Strategia Zarządzania Rejestr Ryzyk

Komunikacją

Zamknąć
Rejestr Jakoki

Zamknłl
Dziennik Projektu

Dziennik Doświ adczeń

„ - - - - - -.
,,iygo1ov1a~ Propozycja
1
powiadomiet1ia I
I
I
- „ ---..J
o zamykaniu projektu

Rekomendac.ja
~ 2amkni~c-ia

Rysunek 18.6 Rekomendowanie zamknięcia projektu - schemat działania

Tabela 18.5 Rekomendowanie zamknięcia projektu - obowiązki

Wytwórca - odpowiedzialny za wytworzenie produktu

Kontroler - najlepiej niezależny od wytwórcy
Zatwierdzający - potwierdza odbiór
>-
c
a.
E .:.!. QJ•
·-c .....
...m
ro

...
o Ci'
$
o
ro
V
$
:i
.....
.:.!.
QJ
·~
- :i
o
a. :i
.....
:i
.....
.:.!.
QJ
V>
o
"O
.:.!. ro ...o V> .:.!. :i

--
Cl.
ro
·~
V
ro
"1'
N
V
c
>.
·N
::>
.....
o
V>
o
Cl.
.:.!.
·-c
QJ
N
.:.!.
·-c
QJ
·~
o
...
Cl.
...o..o
·~
.....
.:.!.
:i
"O
N
c
"O
o >-
c >-
c $ $ ...
'0
QJ
·-...
V ...o
Cl.
ro $QJ $ $ ...o ...o N ro
a.
- -
V>
...m ... '0 '0 QJ QJ "O
a.
N
s
V>
ro
Produkt Czynność o Cl. ~ ~ ~ ~ :z o
Rejestr Zagadn i eń Zamknąć w A12
Rejestr Ryzyk Zamknąć w A25
Rejestr Jakości Zamknąć w A23
Dziennik Projektu Zamknąć w A7
Dziennik Doświ adczeń Zamknąć w A14
Propozycj a powiadomienia
Przygotować (Z) (Z) (Z) w K
o zamykaniu projektu

18.4.5 Rekomendowanie zamknięcia
projektu
Po potwierdzeniu przez Kierownika Projektu, że
projekt może zostać zamknięty, rekomendacja
zamknięcia projektu powinna zostać przedłożona
Komitetowi Sterującemu.
Rysunek 18.6 przedstawia elementy wejściowe
i wyjściowe tego działania.
PRINCE2 zaleca wykonanie następujących czynności :
• Wykorzystać Strategię Zarządzania Komunikacją
do zidentyfikowania wszelkich organizacji lub
zainteresowanych stron, które na l eży powiado·
mić o zamykaniu projektu. Należy również roz-
ważyć działania związane z komunikacją w celu
wykorzystania możliwości public relations i mar-
ketingowych w tym momencie.
Zamykanie Projektu I 225
• Zamknąć Rejestr Zagadnień, Rejestr Ryzyk,
Rejestr Jakości, Dziennik Projektu i Dziennik
Doświadczeń projektu.
• Zabezpieczyć i zarchiwizować wszystkie infor-
macje dotyczące projektu (zgodnie ze Strategią
Zarządzania Konfi guracją) w celu umożliwienia
przeprowadzenia wszelkich przyszłych audy-
tów decyzji zarządczych, działań i efektywności
zespołu zarządzania projektem.
• Sporządzić i przesłać Komitetowi Sterującemu
do zatwierdzenia wstępną wersję powiadomie-
nia o zamykaniu projektu stwierdzającego, że
projekt został zamknięty.
Tabela 18.5 przedstawia obowi ązki związane z tym
działaniem.
 19 Dostosowanie metodyki PRINCE2
do warunków projektu
19.1 NA CZYM POLEGA DOSTOSOWANIE
METODYKI?
Metodyka PRINCE2 może być wykorzystywana
n iezależn ie od skali, złożoności, położen i a geo-
graficznego lub środowiska kulturowego projektu
oraz niezależnie od tego, czy projekt jest częścią
programu, czy też jest realizowany jako samo-
dzielny projekt. Istotnie, jedną z zasad metodyki
jest to, że projekt rea lizowany zgodnie z PRIN-
CE2 dostosowuje metodykę tak, by odpowiadała
warunkom danego projektu.
Dostosowanie oznacza wlaści we wykorzystanie
metodyki PRINCE2 w danym projekcie, zapewn i aj ąc
mu odpowiedni poziom planowania, kontroli, ładu
oraz wykorzystania procesów i tematów, natomiast
wprowad zenie metodyki PRINCE2 w calej organiza -
cji jest nazywane wdroże n ie m . Tabela 19. 1 przed -
stawia różnicę pomiędzy wdrożeniem a dostosowa-
niem metodyki.
19.2 OGÓLNE PODEJ ŚCIE DO DOSTOSOWA-
NIA METODYKI
Niektóre zespoly projektowe mogą utrzymywać,
że nie potrzebują „całej metodyki PRINCE2" i że
w zwi ązku z tym wdrożyli tylko niektóre części tej
metodyki. Może to wskazywać na nieprawidlowe
zrozumienie metodyki PRINCE2, gdyż jest ona zapro-
jektowana w taki sposób, aby można ją było dosto-
Tabela 19.1 Wdroże ni e a dostosowanie
Wdrożeni e metodyki
Dokonywane przez organizaqę w celu wprowadzenia w niej
metodyki PRINCE2.
Koncentracja na:
----------'-
Ko n ce n tra cja na:
• Odpowiedzialności za procesy
• Zasadach/regulach skalowania (np. karta wyników)
• Standardach (szablony, definicje)
• Szkoleniach i rozwoju
• Integracji z procesami biznesowymi
•
•
Narzędziach
Nadzorze procesów
Wskazówki są zawarte w publikacji OGC PRINCE2 Maturity Wskazówki
Model.
sować. Stąd teżdostosowanie PRINCE2 we właściwy
sposób do potrzeb konkretnego projektu jest właśnie
zastosowaniem „pelnej metodyki PRINCE2".
Dostosowanie nie polega na pomijaniu elementów
PRINCE2. Metodyka ta nie jest szeregiem odizolo-
wanych silosów, w którym dowolny element można
pominąć bez wplywu na pozostałe elementy.
PRINCE2 to s i eć wzajemnie powiązanych elemen-
tów: tematy metodyki są wykorzystywane w jej
procesach, techniki służą do wdrażania tych tema-
tów w życie, a osoby pelniące określone role w pro-
jekcie tworzą produkty zarządcze. J eżel i pominie
się któryś z elementów, to ucierpi na tym zarządza­
nie projektem.
Dlatego dostosowanie polega na adaptacji metody-
ki PRINCE2 do czynników zewnętrznych (takich jak
standardy f irmowe, które muszą być zastosowane)
oraz czynników wewnętrznych proj ektu wymagają ­
cych rozważenia (takich jak skala projektu). Celem
jest wprowadzenie takiego poziomu zarządzania
projektem, który nie spowoduje nadmiernego
obciążenia projektu, ale który zapewni poziom
kontroli właściwy dla czynników zewnętrznych
i wewnętrznych projektu.
Niebezpieczeństwo wyn ikającez niedostosowa-
nia metodyki PRINCE2 polega na tym, że może to
doprowadzi ć do „automatyzmu" w zarzą dzan i u
projektem, prowadzącego do tego, że bez głęb­
szego zastanowienia wykonuje się każde działanie
Dostosowanie metodyki
-----
Adaptacja metodyki do kontekstu konkretnego projektu. dokony-
wana przez zespól zarządzania projektem.
• Adaptacji tematów metodyki (przez opracowanie stra tegii
i mechanizm6w sterowania)
• Wprowadzeniu specyficznej terminologn/języka
• Zrewidowaniu Opisów Produktów dla produktów zarządczych
• Zrewidowaniu opisów ról dla ról w projekcie PRINCE2
• Dostosowaniu procesów metodyki do powyższych element6w
są zawarte w niniejszym podręczniku.
230 I Dostosowanie metodyki PRINCE2 do warunków projektu

• Wiele organizacji uczestniczy

w projekcie
• Zewnętrzny klient/dostawca
• Standardy firmowe
• W ramach programu
• Dojrzalość organizacji (np. centrum
doskonalości)
• Terminologia i język • Skala
• Geografia • Zlożoność rozwiązania
• Kultura organizacji • Dojrzalość zespolu
• Priorytet projektu • Typ proj ektu i model cyklu życia
• itd. • itd.

Czynniki Pryncypia Czynniki

środowiskowe PRINCE2 projektowe

Dostosowanie

• Adaptacja tematów (poprzez strategie i mechanizmy sterowania)

• Adaptacja pojęć i języka
• Adaptacja Opisów Produktów dla produktów zarządczych
• Adaptacja opisów ról
• Adaptacja procesów, aby pasowaly do wyżej wymienionych
• Zapisanie w Dokumentacji Inicjowania Proj ektu

Ry sunek 19.1 Czynniki wplywaj <Jce na wymogi dostosow ania

procesu i wytwarza wszystkie produkty zarządcze. 19.2.2 Adaptacja tematów

Jest to pulapka, w którą często wpada zarządzanie
projektami „oparte na szablonach".
Dostosowanie polega zatem na przemyś l en iu, w jaki
sposób zastosować metodykę PRINCE2 w konk ret -
nym projekcie, a następnie na stosowaniu jej bez
zbędnych obci ążeń. Rysunek 19.1 przedstawia spo-
sób oceny czynników środowiskowych i projekto-
wych, służąc dostosowaniu metodyki PRINCE2.
19.2.1 Stosowanie pryncypiów (zasad)
Ponieważ pryncypia (zasady) PRINCE2 są uniwersal-
ne, będą mieć zawsze zastosowanie i nie podlegają
Adapt acja tematów niekoniecznie musi ozn aczać
modyfikację metodyki. W większości przypadków
czynniki środowiskowe i projektowe są uwzg l ęd­
niane w strategii i mechanizmach st erowania pro-
jektem. Odpowiednie zasady polityki i standardy
o rganizacji lub programu są uwzg l ędniane i reje-
strowane w Strategii Za rządzania Ryzykiem, Strate-
gii Zarządza nia J akością, Strategii Za rządza n ia Kon-
figuracją i Strategii Zarządzania Komun i kacją dla
proj ektu. Te produkty zarządcze opi sują procedury,
które będą wykorzystywane w projekcie, aby można
było spe łnić wymagania danej organizacji lub pro-

dostosowaniu. Rozważając te zasady, praktyk może gramu. Wymagany poziom kontroli będzie m iał
zrozu mieć, w jaki sposób zaadaptować dany temat wpływ na f ormalizm i częstotl iwość monitorowania,

do czynników środowiskowych i projektowych bez przeglądów i raportowa nia.

utraty jego wartości.

 Dostosowanie metodyki PRINCE2 do warunków projektu
19.2.3 Stosowanie terminologii i języka
. „
organ1zac11
Konieczność uwzględnienia terminologii i języka
używanego w organizacji lub programie może zmu-
si ć do adaptacji metodyki. Na przykład jeżel i orga -
nizacja lub program stosuje termin „uzasadnienie
inwestycyjne" zamiast terminu „ Uzasadnienie Bizne-
sowe", wskazane może być zastąpien i e tego termi-
nu w całej dokumentacji projektu, jeżel i zapewni to
lepsze jej zrozumienie.
19.2.4 Adaptacja produktów zarządczych
PRINCE2 dostarcza zarysy Opisów Produktów dla
tych produktów zarządczych, które maj ą konkretne
przeznaczenie łub wymagaj ą szczególnej zawar-
tości potrzebnej do wykorzystania w tematach lub
procesach. Przy dostosowywaniu PRINCE2 produkty
zarządcze mogą być adaptowane i w takim przy-
padku może zaistnieć kon i eczność modyfikacji ich
Opisów Produktów lub dostarczenia d la nich szablo-
nów. Dla wszystkich osób zaangażowanych w rea li-
zację projekt u powinno być jasne, jakie j est prze-
znaczenie produktu zarządczego, co powinien on
zawierać i jakie są jego kryteria jakości. Na przykład
w środowisku klient/dostawca może być istotne,
aby Grupa Zadań zawierała szczegółowe informacje
dotyczące zamówienia oraz zwi ązane z nim terminy
i warunki.
19.2.5 Adaptacja ról
W każdym projekcie należy dokładn i e rozważyć
stosowanie struktury organizacyjnej proponowa-
nej przez PRINCE2. Zarysy standardowych opisów
ról zosta ły przedstawione w Dodatku C, z tym że
oczekuje si ę, iż będą one wymagać adaptacji, aby
uwzg l ędnić fa ktyczne możl iwości i uprawnienia
poszczególnych osób w kontekści e roli w projekcie,
która zostanie im przypisana. Na przykład w odnie-
sieniu do projektu realizowanego w ramach progra-
mu odpowiedzialność za Plan Przeglądu Korzyści
może być ulokowana w programie. W związku
z tym odpowi edzialność tę należy usunąć z opisu roli
Przewodn i czącego.
19.2.6 Adaptacja procesów
Wszystkie działania składające sie na procesy PRINCE2
muszą być wykonane, z tym że odpowiedzi alność
za wykonanie tych działań może się zmien i ać (jeżeli
jakieś role zostały poddane adaptacji) i wszelkie
odniesienia do produktów zarządczych mogą
I 231
wymagać zmiany (jeże l i jakieś produkty zarządcze
zostały dostosowane do potrzeb projektu).
19.3 PRZYKŁADY DOSTOSOWANIA PRINCE2
W sekcjach 19.4-19.1 O przedstawiono kilka przykła ·
dów dostosowania metodyki PRINCE2.
Pon i ższe przykłady obejmują niektóre czynniki śro­
dowiskowe i projektowe, które spotyka si ę w w ielu
projektach:
• Projekty realizowane w ramach programu;
• Skala projektu;
• Ś rodowisko komercyjne klient/dostawca;
• Projekty obejmujące wie le organizacji;
• Typ projektu;
• Różn i ce sektorowe;
• Kompendia Wiedzy o za rządzani u projektami.
Wymienione czynniki środowi skowe i projektowe
nie wyczerpują wszelkich możl iwości, ponieważ
stosowanie PRINCE2 nie jest niczym ograniczone.
Przedstawiono jedynie ogólne wskazówki w celu
zilustrowania kwestii, które należy uwzględnić oraz
pewnych taktyk, które można zastosować . Wskazó-
wek tych nie należy interpretować jako jedynego
podejści a do dostosowywania, poniewa ż nie doty-
czą one konkretnego projektu. W praktyce należy
rozważyć wady i zalety różnych moż l iwości dostoso-
wania w kontekście konkretnego projektu.
W organizacji, która wdrożyła metodykę PRINCE2,
wdrożona wersja tej metodyki nadal wymaga dosto-
sowywania do potrzeb konkretnych projektów.
19.4 PROJEKTY REALIZOWANE W RAMACH
PROGRAMU
Program to elastyczna struktura organizacyj-
na utworzona na pewien czas dla koordynacji,
zarządzania strategicznego i nadzorowania
realizacj i zbioru powią zanych ze sobą projektów
i działań, w celu osiągnięcia oczekiwanych rezu l-
tatów i korzyści związanych z celami strategicz-
nymi organizacji. Program może trwać ki lka lat.
Różnica pom i ędzy proj ektami a programami pole-
ga na tym, że proj ekty zazwyczaj coś wytwarzają
lub zm i en i ają, a następnie zostają rozwi ązane .
Korzyści z rezu ltatów projektu będą najprawdopo-
dobniej narastać po jego zakończeniu. Programy są
232 I Dostosowanie metodyki PRINCE2 do w aru nków projektu

Projekty Programy
"
.., r
Ukierunkowane wizją
-.
Ukierunkowane produktami
... .... „ „stanu końcowego" -'
.,, ..,
"' Skończone - określony start i koniec
"' Brak predefiniowanej ści eżki
.... "-- -'
, .., ,
Powiązane produkty o określonym
Zmiany potencjalu biznesowego
"
„ zakresie -' "-- -'

c
" Skoordynowane dostawy produl<tów
) "' "I
Dostarczanie produktów - łączni e z projektami n ieprzynoszącymi
'l bezpośrednich korzyści -"

-. „ Korzyści
-,,.
Korzyścizwykle realizowane rea lizowane w trakcie
po zamknięciu projektu ... programu i po jego zakończeniu -'

Krótsze terminy
"' D luższe terminy
'I

... ~

Rysunek 19.2 Porównanie projektów i programów

zwykle wykorzystywane, aby pomóc w przeksztal- budżetu, l istę korzyści

ceniach organizacji. W związku z tym struktura
organizacyjna programu, utworzona na pewien
czas, ma zwykle cykl życia, który obejmuje uzyski-
wanie korzyści, co może trwać kilka lat. Przedsta-
w ia to Rysunek 19.2.
Projekty realizowane w ramach programu odnoszą
korzyści dzięki przewadze, jaką daje program, i ist-
nieje wiele sposobów dostosowywania metodyki
PRINCE2 do wykorzystania w projektach programu.
W kolejnych sekcjach wyjaśniono, jak dostosowywać
metodykę PRINCE2 do pracy w środowisku progra-
mu (wykorzystuj ącego platformę opisa n ą w publika-
cji OGC Managing Successful Programmes), koncen-
trując się na sposobie adaptacji tematów, procesów
i produktów zarządczych.
19.4.1 Wykorzystanie tematów PRINCE2
19.4. 1.1 Uzasadnienie Biznesowe
Program będzie defi niować standardy, które projekt
realizowany w jego ramach musi zastosować pod-
czas opracowywania Uzasadnienia Biznesowego.
Uzasadnienie Biznesowe proj ektu będzie włączone
do całości owego Uzasadnienia Biznesowego progra-
mu i jego zawartość (w stosunku do przedstawionej
w dodatku A) będz i e prawdopodobnie ograniczona _
Może ono obej mować tylko informacj e dotyczące
(i tolerancje korzyści) oraz
info rmacje dotyczące sposobu, w jaki projekt wnosi
wklad do modelu docelowego programu, przy
czym aspekty Uzasadnienia Biznesowego dotyczące
zasadności proj ektu będą zwykle zawarte w Uzasad-
nieniu Biznesowym programu.
W niektórych przypadkach Uzasadnienie Biznesowe
proj ektu może być tworzone i utrzymywane przez
program i może nawet i stn i eć w szczególowej for-
mie przed zainicjowaniem projektu.
Korzyści będą definiowane, wychwytywane i zarzą ­
dzane przez zespół za rządzan i a programem, a Plan
Przeglądu Korzyści dla projektu zwykle będzie czę­
ścią planu realizacji korzyści programu.
19.4.1.2 Organ izacja
Podręczn i kOGC Managing Successfull Programmes
definiuje radę programu, która sk łada się z Właści ­
ciela Programu, dyrektora programu, jednego lub
więcej szefów zmian biznesowych, przedstawicieli
j ednostek funkcjona lnych organizacj i, za l eżnie o d
potrzeb (np. dzi a łów zasobów Judzk ich czy f inan-
sów), głównego dostawcy oraz Przewodniczących
komitetów sterujących proj ektów w ramach pro-
gramu.
Właściciel Programu to osoba po nosząca
indywi-
dualnie ogólną odpowiedz i alność za zapewnienie,
aby program speln i a ł swoje cele i dostarczał
 Dostosowanie metodyki PRINCE2 do warunków projektu I 233

Właściciel
Programu

Sz~f(-oi.vie) Zmian(·y) Przewodniaący KS Dyrektor Przewodniczący KS Ek1pert

Biznesowy<h(·•il (Project A) Ptogramu (Projekty B, C, O itd.) ds. Projekto\'\lania

' - - - - Mi1nujc - - -1 Rada Programu

I
Glówny Użytkownik

Kornltot Stcruj4cy Ptojektu A

• J_---'
Oblługa Klcfownlt I Nidl6r I
Zmian Pro;ektu I Projektu •
• .
Rola „ Wspar<ie
Projektu
łączona

• •
Rola Kierowńik Kierownik Kle1ownik
l4aona Zespołu Zespołu Z"PC>lu

Rysunek 19.3 Struktura organizacyjna, w której Przewodniczący jest członkiem rady programu,
a Głównego Użytkownika mianuje odpowiedni szef zmiany biznesowej

planowane korzyści. Prawdopodobnie to Właściciel razem w celu przeprowadzenia oceny końcowej

Programu zatwierdzi powołanie Przewodniczącego
projektu.
Dyrektor programu jest odpowiedzialny za przygo-
towanie oraz za bieżące zarządzanie i realizację pro-
gramu w imieniu Właści ciela Programu.
Szef zmiany biznesowej j est odpowiedzialny za
określenie i zarządzanie korzyściami przez cały okres
realizacji programu. Rola ta pełni funkcję pomostu
pomiędzy programem a realizowanymi przez orga-
n izację operacjami biznesowymi w celu zapewnie-
nia, by nowe zdolności dostarczane przez projekty
byly wykorzystywane przez organizację w celu
osiągnięcia pożądanych rezultatów i wynikających
z nich korzyści.
Struktura zespołu zarządzania programem oraz
struktura zespołu zarządzania projektem powinny
być zintegrowane tak, aby:
• istniały jasne linie odpowiedzialności od góry do
dołu (tj. aby każda osoba była odpowiedzialna
wobec kogoś);
• uniknąć dublowania odpowi edzialności;
• raporty i przeglądy były efektywne (np. jeś li
cztery projekty w ramach programu posiadają
tych samych członków Komitetu Sterującego, to
zharmonizowanie końców etapów umożliwia,
by w ramach przeglądu programu zbierali się oni
etapu dla wszystkich czterech projektów).
Integracja ról może polegać na tym, że:
• Dyrektor Programu będzie Przewodniczącym
j ednego lub kilku projektów;
• Szef Zmiany Biznesowej w programie
będzi e odgrywał w projekcie rolę Głównego
Użytkownika (lub będzie uczestniczyć w powo-
łaniu Głównego Użytkownika) jednego lub
kilku projektów, albo będzie Przewodniczącym
jednego lub kilku projektów;
• Wsparcie Projektu będzie zapewnione przez
program;
• ekspert do spraw projektowania w programie
Geżeli będzie powołany) będzie pełnić funkcję
Obsługi Zmian łu b Nadzoru Projektu jednego
łub więcej projektów, ponieważ jego celem na
poziomie programu j est zapewnienie, by istniało
odpowiednie zharmonizowanie i kontrola pod-
czas planowania i wprowadzania zmian.
Wybór struktury i nominacji będz ie zależeć od skali
i złożon ości programu. Wady i zalety wyboru struk-
tury organizacyjnej i dokonanych nominacji muszą
być poddane ocenie wraz z ich konsekwencjami.
Na przykład w sytuacji przedstawionej na Rysun-
ku 19.4, gdzie dyrektor programu jest również
Przewodniczącym jednego z projektów w ramach
234 I Dostosowanie metodyki PRINCE2 do warunków projektu

Wlaściciel
Programu

Szef Zmiarly Szef Zmiany Dyrektor

Szef Zmiany
Ekspert
Bitnesowej Biznesowe) 8i.tnesowcj
Programu d$. Projektowania
A B c

Rada Programu
I
Głliwny Utytkownlk

Komitet Sten.tM<Y

, ___ J__
•
Rola
Obslug• Kierownik I Nadrór I
Zmł1n Projt'ktu I Projt:ktu I
ląaona ~ • • • • • • • • I

Rola
ląaona
... Wipatcic
Projektu

Rola Kłc1ownik Kietownik Kierownik

łączona
Zcspolu Zespolu Zespołu

Rysunek 19.4 Struktura organizacyjna, w której dyrektor programu jest Przewodniczącym projektu,
a funkcję Głównego Użytkownika w projekcie pełni odpowiedni szef zmiany biznesowej

programu, należy rozważyć, w jaki sposób sytuacje 19.4.1.4 Plany

nadzwyczajne należy przekazywać ze szczebla pro·
jektu na szczebel programu i czy należy ustanowić
dodatkowe mechanizmy nadzorcze.
Dwa przyklady struktury organi zacyjnej pokazano
Rysunkach 19.3 i 19.4.
Strategia Zarządzania Komunikacją projektu
będzie się wywodzić ze strategii angażowania inte-
resariuszy w programie, przy czym komunikacja
będzie kontrolowana i planowana jako część planu
komunikacji programu. Analiza interesariuszy dla
projektu może być wykonana przez program albo
program może wymagać, aby to projekt przeją!
przewodnictwo w odniesieniu do pewnych grup
interesariuszy, z którymi posiada dobry kontakt.
19.4. 1.3 Jakość
Strategia Zarządzania Jakością projektu wywodzi
ze strategii zarządzan i a j akością programu.
Dzialania dotyczące nadzoru jakości i kontroli jako-
ści mogą być wykonywane przez czlonków zespolu
zarządzania programem.
Ekspert do spraw projektowania programu może
udzielać Kierownikowi Projektu rad i wskazówek
dotyczących wszelkich metod kontroli jakości, które
mają być wykorzystane.
Wszelkie konkretne standardy, zgodnie z którymi
powinni pracować planiści projektu, będą opisane
w strategii monitorowania i kontroli programu.
Dzialania planowania projektu mające na celu opra -
cowanie planu zapewnią, aby te standardy i n arzę­
dzia zostaly przyjęte przez proj ekt.
Program może posiadać dedykowanych planistów,
którzy mogą pomagać Kierownikowi Projektu
w przygotowaniu i utrzymywaniu Planu Projektu
i Planów Etapów.
Sieć współzależnościprogramu będzie zawierać
szczególowe informacje na temat sposobu, w jaki
produkty dostarczane przez każdy projekt są wyko-
rzystywane przez inne projekty w ramach progra-
mu. Wszelkie uzależnienia projektu od innych pro-
jektów programu oraz innych projektów od danego
się proj ektu powinny być uwzględn ion e w planach
projektu.
19.4.1.5 Ryzyko
Strategia Zarządzania Ryzykiem projektu będzie się
wywodzić ze strategii zarządzania ryzykiem progra-
mu. Będzie ona obejmować określenie wspólnego
zbioru kategorii ryzyka, skali ryzyka (dla prawdopo-
dobieństwa, wplywu i bliskości), wszelkich technik
ewaluacji (takich jak pi en i ężna wartość oczekiwana),
 Dostosowanie metodyki PRINCE2 do warunków projektu I 235
tolerancji ryzyka na poziomie projektu oraz mechani-
zmów służących do przekazywania ryzyk na poziom
programu.
19.4.1.6 Zmiana
Strategia Za rzą dza n ia Konfiguracją projektu będzie
się wywodzić ze strategii zarządzania info rmacją dla
programu. Strategia zarządzania informacj ą określa
sposób, w jaki powinny być utrzymywane punkty
styku pomiędzy projektami (np. tak, aby wszelkie
zmiany w projekcie, które mogą wpływać na jeden
lub więcej projektów, były wychwytywane i przeka-
zywane na wyższy poziom zarządzania).
Procedura sterowania zmianami w projekcie będzie
się wywodzić ze strategii rozwi ązywania zagad-
nień programu. Będzie ona określ ać sposób, w jaki
zmiany zakresu proj ektu lub jego produktów, które
powodują przekroczenie tolerancji projektu lub
które mają wp ływ na korzyści programu łub plan
programu, są przekazywane na poziom programu.
W skład Obsługi
Zmian projektu mogą wejść osoby
peniące rolę eksperta do spraw projektowania pro-
gramu.
19.4. 1.7 Postępy
Strategia monitorowania i kontroli programu może
wplywać na formalizm, częstotl iwość i zakres prze-
glą d ów i raportów projektu, a także na wszelkie
standardy zarządzan i a projektem, których n ależy
przestrzegać.
Tolerancje czasu i kosztów na poziomie projektu
będą definiowane przez program.
Na liczbęi długość etapów zarządczych będzie
wpływać plan programu. Pożądane lub niezbęd­
ne może być zharmonizowanie ocen końcowych
etapu z kamieniami milowymi programu (na przy-
kład koniec transzy). Program może nawet okre-
ślać zbiór standardowych etapów za rządczych,
które będą występowały we wszystkich projektach
w programie.
19.4.2 Procesy
W ramach platformy OGC Managing Successful Pro-
grammes, proces Dostarczanie Potencjału w ramach
Zarządzania Transzami jest całkowicie skoncentro-
wany na przygotowywaniu, monitorowaniu i zamy-
kaniu projektów w ramach programu. Ten proces
nie wymaga dostosowania, jeśli projekty programu
są zarządza n e zgodnie z PRINCE2.
Procesem PRINCE2, na który najbardziej oddziału­
je realizacja projektu w ramach programu będzie
Przygotowanie Projektu.
Proces ten może być realizowany prawie całkowi cie
przez program. Program powoła Przewod niczącego
i Ki erownika Proj ektu, dokona przeglądu wcześniej ­
szych doświadczeń, zaprojektuje i powo ła zespół
za rządzan ia projektem oraz prawdopodobnie opra-
cuje Zalożenia Projektu. Kierownik Projektu będzie
jednak odpowiedzialny za przygotowanie Planu
Etapu inicjowania. W tym kontekście nie chodzi
o to, że proces Przygotowanie Projektu nie jest reali -
zowany, ale raczej o to, że jest realizowany głównie
przez program.
19.4.3 Produkty zarządcze
Szereg produktów zarządczych o takich samych
nazwach, na przykła d Strategia Zarządzan ia Ja kości ą,
istnieje zarówno dla projektu, jak i dla programu,
co może być myl ące. W środowisku programu wska-
zane może być do nazw takich produktów zarząd­
czych dodanie słów „projekt" i „program" dla ich
odróżnienia. Innym sposobem jest sporządzenie
wzorów dokumentów dla projektu i programu tak,
aby ich wygląd znacznie się różnił pod względem
stylu, żeby od razu było w iadomo, do czego się
odnoszą.
Na l eży rozważyć, czy dzienniki i rejestry projektu
będą prowadzone lokalnie dla projektu, czy cent ral-
nie w ramach programu. Na przyk ład na l eży zadecy-
dować, czy będzie j eden Rejestr Ryzyk, prowadzony
przez program dla ryzyk na poziomie programu
oraz dla wszystkich ryzyk dla każdego projektu
w ramach programu, czy też każdy projekt powinien
prowadzić swój własny Rejestr Ryzyk. W tym drugim
przypadku Strategia Zarządzania Ryzykiem projektu
powinna określać sposób, w jaki ryzyka dotyczące
programu, które są identyfikowane i wychwytywane
przez projekt, są przekazywane do Rejestru Ryzyk
programu. Podobnie Strategia Za rządzan i a Ryzy-
kiem programu powinna określać mechanizmy dla
ryzyk d otyczących projektu, które są identyfikowane
i wychwytywane na poziomie programu, a które
na leży przekazać do Rejestru Ryzyk projektu.
19.5 SKALA PROJEKTU
Metodyka PRINCE2 może być wykorzystywana nie-
za leżnie od skali projektu. Skala p rojektu zależy od
wielkości i doświadczen ia organizacj i realizującej
projekt - np. projekt o wartości 1O mln zł dla jednej
236 I Dostosowanie metodyki PRINCE2 do warunków projektu

organ izacji może być projektem prostym, a dla innej
ambitnym. Ska la j est związana nie tylko z wielko-
ścią projektu (często mierzoną w kategoriach czasu,
środków pieniężnych i zasobów ludzkich), lecz rów-
nież z kontekstem złożoności, ryzyka i znaczen ia
projektu.
Organizacje powinny rozważyć kwestię skalowania
swoich projektów. W tabe li 19.2 przedstawiono
przykład prostego podejścia do kategoryzacji pro-
j ektów oraz pewne sugestie dotyczące możl iwego
sposobu dostosowania PRINCE2.
Sekcja 19.5.1 zawiera wskazówki dotyczące dostoso-
wan ia PRINCE2 do prostego projektu.
19.5.1 Prosty projekt
Jak zaznaczono powyżej, ska la projektu za l eży od
organizacji i kontekstu. Niemniej jednak i stniej ą
pewne wskaźniki , któ rych rozważeni e jest przydat-
ne w przypad ku projektu, który o rganizacja uważa
za prosty.

Tabela 19.2 Przykłady projektów o różnej ska li

Ska la p rojektu Charakterystyka Zastosowan ie PRINCE2

Duża Program Transformacja biznesu Należy zastosować ramowe zarządzanie progra1nem, takie
·jak OGC Managing Successful Programmes. Metodyka
PRINCE2 może być zastosowana do zarządzania projektami
w programie.

W ielki projekt Wysokie ryzyko, koszt, znaczenie Wiele etapów realizacyjnych

i zainteresowanie mediów
Poszerzony Kom itet Sterujący (np. grupy użytkowników/
(przytłaczający)
dostawców)
Wielodyscyplinarny (np. prace
Prawdopodobnie odrębne role Kierowników Zespołów
budowlane, IT i zmiana biznesu)
Prawdopodobnie odrębna rola Wsparcia Projektu
Międzynarodowy
Produkty zarządcze nie są łączone

Normalny ~rednie ryzyko, koszt, znaczenie
projekt i widoczność (dla otoczenia)
Relacje komercyjne klienVdostawca
W iele miejsc realizacji
Jeden lub więcej etapów realizacyjnych
Standardowy Komitet Sterujący
Odrębne role Kierowników Zespołów (opcjonalnie)
Wsparcie Projektu jako odrębna rola (opcjonalnie)
Niektóre produkty zarządcze są lączone

Prosty projekt Niskie ryzyko, koszt, znaczenie Jeden etap realizacyjny

i zainteresowanie mediów
Uproszczony Komitet Sterujący
Jedna organizacja
Kierownik Projektu pelni rolę Kierownika Zespołu
Jedno miejsce realizacji
Kierownik Projektu pelni rolę Wsparcia Projektu
Produkty zarządcze są łączone

Zadanie Jeśli Komitet Sterujący jest jedno- Jest traktowane jako Grupa Zadań, która dostarcza
osobowy (a zwykle Przewodniczący jeden lub więcej produktów. Wykorzystuje Grupy Zadań,
jest przełożonym Kierownika Opisy Produktów, Dzienniki/Rejestry i Raporty z Punktów
Projektu), wtedy można to na Kontrolnych.
ogól potraktować jako zadanie.
Kierownik Projektu może
wykonywać także prace
specjalistyczne.
Koszty mogą być pokrywane
ze zwykłego budżetu jednostki
organizacyjnej.
Proste uzasadnienie biznesowe -
Mała np. reakcja na polecenie.
 Dostosowanie metodyki PRINCE2 do warunków projektu
Często zadawane pytanie to: które elementy
PRINCE2 można uprościć w prostych projektach?
Odpowiedź na to pytanie nie jest łatwa. Nawet
proste projekty różnią się znacznie pod względem
swego typu i sposobu zarządzania.
Po pierwsze należy pam iętać, że nawet najprostsze
projekty powinny przestrzegać siedmiu pryncypiów
PRINCE2, jeżeli projekty mają być zarządzane zgodnie
z metodyką PRINCE2. To jest w taki sposób, w jaki
tematy, procesy i produkty zarządcze są wykorzysty-
wane, w wyniku „dostosowania" PRINCE2.
Ogólnie rzecz biorąc,
za ceł stosowania PRINCE2
można przyjąć zmniejszenie ryzyka niepowodzenia
projektu. W zwi ązku z tym każdy przypadek uprosz-
czenia jakiegoś elementu PRINCE2 należy traktować
j ako podjęcie związanego z tym ryzyka.
19.5. 1.1 Wykorzy stanie tematów PRINCE2
Tematem podlegaj ącym najwi ększemu wpływowi
w przypadku prostych projektów jest temat Organi-
zacja:
• Dostosowanie organizacji zespolu zarządza­
nia projektem dotyczy głównie konsolidacji ról
i funkcji. Role mogą być łączone, lecz nie wolno
ich pomijać.
• Ponieważ role Przewodniczącego i Glównego
Użytkownika pochodzą ze środowiska klienta,
często można je polączyć.
• Ponieważ Kierownik Projektu będzie mieć
dużo bliższy kontakt z Komitetem Sterującym
niż w przypadku większych i bardziej skom-
p likowanych projektów, członkowie Komitetu
Sterującego często mają więcej możliwości, aby
osobiście pełnić obowiązki Nadzoru Projektu,
zamiast wyznaczać inne osoby do pełnienia tej
roli.
• W przypadku malych zespołów, powołanie
Kierowników Zespołów może nie być konieczne.
Kierownik Projektu może wykonywać ich obo-
wią zki w prostym proj ekcie.
• Kierownik Proj ektu może wykonywać rolę
Wsparcia Projektu i może być członkiem zespo-
lu. W takim przypadku Kierownik Projektu musi
pogodzić wysilki związ.ane z zarządzaniem pro-
jektem z wysiłkami związanymi z wykonywa-
niem prac w projekcie.
W odniesieniu do pozostałych tematów, minimalne
wymagania są następujące :
I 237
Uzasadnienie Biznesowe Jakaś forma wykaza-
•
nia zasadności biznesowej, bez względu na spo-
sób, w jaki jest ono udokumentowane.
• Plany Opisy Produktów dla kluczowych produk-
tów oraz prosty plan w formie harmonogramu,
obejmują cy informacje, kto jest zaangażowany
w produkcję, terminy przeglądów i zatwierdze-
nia produktów, wraz z kamieniami milowymi.
Często taki plan nazywany jest listą kontro l ną
produktów (przyklad zostal podany w zarysie
Opisu Produktu dla Planu w Dodatku A).
• Jakość Uzgodnienie poziomów jakości wyma -
ganych w projekcie oraz od produktów projektu.
• Ryzyko Analiza ryzyk, na które narażony jest
projekt, określenie dzialań, które zostaną pod-
jęte w celu wdrożenia reakcji na ryzyko, oraz
komunikowanie statusu ryzyka za pomocą
Raportów z Punktu Kontrolnego· oraz Raportów
Okresowych.
• Zmiana Prosta metoda kontrolowania zmian
w projekcie oraz zarządzania konfiguracją
dostarczanych produktów - na przykład proste
standardy identyfikacji i kontroli wersji produktu
wraz z organizacją bezpiecznego przechowywa-
nia produktów pracy.
• Postępy Uzgodnione wymagania dotyczą­
ce mechanizmów sterowania i raportowan ia
w jakiejś formie (pisemnej lub ustnej).
19.5. 1.2 Procesy
Wszystkie procesy pozostają istotne, nawet w pro-
stych projektach. Jednak proces Przygotowanie
Projektu można zazwyczaj przeprowadzić w mniej
formalny sposób. Przewodniczący i Kierownik
Projektu powinni jednak unikać poku.sy, by pomi-
nąć ten proces całkowicie. W niektórych przypad-
kach odpowiednie może być polączenie procesów
Przygotowanie Projektu oraz Inicjowanie Projektu
(tj. stworzenie Dokumentacji Inicjowania Projektu
bezpośrednio na podstawie zlecenia przygotowa-
nia proj ektu, z pomin i ęcie m przygotowania Za ło­
żeń Projektu).
19.5. 1.3 Produk ty zarzą dcze
Dobór odpowiedniego formatu produktu zarząd­
czego może pomóc zmniejszyć nakład pracy na
zarządzanie projektem w prostym projekcie, np.:
• Komitet Sterujący może zadecydować, że będzie
otrzymywać niektóre lub wszystkie raporty ustnie
lub będzie dokonywać ustnej wymiany informacji
i decyzji zamiast odbywania formalnych spotkań.
238 I Dostosowanie metodyki PRINCE2 do warunków projektu
W takich przypadkach Kierownik Projektu powi-
nien przynajmniej udokumentować tę wymianę
informacji i decyzje w Dzienniku Projektu, ponie-
waż ludzie mogą inaczej pam iętać ustną umowę
po uplywie kilku tygodni czy nawet dni.
• Raporty mogą mieć formę wiadomości poczty
elektronicznej.
• Dokumentacja Inicjowania Projektu może być
zbiorem slajdów prezentacji.
Należy rozważyć kwestię stworzenia dokumentów,
które w rzeczywistości obejmują więcej niż jeden
produkt zarządczy. Możliwe jest zarządzanie malym
projektem PRINCE2 za pomocą tylko czterech zbio-
rów dokumentów:
• Dokumentacji Inicjowania Projektu, która obej -
muje:
• Za lożenia Projektu;
• Uzasadnienie Biznesowe;
• Strategię Zarządza n ia Ryzykiem;
• Strategię Zarządzania Jakością;
• Strategię Zarządzania Konfiguracją;
• Strategię Zarządzania Komunikacją;
• Plan Projektu, który obejmuje:
• opis Produktu Końcowego Projektu;
• opisy Produktów;
• Plan Przeglądu Korzyści .
• Raporty Okresowe, które obej muj ą:
• Zestawienie Statusu Produktów.
• Dziennik Projektu, który obejmuje:
• zagadnienia;
• ryzyka;
• doświadczenia;
• planowane i faktyczne dzialania dotyczące
zarządzania j akości ą;
• zapisy Obiektu Konfiguracji.
• Raport Ko ńcowy Projektu, który obejmuje:
• Raport Doświ adczeń .
Następująceprodukty zarządcze mogą nie być
potrzebne w prostych projektach:
• Plan Etapu Jeżeli istnieje tylko jeden etap rea li-
zacji, wówczas szczególowe informacje doty-
czące Planu Etapu mogą być wlączone do Planu
Projektu.
• Raporty z Punktu Kontrolnego Jeżeli nie ma
Kierowników Zespolów, może nie być potrzeby
sporządzenia Raportów z Punktu Kontrolnego
(chociaż Kierownik Projektu może polecić poszcze-
gólnym czlonkom zespolu ich dostarczanie).
• Grupy Zadań Mogą być potrzebne wyłącznie
wtedy, gdy w proj ekcie są Kierownicy Zespołów .
Jeżel i jest tylko Ki erownik Projektu, wówczas
Plan Etapu może być wystarczający . J edn akże
nawet w takich przypadkach Ki erownik Projektu
może zdecydować si ę na wykorzystanie Grup
Zadań j ako mechanizmu sterowania w stosunku
do poszczególnych członków zespołu.
• Raport Koń cowy Etapu Jeżeli istnieje tylko
jeden etap realizacji, koniec tego etapu jest jed-
nocześnie końcem projektu, więc wymagany jest
tylko Raport Końcowy Projektu.
• Raport o Zaga dnieniu Jeżeli szczególy doty-
czące zagadnienia są odpowiednio zarejestro-
w ane w Rejestrze Zagadnień (lub w Dzienniku
Projektu), może nie zach odzić pot rzeba sporzą­
dzenia Raportu o Zagadnieniu.
Przykład produktów zarządczych
Po podjęciu decyzji o połączeniu procesów Przy-
gotowanie Projektu i Inicjowanie Projektu dla
prostego projektu, nie przygotowano Zalożeń
Projektu, natomiast zespół zarządzania projek-
tem wykorzysta! zlecenie przygotowania projek-
t u do przygotowania uproszczonej Dokumentacji
Inicjowania Projektu. Dokumentacja Inicjowania
Projektu obejmowala podstawowy Plan Projektu,
z kilkoma Opisami Produktów oraz szczegółam i
dotyczącymi wszystkich strategii i wykorzystywa-
nych mechanizmów sterowania. Kierownik Pro-
j ektu zdecydowal się używać Dziennika Projektu
do rejestrowania ryzyk, zagadnień, doświadczeń
i wyników dotyczących jakości.
Po etapie inicjowania nastąpił jeszcze tylko jeden
etap, w ramach którego zezwolono na wyko-
nanie niewielkiej liczby Grup Zadań . Aby nimi
zarządzać, Kierownik Projektu wyznaczy! okreso-
we punkty kont rolne, które umożliwily mu spo-
rządzen i e regu larnych Raportów Okresowych dla
Komitetu Sterującego.
Na końcu tego etapu (a w konsekwencji - pro-
jektu) zostal sporządzony Raport Końcowy
Projektu, który obejmowal również informacje
dotyczące Raportu Doświadczeń, zaleceń dzialań
następczych i Planu Przeglądu Korzyści.
 Dostosowanie metodyki PRINCE2 do warunków projektu
19.6 ŚRODOWI SKO KOMERCYJNE KLIENT/
DOSTAWCA
Metodyka PRINCE2 zakłada, że projekt jest reali-
zowany w środowi sku klient/dostawca. Przyjmuje,
że istnieje klient, który określi oczekiwany rezu ltat
i prawdopodobnie zapłaci za projekt oraz dostaw-
ca, który dostarczy zasobów i um i ejętności, aby ten
rezultat osiągnąć. Jeżel i relacja pomiędzy klientem
a dostawcą/dostawcami ma charakter komercyjny,
mają zastosowanie dodatkowe c.zynniki. Przede
wszystkim należy uznać, że istnieją co najmniej dwa
zbiory (klienta i dostawcy):
• przyczyn podjęcia projektu;
• systemów zarządzania (łącznie z metodami
zarządzania projektem);
• struktur ładu korporacyjnego (być może wyma -
gających ujawnienia różnych rodzajów danych
o projekcie w różnych punktach okresu życia
projektu);
• środowisk kulturowych firmy (np. formalizm,
skłonność do podejmowania ryzyka itp.).
19.6.1 Wykorzystanie tematów PRINCE2
19.6.1.1 Uzasadnienie Biznesowe
W kontekście komercyjnym istnieją co najmniej dwa
Uzasadnienia Biznesowe - Uzasadnienie Biznesowe
klienta oraz Uzasadnienie Biznesowe dostawcy. Aby
proj ekt się udał, oba Uzasadnienia Biznesowe m uszą
wykazywać ciągłą zasadność biznesową. Jeżeli pro-
jekt przestanie być korzystny, wykona lny i potrzeb-
ny dla jednej ze stron, wtedy projekt napotka na
trudności i najprawdopodobniej zakończy się niepo-
wodzeniem, niezależnie od tego, jak atrakcyjne jest
Uzasadnienie Biznesowe dla drugiej strony.
Uzasadnienie Biznesowe klienta obejmuje korzyści
d la tego klienta odniesione do kosztów i ryzyk d la
całego okresu wdrożenia i eksploatacji produk-
tu proj ektu. Koszty powinny obejmować koszty
wewnętrzne (zasobów projektowych k lienta oraz
zasobów wymaganych dla zapewnienia ciągłej
eksploatacji i utrzymania produktów projektu)
oraz koszty zewnętrzne (towarów i usług dostaw-
ców). Ryzyka powinny obejmować ryzyka związane
z projektem oraz ryzyka związane z działalnością
operacyjną.
Uzasadnienie Biznesowe dostawcy dotyczy tej czę­
ści projektu klienta, która jest związana z danym
dostawcą . Powinno ono obej mować nie tylko usta-
lenie docelowej wartości marży. Na l eży rozważyć
I 239
kwestię,w jaki sposób projekt przyczyni się, z punk-
tu widzenia dostawcy, do osiągnięcia:
• celów dotyczących sprzedaży;
• celów dotyczących planu wspó łpracy z klientem;
• celów dotyczących obszaru sprzedaży;
• celów dotyczących sektora rynku.
Przykład
innych czynników rozpatrywanych
w Uzasadnieniu Biznesowym dostawcy
Zespół do spraw sprzedaży wymaga od kierow-
nictwa wyższego szczebla dostawcy udzielenia
rabatów na poziomie wykraczającym poza
zakres uprawnień zespołu. Przyczyną wniosku
o udzielenie dodatkowego rabatu jest chęć
wygrania obecnego projektu pilotażowego
w celu zwiększen i a prawdopodobieństwa wygra -
nia projektu wdrożen iowego na wi ększą ska lę.
W t akim przypadku Uzasadnienie Biznesowe
dostawcy powinno wyjść poza wykonanie zobo-
wiązań wynikających z przygotowywanej umowy
i objąć koszty działań mających na celu zapew-
nienia dostawcy maksymalnej szansy na pozyska-
nie projektu wdrożeniowego.
Cały tekst Uzasadnienia Biznesowego lub tylko jego
fragmenty mogą być niedostępne dla drugiej strony.
Często zamiast Uzasadnienia Biznesowego k lienta
dostawca może otrzymać po prostu l istę „przyczyn"
złożen i a oferty w zaproszeniu. Choci aż za leży to
od kulturowych podob i eństw organizacji klienta
i dostawcy, to wzajemne ujawnienie głównych przy-
czyn podjęcia realizacji projektu (tj. spodziewanych
korzyści) prowadzi zwykłe do większych korzyści dla
obu stron.
19.6. 1.2 Organizacja
Jedną z kluczowych decyzji, jaką należy podjąć
w środowisku komercyjnym klient/dostawca j est
wskazanie, kto powinien pełnić funkcję Głównego
Dostawcy. Trzeba wtedy rozważyć:
• Czy wskazane jest, aby Główny Dostawca pocho-
dził z organizacji zewnętrznej, jeżeli Komitet
Sterujący będzie musiał omawiać finansowanie
zmian lub przyszłych prac? A co się stanie, jeżeli
dyskusja będzie dotyczyć ewentualnego rozwią­
zania kontraktu z dostawcą? Jednym z możliwych
rozwiązań byłoby po prostu wyłączenie Główne­
go Dostawcy z części narad dotyczących kwestii
o charakterze poufnym. Inne rozwiązane pole-
ga łoby na wyznaczeniu do pełni eni a tej f unkcji
240 I Dostosowanie metodyki PRINCE2 do warunków projektu
osoby z organizacji klienta, która jest odpowie-
dzialna za realizację kontraktu z dostawcą
(np. kierownika do spraw zamówień).
• Co się stanie, jeże li będzie w ielu dostawców?
J eże li będzie tylko k ilku dostawców (powiedz-
my t rzech lub czterech), wówczas zaleca się,
aby wszyscy dostawcy byli członkami Komitetu
Sterującego, pon i eważ sluży on także j ako forum
integracyjne. W przypadku gdy będzie więcej
niż trzech czy czterech dostawców, kierownik do
spraw zamówień odpowiedzialny za realizację
wszystkich kontraktów z dostawcami powinien
zasiadać w Komitecie Sterującym w ich imieniu,
albo właściwe może być powołanie głównego
wykonawcy.
• J eże li proj ekt obejmuje etap wyłaniania dostaw-
ców, kto powinien pe łnić fu nkcję G łówn ego
Dostawcy, j eże li dostawca nie został jeszcze
powo łany? Może wystąpić potrzeba tymcza -
sowego powoła n ia kogoś do pe łnienia funkcji
Głównego Dostawcy, być może z dzia łu zamó-
wień klienta.
Inną kluczową decyzją jest ustalenie, kto wyznacza
Kierownika Projektu. Zgodnie z metodyką PRINCE2,
Kierownik Projektu pochodzi zwykle z organizacji
klienta, podczas gdy Kierownik(-cy) Projektu dostaw-
ców pełnią we wspólnym proj ekcie funkcję Kierowni-
ków Zespołów. Choci aż Kierownicy Zespołów mogą
być nazywani Kierownikami Projekt u w organizacji
dostawcy, nie należy myl ić nazw tych ról i stanowisk
pracy. Należy pamiętać, że w projekcie zgodnym
z PRINCE2 może być tylko jeden Kierownik Projektu.
Mogą istnieć projekty, w których Kierownik Projek-
tu będzie pochodzić z organizacji dostawcy. Klienci
mogą zechcieć trzymać się z dała od spraw związanych
z wykonywaniem prac, oczekując, że dostawca będzie
także zarządzać projektem. Kl ient prawdopodobnie
wprowadzi wówczas bardziej rygorystyczny Nadzór
Projektu (a nawet może zdecydować si ę na powołanie
jednego ze swoich wewnętrznych Kierowników Pro-
jektu, aby odgrywa ł rolę Nadzoru Proj ektu). W takim
przypadku musi być jasne, że mimo iż osoba prowa-
dząca Nadzór Projektu może zajmować w swojej orga-
nizacji stanowisko Kierownika Projektu, osoba ta nie
jest Kierownikiem Projektu dla tego projektu, ponie-
waż może być tylko jeden Kierownik Projektu. Należy
wziąć pod uwagę sposób działania Komitetu Steru-
jącego w przypadku, gdy Kierownik Projektu będzie
w ramach projektu podlegać Przewodniczącemu,
a z tytułu stałego zatrudnienia (lub kontraktu) swemu
ki erownictwu liniowemu - G łównemu Dostawcy.
Zasady ładu korporacyjnego dostawcy mogą ozna-
czać, że Grupa łub Grupy Zadań zlecone mu w pro-
jekcie klienta muszą być traktowane w ramach
organizacj i dostawcy jako projekt. Może to ozna-
czać ustanowienie odrębnego Komitetu Sterującego
w o rganizacji dostawcy. Na l eży wtedy rozważyć
następujące kwestie:
• Kto będzie pełnił funkcję Głównego Użytkownika,
jeżel i nie będzie to ktoś z organizacji klienta
(opiekun danego klienta w organizacji dostawcy
jest przydatnym zastępcą w roli reprezentującej
interes klienta)?
• w jaki sposób role w Komitetach Sterujących
klienta i dostawcy są ze sobą powiązane, tj. któ-
rzy członkowie Komitetu Sterującego dostawcy
peł ni ą funkcję Główn ego Dostawcy w Komitecie
Sterującym klienta? Ni eza l eżnie od tego, kto
to będzie, osoba ta powinna być upoważn i ona
do podejmowania decyzji w imieniu dostawcy
podczas pełn i enia funkcji Głównego Dostawcy
w Komitecie Sterującym klienta.
Istnieje wiele sposobów ustalania struktury ról
w zespole zarządzania projektem w komercyjnym
kontekście klient/dostawca. Głównym celem jest
zapewnienie, aby obie organizacje ustaliły i utrzy-
mywały solidne Uzasadnienia Biznesowe i aby ich
zasady dotyczące ładu korporacyjnego były prze-
st rzegane.
19.6.1.3 Jakość
Strategia Zarządzania Jakością określi, czy projekt
będzie prowadzony zgodnie z systemami zarządza ­
nia jakością klienta lub użytkownika, czy też z oby-
dwoma tymi systemami.
19.6.1.4 Plany
Czy można zawrzeć kontrakt na wykonanie całego
proj ektu, jeżeli Kom itet Sterujący będzi e zatwier-
dzać f inansowanie tylko etap po etapie? Jedno
podejście polega na t ym, by kont rakt obejmował
ca ły projekt, a zamówienia i płatn ości dotyczące
kamieni milowych były dostosowane do każdego
etapu zarządczego. Takie podejście wymaga, aby
organizacje rozważyły, co się stanie w przypad-
ku, gdy projekt przestanie być nadal zasadny dla
którejkolwiek ze stron i zostanie zamknięty przed-
wcześnie. Rozważna praktyka w zakresie udziela-
nia zamówień i zarządzania sprzedażą polega na
zapewnieniu, aby kontrakty przewi dywały możl i ­
wość ich przerwania przez o bie stro ny.
 Dostosowanie metodyki PRINCE2 do warunków projektu
Klient może wybrać sposób za rzą d zania d ziała n ia­
mi dotyczącymi zamówi eń, tj. albo zarządzać n imi
w ramach et apu inicjowania (rozważając możl i­
wość wykorzystania do tego procesów Sterowanie
Etapem i Zarządza ni e Dostarczaniem Produktów),
albo dodać po etapie inicjowania etap obej muj ący
składa ni e za mówi eń . Zarządza ni e zamówieniami
w ramach etapu inicjowania zmniejszy element
n i epewności w planach. Niemniej jednak i stn i ejące
mechanizmy st erowania mogą nie być wyst arcza-
jące, jeżel i działa nia zwi ązane z zamówieniami są
kosztowne i czasochłon n e.
PRINCE2 zakłada, że Grupy Zadań są uzgadniane
pomiędzy Kierownikiem Projektu a Kierownikiem
Zespolu i Plan Zespolu nie jest obowiązkowy. Plan
Zespolu dostawcy może mieć charakter poufny,
ponieważ może zawierać inne informacje, taki e jak
zależności od projektów innych klientów, koszty pod-
wykonawstwa itp. Raport z Punktu Kontrolnego Kie-
rownika Zespolu, zawi eraj ący opis postępów w odnie-
sieniu do kamieni milowych uzgodnionych w Grupie
Zadań, powinien być wystarczaj ący dla Kierownika
Proj ektu do utrzymywania Planu Etapu.
19.6.1.5 Ryzyk o
W kontekści e komercyjnym może i stni eć potrzeba
prowadzenia więcej n iż jednego Rejestru Ryzyk,
pon i eważ niektóre ryzyka związane z projektem
mogą dotyczyć tylko jednej strony, a jed nocześn i e
mogą istnieć uzasadnione przyczyny, dla których
nie powinny one być w idoczne dla drugiej strony.
W przypadku wykorzystania wspólnego Rejestru
Ryzyk, na l eży szczególnie uważn i e ustalić, kogo
dotyczy dane ryzyko, a n astępni e wyznaczyć odpo-
w iedniego właści ciel a ryzyka. Na przykła d w przy-
padku kontraktu o stałej cenie, wszelkie przekrocze-
nia kosztów będą wpływać na Uzasadnienie Bizne-
sowe dostawcy, natomiast przekroczenia terminów
będą zazwyczaj wpływać głównie na Uzasadnienie
Biznesowe klienta.
19.6. 1.6 Zmiana
Procedura sterowania zmianami w Strategii Za rzą­
dzania Kon fi guracją i wszelkie postanowienia doty-
czące zmian, zawarte w kontrakcie, powinny być
zharmonizowane. Jeżeli budżet zmian jest wyko-
rzystywany, na l eży go dostosować do procedur
klienta dotyczących udzi elania zamówień oraz do
procedur dostawcy dotyczących sprzed aży usłu g.
(Na przykład na leży u stalić, czy klient zatwier-
dziwszy zmianę, wystosuje nowe zamówienie, czy
I 241
zmieni zamówienie pierwotne, czy też zamówienie
pierwotne obejmie zarówno bud żet proj ektu, jak
i budżet zmian? Czy procedura sprzedaży uslug
dostawcy będzie wymagać odrębn ego zatwierdze-
nia przez kierownictwo dostawcy każdego w nio-
sku o wprowadzenie zmiany, czy j est to części ą
zatwierdzeniu projekt u przez kierownictwo?).
19.6.1.7 Postępy
Częstotliwość, sposób przedstawienia i f ormalizm
dokonywania przeglądów i raportowania musi
być zharmonizowane z wymogami obu organizacj i
dotyczącymi ladu korporacyjnego. Na przykład Kie-
rownicy Zespo łów być może będą musieli przygoto-
wać dwa Raporty z Punktu Kontrolnego - j eden dla
Kierownika Projektu ze strony klienta, a drugi dla
kierownictwa dostawcy. Zawartość tych raportów
może się różn i ć (na przykład Raport z Punktu Kon-
trolnego dla kierownictwa dostawcy może obejmo-
wać informacje dotyczące pojawienia s i ę nowych
moż l iwości w zakresie sprzedaży).
19.6.2 Procesy
Pon i eważ metodyka PRINCE2 jest oparta na rela-
cj ach klient/dostawca postrzeganych z perspektywy
klienta, jest mało prawdopodobne, aby procesy po
stronie klienta wymagały dostosowania.
Z perspektywy dostawcy glówna zm iana proce-
sów będ z i e dotyczyć procesów Przygotowa n ie
Projektu i In icjowanie Projektu. Proces Przy-
gotowan ie Proj ektu odbywa s i ę w organizacji
dostawcy przed zawarciem kontraktu, zazwy-
czaj w odpowiedzi na skierowane p rzez klienta
zaproszenie do zleże ni a oferty. Cz ęść procesu
Inicjowan ie Proj ektu będzie s i ę więc o d bywać
przed zawarciem kontraktu, pon i eważ dostaw-
ca będzie musial sformu łować strateg ie, p lany
i mechan izmy sterowan ia w celu oceny zasad -
ności i potrzeby dokonan ia sp rzedaży, a także
związa n yc h z tym kosztów i cen pro ponowanego
rozw i ązan i a . Proces Inicjowanie Projektu nie
będz i e zakończony, dopóki nie zostaną zakoń ­
czone negocjacje dotyczące kontraktu i dopóki
Komitet Steruj ący klienta n ie zatwierdzi projek-
t u. Negocjowanie kontraktu powinno być zarzą ­
dzane zgodn ie z ustaloną procedurą sterowania
. .
zm1anam 1.
Dodatkowy wymóg polega na zharmonizowaniu
procesów sprzedaży uslug d ostawcy z procesem
Przygotowanie Proj ektu (kwa Iifikowanie szansy)
i procesem Inicjowanie Proj ektu (zat wierdzanie
242 I Dostosowanie metodyki PRINC E2 do warunków projektu
oferty). Racjonalnym podejściem jest sporządzenie
wszelkiej dokumentacji projektu w formie osta·
tecznej wersji roboczej w ramach dzi ałań przed
zawarciem kontraktu, aby mogła ona być następn i e
zatwierdzona jako część przyznanego kontraktu.
19.6.3 Produkty zarządcze
W jaki sposób Dokumentacja Inicjowania Projektu
i Grup Zadań dotyczą kontraktu? Jednym z aspek-
tów kontraktu jest opisanie, kto ponosi odpowie-
dzialność w przypadku niewykonania zobowiązań
umownych przez którąś ze stron. Zawartość Doku-
mentacji Inicjowania Projektu powinna się kon-
centrować na tym, w jaki sposób należy zapewnić
wykonanie zobowiązań każdej ze stron. W związku
z tym obydwa te dokumenty służą różnym celom.
Dokumentacj a Inicjowania Projektu może być czę­
ścią dokumentacji kontraktu, z tym że należy zacho-
wać ostrożn ość, gdyż może to ograniczyć zdolność
projektu do adaptacji, jeżeli Dokumentacja Inicjo-
wania Projektu będzi e musiała przechodzić przegląd
pod kątem prawnym w przypadku każdej zmiany.
W przypadku dostawcy zewnętrznego, Grupa Zadań
może przybierać formę prawnie wiążącego kon-
traktu i być może trzeba będzie zmodyfikować jej
zawartość w celu uwzględnienia wszelkich wymaga-
nych postanowień i warunków.
19.7 PROJEKTY OBEJ MUJĄCE W IELE
ORGANIZACJI
Kontekst organizacyjny takich projektów staje się
o wiele bardziej zlożony. Zamiast prostej relacji
klient/dostawca, obejmującej dwie organizacje,
podejmowane są projekty, które obejmują więcej
organizacji.
Przyklady to:
• wspólne przedsięwzi ęcia (joint ventures);
• współpraca badawcza;
• projekty realizowane przez kilka jednostek orga-
nizacyjnych;
• projekty międzyrządowe (np. Unia Europejska);
• projekty międzyagencyjne (np. Program
Narodów Zjednoczonych do spraw Rozwoju);
• kontrakty sojusznicze (aliance contracting);
• konsorcja występujące razem w ofertach;
• partnerstwa.
Może i stnieć jedna główna organizacja zl ecaj ąca
(lub jeden g łówny klient), ale może równ i eż i stn i eć
kilku klientów. Na podobnych zasadach może istnieć
kilka organizacji dostawców. Może to doprowadzić
do sytuacji, w której projekt będzie posiadać wielu
właścici eli, tzn. więcej niż j edna organizacja będzi e
sprawować kontrolę n ajwyższego szczebla nad
procesem podejmowania decyzji. Nieuzgodnienie
podstaw takiej „współwłasności " naraża projekt na
ryzyko i zwiększa prawdopodobieństwo niepowo-
dzenia projektu.
Wskazówki dotyczące wykorzystania PRINCE2
w projektach posiadających wielu właścicieli są
podobne do kontekstu komercyjnego klient/dostaw-
ca pod względem dostosowania tematów, gdzie
odniesienia do „kontraktu" zostają zamienione na
odniesienia do „uzgodnienia". Niemniej jednak
uzgodnienia dla projektów obejmujących wiele
organizacji mogą być bardzo złożone. Na przyklad
Komitety Steruj ące mogą m i eć więcej czł onków
n iż w praktyce potrzeba do efektywnego podej-
mowania decyzji. Jeżeli żadna ze stron nie będzie
posiadać przewagi nad pozostałymi stronami, na l eży
wypracować konsensus w przypadku każdej decyzji.
Duże Komitety Sterujące wymagające osiągnięcia
konsensusu pracują bardzo wolno, więc tempo reali -
zacji projektów prawdopodobnie na tym ucierpi.
Kierownicy Projektów mogą też zacząć podejmować
decyzje wykraczające poza zakres ich uprawnień.
Na l eży wówczas rozważyć kwesti ę przyjęcia struktur
organizacyjnych podobnych do stru ktur za rządza nia
programem, co pomoże przy za rzą dzani u korzyścia­
mi i angażowaniu interesariuszy.
19.8 TYP PROJEKTU
19.8.1 Modele cyklu życia
Wiele branż lub profesji opracowało modele cyklu
życia dla poszczególnych typów projektów, np. meto-
dy kaskadowe lub metody zwinne. PRINCE2 dobrze
współdziala z takimi modelami, ponieważ koncen-
trują się one glównie na działan iach mających na celu
tworzenie i weryfikację specjalistycznych produktów
projektu, czyli tego aspekt u projektów, którego
metodyka PRINCE2 świ adomie nie uwzg l ędn i a.
Dostosowanie metodyki PRINCE2 do współdziałania
ze specjalistyc.znymi modelami cyklu życia projektów
obejmuje w głównej mierze:
• Dostosowanie etapów zarządczych do cyklu roz-
woju produktu, np. projektowanie, budowa,
testowanie, przekazanie.
 Dostosowanie metodyki PRINCE2 do warunków projektu
• Wykorzystanie tolerancji dostosowanych do kon-
centracji na wytwarzaniu produktów, np. pro-
jekty zwinne, które wykorzystują podejście ite-
racyjne i przyrostowe, określają terminy i jakość
(wąski przedział tolerancji) i dopuszczają zmianę
zakresu (szeroki przedział tolerancji).
• Włączenie wszelkich specjalistycznych ról do
struktury zespołu zarządzania projektem.
Na przykład jeżeli model cyklu życia obej-
muje jednostkę organizacyjną do spraw pro-
jektów technicznych, czy rola ta powinna
być równorzędna w stosunku do Kierownika
Projektu, do Kierownika Zespołu, który pod-
lega Kierownikowi Projektu, czy też powinna
mieć formę Nadzoru Projektu? Ponieważ role
są po prostu zbiorem obowi ązków, nie jest aż
tak ważne, j ak nazywa się dana rola, ale istotne
jest, aby obowiązk i zdefiniowane dla ról zostaly
przydzielone komuś z organizacji i aby przydzial
ten byl jednoznacznie rozumiany przez wszystkie
zaangażowane osoby.
• Wykorzystanie metodyki PRINCE2 dla produktów
za rządczych projektu (np. Założeń Projektu) oraz
wykorzystanie specjalistycznej metody w celu
określenia przeznaczenia, sposobu przedstawie-
nia, zawartości i kryteriów jakości dla specjali-
stycznych produktów zarządczych (np. definicja
architektury rozwiązania w DSDM Atern). Metody
specjalistyczne mogą również dostarczać pew-
nych produktów zarządczych projektu, tak więc
istotne jest, aby zidentyfikować, które z produk-
tów zarządc.zych mają być pomocne przy tworze-
niu produktów specjalistycznych (np. techniczna
dokumentacja projektowa), a które mają pomóc
za rządzać projektem. Dla każdego produktu
zarządczego proj ektu należy podj ąć decyzję, czy
zastosować ekwiwalent PRINCE2, czy nie. Celem
jest unikanie powieleń i luk.
• Określen i e punktów styku pomiędzy procesem
Zarządzanie Dostarczaniem Produktów a proce-
sami wytwarzania produktów specjalistycznych.
19.8.2 Projekt ewoluujący
Z badań finansowanych przez Engineering and
Physical Sciences Research Council, zatytułowa nych
Rethinking Project Management (Nowe spojrzenie
na zarządzanie projektami, Winter and Smith, 2006)
wynika, że w dzisiejszych czasach projekty zwykle
nie zaczynają się od z góry określonej specyfikacji,
lecz posiadają specyfikacje zm ieniające się w miarę
postępu projektu. Ponadto specyfikacje są często
kwestionowane i mogą podlegać negocjacjom przez
I 243
cały cykl życi a proj ektu. Wynika z tego, że ponieważ
specyfikację ukierunkowuje Uzasadnienie Bizneso-
we, projekt nie może się rozpocząć z określonym
z góry Uzasadnieniem Biznesowym.
Metodyka PRINCE2 traktuje paradygmat ewolucyjny
w ten sposób, że Uzasadnienie Biznesowe reprezen-
tuje „najlepszą uzgodnioną prognozę" w danym
momencie cyklu życia projektu, która będzie się
zmieniać wraz z przechodzeniem projektu od rozpo-
znania do wdrożenia.
Zarys Uzasadnienia Biznesowego, opracowany
przed projektem (podczas procesu Przygotowa-
nie Projektu), będzi e prawdopodobnie zawierać
zakrojoną na szeroką skalę prognozę pożądanych
rezultatów (np. obniżkę kosztów o 30% - 50°/o),
podczas gdy szczególowe Uzasadnienie Biznesowe,
uaktualnione w połowie projektu, będzie praw-
dopodobnie zawi e rać dużo węższą prognozę (np.
obniżkę kosztów o 35% - 40°/o). Ponadto w m i a rę
postępu projektu zestaw produktów wymaganych
do dostarczenia pożądanych rezu ltatów będzie
również prawdopodobnie pod l egać ewolucj i.
Znaczenie zmieniającego się Uzasadnienia Bizneso-
wego polega na tym, że pozwala ono organizacji
na złożenie zobowiązań inwestycyjnych, które są
współmierne do oczekiwanych korzyści i ryzyk pro-
gnozowanych w danym momencie ewolucji projek-
tu. Uzasadnienie Biznesowe daje również podstawę
do kontroli i oceny wpływu wnioskowanych zmian
będących konsekwencją „możliwych do kontestowa-
nia i otwartych na negocjacje przez cały okres trwa-
nia projektu" aspektów nowoczesnych projektów.
Projekty obejmujące prace badawczo-rozwojowe,
projekty dotyczące sformułowania nowej polity-
ki lub przeprowadzenia studium wykon alności są
typowe dla paradygmatu ewol uującego projektu.
Wymagają one szczególnego rozważen i a, ponieważ
mogą nie przynosi ć żad nych bezpośred n i ch korzyści
(tylko zbiór opcji) i prawdopodobnie doprowadzą
do uzyskania negatywnego zwrotu z inwestycj i.
Możliwa jest wycena opcji, co oznacza, że możliwe
jest porównanie wartości dwóch projektów badaw-
czo-rozwojowych, j eże l i trzeba ustalić priorytety.
19.8.3 Projekt typu studium wykonalności
W niektórych przypadkach studium wykona lności
może być wymagane w celu zbadania sytuacji i usta-
lenia opcji dalszych dzialań. Przy wykorzystaniu
PRINCE2 jedno z podejść polegałoby na potraktowa-
niu takiego studium jako odrębnego projektu.
244 I Dostosowanie metodyki PRINCE2 do warunków projektu
Zdefiniowany . .
Analiza
problem
Rysunek 19.5 Przykład cyklu życia projektu typu studium
Rysunek 19.5 przedstawia stosunkowo prosty cykl
życia projektu typu sporządzenie studium wykonal-
ności. Posiada on jako projekt jeden Plan Projektu,
jedno Uzasadnienie Biznesowe, jeden zbiór ryzyk
oraz jeden produkt projektu - rekomendację. Roz-
ważane opcje mogą się bardzo znacznie różnić pod
względem kosztów i terminów. Każda opcja będzie
posiadać odpowiadający jej Plan Projektu, Uzasad-
nienie Biznesowe i zbiór ryzyk, ale na końcu projek-
tu typu studium wykona ln ości będzie tylko jedna
rekomendacja.
Jeżeli studium wykona l ności będzie traktowane jako
samodzielny projekt, wówczas istotne jest zrozumie-
nie, że rezultat jest tylko opcją, tj. opcją pozwalającą
zdecydować o tym, czy kontynuować działania, czy
nie. Powodzenia nie należy oceniać na podstawie
tego, czy pomysl jest wykonalny, ale na podstawie
zdol ności do podjęcia uzasadnionej decyzji na pod-
stawie przeprowadzonej analizy.
Projekty dotyczące sformułowan i a polityki są
podobne do projektów typu studium wykona ln ości
pod tym względem, że ich wynik nie ma bezpo-
średniej wartości. Wartość zostaje wytworzona
w wyniku późniejszego wdrożenia tej polityki.
Ponieważ projekty dotyczące formułowania polityki
wytwarzają produkty, PRINCE2 jest idealną metody-
ką do zastosowania. Jednak kluc.zową kwestią jest
charakter Uzasadnienia Biznesowego. Uzasadnienie
projektu dotyczące polityki może być sluszne, lecz
pomimo to istotne jest zapewnienie, by inwestycja
w projekt dała wartość uzasadniającą poniesione
naklady.
19.9 RÓŻNICE SEKTOROWE
Cechy projektu mają zastosowanie niezależnie od
tego, czy organizacja działa w sektorze publicznym,
czy prywatnym. Główna różnica będzie dotyczyć
treści i charakteru Uzasadnienia Biznesowego.
Dostosowanie nie jest jednak wymagane, ponieważ
PRINCE2 nie określa, co czyni Uzasadnienie Bizneso-
we korzystnym, wykonalnym i potrzebnym. Kwestie
te będą s i ę różn i ć w przypadku sektora publicznego
Opracowanie Przedstawienie
..
-
OPCJ I rekomendacji
wykonalności
i sektora prywatnego, ale potrzeba posiadania Uza-
sadnienia Biznesowego i sposób jego wykorzystania
w projekcie będą takie same.
Przykładowo w sektorze publicznym w Wielkiej
Brytanii istnieją dwie kwestie, które mogą wymagać
dostosowania metodyki PRINCE2:
• Czy projekt potrzebuje Wlaściciela (patrz sekcja
19.9.1)?
• Czy projekt podlega Przeglądowi OGC Gateway
(patrz sekcja 19.9.2)?
19.9.1 Właściciel Programu/Projektu
WłaścicielProgramu/ Projektu jest osobą odpo-
wiedzialną za zapewnienie, aby projekt lub
program osiągnął swoje cele i dostarczy! przewi-
dywane korzyści.
Rola Właścicie l a Programu/Projektu (ang. Senior
Responsible Owner) została wprowadzona na
szeroką ska l ę w brytyjskim sektorze bud żetowym
dla dużych projektów i programów i obecnie jest
coraz częściej wykorzystywana w innych sektorach
i w innych krajach. Należy podkreślić, że Właściciel
Programu/Projektu nie jest rolą z PRINCE2. Niemniej
jednak:
• W kontekście programu Przewodnic.zący powi-
nien podlegać Właścicielowi Programu wyzna-
czonemu dla programu. Może również być wska-
zane, aby byl on j ednoczesnie Przewodniczącym
dla dużych projektów w ramach programu.
• W przypadku, gdy Wlaściciel Projektu zostanie
powolany w kontekście jednego dużego projek-
tu, osoba podejmująca tę rolę podejmie również
rolę Przewodniczącego lub wyznaczy osobę,
która będzie pelnila funkcję Przewodniczącego.
19.9.2 Przegląd kontynuacyjny typu OGC
Gateway
Przeglądtypu OGC Gateway bada projekty w klu -
czowych punktach decyzyjnych w cyklu ich życi a.
 Dostosowanie metodyki PRINCE2 do warunków projektu
Wybiega on w przyszłość w celu zapewnienia, że
można przejść z powodzeniem do następnego
etapu. Proces ten na l eży do zbioru najlepszych prak-
tyk stosowanych w brytyjskich centralnych organach
rządowych, w służb i e zdrowia, w organach samo-
rządowych i w sektorze obrony narodowej, a także
został przyj ęty przez liczne inne kraje dla projektów
opartych na zamówieniach publicznych, wykorzystu-
jących środki publiczne.
Przegląd OGC Gateway polega na „przeglądzie
partnerskim", w ramach którego niezależni praktycy
spoza projektu wykorzystują swoje doświadczenie
i wiedzę w celu zbadania postępów i prawdopodo-
bieństwa pomyślnego zakończenia projektu. Stosuje
się go, by uzyskać cenne dodatkowe spojrzenie na
zagadnienia stojące przed zespołem wewnętrznym,
oraz stanowi zewnętrzne w yzwanie dla so l idności
planów i procesów.
Przegląd kontynuacyjny odbywa się w różnych
momentach cyklu życia projektu i zespół wykonu-
jący przegląd będzie musiał rozważyć relatywne
znaczenie poszczególnych aspektów dotyczących
pewności pomyślnego zakończenie projektu, biorąc
pod uwagę etap, który projekt osiągnął. W przy-
padku, gdy projekt jest w przygotowaniu i Uzasad-
nienie Biznesowe nie zostało jeszcze ukończone,
ocena może być zdominowana oceną jakości zakre-
su, trwa łości struktury ładu korporacyj nego oraz
zaangażowania kierow nictw a wyższego szczebla.
Ch ociaż czynniki te będ ą prawdopodobnie zaliczać
się do kluczowych czynników sukcesu każdego pro-
jektu, to w późn i ejszej fazie cyklu życia projektu
większą wagę będzie mieć stosowność wykorzysty-
wanych procesów oraz umiejętności i możliwości
dostępne dla projektu.
Przeglądkontynuacyjny może być zharmonizowany
z PRINCE2 w następujący sposób:
• Przegląd nr 1: Zasadność biznesow a Przeg ląd
ten koncentruje się na zasadności biznesowej
projektu przed podjęci em kluczow ej decy-
zj i o zatwierdzeniu inicjowania projektu. Jest
on zharmonizowany z d ziała niem w ramach
Zarządzania Strategicznego Projektem polegają ­
cym na zezwoleniu na inicjowanie.
• Przegląd nr 2 i 3: Strat egia reali zacj i i decy-
zja inwestycyjna Przeglądy te są zharmoni-
zowane z działaniem w ramach Zarządzania
Strategicznego Projektem polegającym na
zezwoleniu na realizację Planu Etapu lub Planu
Nadzwyczajnego i koncentrują się na zapewnie-
I 245
niu, że projekt jest nadal potrzebny, przedsta-
wia godziwą wartość w stosunku do nakładów
i posiada jasną strateg i ę realizacj i.
• Przegląd 4: Gotowość do wdrożeni a
Koncentruje się na gotowości organizacji
do wdrożen i a projektu i jest zharmonizo-
wany z dzia łaniem w ramach Za rządza n ia
Strategicznego Proj ektem polegającym na
zezwoleniu na rea l izację Planu Etapu lub Planu
Nadzwyczajnego.
Innym sposobem rozważenia harmonizacji obydwu
tych podejść byłoby zorganizowanie etapów projek-
tu w taki sposób, by były powiązane z przeglądami:
inicjowanie (Przegląd nr 1), etap zamówień (Prze-
g l ąd nr 2), etap projektowania ogólnego (Przegląd
nr 3), etap projektowania szczegółowego (Przeg l ąd
nr 4), etap realizacji i etap przekazania.
Przeg lądkontynuacyjny nie jest jednoznaczny
z „bramką" lub punktem decyzyjnym (t akim jak
ocena końcowa etapu), jest natomiast środk i em slu-
żącym do zapewnienia dodatkowego nadzoru jako
punktu wyjściowego do faktycznej oceny końcowej
etapu dotyczącej tego, czy projekt jest w stanie osią­
gnąć swoje cele. Koszty i terminy przeprowadzenia
przeglądów kontynuacyjnych powinny być uwzględ­
nione w Planie Projektu i w Planach Etapów.
19.10 KOMPENDIA W IEDZY O ZARZĄDZA­
NIU PROJEKTAMI
Nie należy myl ić PRINCE2 z Kompendium Wiedzy:
• PRINCE2 jest zintegrowaną metodyką zarządza­
nia projektami, dostarczającą zbioru procesów
i tematów, które mogą być zastosowane do
zarządzania projektem od początku do końca.
• Kompendium Wiedzy obejmuje szeroki zakres
kompetencji i technik zarządzania projekta-
mi, których mogą potrzebować Kierownicy
Proj ektów, m.in. takich, jak u miej ętność przewo-
dzenia i negocjowania.
Porównanie pom i ędzy PRINCE2 a kompendium w ie-
dzy takim, jak Kompendium W iedzy Stowarzyszenia
Za rządzan i a Projektami (the Association for Project
Management's Body of Knowledge), Kompendium
Wiedzy o Zarządzaniu Projektami Instytutu Zarzą­
dzania Projektami (the Project Management lnstitu-
te's PMBoK) lub Baza Kompetencji Stowarzyszenia
Zarządzania Projektami (the International Project
Management Association's Competency Baseline),
przedstawiono w Tabeli 19.3.
246 I Dostosowanie metodyki PRINCE2 do warunków projektu
Tabela 19.3 Porównanie PRINCE2 i Kompendium Wiedzy
PRINCE2
Metodyka zarządzania projektami
Nakazowa
Zintegrowany zbiór procesów i tematów (nie są one
odizolowanymi silosami informacyjny1ni, które można
stosować wybiórczo)
Obejmuje wszystkie role zarządzania projektem
-----·~-------
Nie obejmuje umiejętności interpersonalnych
Ma odniesienia do technik
Różnice pomiędzy PRINCE2 (metodyką) a Kompen-
dium Wiedzy sprawiają, że bardzo dobrze się one
wzaj emnie uzupe lniaj ą.
PRINCE2 dostarcza ra m okreś l ających, co ma być
zrobione, przez kogo i kiedy. Kompendium Wiedzy
dostarcza szeregu technik określających, jak należy
to zrobić. Na przykład w PRINCE2 krytycznym kro-
kiem w tworzeniu planu jest szacowanie. PRINCE2
nie określa, j ak na l eży przeprowadzić szacowanie,
ponieważ istnieje szereg t echnik, które mogą być
wykorzystane, w za l eżności od kontekstu projek-
tu, podczas gdy Kompendum Wiedzy dostarcza
wyjaśnień i analizy wachlarza dostępnych technik
szacowania tak, aby planista mógl ocenić, która jest
najbard ziej odpowiednia do wyko rzystania.
Kompendium Wiedzy
Szeroki zbiór .dobrych praktyk" dotyczących zarządzania projektami
Nienakazowe
Każdy zakres tematyczny można rozważać w oderwaniu od innych
Nastawione na Kierowników Pro1ektów
--- - -- - - -- - -
Obejmuje umiejętności interpersonalne
Opisuje techniki
- ----
Dostosowanie PRINCE2 w przypadku, gdy organi-
zacja jest zharmonizowana z określonym Kompen-
dium Wiedzy, powinno obejmować:
• Uzgodnienie jednego zbioru w arun ków,
które maj ą obowi ązywać. Na przykład zgod-
na z Kompendium Wiedzy Stowarzyszenia
Zarządzania Projektami (APM), „grupa sterująca"
jest równoważna Komitetowi Sterującemu
w PRINCE2.
• Zharmonizowanie produktów zarządczych
PRINCE2 z produktami za rządczym i rekomen-
dowanymi przez kompendium wiedzy. Na przy-
kład „karta projektu" w Kompendium Wiedzy
o Zarządzan iu Projektami, odpowiada Zależe­
niom Projektu w PRINCE2.
Dodatek A: Zarysy Opisów Produktów
Niniejszy dodatek zawiera zarysy Opisów Produk-
tów dla zdefiniowanych produktów zarządczych
PRINCE2. Zarysy te nie stanowi ą pelnych Opisów
Produktów, w sensie zawartości takiego opisu
zdefiniowanego w Opisie Produktu w sekcji A.17,
ponieważ niektóre ich elementy, takie jak np.
metoda kontroli jakości, będą się różni ć w zależno­
ści od potrzeb danego projektu. Podano przykłady
formatów, ale nie wyczerpują one wszystkich moż­
liwości. Zawartość Opisu Produktu dla produktu
za rządczego powinna być dostosowana do wyma-
ga ń i środowiska każdego projektu. Istnieją t rzy
rodzaje produktów zarządczych: bazow e (odniesie-
nia), zapisy i raporty.
Bazowe produkty zarządcze to te produkty, które
definiują określ on e aspekty projektu, a po zatwier-
dzeniu podlegają procedurze sterowania zmianami.
Są to:
• A.1 Plan Przeglądu Korzyści (Benefits Review
Plan);
• A.2 Uzasadnienie Biznesowe (Business Case);
• A.4 Strategia Zarządzania Komuni kacją
(Communication Managemen t Strategy);
• A.6 Strategia Zarządzania Konfi guracj ą
(Configuration Management Strategy);
• A.16 Plan obejmuje Plan Projektu, Plan Etapu
i opcjonalnie Plan Zespołu; (Plan);
• A.17 Opis Produktu (Product Description);
• A.19 Założenia Projektu (Project Brief);
• A.20 Dokumentacja Inicjowania Projektu (Project
lnitiation Documentation);
• A.21 Opis Produktu Końcowego Projektu (Project
Product Description);
• A.22 Strategia Zarządzania Jakością (Quality
Management Strategy);
• A.24 Strategia Zarządzania Ryzykiem (Risk
M anagement Strategy);
• A.26 Grupa Zadań (Work Package).
Zapisy to produkty zarządcze podlegające częstym
zmianom, które zawierają informacje dotyczące
postępów projektu. Są to:
• A.5 Zapisy Obiektu Konfiguracji (Configuration
Item Record);
• A.7 Dziennik Projektu (Daily Log);
• A.12 Rejestr Zagadn i eń (lssue Register);
• A.14 Dziennik Doświadczeń (Lessons Log);
• A.23 Rejestr J akości (Quality Register);
• A.25 Rejestr Ryzyk (Risk Register).
Raporty to produkty zarządcze przedstawiające
zarejestrowany obra z stanu niektórych aspektów
projektu. Są to:
• A.3 Raport z Punktu Kontrolnego (Checkpoint
Report);
• A.8 Raport Końcowy Projektu (End Project
Report);
• A.9 Raport Końcowy Etapu (End Stage Report);
• A.1O Raport Nadzwyczajny (Exception Report);
• A.11 Raport Okresowy (Highlight Report);
• A.13 Raport o Zagadnieniu (lssue Report);
• A.15 Raport Doświadczeń (Lessons Report);
• A.18 Zestawienie Statusu Produktów (Product
Status Account).
Chociaż zapisy i raporty nie podlegają procedurze
sterowania zmianami, podlegają jednak innym
aspektom zarządzania konfiguracją, takim j ak np.
sterowanie wersjami, bezpieczne przechowywanie,
prawa dostę pu itp.
Produkty zarządcze nie muszą mieć koniecznie
formy dokumentu; są to zestawy informacj i, które są
wykorzystywane w procesach PRINCE2 w celu umoż­
liwienia określonym rolom podjęcia działań
i/łub decyzji.
Większość produktów bazowych jest opracowy-
wana i rozwijana w trakcie działań przedprojek-
towych i etapu inicjowania projektu, jak przedsta-
wiono na Rysunku A.1. Produkty bazowe są następ­
nie poddawane przeg l ądowi oraz (ewent ualnie)
aktualizacji na końcu każdego etapu. Produkty
zarządcze, wchodzące w skład produktów zarząd­
czych wyższego szczebla, zostały przedstawione
w zawartości każdego produktu zarządczego przez
odniesienie do przypisanego im numeru sekcji
w Dodatku A (np. jeżeli Raport Doświadczeń wcho-
dzi w skład innego raportu, wówczas będzie odnie-
sienie do sekcji A.15).
250 I Dodatek A: Zarysy Opisów Produktów

• Zle<enie •
przygot01Nania • Przed projełttem Etap inicjowani.a

~ -- projektu
„ ......
-
Dokumentacja
Załoteni a Pfojektu
Inicjowania Proj~ktu

Opis Pfoduktu KOf~CO· _ _,.. frlłgmenty Zalołeń Projektu

wego P1ojektu

Z•wł~r•I~
Uzasadnienie
L Za~
Utasadnienia
Biz
t--• Biznesowe
(„aególowel

S11ategia Zanądzania

- Plan Etapu
(Etap inicaow•ni<i)
I Jakokią

Strategia Zarządzania
--""I Konfiguracją

Strategia Za rząd%ania
+I Ryzykiem

Strategia Zarządzania
Komunikacją

Plan Projektu

Op<s Produktu
Końcowego Projektu

.„„„ „„„„„„„„ „ .
·----------------
' '
''
+t Plnn Eta1>u Mote byl czę!cl~
Planu Projektu
'' dla małych
'' I
Złwltr• projektów
''
'' L opisy Produktów
''
'' -
'
~ Grupy Zadań
'
''
''
' Plan Przegl~du
~ Korzykl
''
·- --------- ---- -- -------------
Rysunek A. 1 Fazy rozwoju bazowych produktów zarządczych

A.1 PLAN PRZEGLĄDU KORZYŚCI Projektu, aktualizowany na końcu każdego etapu

i wykorzystywany w procesie Zamykanie Projektu do
A.1.1 Przeznaczenie określ enia wszystkich wymaganych poprojektowych
przeglądów korzyści.
Plan Przeglądu Korzyści jest wykorzystywany do
określenia, jak i kiedy możliwy będzie pomiar osią­ Plan powinien obejmować działa n ia mające na celu
gnięcia korzyści z projektu oczekiwanych przez sprawdzenie, czy oczekiwane korzyści z produktów
G łównego Użytkown ika. Plan ten j est przedsta- zostały zrealizowane oraz jak efektywne są produk-
w iany Przewod niczącemu w procesie Inicjowanie t y podczas ich użytkowa nia. Dla każd ej oczekiw anej

korzyści należy określić stopień jej osiągnięcia oraz
c.zy jest potrzebny jakiś dodatkowy czas na doko-
nanie oceny korzyści rezydualnych. Użytkowanie
produktów projektu może przynieść nieoczekiwane
efekty uboczne, zarówno korzystne, jak i nieko rzyst-
ne. W Planie Przeg l ądu Korzyści należy uwzględn i ć
naklad czasu i pracy niezbęd ny do zidentyfikowania
i analizy powodów, dla kt órych te efekty uboczne
nie zostaly przewidziane.
Jeżeli projekt jest częścią programu, Plan Przeglądu
Korzyści może być zawarty w planie realizacji korzy-
ści programu i może być realizowany na poziomie
programu. Po zakończeniu projektu Plan Przeglądu
Korzyści jest utrzymywany i wykonywany przez
zarząd organizacji lub programu.
A.1.2 Zawartość
• Zakres Planu Przeg l ądu Korzyści, obej m ujący
wykaz oczekiwanych korzyści podlegających
pomiarowi.
• Osoby odpowiedzialne za osiągnięcie oczekiwa-
nych korzyści.
• Sposoby i terminy pomiaru oczekiwanych korzyści.
• Zasoby niezbędne do przeprowadzenia przeglądu
korzyści.
• Poziomy odniesienia, wzg l ędem których będzie
obliczana poprawa.
• Sposób przeg lądu efektywności produktu końco­
wego projektu.
A.1.3 Pochodzenie
• Uzasadnienie Biznesowe.
• Opis Produktu Końcowego Projektu (a w szcze-
gólności kryteria akceptacji).
• Plan realizacji korzyści dla programu (jeżeli pro-
jekt jest częścią programu).
• Jednostka organizacyjna monitorująca efek-
tywność organizacji (np. centrum doskona lości),
j eże l i istnieje.
A.1.4 Format i sposób przedstawienia
Plan Przeglądu Korzyści może przybierać szereg for-
matów, wlączając w to:
• Dokument, arkusz kalkulacyjny lub slajdy pre-
zentacji
• Wpis do narzędzia używanego do zarządzania
projektem.
Dodatek A: Zarysy Opisów Produktów I 251
A.1 .5 Kryteria jakości
• Plan obejmuje wszystkie korzyści wymienione
w Uzasadnieniu Biznesowym.
• Korzyści są mierzalne, a poziomy odniesienia
zostały zarej estrowane.
• Określ on o terminy odpowiednie dla pomiaru
korzyści, w raz z uzasadnieniem tych terminów.
• Wskazano umiej ętności lub osoby, które będą
potrzebne do wykonania pomiarów.
• Naklady pracy i koszty przeprowadzenia przeglą­
dów korzyści są realistyczne w porównaniu do
wartości przewidywanych korzyści.
• Rozważono, czy przewidywane negatywne
skutki powinny być mierzone i pod l egać prze-
glądowi.
A.2 UZASADNIENIE BIZNESOWE
A .2.1 Przeznaczenie
Uzasadnienie Biznesowe służy do udokumentowa-
nia zasadności podjęcia projektu na podstawie sza -
cunkowych kosztów (opracowania, wdrożenia oraz
zwiększonych kosztów działalności bieżącej i utrzy-
mania), w porównaniu do oczekiwanych korzyści
i po uwzględnieniu ewentualnych ryzyk związanych
z projektem.
Zarys Uzasadnienia Biznesowego jest opracowywany
w procesie Przygotowanie Projekt u i jest d oprecy-
zowywany w procesie Inicjowanie Projektu. Proces
Za rządzan i e Strategiczne Projekt em obej muje
zatwierdzenie i potwierdzanie Uzasadnienia Bizne-
sowego.
Uzasadnienie Biznesowe jest wykorzystywane
w procesie Sterowanie Etapem podczas oceny
wplywów zagadnień i ryzyk. Jest ono poddawane
przeglądowi i aktualizacji na końcu każdego etapu
zarządczego w procesie Zarządza ni e Końcem Etapu
o raz na końcu projektu w procesie Zamykanie Pro-
jektu.
A.2.2 Zawartość
• Podsumowanie Uwypukla najważniejsze punk-
ty Uzasadnienia Biznesowego, które powinny
obejmować istotne korzyści oraz zwrot z inwe-
stycji (ang. ROI - Return on lnvestment).
• Pow ody podjęcia projekt u Określa powody pod-
jęcia projektu i wyjaśnia sposób, w który projekt
u możliwi realizację strategii i celów organizacji.
252 I Dodatek A: Zarysy Opisów Produktów
• Możliwe rozwiązani a biznesowe Analiza
i uzasadnione rekomendacje dotyczące pod-
stawowych rozwiązań biznesowych: nie robić
nic, ograniczyć się do minimum, czy zrobić coś
ponad minimum.
• Oczekiw ane korzyści Korzyści, które przyniesie
projekt. wyrażone w kategori ach mierzalnych,
w porównaniu do sytuacji, która istnieje przed
realizacją projektu. Korzyści mogą być zarówno
jakościowe, jak i i lościowe. Powinny wspierać
ko rzyści organizacji lub programu. Należy usta-
lić granice tolerancji dla każdej korzyści oraz
dla korzyści ogólem. Na l eży określić wymagania
związane z osiąganiem korzyści.
• Przewidywane niepożądane skutki Rezultaty
postrzegane j ako niekorzystne przez jednego
lub więcej interesariuszy. Niepożą d ane skutki
są faktycznym i konsekwencjami podejmowa-
nych działan i a. W przeciwieństwie do zagroże­
nia, które z definicji zawiera jakąś niepewność
dotyczącą jego ewentualnego zmaterializowa-
nia. Na przyklad decyzja o połączen i u dwóch
elementów danej organizacji w nową j ednost-
kę może przyn i eść korzyści (np. w postaci lep-
szej wspólpracy), generować koszty (np. koszty
powiększenia jednej z tych dwóch jednostek)
oraz spowodować negatywne skutki (np. spa-
dek produktywności w t rakcie lączenia firm).
Niepożądane skutki n ależy wycen i ć i uwzg l ęd­
nić w ocenie inwestycji.
• Terminy Terminy, w których projekt będzie rea li-
zowany (wyciąg z Planu Projektu) oraz okres,
w którym osiągane będą korzyści. Informacje te
są n astępnie wykorzystywane przy podejmowa-
niu decyzji w sprawie terminów podczas sporzą­
dzania planów (Plan Projektu, Plan Etapu i Plan
Przeglądu Korzyści).
• Koszty Podsumowanie kosztów projektu
(wyciąg z Planu Projektu), przyszlych kosztów
dzialalności operacyjnej i utrzymania produktów
projektu oraz sposobów ich finansowan ia.
• Ocena inwestycji Porównanie lącznych korzy-
ści i negatywnych skutków z kosztami projektu
(wyciąg z Planu Projektu) oraz przewidywany-
mi zwiększonymi kosztami dz i ałalności i utrzy-
mania. Do analizy możn a wykorzystywać takie
techniki, jak: rachunek przeplywów pien i ęż­
nych, zwrot z inwestycji (ang. ROI - Return on
lnvestment), wartość bieżąca netto (ang. NPV
- Net Present Va/ue), wewnętrzna stopa zwro-
tu (ang. /RR - Interna/ Rate of Return) i okres
zwrotu (ang. PP - Payback Period) . Celem j est
umożliwien ie określenia wartości projektu jako
inwestycji. Ocena inwestycji powinna uwzględ­
niać sposób finansowania projektu.
• Główne ryzyka Podsumowanie glównych ryzyk
(zagrożeń i szans) związa nych z projektem, w raz
z ich prawdopodobnymi skutkami oraz planami
na wypadek ich zmaterializowania.
A.2.3 Pochodzenie
• Zlecenie przygotowania projektu i Założenia
Projektu - powody.
• Plan Proj ektu - koszty i terminy.
• Glówny Użytkownik/Glówni Użytkownicy - ocze-
kiwane korzyści.
• Przewodniczący - wartość uzyskiwana za ponie-
sione koszty.
• Rejestr Ryzyk.
• Rejestr Zagadnień.
A.2.4 Format i sposób przedstawienia
Uzasadnienie Biznesowe może przybierać szereg
formatów, włączając w to:
• dokument, arkusz kalkulacyjny lub slajdy pre-
zentacji;
• wpis do narzędzia używanego do zarządzania
projektem.
A.2.5 Kryteria jakości
• Powody podjęci a projektu muszą być zgodne ze
strategią firmy lub strategią programu.
• Plan Projektu i Uzasadnienie Biznesowe muszą
być spójne.
• Korzyści powinny być wyraźnie określ one i uza-
sadnione.
• Sposób realizacji korzyści powinien być jasno
określony.
• Powinno być j ednoznacznie określone, co będzie
stanowi ć pozytywny rezultat.
• Powinno być j ednoznacznie określ one, jakie jest
preferowane rozwiązan i e biznesowe i dlaczego.
• Jeżeli wymagane jest zaopatrzenie ze źródeł
zewnętrznych, powinno być jasno określone,
jakie jest pref erowane źródło zaopatrzenia i dla-
czego.
• Sposób uzyskania niezbęd nych środków fina nso-
wych powinien być jednoznacznie określony.
• Uzasadnienie Biznesowe zawiera zarówno kry-
teria finansowe, jak i niefinansowe.

• Uzasadnienie Biznesowe obejmuje koszty i ryzy-
ka związa n e z projektem, a tak że koszty i ryzyka
eksploatacj i oraz utrzymania.
• Uzasadnienie Biznesowe j est zgodne ze standar-
dami rachunkowości obowi ązującym i w organi-
zacji, np. analiza progu rentowności (ang. break-
even analysis) i zasady księgowania przeplywów
pien i ężnych (ang. cash-flow conventions).
• Glówne ryzyka związane z projektem są jedno-
znacznie określone, wraz z ewentualnymi propo-
zycjami reakcji na te ryzyka.
A-3 RAPORT Z PUNKTU KONTROLNEGO
A.3.1 Przeznaczenie
Raport z Punktu Kontrolnego jest wykorzystywany
do informowania o stanie realizacji Grupy Zadań
z częstot liwością określoną w danej Grupie Za dań.
A.3.2 Zawartość
• Data opracowania Data punktu kontrolnego.
• Okres sprawozdawczy Okres objęty Raportem
z Punktu Kontrolnego.
• Wykonanie wcześniej zleconych czynności
Czynności zapisane w poprzednich raportach, na
przykład wykonane pozycje z listy czynności do
wykonania lub zagadnienia pozostające do roz-
wi ązania.
• Bieżący okres sprawozdawczy:
• Produkty realizowane przez zespól w okresie
sprawozdawczym.
• Produkty ukończone przez zespól w okresie
sprawozdawczym.
• Działania związane z jakością, wykonane
w okresie sprawozdawczym.
• Uzyskane doświadczenia.
• Następny okres sprawozdawczy:
• Produkty zaplanowane do realizacji przez
zespól w następnym okresie sprawozdawczym.
• Produkty, które wedlug planu zespól ma
ukończyć w następnym okresie
sprawozdawczym.
• Dzia łan ia związane z jakością, zap lanowane
na następny okres sprawozdawczy.
• Stan tolerancji Grupy Zadań Postępy realizacji
Grupy Zadań w odniesieniu do tolerancji
(np. dane faktyczne i prognozy dotyczące kosz-
tów/czasu/zakresu).
Dodatek A· Zarysy Opisów Produktów I 253
• Zagadnienia i ryzyka Aktualizacja zagadnień
i ryzyk związanych z Grupą Zadań.
A.3.3 Pochodzenie
• Grupa Zadań.
• Plan Zespolu i dane faktyczne.
• Poprzedni Raport z Punktu Kontrolnego.
A.3.4 Format i sposób przedstawienia
Raport z Punktu Kontrolnego może przybierać sze-
reg formatów, włączając w to:
• ustny raport przekazany Kierownikowi Projektu
(osobiście łub telefonicznie);
• prezentacja w ramach przeglądu postępów (spo-
tkanie lub telekonferencja);
• dokument łub mail przekazany Kierownikowi
Projektu;
• wpis do narzędzia u żywa n ego do zarządzania
projektem.
A.3.5 Kryteria jakości
• Sporządzany z częstotliwością wymaganą przez
Kierownika Projektu.
• Poziom i częstotliwość oceny postępów są odpo-
wiednie dla danego etapu i/lub Grupy Zadań.
• Informacje są terminowe, przydatne, obiektywne
i dokładne.
• l<ażdy produkt w Grupie Zada ń zaplanowany na
dany okres jest ujęty w raporcie.
• Obejmuje a ktua l izację nierozwiązanych zagad -
n i eń z poprzedniego raportu.
A.4 STRATEGIA ZARZĄDZANIA
KOMUNIKACJĄ
A.4.1 Przeznaczenie
Strategia Zarządzania Komunikacją zawiera opis
środków oraz częstotl iwości komunikacji pom i ędzy
stronami wewnętrznymi i zewnętrznymi projektu.
Ułatwia kontakt z interesariuszami przez ustanowie-
nie kontrolowanego i dwukierunkowego przeplywu
informacji.
A.4.2 Zawartość
• Wprowadzenie Określa przeznaczenie, cele
i zakres oraz wskazuje, kto jest odpowiedzialny
za strategię.
• Procedura komunikacji Opis (lub odniesienie
do) wszelkich metod komunikacji, które będ ą
254 I Dodatek A: Zarysy Opisów Produktów
wykorzystane. Każda niezgodność ze standar-
dami zarządzania organizacją lub programem
powinna być uwypuklona, wraz z podaniem uza-
sadnienia tej n i ezgodności.
• Narzędzia i techniki Odnosi si ę do wszelkich
narzędzi komunikacji, które będą wykorzysta-
ne oraz preferowanych technik, które mogą być
zastosowane, dla każdego kroku procesu komu-
nikacji.
• Wymagane zapisy Określa jakie zapisy komu-
nikacji będą wymagane i gdzie będą przechowy-
wane (na przyk ład rejestrowan ie korespondencji
zewnętrznej).
• Raportowanie Określ a jakie sprawozdania doty-
czące procesu komunikacji mają być sporządzane,
wraz z ich przeznaczeniem, terminami i odbiorca-
mi (na przykład wskaźniki efektywności) .
• Terminy działań związanych z komunikacją
Określa kiedy mają być podjęte forma lne dzia-
łania związane z komun i kacją (na przykład na
końcu etapu), łącznie z audytami efektywności
metod komunikacji.
• Role i ich obowiązki Określa, kto będzie
odpowiedzialny za poszczególne aspekty pro-
cesu komunikacji, łącznie z rolami związanymi
z zarządzaniem organizacją lub programem,
które będą zaangażowane w komunikację.
• Analiza interesariuszy:
• Identyfikacja zainteresowanych stron
(może obejmować personel zajmujący si ę
księgowością, forum użytkowników, audyt
wewnętrzny, nadzór jakości na poziomie
organizacji lub programu, konkurentów itp.).
• B i eżące re lacje.
• Docelowe relacje.
• Punkty styku.
• Główne komunikaty.
• Potrzeby informacyjne każdej z zainteresowa-
nych stron:
• Informacje wymagane od projektu.
• Informacje n i ezbędne dla proj ektu.
• Dostawca i odbiorca informacj i.
• Częstotl i wość komunikowania.
• Środ ki komunikacji.
• Format komunikatów.
A.4.3 Pochodzenie
• Polityka komunikacji f irmy (np. zasady ujawnia-
nia informacji przez spółki publiczne notowane
na gie łd zie).
• Strategia zarządzania informacją dla programu.
• Inne elementy Dokumentacj i Inicjowania
Projektu (w szczegól ności struktura zespołu
zarządzan i a projektem, Strategia Zarządzania
Ryzykiem, Strategia Zarządzania Jakości ą oraz
Strategia Zarządzan i a Konfiguracją).
• Ukierunkowane warsztaty i/lub nieformalne dys-
kusje z interesariuszami.
• Analiza interesariuszy.
A.4.4 Format i sposób przedstawienia
Strategia Zarządzania Komunikacją może przybi erać
szereg formatów, włączając w to:
• osobny produkt lub sekcję Dokumentacji
Inicjowania Projektu;
• dokument, arkusz kalkulacyjny lub mapę myśli;
• wpis do narzędzia używanego do zarządzania
projektem.
A.4.5 Kryteria jakości
• Zidentyfikowano wszystkich interesariuszy
i skonsultowano się z nimi w sprawie ich wymo-
gów w zakresie komunikacji.
• Wszyscy interesariusze wyrazili zgodę na zawar-
tość, częstotl i wość i metodę komunikacji.
• Rozważono wspólny standard komunikacji.
• Nakłady czasu, pracy i zasobów potrzebne do
prowadzenia określon ej komunikacji, zostały
uwzg l ędnion e w Planach Etapów.
• Formalizm i częstotl iwość komunikacji są właści ­
we dla znaczenia i złożoności projektu.
• W przypadku projektów będących częścią pro-
gramu, linie komunikacji i struktura rapor-
towania pom i ędzy projektem i programem
zostały wyjaśnione w Strategii Zarządzan i a
Komunikacją.
• Strategia Zarządzania Komunikacją uwzg l ędn i a
środki komunikacji f irmy tam, gdzie jest to wła­
ściwe (np. wykorzystanie departamentu marke-
tingu do dystrybucji biuletynów informacyjnych
projektu).
A.5 ZAPISY OBIEKTU KONFIGURACJI
A.5.1 Przeznaczenie
Udostępn i enie zapisanych informacji, takich jak
historia, status, wersja i wariant każdego obiektu
konfiguracji, oraz szczegółów dotyczących ważnych
powiązań pomiędzy nimi.

Zestaw Zapisów Obiektów Konfiguracji dla projektu
jest często zwany biblioteką konfiguracji.
A.5.2 Zawa rtość
Zawartość Zapisu Obiektu Konfiguracji zostanie każ­
dorazowo określona w Strategii Zarządzania Konfi-
guracj ą projektu.
Listy elementów Zapisów Obiektu Konfiguracji dla
każdego obiektu (pierwsze trzy jednoznacznie iden-
tyfikują obiekt konfiguracji):
• Identyfikator projektu Niepowtarzalny symbol
referencyjny, zwykle numeryczny lub alfanume-
ryczny.
• Identyfikator obiektu Niepowtarzalny symbol
referencyjny, zwykle numeryczny lub alfanume-
ryczny.
• Aktualna wersja Zwykle symbol alfanumeryczny.
• Nazwa obiektu Opis obiektu (w przypadku pro-
duktu powinien być taki sam, jak w strukturze
podziału produktów).
• Data ostatniej zmiany statusu.
• Docelowy właściciel produktu Osoba lub
grupa, która przejmie odpowi edzialność za pro-
dukt po jego przekazaniu.
• Miejsce przechowywania Miejsce, w którym
obiekt jest przechowywany.
• Aktualni posiadacze Ueśl i dotyczy) Osoby aktu-
alnie posiadające produkt.
• Rodzaj obiektu Komponent, produkt, zbiór
produktów - wydanie (patrz sekcja 9.2.2).
• Cechy obiektu Tak, j ak okreś l ono w Strategii
Zarządzania Konfiguracją . Cechy te są wyko-
rzystywane do określenia podzbioru produk-
tów przy sporządzan i u Zestawienia Statusu
Produktów, np. etap zarządczy, w ramach któ-
rego produkt jest tworzony, rodzaj produktu
(np. sprzęt komputerowy/oprogramowanie),
przeznaczenie produktu it p.
• Etap Etap, w którym produkt zostanie wytwo-
rzony.
• Użytkownicy Osoba lub grupa, która będzie
wykorzystywać obiekt.
• Status Tak, jak określ ono w Strategii Zarządza ­
nia Konfiguracją, np. przed realizacją, w trakcie
real izacji, w trakcie przeglądu, zatwierdzony,
przekazany.
• Stadium produktu Ueśl i dotyczy) Zgodnie
z Opisem Produktu, np. maszyna zdemontowa-
na, maszyna przeniesiona, maszyna ponownie
zamontowana (patrz sekcja 7.3.3.2).
Dodatek A: Zarysy Opisów Produktów I 255
• Wariant Ueśl i dotyczy) Na przykład warianty
językowe.
• Wytwórca/producent Osoba lub zespół odpo-
wiedzialny za wytworzenie lub pozyskanie pro-
duktu.
• Data przydzielenia wytwórcy.
• Pochodzenie produktu Na przykład wytworzony
w f irmie lub zakupiony od firmy zewnętrznej.
• Związek z innymi produktami Produkty:
• na które wpłynęłaby zmiana danego
produktu;
• których zmiana wpłynęłaby na dany produkt.
• Powiązania :
• Zagadnienia i ryzyka.
• Dokumentacja określaj ąca wymagania, pro-
jektowanie, budowę, produkcję i weryfikację
obiektu (w szczególności powinien być tam
umieszczony Opis Produktu).
A.5.3 Pochodzenie
• Strategia Zarządzania Konfiguracją.
• Struktura podziału produktów.
• Plan Etapu i Grupa Zadań.
• Rejestr Jakości, Rejestr Zagadnień i Rejestr Ryzyk.
A.5.4 Format i sposób przedst awienia
Zapisy Obiektu Konfiguracji mogą przybierać szereg
formatów, włączając w to:
• dokument, arkusz kalkulacyjny lub bazę danych;
• wpis do narzędz i a używanego do zarządzania
projektem;
• Zapisy Obiektu Konfiguracji mogą być częścią
Bazy Danych Za rządzan i a Konfiguracją dla tych
organizacji, które posi adają własny system zarzą­
dzania konfiguracją stosowany w organizacji lub
programie.
A.5.5 Kryteria jakości
• Zapisy dokładnie od zwierciedlają status pro-
duktów.
• Zapisy są przechowywane razem w bezpiecznym
mleJSCU.
• Numery wersji odpowiadają rzeczywistym pro-
duktom.
• Zapisy Obiekt u Konfiguracji pokazują historię
wersji produktów.
• Istnieje proces, za pomocą którego Zapisy
Obiektu Konfiguracji są definiowane i aktuali-
zowane.
256 I Dodatek A: Zarysy Opisów Produktów
A.6 STRATEGIA ZARZĄDZANIA
KONFI GURACJĄ
A.6.1 Przeznaczenie
Strategia Zarządzania Konfiguracją jest wykorzysty-
wana do określenia, w jaki sposób i przez kogo pro-
dukty projektu będą kontrolowane i chronione.
Udziela odpowiedzi na następujące pytania:
• W j aki sposób i gdzie będą przechowywane pro-
dukty projektu?
• Jakie mechanizmy bezpieczeństwa skladowania
i odzyskiwania będą zastosowane?
• W jaki sposób będą identyfikowane produkty
oraz różne ich wersje i warianty?
• W jaki sposób będą kontrolowane zmiany pro-
duktów?
• Kto ponosi odpowiedzialność za zarządzanie
konfiguracją?
A.6.2 Zawartość
• Wprowadzenie Określenie przeznaczenia,
celów, zakresu oraz osoby odpowiedzialnej za
strategię.
• Procedura zarządzania konfiguracj ą Opis (lub
odniesienie do) procedury zarządzania konfigu-
racją, która ma być zastosowana. Każda niezgod-
ność ze standardami zarządzania orga nizacją lub
programem powinna być uwypuklona z poda-
niem uzasadnienia tej niezgodności. Procedura
powinna obejmować dzialania takie, jak: plano-
wanie, identyfikowani e, sterowanie (wraz z pro-
cedurami dotyczącymi przechowywania/odzyski-
wania, ochrony, przekazywania produktów itd.),
rejestrowanie statusu, weryfikowanie i audyt.
• Procedura obsługi zagadnień i sterowania
zmianami Opis (lub odniesienie do) procedu·
ry obslugi zagadnień i sterowania zmianami,
które mają być zastosowane. Każda rozbież­
ność w stosunku do standardów fi rmowych lub
zarzą dzania programem powinna być uwypu-
klona z podaniem uzasadnienia tej rozbieżności.
Procedura powinna obejmować dzialania takie,
jak: wychwytywańie, analizowanie, proponowa-
nie dzialań, podejmowanie decyzji i wdrażanie.
• Narzędzia i techniki Odniesienie do wszelkich
systemów zarządzania konfiguracją lub narzędzi,
które będą wykorzystane oraz preferowanych
technik, które mogą być zastosowane w każdym
kroku procedury zarządzania konfiguracją.
• Wymagane zapisy Określenie zawartości i for-
matu Rejestru Zagadnień i Zapisów Obiektu
Konfiguracji.
• Raportowanie Określenie zawartości i formatu
raportów (Raport o Zagadnieniu, Zestawienie
Statusu Produktów), które mają być sporządza­
ne, z podaniem ich przeznaczenia, terminów
i odbiorców. Powinno to również obejmować
przegląd efektywności procedur.
• Terminy działa ń związanych z zarządzaniem
konfi guracją i sterowaniem zagadnieniami oraz
zmianami Określenie, kiedy mają być podjęte
formalne działania, na przykład audyty
konfiguracji.
• Role i ich obowiązki Określenie, kto będzie
odpowiedzialny za poszczególne aspekty proce-
dur, lączn i e z rolam i zwi ązanymi z za rządzaniem
o rga nizacj ą lub programem, zaangażowanym i
w zarządzanie konfiguracją produktów projek-
tu. Określenie, czy zostanie powolana Obsluga
Zmian i/lub ustanowiony budżet zmian.
• Skala ocen priorytetu i wagi Sluży do ustalania
priorytetu wniosków o wprowadzenie zmiany
i odstępstw oraz do określania, na jakim pozio-
mie zarządza n ia mogą być podejmowane decy-
zje w sprawie zagadnień określonej wagi.
A.6.3 Pochodzenie
• Oczekiwania jakościowe klienta.
• System zarządzania konfiguracją obowiązujący
w organizacji (np. wszelkie oprogramowanie do
zarządzania konfiguracją, użytkowane lub usta-
nowione przez u żytkownika).
• Strategia Zarządzania Jakością dla programu
oraz strategia zarządzania informacjami (jeżeli
dotyczy).
• System za rządzania jakością u użytkownika.
• System zarządzania jakością u dostawcy.
• Określone wymagania, wynikające z potrzeb
produktu(-ów) i warunków projektu.
• Struktura zespołu zarządza nia projektem
(ze wskazaniem odpowiedzialności za zarządza­
nie konfiguracją).
• Ukierunkowane warsztaty i/lub nieformalne dys-
kusje.
A.6.4 Format i sposób przedstawienia
Strategia Zarządza n i a Konfi guracją może przybi erać
szereg formatów, włączając w to:

• osobny dokument lub fragment Dokumentacji
Inicjowania Projektu;
• wpis do narzędzia używanego do zarządzan i a
projektem.
A.6.5 Kryteria jakości
• Obowiązki są jasno określone i zrozumiałe
zarówno dla u żytkownika, jak i dla dostawcy.
• Zdef iniowany jest glówny identyfikator dla pro-
duktu(-ów) proj ektu.
• Metody i uwarunkowania kontroli wersji są
j asne, zrozum i ałe i jednoznaczne.
• Strategia zapewnia Kierownikowi Projektu
wszystkie wymagane informacj e o produktach.
• Uwzględniono strateg i ę organizacji lub progra-
mu dotyczącą za rządzania konfiguracją .
• System wyszukiwania informacji będzie w stanie
dosta rczać wszystkich wymaganych informacj i
w sposób d okładny, terminowy i użyteczny.
• Dokumentacja projektu zapewnia informacj e
n iezbędne do spełnien i a wymagań audytu.
• Dokumentacja proj ektu zapewnia zapisy histo-
ryczne potrzebne dla poparcia zebranych
doświadczeń .
• Wybrana Strategia Zarządza n ia Konfi guracj ą
j est odpowiednia dla projektu o danej wie lkości
i charakt erze.
• Zapewniono zasoby do zastosowania wybranej
metody za rządzan i a konfig uracją.
• Uwzg l ęd n iono wymagania grupy, która będzie
eksploatowala produkt (lub podobnej grupy,
której produkt proj ektu zostanie przekazany).
A.7 DZIENNIK PROJEKTU
A. 7 .1 Przeznaczenie
Dziennik Projektu jest wykorzystywany do zapi-
sywania nief ormalnych zagad n ień, wymaganych
działań lub istotnych wyda rzeń, których nie
u wzg l ęd n iaj ą inne rej estry lub dzienniki PRINCE2.
Sl u ży Ki erownikowi Projektu jako kronika, termi-
narz lub pam i ętn ik projektu.
Może być również wykorzystywany j ako repozyto-
rium zagadnień i ryzyk w procesie Przygotowanie Pro-
jektu, gdy inne rejestry nie zostaly jeszcze utworzone.
W proj ekcie może istn i eć więcej n iż jeden dziennik,
ponieważ Kierownicy Zespołów mogą posiadać
dzienniki dla swoich Grup Zada ń, od rębne od Dzien-
nika Projektu.
Dodatek A: Zarysy Opisów Produktów I 257
A.7.2 Zawartość
Dziennik Projektu może mieć dowolną formę, ale
zwykle zawiera następujące informacje:
• Data wpisu.
• Problem, działanie, zdarzenie lub komentarz.
• Osoba odpowiedzialna.
• Wyznaczony termin.
• Rezultaty.
A.7.3 Pochodzenie
Wpisy są dokonywane, kiedy Kierownik Projektu
lub Kierownik Zespolu uzna to za stosowne w celu
zarejestrowania ja kiegoś zdarzenia. Podstawą do
dokonania wpisów są często przemyślen i a, rozmowy
i obserwacje.
A.7.4 Format i sposób przedstawienia
Dziennik Projektumoże przybierać szereg formatów,
włączając w to:
• dokument lub arkusz kalkulacyjny;
• kalendarz biurowy lub notatnik;
• elektroniczny dziennik/kalendarz/listy zada ń;
• wpis do narzędzia używa nego do za rządzania
proj ektem.
A.7.5 Kryteria jakości
• Wpisy są wystarczająco udokumentowane, aby
były zrozumiałe także po pewnym czasie (krótka
notatka może mieć sens w danej chw ili, ale czy
będzi e zrozumiala za kilka miesięcy?}.
• Data, osoba odpowiedzialna oraz t ermin realiza-
cj i są zawsze w pisywane.
• Rozważono kwestię dostępu do Dziennika
Projektu (np. czy Dziennik Projektu powinien być
dostępny dla wszystkich osób pracujących nad
projektem?).
A .8 RAPORT KOŃ COWY PROJEKTU
A.8.1 Przeznaczenie
Raport Końcowy Projektu jest wykorzystywany przy
zamykaniu projektu do dokonania przeg l ądu, jak
projekt przebiegł w porównaniu z pierwotną wersj ą
Dokumentacji Inicjowania Projektu, na podstawie
której zezwolono na jego rea l izację. Pozwala rów-
nież na:
• przekazanie wszelkich doświadczeń, które można
z pożytkiem zastosować w innych projektach;
258 I Dodatek A: Zarysy Opisów Produktów
• przekazanie szczegółowych informacji, dotyczą­
cych niezakończonych prac, utrzymujących się
ryzyk lub potencj alnych modyfikacji produktu,
grupie odpowiedzialnej za przyszłe wsparcie pro-
duktów projektu w okresie ich użytkowa ni a.
A.8.2 Zawartość
• Sprawozdanie Kierownika Projektu
Podsumowanie wyników projektu.
• Przegląd Uzasa dnienia Biznesowego
Podsumowanie zasadności Uzasadnienia
Biznesowego projektu:
• Korzyści uzyskane do daty opracowania
raportu.
• Pozostałe korzyści do uzyskania (po zakoń­
czeniu projektu).
• Spodziew ane ko rzyści netto.
• Odchylenia od zatwierdzonego Uzasadnienia
Biznesowego.
• Przegląd realizacji celów projektu Przegląd
przebiegu projektu w porównaniu z zaplano-
wanymi celami i tolerancjami dla czasu, kosz-
tów, jakości, zakresu, korzyści i ryzyka. Przegląd
skuteczności wszystkich strategii projektu
i mechanizmów sterowania.
• Przegl ąd efektywności zespołu proj ektow ego
W szczególności wyrażenie uznania dla dobrych
wyników.
• Przeg l ąd produktów:
• Zapisy dotyczące jakości Lista zaplanowa-
nych i zakończonych działań dotyczących
jakości.
• Zapisy dotyc.zące zatwi erdzeń Lista produk-
tów i ich wymaganych zatwierdzeń.
• Odstępstwa Lista wszelkich brakujących pro-
duktów lub produktów, które nie spełniają
pierwotnych wymagań oraz potwierdzenie
wszelkich ustępstw, na które wyrażono zgodę.
• Przekazanie produktu projektu
Potwierdzenie przez klienta (w fo rmie zapi-
sów akceptacj i}, że jednostki funkcjona lne
eksploatacji i utrzymania są gotowe na przy-
jęcie produktu projektu.
• Podsumowanie zaleceń działań następczych
Wniosek do Komitetu Sterującego o wska-
zanie, kto powinien otrzymać do wykonania
poszczególne rekomendowane działania.
Rekomendowane działania są związane z nie-
zakończonym i pracami, n i ezamkniętymi zagad-
nieniami czy ryzykami oraz innymi czynnościa-
mi niezbędnymi do przekazania produktów do
kolejnej fazy ich cyklu życia.
• Raport Doświadczeń (patrz A.1 S) Przegląd
tego, co przeb i egło dobrze, co przebieg ło źle
oraz wszelkich rekomendacji do rozważenia
przez zarząd organizacji lub programu (a j eżeli
projekt zestal zamkn i ęty przedwcześnie, wtedy
na l eży również wyj aśnić tego przyczyny).
A.8.3 Pochodzenie
• Dokumentacja Inicjowania Projektu.
• Uzasadnienie Biznesowe.
• Plan Projektu.
• Plan Przeglądu Korzyści.
• Rej estr Zagadnień, Rejestr Jakości i Rejestr Ryzyk.
• Raport Doświ adczeń.
• Raporty Końcowe Et apów (oraz Raporty
Nadzwyczajne, j eś l i wystą pily).
A.8.4 Format i sposób przedstawienia
Raport Końcowy Projektu może przybierać szereg
formatów, wlączając w to:
• prezentację dla Komitetu Sterującego (na spo-
tkaniu lub telekonferencji);
• dokument lub mail przekazany Komitetowi
Sterującemu;
• wpis do narzędzia u żywa n ego do zarządzania
projektem.
A.8.5 Kryteria jakości
• Opisano wszelkie odbiegające od normy sytu-
acje, wraz z ich wpływem.
• Wszystkie zagadnienia zostały zamknięte lub są
przedmiotem zaleceń działań następczych.
• Do zalecenia(-eń) działań następczych dołączo­
no wszelkie dostępne użyteczne dokumenty lub
dowody/świadectwa.
• Osoby pe lniące funkcj ę Nadzoru Proj ektu zga-
dzają si ę z treścią raportu.
A.9 RAPORT KOŃ COWY ETAPU
A.9.1 Przeznaczenie
Raport Końcowy Etapu służy do przedstawienia
podsumowania postępów do dnia sporządzenia
raportu, całościowej sytuacji projektu oraz infor-
macji wystarczających, by wystąpić do Komitetu
Sterującego o podjęcie decyzj i w sprawie dalszej
real izacji projektu.

Komitet Sterujący wykorzystuje informacje zawarte
w Raporcie Końcowym Etapu, w połączeniu z Pla-
nem następnego Etapu, do podjęcia decyzji, jakie
dzia łania należy przedsięwziąć w stosunku do pro-
jektu, na przykład: czy zezwolić na realizację następ·
nego etapu, zmienić zakres projektu, czy wstrzymać
real i zację projektu.
A.9.2 Zawartość
• Sprawozdanie Kierownika Projektu
Podsumowanie wyników etapu.
• Przeg ląd Uzasadnienia Biznesowego
Podsumowanie zasadności Uzasadnienia
Biznesowego projektu:
• Ko rzyści uzyskane do daty raportu.
• Korzyści pozostałe do uzyskania (na pozosta·
lych etapach i po zakończen i u projektu).
• Spodziewane korzyści netto.
• Odchylenia od zatwierdzonego Uzasadnienia
Biznesowego.
• Zagregowana ekspozycja na ryzyko.
• Przegląd real izacji celów projektu Przegląd
przebiegu projekt u do daty opracowania raportu,
w porównaniu z zaplanowanymi celami i tole-
rancjami w kategoriach czasu, kosztów, jakości,
zakresu, korzyści i ryzyka. Przegląd skuteczności
wszystkich strategii projektu i mechanizmów
sterowania.
• Przegląd realizacji celów et apu Przeg l ąd
przebiegu konkretnego etapu w porównaniu
z zaplanowanymi celami i tolerancjami w kate-
goriach czasu, kosztów, jakości, zakresu, korzyści
i ryzyka.
• Przegląd efektywności zespołu projektowego
W szczególności wyrażen ie uznania dla dobrych
wyników.
• Przegląd produktów:
• Zapisy dotyczące jakości Lista działań doty-
czących jakości, zaplanowanych i zakończo­
nych w ramach danego etapu.
• Zapisy dotyczące zatwierdzeń Lista produk·
tów planowanych do ukończenia w ramach
danego etapu oraz ich wymagane zatwier-
dzenia.
• Odstępstwa Lista wszelkich brakujących
produktów lub produktów, które nie speł­
niają pierwotnych wymogów oraz potwier-
dzenie wszelkich ustępstw, na które wyrażo­
no zgodę.
Dodatek A: Zarysy Opisów Produktów I 259
• Przekazanie stopniowe (przyrostowe) (jeśli
dotyczy) Potwierdzenie przez klienta, że jed-
nostki fun kcjonalne eksploatacji i utrzymania
są gotowe na przyjęcie zestawu produktów
wchodzących w skład danego wydania.
• Podsumowanie zaleceń działań następ­
czych (jeś l i dotyczy) Wniosek do Komitetu
Steruj ącego o wskazanie, kto powinien
otrzymać do wykonania poszczególne reko·
mendowane dz i ałan i a. Rekomendowane
działania są związane z n i ezakończonymi
pracami, n i ezamkniętym i zagadnieniami czy
ryzykami oraz innymi czynnościami niezbęd­
nymi do przekazania produktów do kolejnej
fazy ich cyklu życia.
• Raport Doświadczeń (jeśli opracowano) (patrz
A.15) Przegląd tego, co przebieg ło dobrze, co
przebi egło źle oraz wszelkich rekomendacji do roz-
ważenia przez zarząd organizacji lub programu.
• Zagadnienia i ryzyka Podsumowanie aktualne-
go zestawu zagadnień i ryzyk wpływających na
projekt.
• Prognoza Prognoza Ki erownika Projektu dla
proj ektu i następnego etapu, w porównaniu
z zaplanowanymi celami i tolerancjami dla czasu,
kosztów, jakości, zakresu, korzyści i ryzyka.
Jeżel i Raport Końcowy
Etapu jest sporządzany na
zakończenie etapu inicjowania projektu, nie wszyst·
kie z powyższych pozycji dotyczących zawartości
mogą być właściwe czy n i ezbędne.
A.9.3 Pochodzenie
• Plan aktualnego Etapu i dane faktyczne.
• Plan Proj ektu.
• Plan Przeg l ądu Korzyści.
• Rejestr Ryzyk, Rejestr Ja kości i Rejestr Zagadnień .
• Raport Nadzwyczajny (jeśl i ma zastosowanie).
• Raport Doświadczeń .
• Zakończone/opóźn i one Grupy Zadań.
• Zaktualizowane Uzasadnienie Biznesowe.
A.9.4 Format i sposób prezentacji
Raport Końcowy Etapu może przybierać szereg for-
matów, włączając w to:
• prezentację dla Komitetu Steruj ącego (na spo-
tkaniu lub telekonferencji);
• dokument lub mail przekazany Komitetowi
Sterującemu;
• wpis do narzędzia zarządzania projektem.
260 I Dodatek A: Zarysy Opisów Produktów
A .9.5 Kryteria jakości
• Raport dokładnie odzwierciedla wykonanie
etapu w porównaniu z planem.
• Opisano wszelkie odbiegające od normy sytu-
acj e, wraz z ich wpływem.
• Osoby pelniące funkcję Nadzoru Projektu zga-
dzają się z treścią raportu.
A.10 RAPORT NADZWYCZAJNY
A .10.1 Przeznaczenie
Raport Nadzwyczajny jest sporządzany, gdy przewi-
duje się, że Plan Etapu lub Plan Projektu wykroczy
poza ustalone dla niego granice tolerancji. Raport
jest sporządza ny przez Kierownika Projektu w celu
poinformowania Komitetu Sterującego o zaistnialej
sytuacji oraz w celu zaproponowania opcji i reko-
mendacji dotyczących dalszego postępowania.
A .10.2 Zawartość
• Opis sytuacji nadzwyczajnej Ogólne przedsta·
wienie sytuacji nadzwyczajnej objętej raportem.
• Przyczyna wystąpienia Opis przyczyny odchyle-
nia od aktualnego planu.
• Skutki odchylenia Następstwa odchylenia
w przypadku, gdy nie zostaną podj ęte żadne
dzialania:
• dla projektu;
• dla organizacji lub programu.
• Możliwe reakcje Przedstawienie możl iwych
opcji postępowania z odchyleniem i jaki bylby
wplyw każdej z tych opcji na Uzasadnienie
Biznesowe, ryzyka i tolerancje.
• Rekomendacja Rekomendacja jednej spośród
możliwych opcji i uzasadnienie dokonanego
wyboru.
• Doświadczenia Wykaz doświadczeń wynikają­
cych z zaistnialej sytuacji nadzwyczajnej dla tego
projektu lub przyszlych projektów.
A.10.3 Pochodzenie
• Aktualny plan i dane faktyczne.
• Rejestr Zagadnień, Rejestr Ryzyk i Rejestr Jakości.
• Raporty Okresowe (dla odchyleń na poziomie
etapu/projektu) lub Raporty z Punktu Kontrolne-
go (dla odchyleń na poziomie zespolu).
• Informacja od Komitetu Sterującego w sprawie
wydarzenia zewnętrznego wpływającego na
projekt.
A.10.4 Format i sposób prezentacji
Raport Nadzwyczajny może przybierać szereg for-
matów, wlączając w to:
• zagadnienie zgloszone na protokołowanym
przeg l ądzie postępów projektu (na spotkaniu
lub telekonferencji);
• dokument lub mail przekazany na następny,
wyższy szczebel zarządzania;
• wpis do narzędzia zarządzania projektem.
w przypadku odchyleń wymagających szybkiej
reakcji, zaleca się, aby Raport Nadzwyczajny byl
w pierwszej kolejności przekazany w formie ustnej,
a następnie w uzgodnionym formacie.
A.10.5 Kryteria jakości
• B i eżący plan dokladnie pokazuje stan wykonania
harmonogramu i budżetu.
• Podano przyczynę(-ny) odchylenia, odchylenie
poddano dokladnej analizie, a wszelkie j ego
wplywy zostaly ocenione i opisane w sposób
wyczerpują cy.
• Rozważono konsekwencje dla Uzasadnienia
Biznesowego i określono wpływ na cały Plan
Projektu.
• Przeanalizowano opcje postępowania (wraz ze
związanymi z nimi ryzykami) i przedstawiono
rekom endacje dotyczące najwłaściwszeg o sposo-
bu dalszego postępowania.
• Raport Nadzwyczajny został przekazany w spo-
sób terminowy i należyty.
A.1 1 RAPORT OKRESOWY
A.11.1 Przeznaczenie
Raport Okresowy jest wykorzystywany w celu
dostarczenia Komitetowi Sterującemu (i ewentual-
nie innymi interesariuszom) podsumowania stanu
etapu w określ onych przez nich odstępach czasu.
Komitet Sterujący wykorzystuje raport do monito-
rowania postępów etapu i projektu. Kierownik Pro-
jektu równi eż wykorzystuje go do powiadomienia
Komitetu Sterującego o wszelkich potencjalnych
problemach lub obszarach, w których Komitet Steru-
jący może pomóc.
A.11.2 Zawartość
• Data opracowania Data opracowania raportu.
• Okres sprawozdawczy Okres sprawozdawczy
objęty Raportem Okresowym.

• Sumaryczny opis stanu etapu Ogólne przedsta-
w ienie stanu etapu w danym momencie.
• Bieżący okres sprawozdawczy:
• Grupy Zadań - oczekujące na zatwierdze-
nie, w trakcie rea lizacji oraz zatwierdzone
w okresie sprawozdawczym (jeżel i Grupy
Zadań są wykonywane przez dostawców
zewnętrznych, do informacji tych można
dołączyć zlecenie zakupu i dane fakturowe).
• Produkty wykonane w okresie sprawoz-
dawczym.
• Produkty planowane do wykonania, lecz
nie rozpoczęte lub nie ukończone w okresie
sprawozdawczym (stanowi to sygna ł wcze-
snego ostrzegania o potencjalnym przekro-
czeniu tolerancji czasu).
• Działania korygujące podjęte w okresie
sprawozdawczym.
• Następny okres sprawozdawczy:
• Grupy Zadań - do zatwierdzenia, w trakcie
realizacji oraz do ukończenia w następnym
okresie sprawozdawczym (jeżeli Grupy Zadań
są wykonywane przez dostawców zewn ętrz­
nych, do informacji tych można dołączyć zle-
cenie zakupu i dane fakturowe).
• Produkty planowane do ukończenia
w następnym okresie sprawozdawczym.
• Dzi ałan i a korygujące, które mają być zakoń­
czone w następnym okresie sprawozdawczym.
• Stan tolerancji projektu i etapu Omówienie
przebiegu real izacji projektu i etapu w odniesie-
niu do ich tolerancji (np. dane faktyczne i pro-
gnozy dotyczące kosztów/czasu).
• Wnioski o wprowadzenie zmiany Zgłoszone,
zatwierdzone/odrzucone i oczekujące na roz-
strzygnięcie.
• Główne zagadnienia i ryzyka Podsumowanie
faktycznych lub potencjalnych problemów i ryzyk.
• Raport Doświadczeń (jeśl i dotyczy) (patrz A.15)
Przegląd tego, co przebi egło dobrze, co przebie-
gło źle, oraz wszelkie rekomendacje do rozważe­
nia przez zarząd organizacji lub programu.
A.11 .3 Pochodzenie
• Dokumentacja Inicj owania Projektu.
• Raporty z Punktów Kontrolnych.
• Rejestr Zagadnień, Rejestr Jakości i Rej estr Ryzyk.
• Plan Etapu i dane faktyczne.
• Strategia Zarządzania Komunikacją .
Dodatek A: Zarysy Opisów Produktów I 261
A.11.4 Format i sposób prezentacji
Raport Okresowy może przybierać szereg formatów,
włączając w to:
• prezentację dla Komitetu Sterującego (na spo-
tkaniu lub telekonferencji);
• dokument lub mail przekazany Komitetowi
Sterującemu;
• wpis do narzędzia zarządzan i a projektem.
A.11.5 Kryteria jakości
• Poziom i częstotl i wość raportowan ia o postę­
pach, wymagane przez Komitet Sterujący, są
odpowiednie dla etapu i/lub projektu.
• Kierownik Projektu przekazał Raport Okresowy
z częstotliwością i o zawartości wymaganej przez
Komitet Sterujący.
• Informacje są aktualne, użyteczne, dokładne
i obiektywne.
• Raport uwypukla obszary potencjalnych proble-
mów.
A. 12 REJESTR ZAGADNI EŃ
A.12.1 Przeznaczenie
Celem Rej estru Zagadnień j est rejestrowanie
i utrzymywanie informacji o wszystkich zagad -
nieniach, które są zarządzane formalnie. Rejestr
Zagadn i eń powinien być regularnie przeg l ądany
przez Kierownika Projektu.
A.12.2 Zawartość
Dla każdegowpisu do Rejestru Zagadnień należy
zarej estrować następujące informacje:
• Identyfikator zagadnienia Przypisuje niepowta-
rzalny symbol każdemu zagadnieniu wpisanemu
do Rej estru Zagadnień, zwykle numeryczny lub
alfanumeryczny.
• Typ zagadnienia Określa rodzaj rejestrowanego
zagadnienia, tj.:
• wniosek o wprowadzenie zmiany;
• odstępstwo;
• problem/obawa.
• Data zgłoszenia Data pierwotnego zgłoszen i a
zagadnienia.
• Zgłoszone przez Imię i nazwisko osoby lub
nazwa zespołu, który(-a) zgłosił(a) zagadnienie.
262 I Dodatek A : Zarysy Opisów Produktów
• Autor Raportu o Zagadnieniu Imię i nazwisko
osoby lub nazwa zespołu, który(-a) sporządzi l(a)
Raport o Zagadni eniu.
• Opis zagadnienia Informacja zawierająca opis
zagadnienia, jego przyczyn i wpływu.
• Priorytet Należy podać w kategoriach wybra-
nych dla projektu. Priorytet należy poddać
ponownej ocenie po przeprowadzeniu analizy
wplywu.
• Waga/znaczenie Na l eży podać w kategoriach
skali wybranej dla projektu. Waga wskazuje
poziom zarządzania, na jakim należy podjąć
decyzję w sprawie zagadnienia.
• Status Aktualny status zagadnienia i data
ostatniej aktualizacji.
• Data zamknięcia Data zamknięcia zagadnienia.
A.12.3 Pochodzenie
• Format i zawartość Rejestru Zagadn ień są okre-
ślone w Strategii Zarządzania Konfiguracją.
• Wpisy są dokonywane w Rejestrze Zagadnień
zaraz po zgloszeniu nowego zagadnienia.
• Rejestr Zagadnień jest aktualizowany w miarę
postępu prac nad zagadnieniem. Po rozwi ązan iu
zagadnienia, wpis w Rejestrze Zagadn i eń jest
zamykany.
A.12.4 Format i sposób prezentacji
Rejestr Zagadnień może przybierać szereg forma -
tów, wlączając w to:
• dokument, arkusz kalkulacyjny lub bazę danych;
• odrębny rejestr lub zapis w notatce z przeg l ądu
postępów;
• wpis do narzędzia zarządzan i a projektem;
• część zintegrowanego rejestru projektu, obejmu-
jącego wszystkie ryzyka, dzialania, decyzje, zalo-
żenia, zagadnienia, doświadczenia itp.
A.12.5 Kryteria jakości
• Aktualny status wskazuj e, czy podjęto dzialanie.
• Zagadnienia są jednoznacznie zid entyf ikowane
wraz z informacją, do którego produktu się
odnoszą.
• Proces aktualizacji Rejestru Zagadnień jest zdefi-
niowany.
• Wpisy do Rejestru Zagadnień, które po przeana-
lizowaniu okazują si ę w rzeczywistości ryzykam i,
są przenoszone do Rejestru Ryzyk, z odpowied-
nią adnotacją przy ich wpisach.
• Dostęp do Rejestru Zagadnień jest kontrolowa-
ny i rejestr jest przechowywany w bezpiecznym
miejscu.
A.13 RAPORT O ZAGADNIENIU
A.13.1 Przeznaczenie
Raport o Zagadnieniu zawiera opis, ocenę wplywu
i rekomendacje dotyczące wniosku o wprowadzenie
zmiany, odstępstwa albo problemu/obawy. Jest spo-
rządzany tylko dla tych zagadnień, które muszą być
obsłużone w sposób forma lny.
Ten raport jest pierwotnie sporządzany przy rejestro-
waniu zagadnienia i jest aktualizowany po przeana-
lizowaniu danego zagadnienia i po określen iu pro-
pozycji dotyczących rozwi ązania tego zaga dnienia.
Raport o Zagadnieniu jest następni e modyfikowany
w celu zarejestrowania decyzji w sprawie wybranej
opcji i podlega ostatecznej aktualizacji po zweryfiko-
waniu realizacji tej opcji i zamknięciu zagadnienia.
A.13.2 Zawartość
• Identyfikator zagadnienia Zgodny z Rejestrem
Zagadnień niepowtarzalny numer referencyjny
nadawany każdemu Raportowi o Zagadnieniu.
• Typ zagadnienia Określ a typ rejestrowanego
zagadnienia, tj.:
• wniosek o wprowadzenie zmiany;
• odstępstwo;
• problem/obawa.
• Data zgłoszenia Data pierwotnego zg łoszenia
zagadnienia.
• Zgłoszone przez Imię i nazwisko osoby lub
nazwa zespołu, który(-a) zgłosil(a) zagadnienie.
• Autor Raportu o Zagadnieniu Imię i nazwisko
osoby lub nazwa zespolu, kt6ry(-a) sporządzil(a)
Raport o Zagadnieniu.
• Opis zagadnienia Oświadczen ie zawierające
opis zagadnienia, jego przyczyn i wplywu.
• Analiza wpływu Szczegółowa analiza prawdo-
podobnego wplywu zagadnienia, która może
obejmować np. l istę produktów, na które dane
zagadnienie może mieć wplyw.
• Rekomendacja Opis działań, które w opinii
Kierownika Projektu należy podjąć w celu roz-
wiązan i a za gadnienia (z uzasadnieniem).
• Priorytet Należy podać w kategoriach skali
wybranej dla projektu. Priorytet należy poddać
ponownej ocenie po przeprowadzeniu analizy
wpływu.

• Waga/znaczenie Należy podać w kategoriach
skali wybranej dla projektu. Waga wskazuje
poziom zarządzania, na jakim należy podjąć
decyzję w sprawie zagadnienia.
• Decyzja Podjęta decyzja (zaakceptować, odrzu-
cić, odroczyć, zastosować ustępstwo).
• Zatwierdzone przez Kto podj ąl decyzję.
• Data decyzji Data podjęcia decyzji i osoba,
która podjęła decyzję.
• Data zamknięcia Data, w której zagadnienie
zostało zamknięte.
A.13.3 Pochodzenie
• Format i zawartość Raportu o Zagadnieniu będą
określ one w Strategii Zarządzania Konfi guracją.
• Raport(y) Okresowy(-e), Raport(y) z Punktu
Kontrolnego i Raport(y) Końcowy(-e) Etapu.
• Plan Etapu wraz z faktycznymi danymi i zdarze-
niami.
• Zespoly użytkowni ków i dostawców pracujące
nad projektem.
• Zastosowane mechanizmy sterowania jakością.
• Obserwacje i doświadczenia dotyczące procesów.
• Rejestr Jakości, Rejestr Ryzyk i Dziennik
Doświadczeń.
• Ukończone Grupy Zada ń.
A .13.4 Format i sposób prezentacji
Raport o Zagadnieniu może przybie rać szereg for-
matów, włączając w to:
• dokument, arkusz kalkulacyjny lub bazę danych;
• wpis do narzędzia zarządzania projektem;
• nie wszystkie wpisy do Rejestru Zagadnień będą
wymagać sporządzenia odrębnego Raportu
o Zagadnieniu.
A.13.5 Kryteria jakości
• Zagadnienie jest jasno określone i jednoznaczne.
• Przeprowadzono szczegółową a n al i zę wpływu
zagadnienia.
• Rozważono wszystkie konsekwencje.
• Zagadnienie zostało przeanalizowane pod kątem
wpływu na tolerancje.
• Zagadnienie zostało prawidłowo zarejestrowane
w Rejestrze Zagadnień.
• Decyzje zostały opisane dokładnie i jedno-
. •
znacznie.
Dodatek A: Zarysy Opisów Produktów I 263
A .14 DZIENNIK DOŚW IADCZEŃ
A .14.1 Przeznaczenie
Dziennik Doświadczeń stanowi repozytorium
doświadczeń projektu, które mają zastosowanie
w tym projekcie lub mogą m i eć w przyszlych pro-
j ektach. Niektóre doświadczenia mogą pochodzić
z innych projektów i powinny być zarejestrowane
w Dzienniku Doświadczeń w celu ich wprowadzenia
do strategii i planów projektu. Niektóre doświadcze­
nia (zarówno dobre, jak i złe) mogą pochodzić z reali-
zowanego projektu i w jego ramach mogą być prze-
kazywane innym za pomocą Raportu Doświadczeń.
A.14.2 Zawartość
Dla każdego
wpisu do Dziennika Doświ adczeń nale-
ży zarej estrować następujące informacje:
• Typ doświadczenia Określen i e typu rejestrowa-
nego doświadczenia, w zależności od obszaru,
którego dotyczy:
• Projekt - do zastosowania w danym projekcie.
• Organizacja lub program - do przekazania
zarządowi organizacji łub programu.
• Projekt i organizacja łub program.
• Opis doświadczenia Opis może obejmować:
• zdarzenie;
• skutek (np. pozytywne/negatywne skutki
f inansowe);
• przyczyny/sygna ł u ruchamiaj ący;
• czy byly jak i eś wcześniejsze sygnały ostrzega-
jące?
• rekomendacje;
• czy doświadczenie zostało uprzednio zidentyfi-
kowane jako ryzyko (zagrożenie lub szansa)?
• Data wpisu Data pierwotnej rejestracji
doświadczenia.
• Wpisane przez Imię i nazwisko osoby lub
nazwa zespołu, który zgłosił doświadczenie.
• Priorytet W ramach kategorii wybranych dla
projektu.
A .14.3 Pochodzenie
• Raporty Doświadczeń z innych projektów.
• Zlecenie przygotowania projektu łub Założenia
Projektu.
Dziennik Projektu, Rejestr Zagadnień, Rejestr
Jakości i Rejestr Ryzyk.
264 I Dodatek A Zarysy Opisów Produktów

• Raporty z Punktu Kontrolnego i Raporty A.15 RAPORT DOŚWIADCZE Ń

Okresowe.
• Ukończone Grupy Zadań. A.15. 1 Przeznaczenie
• Plany Etapu z danymi faktycznymi. Raport Doświadczeń jest wykorzystywany do prze-
• Obserwacje i doświ adczen i a dotyczące procesów kazywan ia doświadczeń, które moźna z poźytkiem
projektu. zastosować w innych projektach.

A.14.4 Format i sposób prezentacji Celem raportu jest spowodowanie dzialania, by

pozytywne doświadczenia staly się częścią sposobu
Dziennik Doświadczeń moźe przybierać szereg for- pracy o rganizacji, a organizacja byla zdolna
matów, wlączając w to: uniknąć negatywnych doświadczeń w przyszlych

• dokument, arkusz ka lkulacyjny lub ba zę danych; projektach.

• odrębny dziennik lub zapis sprawy wniesionej Raport Doświadczeń moźe być sporządzony
w notat ce z przeglądu postępów; w dowolnym momencie w trakcie projektu, tj.
• wpis do narzędzia uźywanego do zarządzania niekoniecznie trzeba czekać do końca projektu.
projektem; Raport Doświadczeń zwykle stanowi część Raportu
Końcowego Etapu i Raportu Końcowego Projektu.
• część zintegrowan ego rejestru projektu, obejmu·
Moźe być wskazane (i niezbęd n e) sporządzen i e
jącego wszystkie ryzyka, dzialania, decyzje, zalo-
źenia, zagadnienia, doświadczenia itp. ki lku Raportów Doświadczeń, specyficznych dla kon-
kretn ej organizacji (np. d la uźytkownika, dostawcy,
A.14.5 Kryteria jakości organi zacji lub programu).

• Aktualny status wskazuje, czy podjęto dzialanie.
• Doświ adcze n i a są identyfikowane w sposób jed-
noznaczny, wraz z informacją, do którego pro-
duktu się odnoszą.
• Proces aktualizacji Dziennika Doświadczeń jest
zdefiniowany.
• Dostęp do Dziennika Doświadczeń jest kontrolo-
wany.
• Dziennik Doświadczeń j est przechowywany
w bezpiecznym miejscu.
Dane zawarte w raporcie powinny być wykorzystane
przez grupę odpowi edzia l ną w organizacji za system
zapewnienia jakości, w celu udoskonalenia, zmiany
oraz poprawy standardów. Dane liczbowe o rzeczy-
wistych na kładach pracy, jakich wymagaly produkty,
mogą pomóc poprawić przyszłe oszacowania.
A .1 5.2 Zawartość
• Podsumowanie.
• Zakres raportu (np. etap lub projekt).
• Przegląd tego, co przebiegle dobrze, co prze-
biegle źle oraz rekomendacje do rozwaźenia

Tabela A.1 Przykładowa lista kontrolna produktów

.... Końcowa
o
.... ::J Opis Produktu Pierwsza wersja Przekazano
"' ....
.:.!. .:.!.
·- ::J Nazwa zatwierdzony gotowa
kontrola j akości Zatwierd zony
Oeśli dotyczy)
~"O wykonana
„e
c a. produktu
-"O
Plan wykonanie Plan Wykonanie Plan wykonanie Plan wykonanie Plan wykonanie

„.

121 Plan testów 02/01 02101 07/02 07/02 14/02 21/02 21/02 28/02 nd. nd.
124 Pompa wodna 02101 02101 13/03 13/03 14/06 30/06 14/07

.. .

przez kierownictwo organizacji lub programu.
W szczególności:
• Metoda zarządzania projektem (łącznie
z dostosowaniem metodyki PRINCE2).
• Wszelkie zastosowane metody specjalistyczne.
• Strategie projektu (zarządzani e ryzyk iem,
zarządzan i e jakością, zarządzan i e komunikacją
i zarządzanie konfiguracją).
• Mechanizmy sterowania (oraz efektywność
ich ewentualnego dostosowania).
• Odbiegające od normy zdarzenia powodujące
odchylenia.
• Przegląd użytecznych miar, takich jak:
• Nakład pracy wymagany do stworzenia pro-
duktów.
• Skuteczność Strategii Zarządzan i a J akości ą
przy proj ektowaniu, opracowywaniu
i dostarczaniu produktów odpowiadających
ich przeznaczeniu (np. ile usterek wykryto po
przejściu produktów przez kontrolę jakości).
• Dane statystyczne dotyczące zagadnień i ryzyk.
• W przypadku doświadczeń o istotnym znacze-
niu, przydatne mogą być dodatkowe informacje
dotyczące:
• Zdarzenia.
• Skutku (np. pozytywne/negatywne skutki
f inansowe).
• Przyczyn/sygnału uru cham i aj ącego.
• Czy byly jakieś wcześniejsze sygnaly
ostrzegające?
• Rekomendacji.
• Czy wywolane zdarzenie bylo uprzednio
zidentyfikowane jako ryzyko (zagrożenie lub
szansa)?
A.15.3 Pochodzenie
• Dokumentacja Inicjowania Projektu (dla określe­
nia sytuacji odniesienia).
• Dziennik Doświadczeń (do identyfikacji doświad ­
czeń).
• Rej estr Jakości, Rejestr Zagadnień i Rejestr Ryzyk
(do analizy danych statystycznych).
• Zapisy jakości (do analizy danych statystycznych).
• Strategia Zarządzania Komunikacją (dla sporzą­
dzenia rozdzielnika).
A.15.4 Format i sposób przedstawienia
Raport Doświadczeń może przybierać szereg forma-
tów, wlączając w to:
Dodatek A: Zarysy Opisów Produktów I 265
• ustne sprawozdanie dla Komitetu Sterującego
(może być przekazane osobiście lub telefonicz-
nie);
• prezentację na przeglądz i e postępów (na spo-
tkaniu lub telekonferencji);
• dokument lub mail przekazany Komitetowi
Sterującemu;
• wpis do narzędzia używanego do zarządzania
projektem.
A.15.5 Kryteria jakości
• Przeanalizowano każdy zarządczy mechanizm
sterowania.
• Podano porównanie oszacowań z danymi fak-
tycznymi.
• Przedstawiono dane o skuteczn ości zastosowa-
nych mechanizmów sterowania jakością.
• Osoby peł niące fun kcję Nadzoru Proj ektu zga-
dzają się z treścią raportu.
• Nieprzewidziane ryzyka są poddane przeglądowi
w celu ustalenia, czy można je bylo przewidzieć.
• Dla każdego doświadczenia podano zalecane
dzialania (należy pamiętać, że doświadczenia nie
można uznać za wykorzystane, o ile nie podjęto
odpowiedniego dzialania).
A.16 PLAN
A.16.1 Przeznaczenie
Plan zawiera opis sposobu i terminu osi ągnięcia
celów, poprzez wskazanie glównych produktów,
czynności i zasobów wymaganych dla zrealizowania
zakresu planu. W PRINCE2 występują trzy poziomy
planów: projektu, etapu i zespolu. Plany Zespolu są
opcjonalne i nie muszą mieć takiego samego składu,
co Plan Projektu czy Plan Etapu.
Plan Nadzwyczajny jest opracowywany na tym
samym poziomie, co plan, który zastępuje.
Plan Projektu dostarcza informacj i o p lanowanych
kosztach, wykorzystywanych przy opracowywa-
niu Uzasadnienia Biznesowego, i wskazuje etapy
zarządcze oraz inne glówne punkty kontrolne.
Jest wykorzystywany przez Komitet Sterujący jako
obiekt odniesienia do monitorowania względem
niego postępów projektu.
Plany Etapu obejmują produkty, zasoby, czynności
i mechanizmy sterowania specyficzne dla danego
etapu i są wykorzystywane jako punkt odniesienia
do monitorowania postępów etapu.
266 I Dodatek A: Zarysy Opisów Produktów
Plany Zespolu U eżel i są wykorzystywane) mogą sk ła­
dać się po prostu z harmonogramu dołączonego do
Grup/Grupy Zadań przydzielonych Kierownikowi
Zespołu.
Plan powinien obejmować nie tylko czynności two-
rzen ia produktów, lecz również czynności zarzą­
dzania tworzeniem produktów, w tym czynności
związane z nadzorem, zarządzaniem jakością, zarzą­
dzaniem konfiguracją, komunikacją oraz z wszelki-
mi innymi wymaganymi mechanizmami sterowania
projektem.
A.16.2 Zawartość
• Opis planu Obejmuje zwięzły opis zakresu planu
(np. projekt, etap, zespół, sytuacja nadzwyczajna)
oraz sposób podejścia do planowania.
• Warunki wstępne dla planu Zawierają wszelkie
kluczowe warunki, które muszą być spełn i one
i utrzymane, aby plan zakończył się powodze-
niem.
• Zależności zewnętrzne Te, które mogą wpły­
wać na plan.
• Założenia planistyczne Te, na których plan j est
oparty.
• Uwzględnione doświadczenia Szczegóły doty-
czące odpowiednich doświadczeń z poprzednich,
podobnych projektów, które zostały poddane
przegl ądowi i uwzględn i one w tym planie.
• Monitorowanie i kontrola Szczegóły dotyczące
sposobu monitorowania i kontrolowania planu.
• Budżety Obejmujące harmonogram i koszty,
łącznie z budżetem ryzyka i budżetem zmiany.
• Tol erancje Tolerancje czasu, kosztów i zakresu
dla planu na danym poziomie (które mogą rów-
nież obejmować bardziej szczegółowe tolerancje
ryzyka na poziomie etapu lub zespołu).
• Opisy produktów (patrz A.17) Obejmują pro-
dukty objęte zakresem planu (w przypadku
Planu Projektu będzie to produkt końcowy
projektu, w przypadku Planu Etapu b ędą to
produkty etapu, a w przypadku Planu Zespołu
będzie to dotyczyło przydzielonej Grupy Zadań).
W poszczególnych Opisach Produktów są okre-
ślone tolerancje jakości.
• Harmonogram Może obejmować:
• Wykres Gantta lub wykres paskowy.
• Strukturę podzi ału produktów (patrz przy-
kład w Dodatku D).
• Diagram następstwa produktów (patrz przy-
kład w Dodatku D).
• S i eć działań .
• Tabelę wymaganych zasobów - z podziałem
na poszczególne rodzaje zasobów (np. czte-
rech inżynierów, jeden kierownik testów,
jeden analityk biznesowy).
• Tabe l ę wnioskowanych/przydzielonych kon-
kretnych zasobów - z podaniem nazwisk lub
1m1on.
A.16.3 Pochodzenie
• Założenia Projektu.
• Strategia Zarządza n i a Jakością (dla czynności
zarządzania jakością włączonych do planu).
• Strategia Zarządzania Ryzykiem (dla czynności
zarządzania ryzykiem włączonych do planu).
• Strategia Zarządzan i a Komunikacją (dla czyn-
ności zarządzania kom un ikacj ą włączonych do
planu).
• Strategia Zarz.ądzan i a Konfiguracją (dla czyn-
ności zarządzania konfiguracją włączonych do
planu).
• Informacje o dostępności zasobów.
• Rejestry i dzienniki.
A.16.4 Format i sposób przedstawienia
Plan może przybierać szereg formatów, włączając
wto:
• od rębny dokument tub część Dokumentacji
Inicjowania Projektu;
• dokument, arkusz kalkulacyjny, slajdy prezentacji
tub mapę myśli;
• wpis do narzędzia używanego do zarządzani a
projektem.
Harmonogram może mieć formę listy kontrolnej
produktów (tj. listy produktów, które mają być
dostarczone w ra mach planu, wraz z kluczowymi
terminami związanymi z ich statusem, np. gotowy
projekt dokumentu, przeprowadzono inspekcję
jakości, zatwierdzony itp.) lub m i eć format uzyski-
wany za pomocą narzędz i a stosowanego do pla-
nowania projektu.
A.16.S Kryteria jakości
• Plan jest możliwy do wykonania.
• Dane szacunkowe są oparte na konsultacjach
z osobami, które będą wykonywać prace i/lub na
danych historycznych.
• Kierownicy Zespołów potwierdzili, że ich część
planu jest możliwa do wykonania.

• Plan ma właściwy poziom szczegółowości (nie
jest zbyt ogólny, ani nadmiernie szczegółowy).
• Plan jest zgodny z wymaganymi standardami
organizacji lub programu.
• Plan uwzględn ia doświadczen i a z poprzednich
projektów.
• Plan uwzględnia wszelkie wymogi prawne.
• Plan obejmuje czynności zarządzan i a i sterowa-
nia (np. jakością), a także czynności tworzenia
produktów w ramach planu.
• Plan wspiera Strategię Zarządzania Jakością,
Strategię Zarządzania Konfiguracją, Strategię
Zarządzania Ryzykiem, Strategię Zarządzania
Komunikacją i formulę realizacji projektu.
• Plan wspiera zarządcze mechanizmy sterowania
określ one w Dokumentacji Inicjowania Projektu.
A.17 OPIS PRODUKTU
A.17 .1 Przeznaczenie
Opis Produktu jest wykorzystywany do:
• zrozumienia szczegółowej natury, przeznaczenia,
funkcji i wyglądu produktu;
• określenia, kto będzie używał/wykorzystywał
produkt;
• wskazania źródeł informacji lub dostawy dla pro-
duktu;
• określen i a poziomu jakości wymaganego od pro-
duktu;
• umożliwi enia określe ni a czynności wymaganych
do wytworzenia, przeg l ądu i zatwierdzenia pro-
duktu;
• określenia osób lub umiejętności potrzebnych do
wytworzenia, przeglądu i zatwierdzenia produktu.
A.17 .2 Zawartość
• Identyfikator Niepowtarzalne oznaczenie, naj-
prawdopodobniej przyznane produktowi zgod-
nie z metodą zarządzania konfi guracj ą i obej-
mujące zwykle nazwę proj ektu, n azwę obiektu
i numer wersji.
• Nazwa Nazwa, pod którą produkt jest ogólnie
znany.
• Przeznaczenie Określenie celu, któremu pro-
dukt będzie służył oraz kto będzie go użytkował.
Czy produkt jest środkiem do realizacji celu, czy
celem samym w sobie? Jest ono pomocne do
zrozumienia funkcji produktu, rozmiaru, ja kości,
złożoności, trwałości itp.
Dodatek A· Zarysy Opisów Produktów I 267
• Zawartość/Skład Jest to lista części produktu.
Na przykład jeżeli produkt jest raportem, mogła ­
by to być lista planowanych rozdziałów lub pod-
rozdzia łów.
• Pochodzenie Jakie są źródła, z których produkt
się wywodzi, np.:
• projekt konstrukcyjny zostanie opracowany
na podstawie specyfikacji;
• produkt zakupiony od dostawcy;
• wykaz oczekiwanych korzyści uzyskany od
użytkownika;
• produkt uzyskany od innego wydziału lub
zespoi u.
• Wymagany f ormat i sposób przedst awienia
Charakterystyka produktu, na przykład jeżel i pro-
dukt j est raportem, określenie, czy raport ma m ieć
formę dokum entu, slajdów prezentacji czy maila.
• Wymagane umiej ętności wytwórcy Wskazanie
um i ejętności wymaganych do wytworzenia
produktu albo wskazanie obszaru/obszarów
firmy, które powinny zapewnić zasoby wytwór-
cze. Wyznaczenie konkretnych osób może być
odłożone aż do rozpoczęcia planowania etapu,
w trakcie którego produkt ma być wytworzony.
• Kryteria jakości Przedstawiają specyfikację jako-
ści, zgodnie z którą produkt musi być wytworzo-
ny oraz pomiary jakości, jakie będą zastosowane
przez sprawdzaj ących ukończony produkt. M oże
to być proste odniesienie do j ednego lub kilku
powszechnych standardów udokumentowanych
gdzie indziej, może to być też pełne objaśni enie
miary, jaka ma być zastosowana. Jeżeli produkt
ma być wytworzony i zatwierdzony w różnych
stadiach (np. zdemontowana maszyna, prze-
niesiona maszyna i ponownie zmontowana
maszyna), wówczas kryteria jakości powinny być
podzielone na grupy dotyczące poszczególnych
stadiów produktu.
• Tolerancja jakości Informacje o przedziale war-
tości kryteriów j akości, w obrębie którego możl i ­
we będ zie zaakceptowanie produktu.
• Met oda kontroli j akości Rodzaj e metod kon-
t roli j akości, np. weryfikacja projektu konstrukcji,
wdrożenie pilotowe, testowanie, inspekcja lub
przegląd, jakie mają być zastosowane do spraw-
dzenia jakości łub funkcjonalności produktu.
• Wymagane umiejętności kontrolera jakości
Wskazanie umiejętności wymaganych do zasto-
sowania wybranej metody kontroli jakości lub
wskazanie, jaka jednostka(-i) organizacyjna(-e)
powinna zapewnić zasoby do testowania.
268 I Dodatek A: Zarysy Opisów Produktów
Wyznaczenie konkretnych osób może być odło­
żone aż do rozpoczęcia planowania etapu,
w trakcie którego ma być przeprowadzone
sprawdzenie jakości.
• Obowiązki dotyczące jakości Określenie
wytwórcy, kontrolera/kontrolerów i zatwierdza-
jącego/zatwierdzających produkt.
A.17.3 Pochodzenie
• Struktura podziału produktów.
• Końcowi użytkownicy produktu.
• Strategia Zarządzania Jakością.
• Strategia Zarządzania Konfiguracją.
A.17.4 Format i sposób prezentacji
Opis Produktu może przybierać szereg formatów,
wlączając w to:
• dokument, slajdy prezentacji lub mapę myśl i ;
• wpis do narzędzia używanego do zarządzan i a
projektem.
A.17 .5 Kryteria jakości
• Przeznaczenie produktu jest jasno określone
i spójne z innymi produktami.
• Produkt jest opisany na tyle szczegółowo, aby
wystarczało to do zaplanowania i zarządzania
jego wytwarzaniem.
• Opis Produktu jest zwięzly, ale wystarczający do
wytworzenia, przeglądu i zatwierdzenia pro-
duktu.
• Odpowiedzialność za wytworzenie produktu jest
jasno określona.
• Odpowiedzialność za wytworzenie produktu
jest zgodna z rolami i obowiązkami przedsta-
wionymi w opisie organizacji zespolu zarzą­
dzania projektem oraz w Strategii Zarządzania
Jakością.
• Kryteria j akości produktu są spójne ze standarda-
mi jakości projektu, standardowymi listami kon-
t rolnymi oraz kryteriami akceptacji.
• Kryteria jakości umożl iwiają rozstrzygn ięci e, czy
produkt odpowiada swemu przeznaczeniu.
• Wskazane sposoby/rodzaje kontroli j akości
pozwalają stwierdzić, czy produkt spełn ia okre-
ślone dla niego kryteria jakości.
• Główny(-ni) Użytkownik(-cy) potwierdzili, że
ich wymagania dotyczące produktu, określone
w Opisie Produktu, zostały dokładnie określone.
• Glówny(-ni) Dostawca(-cy) potwierdzili, że wyma-
gania dotyczące produktu określ one w Opisie
Produktu są możliwe do spełnienia.
A.18 ZESTAWIENIE STATUSU PRODUKTÓW
A.18.1 Przeznaczenie
Zestawienie Statusu Produktów dostarcza infor-
macji o stanie określonej grupy produktów. Grupy
te mogą być różne, np. zestawienie może dotyczyć
calego projektu, określonego etapu, określonego
obszaru projektu lub historii konkretnego produktu.
Jest ono szczególnie przydatne, gdy Kierownik Pro-
jektu chce potwierdzić numery wersji produktów.
A.18.2 Zawartość
• Zakres raportu Opis zakresu raportu (np. dla
całego projektu, etapami, wedlug rodzajów pro-
duktu, wed ług dostawców itp. Cechy produktu
można wykorzystać do dokonania wyboru pod-
zbioru produktów do raportu).
• Data wytworzenia Data wytworzenia raportu.
• Status produktów Dla każdego produktu
objętego zakresem raportu, w raporcie zwykle
zawarte są następujące informacje:
• identyfikator i nazwa produktu;
• wersja;
• status i data zmiany statusu;
• stadium wytwarzania produktu;
• właściciel docelowy;
• aktualni posiadac.ze;
• miejsce przechowywania;
• użytkownik(-cy);
• wytwórca i data przydzielenia wytwórcy;
• planowana i faktyczna data zatwierdzenia
Opisu Produktu j ako bazowego;
• planowana i f aktyczna data zatwierdzenia
produktu jako bazowego;
• planowana data kolejnego zatwierdzenia;
• lista obiektów powi ązanych;
• lista powi ązanych zagadnień (lącznie ze
zmianami zatwierdzonymi i oczekującymi na
decyzję) i ryzyk.
A.18.3 Pochodzenie
• Zapisy Obiektu Konfiguracji.
• Plan Etapu.

A.18.4 Format i sposób prezentacji
Zestawienie Statusu Produktów może przybi erać
szereg formatów, włączając w to:
• dokument, arkusz kalkulacyjny lub raport z bazy
danych;
• produkt narzędzia używanego do zarządzania
projektem.
A.18.5 Kryteria jakości
• Dane i daty są zgodne z Planem Etapu.
• Nazwa produktu jest zgodna z diagramem struk-
tury podzialu produktów i nazwą w Zapisie
Obiektu Konfiguracji.
A.19 ZAŁOŻEN IA PROJEKTU
A.19.1 Przeznaczenie
Za łożen i aProj ektu są wykorzystywane do dostarcze-
nia pelnej i wiarygodnej podstawy dla inicjowania
proj ektu i są wytwarzane w procesie Przygotowanie
Proj ektu.
W procesie Inicjowanie Projektu treść Zależeń Pro-
j ektu jest rozbudowywana i udoskonalana jako
część Dokumentacji Inicjowania Projektu, po czym
Założenia Projektu nie są dalej utrzymywane.
A.19.2 Zawartość
• Definicj a projektu Wyjaśnienie, co projekt
powinien osiągnąć. Definicja projektu powinna
obejmować następujące informacje:
• tło;
• cele projektu (obejmujące docelowe
wymagania dotyczące czasu, kosztu, jakości,
zakresu, ryzyka i korzyści );
• pożąda n e rezu ltaty;
• zakres projektu i wylączen ia;
• ograniczenia i założe n ia;
• t olerancje proj ektu;
• użytkowni k (-cy) i inne znane zainteresowane
st rony;
• punkty styku.
• Zarys Uza sadnienia Biznesowego (pat rz A.2)
Przyczyny, dla których projekt jest potrzebny
oraz wybrane możl iwe rozwi ąza n ie bizneso-
we. Zarys ten zostanie następnie rozbudowany
w celu stworzenia szczegółowego Uzasadnienia
Biznesowego w procesie Inicjowanie Projektu
Dodatek A: Zarysy Opisów Produktów I 269
• Opis Produktu Koń cowego Projektu (patrz A.21)
Obejmuje oczekiwania ja kościowe klienta, kryte-
ria akceptacji ze strony użytkownika oraz kryte-
ria akceptacji przedstawione przez zespoły eks-
ploatacji i utrzymania.
• Formuła realizacji projektu Określenie rozwią ­
zania, które zostanie zastosowane w projekcie
w celu dostarczenia rozwiązania biznesowe-
go, wybranego z Uzasadnienia Biznesowego,
z uwzględnieniem środowiska operacyjnego, do
którego to rozwiązan i e musi być dostosowane.
• Struktura zespołu za rządza nia projektem
Schemat przedstawi ający osoby, które będą
zaa n gażowa n e w zarządzanie projektem.
• Opisy ról Dla zespołu za rządza nia proj ektem
ora z innych kluczowych zasobów, które do tego
czasu zidentyfikowano.
• Odniesienia Do powi ązanych dokumentów lub
produktów .
A.19.3 Pochodzenie
• Zlecenie przygotowania projektu dostarczone na
początku proj ektu.
• Ki erownictwo programu - jeżeli projekt jest
częścią programu, Za łożenia Projektu zostaną
prawdopodobnie dostarczone przez program
i w związku z tym nie muszą się wywodzić ze
zlecenia przygotowania projektu.
• Dyskusje z kierownictwem organizacji dotyczą ­
ce strategii organizacji i wszelkich zasad polityki
i standardów, jakie mają zastosowanie.
• Dyskusje z Komitetem Sterującym i użytkowni­
kami, jeżeli zlecenie przygotowania projektu jest
niekompletne lub jeżel i nie dostarczono zlecenia
przygotowania projektu.
• Dyskusje z jednostkami f unkcjonalnymi eksplo-
at acji i utrzymania Oeśli dotyczy).
• Dyskusje z (potencjalnymi) dostawcami dotyczą­
ce specjalistycznych cykli rozwoj u produktów,
które mogłyby być wykorzystane.
• Dziennik Doświad cze ń .
A.19.4 Format i sposób przedstawienia
Założenia Projekt u m ogą przybierać szereg forma-
t ów, wlączając w to:
• dokument lub slajdy prezentacji;
• wpis do na rzędzia za rządzania projektem.
270 I Dodatek A. Zarysy Opisów Produktów
A.19.5 Kryteria jakości
• Założenia Projektu mają zwięzły charakter,
ponieważ ich celem w tym momencie jest dostar-
czenie solidnych podstaw dla inicjowania projek-
tu. Założenia Projektu zostaną następnie udosko-
nalone i rozbudowane jako część Dokumentacji
Inicjowania Projektu.
• Założenia Projektu dokładnie odzwierciedlają
zlecenie przygotowania projektu oraz wymaga-
nia biznesowe i wymogi użytkowników.
• W formule real izacji projektu rozpatrzono szereg
rozwi ązań, takich jak: produkt stworzony spe-
cjalnie na zamówienie klienta lub gotowy pro-
dukt standardowy, produkt zlecony na zewnątrz
lub opracowany wewnątrz firmy, produkt zapro-
jektowany od nowa lub zmodyfikowany istn ieją­
cy produkt.
• Wybrana formula rea lizacji projektu pozwala na
maksymalne zwiększenie prawdopodobieństwa
końcowego powodzenia projektu.
• Cele projektu, formula realizacji projektu i stra-
tegie są zgodne z zasadami społecznej odpowie-
dz i alności organizacji.
• Cele projektu są konkretne, mierzalne, osi ąga l ne,
realistyczne i określone w czasie {SMART) 1•
A.20 DOKUMENTACJA INICJOWANIA
PROJEKTU
A.20.1 Przeznaczenie
Celem Dokumentacji Inicjowania Projektu jest zde-
finiowanie projektu w celu stworzenia podstawy do
zarządzania nim oraz całościowej oceny powodze-
nia projektu. Dokumentacja Inicjowania Projektu
wyznacza kierunek i zakres projektu oraz (wraz
z Planem Etapu) stanowi swoisty „kontrakt" zawar-
ty pomiędzy Kierownikiem Projektu a Komitetem
Sterującym.
Trzy podstawowe zastosowania Dokumentacji Ini-
cjowania Projektu to:
• zagwarantowanie, że projekt posiada wiarygod-
ną podstawę, przed zwróceniem się do Komitetu
Sterującego, aby poczynił jakiekolwiek większe
zobowiązania wobec projektu;
• pełnien i e funkcji bazowego dokument u,
w odniesieniu do którego Komitet Sterujący
i Kierownik Projektu mogą oceniać postępy,
ang. SMART: Specific, Measurable, Achievable, Rea/istic
and Time-bound - przypis tlumacza.
zagadnienia i bieżące kwestie dotyczące zasad-
ności projektu;
• zapewnienie jednego źródła informacji dotyczą­
cych projektu tak, aby osoby przystępujące do
„organizacji powalanej na pewien czas" mogły
szybko i łatwo dowiedzieć się, czego dotyczy
projekt i w jaki sposób jest zarządzany.
Dokumentacja Inicjowania Projektu jest produktem
„żywym", który powinien w każdym momencie
odzwierciedlać aktualny status, plany i mechani-
zmy sterowania projektem. Jej produkty sk ładowe
muszą być aktualizowane i ponownie zatwierdzane,
w razie potrzeby lub na końcu każdego etapu, aby
odzwierciedlały aktualny status jej poszczególnych
części składowych.
Wersja Dokumentacji Inicjowania Projektu, która
została wykorzystana do uzyskania zezwolenia
na rea l izację projektu {wersja pierwotna), zostaje
zachowana jako podstawa do późniejszej oceny
efektywności dokonywanej podczas zamykania
projektu.
A.20.2 Zawartość
Pon i żejpodano spis treści Dokumentacji Inicjowania
Projektu. Należy pamiętać, że pierwsze dwie sekcje
{definicja projektu i formula realizacji projektu)
pochodzą z Założeń Projektu.
• Definicja projektu Wyj aśnienie, co projekt
powinien osi ągnąć. Powinna obejmować nastę­
pujące informacje:
• tło;
• cele projektu i pożądane rezultaty;
• zakres projektu i wyłączenia;
• ograniczenia i za łoże n ia;
• użytkownik(-cy) i inne znane zainteresowane
strony;
• punkty styku {interfejsy);
• Formuła realizacji projektu Określ enie rozwią­
zania, które zostanie zastosowane w projekcie
w celu dostarczenia rozwiązan i a biznesowe-
go, wybranego z Uzasadnienia Biznesowego,
z uwzględnieniem środowiska operacyjnego, do
którego to rozwiązanie musi być dostosowane.
• Uzasadnienie Biznesowe {patrz A.2) Opis uza-
sadnienia projektu na podstawie szacunkowych
kosztów, ryzyk i korzyści.
• Struktura zespołu zarządza n ia projektem
Schemat przedstawiający osoby, które będą
zaangażowane w zarządzanie projektem.

• Opisy ról Dla zespołu zarządzania projektem
oraz wszelkich innych kluczowych zasobów.
• Strat egia Zarządzan ia Jakością (patrz A.22)
Opis technik i standardów j akości, jakie mają być
zastosowane oraz odpowiedz i alności za osi ą ­
gn ięci e wymaganych poziomów j akości owych .
• Strategia Zarządza ni a Konfiguracją (patrz A.6)
Opis, jak i kto będzie kontrolować produkty pro-
jektu i j e chronić.
• Strategia Zarządzania Ryzykiem (patrz A.24)
Opis konkretnych technik i standardów zarzą­
dzania ryzykiem do zastosowania oraz odpowie-
dzialności za zapewnienie efektywności procedu-
ry zarządzania ryzykiem.
• St rategia Zarządzania Komunikacją (patrz A.4)
Określenie stron zainteresowanych proj ek-
tem oraz środków i częstotl iwości komunikacji
pomiędzy nimi a projektem.
• Plan Projektu (patrz A.16) Opis, w jaki sposób
i kiedy mają być osi ągnięte cele projektu, poprzez
wskazanie glównych produktów, czynności i zaso·
bów wymaganych dla projektu. Stanowi obiekt
odniesienia, względem którego są monitorowane
postępy projektu etap po etapie.
• Mechanizmy sterowania Zestawienie mechani-
zmów sterowania na poziomie projektu, takich
jak granice etapów, uzgodnione tolerancje,
monitorowanie i raportowanie.
• Dostosowanie metodyki PRINCE2 Podsumowa-
nie sposobu, w jaki metodyka PRINCE2 zostanie
dostosowana do projektu.
A.20.3 Pochodzenie
• Zalożenia Projektu.
• Dyskusje z interesariuszami - użytkownikami,
przedstawicielami biznesu i dostawcami na
temat ich wkładu w zakresie metod, standardów
i mechanizmów sterowania.
A .20.4 Format i sposób przedstawienia
Dokumentacja Inicjowania Projektu może m i eć
formę:
• pojedynczego dokumentu;
• indeksu zbioru wchodzących w jej skład doku-
mentów;
• dokumentu zawierającego odniesienia do szeregu
innych dokumentów;
• zbioru informacji w narzędziu zarządzania pro-
jektem.
Dodatek A: Zarysy Opisów Produktów I 271
A.20.5 Kryteria jakości
• Dokumentacja Inicjowania Projektu wlaściwie
przedstawia projekt.
• Ukazuje zasadny, możl iwy do zrealizowania
projekt, który pozostaje w zgodzie ze strategią
organizacji lub ogólnymi potrzebami programu.
• Struktura zarządzania zespołem jest kompletna,
wraz z nazwiskami i stanowiskami. Wszystkie
role zostaly uwzględnione i towarzyszą im
uzgodnione opisy ról. Relacje i linie podziału
władzy są jasne. Jeśli to koniec.zne, struktura
organizacyjna zespołu zarządzania projektem
wskazuje, komu podlega Komitet Sterujący.
• Wyraźnie ukazuje system sterowania, raporto-
wania i zarządzania strategicznego, który j est
moż l iwy do wprowadzenia, odpowiedni do skali,
ryzyka oraz znaczenia projektu dla kierownictwa
organizacji lub programu.
• Mechanizmy sterowania spełn i ają pot rzeby
Komitetu Sterującego, Kierownika Projektu
i Kierowników Zespołów oraz spełniają wymaga-
nia delegowanego nadzoru.
• Jest jasno określone, kto administruje każdym
z mechanizmów sterowania.
• Cele, formuła realizacji i strategie projektu są
zgodne z zasadami społecznej odpowiedzialności
organizacji i mechanizmy sterowania są wystar-
czające do zapewnienia, aby projekt pozostawał
w zgodzie z tymi zasadami.
• Rozważono i uzasadniono fo rmat Dokumentacji
Inicjowania Projektu. Dla małych projektów
wystarczający jest jeden dokument. Dla dużych
projektów wskazane jest, aby Dokumentacja
Inicjowania Projektu była zbiorem odrębnych
dokumentów. Zmienność każdego elementu
Dokumentacji Inicjowania Projektu powinna być
wykorzystana do oceny, czy powinien on stano-
wić odrębny element, np. elementy, które będą
prawdopodobnie pod l egać częstym zmianom,
powinny być wydzielone.
A.21 OPIS PRODUKTU KOŃ COWEGO
PROJEKTU
A.21 .1 Przeznaczenie
Opis Produktu Końcowego Projektu to specjalny
rodzaj Opisu Produktu, który określa, co projekt
musi osiągnąć w celu uzyskania akceptacji. Jest
wykorzystywany w celu:
272 I Dodatek A: Zarysy Opisów Produktów
• uzyskania zgody użytkownika na zakres i wyma-
gania projektu;
• określenia oczekiwań jakościowych klienta;
• określenia kryteriów, metod i obowiązków doty-
czących akceptacji dla projektu.
Opis Produktu Końcowego Projektu jest tworzo-
ny w procesie Przygotowanie Projektu jako część
wstępnej czynności ustalania zakresu i jest udosko-
nalany w procesie Inicjowanie Projektu podczas
tworzenia Planu Projektu. Jest wykorzystywany
w procesie Zamykanie Projektu jako element wery-
fikacji, czy projekt dostarczył oczekiwane rezultaty
i czy spelnione zostały kryteria akceptacji.
A.21 .2 Zawartość
• Nazwa Nazwa, pod którą projekt jest znany.
• Przeznaczenie Określ enie przeznaczenia
produktu projektu oraz jego użytkowników.
Pomaga zrozumieć funkcje produktu, jego roz-
miar, jakość, złożoność, trwalość itp.
• Zawartość/skład Opis głównych produktów,
jakie projekt ma dostarczyć.
• Pochodzenie Jakie są produkty żródlowe, z któ-
rych ten produkt się wywodzi? Na przykład:
• istn i ejące produkty do modyfikacji;
• specyfikacje konstrukcyjne;
• raport ze studium wykonalności;
• zlecenie przygotowania projektu.
• Wymagane umiej ętności wytwórcy Wskazanie
umiejętności wymaganych do wytworzenia pro-
duktu albo wskazanie obszaru{-ów) organizacji,
które powinny zapewnić zasoby wytwórcze.
• Oczekiwania jakościowe klienta Opis jakości
oczekiwanej od produktu projektu oraz stan-
dardów i procesów, jakie mają być zastosowa-
ne, aby osiągnąć tę jakość. Będą one wpływać
na każdy aspekt wytwarzania produktu, a więc
ta k że na terminy i koszty. Oczekiwania j akościo­
we są rejestrowane podczas rozmów z kli entem.
W miarę możl iwości oczekiwania powinny mieć
określone priorytety.
• Kryteria akceptacji Zawierająca priorytety lista
kryteriów, jakie produkt projektu musi spelnić
przed zaakceptowaniem go przez klienta, tj.
mierzalne definicje cech, które zbiór produktów
powinien posiadać, aby był do zaakceptowania
dla głównych interesariuszy {a w szczególności
dla użytkowników i jednostek funkcjonalnych
eksploatacji i utrzymania). Na przykład: latwość
użytkowania, łatwość wsparcia, łatwość utrzyma-
nia, wygląd, główne funkcje, koszty wytworzenia,
koszty bieżące eksploatacji, wydajność, dostęp­
ność, niezawodność, bezpieczeństwo, dokładność
lub efektywność.
• Tolerancje projektu Określ en i e tolerancji, które
mogą m i eć zastosowanie do kryteriów akceptacji.
• Metoda akceptacji Określenie środków, za
pomocą których akceptacj a zostanie potwier-
dzona. Może to być po prostu potwierdzenie,
że wszystkie produkty projektu zostały zatwier-
dzone lub może obejmować opis zlożonych pro-
cedur przekazania produktu projektu, w tym
ewentualnego stopniowego przekazywania
produktów projektu.
• Obowiązki dotyczące akceptacji Określ enie,
kto będzie odpowiedzialny za potwierdzenie
akceptacji.
A.21.3 Pochodzenie
• Zlecenie przygotowania projektu.
• Dyskusje z Głównym Użytkownikiem i Przewod-
niczącym - jeśli możliwe w formie warsztatów
służących ustaleniu zakresu projektu.
• Zaproszenie do złożenia oferty (w stosunkach
handlowych klient/dostawca).
A.21.4 Format i sposób przedstawienia
Opis Produktu dotyczący produktu projektu może
przybi erać szereg formatów, włączaj ąc w to:
• dokument, slajdy prezentacji lub mapę myśli;
• wpis do narzędzia używanego do zarządzania
projektem.
A .21.5 Kryteria jakości
• Przeznaczenie jest jednoznacznie określone.
• Skład określa pełen zakres projektu.
• Kryteria akceptacji stanowią wyczerpującą listę,
według której projekt będzie oceniany.
• Kryteria akceptacji spełniają wymagania wszyst-
kich g łównych interesariuszy (np. w zakresie
użytkowan i a i utrzymania).
• Opis Produktu Końcowego Projektu określa spo-
sób, w jaki jednostki funkcjona lne eksploatacji
i utrzymania będą oceniać akceptowalność goto-
wego produktu(-ów):
• Wszystkie kryteria są mierzalne.
• Każde kryterium z osobna jest realistyczne.
• Kryteria są rea listyczne i spójne ze sobą.
Na przykład wysoka jakość, krótki termin

dostawy i niskie koszty mogą nie być spójne
pomiędzy sobą.
• Wszystkie kryteria można sprawdzić w trak-
cie trwania projektu (np. maksymalna
wydajność pompy wodnej) lub za pomocą
pomiarów zastępczych , które dosta rczają
racjona lnych wskaźn ików pozwa l aj ących oce-
nić czy kryteria akceptacji zostaną speł n i one
po zakończen i u projektu (np. pompa wodna,
która spełnia konstrukcyjne i produkcyjne
standardy niezawodności).
• Oczekiwania jakościowe uwzględniają :
• charakterystykę głównych wymogów jako-
ściowych produktu (np. szybki/wolny, duży/
mały, krajowy/globalny);
• elementy systemu zapewnienia jakości stoso-
wanego u klienta, które powinny być wyko-
rzystane;
• wszelkie inne standardy, które powinny być
wykorzystane;
• poziom zadowolenia klientów/pracowników,
jaki powinien być osiągnięty, jeśli zostanie
zbadany.
A .22 STRATEGIA ZARZĄDZAN IA JAKOŚCIĄ
A.22.1 Przeznaczenie
Strategia Za rządzania Ja kością jest wykorzystywana
do określ enia technik i standardów j akości , które
będą stosowane oraz różnych obowi ązków zwi ąza­
nych z osiągnięciem wymaganych poziomów jakości
w trakcie projektu.
A.22.2 Zawartość
• Wprowadzenie Określa przeznaczenie, cele,
zakres odpowiedzialności i osobę odpowiedzial-
ną za strategię.
• Procedura zarządzania jakości ą Opis (lub
odniesienie do) procedury zarządzania jakością,
która ma być stosowana. Wszelkie odchylenia od
standardów j akości zarzą d za n ia organizacji lub
programu powinny być uwypuklone wraz z uza-
sadnieniem tych odchyl eń. Procedura powinna
obejmować:
• Planowanie jakości.
• Kontrolę jakości: sposób podejścia w projek-
cie do czynności kontroli jakości, co może
obejmować:
• standardy jakości;
Dodatek A: Zarysy Opisów Produktów I 273
• wzory i formularze do wykorzystania (np.
Opis(y) Produktu(-ów), Rejestr Jakości);
• definicje rodzajów metod kontroli jakości
(np. inspekcja, wdrożen i e pilotowe);
• wartości miar do wykorzystania w kontro-
li jakości;
• Nadzór j akości : sposób pod ejścia proj ektu do
czynności nadzoru jakości, co może obejmo-
wać:
• obowiązki Komitetu Sterującego;
• audyty zgodności;
• przeglądy organizowane przez kierownic-
two organizacji lub programu.
• Narzędzia i techniki Odniesienia do wszelkich
systemów lub narzędzi zarządzania jakością,
które maj ą być wykorzystane, ze wskazaniem
ewentualnych preferowanych t echnik, do wyko-
rzystania na każdym kroku procedury zarządza­
nia jakości ą.
• Wymagane zapisy Definicja zapisów jakości,
które będą wymagane i gdzie będą przechowy-
wane, łącznie z określeniem zawartości i wyma -
ganego formatu Rejestru Jakości.
• Raportowanie Opis wszelkich raportów doty-
czących zarządzania jakością, które mają być
wytworzone, z podaniem ich przeznaczenia,
terminów i odbiorców.
• Terminy dzi a ła ń zwi ąza nych z zarzą dzaniem
jakością Okreś l en i e, kiedy mają być p odj ęte
forma lne czyn n ości zarządzania jakością, na
przykład audyty (może to być odniesienie do
Rejestru Jakości).
• Role i obowiązki Określenie ról i obowiązków
dla czynności zarządzania jakością, łącznie z obo-
wiązkami kierownictwa organizacji łub progra-
mu dotyczącymi jakości.
A.22.3 Pochodzenie
• Komitet Steruj ący.
• Założen ia Projektu:
• Struktura zespoł u za rządzan i a projektem
(role i obowiązki).
• Opis Produktu Końcowego Projektu
(oczekiwania jakościowe klienta i kryteria
akceptacji).
• Standardy organizacyjne.
• Systemy zarządzania jakością stosowane
u dostawcy i klienta.
• Wymogi dotyczące zarządzan i a konfiguracją.
274 I Dodatek A: Zarysy Opisów Produktów
• Wymogi dotyczące sterowania zmianami.
• Strategie organizacj i lub programu.
• Zorganizowane warsztaty i nieformalne dyskusje.
A.22.4 Format i sposób przedstawienia
Strategia Zarządza n ia J akości ą może przybi erać
reg formatów, włączając w to:
• odrębny dokument lub część Dokumentacji
Inicjowania Projektu;
• wpis do narzędzia używanego do zarządzania
projektem.
A.22.5 Kryteria jakości
• Strategia wyraźnie określasposoby spelnienia
oczekiwań jakościowych klienta.
• Określone sposoby zapewnienia jakości są wystar-
czające dla osiągnięcia wymaganej jakości.
• Obowiązki dotyczące jakości są określone aż do
poziomu niezależnego od projektu i Kierownika
Projektu.
• Strategia jest zgodna z systemami za rządzan i a
jakością stosowanymi u dostawcy i klienta.
• Strategia jest zgodna z polityką jakości organizacji
lub programu.
• Podejścia do zapewnienia jakości projektu są
odpowiednie w świetle wybranych standardów.
A.23 REJESTR JAKOŚCI
A.23.1 Przeznaczenie
Rejestr Jakości jest wykorzystywany do sumarycz-
nego zestawienia wszystkich planowanych i zakoń­
czonych działań dotyczących jakości. Rejestr Jakości
dostarcza informacji do Raportów Końcowych Etapu
i Raportu Końcowego Projektu. Jego celem j est:
• nadanie niepowtarzalnego numeru referencyjne-
go każdemu działaniu dotyczącemu jakości;
• pełn ienie funkcj i odsylacza do zapisów jakości
dla produktu;
• pełnienie funkcji zestawienia liczby i rodzaju
przeprowadzonych dzialań dotyczących jakości.
A.23.2 Zawartość
Każdy wpis w Rejestrze Jakości powinien zawierać
następujące informacje:
• Numer w pisu Niepowtarzalny numer referen-
cyjny nadawany każdemu dzialaniu dotyczą ­
cemu jakości, wpisanemu do Rejestru Jakości.
Zwykle będzie to wyrażenie numeryczne lub
alfan umeryczne.
• ł dentyfikator(y) produktu(-ów)
Niepowtarzalny(-e) identyfikator(-y) produktu/
(-ów), do których odnosi się działanie dotyczące
sze- jakości .
• Nazwa(-y) produktu(-ów) Nazwa(-y), pod jaką
produkt jest znany.
• Metoda Metoda wykorzystana do działania
dotyczącego j akości (np. wdrożen i e lub partia
pilotowa, przegląd jakości, audyt itp.).
• Role i obowiązki Osoba lub zespól odpowie-
dzialny za czynności zarządzania jakości ą (np.
audytor lub w przypadku przeg lądów jakości -
prezenter, kontroler/kontrolerzy, przewodniczący
narady, administrator).
• Terminy Planowane, przewidywane i faktyczne
terminy:
• działania dotyczącego jakości;
• potwierdzenia zakończenia działania
dotyczącego j akości.
• Wynik Wynik działania dotyczącego jakości.
Jeżeli produkt nie przejdzie pomyślnie przeglądu
jakości, ewentualna ponowna ocena powinna
być wykazana jako odrębny wpis w rejestrze,
ponieważ pierwotne dzialanie dotyczące jakości
zostało zakończone (przez podjęcie decyzji o nie-
pomyślnym wyniku tego działania).
• Zapisy jakości Odniesienia do dokumenta-
cji inspekcji jakości, takich jak plan testów lub
szczegóły dotyczące dzialań wymaganych w celu
naprawienia blędów i braków w produktach
podlegaj ących inspekcji.
A.23.3 Pochodzenie
• Format i zawartość Rejestru Jakości są określone
w Strategii Zarządzania Jakością.
• Wpisy są dokonywane, gdy dzialanie dotyczące
jakości zostaje wpisane do Planu Etapu dla bie-
żącego etapu zarządczego. M ogą podlegać aktu-
alizacji po stworzeniu Planu Zespolu.
• Pozostale informacje pochodzą z faktycznego
wykonania działania dotyczącego jakości.
• Data zatwierdzenia oznacza dzi eń, w którym
wszystkie dzialania naprawcze zostaly zatwier-
dzone.
A.23.4 Format i sposób przedstawienia
Rejestr Jakości może przybierać szereg formatów,
włączając w to:

• dokument, arkusz kalkulacyjny lub bazę danych;
• odrębny rejestr lub zapis w notatce z przeglądu
postępów;
• wpis do narzędz i a używanego do zarządzania
projektem;
• część zintegrowanego rejestru dla projektu obej-
mującego wszystkie ryzyka, dzialania, decyzje,
założenia, zagadnienia, doświadczenia itp.
A.23.5 Kryteria jakości
• Istnieje procedura gwarantująca wpisani e każ­
dego dzialania dotyczącego jakości do Rejestru
Jakości.
• Odpowiedzialność za Rejestr Jakości zostala przy-
dzielona.
• Działania sąjasno opisane i przydzielone.
• Wpisy posiadają niepowtarzalne identyfikatory,
wraz ze wskazaniami produktów, do których się
odnoszą.
• Dostęp do Rejestru Jakości jest kontrolowany.
• Rejestr Jakości jest przechowywany w bezpiecz-
nym miejscu.
• Wszystkie działania dotyczące jakości są przepro-
wadzane na odpowiednim poziomie kontroli.
A.24 STRATEGIA ZARZĄDZANIA RYZYKIEM
A.24.1 Przeznaczenie
Strategia Zarządzan i a Ryzykiem opisuje konkretne
techniki i standardy zarządzania ryzykiem, które
będą zastosowane, oraz odpowiedzialność za ustano-
wienie efektywnej procedury zarządzania ryzykiem.
A.24.2 Zawartość
• Wprowadzenie Określenie przeznaczenia,
celów, zakresu i osoby odpowiedzialnej za stra-
tegię.
• Procedura zarządzania ryzykiem Opis (lub
odniesienie do) procedury zarządzania ryzykiem,
jaka ma być zastosowana. Wszelkie odchylenia
od standardów zarządzania organizacją lub pro-
gramem powinny być uwypuklone wraz z uza-
sadnieniem tych odchyleń. Procedura powinna
obejmować takie dzialania jak:
• Identyfikowanie;
• Ocenianie;
• Planowanie;
• Wdrażanie;
• Komunikowanie.
Dodatek A: Zarysy Opisów Produktów I 275
• Narzędzia i techniki Odniesienie do systemów
lub narzędzi zarządzania ryzykiem, które będą
wykorzystane oraz ewentualnych preferowanych
technik, jakie mogą być wykorzystane na każ­
dym kroku procedury za rządzania ryzykiem.
• Wymagane zapisy Określenie zawartości i for-
matu Rejestru Ryzyk oraz wszelkich innych zapi-
sów dotyczących ryzyka, jakie będą wykorzysty-
wane przez projekt.
• Raportowanie Opis raportów dotyczących zarzą­
dzania ryzykiem, jakie mają być sporządzone,
z podaniem ich celów, terminów i odbiorców.
• Terminy działań związanych z zarządza ni em
ryzykiem Określenie, kiedy mają być podjęte
forma lne d zialani a zarządzania ryzykiem,
np. przy ocenach końcowych etapu.
• Role i obowiązki Określenie ról i obowiązków
dla dzialań dotyczących zarządzania ryzykiem.
• Skale ocen Określenie skal dla oszacowa-
nia prawdopodobieństwa i wplywu na projekt
w celu zapewnienia, by skale kosztów i czasu
(przykładowo) były odpowiednie dla budżetu
i ram czasowych projektu. Skale te mogą być
przedstawione w formie macierzy prawdopodo-
bieństwo/wplyw, okreś lającej kryteria dla każde­
go poziomu skali, np. „bardzo wysokie", „wyso-
kie", „średnie", „niskie" i „bardzo niskie".
• Bliskość Wskazówki dotyczące sposobu oceny
bliskości wystąpienia ryzykownych zdarzeń.
Bliskość jest odzwierciedleniem faktu, że ryzy-
ka mogą się zmateria li zować w określ onym
czasie i stopień ich wpływu będzie się różnić
w zależności od tego, kiedy wystąpią. Typowe
kategorie bliskości to: wkrótce, w trakcie etapu,
w trakcie projektu, po zakończeniu projektu.
• Kategorie ryzyka Definicje kategorii ryzyka,
które będą (ewentualnie) wykorzystane. Mogą
wywodzić się z diagramu struktury podzialu
ryzyka lub z istniejącej listy. J eżeli w danej kate-
gorii nie zarejestrowano żadnego ryzyka, może
to sugerować, że identyfikacja ryzyka nie byla
wystarczająco wnikliwa.
• Kategorie reakcji na ryzyko Definicja kategorii
możliwych do zastosowania reakcj i na ryzyko,
które z kolei są uzależnione od tego, c.zy ryzyko
j est postrzegane jako zagrożenie, czy jako szansa.
• Wskaźniki wczesnego ostrzegania Określenie
wskaźników, które należy zastosować w celu
monitorowania aspektów projektu o krytycz-
nym znaczeniu tak, aby osiągnięcie określonych
z góry poziomów wartości tych wskaźników
276 I Dodatek A Zarysy Opisów Produktów
wywoływało podjęcie działań korygujących.
Będą one wybierane na podstawie ich znacze-
nia dla celów projektu.
• Tolerancja ryzyka Określen ie progowych
poziomów ekspozycji na ryzyko, w przypadku
przekroczenia których ryzyko należy przekazać
na wyższy szczebel zarządzania. (Na przykład
tolerancja ryzyka, która na poziomie projektu
może być ustalona jako jakiekolwiek ryzyko,
którego wystąpienie powodowałoby straty han-
dlowe. Ka żde takie ryzyko na l eży przekazy-
wać kierownictwu organizacji lub programu.)
Tolerancja ryzyka powinna określać oczekiwania
kierownictwa organizacji lub programu oraz
Komitetu Sterującego dotyczące ryzyka.
• Budżet ryzyka Informacja, czy zostanie utwo-
rzony budżet ryzyka, a j eże l i tak, w j aki sposób
będzie wykorzystywany.
A.24.3 Pochodzenie
• Założenia Projektu.
• Uzasadnienie Biznesowe.
• Przewodnik, strategia lub polityka zarządzania
ryzykiem organizacji lub programu.
A.24.4 Format i sposób przedstawienia
Strategia Zarządzania Ryzykiem może przybierać
szereg formatów, włączając w to:
• odrębny dokument lub część Dokumentacji
Inicjowania Projektu;
• wpis do narzędzia używanego do zarządzania
projektem.
A.24.5 Kryteria jakości
• Zakresy obowiązków są jasno określone i zrozu-
miałe zarówno dla klienta, jak i dla dostawcy.
• Procedura zarządzania ryzykiem jest jednoznacz-
nie udokumentowana i zrozumiała dla wszyst-
kich stron.
• Definicje skal, oczekiwanych wartości i bl iskości
ryzyka są jasno określ one i jednoznaczne.
• Wybrane skale są odpowiednie dla wymaganego
poziomu kontroli.
• Wymogi raportowania ryzyka są w pełni okre-
ślone.
A.25 REJESTR RYZYK
A.25.1 Przeznaczenie
Rejestr Ryzyk stanowi zapis zidentyfikowanych ryzyk
dotyczących projektu, wraz z ich statusem i historią.
Jest wykorzystywany do zapisywania i przechowy-
wania informacji o wszystkich zidentyfikowanych
zagrożeniach i szansach związanych z projektem.
A.25.2 Zawartość
Każdy wpis w Rejestrze Ryzyk powinien zawierać
następujące informacje:
• Identyfikator ryzyka Niepowtarzalny numer
referencyjny każdego ryzyka wpisanego do
Rejestru Ryzyk. Będzie to zwykle wyrażenie
numeryczne lub alfanumeryczne.
• Autor zgłoszenia Osoba, która zgłosi ła dane
ryzyko.
• Data zarejestrowania Data zidentyfikowania
ryzyka.
• Kategoria ryzyka Rodzaj ryzyka w odniesieniu
do wybranych kategorii projektu (np. harmono-
gram, jakość, prawne itp.).
• Opis ryzyka W kategori ach przyczyny, zdarze-
nia (zagrożenie lub szansa) i skutku (opis słowny
wpływu).
• Prawdopodobieństwo, wpływ i wartość oczeki-
wana Pomocne jest oszacowanie wartości inhe-
rentnych (przed działaniem będącym reakcją na
ryzyko) oraz wartości rezydualnych (po działaniu
będącym reakcją na ryzyko). Wartości te powin-
ny być rejestrowane zgodnie ze skalami wybra -
nymi dla projektu.
• Bliskość ryzyka Będzie to zwykle określenie
c.zasu, jaki upłynie od chwili obecnej do przewidy-
wanego terminu wystąpienia ryzyka (np. wkrótce,
w trakcie etapu, w trakcie projektu, po zakoń­
czeniu projektu). Bliskość ryzyka powinna być
rejestrowana zgodnie ze skalami wybranymi dla
projektu.
• Kategorie reakcji na ryzyko Sposób traktowa -
nia ryzyka w projekcie w kategoriach wybranych
dla projektu. Na przykład:
• dla zagrożeń: unikanie, redukowanie, plan
rezerwowy, przeniesienie, akceptowanie,
współdzielenie;
• dla szans: wzmocnienie, wykorzystanie,
odrzucenie, współdzielenie.
• Proponowane reakcje na ryzyko Działania
w celu rozwiązania kwestii ryzyka, przy czym

działania te powinny być dostosowane do
wybranych kategorii reakcji. Należy pamiętać,
że do danego ryzyka może mieć zastosowanie
więcej n iż j edna reakcja na ryzyko.
• Status ryzyka Zwykle jest to określ enie, czy
ryzyko nadal istnieje, czy jest zamknięte.
• Właściciel ryzyka Osoba odpowiedzialna za
zarządzanie ryzykiem (w odniesieniu do danego
ryzyka może istn ieć tylko j eden wlaściciel ryzyka).
• Wykonawca reakcji na ryzyko Osoba(-y) odpo-
wiedzialna(-e) za wykonania d ziałania lub dzia-
łań opisanych jako reakcja na ryzyko. Może (ale
nie musi) to być ta sama osoba, co właściciel
ryzyka.
A.25.3 Pochodzenie
• Zawartość, wymagany format i sposób pre-
zentacji Rejestru Ryzyk będzie si ę wywodzić ze
Strategii Zarządzania Ryzykiem.
• Wpisy są dokonywane do Rejestru Ryzyk zaraz
po zidentyfikowaniu nowego ryzyka.
• Zlecenie przygotowania projektu może zawierać
jedno lub więcej inherentnych ryzyk.
• Nowe ryzyka mogą zostać wykryte podczas two-
rzenia Założeń Projektu, projektowania i wyzna-
czania zespołu zarządzania projektem, ustalania
mechanizmów sterowania projektem i opraco-
wywania planów projektu, podczas wydawania
Grup Zadań, przeglądu statusu Grupy Zadań lub
przeg l ądu stanu etapu.
• Dziennik Projektu/Rejestr Zagadnień - zagad-
nienia zgłoszone Kierownikowi Projektu i zare-
jestrowane w Dzienniku Projektu lub Rejestrze
Zagadnień w rzeczywistości często są ryzykami
i są identyfikowane jako ryzyka dopiero po ich
dalszym przeanalizowaniu.
A.25.4Format i sposób przedstawienia
Rejestr Ryzyk może przybierać szereg formatów,
włączając w to:
• dokument, arkusz kalkulacyjny lub bazę danych;
• odrębny rejestr lub zapis w notatce z przeg lądu
postępów;
• wpis do narzędzia używanego do zarządzania
projektem;
• część zintegrowanego rejestru dla projektu obej-
mującego wszystkie ryzyka, działania, decyzje,
założenia, zagadnienia, doświadczenia itp.
Dodatek A: Zarysy Opisów Produktów I 277
A.25.5 Kryteria jakości
• Status wskazuje, czy działanie zostało podjęte .
• Ryzyka są jednoznacznie zidentyfikowane wraz
z informacją, którego produktu dotyczą.
• Dostęp do Rejestru Ryzyk jest kontrolowany i jest
on przechowywany w bezpiecznym miejscu.
A.26 GRUPA ZADAŃ
A.26.1 Przeznaczenie
Grupa Zadań jest zbiorem informacji o jednym lub
o większej liczbie wymaganych produktów, zebra -
nych przez Kierownika Projektu, w celu formalne-
go przeniesienia odpowiedzialności za wytworze-
nie lub dostawę produktu na Kierownika Zespo łu
lub członka zespołu .
A.26.2 Zawartość
Chociaż zawartość dokumentów może się bardzo
różnić,
w za l eżności od relacji pomiędzy Kierowni -
kiem Projektu a odbiorcą Grupy Zadań, to powinna
ona obejmować:
• Data Data uzgodnienia pomiędzy Kierowni-
kiem Projektu a Kierownikiem Zespołu/osobą
upoważnioną.
• Kierownik Zespołu łub osoba upoważniona
Nazwisko Kierownika Zespołu lub osoby, z którą
dokonano uzgodnienia.
• Opis Grupy Zadań Opis prac do wykonania.
• Techniki, procesy i procedury Wszelkie techni-
ki, narzędzia, standardy, procesy lub procedury,
które mają być zastosowane przy wytwarzaniu
produktów specjalistycznych.
• Punkty styku (interfejsy) w okresie wytwarza-
nia Kontakty, które muszą być utrzymywane
przy wytwarzaniu produktów. Mogą to być
osoby dostarczające informacji albo osoby, któ-
rym na l eży przekazywać informacje.
• Punkty styku (interfejsy) związane z eksploata·
cją i utrzymaniem Identyfikacja wszelkich pro-
duktów specjalistycznych, z którymi produkt(y)
z Grupy Zadań muszą współpracować w czasie
ich eksploatacji. Mogą to być inne produkty
wytworzone w tym samym projekcie, produkty
już istniejące czy też produkty, które wytworzo-
ne będą w innych projektach (np. gdy projekt
jest częścią programu).
• Wymagania zarządzania konfiguracją
Określenie wszelkich rozwiązań, które musi
wprowadzić wytwórca dla: kontroli wersji
278 I Dodatek A: Zarysy Opisów Produktów
produktów Grupy Zadań, uzyskiwania kopii
innych produktów lub ich Opisów Produktów,
poddawania produktów zarządzaniu konfigu-
racją, wszelkich wymagań dotyczących prze-
chowywania lub bezpieczeństwa oraz wyma-
gań związanych z informowaniem Wsparcia
Projektu o zmianach statusu Grupy Zadań.
• Uzgodnienia Szczególy dotyczące nakładów
pracy, kosztów, dat rozpoczęcia i zakończenia
oraz kluczowych kamieni milowych dla Grupy
Zadań.
• Tolerancje Szczególy dotyczące tolerancji okre-
ś l onych dla Grupy Zadań (tolerancje będą usta-
lone dla czasu i kosztów, ale mogą równi eż
obejmować zakres i ryzyko).
• Ograniczenia Wszelkie ograniczenia (oprócz
tolerancji) dotyczące pracy, zaa ngażowanych
osób, terminów, opłat, przestrzeganych zasad
(np. bezpieczeństwa i higieny) itp.
• Uzgodnienia dotyczące raportowania
Wymagana częstotl iwość i zawa rtość Raportów
z Punktów Kontrolnych.
• Sposoby obsługi i przekazywania problemów
Dotyczy to procedury zglaszania zagadnień
i ryzyk.
• Wyciągi lub odniesienia do dokumentów powią­
zanych Fragmenty lub odniesienia do innych
istotnych dokumentów, w szczególności:
• Wyciąg z Planu Etapu Będzie to odpowied-
nia część Planu Etapu dla bieżącego etapu
zarządczego lub odniesienie do niej.
• Opis(y) Produktów Będzie to zwykle zalą­
czony Opis(-y) Produktu(-ów) dla produk-
tów wymienionych w Grupie Zadań (należy
pamiętać, że Opis Produktu zawiera metody
dotyczące jakości, które mają być zastosowa-
ne).
• Metod a zatwierdzenia (odbioru) wykonanej
Grupy Zadań Osoba, rola lub grupa osób,
która będzie zatwi e rdzać (odbierać) uko ń czo­
ne produkty należące do Grupy Zada ń oraz
sposób powiadamiania Kierownika Projektu
o ukończen i u produktów i Grupy Zadań.
W Grupie Zadań powinno s i ę znaj dować miej-
sce na zarejestrowanie zarówno zezwolenia na
wykonanie Grupy Zadań, jak i jej akceptacji oraz
odbioru zakończonej Grupy Zadań. Może to być
rozszerzone o ocenę pracy i zbliżać się do oceny
efektywności .
Projekty ze wspólnymi mechanizmami sterowania
dla wszystkich Grup Zadań mogą po prostu zawie-
rać odniesienia do mechanizmów sterowania zdefi-
niowanych w Planie Projektu lub Planie Etapu.
A.26.3 Pochodzenie
• Istniejące umowy handlowe pomiędzy klientem
a dostawcą Geżeli istnieją).
• Strategia Zarządzania Jakością.
• Strategia Zarządzania Konfiguracją.
• Plan Etapu.
A.26.4 Format i sposób przedstawienia
Grupa Zadań może przybierać szereg formatów,
włączając w to:
• dokument;
• rozmowę Kierownika Projektu z Ki erownikiem
Zespoi u;
• wpis do n a rzędzi a używanego do zarzą d zan i a
projektem.
Grupy Zadań mogą mieć różn ą treść i stopi eń sfor-
malizowania w zależności od okoliczności.
Tam, gdzie prace są prowadzone przez zespół bez-
pośrednio kierowany przez Kierownika Projektu,
Grupa Zadań może być ustną instrukcją, ale mogą
istnieć ważne powody, by instrukcje te przekazać
pisemnie, chociażby dla uniknięcia nieporozumień
oraz umożliwienia dokonania oceny efektywno-
ści. W przypadku, gdy prace są prowadzone przez
dostawcę na podstawie kontraktu, a Kierownik Pro-
jektu należy do organizacji klienta, istnieje potrzeba
forma lnie zapisanej instrukcji, zgodnie ze standarda-
mi określ onymi w tym kontrakcie.
A.26.5 Kryteria jakości
• Wymagana Grupa Zada ń j est j asno zdefiniowana
i zrozumiala dla zasobów przydzielonych do j ej
wykonania.
• Istniej e Opis Produktu dla każdego wymaganego
produktu, wraz z jasno określ onym i i akcepto-
walnymi kryteriami jakości.
• Opis(-y) Produktu(-ów) są zgodne z pozostałą
dokumentacją Grupy Zadań.
• Standardy rea lizacji prac są uzgodnione.
• Zdefiniowane standardy są zgodne ze stosowa-
nymi dla podobnych produktów.
• Wszystkie konieczne punkty styku zostały okre-
ślone.

• Organizacja raportowania zawiera postanowie-
nia umożliwiające zglaszanie zagadnień i ryzyk.
• Kierownik Projektu i odbiorca Grupy Zadań usta-
lili dokladnie, co ma być wytworzone.
• Uzgodniono ograniczenia, w tym dotyczące
nakladów pracy, kosztów i terminów
docelowych.
Dodatek A: Zarysy Opisów Produktów I 279
• Terminy i naklady pracy są zgodne z tymi, które
zawarto w Planie Etapu dla bieżącego etapu
zarządczego.
• Ustalono organizację raportowania.
• Określono wymagania dotyczące obecności oraz
udziału osób niezależnych od wytwórcy w dzia-
laniach dotyczących jakości.
Dodatek B: Ład zarządzania projektami

Ład zarządzania projektami wiąże się z tymi obsza-
rami ładu korporacyjnego, które są szczegó lnie
powiąza ne z rea lizacją projektów. Efektywny ła d
za rząd zania projektami za pewnia, że portfel pro-
jektów organizacj i jest zgodny z celami organizacji,
sprawnie realizowany i zrównoważony. W spiera on
także środk i, za pomocą których zarzą d o rganizacji
oraz inni główni interesariusze projektu otrzymują
na czas wia rygodn e i istotne informacje.

Tabela 8.1 Zasady ładu zarządzania projektami stowarzyszenia Association for Project Management

Zasady ładu zarządzan i a projektami Czy uwzględn ione w PRINCE2?

Zarząd ponosi całkowi tą odpowiedzialno~ za lad zarządzania
projektami.
Role, zakresy obowiązków oraz kryteria oceny osiągnięć/wyników
dla ladu zarządzania projektami są jasno określone.
Przez caly okres trwania projektu stosowane są dyscyplinujące
Niniejsza zasada ładu odnosi się do naczelnego zarządu
organizacji i pozostaje poza zakresem PRINCE2.
Częściowo. Projekt ma jasno określone role, zakresy
obowiązków i odpowiedzialności oraz kryteria osiągnięć
dla ladu zarządzania projektami, ale PRINCE2 nie
obejmuje zakresów obowiązków dotyczących ladu
korporacyjnego dla ról w organizacji.
Całkowicie.

rozwiązania organizacyjne ladu zarządzania projektami wspierane

odpowiednimi metodami i mechanizmami sterowania.
Pomiędzy ogólną strategią biznesową a portfelem projektu istnieją Częściowo. Każdy projekt PRINCE2 powinien wykazywat.
spójne i wza1emnie wspieraiące się relacje. zgodność ze strategią organizacji za pomocą Uzasadnienia
Biznesowego. PRINCE2 nie dostarcza wskazówek
dotyczących zarządzania portfelem.
~------------- -----------'
Wszystkie projekty mają zatwierdzony plan, zawierający punkty
Całkowicie.
--'-------------
decyzyine, w których Uzasadnienie Biznesowe 1est przeglądane
i zatwierdzane. Decyzje podejmowane w tych punktach decyzyjnych
są rejestrowane i komunikowane.

Członkowie organów, którym przekazano uprawnienia do zarządzania Częściowo. PRINCE2 dostarcza ram dla skutecznego
strategicznego projektem, są wystarczająco reprezentatywni oraz mają delegowania uprawnień. Kompetencje takich osób
wystarczające kompetenqe, uprawnienia oraz zasoby umożliwiające uczestniczących w projekcie są poza zakresem PRINCE2.
im podejmowanie właściwych decyzji.
Uzasadnienie Biznesowe projektu oparte jest na istotnych Całkowicie.
i realistycznych informacjach, stanowiących solidną podstawę dla
podejmowania decyzji dotyczących zezwoleń.
Zarząd lub delegowani przedstawiciele decydują, kiedy wymagana Częściowo. PRINCE2 zaleca, aby niezależne przeglądy
jest niezależna weryfikacja projektów i systemów zarządzania organizowane przez zarząd organizacji czy programu byly
projektami, oraz odpowiednio ją przeprowadzają. częścią obowiązków Nadzoru Projektu.
'---'-----_.;,...---"'"""'---"----'-''------------'-
Istnieją jasno określone kryteria raportowania statusu projektu oraz Całkowicie.
-----"---------
przekazywania ryzyk i zagadnień na szaebłe wymagane przez organizację.
Organizacja promuje kulturę ulepszania oraz szczerego wewnętrznego Częściowo. PRINCE2 zachęca do otwartego raportowania,
ujawniania informacji projektowych. wykorzystując do tego zarządzanie sytuacjami
nadzwyaajnymi oraz struktury nadzoru.
- - - - - - - - - - Ca
-Ikowicie.
lnteresariusze projektu zaangażowani są na poziomie odpowiadającym
ich znaczeniu dla organizacji oraz w sposób promujący zaufanie.
----
Źródło - Directing Change: A Guide to Governance of Project Management (edycja z małym i zmianami
2005), APM Governance SIG. © Association f or Project M anagement , 2004. Przedruk za zgodą.
284 I Dodatek B: Ład zarządzania projektami

Metodyka PRINCE2 dostarcza {o ile stosowana jest

zgodnie z duchem swoich zasad) ramy dla efektyw-
nego ładu zarządzania projektami. Tabela B.1 poka-
zuje jak PRINCE2 uwzględnia zasady ładu opubliko-
wane przez Association for Project Management.
Dodatek C: Role i obowiązki
C.1 KOMITET STERUJĄCY
Komitet Sterujący odpowiada przed kierownictwem
organizacji lub programu za pomyślną realizację
projektu i posiada uprawnienia do zarządzania stra-
tegicznego projektem w zakresie określonym przez
to kierownictwo zgodnie ze zleceniem przygotowa-
nia projektu.
Komitet Sterujący odpowiedzialny jest równ i eż za
komunikację pomiędzy zespołem za rządza n ia pro-
jektem a interesariuszami spoza tego zespolu
(np. kierownictwem organizacji lub programu).
Zależni e od skali, złożoności, znaczenia oraz ryzyka
projektu, członkowi e Komitetu Sterującego mogą
delegować niektóre zadania Nadzoru Projektu
innym osobom. Komitet Steruj ący może tak że
de l egować uprawnienia do podejmowania decyzji
o zmianach Obsłudze Zmian.
C.1.1 Obowiązki
w czasie przygotowania i inicjowania projektu:
• Uzgodnić tolerancje projektu z kierownictwem
organizacji lub programu.
• Zatwierdzić Założenia Projektu.
• Zatwierdzić Planu Etapu dla etapu inicjowania.
• Wydać zezwolenie na zainicjowanie projektu.
• Podjąć decyzję czy będzie ustanowiona Obsluga
Zmian oraz, jeśli tak będzie, uzgodnić zakres
delegowanych uprawnień.
• Ustalić skalę dla oceny wagi/znaczenia zagadnień.
• Usta lić skalę dla oceny priorytetu dla wniosków
o wprowadzenie zmiany i odstępstw.
• Zatwierdzi ć umowę z dostawcą Ueże l i relacja
pom i ędzy klientem a dostawcą ma charakter
komercyjny).
• Zatwi erdzić Dokumentację Inicjowania Projektu
(i jej elementy składowe).
• Wydać zezwolenie na rea l izację projektu.
W trakcie realizacji projektu:
• Ustalić tolerancje dla każdego etapu oraz
zatwierdzić Plany Etapów.
• Wydać zezwolenie na realizację każdego etapu
zarządczego oraz zatwierdzić związane z nim
Opisy Produktów.
• Zatwierdzić Plany Nadzwyczajne w przypadku
przewidywanego przekroczenia tolerancji na
poziomie etapu.
• Komunikować się z interesariuszami w sposób
określony w Strategii Zarządzania Komunikacją
(ląc.znie z informowaniem kierownictwa organi-
zacji lub programu o postępach projektu).
• Dostarczać ogólnych wytycznych oraz ukierunko-
wywać projekt zapewniając zasadność j ego real i-
zacji oraz utrzymanie w określ onych granicach.
• Odpowiada ć na prośby Kierownika Projektu
o wytyczne.
• Zapewnić, żeby ryzyka podlegaly monitorowan iu
i byly zarządza ne tak efektywnie, j ak to możl iwe
w warunkach danego projektu.
• Zatwierd zać zmiany (o ile tego nie delegowano
Obsludze Zmian).
• Podejmować decyzje na temat zagadnień prze-
kazanych Komitetowi Sterującemu.
• Zatwierdzić ukończone produkty.
Na końcu projektu:
• Nadzorować prawidłowość dostarczenia wszyst-
kich produktów.
• Nadzorować spełnienie wszystkich kryteriów
akceptacji.
• Potwierdzić akceptację Produktu Końcowego
Projektu.
• Zatwierdzić Raport Końcowy Projektu i zapew-
nić, że wszelkie zagadnienia, doświadczenia oraz
ryzyka są udokumentowane oraz przekazane
odpowiedniemu organowi.
• Zezwol i ć na przekazanie za l eceń dzialań n astęp­
czych oraz Raportów Doświ adczeń kierownictwu
organizacji lub programu.
• Przekazać odpowi edzia lność za zaktualizowany
Plan Przeglądu Korzyści kierowni ctwu organiza-
cj i lub programu.
• Zezwo l ić na zamykanie projektu oraz przesłać
powiadomienie o zamykaniu projektu kierownic-
twu organizacji lub programu.
288 I Dodatek C: Role i obowiązki
C.1.2 Kompetencje
Aby odnieść sukces, Komitet Sterujący powinien:
• Posiadać wystarczające uprawnienia do podej-
mowania decyzji, zatwierdzania planów oraz
wydawania zezwo l eń w przypadku koniecznych
odchyl eń od Planów Etapów.
• Posi adać wystarczające uprawnienia do przydzie-
lania zasobów do projektu.
• Posi adać zdolność właściwego reprezentowania
interesów biznesu, użytkownika i dostawcy.
• W idealnych warunkach móc pozostawać w pro-
jekcie przez cały jego czas trwania.
Kluczowe kompetencje obejmują:
• Podejmowanie decyzji.
• Delegowanie.
• Przywództwo.
• Negocjacje i rozwiązywanie konfliktów.
C.2 PRZEWODNICZĄCY
Przewodniczący ponosi ostateczną odpowiedzial-
ność za projekt, będąc wspierany przez Głównego
Użytkownika oraz Głównego Dostawcę. Rolą Prze-
wodniczącego jest zagwarantowanie, że projekt
koncentruje się przez cały czas swego trwania na
osiągan iu zamierzonych celów oraz na dostarczeniu
produktu, który przyniesie przewidywane korzyści .
Przewodniczący musi zapewnić, że projekt wytwo-
rzy wartość odpowiednią do poniesionych nakla-
dów, poprzez taki sposób realizacji projektu, który
opiera się na świadomości kosztów i zachowuje
równowagę pomiędzy wymaganiami biznesu, użyt­
kownika i dostawcy.
Przez caly czas trwania projektu Przewodniczący
odpowiedzialny jest za Uzasadnienie Biznesowe.
Komitet Sterujący nie jest organem demokratycz-
nym, w którym decyzje podejmuje się większością
głosów. Przewod niczący podejmuje ostateczne decy-
zje i przy ich podejmowaniu jest wspierany przez
Głównego Użytkownika i Głównego Dostawcę.
C.2.1 Obowiąz ki
Poza zbiorowymi obowiązkami Komitetu Sterujące­
go, Przewodniczący powinien:
• Wyznaczyć i mianować
zespól zarządzania pro-
jektem (w szczególności Kierownika Projektu).
• Nadzorować opracowanie Zalożeń Projektu oraz
zarysu Uzasadnienia Biznesowego, zapewniając
zgodność projektu ze strategią organizacji (oraz,
kiedy to konieczne, przedstawić kierownictwu
organi zacji lub programu zarys Uzasadnienia
Biznesowego do zatwierdzenia).
• N adzorować opracowanie szczegółowego
Uzasadnienia Biznesowego.
• Zapewn i ć f inansowanie dla projektu.
• Zatwierdzić wszelkie dodatkowe umowy
z dostawcami (o ile relacja pomiędzy klientem
a dostawcą ma charakter komercyjny).
• Przekazać Głównemu Dostawcy odpowiedzial-
ność za jakość i integralność podejścia specja-
listycznego oraz produktów specjalistycznych
wytwarzanych dla projektu.
• Przekazać G łównemu Użytkownikowi odpo-
wiedzia l ność za real izację korzyści określ onych
w Uzasadnieniu Biznesowym, zobowiązując go
do dokonywania przeglądów korzyści w celu
monitorowania stopnia osi ągnięcia korzyści
przedstawionych w Uzasadnieniu Biznesowym.
• Przekazać odpowiedzialność za poprojektowe
przeglądy korzyści kierownictwu organizacji lub
programu.
• Monitorować i kontrolować postępy projek-
tu na poziomie strategicznym, w szczególności
regularni e dokonując przeglądu Uzasadnienia
Biznesowego.
• Przekazywać zagadnienia i ryzyka na szczebel
ki erownictwa organizacji lub programu, jeżeli
przewidywane jest przekroczenie tolerancji.
• Zapewnić, żeby ryzyka związane
z Uzasadnieniem Biznesowym były identyfikowa-
ne, oceniane i kontrolowane.
• Podejmować decyzje w sprawie przekazanych
zagadnień, zwracając szczególną uwagę na cią­
głą zasadność biznesową projektu.
• Organizować i przewodniczyć posiedzeniom
Komitetu Steruj ącego.
• Zapewnić całościowy nadzór biznesowy nad
tym, czy projekt zgodnie ze swoim celem
dostarczy produkty, które przyniosą oczekiwa-
ne korzyści biznesowe oraz że zostanie ukoń­
czony w ramach uzgodnionych tolerancji. Gdy
jest to właściwe, delegować niektóre działania
Nadzoru Projektu ze strony biznesu (patrz C. 7).
C.3 GŁÓWNY UŻYTKOWNIK
Główny Użytkownik(-cy) odpowiedzialny jest za
określenie potrzeb tych, którzy będą wykorzysty-
wać produkty proj ektu, za kontakty użytkowników

z zespołem zarządzania projektem oraz za monito-
rowanie tego, aby dostarczone rozwiązanie spełni ło
te potrzeby w ramach ograniczeń wynikających
z Uzasadnienia Biznesowego w kategoriach jakości,
funkcjona l ności i łatwości użytkowa nia.
Rola ta reprezentuje interesy tych wszystkich, któ-
rzy korzystać będą z produktów proj ektu (łącznie
z eksploatacją i utrzymaniem), tych, którym pro-
dukt umożliwi osiągnięcie ich celu lub tych, którzy
będą wykorzystywali produkty d o dostarczania
korzyści biznesowych. Rola Głównego Użytkownika
udostępnia zasoby użytkownika i monitoruje spel-
nianie wymagań przez produkty projektu. Może
ona wymagać udziału większej liczby osób w celu
uwzględn i enia wszystkich interesów użytkowników,
ale, przez wgląd na efektywność, rola ta nie powin-
na być podzielona pomiędzy zbyt wiele osób.
Główny Użytkownik(-cy) określa korzyści
oraz odpo-
wiada za wykazanie kierownictwu organizacji lub
programu, że przewidywane korzyści, które były
podstawą do zatwierdzenia projektu, zostaly fak-
tycznie uzyskane. Może się to wiązać z angażowa­
niem si ę Głównego Użytkownika także po zakoń­
czeniu projektu.
C.3.1 Obowiązki
Poza zbiorowymi obowiązkami Komitetu Sterują ­
cego, Główny Użytkownik powinien:
• Dostarczyć oczekiwania jakościowe klienta oraz
okreś l ić kryteria akceptacji dla projektu.
• Zapewnić istnienie specyfikacji pożądanego
rezu ltatu projektu.
• Zagwarantować, że projekt wytwarza produkty,
które dostarczą pożądanych rezultatów i spełnią
wymagania użytkownika.
• Zapewnić, że uzyskuje się oczekiwane korzyści
(wywodzące się z rezu ltatów projektu).
• Przedstawić na przeglądach korzyści zestawienie
korzyści faktycznych w porównaniu z przewidy-
wanymi.
• Rozwiązywać konflikty dotyczące wymagań
i priorytetów użytkown ików.
• Zagwarantować, że udostępniane są wszelkie
zasoby użytkownika niezbędne dla projektu
(np. w celu przeprowadzania kontroli jakości
przez użytkownika czy zatwierdzenia produktu).
• Podejmować decyzje dotyczące przekazanych
zagadnień, ze szczególnym skoncentrowaniem
się na zabezpieczaniu oczekiwanych korzyści.
Dodatek C: Role i obowiązki I 289
• Informować oraz doradzać kierownictwu użyt­
kownika we wszystkich sprawach dotyczących
projektu.
• Utrzymywać stabilność efektywności biznesowej
w trakcie przechodzenia od projektu do stanu
zwykłej działalności biznesowej.
• Prezentować punkt widzenia użytkownika na
temat za l eceń dz iałań następczych.
• Sprawować Nadzór Projektu z perspektywy
użytkownika {nadzór ze strony użytkownika)
oraz tam, gdzie to właściwe, delegować dzia-
łania Nadzoru Projektu ze strony użytkownika
(patrz C. 7).
C.4 GŁÓWNY DOSTAWCA
Główny Dostawca reprezentuje interesy tych, którzy
projektują, wytwarzają, wspomagają, zaopatrują
oraz wdrażają produkty projektu. Rola ta jest odpo-
wiedzialna za jakość produktów dostarczanych
przez dostawcę(-ów) oraz za techniczną integra ln ość
projektu. W razie konieczności, dostawców może
reprezentować więcej niż jedna osoba.
W zależności od konkretnego środowiska klient/
dostawca, klient może także chcieć mianować nieza-
leżną osobę czy grupę do sprawowani a nadzoru nad
produktami dostawcy {na przyklad w przypadku,
gdy relacja pomięd zy klientem a dostawcą ma cha-
rakter komercyjny).
C.4.1 Obowiązki
Poza zbiorowymi obowiązkami Komitetu Sterują­
cego, Główny Dostawca powinien:
• Ocenić
i potwierdzić zasadność formuly realizacji
projektu.
• Zapewnić, że propozycje dotyczące projektowa-
nia i wytwarzania produktów są realistyczne.
• Doradzać na temat wyboru metod projektowa-
nia, wykonywania oraz akceptacji.
• Zagwarantować, że udostępniane są wszelkie
zasoby dostawcy niezbędne dla projektu.
• Podejmować decyzje dotyczące przekazanych
zagadnień, ze szczególnym skoncentrowaniem
się na zabezpieczaniu integralności kompletnego
rozwiązan ia.
• Rozwiązywać konflikty dotyczące wymagań
i priorytetów dostawców.
• Informować ki erownictwo, które może nie m i eć
dogłębnej wiedzy technicznej, o aspektach pro-
jektu dotyczących obszaru dostawcy.
290 I Dodatek C: Role i obowiązki
• Zagwarantować, że procedury jakościowe są pra-
widłowo stosowane tak, by produkty odpowia-
dały wymaganiom.
• Sprawować Nadzór Projektu z perspektywy
dostawcy (nadzór ze strony dostawcy) oraz tam,
gdzie to właściwe, delegować dzi ałania Nadzoru
Projektu ze strony dostawcy (patrz C.7).
C.5 KIEROWNIK PROJEKTU
Kierownik Projektu posiada uprawnienia dobieżą­
cego prowadzenia projektu w imieniu Komitetu Ste-
rującego, w ramach ograniczeń określonych przez
ten Komitet.
Podstawowym obowiązkiem Kierownika Projektu
jest zagwarantowanie, by projekt wytwarzał wyma-
gane produkty w ramach określonych tolerancji
czasu, kosztów, jakości, zakresu, ryzyka i korzyści.
Kierownik Projektu jest także odpowiedzialny za to,
by projekt wytworzył rezultat, który będzie w stanie
zapewnić osiągnięcie korzyści określonych
w Uzasadnieniu Biznesowym.
C.5.1 Obowiązki
W ramach swoich obowiązków Kierownik Projektu
powinien:
• Przygotować następujące bazowe produkty
zarządcze (obiekty odniesienia), współpracu­
jąc z wszelkimi rolami Nadzoru Projektu, oraz
uzgodnić je z Komitetem Sterującym:
• Założenia Projektu, obejmujące Opis
Produktu Końcowego Projektu,
• Plan Przeglądu Korzyści,
• Dokumentację Inicjowania Projektu (i jej
elementy składowe),
• Plany Etapów/Nadzwyczajne i Opisy
Produktów wytwarzanych w ich ramach,
• Grupy Zadań;
• Sporządzać następujące raporty:
• Raporty Okresowe,
• Raporty o Zagadnieniach,
• Raporty Końcowe Etapów,
• Raporty Doświadczeń,
• Raporty Nadzwyczajne,
• Raport Końcowy Projektu;
• Utrzymywać następujące zapisy:
• Rejestr Zagadnień,
• Rejestr Ryzyk,
• Dziennik Projektu,
• Dziennik Doświadczeń.
• Utrzymywać kontakt z kierownictwem organiza-
cji łub programu, aby zapewnić, że żadne prace
nie zostaną pom i nięte ani nie zostaną wykonane
ponownie przez pokrewne projekty.
• Utrzymywać kontakty z zewnętrznymi dostaw-
cami lub osobami zarządzającymi relacjami
z klientem.
• Przewodzić i motywować zespół zarządzania
projektem.
• Zapewnić, że określone zostały oczekiwania
dotyczące zasad funkcjonowania członków
zespołu.
• Zarządzać przepływami informacji pomiędzy
poziomem za rządzan ia strategicznego i pozio-
mem dostawczym/wytwórczym projektu.
• Zarządzać wytwarzaniem wymaganych produk-
tów, przyjmując odpowiedzia lność za całościowe
postępy i wykorzystanie zasobów oraz, gdy to
konieczne, inicjować działania korygujące.
• Ustanowić i zarządzać procedurami projektu,
takimi, jak zarządzenie ryzykiem, sterowanie
zagadnieniami i zmianami, zarządzanie konfigu-
racją oraz komunikacją.
• Ustanowić i zarządzać mechanizmami sterowa-
nia projektem - monitorowanie i raportowanie.
• Zezwa l ać na wykonanie Grup Zadań .
• Powiadamiać Komitet Sterujący o wszelkich
odchyleniach od p lanu.
• O ile nie została mianowana inna osoba(-y), peł­
nić rolę Kierownika Zespołu (patrz C.6).
• O ile nie została mianowana inna osoba (łub
funkcja na poziomie organizacji/programu), peł­
nić rolę Wsparcia Projektu (patrz C.9).
• Wdrażać Strategię Zarządzania Konfiguracją.
• Zagwarantować, że personel działa zgodnie ze
Strategią Zarządzania Konfiguracją.
• Planować audyty konfiguracji, aby sprawdz i ć,
że materialne produkty zgodne są z Zapisami
Obiektów Konfiguracji oraz inicjować wszelkie
konieczne działania korygujące.
C.5.2 Kompetencje
Różne rodzaje projektów wymagać będą różnych
rodzajów umiejętności zarządzania projektem.
Aby odnieść sukces, Kierownik Projektu musi umieć
odpowiednio wyważyć różne aspekty swojej roli na
potrzeby konkretnego projektu.

Kluczowe kompetencje obejmują:
• Planowanie. czasem .
• Zarządzan ie
• Zarządza n ie
personelem .
• Rozwiązywan i e
problemów.
• Skrupu l atność
. utrzymuj ącej Rejestr Zagadnień.
• Negocjacje. .
Kom unikacj ę
• C.6.2 Kompetencje
• Zarządzanie
konfliktami.
C.6 KIEROWNIK ZESPOŁU
Podstawowym obowiązkiem Kierownika Zespołu
jest zagwarantowanie wytworzenia okreś l onych
przez Kierownika Projektu produktów o odpowied-
niej j akości, w określ onym terminie i po kosztach
akceptowalnych dla Komitetu Steruj ącego. Kierow -
nik Zespolu podlega Kierownikowi Projektu i przyj-
muje od niego instrukcje.
C.6.1 Obowiązki
• Przygotować Planu Zespołu oraz uzgodnić go
z Kierownikiem Projektu.
• Sporządzać Raporty z Punktów Kontrolnych
wed ług uzgodnień z Ki erownikiem Projektu.
• Planować, monitorować i zarządzać pracami
zespołu .
• Ponosi ć odpowiedzi alność za postę py prac zespo-
łu i wykorzystanie zasobów zespołu oraz inicjo-
wać dzi ała nia korygujące, gdzie jest to koniecz-
ne, w ramach ograniczeń nałożonych przez
Kierownika Projektu.
• Identyfikować wszelkie zagadnienia i ryzyka
związane z Grupą Zadań oraz informować o nich
Kierownika Projektu.
• I nformować Kierownika Projektu o wszelkich
odchyleniach od planu, rekomendować dz i ała­
nia koryg ujące oraz pomagać w przygotowaniu
odpowiednich Planów Nadzwyczajnych.
• Przekazywać Kierownikowi Projektu produkty
ukończone i zatwierdzone zgodnie z ustalonymi
wymaganiami Grupy Zadań.
• Współpracować z osobami pełniącymi role
Nadzoru Projektu i Wsparcia Projektu.
• Zapewnić, że działania dotyczące jakości odno-
szące się do pracy zespołu są prawidłowo plano-
wane i przeprowadzane oraz mieszczą się w gra-
nicach tolerancji.
• Zapewnić, żeby dokonywano odpowiednich wpi-
sów w Rejestrze Jakości.
Dodatek C: Role i obowiązki I 291
• Zarządzać konkretnymi zagadnieniami i ryzyka -
mi zgodnie z poleceniami Kierownika Projektu.
• Pomagać Kierownikowi Projektu w ocenie
zagadn ień i ryzyk.
• Zapewn i ć, żeby wszystkie przypisane mu zagad -
nienia byly odpowiednio raportowane osobie
Różne rodzaje projektów będą wymagały od Kierow-
nika Zespołu różnych rodzajów umiejętności.
Kluczowe kompetencje są podobne do kompetencji
Kierownika Projektu.
C.7 NADZÓR PROJEKTU
Nadzór Projektu obejmuje podstawowe interesy
interesariuszy projektu (biznesu, użytkownika
i dostawcy).
Nadzór Projektu musi być niezależny od Kierownika
Projektu, wobec czego Komitet Sterujący nie może
delegować Kierownikowi Projektu żadnych ze swo-
ich działań nadzorczych.
C.7.1 Obowiązki
Wypełnianie obowiązków nadzorczych wymaga
odpowiedzi na pytanie: „co ma być nadzorowane?"
Li sta możliwości maj ących zastosowanie w odniesie-
niu do interesów biznesu, użytkownika i dostawcy
mogłaby obejmować zapewnienie, że:
• Przez cały czas trwania projektu istnieje współ­
praca pomiędzy biznesem, użytkownikiem
i dostawcą.
• Ryzyka są kontrolowane.
• Właściwe osoby są zaangażowane w tworzenie
Opisów Produktów.
• Zaplanowano zaangażowanie właściwych osób
do kontroli ja kości we właściwych momentach
wytwarzania produktu.
• Personel j est właściwie przeszkolony w zakresie
metod zapewnienia/kontroli ja kości.
• Metody zapewnienia/kontroli jakości są właści­
wie realizowane.
• Działania następcze, wynikające z kontroli jako·
ści, są prawidłowo wykonywane.
• Realizowane rozwiązanie jest możliwe do zaak-
ceptowania.
• Zakres projektu nie rozszerza się niepostrzeżenie.
292 I Dodatek C: Role i obowiązki
• Zadawa l ająco funkcjonuje komunikacja
wewnętrzna i zewnętrzna.
• Stosowane są wlaściwe standardy.
• Spełniane są specjalistyczne wymagania (na przy-
kład bezpieczeństwa).
Obowiązki nadzoru ze strony biznesu:
• Wspomagać Kierownika Projektu w opracowy-
waniu Uzasadnienia Biznesowego oraz Planu
Przeglądu Korzyści (o ile plan ten jest przygoto-
wywany przez Kierownika Projektu).
• Doradzać w sprawie wyboru członków zespołu
zarządzania projektem.
• Doradzać w sprawie Strategii Zarządzania
Ryzykiem.
• Przeglądać Uzasadnienie Biznesowe pod kątem
j ego zgodności ze standardami organizacji lub
programu.
• Weryfikować Uzasadnienie Biznesowe w zesta-
wieniu z wydarzeniami zewnętrznymi oraz
postępam i projektu.
• Sprawdzać czy przez cały czas trwania projektu
przestrzegane jest Uzasadnienie Biznesowe.
• Sprawdzać, czy projekt zgodny jest z ogólną stra-
tegią organizacji lub programu.
• Przeglądać finanse projektu w imieniu klienta.
• Weryfikować, czy przyjmowane rozwiązania
nadal dostarczają wartości odpowiedniej do
poniesionych kosztów.
• Okresowo sprawdzać, czy kontynuowanie pro-
jektu jest nadal zasadne.
• Oceniać, czy zagregowana ekspozycja na ryzyko
pozostaje w granicach tolerancji projektu.
• Sprawdzać, czy są zatwierdzone wszelkie płatno­
ści na rzecz dostawców czy kontrahentów.
• Przeglądać zagadnienia oraz ryzyka dokonując
oceny ich wplywu na Uzasadnienie Biznesowe.
• Ograniczać nadmierne żądania użytkownika
i dostawcy.
• Informować zespół zarządzan i a projektem
o wszelkich zmianach spowodowanych progra-
mem, którego projekt jest części ą (obowiązek
ten może zostać przeniesiony, jeżel i w zespole
zarządzan ia projektem ktoś inny jest przedstawi-
cielem programu).
• Monitorować postępy realizacji etapów oraz
projektu w odniesieniu do uzgodnionych
tolerancji.
Obowiązki nadzoru ze strony użytkownika:
• Doradzaćw sprawie zaangażowania interesariuszy.
• Doradzać w sprawie Strategii Zarządzania
Komunikacją.
• Zapewnić, że określenie potrzeb użytkownika
jest dokładne, pełne i jednoznaczne.
• Ocenić czy rozwiązanie spełni wymogi użytkow­
nika i prowadzi do osiągnięcia celu.
• Informować o wpływie potencjalnych zmian
z punktu widzenia użytkownika.
• Monitorować ryzyka mogące dotknąć użytkow­
nika.
• Zapewn i ć, żeby wszelkie dzia łania przeg l ądu/
kontro li ja kości, związane z produktami na
wszystkich etapach, mialy odpowiednie przedsta-
wicielstwo ze strony użytkown ika.
• Zagwa rantować, że procedury kontroli jakości są
prawidlowo stosowane w celu zapewnienia speł­
nienia wymogów użytkownika przez produkty.
• Zapewn i ć efektywną wspólpracę z użytkowni-
kiem.
Obowi ązki nadzoru ze strony dostawcy:
• Przeglądać Opisy Produktów.
• Doradzać w sprawie Strategii Zarządzania
Jakością oraz Strategii Zarządzania Konfiguracją.
• Doradzać w sprawie wyboru strategii wytwarza-
nia produktów, zasad projektowania/konstru-
owania i użytych metod.
• Zagwarantować, że wszelkie standardy dostawcy
i operacyjnego wykorzystania produktów okre-
ślone dla projektu są przestrzegane i efektywnie
stosowane.
• Opiniować z perspektywy dostawcy potencjalne
zmiany i ich wplyw na prawidlowość, komplet-
ność i integra l ność produktów w odniesieniu do
ich Opisów Produktów.
• Monitorować wszelkie ryzyka w aspektach
wytwórczych proj ektu.
• Ocenić, czy procedury kontroli jakości są prawi-
dłowo stosowane tak, aby produkty spel niały
stosowne wymagania.
C.7.2 Kompetencje
Aby odnieść sukces, Nadzór Projektu powinien:
• Być w stanie odpowiednio reprezentować intere-
sy biznesu, użytkownika lub dostawcy.
• Posiadać wystarczającą wiarygodność, aby
zagwarantować, że przestrzegane będą jego
rady i wytyczne/wskazówki.

• Posiadać wystarczającą wiedzę specjalistyczną
o obszarach dotyczących biznesu, użytkownika
Iub dostawcy.
• W idealnej sytuacji powinien być w stanie uczest-
n i czyć w projekcie przez cały okres j ego trwania.
Kluczow e kompetencj e obejmują :
• Dyp l omacj ę.
• Dokładność.
• Skrupulatność.
• Komunikację.
C.8 OBSŁU GA ZMIAN
Komitet Steruj ący może del egować uprawnienia do
zatwierdzania wniosków o wprowadzanie zmiany
czy od stępstw pojedynczej osobie lub grupie nazy-
w anej Obslugą Zmian. Kierownik Projektu może
być wyznaczony jako Obsluga Zmian dla n iektórych
aspektów projektu (np. zmi any zatwierdzonych
Grup Zadań, o ile nie wplywa to na tolerancje
etapu).
C.8.1 Obowiązki
• Przeglądać i zatwierdzać lub odrzucać wszystkie
wnioski o wprowadzenie zmian oraz odstępstwa
w ramach delegowanych uprawn i eń oraz budże­
tu zmian ustalonego przez Komitet Sterujący.
• Zwracać si ę do Komitetu Sterującego, jeżeli prze-
widywane jest przekroczenie ram delegowanych
uprawnień lub przyznanego budżetu zmian.
C.8.2 Kompetencje
Obsluga Zmian powinna:
• Być w stanie odpowiednio reprezentować intere-
sy biznesu, użytkownika czy dostawcy.
• Posiadać wystarczającą wiarygodność, aby
zagwarantować, że przestrzegane będą jej rady
i wytyczne/wskazówki.
• Posiadać wystarczającą wiedzę specj al i styczną na
temat biznesu, użytkown i ka czy dostawcy.
Kluczowe kompetencje obejmują:
• Podejmowanie decyzji.
• Planowanie.
• Skrupulatność.
• Rozwiązywanie problemów.
Dodatek C: Role i obowiązki I 293
C.9 WSPARCIE PROJEKTU
Zapewnienie jakiegokolwiek Wsparcia Projektu nie
jest obowiązkowe z forma lnego punktu widzenia.
Jeże l i zadania Wsparcia Projektu nie zostaly delego-
wane konkretnej osobie czy jednostce funkcjonal-
nej, wype lniać je będ zie Kierownik Projektu.
Jedną z funkcji wspierających, którą trzeba wziąć
pod uwagę, jest zarządzan ie konfigu racją. W za leż­
ności od rozmiarów i środowiska projektu, może
zaistnieć potrzeba sformalizowania tej funkcji
i może się to stać zadaniem, z którym Kierownik
Projektu nie poradzi sobie sam bez wsparcia.
Funkcje Wsparcia Projektu może pelnić Biuro Pro-
jektu lub osoby specjalnie wyznaczone dla proj ek-
t u. W celu uzyskania dalszych informacji na temat
wykorzystania Biura Projektu, należy się odwolać do
wytycznych OGC Portfolio, Programme and Project
Support Offices (2008).
C.9.1 Obowiązki
Poniższa lista jest spisem sugerowanych zadań:
• Zalożyć i utrzymywać dokumentację projektu.
• Ustanowić procedury kontroli dokumentów.
• Zbierać faktyczne dane oraz prognozy.
• Uaktualniaćplany.
• Przeprowadzać lub wspierać proces przeglądu
jakości.
• Adm inistrować lub wsp i erać posiedzenia
Komitetu Steruj ącego.
• Pomagać w opracowywaniu raportów.
• Udostępniać wi edzę na temat specjalnych
narzędzi i technik (na przyklad narzędzi do
planowania i kontroli, analizy ryzyka).
• Utrzymywać następujące zapisy.
• Rejestr Jakości;
• Zapisy Obiektów Konfiguracji;
• wszystkie inne rejestry/dzienniki delegowane
przez Kierownika Projektu.
• Administrować proced u rą zarządzania konfi-
guracją (obowi ązki te może pełn ić bibliotekarz
konfiguracji pochodzący ze strony kierownictwa
organizacji lub programu), a w szczególności:
• Administrować przyjęciem, identyfikacją,
wersjami, przechowywaniem oraz wydawa-
niem wszystkich produktów projektu.
• Dostarczać informacje na temat statusu
wszystkich produktów (przygotowując
i wydając Zestawienia Statusu Produktów).
294 I Dodatek C: Role i obowiązki

• Archiwizować kopie produktów, które zostały

zastąpione przez kolejne uaktualnienie.
• Zapewnić bezpieczeństwo i ochronę orygina-
łów wszystkich produktów projektu.
• Utrzymywać rejestr wszystkich wydanych
kopii.
• Powiadamiać posiadaczy o wszelkich zmia-
nach w ich kopiach.
• Numerować, zapisywać, przechowywać i dys-
trybuować Raporty o Zagadnieniach.
• Przeprowadzać audyty konfiguracji.

C.9.2 Kompetencje
Typowe kompetencje dla ról Wsparcia Projektu
za l eżeć będą od rodzaju projektu i organizacji.

Klu czowe kompetencje obejmują:

• Adm i n i stracj ę
i organizację.
• Znajomość specjalistycznych narzędz i i technik.
• Znajomość standardów zarządczych organi-
zacji lub programu mających zastosowanie
w projekcie.
Dodatek D: Przykład planowania opartego
na produktach
D.1 SCENARIUSZ riały konferencyjne dla stu uczestników. Okładka tych
materiałów musi nawi ązywać do wybranego tematu
Projekt ma zorgan i zować i przeprowadzić konferen- konferencji. Materiały te muszą zawierać wydruko-
cję d la 80 - 1OO uczestników. Otrzymano ustalenia wany program konferencj i, kopie slajdów i notatek
dotyczące terminu oraz wybranego tematu konfe- używanych przez prelegentów oraz nawiązujący do
rencji. Głównym celem konferencji jest aktualizacja programu arkusz oceny, służący do zebrania opinii
wiedzy osób wykonujących pewną profesję na temat uczestników. Przed wysłaniem pocztą listów rekla-
niedawnych zmian w procedurach i standardach ich mowych do potencjalnych uczestników, należy ustalić
profesji. Konferencja odbywać si ę będzie w miej- zasady rezerwacji, uzgodnić program, wybrać i zare-
scu, które trzeba dopiero wybrać, sprawdzić jego zerwować miejsce konferencji. Po zarezerwowaniu
dostępność, infrastrukturę i udogodnienia oraz lokalu, t rzeba będzie przygotować i wydrukować
cenę, a następnie zarezerwować. Uczestnikami będą komunikat prasowy nawiązujący do programu kon-
wyłącznie osoby wykon uj ące dany zaw ód i d latego ferencji. Po wydrukowan iu komunikatu i wysłaniu
można skorzystać z istniejącej listy adresowej. N a leży pocztą listu reklamowego konferencji, lista uczestni-
wybrać odpowiednich prelegentów, skontaktować ków zostanie zaktualizowana na podstawie napły­
się z nimi i zaangażować ich. Po zaangażowaniu pre- wających zgłoszeń uczestnictwa. Po zamknięciu listy
legentów, należy ułożyć szczegółowy harmonogram uczestników, trzeba będzie również zatrudnić perso-
i program konferencji. Potrzebne będą także mate- nel jednodniowy do obsługi konferencji.

Konferencja

I
/ 1
....,
Oołwladc1tn11
5 Mnterlały dla 6 Logi.styka
2 Uczes-tnky 3 Pfelegcncl 4Rełcl ~ma I 1n•te1l•ly
1 Mlej~ce vcz.estnlków konfecencji i f)OPI ttdnlc:h
Ońltlłftc.J!ł

6.1 ......,

- 1.1
~.adl.a
tnitp<.a
2. 1
..,.,_.
\l<U

~
l.I
Po1encjalnl
Pftlegend
4.1

""
łt':l.amowy
S. I
~lołdki .......
Wybfor'f

koni•«•><!,,

...., .., ....,

-
/

- ..........
1.2

mit;K•
2.2
l~tnl•
UUC1tniaw.a

~
l.2
laprOSlenla dl.ł
prfltgentów
4.2
„..,.,...
Not•lł:•
S.2
Vłydrułiow•ny
Pf09fłm
U<talo<>y
ttrMin

- 1.l
O<eny
miej«

„.
2.l
Zauidy
rezerwa(jl
) .)
Za.a~atowanl
P't egend
- S.l
Slajdy
I notatki
- 6.l
Uzgodniony
ptogram

M!tjKe wybrane
i ZłltltlWOWłlńt
2A
~lłlt(lf'lł 11\ll
ua.11tnlk6w - s.•
FCHmuł.ari
an\iety - 6.•
Personel
jednodniowy

Rysunek o. 1 Struktura podziału produktów w formie diagramu hierarchicznego

298 I Dodatek D: Przykład planowania opartego na produktach

D.2 PRZYKŁAD OPISU PRODUKTU

KOŃ COWEGO PROJEKTU

Ta b ela D.1 Przykład Opi su Produkt u Końcowego Proj ekt u dla coroczn ej konferencji

Nazwa Coroczna konferencja

Przeznaczenie Konferencja jest dla uczestników coroczną okazją do zapoznania się z ostatnimi zmianami
w procedurach i standardach ich profesji oraz do nawiązania i odnowienia kontaktów z innymi
przedstawicielami ich zawodu.
Skład • Miejsce konierencji
• Uczestnicy
• Prelegenci
Reklama
• Materialy konferencyjne dla uczestników
• Obsługa logistyczna konferencji
Pochodzenie • Wybrany temat konferencji
• Lista adresowa
• Doświadczenia i materiały z poprzedniej konferencji
• Ustalona data konferencji
Wymagane umiejętności • Zarządzanie konferencjami
wytwórcy • Marketing
• Reklama/Public relations
Oczekiwania jakościowe Priorytet 1: Konferencja musi
klienta • mieć profesjonalny styl, być sfinansowana przez uczestników oraz uwzględniać potrzeby
szerokiego kręgu uczestników (od początkujących po doświadczonych profesjonalistów);
• być wydarzeniem stanowiącym forum dla nawiązywania i poszerzania kontaktów;
sprawić, że zadowoleni uczestnicy wezmą udział w następnych konferencjach.

Priorytet 2:
• Prelegenci zostaną wybrani na podstawie ich wiedzy, doświadczenia i kompetencji. Nie
będą niczego „sprzedawać" uczestnikom.

• Konferencja powinna mieć charakter interaktywny.

Kryteria akceptacji i tolerancje
jakości na poziomie projektu
• Konferencja powinna odbyć się w miejscu położonym centralnie. minimalizując w ten
sposób koszty dojazdów.
W kolejności priorytetów:
• Opłaty uczestników muszą pokryć koszty konferencji.
• W konferencji uczestniczy minimum 80, maksimum 100 osób.
• Ponad SOo/o prezentacji jest interaktywnych (raczej seminaria, a nie wykłady).
• Prelegenci i program są zatwierdzeni przez radę programową reprezentującą interesy
członków.

• Ankieta badająca poziom zadowolenia uczestników wskazuje, że ponad 75o/o weźmie

udzial w przyszlorocznej konferencji i/lub poleci ją kolegom/koleżankom.
• Hotel znajduje się w odległości do pięciu kilometrów od stacji na glównej linii kolejowej.
Metoda akceptacji Ponieważ konferencji nie będzie można powtórzyć, o ile okaże się ona nie do zaakceptowania.
Komitet Sterujący udzieli:
• wstępnej akceptacji - na podstawie zatwierdzenia uzgodnionego programu przez radę
programową oraz niezależnego zapewnienia, że przewidywana liczba uczestników oraz
koszty konferencji będą możliwe do zaakceptowania;
• ostatecznej akceptacji - na podstawie Raportu Końcowego Projektu dostarczającego
dowody, że spelnione zostaly kryteria akceptacji.
Odpowiedzialność • Glówny Użytkownik i Przewodniczący odpowiedzialni są za potwierdzenie akceptacji.
za akceptację
 Dodatek D: Przykład planowania opartego na produktach I 299

7 Materiały z poprzednich konferencji

6.1
I Zewnętrzny I I Zewnętrzny I I .I nia dla mie• a

1.2 Mol:liwe mie'sca

6.2 Ustalon tcrnlln 1 Miejsce
6 Logistyka konferenc'I
I Zewnętrzny I 1.3 Ocen mie'sc

6.J Uz ram ane i zarezerwowane

6.4 Penonel jednodn"

2.1 Lista adresowa

I Zewn9trzny I
2.2 Z toszenia uczestnktw•
2 Uczestnicy
5. 1 Ołtladki
Konferencja - I Zewnętrzny I
5 Materiały dla uczestników 2.3 Zas&d rnerwac·i
5.2 drukowan
2.4 Ost a t eczńa lista uczest1lików
5.3 Sla d I no1a1ki

S.4 Formu1art anie.ie

nd
3 Prelegenci
4. 1 List reklam
4 Reklama
3.3 Zaan a źowanl >rei enci
4.2 Notatka rasowa

Rysunek D.2 Struktura podziału produktów w formie mapy myśli

D.3 PRZYKŁADYSTRUKTURY PODZIAŁU • Diagram hierarchiczny (np. diagram struktury

PRODUKTÓW podzialu produktów).
• Mapa myśli.
PRINCE2 nie określa formatu struktury podziału pro-
• Lista zagn i eżdżona .
duktów. Dla projekt u „konferencja" podano trzy
przykladowe formaty:

Struktura podziału produktów w formie listy zagnieżdżonej

Konferencj a 4 Reklama:
4.1 List reklamowy,
1 M iejsce konfe rencji:
4.2 Komunikat prasowy.
1.1 Wymagania dla miejsca konferencji,
1.2 Możliwe miejsca, 5 Materialy dla uczestników:
1.3 Oceny miejsc, 5.1 Okładki,
1.4 Miejsce wybrane i zarezerwowane. 5.2 Wydrukowany program,
5.3 Slajdy i notatki,
2 Uczestnicy:
5.4 Formularz ankiety badającej poziom
2.1 List adresowa (produkt zewnętrzny),
zadowolenia.
2.2 Zgłoszenia uczestnictwa (produkt
zewnętrzny), 6 Logistyka konferencji:
2.3 Zasady rezerwacji, 6.1 Wybrany temat konferencji (produkt
2.4 Ostateczn a lista uczest ników. zewnętrzny),
6.2 Ustalony termin (produkt zewnętrzny),
3 Prelegenci:
6.3 Ustalony program,
3.1 Potencjalni prelegenci,
6.4 Personel jednodniowy.
3.2 Zaproszenia dla prelegentów,
3.3 Zaa n gażowan i prelegenci. 7 Doświ adczen i a i materi ały z poprzedniej
konferencj i (produkt zewn ętrzny).
300 I Dodatek D: Przykład planowania opartego na produktach

D.4 PRZYKŁAD OPISU PRODUKTU

ldentyfkator Konferencja/4.1/Wersja 1.0

Nazw a List rek lamowy

Przeznaczenie List rek lamowy jest podstawowym środkiem slużącym rozreklamowaniu

konferencji wśród potencjalnych uczestników. Będzie on rozeslany pocztą
do specjalistów pracujących w branży wg listy adresowej.

Zawartość • Koperta wysylkowa

• List informujący o konferencji
• Broszura ze szczególowymi wyjaśnieniami dotyczącymi konferencji, miejsca
i sposobu rezerwacji
• Formularz zgloszeniowy
• Koperta zwrotna

Pochodzenie • Lista adresowa

• Uzgodniony program
• Zasady rezerwacj i
• Wybrane miejsce konferencji

Wymagany format List na standardowym papierze firmowym formatu A4

i sposób przedstawienia Broszura i formularz zgloszeniowy formatu AS
Koperta wysylkowa formatu CS

Wymagane umiejętności Wymagane umiejętności w zakresie marketingu, wzornictwa i tekstów

wytwórcy reklamowych
Kon ieczna znaj omość konferencj i

O bowiązki dotyczące • Wytwórca - Firma zarządzająca organ i zacj ą imprezy

ja kości • Testerzy - zgodnie z pozycj ą: „Wymagane um i ejętności kontro lera jakości"
• Zatwierdzaj ący - Sekretariat sekcji członkowsk i ej

Kryteria jakości Tolerancja jakości M etoda kontroli jakości Wymagane umiejętności

kont rolera jakości

Zgodność z firmowymi Jak określono Przegląd jakości PRINCE2 Zespól Marketingu

standardami identyfikacji w firmowych standardach
wizualnej identyfkacji wizualnej

Li st i broszura Brak Przeg l ąd Kierownik Projektu

odzwi erciedlają „ Konferencja"
dokladnie wszystkie
uzgodnione szczegóły
konferencji

Żadnych blędów Brak Korektor błędów Korektor

ortografcznych programu Word
i gramatycznych we
wszystkich elementach Przegląd
listu reklamowego

List przewodni mieści się Może zająć drugą stronę Przeg l ąd Korektor
na jednej stronie A4 arkusza A4
 Dodatek D: Przykład planowania opartego na produktach I 301

D.5 DIAGRAM NASTĘPSTWA PRODUKTÓW

6.2
Ustalony
termin
6.1
Wybrany ~
temat
konfercn~

3.1
1.1
Wymagania d la
miejsca -
Potencjalni
prelegenci l
2.3
1.2 Zasady
• Motliwe
miejsca
rezerwacji

3.2 I
Zaproszenia dla J.
prelegentów
1.3
• Oceny
miejsc
3.3
Zaangatowani .I.
prelegenci 2.1
Usta
1.4 adresowa
Miejsce 'tN)'brane
i zarezerwowane ~
- 6.3
Uzgodniony
program

l 4.1
4.2 List
5.1 5.3 5.2 5.4 Notatka reklamowy
Okładki Slajdy Nydrukowany fOfmularz prasowa
i notatki program ankiety

I
I

5 2.4 2.2
Materiały Zgloszenia
dla uczestników
Ostateczna lista ,.......... uaestnictwa
uczestników
~
7
Oołwi,adaenia
I rnattr loly
2 poprtednich 6.4
Personel
konfe1e~
jednodniowy

Konferencja

Rysunek D.3 Przykład diagramu następstwa produktów dla projektu „Konferencja"

Uwaga: Ze strukt ury podziału produktu trzeba przenieść na diagram następstwa produktów tylko produkt
końcowy projektu, wydania (zestawy przekazywanych produktów) oraz produkty. Na przykład w niniejszym
scenariuszu planista użył elementu „Reklama" w strukturze podziału produktów, ale jedynymi produktami
„Reklamy" do wytworzenia są list reklamowy oraz komunikat prasowy. „Reklama" nie jest produktem
wym agającym pracy, ale wygodnym sposobem opisu/grupowania produktów, które za pewniają konferencji
reklamę . Inaczej jest w przypadku „Materiałów dla uczestników", które są produktem wytworzonym przez
połączenie produktów w postaci okładek, wydrukowanego programu, wydruków konferencyjnych slajdów
i notatek oraz formularza ankiety badaj ącej poziom zadowolenia.
Dodatek E: Listy kontrolne zgodności
projektu z PRINCE2
Poniższych list kontrolnych ułożonych według pro-
cesów można używać w różnych momentach cykl u
życi a projektu, aby sprawdzić, czy odpowiednio
uwzg lędniono kluczowe aspekty PRINCE2. Listy te
nie wyczerpują tematu, ale powinny wystarczyć,
aby stwierdzić z uzasadnioną pewnością, czy projekt
zarządzany jest zgodnie z metodyką PRINCE2.
Na l eży zwrócić uwagę, że jakiekolwiek odniesie-
nia w poni ższych listach kontrolnych do produktu
za rządczego oznaczaj ą „zgodność z Opisem Pro-
duktu w Dodatku A", a w szczególności, że nale-
ży przejrzeć kryteria jakości dla tych produktów
zarządczych.

E.1 PRZYGOTOWANIE PROJEKTU

Pytanie Tak/Nie
1 Czy zostały przydzielone role zespolu zarządzania projektem:
a Przewodniczącego?

b Kierownika Projektu J
c Glównego Uźytkownika(-ów)?
- d Glównego Dostawcy(-ów)- jeżeli to właściwe w tym momencie?
e Wsparcia Projektu?
r Kierowników Zespołu - jeżeli to wla~ciwe w tym momencie?
g Nadzoru Projektu?
h Obslugi Zmian - jeżeli to wlaściwe w tym momencie?
2 Czy czlonkowie Komitetu Sterującego są dostępni oraz posiadają dostateczne uprawnienia
i wiarygodność, aby zarządzać strategicznie projektem?
3 Czy interesariusze projektu są wystarczająco reprezentowani przez Komitet Sterujący?
4 Czy istnieją opisy ról dla każdej mianowanej kluczowej osoby?
5 Czy osoby mianowane potwierdziły przyjęcie mianowania?
6 Czy zalożono Dziennik Projektu?
7 Czy zalożono Dziennik Doświadczeń?
8 Czy zidentyfikowano doświadczenia z poprzednich podobnych projektów i, tam gdzie to wlaściwe,
uwzględniono je?

9 Jeżeli organizacja
nie prowadzila przedtem takich projektów, czy znaleziono doświadczenia
z porównywalnych projektów poza organizacją?
10 Czy opracowano Założenia Projektu?
11 Czy istnieje zarys Uzasadnienia Biznesowego7
12 Czy opracowano Opis Produktu Końcowego Projektu?
13 Czy podjęto decyzję, jaka będzie formula realizacji projektu?
14 Czy istnieje Plan Etapu inicjowania?
306 I Dodatek E: Listy kontrolne zgod ności projektu z PRINC E2

E.2 ZARZĄDZAN I E STRATEGICZNE PROJEKTEM

E.2. 1 Zezwalanie na zainicjowanie projektu

Pytanie Tak/Nie
15 Czy Komitet Sterujący zatwierdził Założenia Projektu? Czy w szczególności:

• Potwierdził definicję i formułę realizacji projektu?

• Dokonał przeglądu i zatwierdził Opis Produktu Końcowego Projektu?

• Formalnie potwierdził mianowania głównych członków zespołu zarządzania projektem?

• Dokonał przeglądu
korzyści?
i zatwierdził zarys Uzasadnienia Biznesowego, a w szczególności prognozowane

16 Czy Komitet Sterujący zatwierdził Plan Etapu inicjowania? Czy w szczególności:

• Zatwierdził plan opracowania Dokumentacji Inicjowania Projektu?

• Uzyskał łub zaangażował zasoby potrzebne do realizacji Planu Etapu inicjowania'

• Upewnił się, czy wdrożono odpowiednie mechanizmy raportowania i kontroli dla etapu inicjowania'

• Ustalił tolerancje dla etapu inicjowania?

• Wystąpił z wn ioskiem do kierownictwa organizacji lub programu o konieczne wsparcie logistyczne

(na przykład pomieszczenia, środki komunikacji, sprzęt i wszelkie inne Wsparcie Projektu)?

• Potwierdził, że rozumie wszelkie ryzyka mające wpływ na decyzję o wydaniu zezwolenia na realizację
etapu inicjowania?

17
• Potwierdził Kierownikowi Projektu, że prace określone w Planie Etapu inicjowania
Czy Komitet Sterujący poinformował kierownictwo organizacji lub programu (oraz inne zainteresowane
mogą się rozpocząć?

strony), że zezwolono na zainicjowanie projektu?

E.2.2 Zezwalanie na rea li zację projektu

Pytanie Tak/N ie
18 Czy Komitet Sterujący zatwierdził Dokumentację Inicjowania Projektu ? Czy w szczególności:

• Potwierdził, żeUzasadnienie Biznesowe jest zasadne, potrzebne i wykonalne oraz że

oczekiwania i standardy kierownictwa organizacji lub programu, oraz zatwierdził je?
spełnia

• Potwierdził, że przejrzano i uwzględniono doświadczenia z uprzednich podobnych projektów?

• Potwierdził, że Strategia Zarządzania Jakością spełni oczekiwania jakościowe, i zatwierdził ją?

• Potwierdził, że
zarządzania
Strategia Zarządzania Konfiguracją zapewni oczekiwany sposób
produktami, i za twierdził ją?
podejścia do

• Potwierdził, że Strategia Zarządzania Ryzykiem zabezpieczy odpowiednio projekt, i zatwierdził ją?

• Potwierdził, że przeprowadzono ocenę ryzyka, i że zaplanowano działania reakcji na ryzyko?

• Potwierdził zasadność i reałizowalność Planu Projektu oraz zatwierdził go?

• Potwierdził, że Plan Przeglądu Korzyści obejmuje wszystkie oczekiwane korzyści, i zatwierdzi! go?

• Potwierdził, że wszyscy członkowie zespołu zarządzania projektem zaakceptowali swoje role (struktura
zespołu zarządzania projektem, role i obowiązki)?

• Zagwarantował, że mechanizmy sterowania projektem są właściwe dla charakteru projektu?

• Upewnił się, że potrzeby informacyjne oraz częstotliwość komunikacji, tak jak to określono w Strategii
Zarządzania Komunikacją, są właściwe dla charakteru projektu, i zatwierdził ją?

• Dokonał przeglądu
aby upewnić się,
tolerancji dla projektu określonych przez kierownictwo organizacji lub programu•
że są one właściwe i realistyczne?

19
• Rozważył spójność różnych części Dokumentacji Inicjowania Projektu i zatwierdzi! ją jako
Czy Komitet Sterujący poinformował kierownictwo organizacji lub programu (i inne zainteresowane strony),
całość?

że wydano zezwolenie na realizację projektu?

 Dodatek E: Listy kontrolne zgodności projektu z PRINCE2 I 307

E.2.3 Zezwa lanie na rea l izację Planu Etapu lub Planu Nadzwyczajnego
Pyt anie Tak/Nie
20 Czy Komitet Sterujący dokona! przeglądu Raportu Końcowego Etapu? Czy w szczególności:

•
-
Dokona! przeglądu stanu realizacji projektu,
etapu zarządczego?
korzystając z Raportu Końcowego Etapu dla bieżącego

21
• Dokona! przeglądu osiągniętych korzyści oraz doświadczeń

Czy Komitet Sterujący oceni! ogólną zasadność projektu? Czy w szczególności:

zdobytych w czasie etapu?

• Dokona! przeglądu Planu Projektu oraz aktualnej sytuacji w odniesieniu do tolerancji projektu
uzgodnionych z kierownictwem organizacji lub programu?

• Dokonał przeglądu
zasadny?
Uzasadnienia Biznesowego w celu zapewnienia, że projekt jest w dalszym ciągu

• Dokonał przeglądu
w dalszym ciągu
kluczowych ryzyk, aby upewnić się, że poziom łącznej ekspozycji na ryzyko jest
akceptowalny oraz że zaplanowano działania reakcji na ryzyko?

• Uzyskał decyzje spoza projektu dla wszelkich potencjalnych odchyleń poza granice tolerancji projektu?
(Na przyklad: jeżeli projekt ten jest częścią programu, wtedy kierownictwo programu powinno
przeanalizować wplyw tych odchyleń na program i podjąć odpowiednie dzialania).

22 Czy Komitet Sterujący dokonał przeglądu i zatwierdzi! Plan następnego Etapu (lub Plan Nadzwyczajny)? Czy
w szczególności:

• Dokona! przeglądu planu, dla którego Kierownik Projektu chce uzyskać zatwierdzenie?
Etapu dla następnego etapu zarządczego lub Plan Nadzwyczajny).
(Będzie to Plan

• Wydal Kierownikowi Projektu zezwolenie na realizację przedstawionego planu (Planu Etapu lub Planu
Nadzwyczajnego) lub polecił Kierownikowi Projektu, aby przedwcześnie zamknąl projekt?
--
• Ustalił
jeśli
tolerancje dla następnego etapu zarządczego lub (w przypadku Planu Nadzwyczajnego) zmienił,
to konieczne, tolerancje dla bieżącego etapu?
23 Czy Komitet Sterujący poinformowal kierownictwo organizacji lub programu (i inne zainteresowane strony),
że wydano zezwolenie na realizację następnego etapu (lub że zatwierdzono plan nadzwyczajny dla bieżącego
etapu)?

E.2.4 Podejmowanie decyzji doraźnej

Pytanie Tak/Nie
-
24 Czy Komitet Sterujący odpowiedział na prośby i wnioski Kierownika Projektu? Czy w szczególności:

• DokonaI przeglądu prośby/wniosku?

Raportu o Zagadnieniu).
(Może być on nieformalny lub formalny, ten ostatni w formie

• Podjąl decyzję, na przykład: zatwierdzi!, odrzuci!, odroczy! decyzję, poprosi! o więcej informacji?

25
• Przekazal wytyczne Kierownikowi Projektu?
Czy Komitet Sterujący odpowiedzial na raporty? Czy w
.
szczególności:

• Dokona! przeglądu ostatniego Raportu Okresowego w celu zrozumienia stanu projektu i jest
usatysfakcjonowany w wyniku rozmowy z Kierownikiem Projektu, że etap postępuje zgodnie
z planem?

• Podjąl
decyzje dotyezące Raportów Nadzwyczajnych -
odpowiednio reakcje na sytuacje nadzwyczajne?
dostosował tolerancje lub zatwierdz.il

• Podjąłdecyzje dotyczące Raportów o Zagadnieniach w jemu delegowanych granicach

poprosił o wytyczne kierownictwo organizacji lub programu?
uprawnień lub

26 Czy Komitet Sterujący zareagowal na zdarzenia zewnętrzne? Czy w szczególności:

• Zapewnił, że
wpływ?
projekt informowany jest o wydarzeniach zewnętrznych, które mogą mieć na niego

• Zagwarantowal, że projekt koncentruje się caly czas na ustalonych celach organizacji lub programu
i ma nadal uzasadnienie w kategoriach biznesowych?
308 I Dodatek E: Listy kontrolne zgodności projektu z PRINCE2

Pytanie Tak/Nie
• Zagwarantował, że Kierownik Projektl1powiadamiany jest o wszelkich z1nianach w środowisku
organizacji łub programu, które mog11 wpłynąć na projekt, i że podejmowane są odpowiednie
działania?

27 Czy Komitet Steruiący poinformował kierownictwo organizacji lub programu (i inne zainteresowane strony)
o postępach projektu zgodnie ze Strategią Zarządzania Komunikacją?

E.2.5 Zezwalanie na zamknięcie projektu

Pytanie Tak/Nie
28 Czy Komitet Sterujący potwierdził przekazanie produktu końcowego projektu i akceptację? Czy
w szaególności:

• Zweryfikował zgodność przekazania produktu projektu ze Strategią Zarządzania Konfiguracją,

a w szczególności istnienie zapisów wszystkich wymaganych akceptaq1 przez użytkownika oraz
akceptacji eksploatacji i utrzymania?

• Zagwarantowal. że (gdzie to właściwe) zmiany biznesu (operacyjne)

i możliwe do u trzymania?
wynikające z projektu S<l wspierani

• Zagwarantował, że wszelkie oczekiwania jakościowe klienta, które można potwierdzić dopiero po

zakończeniu projektu (np. osiągnięte poziomy niezawodności) zawarte S<) w Planie Przeglądu Korzyści
jako przeglądy poprojektowe?
29 Czy Komitet Sterujący zatwierdził Raport Końcowy Projektu? Czy w szczególności:

• Skorzystał z wersji Dokumentacji Inicjowania Projektu, zatwierdzonej podczas inicjowania projektu jako
obiekt odniesienia, w celu oceny jak różni się projekt od swoich początkowych założeń, oraz jako ze
źródła informacji, w zestawieniu z którymi można oceniać sukces projektu?

• Zagwarantował, że zalecenia działań następczych zostały odpowiednio odnotowane w Raporcie

Końcowym Projektu i że odpowiednim grupom uświadomiono ich odpowiedzialność za dalsze zajęcie
się tymi zaleceniami?

• ZatwierdziłRaport Końcowy Projektu do rozpowszechnienia

kierownictwo organizacji lub programu?
wśród zainteresowanych stron, takich jak

30 Czy Komitet Sterujący dokonał przeglądu Raportu Doświadczeń i uzgodnił, kto powinien go otrzymać? Czy
Komitet zagwarantowal. że odpowiednim grupom (na przykład kierownictwu organizacji lub programu,
centrum doskonałości) uświadomiono ich odpowiedzialność za dalsze zajęcie się wszelkimi rekomendacjami?
31 Czy Komitet Sterujący potwierdził Uzasadnienie Biznesowe? W szczególności, czy potwierdził zaktualizowane
Uzasadnienie Biznesowe, porównując faktyczne i przewidywane korzyści, koszty i ryzyka z zatwierdzonym
Uzasadnieniem Biznesowym w pierwotnej Dokumentacji Inicjowania Projektu? (Potwierdzenie wszystkich
korzyści może nie być możliwe, ponieważ niektóre z nich zostaną zrealizowane dopiero po zamknięciu
projektu).
32 Czy Komitet Sterujący zatwierdził zaktualizowany Plan Przeglądu Korzyści? Czy w szczególności:

• Dokona! przeglijdu i uzyskał zatwierdzenie zaktualizowanego Planu Przeglądu Korzyści,

że uwzględnia on oczekiwane korzyści, których nie można było jeszcze potwierdzić?
upewniając się,

• Potwierdzi!, że odpowiedzialność za Plan

organizacji lub programu?
Przeglądu Korzyści została przekazana kierownictwu

33 Czy Komitet Steruiący wystosował powiadomienie o zamykaniu projektu? Czy w szaegółności:

• Dokonał przeglądu
Zarządzania Komunikacją?
i wystosował powiadomienie o zamykaniu pro1ektu zgodnie ze Strategią

• Poinformował
uwolnione?
tych, którzy udostępniali projektowi infrastrukturę i zasoby. że mog11 one teraz zostać

• Uwol nił zasoby udostępnione projektowi?

• Podał termin zamknięcia rachunku kosztów obciążających projekt?

 Dodatek E: Listy kontrolne zgodności projektu z PRINCE2 I 309

E.3 INICJOWANIE PROJEKTU

Pytanie Tak/Nie
-------
34 Czy doświadczenia z poprzednich podobnych projektów zostaly zidentyfikowane i tam, gdzie to wla~ciwe,
wykorzystane?
35 Czy jest opracowana 1 udokumentowana Strategia Zarządzania Ryzykiem?
36 Czy zalożono Rejestr Ryzyk 1 dokonano w nim wpisów?
37 Czy jest opracowana i udokumentowana Strategia Zarządzania Konfiguracją?

3B Czy utworzono począ tkowe Zapisy Obiektów Konfiguracji?

39 Czy zalożono Rejestr Zagadnień i dokonano w nim wpisów?
40 Czy jest opracowana i udokumentowana Strategia Zarządzania Jakością?
41 Czy zalożono Rejestr Jak~i i dokonano w nim wpisów?
42 Czy jest opracowana i udokumentowana Strategaa Zarządzania Komunikacją?
43 Czy określono i ustanowiono mechanizmy sterowania projektem'
-
44 Czy opracowano Plan Projektu?
45 Czy zaktualizowano strukturę zespolu zarządzania projektem tak. aby obejmowala ona wszelkie nowe
mianowane role lub zmiany zakresu obowiązków istniejących ról?
46 Czy istnieja, opisy ról dla nowych mianowań i czy osoby mianowane potwierdzily ich akceptację?
47 Czy zarys Uzasadnienia Biznesowego przeksztalcono w szaególowe Uzasadnienie Biznesowe?
4B Czy opracowano Plan Przeglądu Korzyści (moglo tego dokonać kierownictwo organizacji lub programu}?
49 Czy zestawiono Doku mentację Inicjowania Projektu?

E.4 STEROWANIE ETAPEM

Pytanie Ta k/Nie
50 Czy utworzono i przekazano do wykonania Grupy Zadań?
51 Czy wszyy;:y Kierownicy Zespolów uzgodnili z Kierownikiem Projektu wszystkie swoje Grupy Zadań?
52 Czy ukończone produkty zostaly wytworzone zgodnie z wydaną Grupą Zadań i Opisem Produktu?
53 Czy utworzono/zaktualizowano odnośne Zapisy Obiektów Konfiguracji?
54 Czy Rejestr Jakości jest aktualizowany i przeglądany?
55 Czy jakiekolwiek produkty zostaly przekazane jako część dostawy stopniowej (kolejne wydania)? Jeżeli tak. cz,
zostaly one przekazane zgodnie ze Strategią Zarządzania Konfiguracją?
56 Czy Rejestr Ryzyk jest aktualizowany i przegl<1dany?
57 Czy Rejestr Zagadnień Jest aktualizowany i przeglądany?
SB Czy aktualizowano Plan Etapu danymi faktycznymi i zrewidowanymi prognozami?
59 Czy Dziennik Projektu jest aktualizowany i przegl<idany?
60 Czy dla wydanej Grupy Zadań otrzymywano Raporty z Punktów Kontrolnych z uzgodnioną
każdej

częstotliwością i w uzgodnionym formacie?

61 Czy postępy (faktyczne i prognozowane) byly sprawdzane pod kątem uzgodnionych tolerancji?
62 Jeżeli prognozowano przekroaenie tolerancji, czy przekazano to do Komitetu Sterującego?

63 Jeżeli konieczne były dzaalanaa korygujące. czy zostaly one zapisane, wdrożone, a ich przebieg był śledzony?
64 Czy Uzasadnienie Biznesowe sprawdzano okresowo pod kątem dalszej zasad~i projektu?
65 Czy opracowywano Raporty Okresowe i przekazywano je z uzgodnioną częstotliwością i w uzgodnionym
formacie?
66 Czy istnieją Raporty o Zagadnieniach dla wszystkich zagadnień, którymi zajmowano się formalnie?
31 O I Dodatek E: Listy kontrolne zgodności projektu z PRINC E2

Pytanie Tak/Nie
67 Czy istnieją Raporty Nadzwyczajne dla wszystkich sytuacji nadzwyczajnych zgłoszonych Komitetowi
Sterującemu?

68 Czy Dziennik Doświadczeń zostal zaktualizowany wpisami nowych doświadczeń?

E.5 ZARZĄDZANI E DOSTARCZANIEM PRODUKTÓW

Pytanie Tak/N ie
69 Czy Grupa Zadań i Opis(y) Produktów zawieraly wystarczaja.ce informacje, łącznie z odniesieniami do innych
dokumentów, aby umożliwić Kierownikowi Zespołu wytworzenie wymaganych produktów?
70 Czy opracowano Plan Zespolu wykazujący, że Grupa Zadań może zostać ukończona w ramach uzgodnionych
tolerancji?
71 Czy Plan Zespolu zostal zaktualizowany przez uwzględnienie stanu faktycznego i zrewidowanych prognoz?
72 Czy postępy (faktyczne i prognozowane) zostaly sprawdzone pod kątem uzgodnionych tolerancji?
73 Jeżeli prognozowano przekroczenie tolerancji, czy przekazano to do Kierownika Projektu?
74 Czy opracowywano Raporty z Punktów Kontrolnych i przekazywano je Kierownikowi Projektu
w uzgodnionym formacie i z uzgodnioną częstotliwością?
75 Czy Kierownik Zespolu zawiadomił Kierownika Projektu o wszelkich zagadnieniach i ryzykach?
76 Czy dla każdego ukończonego produktu istnieją zapisy dotyczące jego zatwierdzenia?
77 Czy Kierownik Zespolu zawiadomił Wsparcie Projektu o wszelkich wymaganych aktualizacjach Zapisów
Obiektu Konfiguracji i Rejestru Jakości?
78 Czy Kierownik Zespolu zawiadomił Kierownika Projektu, że wszystkie produkty w Grupie Zadań zostały
dostarczone?

E.6 ZARZĄDZAN IE KO ŃCEM ETAPU

Pytanie Tak/N ie
79 Czy zatwierdzono wszystkie produkty, których ukończenie planowano w etapie?
80 Czy sporządzono Zestawienie Statusu Produktów, aby zweryfikować status produktów etapu?
81 Jeżeliw czasie trwania etapu nastąpilo przekazanie produktów, czy zostały udokumentowane powiązane
z nimi niezamknięte zagadnienia jako zalecenia dzialań następczych, gotowe do dystrybucji pod warunkiem
uzyskania zatwierdzenia Komitetu Sterującego?
82 Czy dokonano przeglądu i aktualizacji Dziennika Doświadczeń?

83 Jeżelito wymagane, czy opracowano Raport Doświadczeń gotowy do dystrybucji, pod warunkiem uzyskania
zatwierdzenia przez Komitet Sterujący?
84 Czy Plan Etapu został zaktualizowany tak. aby uwzględniał faktyczne wyniki?
85 Czy dokonano przegla.du Strategii Zarządzania Ryzykiem i (o ile to konieczne) jej aktualizacji?
86 Czy dokonano przeglądu i aktualizacji Rejestru Ryzyk?
87 Czy dokonano przeglądu Strategii Zarządzania Konfiguracją i (o ile to konieczne) jej aktualizacji?
88 Czy dokonano przeglądu i aktualizacji Zapisów Obiektów Konfiguracji?
89 Czy dokonano przeglądu i aktualizacji Rejestru Zagadnień?
90 Czy dokonano przeglądu Strategii Zarządzania Jakością i (o ile to konieczne) jej aktualizacji?
91 Czy dokonano przeglądu i aktualizacji Rejestru Jakości?
92 Czy dokonano przeglądu Strategii Zarządzania Komunikacją i (o ile to konieczne) jej aktualizacji?
93 Czy dokonano przeglądu i (o ile to konieczne) aktualizacji mechanizmów sterowania projektem?
94 Czy dokonano przeglądu Planu Projektu i (o ile to konieczne) jego aktualizacji?
 Dodatek E: Listy kontrolne zgodności projektu z PRINCE2 I 311

-
Pytanie Tak/Nie
95 Czy zaktualizowano strukturę zespołu zarządzania projektem tak, aby obejmowała ona wszelkie nowe
mianowane role lub zmiany zakresu obowiązków istniejących ról?
----
96 Czy istnieją opisy ról dla nowych mianowań i czy osoby mianowane potwierdzily ich akceptację?
97 Czy dokonano przeglijdu Uzasadnienia Biznesowego i (o ile to konieczne) jego aktualizacji?
---
98 Czy dokonano przeglijdu Planu Przeglądu Korzyści i (o ile to konieczne) jego aktualizacji?
----
99 Czy dokonano przeglądu Dokumentacji Inicjowania Projektu i (o ile to konieczne) jej aktualizacji?
-
1OO Czy opracowano Raport Końcowy Etapu, pokazujący faktyczne wykonanie w stosunku do planowane go oraz
zestawiający doświadczenia i zalecenia działań następczych?
---- ----
101 Czy Raport Końcowy Etapu został przekazany Komitetowi Sterującemu zgodnie z mechanizmami sterowania
projektem?
Dla n astępnego etapu:
102 Czy opracowano Plan Etapu dla następnego etapu?
103 Czy opracowano Opisy Produktów dla produktów następnego etapu?
-----
104 Czy wystąpiono do Komitetu Sterującego o wydanie zezwolenia na realizację następnego etapu?
DIa sytuacji wyjątkowych:
--'------'------
1OS Czy opracowano Plan Nadzwyczajny fjeżeli zlecił to Komitet Sterujący)?

106 Czy opracowanc:Yzaktuałizowano Opisy Produktów dla Pła nu Nadzwyczajnego?

107 Czy wystąpiono do Komitetu Steruji)cego o zatwierdzenie Planu Nadzwyczajnego?
-"------------lf------
E.7 ZAMYKANIE PROJEKTU
Pytanie Tak/Nie
108 Czy ukończono i zatwierdzono wszystkie produkty?
109 Czy opracowano Zestawienie Statusu Produktów, aby zweryfikować status wszystkich produktów?
110 Czy udokumentowano wszystkie nierozwiązane zagadnienia jako zalecenia dzialań następczych, gotowe do
dystrybucji pod warunkiem uzyskania zatwierdzenia Komitetu Steruji)cego?
111 W przypadku przedwczesnego zamknięcia projektu, czy środki dla odzyskania produktów ukończonych łub
produktów w toku produkcji zostały zatwierdzone przez Komitet Steruji)cy? Jeżeli bylo to zalecane, czy został
opracowany i zatwierdzony Plan Nadzwyczajny?
112 Czy istnieje zapis akceptacji dla przekazanego produktu końcowego projektu?
113 Czy zapis akceptacji obejmuje akceptację służb eksploatacji i utrzymania?
114 Czy Dziennik Doświadczeń został przejrzany i opracowano Raport Doświadczeń. gotowy do dystrybucji pod
warunkiem uzyskania zatwierdzenia Komitetu Sterującego?
115 Czy zaktualizowano Plan Projektu tak, aby zawierał dane faktyczne?
116 Czy zaktualizowano Uzasadnienie Biznesowe tak, aby zawierało dane faktyczne?
117 Czy zak tualizowano Plan Przeglądu Korzyści tak. aby zawierał dane faktyczne?
118 Czy opracowano Raport Końcowy Projektu, pokazujący faktyczne wykonanie w stosunku do planowanego,
-
oraz zestawiający doświadczenia i zalecenia działań następczych?
119 Czy Raport Końcowy Projektu zestal przekazany Komitetowi Sterującemu zgodnie z mechanizmami
sterowania projektem?
120 Czy opracowano propozycję powiadomienia o zamykaniu projektu do zatwierdzenia przez Komitet Sterujący
i dalszej dystrybucji?
121 Czy zamknięto wszystkie rejestry i dzienniki?
122 Czy zarchiwizowano calą dokumentację projektu?
 Dodatek F: Terminologia

Dodatek zawiera zestawienia specyficznych terminów i pojęć uźytych w tej publikacji w języku polskim oraz ich
angielskich odpowiedników.

F.1 ZASADY
Lista pryncypiów (zasa d) PRINCE2, które szczegółowo przedstawiono w Rozdziale 2.

Nazwa angielska Nazwa polska

Continued business justification Ciągła zasadność biznesowa
----------------------------------~
Learn from experience Korzystanie z doświadczeń
Defined ro/es and responsibilities Zdefiniowane role i obowiązki
Manage by stage Zarządzanie etapowe
" -- -
Manage by exception Zarządzanie z wykorzystaniem tolerancji
Focus on products Koncentracja na produktach
Tai/or to suit the project environment Dostosowanie do warunków projektu

F.2 TEMATY
Lista tytułów tematów, które szczególowo przedstaw iono w Rozdzia łach od 3. do 10.

Nazwa angielska Nazwa polska

Business Case Uzasadnienie Biznesowe
Organization Organizacja
Quality Jakość

Plans Plany
Risk Ryzyko
Change Zmiana
Progress Postępy

F.3 PROCESY I DZIAŁAN IA

Lista procesów i działań, które szczególowo przedstaw iono w Rozdziałach od 11 . do 18.

Nazwa angielska Nazwa polska

Starting up a project Przygotowanie Projektu
Appoinring the Executive and the Project Manager Mianowanie Przewodniczącego i Kierownika Projektu
Capture previous lessons Zgromadzenie dotychczasowych doświadczeń

Design and appoint the project management team Projektowanie i mianowanie zespolu zarządzania projektem
Prepare the outline Business Case Przygotowanie zarysu Uzasadnienia Biznesowego
Select the pro1ect approach and assemble the Project Brief Wybieranie formuły realizacji projektu i zestawianie Założeń Projektu
Plan the initiation stage Planowanie etapu inicjowania

Directing a Project Zarządzanie Strategiczne Projektem

Authorise initiation Zezwalanie na zainicjowanie projektu
Authorise the project Zezwalanie na realizację projektu
o.;_.;.--'- ------------
316 I Dodatek F: Terminologia

Nazwa angielska Nazwa polska

Authorise a Stage or Exception Plan Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego
Give ad hoc direction Podejmowanie decyzji doraźnej
~~~~~~~~~~~~~~~-

Authorise project closure ZezwaIanie na zamknięcie projektu

lnitiating a Project Inicjowanie Projektu

Prepare the Risk Management Strategy Opracowanie Strategii Zarządzania Ryzykiem
~~~~~~~-

Prepare the Configuration Management Strategy 0 pracow anie Strategii Zarządzania Kon figuracją

Prepare the Quality Management Strategy Opracowanie Stra tegii Zarządzania Jakością

Prepare the Communication Management Strategy Opracowanie Strategii Zarządzania Komunikacją

~~~~~~~~~

Set up the project controls Ustanowienie mechanizmów sterowania projektem

Create the Project Plan Sporządzanie Planu Projektu
~~~~~~~~~~~~~~'----~ ~---'~~~~~

Refine the Business Case Doprecyzowanie Uzasadnienia Biznesowego

Assemble the Project lnitiation Documentation Zestawianie Dokumentacji Inicjowania Projektu
~~~~~~~~- -~~~~~~~

Controlling a Stage Sterowanie Etapem

---~~~~~~~~~~~~~~~~

Authorise a Work Package Zezwalanie na wykonanie Grupy Zadań

~~~~~~~~~~~~~~~-

Review Work Package status Przeglądanie stanu Grupy Zadań

Receive comp/eted Work Packages Odbieranie zakończonych Grup Zadań
Review the stage status Przeglądanie stanu etapu
Report highlights Raportowanie okresowe
Capture and examine issues and risks Wychwytywanie i badanie zagadnień i ryzyk
~~~~~~~-

EscaIating issues and risks Przekazywanie zagad nień i ryzyk na wyższy szczebel
Take corrective action Podejmowanie dzialań korygujących

Managing Product Delivery Za rządzanie Dostarczaniem Produktów

Accept a Work Package Przyjmowanie Grupy Zadań do wykonania
~~~~~~~~~~~~~~~~

Execute a Work Package Wykonywanie Grupy Zadań

Deliver a Work Package Oddawanie wykonanej Grupy Zadań

Managing a Stage Boundary Za rządzanie Końcem Etapu

Plan the next stage Planowanie następnego etapu
~~~~~~~~~~~~~~~~ ~"'--~-'--~~~~~~~~~~~~-

Updi!te the Project Plan Uaktu aInianie Planu Projektu

Update the Business Case Uaktualnianie Uzasadnienia Biznesowego
Report stage end Raportowanie zakończenia etapu
~~~~~~~~~~~~~---'~~~-

Produce an Exception Plan Sporządza nie Planu Nadzwyczajnego

Closing a Project Zamykanie Projektu

Prepare planned closure Przygotowanie planowego zamknięcia
~~~~~~~~~~~~---'--'"--~~

Prepare premature closure Przygotowanie przedwczesnego zamknięcia

Hand over products Przekazanie produktów
~~~~~~- ~

Evaluate the project Ocenianie projektu

Recommend project closure Rekomendowanie zamknięcia projektu
 Dodatek F: Terminologia I 317

F.4 PRODUKTY ZARZĄDCZE PRINCE2

Lista wszystkich produktów zarządczych proponowanych przez PRINCE2. Zarysy ich opisów przedstawiono
w Dodatku A.

Nazwa angielska Nazwa polska

A 1 Benefits Review Plan A.1 Plan Przeglądu Korzyści

A2 Business Case A.2 Uzasadnienie Biznesowe

A3 Checkpoint Report A.3 Raport z Punktu Kontrolnego
A4 Communication Management Strategy A.4 Strategia Zarządzania Komunikacją

A5 Configuration Item Record A. 5 Zapisy Obiektu Konfiguracji

A6 Configuration Management Strategy A.6 Strategia Zarządzania Konfiguracją

A7 DailyLog A. 7 Dziennik Projektu

AB End Project Report A.8 Raport Końcowy Projektu
A9 End Stage Report A.9 Raport Końcowy Etapu
A 1O Exception Report A.1O Raport Nadzwyczajny
A 11 High/ight Report A.11 Raport Okresowy
A 1z lssue Register A.12 Rejestr Zagadnień
A 13 lssue Report A.13 Raport o Zagadnieniu
A 14 Lessons Log A.14 Dziennik Doświadczeń
A 15 Lessons Report A. 15 Raport Doświadczeń

A 16 Plan A.16 Plan

A 17 Product Description A. 17 Opis Produktu
AIB Product StatusAccount A.18 Zestawienie Statusu Produktów
A 19 Project Brief A. 19 Zależenia Projektu
AZO Project lnitiation Documentation A.20 Dokumentacja Inicjowania Projektu
AZ I Project Product Description A.21 Opis Produktu Końcowego Projektu
AZZ Quality Management Strategy A.22 Strategia Zarządzania Jakością
AZ3 Quality Register A.23 Rejestr Jakości
AZ4 Risk Management Strategy A.24 Strategia Zarządzania Ryzykiem
AZ5 Risk Register A.25 Rejestr Ryzyk
AZ6 Work Package A.26 Grupa Zadań

F.5 ROLE
Lista ról w projektach według PRINCE2, które są szczegółowo opisane w Dodatku C.

Nazwa angielska Nazwa polska

Project Board Komitet Sterujący
Executive Przewodniczący

Senior User Glówny Użytkownik

Senior Supplier Główny Dostawca
Project Manager Kierownik Projektu
Team Manager Kierownik Zespolu
Project Assurance Nadzór Projektu
Change Authority Obsługa Zmian
318 I Dodatek F: Terminologia

Nazwa angielska
~~~~~~~~~~~~~~~~~~~~~~~
Nazwa polska
Project Support Wsparcie Projektu
Chair (Quality Review) Kierownik przeglądu (Przegląd jakości)
'"--'---'--~~~~~~~~~~~

Presenter (Quality Review) Prezenter (Przegląd jakości)

Reviewer (Quality Review) Kontroler/Recenzent (Przegląd jakości)
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

Ad1ninistrator (Quality Review) Administrator (Przegląd jakości)

f.6 SŁOWN IK ANGIELSKO-POLSKI

English name Nazwa polska
~~~~~~~~~~~~~~~~~~~-'-~-

accept (risk response) akceptowanie (reakcja na ryzyko)

~-'--'--~~~~~~~~~~~~

acceptance akceptacja
acceptance criteria kryteria akceptacji
activity dzialanie
agile methods ~~~~~~~~~~~~~~~~~~~~-
metody zwinne (agile)
appro vaI zatwierdzenie
approver zatwierdzający

assumption zależenie

assurance nadzór
authority uprawnienie
authorization zezwolenie
avoid (risk response) unikanie (reakcja na ryzyko)
baseline obiekt/poziom odniesienia
baseline manage1nenr product produkt zarządczy będący obiektem odniesienia
benefit korzyść

benefits tolerance tolerancja korzyści

centre of excellence centrum doskonalości

change budget budżet zmian
change control sterowanie zmianami
checkpoint punkt kontrolny
closure notification powiadomienie o zamykaniu projektu
~~~~~~~~~~~~~~
-
closure recommendation rekomendacja zamknięcia projektu
~-'---=-~~~~~~~~~~~~

concession ustępstwo

configuration /tein obiekt konfiguracji

configuration management zarządzanie konfiguracją

configuratio11 management system system zarządzania konfiguracją

--=--~-'"-'-~~~~~~~~~~~-

constraints ograniczenia
contingency rezerwa
corporate or programme standards standardy korporacyjne lub programu
~--'--=~~~~~~~~~~~~

correct1ve action dzialania korygujące

~~~~~~~~~~~~~~~~~~~~---'--=---

COS I tolerance tolerancja kosztów

~~~~~~~~~~~~~~~~~~~~~--'--~~~

customer klient
customer's quality expectations oczekiwania jakościowe klienta
~~~~~~~~~~~~~~~

deliverable przedmiot dostawy

 Dodatek F: Terminologia I 319

English name Nazwa polska

dependencies (plan) zależności (w planie)
dis-benefit niepożądany skutek

embedding (PRINCE2) wdrożenie (PRINCE2)

enhance (risk response) wzmocnienie (reakcja na ryzyko)
event-driven control mechanizm sterowania zależny od zdarzeń

except1on sytuacja nadzwyczajna

exception assessment
exploit (risk response)
fal/back (risk response)
follow-on action recommendations
ocena sytuacji nadzwyczajnej
wyeksploatowanie lub wykorzystanie (reakcja na ryzyko)
-'------
plan rezerwowy (reakcja na ryzyko)
zalecenia działań następczych

governance (corporate) lad (w odniesieniu do korporacji)

governance (project) lad (w odniesieniu do projektu)
handover przekazanie
host site lokalizacja projektu
impact (of risk) oddzialywanie (ryzyka)
inherent risk ryzyko inherentne
initiation stage etap inicjowania
ISSUe zagadnienie
log dziennik
management product produkt zarządczy
1nanage1nent stage etap zarządczy
milestone kamień milowy
off-specification odstępstwo {niezgodność)

operational and maintenance acceptance akceptacja slużb eksploatacji i utrzymania

outco1ne rezultat, efekt zmiany
output wynik, produkt projektu
performance target docelowy wskaźnik wykonania
plan plan
planned closure planowe zamknięcie
planning horizon horyzont planowania
portfolio portfel
premature closure przedwczesne zamknięcie
prerequisites (pl<Jn) warunki wstępne (planu)
probability prawdopodobieństwo

problemtconcern problem/obawa
proeedure procedura
process proces
producer wytwórca
product produkt
product breakdown structure struktura podzialu produktów
product checklist lista kontrolna produktów
product flow diagram diagram następstwa produktów
product status account zestawienie statusu produktów
320 I Dodatek F: Terminologia

English name Nazwa polska

product·based planning
programme
project
project approach
project authorisation notification
project initiation notification
------~~~~~~~~~~~~~~~~~~~-'--~~~
planowanie oparte na produktach
program
projekt
formula realizacji projektu
powiadomienie o zezwoleniu na realizację projektu
powiadomienie o inicjowaniu projektu

project lifecycle cykl życia projektu

project management zarządzanie projektem
project management team zespół zarządzania projektem
~~~~~~~~~~~~~~~~--''--~--'-~~-'---'--~~

project management team structure struktura zespołu zarządzania projektem

project mandale zlecenie przygotowania projektu
~~~~~~~~~~~~~~~~~~~----'--~~~~~~~~~~~~~~~~~

project office biuro projektu

project product produkt projektu
project start-up notification powiadomienie o przygotowywaniu projektu
~~~~~~~~~~~-

proximi ty (of risk) bliskość (ryzyka)

quality jakość

quality assurance nadzór jakości

quality control kontrola jakości
quality criteria kryteria jakości~~~~~~~~~~~~~~~~~~

quality inspection inspekcja jakości

quality management zarządzanie jakością
~~~~~~~~~~~~~~~~..:.....~.....:..~---''--~~~~~~~~~~~~~~

quality management system system zarządzania jakością

quality records zapisy jakości
quality review przegląd jakości

quality review technique technika przeglądu jakości

quality tolerance tolerancja jakości

records zapisy
reduce (risk response) redukowanie (reakcja na ryzyko)
registers rejestry
reject (risk response) odrzucenie (reakcja na ryzyko)
release wydanie (zbiór produktów przekazywanych jako cal~
reports raporty
request for change wniosek o wprowadzenie zmiany
residua/ risk ryzyko rezydualne
reviewer kontroler/recenzent
risk ryzyko
risk actionee wykonawca reakcji na ryzyko
risk appetite apetyt na ryzyko
risk estimation oszacowanie ryzyka
-'--'--~~~~~~~~~~~~~~~~

risk evaluation ewaluacja (ocena) ryzyka

risk management zarządzanie ryzykiem
risk owner właściciel ryzyka
risk profile profil ryzyka
 Dodatek F: Terminologia I 321

English name Nazwa polska

risk response reakcja na ryzyko
risk response category kategoria reakcji na ryzyko
risk tolerance tolerancja ryzyka
risk tolerance line linia tolerancji ryzyka
role description opis roli
schedule harmonogram
seope zakres
scope tolerance tolerancja zakresu
Senior Responsib/e Owner (SRO) Właściciel Programu/Projektu
share (risk response) wspóldzielenie (reakcja na ryzyko)
specialist product produkt specjalistyczny
sponsor sponsor
stage etap
stakeholder interesariusz
start up przygotowanie
strategy strategia
supplier dostawca
tailoring dostosowanie
technical stage etap techniczny
time-driven control element sterowania zależny od czasu
tolerance tolerancja
tranche transza
transfer (risk response) przeniesienie (reakcja na ryzyko)
trigger sygnał uruchamiający

user acceptance akceptacja ze strony użytkownika

user(s) użytkownik(-cy)

variant wariant
version wersja

F.7 SŁOWNIK POLSKO-ANGIELSKI

Nazwa polska English name ~~~~~~~~~~~~~~~~~~~

akceptacja acceptance
akceptacja slużb eksploatacji i utrzymania operational and maintenance acceptance
akceptacja ze strony użytkownika user acceptance
akceptowanie (reakcja na ryzyko) accept (risk response)
apetyt na ryzyko risk appetite
biuro projektu project office
bliskość (ryzyka) proximity (of risk)
budżet zmian change budget
centrum doskonalości centre of excellence
cykl życia projektu project lifecycle
diagram następstwa produktów product flow diagram
docelowy wskaźnik wykonania performance target
Nazwa polska English name
dostawca supplier
dostosowanie tailoring
działania korygujące corrective action
działanie activity
dziennik log
element sterowania zależny od czasu time-driven control
---------------~ ----------------~
etap stage
etap inicjowania initiation stage
etap techniczny technical stage
etap zarządczy management stage
-------
ewaluacja {ocena) ryzyka risk evaluat1on
formula realizacji projektu
harmon ogram
_____________.;.._-'--'-'--------------------
project approac/1
schedule
horyzont planowania planning l1orizon
inspekcja jakości quality inspection
interesariusz stakeholder
jakość quality
kamień milowy milestone
kategoria reakcji na ryzyko risk response category
--------------'-- --''--''----------------~
klient customer
kontrola jakości quality control
kontroler/recenzent reviewer
korzyść benefit
kryteria akceptacji acceptance criteria
---------------~
kryteria jakości quality criteria
----------------~
linia tolerancji ryzyka
lista kontrolna produktów
- risk tolerance line
product checklist
-----------------
1okaIizacja projektu host sile
ład (w odniesieniu do korporacji) governance (corporate)
- - - - - - - - - - - -- - - -
1ad {w odniesieniu do projektu) governance (project)
mechanizm sterowania zależny od zdarzeń event-driven control
metody zwinne {agile) agile methods
-------------- ---
nadzór assurance
nadzór jakości quality assurance
niepożądany skutek dis-benefit
obiekt konfiguracji configuration Ilem
-------~~-------
obiek ł/poziom odniesienia baseline
ocena sytuacji nadzwycza1nej exception assessment
~~-~-----~-------
oczekiw ania jakościowe klienta customer's quality expectations
--------~-------'- ---'-------~-------~
oddziaływanie (ryzyka) inipact (of risk)
odrzucenie (reakcja na ryzyko) reject (risk response)
---------------~
odstępstwo (niezgodność) off-specification
ograniczenia constraints
 Dodatek F: Terminologia I 323

Nazwa polska English name

opis roli role description
~-----------------------'---~
oszacowanie ryzyka risk estimation
~-----------------------------------~
plan plan
plan rezerwowy (reakcja na ryzyko) fal/back (risk response)
planowanie oparte na produktach product-based planning
'------'----'--------------""----
pIanowe zamknięcie planned c/osure
---'--------~
portfel portfolio
----
powiadomienie o inicjowaniu projektu project initiation notiflcation
powiadomienie o przygotowywaniu projektu project start-up not1f1cation
powiadomienie o zamykaniu projektu closure notification
powiadomienie o zezwoleniu na realizację projektu project authoriSdtion notd1cation
--------~
prawdopodobieństwo probability
problem/obawa
procedura
~-------~ - problemlconcern
procedure
proces process
~------------------'---~
produkt product
produkt projektu project product
produkt specjalistyczny specialist product
produkt zarządczy management product
-
-'--------~
produkt zarządczy będący obiektem odniesienia
- - - - baseline
- - -management
- product
prof1I ryzyka risk profile
-----------------------~~~---------
program programme
projekt project
przedmiot dostawy deliverable
-~--------------------~
przedwczesne zamknięcie premature c/osure
przegląd jako~ci quality review
~-------~

przekazanie handover
przeniesienie (reakcja na ryzyko) transfer (risk response)
przygotowanie start up
-------
punkt kontrolny checkpoint
raporty reports
reakcja na ryzyko risk response
~------------------'------
redukowanie (reakcja na ryzyko) reduce (risk response)
rejestry registers
rekomendacja zamknięcia projektu closure recommendation
rezerwa contingency
rezultat. efekt zmiany outcome
--'"----------------------~
ryzyko risk
ryzyko inherentne inherent risk
------------------------------------~
ryzyko rezydualne residua/ risk
-'"-----------~
sponsor sponsor
standardy korporacyjne lub programu corporate or programme standards
--------~
sterowanie zmianami change control
- - - - - - - - - - - - - - - --=---- - - -
324 I Dodatek F: Terminologia

Nazwa polska English name

strategia strategy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

struktura podziału produktów product breakdown structure

~~~~~~~~~~~~~-

struktura zespołu zarządzania projektem project management team structure

sygnał uruchamiający trigger
~------~~~~~~~~~~~~~~---''-'--~~~

syste1n zarządzania jakością quality management system

system zarządzania konfiguracją configuration management system
~~~~~~~~~~~~~~-

sytuacja nadzwyczajna exception

technika przeglądu jakości quality review technique
~~~~~~~~~~~~~~~

tolerancja tolerance
tolerancja jakoki quality tolerance
tolerancja korzyści benefits tolerance
tolerancja kosztów cost tolerance
tolerancja ryzyka
--'-"'"-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
risk tolerance
tolerancja zakresu scope tolerance
transza tranche
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-

unikanie (reakcja na ryzyko) avoid (risk response)

uprawnienie authority
ustępstwo concession
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

użytkownik(-cy) user(s)
wariant variant
warunki wstępne (planu) prerequisites (plan)
wdrożenie (PRINCE2) embedding (PRINCE2)
wersja version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-

Wł aści cieI Programu/Projektu Senior Responsible Owner (SRO)

właściciel ryzyka risk owner
wniosek o wprowadzenie zmiany requestforchange
współdzielenie (reakcja na ryzyko) share (risk response)
wydanie (zbiór produktów przekazywanych jako całość) release
~~~~~~~~~~~~~~~~~~~~~~~~~~~

wyeksploatowanie łub wykorzystanie (reakcja na ryzyko) exploit (risk response)

wykonawca reakcji na ryzyko risk actionee
wynik, produkt projektu output
wytwórca producer
wzmocnienie (reakcja na ryzyko) enhance (risk response)
zagadnienie ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
issue
zakres scope
zalecenia działań następczych follow-on action recommendations
zależności (w planie) dependencies (plan)
założenie assumption
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

zapisy records
zapisy jakoki quality records
zarządzanie jakością quality management
zarządzanie konfiguracją configuration management
 Dodatek F: Terminologia I 325

Nazwa polska English name

zarządzanie ryzykiem risk management
zatwierdzający
'--'-~~~~~~~~~~~~~~~~~~~'----~~~~

approver
-
zatwierdzenie approval
~~~~~~~~~~~~--~--'"'-'-~~~~~~---~~~~~~~~~~~
zespól zarządzania projektem project management team
~~~~~~~~~~----

zestaw ienie statusu produktów product status account

zezwolenie authorization
zlecenie przygotowania projektu project mandale
Dalsze informacje
WYDAWNICTWA OFFICE OF GOVERNMENT
COMMERCE
PRINCE2
Metodyka PRINCE2 jest częścią zestawu przewodni-
ków opracowanych przez brytyjski urząd Office of
Government Commerce (OGC), mający na celu pomoc
organizacjom i czy osobom w zarządzaniu projekta-
mi, programami i usługami. Tam, gdzie jest to uza-
sadnione, przewodnikom tym towarzyszą także pro-
gramy zdobywan ia kwal if ikacji oraz akredytowane
szkolenia i usługi konsultingowe.
PRINCE2 - Skuteczn e Zarządzanie Projektami (2009).
The Stationery Office, Lond on.
Directing Successful Projects with PRINCE2 (2009).
The Stationery Office, London.
Zarządzanie Ryzykiem (M_o R)
Projekty istnieją w świecie, którego cechuje nie-
pewność i z tego powodu skuteczne zarządzanie
ryzyk iem ma zasad nicze znaczeni e d la zarządzania
dostarczaniem produktów projektu, ich rezultata-
mi oraz ostatecznymi korzyściami, które określono.
Zarządzan i e ryzykiem (M_o_R) umiejscawia zarzą­
dzanie ryzyk iem w projekcie w kontekście szerszego
środowiska biznesowego.
Management of Risk: Guidance for Practitioners
(2007). The Stationery Office, London.
Skuteczne Zarządzanie Programami (MSP)
Skuteczne Zarządzanie Programami przedstawia
sprawdzone dobre praktyki zarządza nia programa-
m i w skutecznym przeprowadzaniu zm ian tra nsfor-
macyjnych w szerokiej gamie organizacj i sektora
publicznego i prywatnego. Dostarcza ono ram d la
zarządzania strategicznego i nadzorowania wdraża­
nia zbioru powiązanych projektów i dzialań w celu
dostarczenia rezultatów i korzyści związanych ze
strategicznymi celami organizacji.
Managing Successful Programmes (2007). The Statio-
nery Office, London.
Przewodnik Zarządzania Portfelem
Przewodnik Zarządzania Portfelem wyja śn i a klu-
czowe zasady zarządzania portfelem, wywodzące
si ę z doświadczeń organizacji sektora publicznego
i prywatnego w Wielkiej Brytanii i innych krajach.
Dostarcza on praktycznych rad na temat ustana-
wiania funkcji zarządzania portfelem, ilustrowa-
nych prawdziwymi przykładami z życia, i końc.zy się
sekcją na temat dalszych rad i wskazówek. Główny­
mi odbiorcami tego poradnika są zespoły odpowie-
dzialne za koordynację programów i proj ektów,
szczególnie te dosta rczające wspa rcia dla d ecyzj i
inwestycyj nych i raportuj ące postępy kierownictwu.
Założono, że czyteln icy maj ą pra ktyczną w i edzę na
temat zarządzania programami i projektami o raz
raportowania postępów.
Model dojrzałości organizacji w zakresie
zarządzania portfelem, programami
i projektami (P3M3"')
Model dojrzałości organizacji w zak resie zarządza­
nia portfelem, programami i projektami (P3M3) jest
przewodnikiem po ustrukturyzowanych naj lepszych
praktykach. Wprowadza on hierarchiczny podzi ał
szerokich dyscyplin za rządzan i a portfe lem, progra -
mami i projektami według określonych perspektyw.
Podejście hierarchiczne umożliwia organizacjom
ocenienie ich bieżącej zdolności, a następnie opraco-
wanie mapy ulepszeń uszeregowanej według priory-
tetów tych perspektyw, wynikających z ich wpływu
na osiągnięcia organizacji.
Biura zarządzania portfelem, programami
i projektami (P30)
Opracowanie pt. Biura zarządzania portfelem,
programami i projektami dostarcza wskazówek na
t emat jak zdefin iować, ustanowić i prowad zić biuro
za rządzania portfelem, programem lub projektem.
Obejmuje ono gamę funkcji i usług, które mogą
zapewnić biura P30 i zawiera odniesienia do tech-
nik, które można wykorzystać.
Portfolio, Programme and Project Offices (2008).
The Stationery Office, London.
330 I Dalsze informacje
Model Dojrzałości PRINCE2 (P2MM)
Model Dojrzałości PRINCE2 opisuje zbiór kluczo-
wych obszarów procesów (KPA - key process area)
wymaganych dla skutecznego wdrożenia oraz
wykorzystania metodyki PRINCE2 w organizacji. Jest
to podstawowa wa rtość P2MM. Podręcznik PRINCE2
opisuje, jak zarządzać poj edynczym projektem, ale
nie zawiera on procesów wdrażan i a PRINCE2. Model
dojrzałości P2MM zawiera te procesy.
P2MM opisuje kluczowe praktyki dopasowane
do procesów i komponentów PRINCE2, pozwala-
jące stosować metodykę w sposób powtarzalny
(Poziom 2), oraz idzie dalej opisując kluczowe
praktyki wymagane dla zinstytucjonalizowania tej
metodyki (Poziom 3) j ako standardowego procesu
biznesowego zarządzan i a projektami.
Proces przeglądu OGC Gateway Review
Proces przeg l ądu OGC Gateway jest uznanym proce-
sem nadzorczego przeglądu projektów i programów,
który obowiązkowy jest dla wszystkich brytyjskich
rządowych programów i projektów wysokiego ryzy-
ka. Przegląd OGC Gateway polega na przeglądzie
partnerskim, w ramach którego niezależni praktycy
spoza konkretnego programu/projektu wykorzystują
swoje doświadczenie i wiedzę fachową, aby prze-
anal i zować postępy i ocenić prawdopodobieństwo
pomyśl nej rea lizacji programu czy projektu. Proces
przeglądu zapewnia cenne dodatkowe spojrzenie na
zagadnienia, stojące przed zespolem wewnętrznym,
oraz stanowi zewnętrzne wyzwanie dla sol idności
planów i procesów. Usługa ta opiera się na dobrych
praktykach i we wszystkich branżach biznesu istnieje
wiele podobnych przykładów tego rodzaju przeglą­
dów partnerskich mających na celu zapewnienie nad-
zoru właścicielowi programu czy projektu.
Pelne szczegóły na temat procesu przeg l ądu OGC
Gateway dostępne są na stronie internetowej OGC 1•
Osiąganie doskonałości w budownictwie
Przewodnik dotyczący zamówień pt. Osiąganie
doskonałości w budownictwie należy do zbioru
11 przewodników i dwóch poradników wyższego
poziomu. Bazują one na dotychczasowych doświad­
czeniach agend rządu brytyjskiego, wspierają przy-
szłe strategie i dopasowane są do procesu przeglądu
OGC Gateway2 •
(www.ogc.gov.uk/what_is_ogc_gateway_review.asp)
2 3
(www.ogc.gov.uk/guidance_achieving_excellence_in_
construction.asp)
Poprzez inicjatywę Osiąganie doskonałości w budow-
nictwie, agendy rządu brytyjskiego oraz organizacje
sektora publicznego angażują się w maksymalizację,
poprzez ciągłe ulepszanie skuteczności, wydajności
oraz wartości uzyskiwanej dzięki ponoszonym nakla-
dom związanym z zamówieniami na nowe prace
budowlane, utrzymanie i remonty.
Praktyki Zarządzania Usługami ITILe
ITIL jest najszerzej akceptowanym podejściem do
zarządzania usługami informatycznymi na świecie.
Dostarcza ono spójny zbiór podręczników na temat
najlepszych praktyk pochodzących z sektora publicz-
nego i prywatnego w wielu krajach świata i zostało
ono niedawno zaktualizowane w ramach dużego,
ważnego projektu.
Zarządzan i e usługam iinformatycznymi (ITSM) czer-
pie ogromne korzyści z podejścia o partego na najlep-
szych praktykach. Ponieważ ITSM ukierunkowane jest
zarówno przez technologię, jak i ogromny wachlarz
środowisk organizacyjnych, w których jest stosowane,
pozostaje w stanie permanentnej ewolucji. Najlep-
sze praktyki, oparte na radach ekspertów i wkładzie
użytkowników ITIL, są zarówno aktualne jak i prak-
tyczne, łącząc najnowsze pomysły z solidnymi, zdro-
worozsądkowymi wskazówkam i.
Continua/ Service lmprovement (2007).
The Stationery Office, Lo ndon.
Service Design (2007). The Stationery Office, London.
Service Operation (2007). The Stationery Office,
London.
Service Strategy (2007). The Stationery Office,
London.
Service Transition (2007). The Stationery Office,
London.
WYDAWNICTWA THE STATIONERY OFFICE
(PUBLIKACJE UZUPEŁNIAJĄCE)
APMP3 dla praktyków PRINCE2
Podręcznik ten umożliwia
kandydatom zaznajo-
mionym z metodyką PRINCE2 przygotowanie się do
egzaminu APMP. Jest on dla kandydatów do egza-
minu APMP pojedynczym zbiorem materiałów źró­
dłowych, obejmującym wszystkie aspekty programu
APMP - Association for Project Management Profes-
sional

nauczania APMP. łączn i e z materia łam i wykorzy-
stywanymi zarówno przed kursem, jak i w trakcie
kursu, jed nocześnie dostosowanym do metodyki
PRINCE2. Umoż l iwi a to praktykom PRINCE2 (lub
personelowi zarządzania projektem pracującemu
w warunkach PRINCE2) na poszerzenie ich wiedzy
na temat zarządza nia projektami w celu zaznajo-
mienia się ze wszystkimi tematami w programie
nauczania APMP.
APMP for PRINCE2 Practitioners (2008).
The Stationery Office, London.
Seria wydawnictw Koncentracja na
umiejętnościach (zbiór trzech książek)
Seria wydawnictw Koncentracja na umiejętnościach
zajmuje si ę różnymi „miękk i mi umiejętnościami"
demonstrowanymi przez skutecznych kierowników
programów i projektów, pon i eważ bieżące koor-
dynowanie, motywowanie i aspekty komunikacji
w za rządzan iu proj ektem i programem są bardzo
podobne.
Leadership Ski/Is for Project and Programme
Managers (2008). The Stationery Office, London.
Team Management Ski/Is for Project and Programme
Managers (2008). The Stationery Office, London.
Communication Ski/Is for Project and Programme
Managers (2008). The St ationery Office, Lo ndon.
Zwinne metody zarządzania projektem:
prowadzenie projektów zgodnych
z PRINCE2 z wykorzystaniem OSOM A tern
Ta rewolucyjna ksi ążka
pokazuje, j ak użytkown icy
mogą połączyć silne strony obydwu rozważanych
podejść metodologicznych tak, że uzupełn iaj ą się
one i tworzą nowe, naj lepiej wyselekcjonowane
ramy odpowiednie dla wszystkich środowi sk projek-
tów. Opierając si ę na metodykach PRINCE2 i OSOM
Atern, dwóch najbard ziej uznanych i międzynaro­
dowo rozpoznawanych podejści ach do zarządzan i a
projektami, zbadano różn i ce pomiędzy obydwoma
podejściami przed pokazaniem, gdzie się pokrywaj ą
i w jaki sposób mogą zostać zintegrowane. Chociaż
OSOM Atern jest samodz i elną metodyką zarządza­
nia projektami, ta nowa publikacja mieści s i ę w serii
tytu łów związanych z PRINCE2.
Agile Project Management: Running PRINCE2 Pro-
jects with OSOM Atern (2007). The Stationery Office,
London.
Dalsze informacje I 331
Poprawa realizacji projektów przy
wykorzystaniu modelu dojrzałości
PRINCE2
Metodyka PRINCE2 cytowana j est jako naj szerzej
stosowana metodyka zarządzania projektami na
świecie, ale, chociaż podręcznik PRINCE2 opisuje,
w jaki sposób zarządzać pojedynczym projektem,
to nie zawiera on żadnych wskazań, w jaki sposób
wd rażać metodykę PRINCE2 w organizacji.
Wskazania takie są teraz dostępne. Omawiana
publikacja opisuj e procesy i praktyki organizacyjne
wymagane d la skutecznego wdrożen i a metodyki
PRINCE2 j ako standardu organizacyjnego. Zawiera
ona wskazówki na temat przypisywania odpowie-
dz i alności, dopasowywania metodyki, szkoleń, inte-
growania PRINCE2 z innymi systemami za rządczym i
oraz ustanawiania mechanizmów nadzoru j akości
w celu uzyskania ci ągłej zdo l ności do ulepszania.
Czytaj ąc publikację
lmproving Project Performance
using the PRINCE2 Maturity Model, odkryjesz, j ak
organizacje mogą uzyskać pełną wartość z metodyki
PRINCE2. Zawiera ona praktyczne porady na temat
korzystania z Modelu dojrzałości PRINCE2 OGC
(P2MM) i pokazuje, j ak P2MM może być stosowany
w różnych sytuacjach.
lmproving Project Performance using the PRINCE2
Maturity Model (2007). The Stationery Office,
London.
INNE ŹRÓDŁA
Poniższa lista zawiera użyteczne publikacje, z któ-
rych niektóre cytowane są przez autorów podręczni­
ków na temat PRINCE2.
Adair, John (2004) The John Adair Handbook of
Management and Leadership, Thorogood,
ISBN 978-1854182043.
APM GoPM Specific lnterest Group (2005) Oirec-
ting Change: A Guide to the Governance of Project
Management, 2"d edition, Association for Project
Management, High Wycombe, ISBN 1-903494-15-X.
Association of Project Management (2006) APM
Body of Knowledge, s•h edition, High Wycombe,
ISBN 978-1903494134.
332 I Dalsze informacje

British Standards Institution (2002) 856079- 1:2002

A Guide to Project Management, BSI, London.
Goldratt, Eliyahu M. (1997) Critical Chain, Avebury,
ISBN 978-0566080388.
International Project Management Association
(2006) ICB-IPMA Competency Baseline, version 3.0,
ISBN 0-9553213-0-1.
Project Management Institute (2004) A Guide to the
Project Management Body of Know/edge: PM BOK
Guide, 4th edition, ISBN13 9781933890517.
Winter, Mark and Smith, Charles (2006) Rethinking
Project Management, EPSRC Network 2004-2006.
Leksykon

Kursywą w nawiasach kwadratowych podano angielskie odpowiedniki.

akceptowanie Reakcja na zagrożenie, której istotą jest podjęcie świadomej i przemyślanej decyzji
(reakcja na ryzyko) o braku reakcji na dane zagrożenie, po rozpoznaniu, że powstrzymanie się od
dzialania jest bardziej ekonomiczne niż próba reagowania na ryzyko. Zagrożenie
[accept] takie powinno być następnie monitorowane w celu upewnienia się, że pozostaje
na tolerowalnym poziomie.
akceptacja Formalne działanie potwierdzające. iż projekt spełnił uzgodnione kryteria akcepta-
cji, a w ten sposób spełnił też wymagania jego interesariuszy.
[acceptance]
akceptacja eksploatacji Szczególny rodzaj akceptacji przez osobę lub grupę, która będzie utrzymywała
i utrzymania produkt po przekazaniu go do eksploatacji.
[operational and maintenance
acceptance]
akceptacja użytkownika Szczególny rodzaj akceptacji przez osobę lub grupę, która będzie korzystać z pro-
duktu po przekazaniu go do środowiska operacyjnego.
[user acceptance]
apetyt na ryzyko Indywidualne nastawienie danej organizacji do podejmowania ryzyka, które z ko-
lei wyznacza poziom ryzyka, jaki ta organizacja uważa za możliwy do zaakcepto-
[risk appetite] .
wania.
biuro projektu Biuro ustanowione na pewien czas w celu wsparcia realizacji konkretnej inicjatywy
wprowadzenia zmiany realizowanej jako projekt. Jeżeli je utworzono, biuro projektu
[project office]
przyjmuje na siebie obowiązki roli Wsparcia Projektu.
bliskość (ryzyka) Czynnik czasowy ryzyka - kiedy ryzyko może się zmaterializować. Wielkość wpływu
ryzyka może się zmieniać w zależności od tego, kiedy się ono zmaterializuje.
[proximityJ
budżet zmian $rodki pieniężne przydzielone Obsłudze Zmian przeznaczone na realizację zatwier-
dzonych wniosków o wprowadzenie zmian.
[change budget]
centrum doskonałości Jednostka organizacyjna koordynująca portfel, programy i projek ty, określająca
standardy, zapewniająca spójność metod i procesów, zarządzanie wiedzą oraz
[centre of excellence]
nadzór i szkolenia.
cykl życia projektu Okres od zakończenia przygotowania projektu aż do akceptacji Produktu Końco­
wego Projektu.
[project lifecycle]
diagram następstwa Diagram pokazujący kolejność wytwarzania oraz wzajemne zależności pomiędzy
produktów produktami wymi enionymi w strukturze podziału produktów.
[product flow diagram]
docelowe wskaźniki Cele planu określone w kategoriach czasu, kosztów, jakości, zakresu, korzyści
wykonania i ryzyka.
[performance targets]
Dokumentacja Inicjowania Zbiór dokumentów tworzących logiczną calość. który zestawia razem najistotniej-
Projektu sze informacje potrzebne do rozpoczęcia projektu na solidnej podstawie i służy do
przekazania tych informacji wszystkim stronom zainteresowanym projektem.
[Project lnitiation
Documentation]
336 I Leksykon

dostawca Osoba, grupa lub kilka grup odpowiedzialnych za dostawę/wytworzenie produk-

tów specjalistycznych projektu.
[supplier]
dostosowanie Właściwe wykorzystanie PRINCE2 w odniesieniu do danego projektu, polegające
na zapewnieniu prawidłowego poziomu planowania, kontroli, ladu oraz na za-
[tailoring]
stosowaniu procesów i tematów. Natomiast przyj ęcie metodyki PRINCE2 w całej
organizacji jest nazywane „wdrożeniem" .
OSOM Atern Metoda realizacji projektu z rodziny metod zwinnych (agile), opracowana przez
i będąca własnością konsorcjum OSOM. Atern jest zgodnym z PRINCE2 podej-
ściem, wykorzystującym do wytwarzania produktów krótkie iteracje o określonym
czasie trwania.
- -- - -
działania korygujące Zbiór czynności podejmowanych w celu zażegnan ia zagrożenia tolerancji dla pla-
nu lub usuni ęcia wady produktu.
[corrective action]
działanie Proces, funkcja lub zadanie, które trwa przez jakiś czas, które ma rozpoznawalny
wynik i jest zarządzane. Jest zwykle definiowane jako część procesów lub planów.
[activity]
Dziennik Projektu Wykorzystywany do zapisywania problemów/obaw, które mogą być obsłużone
przez Kierownika Projektu w trybie nieformalnym.
[Daily log]
Dziennik Doświadczeń Nieformalne repozytorium doświadczeń, które mają zastosowanie w tym projek-
cie łub w przyszłych projektach.
[Lessons Log]
dzienniki Nieformalne repozytoria zarządzane przez Kierownika Projektu, które nie wyma-
gają żadnych uzgodni eń z Komitetem Sterujący1n co do ich fonnatu i zawartości .
[logs]
W PRINCE2 są dwa dzienniki: Dziennik Projektu i Dziennik Doświadczeń .
etap Patrz: „ etap zarządczy" lub „etap techniczny".
----
[stage]
etap inicjowania Okres od zezwolenia przez Komitet Sterujący na zainicjowanie projektu do ze-
zwolenia na real izację projektu (lub podjęcie decyzji, że projekt nie będzie reali-
[initiation stage]
zowany). Szczegółowe planowanie oraz stworzenie infrastruktury zarządza nia
projektem są realizowane w trakcie tego etapu w procesie Inicjowanie Projektu.
etap techniczny Metoda grupowania pracy według zbioru stosowanych technik lub wytwarzanych
produktów. W wyniku takiego grupowania etapy obejmują elementy takie, jak:
[technical stage]
projektowanie, budowę czy wdrażanie. Takie etapy są etapami technicznymi i są
pojęciem innym n iż etapy zarządcze.
- -- - -
etap zarządczy Etap zarządczy to część projektu, którą Kierownik Projektu zarządza w imieniu
Komitetu Sterującego w danym czasie. Po jej zakończeniu Komitet Sterujący do-
[management stage]
konuje przeglądu dotychczasowych postępów, stanu realizacji Planu Projektu,
Uzasadnienia Biznesowego oraz ryzyk, a także Planu (następnego) Etapu, w celu
podjęcia decyzji, czy projekt należy kontynuować.

ewaluacja ryzyka Proces zrozumienia efektu netto zidentyfikowanych zag rożeń i szans dla danego
działa nia, gdyby je połączyć.
[risk evaluation]
- -- - -
formuła realizacji projektu Opis sposobu, w jaki mają być realizowane prace projektu. Przykładowo, tworzy-
my produkt od początku albo kupimy produkt już istniejący.
[project approach]
Główny Dostawca Rola w Komitecie Sterującym , która dostarcza wi edzy i doświadczenia w zakresie
głównych dyscyplin związanych z wytwarzaniem produktów, które projekt ma
[Senior Supplier]
dostarczyć. Główny Dostawca reprezentuje w projekcie interesy dostawcy i udo-
stępnia zasoby dostawcy.
 Leksykon I 337

Główny Użytkownik Rola w Komitecie Sterującym odpowiedzialna za zagwarantowanie, że potrzeby

użytkownika są prawidłowo określone oraz że dostarczone rozwiązan ie spełn ia te
[Senior User]
potrzeby.
Grupa Zadań Zbiór informacji niezbędnych do wytworzenia jednego lub większej liczby pro-
duktów. Zawiera on: opis działań, Opis(-y) Produktu(-ów), szczegóły wszelkich
{Work Package]
ograniczeń dotyczących wytwarzania oraz potwierdzenie uzgodnienia po1niędzy
Kierownikiem Projektu a osobą lub Kierownikiem Zespołu, który ma wykonać tę
Grupę Zadań, że praca może być wykonana w ramach tych og ran iczeń.

harmonogram
[schedule]
horyzont planowania
[planning horizon]
inspekcja jakości
[quality inspection]
interesariusz
[stakeholder]
Graficzna ilustracja planu (na przykład w fonnie wykresu Gantta), opisująca
zwykle kolej ność zadań wraz z przydziałem zasobów, które łącznie zapewnią re-
alizację tego planu. Zgodnie z PRINCE2 wszelkie działania projektu powinny być
udokumentowane wyłącznie w harmonogramach związanych z Planem Projektu,
Planem Etapu lub Planem Zespołu. Czynności, które są przydzielane w ramach
bieżącego zarządzania, mogą być udoku1nentowane w odpowiednim dzienniku
lub rejestrze (tj. w Rejestrze Ryzyk, Dzienniku Projektu, Rejestrze Zagadnień czy
Rejestrze Jakości), jeżeli nie wymagają podjęcia istotnych działań.
Okres, dla którego możl iwe jest dokładne planowanie.
Systematyczny, uporządkowany proces oceny produk tu przeprowadzany przez
dwie lub więcej starannie wybranych osób (zespól kontrolerów) w sposób zapla-
nowany, udokumentowany i zorganizowany.
Osoba fizyczna, grupa lub organizacja, która może mieć wpływ, może znaj dować
się pod wpływem lub może uważać siebie za kogoś, na kogo oddzialywuje dane
przedsi ęwzięcie (program, projekt, działan ie, ryzyko).

jakość Ogól cech oraz inherentnych lub przypisanych charakterystyk produktu, osoby, pro-
cesu, usługi i/lub systemu, które umożl iwiają wykazanie, że spełnia on oczekiwania
[quality]
lub zaspokaja ok reślone potrzeby, wymagania lub jest zgodny ze specyfikacją.
kamień milowy Ważne zdarzenie w harmonogramie planu, takie jak ukończenie kluczowych Grup
Zadań, etapu technicznego czy etapu zarządczego.
[milestone]
kategoria reakcji na ryzyko Rodzaj reakcj i na ryzyko. W odniesieniu do zagrożeń poszczególne możliwe kate-
gorie reakcji na ryzyko to: uniknanie, redukowanie, przeniesienie, akceptowanie
[risk response category]
lub współdzielenie ryzyka. W odniesieniu do szans poszczególne możliwe katego-
rie reakcji na ryzyko to: wykorzystanie, wzmocnienie, odrzucenie lub współdziele­
nie ryzyka.
Kierownik Projektu Osoba, której powierzono uprawnienia i obowiązek bieżącego zarządzan ia opera-
cyjnego projektem, aby dostarczył on wymagane produkty w granicach uzgodnio-
[Project Manager]
nych z Komitetem Sterującym.
Kierownik Zespołu Osoba odpowiedzialna za wytworzenie produktów przydzielonych przez Kierow-
nika Projektu, jak to określono w Grupie Zadań, o odpowiedniej jakości, w ter-
{Team Manager]
minie i w granicach kosz tów akceptowalnych dla Komitetu Sterującego . Ta rola
podlega Kierownikowi Projektu i otrzy1nuje od niego instrukcje. Jeżeli Kierownik
Zespołu nie zostanie wyznaczony, obowiązki związane z rolą Kierownika Zespołu
pełn i Kierownik Projektu.

klient Osoba lub grupa, która zleciła pracę i odniesie korzyści z jej końcowych rezultatów.
[customer]
kontrola jakości Proces monitorowania konkretnych rezu ltatów projektu w celu stwierdzenia, czy
odpowiadają one stosownym standardom, i określenia sposobów eliminowania
[quality control]
przyczyn niesatysfakcjonujących osiągn ięć.
338 I Leksykon

kontroler Osoba lub zespól niezależny od wytwórcy, który ocenia, czy produkt spełnia wy-
magania określone w jego Opisie Produktu.
[reviewer]
- - - - -- - - - -
korzy ś ć Mierzalna poprawa wynikająca z osiągniętego rezultatu uznawana przez jednego
lub więcej interesariuszy za zaletę.
[benefi t]
kryteria akceptacji Zawierająca priorytety lista kryteriów, które musi spelnić Produkt Końcowy Projek-
tu zani1n zostanie zaakceptowany przez klienta, tj. lista cech określonych w kate-
[acceptance cri teria]
goriach mierzalnych, które musi mieć grupa produktów, aby była akceptowalna
dla kluczowych interesariuszy.
kryteria jakości Opis specyfikacji wymagań jakościowych, jakie produkt musi spelniać oraz pomia-
rów jakościowych, jakie zostaną wykonane przez osoby przeprowadzające inspek-
[quality criteria]
cję gotowego produktu.
- - -- - - -- - -
linia tolerancji ryzyka Li nia zaznaczona na sumarycznym profilu ryzyka. Ryzyka, które pojawiają się ponad
tą l inią, nie mogą być akceptowane (tolerowane) bez przekazania informacji o nich
[risk toleran ce line]
na wyższy szczebel zarządzania. W przypadku projektu, Kierownik Projektu przeka-
zuje takie ryzyka Komitetowi Sterującemu.
lista kont rolna produktów Lista glównych produktów ujętych w planie, wraz z kluczowymi terminami zwią­
zanymi z ich dostawą .
[product checklist]
lokalizacj a projektu Miejsce, w którym projekt jest realizowany (na przyklad biuro lub plac budowy).
[host site]
- - -- - -- -
ład(w odniesieniu Stale dzialanie utrzymujące solidny system kontroli wewnętrznej, za pomocą któ-
do korporacji) rego dyrektorzy i kierownicy organizacji zapewniają, że w celu ochrony aktywów,
zwiększania zdolności oraz budowania reputacji organizacji wdrożono skuteczne
[governance (corporate)]
systemy zarządzania, obejmujące systemy monitoringu i kontroli finansowej,
------------~
ład(w odniesieniu Te obszary ladu korporacyjnego, które wiążą si ę szczególnie z dzialaniami
do projekt u) w projektach. Efektywny ład zarządzania projektami zapewnia, że portfel pro-
jektów organizacji jest zgodny z celami organizacji, jest sprawnie realizowany
[governance (project)]
i jest zrównoważony.
mechanizm sterow ania Mechanizm sterowania o charakterze cyklicznym, umożliwiający organowi wyższe­
zależny od czasu go szczebla monitorowanie postępów, np. taki element sterowania, który występu­
je co 2 tygodnie. PRINCE2 oferuje dwa podstawowe główne raporty o postępach
[time-driven control]
prac zależne od czasu: Raport z Punktu Kontrolnego i Raport Okresowy.
mechanizm sterow ania Jest to mechanizm sterowania, który jest uruchamiany w przypadku wystąpienia
zależ ny od zdarzeń konkretnego zdarzenia. Może to być na przyklad: koniec etapu, skompletowanie
Dokumentacji Inicjowania Projektu czy sporządzenie Raportu Nadzwyczajnego.
[e vent-driven control]
Mogą to być również zdarzenia organizacyjne, które wplywają na projekt, takie
jak koniec roku finansowego.
metody kaskadow e Metoda kaskadowa opisuje formulę realizacji, która ma charakter liniowy i sekwen-
cyjny, z od rębnymi celami dla każdej fazy realizacji. Po zakończeniu danej fazy re-
[ waterfall methods]
alizacji następuje przejście do kolejnej fazy i nie ma powrotu do wcześniejszych faz
(stąd analogia - woda splywająca kaskadami nie może wracać pod górę).

metody zwinne Głównie są to metody tworzenia oprogramowania, które stosują formułę reali-
zacji projektu wykorzystującą stale i krótkie iteracje o określonym czasie trwania,
[agile methods]
w trakcie których produkty są wytwarzane przyrostowo. Metodyka PRINCE2 jest
zgodna z zasadami zwinnych metod.
 Leksykon I 339

nadzór Ogól systematycznych czynności, koniecznych dla uzyskania pewności, że nadzo-

rowany obiekt jest odpowiedni. Przedmiotem nadzoru może być : system, proces,
{assurance]
organizacja, program, projekt, rezu ltat, korzyść, zdol ność, produkt czy przedmiot
dostawy. Odpowiedniość może być zdefiniowana subiektywnie lub obiektywnie
w zależności od warunków. Z tego wynika, że nadzór powinien mieć pewien
stopień niezależności od tego, co nadzoruje. Patrz . Nadzór Projektu" i .nadzór
jakości".

nadzór jakości
{quality assurance]
Nadzór Projektu
{Project Assurance]
~~~~~~~~-~~~~~~~-
Niezależne sprawdzenie, czy produkt będzie odpowiadał swojemu przeznaczeniu
lub spelni wymagania.
Obowiązki Komitetu Sterującego polegające na upewnieniu się, że projekt jest
prowadzony prawidłowo. Każdy członek Komitetu Sterującego koncentruje się na
określonym obszarze Nadzoru Projektu, tzn. na nadzorze biznesowym - Przewod -
niczący, nadzorze ze strony użytkownika - Glówny Użytkownik (Główni Użytkow­
nicy) oraz nadzorze ze strony dostawcy - Główny Dostawca (Glówni Dostawcy).

niepożądany skutek Rezultat postrzegany jako niekorzystny przez jednego lub więcej interesariuszy.
Jest to nieuchronna konsekwencja d ziałania, w przeciwi eństwie do zagrożen i a,
{dis-benefit]
które z definicji zawiera ja kąś niepewność dotyczącą jego ewentualnego zmate-
rializowania.
obiekt konfiguracji Element podlegający zarządzaniu konfiguracją. Elementem tym może być frag-
ment produktu, produkt lub zbiór produktów wchodzących w skład wydania.
{configuration Item]
obiekt/poziom odniesienia Obiekt lub poziom bazowy, względem którego dany obiekt fjednostka) jest moni-
torowany i kontrolowany.
{baseline]
Obsługa Zmian Osoba lub grupa osób, której Komitet S terujący może del egować obowiązki
decydowania o wnioskach o wprowadzenie zmian lub o zgłoszonych odstęp­
{Change Authority]
stwach (niezgodnościach). Obsługa Zmian może mieć przyd zielony budżet
zmian i może zatwierdzać zmiany w ramach tego budżetu .
~~~~~~~~~~~~~~~~

Ocena Końcowa Etapu Przegląd Raportu Końcowego Etapu dokonywany przez Komitet Sterujący
i Kierownika Projektu w celu podjęcia decyzji, czy zatwierdzić Plan (następnego)
{End Stage Assessment]
Etapu. W zal eżności od wielkości i znaczenia projektu, przegląd ten może mieć
charakter formalny lub nieformalny. Zezwolenie na kontynuowanie projektu
powinno zostać udokumentowane jako forma lny zapis.
~~~~~~~~~~~~~~~~~

ocena sytuacji nadzwyczajnej
[exception assessment]
oczekiwania jakościowe
klienta
Jest to przegląd dokonywany przez Komitet Sterujący w celu zatwierdzenia (lub
odrzucenia) Planu Nadzwyczajnego.
Oświadczenie dotyczące jakości
oczekiwanej od produktu projektu zapisane
w Opisie Produktu Końcowego Projektu.

{customer's quality
expectations]
odrzucenie
(reakcja na ryzyko)
{reject]
odstępstwo (niezgodność)
{ off-specification]
~~~~~~~~~~~~~~~~
Reakcja na ryzyko (szansę) polegająca na podjęciu świadomej i przemyślanej
decyzji o jej niewykorzystaniu lub niew zmocnieniu, po rozpoznaniu, że bardziej
ekonomiczne jest tak postąpić niż próbować podejmować jakąś inną reakcję na to
ryzyko. Taka szansa powinna być nadal monitorowana.
Coś, co powinno być dostarczone przez projekt, ale nie jest (lub przewiduje się,
że nie będzie), a czego Kierownik Projektu nie jest w stanie zapewnić w granicach
uzgodnionych tolerancji. Może to być brakujący produkt lub produkt, który nie
jest zgodny ze swoją specyfikacją. Jest to rodzaj zagadnienia.

ograniczenia Restrykcje, którym podlega projekt.

{constraints]
340 I Leksykon

Opis Produktu Opis przeznaczenia, składu, pochodzenia i kryteriów jakości produktu. Powstaje
w czasie planowania, możliwie jak najszybciej po stwierdzeniu zapotrzebowania
[Product Description]
na ten produkt.
Opis Produktu Końcowego Specjalny rodzaj Opisu Produktu, który jest wykorzystywany dla uzyskania zgody
Projektu użytkown ika na zakres i wy1nagania projektu oraz w celu określenia oczekiwań
jakościowych klienta oraz zdefiniowania kryteriów akceptacji dla projektu.
[Project Product Description]
opis roli Opis zbioru obowiązków specyficznych dla danej roli.
[role description]
organ odpowiedzialny Osoba lub zespól zlecający projekt (zwykle kierownictwo organizacji lub progra-
mu) uprawniony do zaangażowania zasobów i funduszy w imieniu organizacji
{responsible authority]
złecające1 projekt.

oszacowanie ryzyka Oszacowanie prawdopodobieństwa i wplywu pojedynczego ryzyka, biorąc pod

uwagę przyjęte standardy, docelowe poziomy ryzyka, wspólzależności i inne istot-
[risk estimation]
ne czynniki.
~~~~~~~~~~~ ~~~~~~~~~-

plan Szczeg óIow a propozycja wykonania lub osiąg nięcia czegoś wyka zująca szczegó-
lowo co, kiedy, jak i przez kogo. W PRINCE2 występuj ą tylko następujące plany:
[plan]
Plan Projektu, Plan Etapu, Plan Zespolu, Plan Nadzwyczajny i Plan Przeglądu
Korzyści.

Plan Etapu Szczególowy plan, wykorzystywany jako podstawa dla sterowania projektem
w trakcie etapu.
[Stage Plan]
Plan Nadzwyczajny Jest to plan, który często jest następstwem Raportu Nadzwyczajnego. W przy-
padku sytuacji nadzwyczajnej dotyczącej Planu Etapu, plan ten obejmuje okres od
[Exception Plan]
dnia bieżącego do końca bieżącego etapu. Jeśl i sytuacja nadzwyczajna mialaby
miejsce na poziomie projektu, zastąpilby Plan Projektu.
Plan Projektu Plan wysoki ego poziomu, pokazujący glówne produkty projektu, terminy ich do-
starczenia i koszty. Pierwotny Plan Projektu jest przedstawiany jako część Doku -
[Project Plan]
mentacji Inicjowania Projektu. Jest on uaktualniany w miarę naplywu informacji
o faktycznych postępach . Dla Komi tetu S terującego jest to glówny dokument
do sterowania projektem, slużący do mierzenia faktycznych postępów w stosunku
do oczekiwań .
Plan Przeglądu Korzyści Określa, jak i kiedy można dokonać pomiaru korzyści wynikających z projektu. Jeśli
projekt jest zarządzany w ramach programu, ta informacja może powstać i być
{Benefits Review Plan]
utrzymywana na poziomie programu.
~~~~~~~~~~~~~

plan rezerwowy Reakcja na zagrożenie polegająca na przygotowaniu planu rezerwowego dla dzia-
(reakcja na ryzyko) łań, które będą podjęte w celu zredukowania skutków zagrożen ia, gdy ryzyko się
zmaterializuje.
[fal/back] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-

P1an Zespołu Opcjonalny plan, wykorzystywany jako podstawa do zarządzania zespolem pod-
czas wykonywania Grup Zadań.
[Team Plan]~~~~~~~~~~~~~~~~~~~~~

planowanie oparte na Technika tworzenia wszechstronnego planu opartego na wytworzeniu i dostawie

produktach wymaganych produktów. Technika ta uwzględnia warunki wstępne, produkty,
wymagania jakościowe oraz zależności między produktami.
[product-based planning]
planowe zamknięcie Działania w ramach PRINCE2 w celu zamknięcia projektu zgodnie z planem.
[planned closure]
portfel Wszystkie programy oraz niezależne projekty realizowane przez organizację,
grupę organizacji lub jednostkę organizacyjną.
[portfolio]

powiadomienie
o zainicjowaniu projektu
[project initiation notification]
powiadomienie
o przygotowywaniu projektu
[project start-up notification]
powiadomienie o zamykaniu
projektu
[c/osure notification]
powiadomienie o zezwoleniu
na realizację projektu
[project authorisation
notification]
prawdopodobieństwo
[probability]
PRINCE2
[PRINCE2]
problem/obawa
[problemlconcern]
procedura
[procedure]
proces
[process]
produkt
[product]
produkt projektu
[project product]
produkt specjalistyczny
[specialist product]
produkt zarządczy
[management product]
Leksykon I 341
Powiadomienie ze strony Komitetu Sterującego, skierowane do wszystkich intere-
sariuszy i jednostek, w których projekt będzie realizowany. Informuje, że projekt
jest zainicjowany, oraz poleca udzielić niezbędnego wsparcia logistycznego (np.
środków komunikacji, sprzętu czy innego wsparcia projektu), wystarczającego na
etapie inicjowania.
Powiadomienie jednostek, w których projekt będzie realizowany, że wkrótce roz-
pocznie się przygotowanie projektu. Zawiera polecenie świadczenia potrzebnych
usług Wsparcia Projektu.
Informacja przekazywana przez Komitet Sterujący wszystkim interesariuszom oraz
organizacjom, w siedzibach których projekt jest realizowany, o tym, że można zwol-
nić zasoby projektu oraz zakończyć świadczenie uslug pomocniczych, takich jak
udostępnianie pomieszczeń, wyposażenia oraz dostępu do urządzeń . Powinno ono
zawierać również termin zamknięcia rachunku kosztów obciążających projekt.
Powiadomienie ze strony Komitetu Sterującego skierowane do wszystkich intere-
sariuszy i jednostek, w których projekt będzie realizowany. Informuje, że projekt
został zatwierdzony do realizacji, oraz poleca udzielić niezbędnego wsparcia
logistycznego (np. środków komunikacji, sprzętu czy innego wsparcia projektu),
wystarczającego na okres realizacji projektu.
Jest to oszacowana liczbowo możliwość faktycznego wystąpienia konkretnego za -
grożenia lub szansy, z rozważeniem częstotliwości, z jaką może ono występować.
Metodyka, która wspiera wybrane aspekty zarządzan ia projektem. Nazwa jest
akronimem angielskiego określenia Projects in a Controlled Environment, co
oznacza „projekty w sterowalnym środowisku".
Rodzaj zagadnienia (inny niż wniosek o wprowadzenie zmiany czy odstępstwo),
które Ki erownik Projektu musi rozwiązać lub przekazać na wyższy szczebel za-
rządzan ia.
Wyspecyfikowany szereg czynności dotyczących konkretnego aspektu zarządzania
projektem ustalony specjalnie dla danego projektu, na przykład procedura zarzą­
dzania ryzykiem.
Ustrukturyzowany zbiór działań zaprojektowany w celu osiągnięcia konkretnego
celu. Proces pobiera jeden lub większą l iczbę określonych elementów wejściowych
i przeksztalca je w określone elementy wyjściowe .
Element wejściowy lub wyjściowy, w formie materialnej lub niematerialnej, który
można wcześniej opisać, wytworzyć i sprawdzić. PRINCE2 wyróżnia dwa rodzaje
produktów - produkty zarządcze oraz produkty specjalistyczne.
To, co projekt musi dostarczyć w celu uzyskania akceptacji.
Produkt, który jest przekazywany użytkownikowi lub użytkownikom. Należy zwrócić
uwagę, że produkty zarządcze nie są produktami specjalistycznymi, bo są tworzone
wylącznie na potrzeby zarządzania projektem.
Produkt potrzebny jako element zarządzan ia projektem oraz ustanowienia
i utrzymania j akości (na przykład: Raport Okresowy, Raport Końcowy Etapu itd.)
Produkty zarządcze pozostają takie same niezależnie od rodzaju projektu i mogą
być używane we wszystkich projektach, jak opisano lub z odpowiednimi mo-
dyfikacjami. Istn i eją trzy rodzaje produktów zarządczych: produkty bazowe, dla
których są tworzone obiekty odniesienia, zapisy oraz raporty.
342 I Leksykon

produkt za rządczy bazowy Rodzaj produktu zarządczego określającego aspekty projektu, który po zatwier-
dzeniu staje się obiektem odniesienia i podlega sterowaniu zmianami.
product]
_.;;...._ _______________________________
[baseline management
~

profil ryzyka Opis rodzajów ryzyka, na które narażona jest dana organizacja oraz stopień
narażenia na te ryzyka.
{risk profile]
program Elastyczna struktura organizacyjna utworzona na pewien czas dla koordynacji,
zarządzania strategicznego i nadzorowania realizacji zbioru powiązanych ze sobą
{programme]
projektów i dzialań. w celu osiągnięcia oczekiwanych rezultatów i korzyści zwią-
zanych z celami strategicznymi organizacji. Program może trwać kilka lat.
----------~
projekt Tymczasowa organizacja powolana w celu dostarczenia jednego lub więcej pro-
duktów biznesowych wedlug uzgodnionego Uzasadnienia Biznesowego.
{project]
- -- - - -- -
projekt zgodny z PRINCE2 Projekt, który stosuje wszystkie pryncypia (zasady) PRINCE2.
{PRINCE2 project]
pryncypia (zasady) PRINCE2 Nakazy przewodnie dobrych praktyk zarządzania projektami. które są podstawą
projektu zarządzanego z wykorzystaniem PRINCE2.
{PRINCE2 principles]
przedmiot dostawy Patrz „produkt".
{deliverable]
- - - -- - - -
przedwczesne zamkn ięcie Dzialanie w ramach PRINCE2 podejmowane w celu zamknięcia projektu przed
jego planowym zamknięciem. Kierownik Projektu musi upewnić się, że prace
{premature c/osure]
w toku nie są po prostu przerwane i porzucone, ale że wszelkie wartości wytwo-
rzone do tej pory w projekcie zostaną uratowane, oraz sprawdzić, czy informacje
o wszelkich brakach spowodowanych przerwaniem projektu są przekazane kie-
rownictwu organizacji/programu.
----------Patrz: „inspekcja jakości ".
przegląd ja kości

{quality re view ]
- - -- -- - -
przekazanie Przeniesienie odpowiedzialności za zestaw produktów na wlaściwego użytkow­
nika(-ów). Taki zestaw produktów nazywany jest wydaniem. W trakcie projektu
[handover]
może wystąpić więcej niż jedno przekazanie (dostawy stopniowe). Ostateczne
przekazanie ma miejsce w procesie Zamykanie Projektu.
----------~ - - -- -- -
przeniesienie Reakcja na zagrożenie, w ramach której strona trzecia przejmuje odpowiedzial-
(reakcj a na ryzyko) ność za część finansowych implikacji wynikających ze skutków zagrożenia (na
przyklad przez ubezpieczenie lub za pomocą odpowiednich klauzul umownych).
{transfer]
--------
Przewodn iczący Osoba, która ponosi pelną odpowiedzialność za zapewnienie, że projekt zrealizuje
swoje cele i przyniesie zaplanowane korzyści. Osoba ta powinna zagwarantować,
[Executive]
że projekt koncentruje się na aspekcie biznesowym. ma jasno określon e upraw-
nienia oraz że wszelkie prace. wraz z ryzykami, są aktywnie zarządzane. Przewod-
niczący kieruje pracami Komitetu Sterującego, reprezentuje klienta i jest odpowie-
dzialny za Uzasadnienie Biznesowe.
----------~
przygotowanie Dzialania przedprojektowe, podejmowane przez Przewodniczącego Komitetu
Sterującego i Kierownika Projektu w celu opracowania zarysu Uzasadnienia Bizne-
{start up]
sowego, Zalożeń Projektu oraz Planu Etapu Inicjowania.
-------~

punkt kontrolny Przegląd postępu prac na szczeblu zespolu, odbywający się w określonych ter-
minach.
{checkpoint]
- - -- - - -

Raport Doświadczeń
{Lessons Report]
Raport Końcowy Etapu
{End Stage Report]
Raport Końcowy Projektu
{End Project Report]
Raport Nadzwyczajny
{Exception Report]
Raport o Zagadnieniu
{lssue Report]
Raport Okresowy
[Highlight Report]
Raport z Punktu Kontrolnego
{Checkpoint Report]
raporty
{reports]
reakcja na ryzyko
{risk response]
redukowanie (reakcja na
ryzyko)
{reduce]
Rejestr Jakości
[Quality Register]
Rejestr Ryzyk
{Risk Register]
Rejestr Zagadnień
{lssue Register]
rejestry
{registers]
rekomendacja zamknięcia
projektu
{c/osure recommendation]
Leksykon I 343
Raport dokumentujący wszelkie doświadczenia, które można wykorzystać z po-
żytkiem w innych projektach. Celem raportu jest wywołanie działania, w wyniku
którego pozytywne doświadczenia będą trwałe wykorzystywane w sposobie pra-
cy organizacji, a organizacja będzie zdolna uniknąć negatywnych doświadczeń
w przyszłych projektach.
Raport przekazywany Komitetowi Sterującemu przez Kierownika Projektu na za-
kończenie każdego etapu zarządczego projektu. Dostarcza infonnacji o osiągnię­
ciach projektu w trakcie etapu oraz o stanie projektu na końcu etapu.
Raport przekazywany Komitetowi Sterującemu przez Kierownika Projektu potwier-
dzający przekazanie wszystkich produktów, zawierający uaktualnione Uzasadnienie
Biznesowe oraz ocenę stopnia zgodności wyników projektu z pierwotną Dokumen-
tacją Inicjowania Projektu.
Raport opisujący sytuację nadzwyczajną, jej wpływ, opcje postępowania, reko-
mendację oraz skutki rekomendowanej opcji. Ten raport przygotowuje Kierownik
Projektu dla Komitetu Sterującego.
Raport zawierający opis, ocenę wpływu i zalecenia dotyczące wniosku o wpro-
wadzenie zmiany, odstępstwa albo problemu/obawy. Jest sporządzany tylko dla
zagadn ień, które muszą być obsłużone w sposób formalny.
Raport Kierownika Projektu dla Komitetu Sterującego o postępach etapu, przeka-
zywany w określonych terminach.
Raport o postępach prac oparty na informacjach zebranych w trakcie przeglądu
w punkcie kontrolnym, który jest przekazywany przez zespól Kierownikowi Pro-
jektu i dostarcza dane sprawozdawcze tak, jak określono w Grupie Zadań .
Produkty zarządcze przedstawiające zarejestrowany obraz stanu niektórych aspek-
tów projektu.
Czynności, jakie mogą być wykonane w celu doprowadzenia sytuacji do poziomu,
na którym stopień ekspozycji na ryzyko jest akceptowalny dla danej organizacji.
Reakcje te należą do jednej z kilku kategorii reakcji na ryzyko.
Reakcja na ryzyko polegająca na podjęciu proaktywnych czynności w celu
zmniejszenia prawdopodobi eństwa wystąpien ia danego zdarzenia przez pro-
wadzenie pewnej formy sterowania i/lub zmniejszenia wplywu tego zdarzenia,
jeżeli ono wystąpi .
Rejestr zawierający su1naryczne zestawienie danych dotyczących zarówno wszyst-
kich planowanych, jak i zakończonych działań dotyczących jakości. Rejestr Jakości
jest wykorzystywany przez Kierownika Projektu i Nadzór Projektu w trakcie prze-
glądu postępów prac.
Zapis zidentyfikowanych ryzyk dotyczących danej inicjatywy, wraz z ich statusem
i h istorią.
Rejestr używany do rejestrowania oraz utrzymywania infonnacji o wszystkich
zagadnieniach, które są zarządzane formalnie. Rejestr Zagadnień powinien być
regularnie przeglądany przez Kierownika Projektu.
Formalne repozytoria zarządzane przez Kierownika Projektu, które wymagają
zgody Komitetu Sterującego co do ich formatu, składu i zasad wykorzystywania.
PRINCE2 wyróżnia trzy rejestry: Rejestr Zagadnień, Rejestr Ryzyk, Rejestr Jakości.
Propozycja przygotowana przez Kierownika Projektu dla Komitetu Sterującego
w celu wysłania w formie powiadomienia o zamykaniu projektu, kiedy Komitet
Sterujący będzie przekonany, że projekt można zamknąć.
344 I Leksykon

rezerwa Coś pozostawione w zapasie zwykle w celu obsługi odchyleń kosztów i czasu lub
ryzyk. PRINCE2 nie poleca stosowania rezerw poni eważ rozbieżnościami osza-
[ contingency1
cowań zarządza się, ustalając tolerancje, a ryzyka mi zarządza się poprzez wybór
odpowiednich reakcji na ryzyko (łączni e z reakcją opisaną w planie rezerwowym.
która stanowi zabezpieczenie na wypadek zmaterializowania się ryzyka).
rezultat Rezultat zmiany, zwykle mający wplyw na realną sytuację i/lub okoliczności. Rezul-
tatów oczekuje się, kiedy wprowadza się zmiany. Rezultaty osiągane są jako wynik
[outcome]
działań podejmowanych w celu wprowadzenia zmiany.

ryzyko Niepewne zdarzenie lub grupa zdarzeń, które w przypadku ich wystąpienia mogą
mieć wpływ na osiągnięcie celów. Miarą ryzyka jest wartość iloczynu miary prawdo-
[risk]
podobieństwa wystąpienia dostrzeganego zagrożenia lub szansy oraz miary wielko-
ści jego(jej wpływu na cele.

ryzyko inherentne Narażeni e wynikające z konkretnego ryzyka przed podjęciem jakiegokolwiek

dzia łania w celu za rządzenia nim.
[inherent risk]
ryzyko rezydualne Ryzyko pozostałe po zastosowaniu reakcji na ryzyko.
[residua/ risk]
sponsor Osoba lub organizacja rozumiana zwykle jako główna siła sprawcza prog ramu
lub projektu. PRINCE2 nie definiuje roli sponsora. Sponsor najprawdopodobniej
[sponsor]
będzie Przewod ni czącym Komitetu Sterującego lub osobą, która powoła Prze-
wodn iczącego .

standardy organizacji lub Są to nadrzędne standardy, do których musi stosować się projekt. Będą one mialy
programu wplyw na cztery strategie projektu (Strategię Zarządzania Komun i kacją, Strategię
Zarządzania Konfiguracją , Strategię Zarządzania Jakością oraz Strategię Zarządza­
[corporate or programme
nia Ryzykiem) oraz na mechanizmy sterowania projektem.
standards]
sterowanie zmianami Procedura zapewniająca. że wszelkie zmiany. które mogą wpłynąć na uzgodnio-
ne cele projektu, zostaną zdefiniowane. ocenione oraz zatwierdzone, odrzucone
[change control]
albo odroczone.
strategia Form ula realizacji lub linia postępowan ia,
zaprojektowana i przyjęta w celu osią­
gni ęcia długoterminowego celu. Strategie mogą istn i eć na różnych poziomach -
[strategy]
na poziomie organizacji, programu czy projektu. Na szczeblu projektu PRINCE2
definiuje cztery strategie: Strategię Za rządzania Komunikacją, Strategię Zarzą­
dzania Konfigu racją, Strategię Zarządzan ia Jakością oraz Strategi ę Zarządzania
Ryzykiem.
Strategia Zarządzania Jakością Strategia określająca techniki i standardy jakości, jakie będą stosowane w projek-
cie wraz z różnym i obowiązkami niezbędnymi dla osiągn ięcia wymaganych pozio-
[Quality Management
mów jakości.
Strategy]
Strategia Zarządzania Opis środków oraz częstotliwości komunikacji pomiędzy zespołem projektowym
Komunikacją a interesariuszami projektu.
[Communication Management
Strategy]
Strategia Zarządzania Opis jak i kto będzie sterował konfigu racją i ch ronił produkty projektu.
Konfiguracją

[Configuration Management
Strategy]
 Leksykon I 345

Strat egia Zarządzania Strategia opisująca cele stosowania zarządzania ryzykiem, opis procedury, która
Ryzykiem będzie przyjęta, role i obowiązki, tolerancje dla ryzyka, terminy działań w ramach
zarządzania ryzykiem, narzędzia i techniki, które zostaną wykorzystane, a także
[Risk Managemen t Strategy] wymagania dotyczące raportowania.
struktura podziału produktów Hierarchicznie u porządkowanie wszystkich produktów, które mają być wytworzone
w ramach planu.
[product breakdo wn structure]
struktura zespołu zarządzan ia Schemat organizacyjny przedstawiający role, jakie będą wykorzystywane w zespo-
projekt em le zarządzan ia projektem. wraz z osobami przypisanymi do tych ról oraz relacjami
delegacji i pod ległości.
[project management team
structure]
-------~

sygnał uruchamiający Zdarzenie lub decyzja uruchamiające proces PRINCE2.

[trigger]
syst em za rządzania jakością
Kompletny zbiór standardów, procedur i obowiązków dotyczących jakości dla
danego miejsca realizacji projektu lub dawniej organizacji. W kontekście projektu,
[quality management system]
„ miejsce realizacji projektu" i „organizacja" powinny być interpretowane jako
trwala lub rela tywnie trwała organizacja (lub organizacje} sponsorująca prace pro-
jektowe. tzn. „ zewnętrzna" w stosunku do powołanej na pewien czas organizacji
projektu. Na przykład program może być uważany za relatywnie trwałą organiza-
cję sponsorującą projekty i może posiadać udokumentowany system zarządzania
jakością.
~------ ~-------

system zarządzania Zbiór procesów, narzędzi oraz baz danych wykorzystywanych do zarządzania
konfigu racją danymi konfiguracji. Projekt korzysta zwykle z systemu zarządzania konfiguracją
należącego albo do organizacji klienta, albo dostawcy.
[configuration management
system]
sytuacja nadzwyczajna Sytuacja, w której można przewidzieć, że wystąpi odchylenie poza poziomy tole-
rancji uzgodnione pomi ędzy Kierownikiem Projektu a Komitetem Sterującym (lub
[exception]
pomiędzy Komitetem Sterującym a kierownictwem korporacji lub programu).
------------
t echnika przegl ądu ja kości
Technika inspekcji ja kości ze zdefiniowanymi rolami i określoną strukturą . Technika
ta jest zaprojektowana w celu oceny, czy dany produkt mający formę dokumentu
[quality review technique]
(lub podobną, np. formę prezentacji) jest kompletny, zgodny ze standardami oraz
czy spelnia kryteria jakości uzgodnione dla niego w odpowiednim Opisie Produk-
tu. Uczestnicy są wybierani spośród osób posiadających niezbędne kompetencje,
aby ocenić zgodność produktu z jego przeznaczeniem.
temat Aspekt zarządzania projektem, którym należy się stale zajmować w trakcie projek-
tu i który wymaga określonego traktowania, aby procesy PRINCE2 byly skuteczne.
[theme]
------------
toIera ncja Dopuszczalne odchylenie powyżej i poniżej planowanej wartości w odniesieniu
do czasu i kosztów, o którym informacja nie musi być przekazana na wyższy
[tolerance]
szczebel za rządzania. Mogą również istnieć tolerancje dotyczące jakości , zakresu,
korzyści i ryzyka. Tolerancja jest stosowana na poziomie projektu, etapu i zespolu.
- -- - - --
t olerancja czasu Dopuszczalne odchylenie od planowanego terminu, o którym informacja nie musi
być przekazana na wyższy szczebel zarządzania. Tolerancja czasu jest udokumen-
[time tolerance]
towana w odpowiednim planie. Patrz: „ tolerancja" .
~----------~
tolerancja jakości Tolerancja określona dla kryterium jakości produktu, definiująca dopuszczalny
przedział wartości. Tolerancja jakości jest udokumentowana w Opisie Produktu
[quality tolerance]
Końcowego Projektu (w przypadku tolerancji jakości na szczeblu projektu) oraz
w Opisie Produktu dla każdego produktu, który ma być dostarczony.
~-----------~
346 I Leksykon

tolerancja korzyści Dopuszczalne odchylenie dla oczekiwanej korzyści, o którym informacja nie musi
być przekazana na wyższy szczebel zarządzania. Tolerancja korzyści jest udokumen-
[benefits tolerance]
towana w Uzasadnieniu Biznesowym. Patrz „ tolerancja" .
tolerancja kosztów Dozwolone odchylenie od zaplanowanych kosztów realizacji planu, o którym nie
trzeba jeszcze natychmiast poinformować wyższego szczebla zarządzania . Toleran-
[cost tolerance]
cja kosztów udokumentowana jest w odpowiednim planie. Patrz „ tolerancja".
tolerancja ryzyka Progowe poziomy ekspozycji na ryzyko, których przekroczenie da sygnał do spo-
rządzen ia Raportu Nadzwyczajnego w celu zawiadomienia Ko1nitetu Sterującego
[risk tolerance]
o zaistniałej sytuacji. Tolerancje dla ryzyka mogą obejmować limity dla łącznych
zagrożeń planu (np. łączne koszty ryzyka muszą wynosić mniej n iż 10% budżetu
planu) lub limity dla pojedynczego zagrożenia (np. zagrożenia dla konkretnej usłu­
gi operacyjnej). Tolerancja ryzyka jest udokumentowana w Strategii Zarządzania
Ryzykiem.
tolerancja zakresu Dopuszczalne odchylenie zakresu planu, które jest dozwolone przed przekaza-
niem na wyższy szczebel zarządzan ia. Tolerancja zakresu jest udokumentowana
[scope tolerance]
w odpowiednim planie w formie zapisu lub odniesienia do struktury podziału
produktów dla tego planu. Patrz: „ tolerancja".
transza Pojęciestosowane w zarządzani u programami, opisujące grupę projektów zesta-
wionych pod kątem wyróżn ionej skokowej zmiany zdol ności i osiągania korzyści.
[tranche]
unikanie (reakcja na ryzyko) Reakcja na zagrożeni e, gdy zagrożeni e albo nie będzie nadal wpływało, albo
może więcej nie zaistnieć.
[avoid]
. .
uprawn1en1e Prawo do przydzielania zasobów oraz podejmowania decyzji (występuje na pozio-
1nie projektu, etapu i zespołu).
[authority]
ustępstwo Odstępstwo (lub niezgodność) zaakceptowane przez Komitet Sterujący bez koniecz-
ności wykonania działań korygujących.
[concession]
Uzasadnienie Biznesowe Uzasadnienie działania organizacyjnego (projektu) obejmujące zwykle koszty,
korzyści, ryzyka oraz terminy, względem którego weryfikowana jest ciągłość jego
[Business Case]
zasadności .

użytkownik(-cy) Osoba lub grupa, która będzi e używała jednego łub więcej produktów wytworzo-
nych w projekcie.
[user(s)]
wariant Sposób rozróżniania produktów pochodnych od produktów będących obiektami
odniesienia. Na przykład podręcznik użytkownika może posiadać wariant angielski
[varia n tj
i wariant hiszpański .
warunki wstępne (planu) Wszelkie podstawowe warunki, które muszą być spełnione i utrzymane, aby plan
zakończył się sukcesem.
[prerequisites]
wdrożenie (PRINCE2) To, co organizacja musi zrobić, aby przyj ąć PRINCE2 jako swoją metodykę zarzą ­
dzania projektami. Różni się ono od dostosowania metodyki. które określa. co
[embedding]
nal eży zrobi ć w projekcie, aby zastosować tę metodykę w środowisku konkret-
nego projektu.
wersja Konkretny obiekt odniesienia dla produktu. Wersje posługują się zwykle konwencją
nazewniczą. umożliwiającą ustalenie kolejności lub daty powstania obiektu odnie-
[version]
sienia. Na przykład wersja 2 Planu Projektu jest obiektem odniesienia następnym po
wersji 1 Planu Projektu.
 Leksykon I 347

Właściciel Programu/Projektu Właścicielto określenie wprowadzone przez rząd Wielkiej Brytanii. Jest to określe­
nie osoby odpowiedzialnej za zapewnienie, aby projekt lub program zmiany osią­
[Senior Responsibfe Owner
gnął swoje cele i dostarczy! przewidywane korzyści. Powinien on być wlaścicielem
(SRO)] całej zmiany biznesowej, która jest wspierana przez projekt. Właściciel powinien
zapewnić, by zmiana ciągle koncentrowa ła sie na biznesie, miała jasno określoną
władzę oraz by kontekst, włączając ryzyka, był aktywnie zarządzany. Osoba ta
musi zajmować wysoką pozycję w hierarchii organizacji i musi ponosić osobistą
odpowiedzial ność za pomyśl ną realizację projektu. Osoba ta powinna być uzna-
wana w całej organizacji za właściciela programu/projektu.
właściciel ryzyka Wskazana imiennie osoba, która jest odpowiedzialna za zarządzan ie, monitoro-
wanie i kontrolowanie wszystkich aspektów przypisanego jej konkretnego ryzy-
[risk owner]
ka, lącznie z zastosowaniem wybranych reakcji w odpowiedzi na zagrożenia lub
w celu maksymalnego wykorzystania szans.
wniosek o wprowadzenie Propozycja zmian obiektu odniesienia (bazowego). Jest to rodzaj zagadnienia.
zmiany
[request for change]
wpływ (ryzyka) Przewidywany lub faktyczny skutek zmaterializowania się konkretnego zagrożenia
lub szansy.
[impact (of risk)]
Wsparcie Projektu Rola o charakterze administracyjnym w zespole zarządzania projektem. Wsparcie
Projektu może mieć formę porad i pomocy w zakresie narzędzi zarządzania pro-
[Project Support]
jektem, wskazówek, uslug administracyjnych takich, jak gromadzenie i przecho-
wywanie dokumentacji, oraz zbierania danych faktycznych.
współdzielenie Reakcja na ryzyko (zag rożenie lub szanse) poprzez zastosowanie formuły podzialu
(reakcja na ryzyko) zysków/pokrycia strat: obie strony dzi elą się zyskami (w ustalonych z góry gra-
nicach), jeżeli koszty są niższe niż w planie kosztów i wspólnie pokrywają straty
[share] (również w ustalonych z góry granicach) w przypadku przekroczenia planu kosz-
tów.
wydanie (zbiór produktów) Zbiór produktów podlegających przekazaniu. Zawartość wydania podlega zarządza­
niu, sprawdzeniu i wdrożeniu jako jedna calość. Patrz: „ przekazanie".
[release]
wyeksploatowanie lub Reakcja na ryzyko związana z szansą, polegająca na skorzystaniu z pojawiającej
wykorzystanie się szansy i zapewnieniu, że ona zaistnieje, a jej potencjał zostanie wykorzystany.
(reakcja na ryzyko)
[exploit]
wykonawca reakcji na ryzyko Niektóre czynności mogą nie być w gestii właściciela ryzyka, by kontrolował je
wprost. W takiej sytuacji należy mianować osobę odpowiedzialną za dzialanie,
[risk actionee]
będące reakcją na ryzyko. On lub ona musi informować na bieżąco właściciela
ryzyka o aktualnej sytuacji.
wynik Produkt, którego wytworzenie jest przedmiotem danego planu. Produkty specja-
listyczne są specyficzne dla poszczególnych projektów (np. kampania reklamowa,
[output]
system sprzedaży biletów parkingowych, fundamenty budynku, nowe procesy
biznesowe itp.). Nazywane są one również przedmiotem dostawy lub wytworem.
wytwórca Osoba lub grupa osób odpowiedzialna za wytworzenie produktu.
[producer]
wzmocnienie Reakcja na ryzyko (w przypadku szansy), polegająca na podjęci u czynności, by
(reakcja na ryzyko) zarówno zwiększyć prawdopodobi eństwo wystąpienia zdarzenia, jak i wzmocnić
wpływ zdarzenia, gdyby wystąpilo.
[enhance]
348 I Leksykon

zagadnienie Istotne zdarzenie, które zaszło, nie było planowane, a wymaga działań zarządczych.
Może to być wszelkiego rodzaju obawa, pytanie, wniosek o wprowadzenie zmiany,
{issue]
sugestia lub odstępstwo (niezgodność) zglaszane w trakcie projektu. Zagadnienia
projektowe mogą dotyczyć wszystkiego, co ma związek z projektem.
~~~~~~~~~

zakres Zakres planu to lączna suma jego produktów oraz dotyczących ich wymaga ń .
Zakres jest opisany za pomocą struktury podziału produktów planu i powiązanych
{scope]
Opisów Produktów.
zalecenia działań następczych Rekomendowane czynności związane z niezakończonymi pracami, niezamkniętymi
zagadnieniami czy ryzykami oraz innymi działaniami niezbędnymi do przekazania
{follow-on action
produktu do kolejnej fazy jego życia . Zalecenia są zestawione i włączone do Rapor-
recommendations] tu Końcowego Etapu (przy stopniowym przekazywaniu produktu) oraz do Raportu
Końcowego Projektu.
~~~~~~~~~~~~~~ ~~~~~~~~

zależności (w planie) Związek pomiędzy produktami lub działaniami. Na przykład nie można zacząć
wytwarzać produktu C, dopóki produkty A i B nie zostaną ukończone. Zależno­
{ dependencies]
ści mogą być wewnętrzn e lub zewnętrzne. Zależności wewnętrzne to zależności
pod kon trolą Kierownika Projektu. Za leżności zewnętrzne pozostają poza jego
kontrolą. Na przyklad jest to dostawa produktu wymagana przez projekt z innego
projektu.
Założenia Projektu Deklaracja opisująca cel, koszt, terminy i wymagane wskaźn i ki wykonania oraz
ograniczenia dla projektu. Jest ona przygotowywana przed projektem w proce-
{Project Brief]
sie Przygotowanie Projektu, a następnie wykorzystywana w procesie Inicjowanie
Projektu do opracowania Dokumentacji Inicjowania Projektu oraz jej części skła­
dowych. Jest ona następnie zastąpiona Dokumentacją Inicjowania Projektu i nie
jest dalej utrzymywana.
~~~~~~~~~

założenie Stwierdzenie przyjmowane za prawdziwe dla celów planowania, które może się
jednak później zmienić . Zależenie przyjmuje się, gdy jeszcze nie są znane wszyst-
{assumption]
kie okoliczności lub niektóre decyzje jeszcze nie zapadly. Zalożenia dotyczą zwykle
kwestii o takim znaczeniu, iż w przypadku ich zmiany lub niepotwierdzenia praw-
dziwości , konieczna będzie istotna zmiana planu.
~~~~~~~~~

Zapis Obiektu Konfiguracji
{Configuration Item Record]
zapisy
[records]
zapisy jakości
[quality records]
zarządzanie jakością
[quality management]
zarządzanie konfiguracją
{configuration management]
zarządzanie projektem
{project management]
zarządzanie ryzykiem
{risk management]
Zapisana informacja opisująca status, wersję oraz wariant każdego obiektu konfi-
guracji oraz wszelkie szczegóły dotyczące ważnych powiązań pomiędzy obiektarni
konfiguracji.
Produkty zarządcze podlegające częstym zmianom, które zawierają informacje
dotyczące postępów projektu.
Dowody zachowane w celu wykazania, że wymagane działania nadzoru jakości
i kontroli jakości zostały wykonane.
Skoordynowane dzialania, mające na celu kierowanie i kontrolowanie organizacji
pod wzg lęd em jakości .
Działania
techniczne i administracyjne, których przedmiotem jest tworzenie, utrzy-
mywanie i kontrolowana zmiana konfiguracji przez caly okres życia produktu.
Planowanie, delegowanie, monitorowanie i kontrolowanie wszystkich aspektów
projektu oraz motywowanie zaangażowanych osób, aby osiąg nąć oczekiwane
cele projektu w granicach docelowych wskaźników wykonania, określonych dla
czasu. kosztów, jakości, zakresu, korzyści i ryzyk.
Systematyczne stosowanie pryncypiów, formuł realizacji i procesów do zadań,
polegaj ących na identyfikowaniu i ocenie ryzyk (zagrożeń/szans), a następnie
planowanie i wd rażanie reakcji na ryzyko.
 Leksykon I 349

zatwierdzający Osoba lub grupa osób (np. Ko1nitet Sterujący) wskazana jako posiadająca kwalifi-
kacje i uprawnienia do zatwierdzenia produktu (zarządczego lub specjalistycznego)
{approver]
jako ukończonego i odpowiadającego jego przeznaczeniu.
zatwierdzenie Formalne potwierdzenie, że produkt jest ukończony i spełnia wymagania określone
w jego Opisie Produktu (z uwzględnieniem ewentualnych ustępstw).
[approval]
zespół zarządzania projektem Cała struktura zarządzania projektem złożona z Komitetu Sterującego, Kierownika
Projektu wraz z wszelkimi rolami Kierownika Zespołu, Nadzoru Projektu i Wsparcia
{project management team]
Projektu.
zestawienie statusu Raport o statusie produ któw. Potrzebne produkty mogą być wyszczególnione za
produktów pomocą identyfikatora lub części projektu, w ramach której zostały wytworzone.

[product status account]

zezwolenie Formalnie wyrażona zgoda na wykonanie określonego(-ych) działania(-ań).
{authorization]
zlecenie przygotowania Produkt zewnętrzny wytworzony przez uprawniony organ zlecający projekt. Zlecenie
projektu jest sygnałem do rozpoczęcia procesu Przygotowanie Projektu.
{project mandate]
 Indeks

Uwaga: numery stron wydru kowane wytłuszczo­ centra doskona lości 25, 43, 148, 152, 230, 251, 308, 321
nym dru kiem wskazują strony z tabelami, a wydru- commercial off- the-shelf products (COTS) 136
kowane kursywą - strony z rysunkami. cykl wytwarzania/rozwoju 136
cykl życia proj ektu 111, 121, 153, 243- 5, 244, 305
akceptacja 14, 148, 152, 210, 321 czas trwania, czas realizacji
Akredytowane Organizacje Konsultingowe (ACO) 8 patrz terminy
Akredytowane Organizacje Szkoleniowe (ATO) 8 członek zespolu 35, 36, 40, 122, 146, 178
aktualna wartość netto 28 czynnik sukcesu 162
analiza czynniki projektowe/projektu 229-31, 230
interesariuszy 44- 5, 134, 164, 234 czynniki środowiskowe 230- 1, 230
możliwych rozwiązań/opcji 102, 102 czynniki wewnętrzne 88, 229
ścieżki krytycznej 7 czynniki zewnętrzne 53, 88, 11 O, 204, 229
wartości wypracowanej (metoda) 7, 114 czynności 124, 125
wrażliwości 26, 28 patrz także rekomendowane czynności
angażowanie interesariuszy w sprawy projektu 59
apetyt na ryzyko 82 decyzja doraźna 136, 150, 150, 152, 307
archiwizowanie 100-1, 225, 294, 311 delegowanie 4, 5, 7, 13, 35-7, 39, 40-1, 107-1 o, 133, 143,
archiwum 122 146, 165
arkusz kalkulacyjny 76 delegowanie uprawnień 39, 101, 146, 165, 287, 293, 307
aspekty specjalist yczne 7 diagnozowanie z wykorzystaniem PRINCE2 8
Association for Project Management 245, 283 diagram 65, 69, 69, 70- 2, 74, 14, 76, 84, 125
audyt 8, 44, 51, 52, 54-6, 60, 98, 101, 161, 225, 254, 256, diagram kamieni milowych 114
273-4, 290,294 diagram następstwa p roduktów 69, 69- 72, 169, 205, 212,
266, 301, 301, 321
bezpieczeństwo 53, 97, 101, 138 diagram procesu
bieżąca kontrola (sterowanie) 113, 122 Inicjowanie Projektu 157
biuro projektu 41 Przygotowanie Projektu 129
budowanie zespolu 57, 59 Sterowanie Etapem 177
budżet 24, 76 Zamykanie Projektu 217
planu 13, 76 Zarządzan ie Dostarczaniem Produktów 195
projektu 24, 241 Zarządzanie Końcem Etapu 203
ryzyka 76, 84, 92, 160, 266, 276 Zarządza nie Strategiczne Projektem 143
zmian 76, 99, 103-4, 161, 241, 256, 266, 293, 321 diagram przepływu patrz diagram następstwa produktów
b urza mózgów 85 diagram struktury podzialu produktów 70, 169, 205,
212, 297
cel 151, 218 diagram struktury podzialu ryzyka 84- 5, 86
oceny 151-2 diagram ścieżki krytycznej 76
cel procesu Dokumentacja Inicjowania Projektu 112, 122, 123, 146,
Inicjowanie Projektu 157 147, 148, 153, 159. 160, 162, 164, 166, 168, 170, 178,
Przygotowanie Projektu 129 179, 184, 186, 188, 190, 196, 198, 205, 206, 206, 208,
Sterowanie Etapem 177 210.211,218,219.221,222,224,242,249,250
Zamykanie Projektu 217 cele określone w 152, 217
Zarządzania Dostarczaniem Produktów 195 przeglądanie 109, 122, 144, 146, 152, 179, 204-5,
Zarządzania Końcem Etapu 204 212,242
Zarządzanie Strategiczne Projektem 143 uaktualnianie 149, 149, 205, 206, 207, 212, 213
cel projektu 3, 4, 5, 12-3, 37, 45, 81, 135, 138 zarys 270-1
cel techniki przeglądu jakości 57 zawartość 14, 108, 122, 130, 152, 238, 242, 270- 1
354 I Indeks

zestawianie 130, 157, 171-3, 172, 173 uaktualnianie 122, 134-5, 137-9, 161, 163-4, 167,
dokumentowanie(-acja) 11, 21, 37, 42, 44, 52-4, 60, 68, 169-70, 187, 191-2,238
69,99, 108, 113, 115, 129, 144, 158, 163, 166- 7, 169, wpisy do 76, 101
186, 188,218,223,237- 8,251,276 zarys 257
dostarczanie produktów 3, 14, 122, 177, 195-200, 220 zawartość 238
dostawca 4, 5, 12, 32, 102, 167, 232
patrz także Główny Dostawca efekt uboczny 22, 25, 57, 153, 251
dostosowanie 147, 229-46, 229, 230, 249 ekspert ds. projektowania programu 233, 234
do projektu 3, 6, 11, 14 eksploatacja 38-9, 138, 148- 9, 185, 197, 210, 218,
doświadczenia 12, 25, 49, 50, 60, 73, 85, 91, 114- 5, 146, 220- 1,239
198, 204, 222, 260 etap 13, 101, 108, 109
pozyskiwanie/poszukiwanie 159, 161 -3, 165, 167, 170 długość 111, 235
zgromadzenie wcześn iej szych/dotychczasowych dopasowanie/dostosowanie do działań 11 1, 240, 242
129, 13 1, 132, 132 koniec 25, 185, 203, 209-10, 270, 211
dublowanie (unikanie) 234 liczba 111, 165, 235
dyrektor programu 233, 233, 234 planowanie następnego 204- 6, 205, 206
działania 124, 125 przeglądan ie stanu 183-5, 184, 185, 191
dotyczące Grup Zadań 196-200 wykorzystanie 42, 110-2
Kierownika Projektu 158, 178, 204 zarządzani e etapowe 11, 13, 107
Kierownika Zespołu 196- 200 zezwolenie na real izację (planu) 108, 109-1O, 122,
kolejność 73-75, 89 123, 143, 144, 147-50, 148, 149, 178-9,77~204,307
działaniaw procesie etap inicjowania 23, 39, 11 1, 727, 122, 138, 139
Inicjowanie Projektu 158-173 odpowiedzial ność za 145
Przygotowanie Projektu 130-9 plan 66, 131, 139, 145, 235
Sterowanie Etapem 178- 192 planowanie 138- 9, 738, 139
Zamykanie Projektu 218-225 etap składan ia zamówień 226
Zarządzanie Dostarczaniem Produktów 196-200 etap techniczny 11 1- 2, 712
Zarządzan ie Końcem Etapu 204-213 etap zarządczy 108- 1O
Zarządzan ie Strategiczne Projektem 144-154 etapy projektu patrz etap
działania następcze 152- 4, 210- 1, 217-8, 221- 3, 238,
258- 9,287,289,308,310- 1,334 finanse patrz budżet, koszty
po kontroli/przeglądzie jakości 57-9, 60, 291 finansowanie 25, 27, 92, 122, 135, 158, 239-40
po końcu etapu 148-9, 270, 211 formalizm 14, 54, 60, 67, 181, 196, 230, 235, 239, 241, 251,
patrz także zalecenia działań następczych 278, 293,
działania operacyjne 27-8, 239 formula realizacj i projektu129, 129, 130, 136, 137, 137,
działania poprojektowe 25, 122, 143, 153, 220- 1, 250 138- 9, 145-6, 167,168, 171, 172,204- 5,207,212,220
działa nia w węzłach (techn ika) 74, 74
Dziennik Doświadczeń 115, 122, 132, 132, 133, 135, 137, Gantta wykres, d iagram 65, 76, 266, 323
138, 146, 147, 159, 159, 160, 162, 164, 166, 768, 784, Główny Dostawca 34, 36-8, 36, 40, 144, 233, 234
205,210,270,222,224,2 24,225,249 odpowiedzial ność 38
przeg lądanie 133, 135-6, 139 rola i obowiązki 29, 38, 46, 50, 61, 78, 93, 104, 117,
przeznaczenie 11 5, 263 197,239- 40,289- 90
wpisy do 159, 161- 3, 165, 167, 170, 185, 187 Główny Użytkowni k 21, 26, 29, 37-8, 40, 46, 50, 61, 78,
zarys 263-4 93, 104, 117,240,288-9
Dziennik Projektu 98, 100, 113, 737, 131, 132, 732, 134, odpowiedzial ność 21, 24-6, 36
73i 1 3~13~ 1 37,738, 1 3~7~16~7~1-18~ rola i obowiązki 21, 26, 29, 37- 8, 46, 50, 61, 78, 93, 104,
791, 192,224,225,277,299,305,322 117, 240, 288-9
format i sposób prezentacji 25 7 grupa dostawców 39, 40
kryteria ja kości 257 grupa użytkowników 26, 39, 40
pochodzenie 257 Grupa Zadań 67, 103, 112-3, 147, 178,240-1,249
przeglądan ie 159-61, 187 definiowanie 180
przeznaczenie 93, 113-4, 257 format i sposób prezentacji 278
 Indeks I 355

kryteria jakości 278-9 a przegląd korzyści 24-5

odbieranie zakończonych 122, 182, 182, 183, 197, 199 a zamykanie projektu 152
oddawanie wykonanej 198- 200, 199, 200 jako zlecające projekt 121, 130
przeglądanie 181-2, 787, 182, 197 mianowanie Przewodniczącego przez 35, 130
przeznaczenie 277 obowiązki 29, 35-6, 46, 61, 78, 93, 117
przyjmowa nie do wykonania 796, 196, 197 potrzeby 159, 161, 163-4, 166, 169, 170, 173
wykonywan ie/realizacja 67, 109, 197-8, 198, 199 rola doradcza 151
zarys 277-9 strategie/standardy/praktyki 136, 159, 161-3, 165,
zarządzanie 195-6 167
zawartość 41, 113, 178, 277- 8 kierownictwo programu 21, 23- 5, 35, 36
zezwolenie na realizację 11O, 113, 178-81, 179, 180, jako jednostka zlecająca projekt 121, 130
185, 191 obowiązki 29, 35, 39, 46, 50, 50, 61, 78, 93, 104, 117
potrzeby/wymaga nia 160- 1, 163- 4, 166, 169-70, 173
handlowa wersja produktu - „z pól ki" 136 strategie/standardy/praktyki 136, 158-65, 167
harmonogramowanie 68, 71, 73- 6 Kierownik Projektu 35, 35, 36, 41
horyzont planowania 13, 65, 67, 11 1, 323 codzienna/bieżąca kontrola 66, 109
kompetencje 291-2
identyfikator 87, 88, 1OO, 102 mechanizmy sterowania wykorzystywane przez 11 O
identyfikowanie 44- 5 mianowa nie/powoła nie 129, 130- 1, 737, 132, 235
informacje 65, 163, 171, 178, 181, 191, 203-4, 225 monitorowanie przez 74, 100
zbieranie/gromadzenie 129, 181, 183, 192 rola i obowiązki 4-5, 14, 24-5, 29, 35-6, 40-1, 4 7, 43,
zestawianie 186 45, 46,50, 61,78,93, 104, 11 7, 135,237,290-1
źródło 3, 84, 92, 1oo wsparcie dla 37, 91
Inicjowanie Projektu - proces 42, 53- 4, 129- 30, 138, 143, wytyczne doraźne dla 150-2, 750
157- 173, 757,237- 8,241 Kierownik Zespoi u 35, 35, 36, 40- 1, 115- 6
Iista kontrolna 309 kompetencje 291
przeznaczenie 157 konsultowanie z 204, 212
inspekcja ja kości 55, 57, 60 potrzeba wyznaczenia 134, 237
integracja 36, 97, 229, 233, 245, 246 rola i obowiązki 41, 46, 50, 61, 78, 93, 104, 117,
interesariu sze 7, 12, 14, 21- 2, 24, 33, 34- 5, 39, 44, 85, 151, 195- 6, 197, 291
164, 171 wykonywanie Grup Zadań przez 67, 109, 122, 183
biznesowi 12, 34 klient 34, 50- 54,
macierz interesariuszy 39 kolejność dzialań 73- 75
praca z 44 komercyj ne relacje klient/dostawca 34, 60, 67, 144, 197
zaangażowanie 44-5, 59, 163, 234 komercyjne uwarunkowania (środowi sko) 180, 181
zewnętrzni 37, 91 Komitet Sterujący 14, 21, 34, 36- 8, 40, 52, 66, 83, 150,
interesy 12, 33-4 237,240
interesy związane z projektem 33- 4, 34, 36 cechy 37
International Project Management Association 245, 318 członkowie 34, 36- 8
kompetencje 288
jakość 5,5, 13, 17, 49-61,234,240 konsultowanie z 204- 5, 212, 220
definicja 49- 51 kontrola przez 109, 143
obowiązki dotyczące 52, 54, 60-1, 61 odpowiedzialność 35-6, 51
odpowiedzialność za 35 podejmowanie decyzji 103, 130, 158
podejście PRINCE2 do 51 - 60 poodejmowanie decyzji doraźnej 150-2, 151
potrzeby 160-1, 163-4, 166, 169- 70, 173, 271
kamień milowy 66, 114, 135, 145- 6, 167, 180- 1, 197, 235, rola i obowiązki 22-3, 27, 121-2, 287-8
237, 240- 1, 278, 323 wytyczne/polecenie 723, 743, 750, 777, 183, 784,
określenie 75- 6 185, 188
kierownictwo liniowe 12, 43, 240 zatwierdzenie przez (zgoda) 25, 35, 39, 54, 67, 160,
kierownictwo organizacji 21, 24-7, 29, 35, 36, 35- 7, 46, 162- 4, 167, 169-71,204,223
61, 78,93, 109, 709, 117, 12~ 143, 151 -2,223 zezwolenia wydawane przez 109- 1O, 144-54
356 I Indeks

kompendium wiedzy 245, 246 zasobów 41, 75-6

kon1petencje 288, 290- 4 kryteria akceptacji 51, 53, 54, 61, 135, 145, 162, 219, 251,
kompletność 56-7, 70 269,272-3,289,298,321,324
komunikacja 7, 12, 33, 41, 45, 52, 58, 65, 69, 133- 4, 146, spełnienie 219
164, 245 zmiana 205
dotycząca ryzyk 83, 91-2, 159 kryteria jakości 49, 50, 51, 52, 54-5, 57-8, 60, 70-1, 195,
kanały 35, 133-4 197, 231, 243
pomiędzy szczeblami/poziomami zarządzania 46, 165 spełnienie/sprostanie 185, 219
z interesariuszami 45, 52 w Opisie Produktu 71, 197, 305
koncentracja na produktach 7, 11, 14, 49, 51, 204 kultura jakości 60
konflikt (unikanie) 36, 41 kwalifikacje 7
koniec etapu 42, 101, 112, 772, 727, 123, 157, 172, 177, patrz także Opis Produktu - zarys
184,203,205,203-13 krzywa S 77, 114
konsulting 8, 315
konsultowanie 164, 212, 254 linia tolerancji ryzyka 88
kontekst 124 lista kontrolna produktów 76, 237, 264
kontekst procesu listy kategoryzujące ryzyka 85
Inicjowanie Projektu 158 listy kontrolne 305-11
Przygotowanie Projektu 130 luz (zapas) 74-5, 74, 77
Sterowanie Etapem 178
Zamykanie Projektu 217- 218 ład 7, 13, 33, 239-41, 245, 283-4, 324
Zarządzanie Dostarczaniem Produktów 195- 6 łańcuch krytyczny 75
Zarządzanie Końcem Etapu 204
Zarządzanie Strategiczne Projektem 143-4 macierz prawdopodobieństwo/wpływ 87, 88
kontrakt 60, 13S, 169, 221, 239-41 materiały referencyjne 180
kontrola jakości 50, 52, 70, 234 mechanizm(·y)
kontrola postępów 113 kontroli 56, 92, 107, 145
kontroler jakości S3- 5, 57 monitorowania 107
korygujące działanie 67, 78, 91, 101, 103, 103-4, 107- 9, nadzoru 13, 234
113-4, 116, 177- 8, 777, 779, 184-5, 784, 187-9, 191, raportowania 145, 237
192, 192, 197,261,276,290-1,309,322 wykorzystywane przez Kierownika Projektu 11 O
korzystanie z doświadczeń 11, 12 wykorzystywane przez Komitet Sterujący 1OO
patrz także doświadczenia; Dziennik Doświadczeń; zależne od czasu 112- 3
Raport Doświadczeń zależne od zdarzeń 112-3
korzyści 4,5, 11-13,21- 22,22,23,24-5, 142, 170 mechanizmy sterowania 13-4, 36, 43, 77, 98, 107- 1O,122,
oczekiwane 11, 21, 23- 5, 146 139, 145, 157, 158, 164-5, 766, 167, 168, 169, 171,
pomiar/mierzenie 24-S, 27, 146, 250 205,223,229,238,241
potwierdzenie 23, 23-4 jakością 54, 61
przegląd 24- 5, 29, 122, 146 zagadnieniami 98
rezydualne 25, 251 zmianami 98
z PRINCE2 7 mechanizmy sterowania projektem 14, 108, 146, 149, 152,
korzyści netto 28, 258, 259 161, 166, 166- 7, 168, 169, 171, 172, 179, 180,205,241
kosztorys 91 ustanawianie/ustalanie 13, 43, 98- 101, 139, 757, 158,
koszty 3, 12, 22, 26-8, 49, 53, 72-3, 76-7, 80, 86-8, 90, 92, 164- 7, 166, 167
99, 102, 111, 114, 150, 157-8, 169-70, 178- 80, 195, zależne od czasu 112
207, 218, 236, 239, 244-5, 251 - 3, 258-9, 261, 265-6, zależne od zdarzeń 113
269,272,278 patrz także kontrola postępów
calkowite/ogólne 73, 99, 111 metoda (sprawdzenia) jakości SO, 51, 52, 54-6
ograniczenia dla 77, 139 metoda wartości wypracowanej 7, 114
rozliczenie 153 mianowanie 130, 131, 131, 132, 132, 733, 134, 133-4
szacunkowe 25, 270 miary 22, 44, 52, 55-6, 60, 135, 223, 267, 330
tolerancje 76, 107, 108, 235, 278 modeł cyklu życia 71, 230, 242
 Indeks I 357

monitorowanie 4, 5, 13, 38, 81-2, 91, 107, 113, 177-8, 197 ocenienie projektu 223
odpowiedzialność za 37- 8 organ izację 46, 46
przez Kierownika Projektu 4,41, 74, 100 Plan Nadzwyczajny 212
przez Komitet Sterujący 37, 66, 143 Plan Projektu 169
Monte Carlo analiza 88, 92 planowanie etapu inicjowania 139
M_o_R- Zarządzanie Ryzykiem 6, 82, 315 plany 77, 78, 206
MoSCoW technika 53, 99 postępy 104, 105
możl iwe inwestycje 21, 26 przeglądanie stanu etapu 185
możliwe rozwiąza nia biznesowe 25- 6, 252 przekazanie produktów 222
Raporty Okresowe 187
nadzór jakości 50-1, SO, 52, 57, 234 strategie 159, 161, 163, 165
Nadzór Projektu 23- 4, 36, 38- 9, 40, 50, 233, 234 Uzasadnienie Biznesowe 28, 29, 136, 171 , 208
delegowanie 133-4 zagadnienia 189, 190
kompetencje 292-3 zakończenie etapu 211
konsultowanie z 160- 1, 163- 4, 166, 169- 70, 173, 180, Założenia Projektu 137
197-8, 204, 212 zamknięcie projektu 219, 220, 224
niezal eżność 38, 42, 43, SO, 51 zarządzanie ryzykiem 91, 92, 93, 189, 190
rola i obowiązki 29, 38, 46, 50, 61 , 78, 93, 104, 117, zdefiniowane 11-2, 133
233,291-2 zezwolenia 145, 147, 149, 154, 180
wyznaczanie/powolywanie do roli 146, 151-2, 237, 240 zgromadzenie doświadczeń 133
nakłady 21, 34, 72, 244 zmiany 103, 104
czasu 102, 130-1, 134, 158, 170, 178, 180,251,254 Obsługa Zmian 38- 9, 99, 101, 103, 103, 104, 146, 161,
pien iężne 111 233,233,234,235,256,293
kosztów 158, 170, 180, 195,278- 9 obszary tolerancji 108
pracy 14,72-3, 102, 130-1, 134, 178-9, 181, 195, 197, ocena inwestycji 24, 27, 252
223,237,251,254,264- 5,278- 9 ocena końcowa etapu 21-2, 113, 115-6, 165, 245
narzędzia 67-8, 73, 84, 92, 168, 229, 234 ocena (analiza) wpływu 22- 4, 99, 1OO, 102, 11O, 139, 150,
negatywne skutki 22, 22, 27, 221, 252, 263 183, 187-8, 191,209,243,251
niepewność 4, 17, 27, 81, 85- 6, 11 1, 114, 241 oczekiwan ia 14
niezadowolenie kl ienta/użytkownika 14, 49 oczekiwania interesariuszy 14
oczekiwania jakościowe 57,52-4, 135, 145- 6, 158, 162
obawa/problem 97, 98, 100- 1, 103, 114, 151, 187, 261 - 2, zmiana 205, 212
322, 327, 329 odchylenie 67, 102, 11 6, 147, 152, 189, 192, 223
obiekt bazowy 66, 78, 113 odpowiedzialność 7, 13, 33, 35-41, 43, 45, 51, 55, 60,
patrz także obiekt odniesienia 133, 232
obiekt konfiguracji 97, 1OO odstępstwo 38-9, 97, 98, 99, 100- 1, 103, 114, 151 , 187-8,
obiekt odniesienia 29, 57, 66, 71, 78, 97- 8, 1OO, 113, 191,256,258-9,261-2,326
157, 223 Office of Government Commerce (OGC)
dla kontroli postępów 113-4 Managing Successful Programmes (MSP) 232, 235,
dla opisu produktu 71, 249 236, 315
zmiana 97 przegląd typu„gateway" 6, 244-5, 316
obowiązki (opisy) 287-94 publikacje 6, 316- 7
obowiązki/odpowiedzialność za 33, 70- 1, 124, 158 ograniczenia 38, 40, 73, 77, 129, 138- 9, 167, 180, 197, 265,
decyzje doraźne 151 270,278,289- 91,326
dzia łania korygujące 192 ograniczenia czasowe 77, 139
przekazanie produktów 153, 221 okres zwrotu 28, 252
Dokumentację Inicjowania Projektu 173 Opis Produktu 57, 52, 54-5, 212, 249, 278, 300, 305, 326
formulę real izacji projektu 137 biblioteka/zbiór 55, 71
Grupę Zadań 180, 182, 183, 196, 199, 200 dla produktów zewnętrznych 70
jakość 55, 61, 62 format i sposób prezentacji 237, 267
mechanizmy sterowania projektem 167 kryteria ja kości 268
mianowania 132, 134 pochodzenie 268
358 I Indeks

produktów zarządczych 231 odchylenia od 102, 147

przeglądanie 146, 149 przeglądanie 11 O, 203, 209, 234
przeznaczenie 14, 54, 267 sporządzanie/tworzenie/opracowywanie 66, 68, 158,
sporządzanie/tworzenie 55- 6, 69, 71, 169, 205 167-9, 168, 169,234
w Grupie Zadań 178, 180 uaktualnianie 204, 206- 7, 206, 207, 218, 219-20, 219,
zarys 267- 8 219, 220
zawartość 52, 112, 185, 195, 197, 267- 8 wplyw/oddzialywanie na 183-4, 188
Opis Produktu Końcowego Projektu 54, 271, 305- 6, 326 za twierdzenie 146, 149, 204
przyklad 298 zawartość 66, 113, 146, 265-6
uaktualnianie 169, 207 Plan Przeglądu Korzyści 25, 66, 146, 148, 147, 221, 251
zarys 271-3 format i sposób prezentacji 251
zawartość 54, 66, 272 kryteria jakości 251
opis roli 29, 35-6, 39, 42, 46, SO, 61, 78, 93, 104, 117, odpowiedzialność za 29, 231
130-1, 131, , 32, 133- 4, 133, 134, 212, 229, 230, pochodzenie 251
231, 287- 94 przeznaczenie 25, 250
organizacja 5, 17, 33-46 sprawdzanie 184, 221
adaptowanie 3 uaktualnianie 149, 208, 209, 220, 221
definicja 33- 5 zarys 250
dostosowanie 232-4, 237, 239, 242- 3 zawa r tość 251
obowiązki dotyczące 46, 46 plan realizacji korzyści 251
podejście PRINCE2 do 35-44 plan rezerwowy 89
poziomy/szczeble 33, 35 Plan Zespołu 67, 68, 241
przeznaczenie tematu 33 przeglądanie 179, 180, 180, 181, 181, 182
struktura 231 - 2, 233, 234 sporządzenie/tworzenie 67, 195, 197
organizacja realizująca projekt 33, 34, 41, 43, 50, 231 uaktualnianie 198, 198, 199
organizacje zewnętrzne 36, 41, 49, 131 - 2, 159, 239 zatwierdzenie 197
planowanie 4, 5, 7, 14, 26, 41, 45, 65
.pelzanie zakresu" 5, 14, 69, 177 etapowe 13, 204-6, 205
personel 3, 8, 26, 37- 8, 42-3, 58, 65, 138, 254, 290-1 jakości 50, 52- 6
dostępność(osób) 37,58, 75, 131, 169, 191 oparte na produktach 51, 52-6, 65, 68-70, 114, 297- 301
pieniężna wartość oczekiwana 88, 88, 92 angażowania interesariuszy 45
PlanEtapu 66,66- 7,68, 11 6, 129, 178, 779,209- 10,270,218 planowanie ja kości 50- 6, 51
dla etapu inicjowania 138-9, 138, 139, 144, 144, 145 planowanie oparte na produktach 7, 68-72, 69, 297- 301
przeglądanie/analizowanie 110, 149, 179, 183- 5, 188, planowanie reakcji na ryzyko 89- 91
189, 190, 212 plan(-y) 17, 65- 78, 234, 265- 7
sporządzenie/tworzenie 66, 110, 122, 129, 204- 5 definicja 65- 7
uaktualnianie 113, 179, 180, 180, 181, 182, 182, 182, dostosowanie/adaptowanie 237, 240
183, 183, 184, 185, 185, 191, 192,207 podejście PRINCE2 do 67-77
utrzymywanie 234, 241 poziomy 65- 6
wniosek o zatwierdzenie 123, 143, 148, 203, 210 prezentacja/przedstawianie 67, 77
wplyw na 184, 188, 191 projektow anie 67- 8, 68
zawartość 113, 183, 266 przeznaczenie 65, 265
zezwolenie na realizację 147- 50, 148, 149, 245 reakcji na ryzyko 89- 91
Plan Nadzwyczajny 67, 113, 123, 143, 151, 207, 209, 220, 326 zarys 265- 267
przedstawienie 203-4 plany organizacji 66
przeglądanie 110, 149 plany programu 66
sporządzanie/opracowanie 103, 203, 211-3, 211, 213 podejmowanie decyzji 3, 5, 7, 13-4, 21-2, 26, 33, 35- 7,
zatwierdzenie/akceptacja 179, 210 58,67- 8,81, 90,98, 103, 103, 109-10, 113, 116, 121,
zezwolenie na realizację 145, 147- 50, 148, 149, 245, 130, 132, 143, 149, 150, 151, 157, 166, 183, 191, 204,
307 239- 40, 242- 3, 245, 256, 258, 263, 8.1
Plan Projektu 13, 66, 66, 69, 166, 189, 209, 249 polityka organizacji 50, 54, 82, 98
cele, zadania 152, 209 polityka programu 98
 Indeks I 359

polityka zarządzania ryzykiem 82 procesy 5,5,6, 18, 121-225, 121

pomiary 26, 45, 52, 108, 114, 267 symbole na diagramach 125
porażka/niepowodzenie projektu 12, 144, 204, 237 patrz takie nazwy poszczególnych procesów,
postępy 5, 17, 65, 107- 16, 109, 235, 237 diagramy procesu
aktualizacje informacji o 11 O produkt(·y) 4, 26, 49, 91, 178
dane o 84 akceptacja 217, 221
kontrola postępów 107- 1O,112- 3, 115-6 dodatkowy 70, 207, 212
obowiązki dotyczące 116, 117 dostarczanie 177-8, 195, 199
przeglądanie 108-10, 113- 6,241 gotowe (.z półki") 136
raportowanie 108, 109, 115,241 identyfikowanie 1OO
patrz takie mechanizmy sterowania projektem odpowiadający swojemu przeznaczeniu 47, 52-5,
potrzeba 21 - 23, 26 57- 60, 223
poufność 239, 241 odpowiedzial ność za 38, 218
powiadomienie 45, 123, 143, 144, 146, 153, 198-9, 218- 20, odpowiedzialność za dostarczenie 35
224, 224, 225, 260, 287, 308, 311 przedmiot dostawy 4, 22, 41, 328
praktyki dobre/najlepsze 6, 7, 50, 60, 77, 83 przekazanie 148, 152- 3, 180, 185, 197, 209- 10, 217,
prawdopodobieństwo ryzyka 86 220- 1,242
PRINCE2 7, 11- 14 stadia wytwarza nia 70, 225, 267
a kompendia wiedzy (Bodies of Knowledge - 8oK) status 58, 100-1, 146
245-6, 246 wytwarzanie 195, 197
dostosowanie 14, 18, 115, 147, 165, 172,207,223, zakończone/ukończone 60,77,204,209,220
229-46, 229, 230 zatwierdzenie 56-60, 56, 122, 125, 180, 183, 197- 9,
elementy nieobjęte przez 7 204, 206, 219
model procesowy 123, 124 zewnętrzny 69, 70- 2
podejście do jakości 51-60 produktyzarządcze 91,98, 101, 108, 113-5, 125, 158,
podejście do organizacji projektu 35-46 160- 1, 171
podejście do planów 67-77 adaptowanie 229-32, 230, 235, 237-8, 242
podejście do postępów 108- 118 bazowe (odniesienia) 249, 250, 290
podejście do ryzyka 82- 92 profil 45
podejście do Uzasadnienia Biznesowego 22 profil ryzyka 87-8, 102, 209
podejście do zmiany 98-103 prognoza 22,25,28, 107, 109, 122, 148, 182, 185,207,243
powiązane wydawnictwa/publikacje 315-7 prognoza (przewidywanie) przekroczenia tolerancji 107,
poziomy planowania 65-6, 67 116, 151, 198, 203-4
procesy 121, 121 program 33, 44
pryncypia (zasady) 4, 5, 6, 11- 14, 230, 230, 237, 328 Proj ect Management Institute 245
przegląd procesów 121-3 projekt 21
struktura 5- 6, 5 cechy, charakterystyka 3- 4
szkolenie na temat 43 definicja 33
technika przegląd jakości 57- 60 ewoluujący 22, 243
uniwersalność 11, 14 jako część (w ramach) programu 37, 39, 44- 5, 68, 83,
wdrożenie 229, 231 102, 130, 135, 138, 163, 170,221,229,231 - 5
wprowadzenie do 4-6 obejmujący w iele organizacji 242
zasady ładu 283, 264 obligatoryjny 22
priorytet (określanie) ustalanie 43, 53, 87, 99, 101, 104, 188 ocenianie 222-3, 222, 223
problem/obawa 97, 98, 100-1, 103, 114, 151, 187,261- 2, porażka/niepowodzenie 12, 36, 144, 204, 222, 237
322, 327, 329 prosty 236-8
procedura sterowania zagadnieniami i zmiana mi 101, t ypu studium wykonalności 243-4, 244, 272
101-1 03, 116, 161, 187 typy/rodzaje 22, 242-4, 244
procedura zaangażowania interesariuszy 163 w sektorze publicznym 244-5
procedura zarządzania konfiguracją 41, 43, 98, 100-1, 104, wielkość, skala 235- 8, 23 6
256, 293 zamykanie 110, 115, 122, 144, 146-7, 150
procedura zarządzania ryzykiem 84, 84 zezwalanie na zainicjowanie 144-5, 144, 145, 306
360 I Indeks

zezwalanie na realizację 145-7, 146, 147, 307 raport patrz Raport Końcowy Etapu; Raport
zezwolenie na zainicjowanie 123, 139, 143, 143, 144, Nadzwyczajny; Raport Okresowy; Raport
144, 157, 159, 160, 162 o Zagadnieniu; Raport Doświadczeń; Zestawienie
prośba (wniosek) Kierownika Proj ektu o wytyczne 101, Statusu Produktów
102- 3, 123, 143, 150, 150, 177. 184, 185 Raport Doświadczeń 9 1, 132, 148, 149, 153, 154, 210, 210,
prośba (wniosek) Komitetu Sterującego o wytyczne 123, 211,222,223, 223,238,249, 258- 9,261
143, 150, 151, 151 przeg lądanie 132, 148, 152
pryncypia (zasady) 4, 5, 6, 11-14, 230, 230, 237, 328 przeznaczenie 115, 264
patrz także uzasadnienie biznesowe - ciągłość; zarys 264- 5
koncentracja na produktach; wykorzystywanie Raport Końcowy Etapu 115, 148, 148, 149, 200, 210, 210,
doświadczeń; zarządzanie odchyleniami; obowiązki; 2 11, 238, 249
role; etapy; dostosowanie kryteria jakości 260
przedprojektowe działania 23, 37, 40, 109, 121- 2, 121, sporządzanie 209- 1O
249, 329 zarys 258-60
przegląd Raport Końcowy Projektu 115, 117, 152, 153, 154, 221,
kontynuacyjny 57, 245, 222, 223, 223, 238, 249, 290, 308, 311, 329
korzyści 25, 122, 153, 220-1 zarys 257-8
partnerski 50, 57, 245, 316 zawartość 258
poprojektowy 25, 122, 143 Raport Nadzwyczajny 83, 101, 116, 150, 151, 152, 203, 329
typu.gateway" 6, 244-5, 316 reakcja na 150- 1, 203
patrz także działa nia poprojektowe sporządzanie 103, 112, 116, 189
przekazywanie na wyższy szczebel (eskalacja) 17, 82, zarys 260
166, 180, 287-9 Raport o Zagadnieniu 100, 101, 116, 150, 150- 1, 185, 188,
odchyleń 107 188, 189, 19 '' 192, 238, 249
przekroczenie tolerancji 107, 109, 116, 288 przeznaczenie 1OO, 262
ryzyk 82, 185, 188, 189-91, 190, 190 uaktualnianie 102- 3, 184, 185, 190, 190, 197, 191,
sytuacji nadzwyczaj nych 46, 103, 109, 116, 143, 147, 192, 192, 212, 220
165, 234 zarys 262-3
zagadnień 99, 103, 151, 185, 188, 189- 91, 190, 190 Raport Okresowy 37,91, 110, 112, 115, 122, 150- 1, 750,
zagrożeń 111 152, 185- 7, 186, 187, 237-8, 249, 290, 329
Przewodniczący 36, 36-7, 40, 232, 233, 234, 237, 329 zarys 260
konsultacje z 135, 208 patrz także raportowanie
mianowanie 130-1, 131, 132, 235 Raport z Punktu Kontrolnego 113, 115, 122, 18 1, 181,
rola i obowiązki 21, 23-5, 29, 37, 46, 61, 78, 93, 104, 182, 183. 184, 186, 198, 199, 237-8, 241, 249
117 zarys 253
przewodnik po procesach zarządzania ryzkiem 82-3 raportowanie 113
Przygotowanie Projektu - proces 23, 37, 40, 54, 66, 109, częstotliwość 37, 181, 235
121, 123, 129-39,235,241 doświadczeń 114-5
diagram 129 mechanizmy 145, 237
dostosowanie 23 7 okresowe 178, 186- 7, 186, 187, 238
lista kontrolna 305 orga nizacja 133- 4, 139, 180, 197, 230
przeznaczenie 41 - 2, 129 postępów 108, 109, 115, 237, 241
przywództwo 7, 43, 59 reakcja na raporty 150- 1, 203, 209, 211
publikacje struktura raportów 7
Office of Government Commerce (OGC) 6, 6, 37, 41, 44, realizacja 122, 136
82- 3, 232 Rejestr Jakości 51, 55- 6, 60, 56, 114, 163, 225, 249
Wydawnictwa The Stationary Office 316- 7 przeglądanie 181, 181, 184, 185-6, 199, 199
punkt kontrolny 66, 75 sprawdzanie 182, 183
punkty styku 138, 143, 180, 195-7, 235, 254, 269, 270, 277-8 uaktualnianie 179, 180, 180, 198, 199, 205, 206, 206
zarys 274- 5
rada programu 232, 233, 234 format i sposób przedstawienia 277
kryteria jakości 277
 Indeks I 361

Rejestr Ryzyk 83, 160, 160, 162, 164, 166, 168, 170, 170, sterowanie 198
179, 181, 184, 186, 188, 190, 192, 205, 206, 208, 210, patrz także przekazywanie na wyższy szczebel;
211, 221, 222, 224-5, 224, 224, 235, 241, 249 ryzyka
pochodzenie 277 schemat dzialania dla
przeg lądanie 161-3, 165, 167, 170, 183, 185- 6, 191, decyzji doraźnej 150
205,208 etapu inicjowania 138
przeznaczenie 83, 208- 9, 276 Grup Zadań 179, 181- 2, 196, 198-9
uaktualnianie 161, 163-4, 167, 169-70, 179, 181, 182, mechanizmów sterowania projektem 766
185, 185, 189, 190, 191, 192, 197, 2 06, 207, 207, mianowań 737, 133
208, 209, 212, 213 oceniania projektu 222
wpis do 70, 76, 85, 188 planowanego zamknięcia 218
zarys 276- 7 planowania etapu 205
zawartość 83, 276-7 podejmowania dzialań korygujących 191
Rejestr Zagadnień 98, 100, 707, 102- 4, 113-4, 760, 161, projektowania zespolu zarządzania 133- 4
161, 762, 164, 166, 168, 179, 186, 190, 210, 224, 224, przedwczesnego zamknięcia 2 79
225, 249, 261-2 przeglądania stanu etapu 184
przeglądanie 184, 185, 191 przekazania produktów 221
przeznaczenie 261 raportowania końca etapu 2 10
uaktualnianie 180, 181, 787, 182, 184, 185, 185, 788, raportowania okresowego 186
189, 790, 190, 191, 192, 192, 205, 206, 206, 207, 207, sporządzania/uaktualniania Planu Projektu 768, 206
208, 208, 209, 27 7, 213, 279, 220, 220, 222 sporządzania Planu Nadzwyczajnego 2 77
zarys 261 - 2 strategii 159, 160, 162, 164
rekomendowane czynności 115- 6 Uzasadnienia Biznesowego 735, 170, 208
rekomendowane czynności w procesie wyboru formuly realizacji 137
Inicjowanie Projektu 159, 161- 3, 165, 167, 170- 1 zagadnień i ryzyk 788, 190
Przygotowanie Projektu 130, 132-3, 135- 6, 139 zamykania projektu 224
Sterowanie Etapem 179, 181, 183, 186-7, 189, 192 zestawiania Dokumentacji Inicjowania Projektu 772
Zamykanie Projektu 219, 220- 1, 223, 225 zestawiania Założeń Projektu 137
Zarządzani e Dostarcza niem Produktów 197, 199 zezwa lania 144, 146, 148, 153
Za rządzanie Końcem Etapu 205, 207-9, 212 zgromadzenia dotychczasowych doświadczeń 132
Zarządzanie Strategiczne Projektem 145-6, 148, 151- 2 schemat procesu patrz diagram procesu
rekomendowane czynności w zarządzaniu ryzykiem 85 skala znaczenia/wagi 39, 99, 187
relacje klient/dostawca 34, 40, 60, 67, 138, 144, 197, 236, sklonności do akceptacji ryzyka 208
241-2 słuszność 146, 149
relacje komercyjne 34, 60, 67, 144, 197 specjalistyczne prace 112
rezultat 22, 21, 26, 138, 158, 233, 239, 243-4, 315, 330 specyfikacja szczególowa 7
role 33, 35, 240 spory związane z akceptacją produktów 55
adaptacja 231 spójność 7, 11, 38, 55, 70, 104, 306
definiowanie 7, 11-2, 33 standardy 4, 38, 43, 49, 52, 55, 67-8, 135-6, 158- 9, 161-3,
lączenie/wspóldzielenie 33, 36, 39, 178, 233, 237, 244 165, 167, 169, 178,205,229-30,230.232,234-5
w zarządza niu ryzykiem 91 dostawcy 197, 292
ryzyko 5, 13- 4, 17, 77, 81- 93, 111, 203-4, 234- 5 Sterowanie Etapem - proces 721, 122, 123, 143, 177-
analizowanie 68, 76-7, 183, 187- 9, 188, 189, 197,237 192, 177
aspekty 86, 86 lista kontrolna 309-1 O
glówne 27, 170 przeznaczenie 264
identyfikowanie 76, 84-86 sterowanie jakością 56- 60
ocenianie 86-88, 102, 102, 208- 9 sterowanie zagadnieniami 97- 9, 299, 101, 101, 116, 161,
podejście PRINCE2 do 82-92 187, 189
przeglądanie 146, 197, 210 sterowanie zmianą 54, 57, 69, 71, 97-9, 101, 101, 104,
reakcja na 81,89, 89, 90- 1, 146, 148, 188 116, 122, 187, 237, 241
rejestrowanie (wychwytywanie) 183, 185-6, 178- 9, procedura 101-3, 187, 235, 241
188, 189, 197 strategia angażowania 45, 234
362 I Indeks

Strategia Zarządzania Jakością 51,54, 146, 162- 3, 164, sytuacja nadzwyczajna 107, 110, 116, 143, 147, 151, 165,
166, 168, 172, 179,235 234,332
analizowanie/sprawdzenie 163, 212, 223 szacowanie 44, 65, 67- 8, 68, 72- 3, 168, 222, 246
opracowanie 162-3, 162, 163 szanse (okazje) 4, 28, 65, 81, 83, 85- 7, 91 - 2, 252, 275
pochodzenie 234, 273- 4 reakcja na 89- 90, 89, 146, 148
za rys 273- 4 patrz także ryzyko
zawartość 164, 240, 273 szef zmiany biznesowej 233- 4, 233, 234
Strategia Zarządzania Komunikacją 33, 37, 39, 45- 6, 46, szkolenie 7, 43, 134, 138, 229
91, 115, 144, 150, 157, 158, 163- 5, 164, 165, 166, 768,
171, 185-7. 186, 188,210,210,224, 234,238, 249,250 ścieżka audytu jakości 51, 52
dokumentuje 11 S, 144, 186 ścieżka krytyczna 74- 7
format i sposób prezentacji 254 środowisko
kryteria jakości 254 klient/dostawca 22, 33, 231, 239-40, 289
opracowanie 163-4, 164, 165 komercyjne 34, 75, 158, 197, 231, 239- 242
pochodzenie 234, 254 operacyjne (eksploatacji) 138, 220-1
przeg ląd 46, 210 programu 209, 231 - 235
przeznaczenie 253 projektu 5, 5, 6, 14
zarys 253-4 utrzymania 220- 1
zawartość 45-6, 253-4
Strategia Zarządzania Konfiguracją 39, 41, 98- 9, 103, techniki 7
146, 148, 152, 757, 158, 760, 161- 2, 180,241,249, ewaluacji ryzyka 89
250, 256 łańcucha krytycznego 75
analizowanie 221 przeglądu jakości 57-60
format i sposób prezentacji 256-7 szacowania ryzyka 87
opracowanie 160- 2, 160, 161 identyfikowania ryzyka 85
pochodzenie 235, 256 oceny postępów 114
przeznaczenie 256 tematy PRINCE2 5, 5, 6, 7, 17- 8, 17
za rys 256- 7 adaptacja 230, 239-41
zawartość 98-9, 256 dostosowanie 18, 232- 5, 239-41
Strategia Za rząd zania Ryzykiem 83, 92, 108, 146, 757, integrowanie 17
164- 5, 164, 166, 168, 168, 171, 172, 181, 188, 230, zastosowani e 18
234-5,238,249,257 patrz także jakość; organizacja; plan; postępy;
opracowanie 158- 60, 159, 159 ryzyko; Uzasadnienie Biznesowe; zmiana
zarys 275- 6 terminologia 49, 229, 230, 231
zawartość 84, 275- 6 terminy 5, 13,23- 5,27,65- 6, 107, 135, 180-1, 232
strategie 146, 164, 230 ogólnie oszacowane 72, 99
przeglądanie 165, 168 przeglądów kontynuacyjnych 245
strony zewnętrzne 70, 72 szacowane 49
struktura podzialu prac 72 ustanawianie 167
struktura podzialu produktów 67, 212 wymagane 135, 167
diagram 212 z Planu Projektu 170
przyklad 296, 299, 299 testowan ie 57, 72
tworzenie 68-69, 69, 71, 169, 205 tolerancje 102, 109, 113, 138, 166, 170, 177-9, 208, 235
struktu ra podziału ryzyka 85, 86 dla delegowanych uprawnień 107, 165
struktu ra powiązań organizacyjnych 40 Grupy Zadań 113
studium wykonalności 243-4, 244, 272 jakości 51, 52- 5
sumaryczny profil ryzyka 88 kosztów 76
sygnał uruchamiający 121, 124-5, 130 odchylenia od 67, 107
sygnały/wskaźniki wczesnego ostrzegania 82, 84-5, 160, poszerzenie 151
261, 263, 265 przeglądanie 147
system zarządzania jakością 49-50, 52, 54, 240 przekroczen ie 151, 198, 203- 4
ryzyka 82- 4,87- 8, 102
 Indeks I 363

sześćrodzajów 108, 108 weryfikowanie Uzasadnienia Biznesowego 21, 23-4

ustanawianie, ustalanie 13, 26, 107, 149, 178, 189 wiarygodność 24, 269-70, 283
uzgodnione/uzgadnianie 11 O, 11S, 122, 187, 189, członków zespolu projektowego 37, 4S, 292- 3, 30S
197- 8 planu 6S, 20S, 212
wykorzystanie 243 wielofunkcyjność 3- 4, 12, 17, 41
trendy 60, 87, 113- 4 Właściciel Programu 232-3, 233, 234, 244
wlaściciel ryzyka 83, 91, 241
ukierunkowanie 11 , 21, 23, 35-7, 121 właściciel zadania 75
umowa serwisowa/kontrakt 169, 221 wniosek (prośba) o
unikalność 4, 12 wprowadzenie zmiany 31, 38- 9, 97, 98, 99- 101, 103,
uniwersalność 11, 14, 230 114, lS0- 1, 188, 191,239
uprawnienia 3S- 7, 122, 143, 166, 231, 239, 242, 283, 333 Zestawienie Statusu Produktów 183, 18S, 219- 20
patrz także delegowanie Wsparcie Projektu 3, 36, 40, 134, 233, 233, 234, 237
uruchamianie 14S, 178, 191 kompetencje 294
uruchomienie projektu 121, 130 rola i obowiązki 29, 41-2, 46, 50, 61, 78, 83, 93, 104,
ustępstwo 60, 103, 1S1, 18S, 191, 219-20, 258- 9, 263, 333 117, 293- 4
utrzymanie 27-8,38, 138, 148, 1S2, 169, 180, 185, 197, wspólny język 7
o.
21 220- 1, 239, 253 wydanie 97
koszty 26- 27 wykonal ność 21 - 4, 26, 122, 144, 147, 197- 8, 239
organizacja służby 38, 148, 1S2, 18S wykonanie faktyczne 1S2
Uzasadnienie Biznesowe 3,5, 7, 11, 17,21- 9,66, 107, 1S1, wykonawca reakcji na ryzyko 83, 91
191, 209, 243, 245 wykres/diagram Gantta 6S, 76, 266, 323
definicja 21-2 wynik/produkt projektu 22, 22, 26, 34
dokończenie 1S8 wyrównywanie obciążenia 7S
doprecyzowanie 167, 170-1, 170, 171 wytwórca - zakres obowiązków SS
dostosowanie 237-9
format i sposób prezentacji 251 zaangażowanie interesariuszy 44-5, 59, 163, 234
kryteria jakości 252-3 zabezpieczenie dokumentacji projektu 225
odpowiedzia lność za 29, 37, 136 zabezpieczenie produktów 220
opracowywanie 22- 3 zadowolenie klienta S2, 85, 273
pochodzenie 23, 251 zagadnienie 67, 97- 100, 101
podejście PRINCE2 do 22- 28 rejestrowanie/wychwytywanie 101, 163, 178, 185,
przegląd 23, 11O, 178, 204, 209 187- 8, 188, 188
przeznaczenie 21, 2S1 rodzaje 98, 98
różne dostawcy i klienta 1S8, 239 sterowanie 198
uaktualnianie 122, 1S3, 208, 208, 207- 9 patrz także przekazywanie na wyższy szaebel -
utrzymywanie 22-4 zagadnień
weryfikowanie/sprawdzenie 21 - 4, 149 zagrożenie 4, 13,6S, 70, 81,83,85-7
wpływ na 102, 184, 188 reakcja na 89- 91, 89, 89- 90, 146, 146
zarys 251-3 patrz także szanse; ryzyko
zawartość 2S- 8, 251 - 2 zakres 4,7, 13,49,69,70, 138
użytkownicy 12, 33- 4, 34, 36- 8, 36, 102, 138 zalecenia działań następczych 148, 149, 1S2, 153, 154, 210,
angażowanie 69, 71 , 167 210, 211, 217, 221, 221, 222, 221
patrz także Glówny Użytkowni k zależności 72, 74, 74, 77, 167, 266, 241
Zalożenia Projektu 84, 122, 129-31, 129, 131, 133, 135, 136,
warsztaty ryzyka 85 138, 138, 144, 14S, 145, 159, 160, 161, 162, 164, 166,
warsztaty/sesja warsztatowa 8S, 131, 2S4, 2S6 168, 170, 772,23S,237- 8,249,250
wartości docelowe 6S, 97, 102, 108, 113, 122 przeglądanie 122, 14S, 1S9, 161-3, 16S, 167, 170
wartość uzasadniająca poniesione nakłady 34, 37, 89, 244 zarys 269
wartość wypracowana 7, 114 zawartość 54, 269
warunki projektu 11, 14 zestawianie 136- 8, 137, 137
weryfikowanie konfiguracji 98, 101, 161 Zamykanie Projektu - proces 123, 143, 177,217, 217-25, 205
364 I Indeks

lista kontrolna 31 1 zarządzan ie ryzykiem 14

planowe 218-9, 278, 219, 327 przewodnik po procesach 82-3
powiadomienie o za mykan iu projektu 123, 143, 153, patrz także Strategia Zarządzania Ryzykiem
153, 287, 308, 327 Zarządzan ie Ryzykiem (M_o_R) 6, 82, 315
przedwczesne zamknięcie/zakończenie 11O,146-7, Zarządzanie St rategiczne Projektem - proces 727, 723, 129,
148, 149-50, 750,219-20,279,220,223,240,311,329 143-54, 143, 777,277,245,251
zamknięcie projektu 11o, 122, 185, 224, 224, 311 lista kontrolna 306-8
zezwalanie na 144, 151-4, 153, 154, 308 p rzeznaczenie 143
zapas (luz) 74, 74-5, 77 zasadność 7, 11, 21, 23, 81, 87, 99, 104, 107, 110- 1, 122,
zapis(-y) patrz Dziennik; Dziennik Doświadczeń; Rejestr 144
Jakości; Rejestr Ryzyka; Rejestr Zagadnień; Za pisy weryfikowanie, zapewnienie 121, 129, 143, 145, 147,
Obiektu Konfig uracji 149, 152, 204, 209
zapisy akceptacji 51, 60, 258 ciągła 11, 21,81, 104, 107, 207, 239, 288
Zapisy Obiektu Konfiguracji 1OO,104, 114, 122, 127, 249 zasadn ość biznesowa 88, 203- 4, 207-8, 237, 245
format i sposób prezentacji 254 zasoby 65-7, 72
kryteria jakości 255 dostępność 75, 184
pochodzenie 254 przydzielani e; pozyskiwan ie 34- 5, 74-5, 145, 147,
potwierdzenie 181, 183 149, 169
przeznaczenie 1OO, 254 wymagania dla 41, 72, 76
tworzenie/uaktualnianie 160-1, 160, 161, 768, 169, wyrównywanie obciążenia 75
169, 179, 180, 180, 181, 182, 182, 183, 191, 192, zarządza nie 14, 77, 113
192, 198, 199, 199, 205, 206, 211, 212-3, 213, 221, zwolnienie 219-20
221, 222, zatwierdzający (produkt) 55, 59, 61
zarys 254-5 zdol ności ponoszenia ryzyka 208
zawartość 254-5 zdyskontowane przepływy pieniężne 28
zapisy zatwierdzeń 60, 199 zespoly 3
zarządzanie 13 zespól zarządzania programem 233
bieżące, codzienne 1, 35, 40, 66, 130, 178 zespół za rządzania projektem 33, 35-44, 54, 145, 209,
etapowe 11, 13, 107, 109, 121 212,218,221-2,225
operacyjne 13, 35, 107, 109, 121 obowiązki 46, 50, 54, 178
poziomy/szczeble 7, 13, 35, 37, 66, 99, 108-9, 121, 124, struktura 131, 133, 733, 134, 737, 138, 160, 166, 167,
165- 6, 235, 256 168, 169, 171, 772,204,207,231,233- 4,233,234,243
projektem 1,4-7, 11, 13 tworzenie 130, 132-4, 733, 134
strategiczne 6, 13, 35, 109 zestawienie ryzyk 148
struktura 12 zestawienie statusu 101
z wykorzystaniem tolerancj i 7, 11, 13, 35, 37, 107- 8, Zestawienie Statusu Produ któw 98, 100, 184, 186, 186,
110-1, 115, 143, 165 209,270,278,219, 220,238,249
zarządzanie zmianą 7 pochodzenie 114, 268
Zarządzanie Dostarczaniem Produktów - proces 40, 66, polecenie przygotowania/sporządzenia 183, 185,
195-200, 195, 243 219- 20
lista kontrolna 310 przeznaczenie 100-1, 114, 268
przeznaczen ie 195 zarys 268- 9
zarządzanie jakością 49-50, 209, 212 zawartość 114, 268
zarządzanie konfiguracją 14, 24, 41, 97, 100, 161, 180 zewnętrzne czynniki/zdarzenia 53, 11O, 1SO, 204, 229
system 44, 97, 161 zezwalanie 143-9, 144, 145, 146, 147, 148, 149, 152-3,
Zarządzanie Końcem Et apu - proces 25, 37, 41-2, 54, 66, 152, 753, 154
98, 110, 727, 122, 123, 143, 157, 173, 203-213 listy kontrolne 306-8
lista kontrolna 310- 1 na wykonan ie Grupy Zadań 178, 179, 180
przeznaczenie 203-4 na zainicjowanie projektu 143, 144-5, 145, 245, 306
za rządzanie l udźmi 42-3 na realizację etapu 108, 11O, 123, 143, 148, 177, 179,
zarządzanie projektem 4, 5 179, 307
cztery szczeble, poziomy 35, 35 na realizację Planu Nadzwyczajnego 748, 307
 Indeks I 365

na realizację projektu 25, 109, 123, 143, 145, 146, 157,

172, 173, 287, 306
na wykonanie Grupy Zadań 113, 123, 177, 179, 195, 196
na zain icjowanie projektu 123, 139, 143, 144, 157,
159, 160, 162
na zamknięcie proj ektu 152, 218
przez Kierownika Projektu 11O
zezwolenie 143- 9, 143, 744, 146, 148, 152, 157, 159, 160,
762, 173
zlecenie przygotowania projektu 23, 25, 35- 6, 84, 121,
123, 129, 130, 131, 132, 135, 135,237- 8,250
rewizja 150
zlożoność planu 72, 76
zlożoność powiązań między produktami 1OO, 160
złożoność produktu 55, 267, 272
złożoność projektu 13-4, 18, 35, 39, 67- 8, 84, 111, 165,
229,236,254,287
zmiana 3,5, 17,81,82,97- 104
obowiązki 103, 104
wniosek o wprowadzenie 17, 38-9, 97, 98, 99, 1OO,
103, 150, 187,261 - 2,334
zatwierdzona 209, 223
zmiana biznesowa(-u) 3, 22, 82, 333
zmienne w projekcie 5
zobowiązania umowne 242
zwrot z inwestycji (ROI) 27
zwykła dzialal ność biznesowa 3, 152