Tytuł oryginału: Effective Project Management: Traditional ...pdf.helion.pl/efzap4/efzap4.pdf ·...

Tytuł oryginału: Effective Project Management: Traditional, Agile, Extreme, 6th edition

Tłumaczenie: Magda Witkowska

ISBN: 978-83-246-3906-9

Published by John Wiley & Sons, Inc. All rights reserved. This translation published under license with the original publisher John Wiley & Sons, Inc.Translation copyright © 2013 by Helion S.A.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise without either the prior written permission of the Publisher.

Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://onepress.pl/user/opinie/efzap4Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://onepress.pl (księgarnia internetowa, katalog książek)

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://onepress.pl/rt/efzap4

http://onepress.pl/rf/efzap4

http://onepress.pl/ro/efzap4

http://onepress.pl

http://ebookpoint.pl/r/JH8P6

SPIS TRE�CI

O autorze ............................................................................19

Przedmowa ..........................................................................21

Wprowadzenie .....................................................................23

Cz�� I Definiowanie grup procesóww zarz�dzaniu projektami i korzystanie z nich 43

Rozdzia� 1. Czym jest projekt? ................................................................47Definicja projektu ................................................................................................ 48

Sekwencja dzia�a� ............................................................................................ 48Niepowtarzalne dzia�ania ............................................................................... 48Z�o�one dzia�ania ............................................................................................ 49Powi�zane dzia�ania ........................................................................................ 49Jeden cel ............................................................................................................ 49Okre�lony czas realizacji ................................................................................ 50Bez przekraczania bud�etu ............................................................................. 50Zgodnie z wymaganiami ................................................................................ 50Biznesowa definicja projektu ..........................................................................51

Czym jest program? ...............................................................................................51Tworzenie tymczasowych biur programu .................................................... 52Tworzenie sta�ych biur programu ................................................................. 52

Czym jest portfel projektów? .............................................................................. 52Trójk�t zakresu projektu ......................................................................................53

Zakres ................................................................................................................ 54Jako�� ................................................................................................................. 54Koszty .................................................................................................................55

Poleć książkęKup książkę



6 Efektywne zarz�dzanie projektami

Czas .....................................................................................................................55Zasoby ................................................................................................................56Trójk�t zakresu projektu jako zrównowa�ony system ................................56Nadawanie priorytetów zmiennym trójk�ta zakresu pod k�tem

usprawnie� w procesie zarz�dzania zmian� ............................................. 58Trójk�t zakresu projektu w praktyce ............................................................. 58

Zarz�dzanie chochlikami .................................................................................... 59Chochlik zakresu ............................................................................................. 59Chochlik nadziei ............................................................................................. 60Chochlik wysi�ków .......................................................................................... 60Chochlik cech .................................................................................................. 60

Klasyfikowanie projektów i jego znaczenie ...................................................... 62Wskazywanie kryterium klasyfikacji projektów .......................................... 62Klasyfikacja wed�ug cech projektów ............................................................. 62Klasyfikacja wed�ug typów projektów ...........................................................65

Podsumowanie .......................................................................................................65Pytania do dyskusji ................................................................................................65

Rozdzia� 2. Czym jest zarz�dzanie projektami? .........................................67Podstawy zarz�dzania projektami ...................................................................... 68

Jaki problem biznesowy ma rozwi�za� ten projekt? ................................... 69Co b�dzie trzeba zrobi�? ................................................................................. 70Co zostanie zrobione? ..................................................................................... 70Jak to zostanie zrobione? ................................................................................ 70Sk�d b�dzie wiadomo, �e to zosta�o zrobione? ........................................... 70Na ile skutecznie zosta�o to zrobione? ..........................................................71

Czym tak naprawd� s� wymagania projektu? ................................................... 72Modele cyklu zarz�dzania projektami — wprowadzenie ............................... 78

Jasne formu�owanie celu i rozwi�zania ........................................................ 79Metody tradycyjnego zarz�dzania projektami ............................................ 86Metody zwinnego zarz�dzania projektami ..................................................91Metody ekstremalnego zarz�dzania projektami ......................................... 97Modele cyklu zarz�dzania projektem emertxe .......................................... 101Przegl�d modeli PMLC .................................................................................103

Wybór najlepiej dopasowanego modelu PMLC .............................................105Ca�kowity koszt ..............................................................................................106Czas trwania projektu ....................................................................................107Stabilno�� rynku .............................................................................................107Technologia .....................................................................................................107Klimat biznesowy ...........................................................................................107Liczba dzia�ów, na które oddzia�uje projekt ...............................................108Uwarunkowania organizacyjne ....................................................................108Umiej�tno�ci i kompetencje zespo�u projektowego ..................................109

Podsumowanie .....................................................................................................109Pytania do dyskusji .............................................................................................. 110




Spis tre�ci 7

Rozdzia� 3. Grupy procesów w ramach zarz�dzania projektami .................111Definiowanie pi�ciu grup procesów ................................................................. 112

Grupa procesów wyznaczania zakresu ........................................................ 112Grupa procesów planowania ........................................................................ 113Grupa procesów rozpoczynania ................................................................... 114Grupa procesów monitorowania i kontroli ............................................... 114Grupa procesów zamykania projektu .......................................................... 115

Definiowanie dziewi�ciu obszarów wiedzy ..................................................... 115Zarz�dzanie integracj� ................................................................................... 116Zarz�dzanie zakresem .................................................................................... 116Zarz�dzanie czasem ........................................................................................ 116Zarz�dzanie kosztami .................................................................................... 116Zarz�dzanie jako�ci� ...................................................................................... 117Zarz�dzanie zasobami ludzkimi .................................................................. 118Zarz�dzanie komunikacj� .............................................................................122Zarz�dzanie ryzykiem ....................................................................................123Zarz�dzanie zaopatrzeniem .......................................................................... 135

Mapowanie obszarów wiedzy na grupy procesów ..........................................149Na czym polega mapowanie? ........................................................................150Jak korzysta� z mapowania? ..........................................................................150Definiowanie modeli PMLC na podstawie grup procesów .....................150Spojrzenie w przysz�o�� — mapowanie grup procesów

w celu wyznaczenia z�o�onych modeli PMLC ........................................ 151Podsumowanie ..................................................................................................... 151Pytania do dyskusji .............................................................................................. 151

Rozdzia� 4. Wyznaczanie zakresu projektu TPM ......................................153Narz�dzia, schematy i procesy stosowane

w wyznaczaniu zakresu projektu ....................................................................154Zarz�dzanie oczekiwaniami klienta ................................................................. 155

Odró�nianie potrzeb od zachcianek ........................................................... 155Proces wyznaczania zakresu projektu ..........................................................156Spotkanie dotycz�ce zakresu projektu ........................................................160

Podsumowanie .....................................................................................................199Pytania do dyskusji ............................................................................................. 200

Rozdzia� 5. Planowanie projektu TPM ....................................................201Narz�dzia, schematy i procesy w planowaniu projektu ................................ 202Znaczenie planowania ....................................................................................... 204Pakiety oprogramowania w planowaniu projektów ...................................... 205

Czy potrzebuj� pakietu oprogramowania? ................................................ 206Narz�dzia planowania projektów ............................................................... 207Ile czasu powinno zajmowa� planowanie? ................................................. 209Prowadzenie sesji planistycznej ................................................................... 209

Wspólne sesje planowania projektowego .........................................................210Planowanie sesji .............................................................................................. 211Prowadzenie wspólnej sesji planowania projektu ......................................218





Tworzenie struktury podzia�u pracy .................................................................218Tworzenie WBS na podstawie RBS ..............................................................218Zastosowania struktury podzia�u pracy ......................................................221Tworzenie struktury pracy ........................................................................... 222Stosowanie WBS w przypadku du�ych projektów .................................... 225Tworzenie WBS metod� iteracyjn� ............................................................. 225Sze�� kryteriów testowania kompletno�ci struktury podzia�u pracy ..... 226Podej�cia do tworzenia struktury podzia�u pracy ......................................231Prezentacja graficzna struktury podzia�u pracy ........................................ 236

Szacowanie ........................................................................................................... 236Szacowanie czasu trwania projektu ............................................................. 239Ilo�� zasobów a czas trwania .........................................................................241Zmienno�� czasu trwania dzia�ania ............................................................ 243Sze�� metod prognozowania czasu trwania dzia�ania .............................. 244Cykle szacowania ........................................................................................... 248Prognozowanie ilo�ci potrzebnych zasobów ............................................ 249Planowanie zasobów ..................................................................................... 252Prognozowanie kosztów ................................................................................253

Tworzenie diagramu sieci projektu .................................................................. 256Tworzenie kompletnego diagramu sieci projektu .................................... 256Korzy�ci z tworzenia harmonogramu sieciowego .................................... 257Budowanie diagramu sieci metod� diagramowania pierwsze�stwa ...... 259Zale�no�ci ........................................................................................................261Ograniczenia .................................................................................................. 263Zmienne opónione ...................................................................................... 267Tworzenie wst�pnego harmonogramu projektu ....................................... 268Analiza wst�pnego diagramu sieci projektu .............................................. 273Skracanie harmonogramu ............................................................................ 273Rezerwa mened�erska ................................................................................... 276

Pisanie skutecznej propozycji projektu ........................................................... 277Tre�� propozycji projektu ............................................................................ 277Format propozycji projektu ......................................................................... 279

Zgoda na uruchomienie projektu .................................................................... 279Podsumowanie .................................................................................................... 280Pytania do dyskusji ............................................................................................. 280

Rozdzia� 6. Uruchamianie realizacji projektu TPM ...................................283Narz�dzia, szablony i procesy

niezb�dne do rozpocz�cia prac projektowych ............................................ 284Rekrutacja zespo�u projektowego .................................................................... 284

Cz�onkowie podstawowego zespo�u projektowego .................................. 285Zespó� klienta ................................................................................................. 289Cz�onkowie zespo�u zaanga�owani na zlecenie ........................................ 289Równowa�enie zespo�u ..................................................................................291Jak uwolni� potencja� zespo�u projektowego? ........................................... 293Plan rozwoju zespo�u .................................................................................... 293




Spis tre�ci 9

Prowadzenie spotkania inicjuj�cego ................................................................ 294Cz�� prowadzona przez sponsora ............................................................. 294Cz�� prowadzona przez mened�era projektu .......................................... 295Cel spotkania inicjuj�cego ........................................................................... 295

Ustalanie zasad pracy w zespole ....................................................................... 299W jakich sytuacjach trzeba okre�li� zasady pracy w zespole? .................. 300Kwatera g�ówna zespo�u ................................................................................312

Zarz�dzanie zmianami zakresu projektu ......................................................... 313Proces zarz�dzania zmianami zakresu projektu ........................................314Rezerwa mened�erska ....................................................................................317Bank zakresów .................................................................................................318

Zarz�dzanie komunikacj� w zespole ................................................................318Tworzenie modelu komunikacji ..................................................................319Zarz�dzanie komunikacj� poza zespo�em ..................................................323

Alokacja zasobów ................................................................................................325Poziomowanie zasobów ................................................................................325Odpowiednio wypoziomowany harmonogram ....................................... 328

Strategie poziomowania zasobów .................................................................... 328Wykorzystywanie dost�pnych zapasów czasu ........................................... 329Przesuwanie daty zako�czenia projektu .................................................... 329Wyg�adzanie ....................................................................................................330Alternatywne metody tworzenia harmonogramu dzia�a� .......................330Wp�yw poziomowania zasobów na koszty projektu .................................332

Finalizacja harmonogramu projektu ...............................................................332Pakiety robocze ....................................................................................................335

Cel zastosowania pakietu roboczego ...........................................................335Format pakietu roboczego ............................................................................336

Podsumowanie .....................................................................................................339Pytania do dyskusji ..............................................................................................339

Rozdzia� 7. Monitorowanie i kontrola post�pów prac nad projektem TPM ....341Narz�dzia, szablony i procesy niezb�dne w monitorowaniu

i kontrolowaniu post�pów prac .................................................................... 342System raportowania o post�pach ....................................................................343

Rodzaje raportów o stanie projektów ..........................................................343Aktualizowanie informacji .......................................................................... 347Cz�stotliwo�� raportowania ......................................................................... 348Odchylenia od planu .................................................................................... 348

Stosowanie graficznych narz�dzi raportowania .............................................350Diagramy Gantta ............................................................................................350Raporty-semafory ........................................................................................... 351Diagramy wypalania ...................................................................................... 351Trend odchyle� od terminowej realizacji kamieni milowych

(celów cz�stkowych) .................................................................................... 351Analiza warto�ci uzyskanej ...........................................................................356Integrowanie wykresów trendu odchyle� od terminowej realizacji

kamieni milowych z analiz� warto�ci uzyskanej .....................................361





Zarz�dzanie bankiem zakresów ........................................................................ 364Tworzenie i prowadzenie rejestru problemów ................................................365Spotkania monitoruj�ce post�py prac ..............................................................365

Kto powinien uczestniczy� w spotkaniach monitoruj�cych? ..................366W jakich porach organizowa� spotkania monitoruj�ce? ..........................366Czemu s�u�� spotkania monitoruj�ce? .......................................................366Zakres spotka� monitoruj�cych ................................................................. 367Codzienne 15-minutowe spotkania monitoruj�ce ................................... 368Spotkania po�wi�cone problemom ............................................................ 368

Zarz�dzanie eskalacj� problemów ................................................................... 369Strategie na poziomie mened�era projektu ............................................... 370Strategie na poziomie mened�erów zasobów ............................................ 370Strategie na poziomie klienta ...................................................................... 370Strategie zapobiegania eskalacji problemów ..............................................371

Zgoda na zako�czenie projektu ....................................................................... 372Podsumowanie .................................................................................................... 372Pytania do dyskusji ..............................................................................................373

Rozdzia� 8. Zamykanie projektu TPM .....................................................375Narz�dzia, szablony i procesy niezb�dne w monitorowaniu

i kontrolowaniu post�pów prac .................................................................... 376Procedury akceptacji rezultatów projektu przez klienta ............................... 376Zamykanie projektu ........................................................................................... 376Uzyskanie akceptacji rezultatów projektu przez klienta .............................. 377

Akceptacja nieformalna ................................................................................ 377Akceptacja formalna ..................................................................................... 377

Dostarczanie zamówionych elementów .......................................................... 378Podej�cie stopniowe ...................................................................................... 378Podej�cie szokowe .......................................................................................... 378Podej�cie równoleg�e ..................................................................................... 379Podej�cie „jednostka po jednostce” ............................................................ 379

Kompletowanie dokumentacji projektu ......................................................... 379Zgromadzone informacje b�d� pomocne przy wprowadzaniu

póniejszych zmian do produktu ............................................................ 379Na podstawie zapisów historycznych mo�emy dok�adniej i szybciej

prognozowa� czasy trwania dzia�a� i zada� oraz kosztyprzysz�ych projektów ................................................................................. 379

Dokumentacj� mo�emy wykorzystywa� jako materia�y szkoleniowedla przysz�ych mened�erów projektów ................................................... 380

W dokumentacji mog� poszukiwa� wskazówek zespo�y pracuj�ce nadprzysz�ymi projektami ............................................................................... 380

Na podstawie dokumentacji kierownicy liniowi mog� udoskonala�metody oceny pracy cz�onków zespo�ów projektowych ....................... 380

Audyt powdro�eniowy .......................................................................................381Raport zamykaj�cy ..............................................................................................383wi�towanie sukcesu .......................................................................................... 384Podsumowanie .....................................................................................................385Pytania do dyskusji ..............................................................................................385




Spis tre�ci 11

Cz�� II Definiowanie cykli i strategiizarz�dzania projektami 387

Rozdzia� 9. Ogólny obraz projektu a jego stopie� skomplikowaniai niepewno�� .......................................................................389Stopie� skomplikowania i niepewno�� a zarz�dzanie projektami .............. 390

Wymagania ......................................................................................................393Elastyczno�� ....................................................................................................393Dostosowywanie si� ........................................................................................395Niepewno�� i stopie� skomplikowania a ryzyko .......................................395Niepewno�� i stopie� skomplikowania a spójno�� zespo�u .................... 396Niepewno�� i stopie� skomplikowania a komunikacja .......................... 397Niepewno�� i stopie� skomplikowania a zaanga�owanie klienta .......... 398Niepewno�� i stopie� skomplikowania a specyfikacja ............................ 400Niepewno�� i stopie� skomplikowania a zmiany .................................... 402Niepewno�� i stopie� skomplikowania a warto�� biznesowa ................. 404

Podsumowanie .................................................................................................... 405Pytania do dyskusji ............................................................................................. 405

Rozdzia� 10.Tradycyjne zarz�dzanie projektami .......................................407Na czym polega tradycyjne zarz�dzanie projektami? ................................... 408Liniowy model cyklu zarz�dzania projektem ................................................ 409

Definicja ...........................................................................................................410Cechy charakterystyczne ...............................................................................410Zalety ................................................................................................................415Wady .................................................................................................................417Kiedy nale�y stosowa� liniowy model PMLC ........................................... 420Warianty liniowego modelu PMLC ........................................................... 420Adaptacja i integracja narz�dzi, szablonów i procesów w celu

maksymalnie efektywnego wykorzystania liniowych modeli PMLC ...... 423Stopniowy model cyklu zarz�dzania projektem ............................................ 424

Definicja .......................................................................................................... 424Cechy charakterystyczne .............................................................................. 425Zalety ............................................................................................................... 425Wady ................................................................................................................ 427Kiedy nale�y stosowa� stopniowy model PMLC? ..................................... 430Adaptacja i integracja narz�dzi, szablonów i procesów

w celu maksymalnie efektywnego wykorzystaniastopniowego modelu PMLC ..................................................................... 430

Zarz�dzanie projektami metod� �a�cucha krytycznego ................................431Czym jest �a�cuch krytyczny? ...................................................................... 432Odchylenia czasu trwania: naturalne i specjalne .......................................433Statystyczne uzasadnienie metody �a�cucha krytycznego ...................... 434Podej�cie do zarz�dzania projektami od strony �a�cucha krytycznego ......435Bufory .............................................................................................................. 438





Zarz�dzanie buforami .................................................................................. 439Historia zarz�dzania projektami metod� �a�cucha krytycznego ........... 442


Rozdzia� 11. Zwinne zarz�dzanie projektami ............................................447Na czym polega zwinne zarz�dzanie projektami? ......................................... 449

Wdra�anie modeli APM ............................................................................... 450Zespo�y projektowe APM pracuj�ce w jednym miejscu ........................... 452

Iteracyjny model cyklu zarz�dzania projektem ............................................. 454Definicja iteracyjnego modelu PMLC ........................................................ 455Cechy charakterystyczne .............................................................................. 460Zalety ................................................................................................................461Wady ................................................................................................................ 462Rodzaje iteracyjnych modeli PMLC ........................................................... 463Kiedy nale�y stosowa� iteracyjny model PMLC ....................................... 469

Adaptacyjny model cyklu zarz�dzania projektem ......................................... 470Definicja adaptacyjnego modelu PMLC .................................................... 470Cechy charakterystyczne .............................................................................. 475Zalety ............................................................................................................... 476Wady ................................................................................................................ 477Rodzaje adaptacyjnych modeli PMLC ....................................................... 478Kiedy nale�y stosowa� adaptacyjne modele PMLC? .................................519

Adaptacja i integracja narz�dzi, szablonów i procesów APM .......................521Definiowanie zakresu kolejnej iteracji lub cyklu .......................................521Planowanie nast�pnej iteracji lub cyklu ..................................................... 522Rozpoczynanie nast�pnej iteracji lub cyklu ...............................................523Monitorowanie i kontrola nast�pnej iteracji lub cyklu ............................523Zamykanie nast�pnej iteracji lub cyklu ...................................................... 524Decyzja o rozpocz�ciu nast�pnej iteracji lub cyklu .................................. 524Zamykanie projektu ...................................................................................... 524


Rozdzia� 12. Ekstremalne zarz�dzanie projektami .....................................529Na czym polega ekstremalne zarz�dzanie projektami? .................................530Ekstremalny model cyklu zarz�dzania projektem .........................................530

Definicja ...........................................................................................................530Charakterystyka projektu ekstremalnego ....................................................531Zalety .................................................................................................................532Wady..................................................................................................................533Ekstremalny model INSPIRE........................................................................533

Na czym polega zarz�dzanie projektami emertxe? ....................................... 548Model cyklu zarz�dzania projektem emertxe ............................................ 548Kiedy nale�y stosowa� model emertxe PMLC? .......................................... 548




Spis tre�ci 13

Stosowanie narz�dzi, szablonów i procesów w celu maksymalnieefektywnego wykorzystania modelu emertxe PMLC ................................. 549

Definiowanie zakresu kolejnej fazy ............................................................. 549Planowanie nast�pnej fazy ............................................................................ 550Rozpoczynanie nast�pnej fazy ......................................................................551Monitorowanie i kontrola nast�pnej iteracji lub cyklu.............................551Zamykanie fazy............................................................................................... 552Decyzja o rozpocz�ciu nast�pnej fazy ......................................................... 552Zamykanie projektu....................................................................................... 552

Podsumowanie .................................................................................................... 552Pytania do dyskusji ..............................................................................................553

Cz�� III Budowa skutecznej infrastrukturyzarz�dzania projektami 555

Rozdzia� 13. Biuro wsparcia projektów ....................................................557Przes�anki tworzenia biur zarz�dzania projektami ....................................... 558Czym jest biuro wsparcia projektów? .............................................................. 560

Jednostka organizacyjna utworzona na sta�e albo na okre�lony czas .... 560Portfel us�ug �wiadczonych przez PSO .......................................................561Okre�lony portfel projektów ........................................................................563

Nazewnictwo biur wsparcia projektów ........................................................... 564Definiowanie misji biura wsparcia projektów ................................................565Formu�owanie celów PSO ..................................................................................566Funkcje PSO .........................................................................................................566

Wspieranie projektów ....................................................................................566Konsultacje i doradztwo ............................................................................... 567Tworzenie metod i standardów ................................................................... 569Narz�dzia informatyczne ............................................................................. 570Szkolenie ......................................................................................................... 570Doradztwo w zarz�dzaniu zasobami potrzebnymi

do realizacji projektów ............................................................................... 572Struktura organizacyjna PSO ........................................................................... 574

Wirtualne i rzeczywiste biura wsparcia projektów ................................... 574Biura proaktywne i reaktywne ..................................................................... 574Biuro powo�ane na czas okre�lony i na sta�e ............................................. 575Program i projekt ........................................................................................... 575Biuro korporacyjne i funkcjonalne ............................................................ 575Biura centralne i regionalne ......................................................................... 575

Miejsce PSO w organizacji ................................................................................ 576Jak zorientowa� si�, �e PSO jest nam potrzebne? ........................................... 578

Raport Standish Group ................................................................................ 578Sygna�y wskazuj�ce, �e PSO jest organizacji potrzebne ........................... 582

Tworzenie PSO .................................................................................................... 584Etapy wzrostu PSO ........................................................................................ 584Planowanie PSO ............................................................................................. 586





Trudno�ci zwi�zane z tworzeniem PSO .......................................................... 596Szybko�� i cierpliwo�� ................................................................................... 597Wdra�anie PSO metod� z do�u do góry ..................................................... 598My�lenie systemowe ...................................................................................... 598Systemy na poziomie ca�ej organizacji ....................................................... 598Zarz�dzanie wiedz� ....................................................................................... 598Uczenie si� ...................................................................................................... 599Otwarta komunikacja ................................................................................... 599

Biuro wsparcia projektów przysz�o�ci ............................................................. 599Centralne i regionalne BP4SO ..................................................................... 600Pracownicy BP4SO .........................................................................................601Inne uwagi ...................................................................................................... 602


Rozdzia� 14. Zarz�dzanie portfelem projektów .........................................605Wprowadzenie do zarz�dzania portfelem projektów ................................... 606

Czym jest projekt portfelowy? ..................................................................... 606Czym jest portfel projektów? ....................................................................... 607Czym jest zarz�dzanie portfelem projektów? ............................................ 608G�ówne etapy zarz�dzania portfelem projektów ...................................... 608

Tworzenie strategii portfela ...............................................................................610Ocena zgodno�ci projektu ze strategi� portfela ..............................................618Hierarchizacja projektu i przyznanie funduszy ..............................................619Budowanie zrównowa�onego portfela,

z�o�onego z uszeregowanych projektów ...................................................... 625Zarz�dzanie aktywnymi projektami .................................................................635

Czego nauczyli�my si� podczas realizacji projektu? ................................. 643Rola i funkcje PSO w zarz�dzaniu portfelem projektów .............................. 644

Sponsor projektu ........................................................................................... 644Mened�er portfela ......................................................................................... 644

Przygotowanie projektu do zg�oszenia go do portfela .................................. 645Statut projektu dostosowany do potrzeb zarz�dzania portfelem ........... 646Dwuetapowe sk�adanie propozycji projektu ............................................. 649Przedk�adanie ca�ej propozycji projektu za jednym razem ..................... 649

Zwinne zarz�dzanie portfelem projektów ...................................................... 650Integracja modelu PMLC w ramach procesu

zwinnego zarz�dzania portfelem projektów ...........................................653Wyzwania w zarz�dzaniu zwinnymi portfelami ........................................656Wybór zrównowa�onego portfela ............................................................... 657Zarz�dzanie aktywnymi projektami ........................................................... 660

Podsumowanie .....................................................................................................661Pytania do dyskusji ..............................................................................................661




Spis tre�ci 15

Rozdzia� 15. Tworzenie programu ci�g�ego doskonalenia procesówi zarz�dzanie nim ...............................................................663Praktyki i procesy w zarz�dzaniu projektami ................................................. 664

Proces zarz�dzania projektami .................................................................... 664Praktyka zarz�dzania projektami .................................................................666

Dojrza�o�� procesów i praktyk ......................................................................... 669Poziom 1. Ad hoc lub nieformalny ............................................................. 669Poziom 2. Udokumentowane procesy ....................................................... 670Poziom 3. Udokumentowane procesy stosowane przez wszystkich ...... 670Poziom 4. Integracja z procesami biznesowymi ....................................... 670Poziom 5. Ci�g�e doskonalenie ....................................................................671

Ocena dojrza�o�ci procesu i praktyki zarz�dzania projektami .................... 672Macierz jako�ci procesów i mapa strefowa ................................................ 672Jakie procesy zdefiniowano dotychczas? .................................................... 677

Stosowanie modelu ci�g�ego doskonalenia procesów (CPIM) .................... 679Etap 1. Podstawy ............................................................................................ 679Etap 2. Ocena i analiza ..................................................................................681Etap 3. Program doskonalenia ..................................................................... 683Etap 4. Kontrola wyników ........................................................................... 684

Rola i zakres obowi�zków PSO ........................................................................ 684Korzy�ci p�yn�ce z wdra�ania CPIM ............................................................... 684CPIM w odniesieniu do procesów biznesowych ........................................... 685

Charakterystyka procesów biznesowych .................................................... 686Obserwowanie sygna�ów �wiadcz�cych o konieczno�ci

wprowadzania udoskonale� ..................................................................... 690Dokumentacja bie��cego procesu biznesowego ........................................691Prognozowanie stanu przysz�ego ................................................................ 692Znajdowanie luki mi�dzy stanem bie��cym i przysz�ym ........................ 692Definicja projektu doskonalenia procesu biznesowego .......................... 692

Narz�dzia, szablony i procesy w doskonaleniu procesów biznesowych .... 694Diagramy Ishikawy i analiza przyczyn ród�owych ................................. 694Wykresy kontrolne ........................................................................................ 697Schematy blokowe ......................................................................................... 697Histogramy ..................................................................................................... 698Analiza Pareto ................................................................................................ 699Wykresy przebiegu pracy ...............................................................................701Wykresy punktowe .........................................................................................701Analiza pola si� ................................................................................................701Warto�ci progowe .......................................................................................... 704






Cz�� IV Zarz�dzanie realiami projektów 707

Rozdzia� 16. Strategie prewencyjne i interwencyjne w przypadkuprojektów zagro�onych .......................................................709Definicja projektu zagro�onego ........................................................................710

Dlaczego projekty staj� si� zagro�one i dlaczego ko�cz� si� pora�k�? .......711Zarz�dzanie zagro�onymi projektami .............................................................715

Strategie prewencyjne .....................................................................................715Korzystanie z narz�dzi, szablonów i procesów w celu zapobiegania

otrzymywaniu przez projekty statusu zagro�onych ...............................716Strategie interwencyjne ................................................................................. 723Szablon procesu interwencyjnego ................................................................735

Role i obowi�zki PSO w odniesieniu do zagro�onych projektów .............. 737Analiza sytuacji bie��cej ............................................................................... 739Weryfikacja po��danego celu ...................................................................... 739Ocena dost�pnych opcji ............................................................................... 739Opracowanie zmodyfikowanego planu ..................................................... 739


Rozdzia� 17. Organizacja projektów wielozespo�owych ...............................741Definicja projektu wielozespo�owego ...............................................................741Wyzwania zwi�zane z zarz�dzaniem projektami wielozespo�owymi ......... 743

Praca z zespo�ami pochodz�cymi z ró�nych firm .................................... 744Praca z zespo�ami o zdecydowanie niezale�nej kulturze ......................... 745Praca z ró�nymi procesami ró�nych zespo�ów ......................................... 745Uwzgl�dnianie konkurencyjnych priorytetów ......................................... 745Komunikacja w ramach struktury zespo�u ................................................ 746Tworzenie struktury zarz�dzania projektem ............................................. 746Wybór konkretnego modelu PMLC ........................................................... 746Opracowywanie zintegrowanego planu i harmonogramu projektu ..... 747Wyznaczanie metody gromadzenia wymaga� .......................................... 747Wyznaczanie procesu zarz�dzania zmianami zakresu ............................ 748Definiowanie struktury spotka� zespo�u ................................................... 748Wyznaczanie praktycznych poziomów raportowania ............................. 748Dzielenie zasobów mi�dzy zespo�ami ........................................................ 749Decyzje kadrowe na ró�nych etapach realizacji modeli PMLC .............. 750Poszukiwanie swojego zast�pcy ................................................................... 750

Klasyfikacja projektów wielozespo�owych ...................................................... 750Dwa zespo�y .....................................................................................................751Wi�ksza liczba zespo�ów ................................................................................751

Struktura biura projektu ................................................................................... 752Charakterystyka biura projektu ...................................................................753Zalety biura projektu .................................................................................... 755Wady biura projektu ..................................................................................... 757Kiedy nale�y korzysta� z biura projektów? ................................................ 758




Spis tre�ci 17

Struktura zespo�u g�ównego .............................................................................. 758Charakterystyka zespo�u g�ównego ............................................................. 759Zalety zespo�u g�ównego ............................................................................... 762Wady zespo�u g�ównego ............................................................................... 764Kiedy nale�y korzysta� z zespo�u g�ównego? ............................................. 765

Struktura superzespo�u ...................................................................................... 766Charakterystyka superzespo�u ..................................................................... 767Zalety superzespo�u ....................................................................................... 770Wady superzespo�u .........................................................................................771Kiedy nale�y korzysta� z superzespo�u? ..................................................... 772


Rozdzia� 18. Zarz�dzanie rozwojem zawodowym zespo�ów projektowych ....775Jaki problem zwi�zany z rozwojem zawodowym ma zosta� rozwi�zany? ....... 776Co b�dzie trzeba zrobi�? .................................................................................... 776

Zdobywanie do�wiadczenia ......................................................................... 777Bezpo�rednie szkolenie praktyczne ............................................................ 777Po�rednie szkolenie praktyczne ................................................................... 777Aktywno�� profesjonalna ............................................................................. 778

Co zostanie zrobione? ........................................................................................ 778Jak to zostanie zrobione? ................................................................................... 778Sk�d b�dzie wiadomo, �e to zosta�o zrobione? .............................................. 779Na ile skutecznie zosta�o to zrobione? ............................................................ 779Dok�d i�� dalej? Nowa koncepcja na przysz�o�� ............................................ 779

Grupa stanowisk PM/BA ............................................................................. 779Zastosowanie struktury PM/BA na potrzeby rozwoju zawodowego ..... 788Jak móg�by wygl�da� program rozwoju zawodowego? ............................ 788Planowanie kariery zawodowej z wykorzystaniem struktury BA/PM ... 792

Jeszcze nowsza koncepcja .................................................................................. 793Podsumowanie .................................................................................................... 795Pytania do dyskusji ............................................................................................. 796

S�owniczek skrótów ............................................................797

Strona internetowa ksi��ki ..................................................801

Bibliografia ........................................................................803

Skorowidz .........................................................................811





Podzi�kowaniaChcia�bym tu szczególnie podzi�kowa� wyk�adowcom z co najmniej 250uniwersytetów i college’ów z ca�ego �wiata, którzy zdecydowali si� wykorzy-sta� poprzednie wydania tej ksi��ki w swojej pracy. Wielu z nich zg�osi�o miswoje opinie i uwagi, za co równie� jestem bardzo wdzi�czny. Du�a cz�� tychsugestii zosta�a uwzgl�dniona w szóstym wydaniu. Mam równie� d�ug wdzi�cz-no�ci wobec licznych konsultantów i firm z ca�ego �wiata, którzy postanowi-li zastosowa� adaptacyjn� struktur� projektu (APF) i znaleli czas, aby przed-stawi� mi swoje do�wiadczenia z ni� zwi�zane. Z mojej wiedzy wynika, �e APFjest obecnie stosowana w takich bran�ach, jak bankowo��, ubezpieczenia,produkcja filmowa, handel detaliczny, badania farmaceutyczne, dystrybucja,us�ugi profesjonalne, zarz�dzanie �a�cuchem dostaw czy logistyka. Serdeczniedzi�kuj� wszystkim, którzy zaufali APF.




ROZDZIA 22Czym jestzarz�dzanie projektami?

Projektowanie, adaptacja i realizacja modeli cykli zarz�dzania projektami opieraj� si�na zmiennej charakterystyce projektu i stanowi� fundament skutecznego zarz�dzaniaprojektami.

Nie narzucaj takich procesów i procedur, które b�d� t�amsi� kreatywno�� ca�ego zespo�ui jego poszczególnych cz�onków! Powiniene� raczej tworzy� atmosfer� sprzyjaj�c�kreatywnym zachowaniom.

— Robert K. Wysocki, Ph.D., prezes, EII Publications

Czego dowiesz si� z tego rozdziau?

Po przeczytaniu rozdziau b�dziesz potrafi:

� Analizowa� i stosowa� robocz� definicj� zarz�dzania projektami.

� Stosowa� definicj� wymaga� nawi�zuj�c� do warto�ci biznesowej.

� Definiowa� ogólny obraz projektu na podstawie stopnia jasno�ci celu i rozwi�zania.

� Analizowa� i stosowa� cztery �wiartki ogólnego obrazu projektu.

� Rozpoznawa� cechy charakterystyczne tradycyjnego zarz�dzania projektami (TPM),zwinnego zarz�dzania projektami (APM), ekstremalnego zarz�dzania projektami(xPM) oraz zarz�dzania projektami emertxe (MPx).

� Rozpoznawa� oddziaywanie zo�ono�ci i niepewno�ci na ogólny obraz projektu.

� Rozpoznawa� podobie�stwa i ró�nice mi�dzy liniowym, stopniowym, iteracyjnym,adaptacyjnym i ekstremalnym modelem PMLC.

Podejrzewam, �e wielu osobom niniejszy rozdzia� otworzy oczy na to, jak roz-leg�y i g��boki potrafi by� �wiat zarz�dzania projektami. Nie przestaje zadzi-wia� mnie fakt, �e po czterdziestu latach praktyki w zarz�dzaniu projektaminieustannie napotykam nowe wyzwania i ci�gle ucz� si� czego� nowego na




68 Rozdzia 2.

temat tej fantastycznej dyscypliny. Powiniene� wiedzie�, �e zarz�dzanie pro-jektami nie polega wy��cznie na rutynowym wype�nianiu druczków i sk�ada-niu sprawozda�. To �wiat pe�en wyzwa�, w którym b�dziesz musia� wykaza�si� kompetencjami w zakresie skutecznego przywództwa, b�dziesz musia�w pe�ni wykorzystywa� swoj� kreatywno��, a tak�e nieustannie wykazywa� si�odwag�. To �wiat, w którym ka�dego dnia b�dziesz stawa� w obliczu nowych,nieznanych Ci sytuacji, w zwi�zku z którymi b�dziesz musia� g��biej si�gn��do przybornika z narz�dziami i wybra� z niego te, które pozwol� Ci opracowa�skuteczne rozwi�zanie bie��cego problemu.

Dla osób praktykuj�cych zarz�dzanie projektami z pewno�ci� nie jest �adn�tajemnic�, �e dziedzina ta si� zmieni�a i ca�y czas si� zmienia. Zmiany te stawiaj�nas w obliczu permanentnego wyzwania zwi�zanego z ocen� warunków pro-jektu i odpowiednim dopasowaniem stosowanej metodyki zarz�dzania nim.�yjemy w �wiecie, w którym uwarunkowania projektu i jego otoczenie pod-legaj� nieustannym zmianom — to w�a�nie te zmiany powinny by� dla Ciebiewyznacznikiem tego, jakie narz�dzia, schematy i procesy oka�� si� w danej sytu-acji najskuteczniejsze. Przyjrzyj si� uwa�nie tym uwarunkowaniom, a z pewno-�ci� zrozumiesz, jak trudne mo�e si� okaza� skuteczne zarz�dzanie projektem.

Nie jeste� ju� w Kansas! Dziedzina zarz�dzania projektami przesz�a w nowystan, który — w momencie pisania tej ksi��ki — nie uformowa� si� jeszczew swej sta�ej postaci. Prawd� powiedziawszy, praktyka zarz�dzania projektamimo�e nigdy nie osi�gn�� sta�ej, niezmiennej formy. wiat biznesu podlega nie-ustannym fluktuacjom i nie nale�y liczy� na to, �e kiedykolwiek si� to zmieni.Realia biznesowe znajduj� bezpo�rednie prze�o�enie na to, w jaki sposóbmusisz zarz�dza� projektami. Stosowane przez Ciebie podej�cia b�d� zatemrównie� podlega� nieustannym zmianom. Co to oznacza dla pocz�tkuj�cegomened�era projektu? G�owa do góry: sprawy nie maj� si� tak le, jak mog�obysi� wydawa�. W cz��ci drugiej niniejszej ksi��ki dok�adnie nakre�l� drog�,któr� powiniene� pod��a�. Je�eli przyswoisz sobie wiedz�, któr� przekazuj�w rozdzia�ach sk�adaj�cych si� na cz�� pierwsz�, b�dziesz dysponowa� pot��-nym przybornikiem narz�dzi oraz b�dziesz potrafi� stosowa� trwa�� strategi�skutecznego zarz�dzania projektami.

Wyruszmy zatem w podró�, na ko�cu której b�dziesz móg� si� nazwa� efek-tywnym mened�erem projektów.

Podstawy zarz�dzania projektami

Instytut Zarz�dzania Projektami (PMI) przedstawia nast�puj�c� formaln� defi-nicj� zarz�dzania projektami: „Stosowanie wiedzy, umiej�tno�ci, narz�dzi i tech-nik prognozowania dzia�a� pozwalaj�cych zrealizowa� za�o�enia projektu”1.

1 Project Management Institute, A Guide to the Project Management Body of Knowledge, 4th Edition,

Project Management Institute, Newtown Square 2008.




Czym jest zarz�dzanie projektami? 69

Powy�sza definicja mo�e by� oczywi�cie interpretowana na wiele ró�nychsposobów, nie uwa�am jednak, aby by�o to jej wad� — osobi�cie lubi� formu-�owa� sprawy prosto i intuicyjnie, a dok�adnie tak post�piono w PMI. Napotrzeby niniejszej ksi��ki postanowi�em nieco t� definicj� rozbudowa� i stwo-rzy� definicj� robocz�, któr� przedstawi� ju� niebawem.

UwagaZarz�dzanie projektami to zestaw narz�dzi, schematów i procesów zapro-jektowanych z my�l� o poszukiwaniu odpowiedzi na sze�� nast�puj�cychpyta�:

� Jaki problem biznesowy ma rozwi�za� ten projekt?

� Co b�dzie trzeba zrobi�?

� Co zostanie zrobione?

� Jak to zostanie zrobione?

� Sk�d b�dzie wiadomo, �e to zosta�o zrobione?

� Na ile skutecznie zosta�o to zrobione?

Przyjrzyjmy si� pokrótce odpowiedziom na te pytania.

Jaki problem biznesowy ma rozwi�za� ten projekt?Pod poj�ciem problemu nale�y tu rozumie� konkretne trudno�ci, które nale�ypokona�, albo okazj� biznesow�, któr� warto wykorzysta�. Je�eli mowa o pro-blemie w rozumieniu trudno�ci, jego rozwi�zanie mo�e by� do�� dobrze znane,w zwi�zku z czym jego wdro�enie nie powinno przysparza� k�opotów. Je�elinatomiast rozwi�zanie problemu nie jest do ko�ca znane, zarz�dzanie pro-jektem musi nabra� charakteru iteratywnego gromadzenia nowej wiedzy i stop-niowego odkrywania tego rozwi�zania. Tego rodzaju projekty wi�� si� oczy-wi�cie z wi�kszym ryzykiem, co jest spowodowane brakiem precyzyjnejdefinicji rezultatów. Co wi�cej, mimo najlepszych ch�ci zespo�u projektowegoi klienta rezultat mo�e nigdy nie zosta� wypracowany.

Powiniene� pami�ta�, �e zarz�dzany przez Ciebie projekt najprawdopodob-niej konkuruje o zasoby z innymi projektami, które s� zwi�zane z tym samymproblemem biznesowym, cho� podchodz� do niego od zupe�nie innej strony.Twój projekt mo�e odnosi� si� na przyk�ad do jednego aspektu problemu,a inny projekt zajmowa� si� jak�� inn� jego cz��ci�. Je�eli taka sytuacja mamiejsce, powiniene� o niej wiedzie�, poniewa� czasami integracja dwóch tegorodzaju projektów w jeden program mo�e okaza� si� korzystna z punktu widze-nia kosztów i mo�e dawa� wi�ksze szanse na osi�gni�cie zamierzonego celu.W najgorszym razie móg�by� spojrze� na problem z ró�nych punktów widze-nia. Wypracowanie tego typu rozwi�zania lub wykorzystanie potencjalnychkorzy�ci tego typu sytuacji mo�e si� okaza� dla najwy�szego kierownictwafirmy równie istotne jak poszczególne projekty.




70 Rozdzia 2.

Co b�dzie trzeba zrobi�?Odpowied na to pytanie jest do�� oczywista: rozwi�za� problem, czyli usun��trudno�ci lub wykorzysta� nadarzaj�c� si� okazj�. Wszystko �adnie i pi�knie,problem jednak w tym, �e rozwi�zanie problemu mo�e okaza� si� niewyko-nalne ze wzgl�du na uwarunkowania biznesowe, w których projekt b�dzierealizowany. Nawet w tych rzadkich przypadkach, w których rozwi�zanie pro-blemu jest znane, mo�esz nie dysponowa� ludmi odpowiednio przygoto-wanymi do realizacji projektu, a nawet je�li b�dziesz mia� takich ludzi, mog�si� oni okaza� niedost�pni w danym momencie. W sytuacji, w której rozwi�-zanie jest przynajmniej cz��ciowo nieznane, mo�e Ci si� nie uda� okre�li� godo ko�ca. Tak czy owak, musisz udokumentowa� dzia�ania niezb�dne w celurealizacji projektu. Je�eli rozwi�zanie problemu jest znane, przygotowanieodpowiedniego dokumentu nie powinno nastr�cza� trudno�ci, je�eli jednakrozwi�zanie jest cho�by cz��ciowo nieznane, dokument ten b�dzie raczejpowstawa� stopniowo — nie b�dziesz dysponowa� wystarczaj�c� wiedz�, abystworzy� go na samym pocz�tku prac.

Co zostanie zrobione?Odpowied na to pytanie zostanie sformu�owana w postaci deklaracji celuogólnego i celów kierunkowych. By� mo�e Ty sam lub inni zaproponujeciecz��ciowe rozwi�zania problemu lub sposoby na wykorzystanie nadarzaj�cejsi� okazji biznesowej. Tak czy owak, Twoje zamiary zwi�zane z realizacj� pro-jektu zostan� zwerbalizowane w deklaracji ogólnej projektu (POS, od ang.project overview statement).

Jak to zostanie zrobione?Odpowied na to pytanie b�dzie wyznacznikiem podej�cia do realizacji pro-jektu, a jednocze�nie b�dzie szczegó�owym planem osi�gni�cia celu ogólnegoi celów kierunkowych wskazanych w POS. Przewidywane podej�cie do reali-zacji projektu mo�e zosta� w pe�ni udokumentowane na samym pocz�tku pracalbo mo�e zosta� opisane iteratywnie, odpowiedni dokument musi jednakpowsta�.

Sk�d b�dzie wiadomo, �e to zosta�o zrobione?Opracowane przez Ciebie rozwi�zanie problemu lub sposób na wykorzystanieokazji biznesowej b�d� stanowi� okre�lon� warto�� biznesow� dla organizacji.To w�a�nie tutaj kryje si� Twoje kryterium sukcesu. Warto�� ta b�dzie pod-staw� do wydania decyzji w kwestii tego, czy Twój projekt w ogóle b�dzie reali-zowany. Kryteria sukcesu mog� przybra� zatem posta� wzrostu przychodów,ni�szych kosztów lub lepszej jako�ci us�ug. Te trzy kategorie warto�ci bizne-





sowej okre�la si� czasem skrótem IRACIS (od ang. increased revenue, avoided costs

or improved services). Bez wzgl�du na to, o jakich kryteriach sukcesu mówimy,koniecznie musz� one zosta� wyra�one w formie ilo�ciowej, aby potem nieby�o w�tpliwo�ci co do tego, czy uda�o si� osi�gn�� spodziewane efekty biz-nesowe. W ramach jednego z elementów audytu powdro�eniowego b�dzieszdokonywa� porównania faktycznie wypracowanej warto�ci biznesowej z sza-cowan� warto�ci� biznesow� zadeklarowan� w dokumentacji projektu, którazadecydowa�a o tym, �e projekt w ogóle ruszy�.

Na ile skutecznie zosta�o to zrobione?Odpowied na to pytanie mo�na ustali�, poszukuj�c odpowiedzi na czteryinne pytania:

W jak du�ym stopniu uzyskane rezultaty pokry�y si� z zadeklarowa-nymi kryteriami sukcesu? Kierownictwo firmy uda�o si� przekona� dorealizacji projektu na podstawie konkretnej warto�ci biznesowej, któr�mia�a otrzyma� organizacja, gdyby projekt zako�czy� si� sukcesem. Czyuda�o si� osi�gn�� te rezultaty? W jakim stopniu si� to uda�o?Jak poradzi� sobie zespó� projektowy? Zespó� projektowy dzia�a� zgod-nie z jakim� modelem cyklu zarz�dzania projektem (PMLC, od ang.project management life cycle). Nale�y dokona� jakiego� rodzaju oceny sku-teczno�ci zespo�u w realizacji przyj�tego modelu.Na ile skuteczna okaza�a si� wybrana metodyka zarz�dzania projek-tem? Oprócz robienia wszystkiego w�a�ciwie, zespó� powinien podej-mowa� równie� w�a�ciwe dzia�ania. Z pewno�ci� mo�na by�o zastosowa�kilka ró�nych rozwi�za�, wi�c zespó� powinien by� zdecydowa� si� napodej�cie najlepiej dopasowane do potrzeb projektu.Jakie uda�o si� wyci�gn�� wnioski, które mo�na by wykorzysta� w pracynad przysz�ymi projektami? Odpowied na to pytanie jest udzielanaw toku wykonywania audytu powdro�eniowego.

Odpowiedzi na sze�� powy�szych pyta� sprowadzaj� dziedzin� zarz�dzaniaprojektami do uporz�dkowanego zdrowego rozs�dku. W moim przekonaniu„uporz�dkowanie” oznacza tutaj, �e proces lub procesy s� nieustannie mody-fikowane pod k�tem zmieniaj�cych si� potrzeb projektu. „Zdrowy rozs�dek”oznacza natomiast, �e proces zarz�dzania projektem nie wymaga podejmo-wania dzia�a�, które nie generuj� dodatkowej warto�ci. Gdyby realizowanyprojekt nie by� w gruncie rzeczy przejawem uporz�dkowanego zdrowego roz-s�dku, nale�a�oby zada� sobie pytanie, dlaczego jest w ogóle realizowany.Odpowiedzi na sze�� powy�szych pyta� s� zatem do�� dobrym wyznacznikiemtego, czy obrane przez Ciebie podej�cie do zarz�dzania danym projektemjest w�a�ciwe. Pami�taj�c o wszystkich powy�szych uwagach, mo�emy sformu-�owa� nast�puj�c� robocz� definicj� zarz�dzania projektami:




72 Rozdzia 2.

Definicja: Zarz�dzanie projektamiZarz�dzanie projektami to uporz�dkowane i zdroworozs�dkowe podej�cie,które wykorzystuje odpowiednie zaanga�owanie klienta w celu dostar-czenia oczekiwanych przez niego rezultatów, odpowiadaj�ce oczekiwanejdodatkowej warto�ci biznesowej.

Powy�sza definicja wyranie odbiega od wszystkich innych, z którymi mog�e�spotka� si� do tej pory. Po pierwsze, jest to jedyna znana mi definicja, którawyranie wspomina o warto�ci biznesowej. Warto�� biznesowa nale�y do zakresuodpowiedzialno�ci klienta, poniewa� to on formu�uje wymagania projektu.Mened�er projektu jest natomiast odpowiedzialny za spe�nienie tych wyma-ga�. Spe�nienie wymaga� jest tu zatem przyczyn�, a dodatkowa warto�� biz-nesowa jest skutkiem. Wszystko sprowadza si� wi�c do sensownego zaanga�o-wania klienta w realizacj� projektu. Mo�na zatem powiedzie�, �e w pewnymsensie klient wchodzi w rol� kolejnego cz�onka zespo�u projektowego, cho�cz�sto jest równie� wspó�zarz�dzaj�cym takim projektem. Temat ten rozwin�w dalszych fragmentach tej ksi��ki.

Po drugie, cho� równie wa�ne, kluczowym elementem mojej definicji jest zdro-worozs�dkowo�� zarz�dzania projektem, która ma wyra�a� to, �e skutecznezarz�dzanie nie mo�e sprowadza� si� do stosowania jednego, uniwersalnegopodej�cia. Skoro mamy tu do czynienia z podej�ciem zdroworozs�dkowym,to musi ono by� nieustannie dopasowywane do zmieniaj�cych si� uwarunko-wa� projektu. Na kartach tej ksi��ki postaram si� sformu�owa� zasady efek-tywnego zarz�dzania projektami. Definicje modeli PMLC, przedstawionew podrozdziale zatytu�owanym „Modele cyklu zarz�dzania projektami —wprowadzenie”, stanowi� punkt wyj�cia do Twojej podró�y, po uko�czeniuktórej b�dziesz kompetentnym mened�erem projektów. Dzi�ki lekturze niniej-szej ksi��ki dowiesz si�, �e kompetentny i efektywny mened�er projektu jestjednocze�nie liderem, który musi wykazywa� si� kreatywno�ci�, elastyczno�ci�i odwag�. Wymieni� tu wszystkie sk�adniki, których b�dziesz móg� u�ywa�do formu�owania w�asnych przepisów na skuteczne zarz�dzanie projektami.Ty jeste� szefem kuchni i to Ty tu decydujesz.

Po trzecie, b�dziesz musia� dok�adnie poj�� koncepcj� wymaga�. Wymaganiaoraz zwi�zana z nimi dokumentacja stanowi� wyznacznik charakterystykiprojektu i b�d� dla Ciebie zbiorem wskazówek, które pomog� Ci dobra�i zaadaptowa� najlepsz� metod� zarz�dzania danym projektem. Postanowi-�em zastosowa� w tej kwestii raczej niekonwencjonalne podej�cie, opieraj�cesi� na mojej autorskiej definicji wymaga� projektu.

Czym tak naprawd� s� wymagania projektu?

Wymagania okre�laj�, co powinny oferowa� dany produkt lub us�uga, abyzaspokaja� potrzeby klienta i generowa� oczekiwan� warto�� biznesow�.Bardziej formalna definicja zosta�a sformu�owana przez cz�onków Interna-





tional Institute of Business Analysis (IIBA) w publikacji „Guide to theBusiness Analysis Body of Knowledge”:

„Wymaganiem jest: 1. Warunek lub funkcjonalno�� potrzebne interesariuszowi do rozwi�zaniajakiego� problemu lub osi�gni�cia jakiego� celu.

2. Warunek lub funkcjonalno��, które musz� by� spe�nione lub w któremusi by� wyposa�one rozwi�zanie lub element rozwi�zania, aby zosta�yspe�nione wymogi umowy, normy, specyfikacji lub innego formalnieobowi�zuj�cego dokumentu.Udokumentowana posta� warunku lub funkcjonalno�ci w rozumieniupunktu (1) lub (2)”.

Nie mam zamiaru kwestionowa� s�uszno�ci tej definicji. Zak�adam, �e spe�-nia ona swój cel. Na potrzeby naszych rozwa�a� i zastosowa� praktycznychchcia�bym jednak zaproponowa� troch� inny punkt widzenia na t� kwesti�.Moim zdaniem realizujemy z�o�ony projekt, maj�cy na celu rozwi�zanie klu-czowego, dotychczas nierozwi�zanego problemu lub wykorzystanie nadarza-j�cej si� okazji biznesowej. Oba te rezultaty maj� dwa elementy wspólne:� Potrzeb� wygenerowania warto�ci biznesowej — im wi�kszej, tym lepiej.� Z�o�ono�� i niepewno�� — wszystkie proste projekty zosta�y ju�

wykonane.

Generowanie warto�ci biznesowej jest tak naprawd� jedynym wyznacznikiemsukcesu projektu. Od dawna jestem zdania, �e kryterium sukcesu realizacjiprojektu, rozumiane jako uzyskanie stanu okre�lonego w specyfikacji wewskazanym czasie i w ramach wskazanych ogranicze�, jest chybione. Takieuj�cie w ogóle nie uwzgl�dnia ani pierwiastka biznesowego, ani klienta, anisatysfakcji odczuwanej przez cz�onków organizacji. W�a�nie dlatego ja stawiamna kryterium generowania warto�ci biznesowej. Czy� to nie oczekiwana war-to�� biznesowa zadecydowa�a o tym, �e projekt w ogóle doczeka� si� realiza-cji? Istniej� oczywi�cie pewne wyj�tki od tej regu�y, na przyk�ad projekty,których realizacja jest wymagana i obowi�zkowa bez wzgl�du na to, czy gene-ruj� jak�� warto�� biznesow�.

Definicja: WymaganiaWymagania okre�laj� oczekiwany stan docelowy, którego skuteczna inte-gracja z rozwi�zaniem pozwala uzyska� konkretn�, wymiern� i dodatkow�warto�� biznesow� dla organizacji.

Pod poj�ciem zestawu wymaga� nale�y rozumie� zestaw koniecznyi jednocze�nie wystarczaj�cy, aby uda�o si� wygenerowa� oczekiwan� war-to�� biznesow�.

Konieczno�� i wystarczalno�� wymaga� oznacza, �e w celu osi�gni�cia suk-cesu trzeba spe�ni� wszystkie wymagania oraz �e �adne z nich nie jest zb�dne.Jest to o tyle wa�ne, �e realizacja projektu zosta�a zatwierdzona na podstawie




74 Rozdzia 2.

oczekiwanej warto�ci biznesowej, wyznaczonej przez pryzmat kryteriów suk-cesu. Po��czenie wymaga� i kryteriów sukcesu pozwala uzyska� punkt wyj�cianie tylko do nadawania priorytetów wymaganiom w kontek�cie ich wk�aduw generowanie warto�ci biznesowej, lecz równie� do nadawania priorytetówfunkcjom, podfunkcjom, procesom, dzia�aniom i cechom, które sk�adaj� si�na ostateczne wymagania.

Powy�sza definicja wymaga� jest wyranie inna od definicji sformu�owanejprzez cz�onków IIBA, jednak dzi�ki swojej prostocie i wyj�tkowo�ci rzuca zde-cydowanie wi�cej �wiat�a na zale�no�ci ��cz�ce wymagania oraz sam projekt.Nie mam �adnych konkretnych zastrze�e� do definicji IIBA — po prostuuwa�am, �e definicja robocza, nawi�zuj�ca do warto�ci biznesowej, jest lepszymwyborem. Dlatego te� na kartach tej ksi��ki b�d� si� pos�ugiwa� definicj� mojegoautorstwa.

Wymagania b�d� czynnikami przyczynowymi, determinuj�cymi osi�gni�ciekryteriów sukcesu okre�lonych w POS. Ka�de wymaganie musi by� bezpo�red-nio zwi�zane ze statutem projektu. Takie uj�cie powoduje, �e na pocz�tkurealizacji projektu wymaga� jest stosunkowo niewiele (od o�miu do dwunastu).Dla porównania zaznaczmy, �e zgodnie z definicj� IIBA na pocz�tku pracnad projektem mo�na wyznacza� setki, a nawet tysi�ce wymaga�, których natak wczesnym etapie prac po prostu nie da si� w pe�ni uwzgl�dni�. Umys� cz�o-wieka najzwyczajniej w �wiecie nie jest w stanie obj�� i przyswoi� tak du�ejliczby wymaga�. Wydaje si� wysoce nieprawdopodobne, aby przy takim uj�ciuwymaga� mo�na by�o kiedykolwiek uzna�, �e sformu�owana lista tych wyma-ga� jest kompletna. Licz�c si� z tym, �e na etapie prac nad realizacj� projektumo�e dochodzi� do odkrycia i sformu�owania nowych wymaga�, mo�na uzna�list� wymaga� za kompletn� w rozumieniu mojej definicji ju� na pocz�tkurealizacji projektu. Warto tu jednak podkre�li�, �e na tym etapie nikt nie majeszcze pe�nej wiedzy na temat dekompozycji tych wymaga�. Moja definicjajest bardziej zorientowana na warto�� biznesow� ni� definicja autorstwa IIBA.Wiedza pozyskana w trakcie kolejnych cykli realizacji projektu oraz wyci�gni�tez niej wnioski pozwalaj� dokona� dekompozycji wymaga� na kolejnychpoziomach wyznaczanych przez funkcje, podfunkcje, procesy, dzia�ania i cechy.Pierwszy poziom dekompozycji to poziom funkcjonalny, który mo�na uto�-samia� z wymaganiami w uj�ciu definicji sformu�owanej przez IIBA. Ozna-cza to, �e na samym pocz�tku realizacji projektu mo�na zdefiniowa� jegowszystkie wymagania, nie mo�na natomiast okre�li� ich szczegó�ów na pozio-mie funkcji, podfunkcji, procesów, dzia�a� i cech. Te szczegó�owe informacjes� pozyskiwane wraz z realizacj� kolejnych cykli sk�adaj�cych si� na projekt.

Moim zdaniem moja definicja wymaga� powinna by� oceniana wy�ej ni�definicja sformu�owana przez IIBA, poniewa� bezpo�rednio ��czy ona wyma-gania z kryteriami sukcesu projektu, czego o definicji IIBA powiedzie� niemo�na. Takie uj�cie umo�liwia nadawanie wymaganiom priorytetów (znówwyrana ró�nica w stosunku do wymaga� w rozumieniu IIBA). O formu�owa-niu, gromadzeniu, dekompozycji i kompletno�ci wymaga� zdecydowanie wi�-





cej b�d� mia� do powiedzenia w rozdziale 4. oraz w cz��ci drugiej, sk�d dowieszsi�, w jaki sposób kompletno�� wymaga� przek�ada si� na wybór najlepiejdopasowanego modelu PMLC.

Ostrze�enie�czenie wymaga� z wymiern� warto�ci� biznesow� mo�e si� okaza�trudne, poniewa� do uzyskania tej warto�ci potrzeba ca�ego zestawukoniecznych i wystarczaj�cych wymaga�. Jest to zbiór wzajemnie zale�nychod siebie wymaga�, w zwi�zku z czym przypisanie konkretnej warto�cibiznesowej jednemu wymaganiu mo�e okaza� si� niemo�liwe. W takiejsytuacji poprzestaje si� na szeregowaniu wymaga�.

Prawdopodobnie zastanawiasz si�, czy moja definicja jest lepsza od definicjizaproponowanej przez IIBA oraz czy stosowanie jej w Twojej organizacji masens z biznesowego punktu widzenia. Poni�ej przedstawiam sze�� argumentów,które chcia�bym, aby� przemy�la� i omówi� z cz�onkami swojego zespo�uprojektowego.� Moja definicja zmniejsza liczb� wymaga� z kilkudziesi�ciu do sze�ciu

lub o�miu. My�l� o wymaganiach na wy�szym poziomie ni� wi�kszo��moich kolegów po fachu. Zastosowanie definicji zaproponowanej przezIIBA powoduje, �e na pocz�tku prac nad projektem sporz�dzenie kon-kretnej listy wymaga� jest raczej niemo�liwe. Mo�na je pozna� dopierona etapie realizacji projektu. W�a�nie takie podej�cie przyjmuj� w ramachmojej adaptacyjnej struktury projektu (APF, od ang. adaptive project fra-

mework). Dzi�ki mojej definicji wymaga� wy�szego rz�du istnieje mo�li-wo�� sformu�owania kompletnej listy wymaga� ju� na samym pocz�tkuprac nad projektem. Z moich w�asnych do�wiadcze� wynika, �e defini-cja wy�szego rz�du daje klientowi i cz�onkom zespo�u projektowegobardziej holistyczny ogl�d projektu i umo�liwia podejmowanie znacz-nie lepszych decyzji biznesowych, maj�cych wp�yw na rozwi�zanie.

� W wi�kszo�ci przypadków wskazanie pe�nej listy wymaga� jest mo�-liwe wy��cznie w ramach procesu iteracyjnego. Zastosowanie mojejdefinicji wy�szego rz�du pozwala sformu�owa� kompletn� list� wymaga�.Trudno�ci pojawiaj� si� dopiero na etapie identyfikacji cz��ci sk�ado-wych poszczególnych wymaga� — mam tu na my�li tworzenie strukturypodzia�u wymaga� (RBS, od ang. requirements breakdown structure):Wymagania

FunkcjePodfunkcje

ProcesyDzia�ania

CechyTe szczegó�owe informacje mo�na pozyska� i udokumentowa� wy��cz-nie w trakcie realizacji projektu. Aby wymagania mog�y sta� si� elementem




76 Rozdzia 2.

rozwi�zania, ich cz��ci sk�adowe musz� albo w sposób bezpo�redni przy-czynia� si� do generowania warto�ci biznesowej, albo wspiera� elementysk�adowe wy�szego rz�du, które bezpo�rednio przyczyniaj� si� do gene-rowania tej warto�ci. W ten sposób eliminuje si� wi�kszo�� zb�dnychdodatków do rozwi�zania, które nie maj� �adnej oczywistej warto�cibiznesowej. RBS zostanie omówiona bardziej szczegó�owo w rozdziale 4.,natomiast w rozdziale 5. skupi� si� na strukturze podzia�u pracy (WBS,od ang. work breakdown structure). Ujmuj�c rzecz najpro�ciej, RBS doku-mentuje wszystkie dzia�ania, które nale�y podj�� w celu zaoferowaniakompleksowego rozwi�zania problemu, natomiast WBS okre�la, jak tozostanie zrobione. Dzi�ki mojej definicji wymaga� mo�na zatem wyzna-czy� bliskie powi�zania mi�dzy prac� nad realizacj� projektu a genero-waniem warto�ci biznesowej.

� Moja definicja upraszcza proces poszukiwania rozwi�zania oferuj�cegowystarczaj�c� warto�� biznesow�. Je�eli jeste� emocjonalnie przywi�-zany do jakiego� elementu rozwi�zania, ale nie potrafisz wykaza�, �eprzyczynia si� on do generowania warto�ci biznesowej, nie oczekuj, �etrafi on do ostatecznej wersji rozwi�zania. W ten sposób eliminuje si�zb�dne nak�ady czasu, pieni�dzy i innych zasobów na co�, co nie przy-czynia si� do generowania warto�ci biznesowej przez rozwi�zanie.

� Moja definicja upraszcza wybór alternatywnych kierunków rozwi�-zania. Warto�� biznesowa jest najlepszym czynnikiem decyduj�cym,kiedy trzeba dokona� wyboru spomi�dzy konkuruj�cych ze sob� alter-natywnych opcji. Osobi�cie pracowa�em przy projektach, w którychpewien element rozwi�zania pocz�tkowo wydawa� si� nie mie� wp�ywuna generowan� warto�� biznesow�, nie zosta� wi�c uwzgl�dniony w pro-jekcie, jednak w trakcie jednej z kolejnych iteracji zespó� projektowy lubklient uznawali, �e komponent ten jednak jest warto�ciowy i w zwi�zkuz tym nale�y go w��czy� do rozwi�zania. Na etapie formu�owania roz-wi�zania powiniene� kierowa� si� zasad�, w my�l której w razie w�tpliwo-�ci danego komponentu rozwi�zania si� nie uwzgl�dnia — je�li oka�esi� on mie� jednak wp�yw na generowan� warto�� biznesow�, zostanieto dostrze�one na etapie realizacji projektu.

� Moja definicja pozwala lepiej gospodarowa� zasobami wyst�puj�cymiw ograniczonej ilo�ci (pieni�dzmi, czasem, ludmi). Korzystaj�c z defi-nicji wymaga� wy�szego rz�du, uzyskujesz zwrot z inwestycji w ka�dyelement opracowanego rozwi�zania. Z�o�one projekty s� obarczone nie-pewno�ci� i ryzykiem, wi�c �wiadomo�� wydajnego i optymalnego wyko-rzystania dost�pnych zasobów jest krzepi�ca zarówno dla klienta, jaki dla Twojego kierownictwa.

� Moja definicja ma charakter roboczy. Jest ona bezpo�rednio powi�-zana z oczekiwan� warto�ci� biznesow�, która ma by� rezultatem udanejrealizacji projektu. Warto�� biznesowa mo�e sta� si� równie� podstaw�do nadawania priorytetów poszczególnym wymaganiom, co w przypadkudefinicji IIBA nie jest mo�liwe.





We wszystkich stosowanych przeze mnie narz�dziach, schematach i proce-sach zawsze najwy�ej ceni�em sobie prostot�. W moim odczuciu definicjawymaga� wy�szego rz�du, któr� opracowa�em, spe�nia to kryterium, a pozatym zupe�nie dobrze sprawdza si� w praktyce.

Struktura podzia�u wymaga� okazuje si� kluczowym czynnikiem decyduj�-cym o wyborze najlepiej dopasowanego modelu PMLC. To naprawd� bardzoprosty proces podejmowania decyzji. W ramach procesu tworzenia strukturyRBS Ty i Twój klient b�dziecie mogli dokona� oceny kompletno�ci tej struk-tury oraz pewno�ci, jak� w niej pok�adacie. Je�eli ju� kilkakrotnie realizowa-�e� danego rodzaju projekt, powiniene� by� raczej pewny, �e stworzona przezCiebie struktura jest kompletna. Mo�e to dotyczy� na przyk�ad powtarzaj�-cych si� projektów infrastrukturalnych.

Oprzyj si� pokusie my�lenia, �e struktura RBS pozostaje niezmienna. Pami�taj,�e �wiat nie staje w miejscu tylko dlatego, �e zarz�dzasz projektem. Podczasprac nad projektem nie da si� unikn�� zmian. Zmiana mo�e mie� charakterwewn�trzny dla organizacji i wywodzi� si� od klienta lub nawet od samegozespo�u projektowego. Zmiany s� nieprzewidywalne, no mo�e poza tym, �ez pewno�ci� b�d� mia�y miejsce i �e b�dziesz musia� na nie w�a�ciwie zareago-wa�. Zmiana mo�e pochodzi� równie� ze róde� zewn�trznych, takich jak rynek,konkurencja albo jaki� technologiczny prze�om. Zmiany mog� nie mie� �ad-nego wp�ywu na Twój projekt, mog� mie� wp�yw minimalny albo rodzi� dlaniego powa�ne skutki. Najwa�niejsze jest to, aby� zawsze umia� odpowiedniona nie zareagowa�.

Tradycyjne praktyki zwi�zane z zarz�dzaniem projektami zak�adaj�, �e wyma-gania klienta zostan� jasno i precyzyjnie zdefiniowane jeszcze przed rozpo-cz�ciem fazy planowania. Wi�kszo�� wspó�czesnych teoretyków tego zagad-nienia jest zdania, �e pe�ne i jasne zdefiniowanie wymaga� na pocz�tku pracnad projektem jest po prostu niemo�liwe. Bez wzgl�du na to, czy si� z tympogl�dem zgadzasz, czy nie, warunek ten jest uwzgl�dniany w wi�kszo�ci wspó�-cze�nie realizowanych projektów i s� po temu zupe�nie dobre powody, naprzyk�ad:� zmieniaj�ce si� warunki rynkowe,� dzia�ania podejmowane przez konkurentów,� post�p technologiczny,� nowe informacje przedstawiane przez klienta,� zmiany priorytetów.

W�a�nie z tych powodów postanowi�em zdefiniowa� wymagania w sposób,który przedstawi�em ju� wcze�niej. W cz��ci drugiej wspólnie przeanalizujemyte sytuacje i zastanowimy si� równie� nad post�powaniem w obliczu zmianzakresu projektu oraz nad ich oddzia�ywaniem na procesy zwi�zane z zarz�dza-niem projektami. Przy okazji poznasz alternatywne podej�cia do zarz�dzaniaprojektami, pozwalaj�ce poradzi� sobie w tych trudnych sytuacjach i jedno-cze�nie nie straci� koncentracji na kliencie przez ca�y cykl realizacji projektu.




78 Rozdzia 2.

Rynek wygl�da dzi� zupe�nie inaczej ni� trzydzie�ci lat temu. Komputery PCmaj� w�a�nie oko�o trzydziestu lat, a przecie� mia�y ogromny wp�yw na zmiany,które zasz�y w tym okresie. Media spo�eczno�ciowe to zjawisko zupe�nie nowe,wi�c jeszcze nie wiemy, jakie pozostawi po sobie skutki. G�ównym czynni-kiem decyduj�cym o tych zmianach rynkowych by� post�p technologiczny.Wykorzystanie technologii w celu jak najszybszego dotarcia na rynek jest dzi�strategi� obowi�zkow�. Strategi� obowi�zkow� jest równie� wprowadzaniena rynek najbardziej innowacyjnych produktów i us�ug, zanim zrobi� to kon-kurenci. Kluczowe znaczenie dla ka�dej skutecznej strategii ma tak�e tworze-nie barier wej�cia dla nowych graczy rynkowych. Jedynym katalizatorem tychstrategii jest zarz�dzanie projektami. W jego ramach musz� powsta� metodyprzystosowane do realiów intensywnych zmian, szybko�ci oraz rosn�cej z�o-�ono�ci. Tradycyjne metody nie nad��aj� za tego rodzaju projektami — nicdziwnego, �e ponad 70 procent wszystkich realizowanych projektów ko�czysi� niepowodzeniem. Nale�y po�o�y� temu kres. Mened�erowie projektówpotrzebuj� metod zbudowanych na za�o�eniu, �e zmiany s� nieuchronne —�e nale�y wykorzystywa� wiedz� i nowe informacje pozyskiwane ju� w trakcierealizacji procesu. W parze z tymi metodami musz� i�� wbudowane procesy,które pozwol� zintegrowa� zachodz�ce zmiany z wnioskami p�yn�cymi zezdobywanej na bie��co wiedzy.

Ostrze�enieNigdy nie b�dziesz mia� stuprocentowej pewno�ci, �e struktura RBS jestkompletna. Je�eli masz jakiekolwiek w�tpliwo�ci, dla bezpiecze�stwa przyj-mij za�o�enie, �e czego� w niej jednak brakuje. Pocz�tkowo powiniene�zawsze zak�ada�, �e najlepiej dopasowan� metod� jest tradycyjna metodazarz�dzania projektem. Je�eli na którym� etapie prac dojdziesz do wniosku,�e Twoje pierwotne decyzje by�y b��dne i �e w strukturze RBS zabrak�okilku istotnych elementów rozwi�zania, powiniene� zastanowi� si� nadprzej�ciem na jedn� z metod adaptacyjnych lub iteracyjnych. Je�eli sta-niesz w obliczu projektu, który nie ma nawet zdefiniowanego celu g�ów-nego, odpowiednim wyborem b�dzie metoda ekstremalna. W cz��ci drugiejzdecydowanie bardziej szczegó�owo przedstawi� sposób podejmowaniatych decyzji.

Modele cyklu zarz�dzania projektami— wprowadzenie

Aby móc zaplanowa� czekaj�c� Ci� podró�, potrzebujesz ogólnego obrazuprojektu, który by�by na tyle prosty, aby móg� pozostawa� aktualny bez wzgl�duna zmiany zachodz�ce w otoczeniu biznesowym. B�dzie to Twoja niezmiennamapa drogowa do dalszej analizy i dzia�a�. Specjali�ci ds. zarz�dzania pro-jektami ju� od kilku lat wieszcz�, �e w tej dziedzinie nie ma rozwi�za� uni-wersalnych. Gdyby takowe rozwi�zania istnia�y, �ycie mened�era projektunie by�oby trudne, a niniejsza ksi��ka nie mia�aby nawet stu stron. W rzeczy-





wisto�ci praca mened�era projektu stanowi, niestety (a dla osób lubi�cychprzygody pewnie na szcz��cie), nie lada wyzwanie i wymaga zaanga�owaniape�nego potencja�u kreatywnego. My�lenie pod k�tem „rozwi�za� uniwer-salnych” si� nie sprawdza i chyba nigdy si� nie sprawdza�o. Mam tu oczywi-�cie na my�li fakt, �e mened�er projektu powinien na podstawie jego charak-terystyki dobiera� narz�dzia, schematy i procesy, które s� w danej sytuacjiodpowiednie. Aby pomóc ci w opracowaniu modelu podejmowania decyzjiw kwestii wyboru w�a�ciwego modelu zarz�dzania projektem, na pocz�tekzdefiniuj� pokrótce bardzo ogólny obraz projektu, a nast�pnie przedstawi�strategi� pog��biania tego obrazu w celu doj�cia do konkretnego modelu cykluzarz�dzania projektem (PMLC, od ang. project management life cycle). Dopieropóniej omówi� narz�dzia, schematy i procesy, a tak�e ich zastosowaniew odniesieniu do konkretnych cech charakterystycznych projektu. Powiniene�ju� na samym pocz�tku zrozumie�, �e w zarz�dzaniu projektami nie ma cudow-nych rozwi�za�. Zarz�dzanie projektem nie polega na dzia�aniu zgodnie z usta-lonym przepisem, a raczej na tworzeniu takiego przepisu. Chcia�bym, aby�by� szefem kuchni, a nie zwyk�ym kucharzem. Kucharz potrafi jedynie goto-wa� wed�ug przepisów stworzonych przez inne osoby, podczas gdy szef kuchnisam takie przepisy tworzy. Aby osi�gn�� pu�ap, na którym te� posi�dziesz t�umiej�tno��, b�dziesz musia� ci��ko si� napracowa�.

Definicja: Model cyklu zarz�dzania projektemModel cyklu zarz�dzania projektem (PMLC) to pi�� nast�puj�cych po sobiegrup procesów (definiowanie zakresu, planowanie, wykonanie, monitoro-wanie i kontrola, zamykanie projektu), które realizuje si� po to, aby osi�-gn�� cel ogólny projektu. Wszystkie grupy procesowe musz� mie� miejsceco najmniej jeden raz w ramach cyklu, cho� wszystkie mog� zosta� powtó-rzone dowoln� liczb� razy.

Jasne formu�owanie celu i rozwi�zaniaOsobi�cie jestem zwolennikiem prostych modeli, dlatego te� mój model ogól-nego obrazu projektu zbudowa�em na podstawie dwóch zmiennych: celu i roz-wi�zania. Obie zmienne mog� przybiera� jedn� z dwóch warto�ci: jasne lubniejasne. W ten sposób powstaje macierz z�o�ona z czterech �wiartek, przed-stawiona na rysunku 2.1.

Pierwsza �wiartka modelu to tradycyjne zarz�dzanie projektami (TPM, odang. traditional project management), druga �wiartka to zwinne zarz�dzanie pro-jektem (APM, od ang. agile project management), trzecia �wiartka to ekstremalnezarz�dzanie projektem (xPM, od ang. extreme project management), natomiastczwarta �wiartka to zarz�dzanie projektem emertxe (MPx, od ang. emertxe pro-ject management). Nie potrafi� wyranie rozgraniczy� warto�ci „jasne” i „nieja-sne”, jednak nie ma to wi�kszego znaczenia dla tego modelu. Warto�ci te maj�charakter jako�ciowy, a nie ilo�ciowy. Dany projekt mo�e charakteryzowa� si�




80 Rozdzia 2.

Rysunek 2.1. Cztery �wiartki ogólnego obrazu projektu

ró�nym stopniem jasno�ci, a w zwi�zku z tym z niniejszego modelu powi-niene� wyci�gn�� wniosek, �e przej�cie z jednej �wiartki do drugiej nast�pujew sposób p�ynny.

Przyjmijmy w charakterze przyk�adu, �e celem projektu jest walka ze zwyk�ymkatarem. Czy tak sformu�owany cel jest celem jasnym i kompletnym? Oczy-wi�cie, �e nie. Wszystko rozbija si� o znaczenie s�owa walka, które w tym kon-tek�cie mo�e sugerowa� nast�puj�ce scenariusze:� Przed narodzinami p�ód otrzymuje zastrzyk z lekiem ingeruj�cym w sk�ad

jego DNA, przez co osoba ta nigdy nie zachoruje na katar.� Jednym z elementów diety wszystkich ludzi staje si� dzienna dawka soku

z konkretnego gatunku drzewa, które ro�nie wy��cznie na okre�lonychwysoko�ciach w Himalajach. Sok chroni organizmy ludzi przez zara�e-niem si� katarem.

� Osoba zara�ona katarem przyjmuje du�� dawk� herbaty parzonej z rzad-kiego korzenia rosn�cego wy��cznie w �rodkowych Chinach. W wynikutej kuracji katar zostaje wyleczony w ci�gu dwunastu godzin.

Wszystko sprowadza si� tu zatem do znaczenia s�owa walka. W charakterzeinnego przyk�adu dokonajmy analizy sparafrazowanych s�ów prezydentaJohna F. Kennedy’ego, który w 1961 roku powiedzia�: „Do ko�ca tej dekadypostawimy cz�owieka na Ksi��ycu i bezpiecznie sprowadzimy go z powro-tem”. Czy masz jakiekolwiek w�tpliwo�ci co do jasno�ci i kompletno�ci tegocelu? Czy po zako�czeniu projektu mog� pojawi� si� jakiekolwiek w�tpliwo�cico do tego, czy cel projektu zosta� osi�gni�ty?

Ka�dy projekt, który by� lub kiedykolwiek b�dzie realizowany, kwalifikujesi� do jednej z czterech wskazanych przeze mnie �wiartek. Na ten ogólny obrazprojektu nie oddzia�uj� absolutnie �adne zmiany. Taki obraz projektu pozostajeniezmienny. �wiartka, w której znajduje si� dany projekt, stanowi pierwsz�wskazówk� odno�nie do wyboru najlepiej dopasowanego modelu PMLC,a tak�e odno�nie do dostosowania narz�dzi, schematów i procesów do potrzebtego projektu. Po rozpocz�ciu prac nad projektem jego cel i rozwi�zanie zaczy-naj� si� klarowa�, w zwi�zku z czym mo�e doj�� do przesuni�cia projektu doinnej �wiartki, a to mo�e si� z kolei wi�za� ze zmian� modelu PMLC. Decy-zja o zmianie modelu PMLC w przypadku realizowanego ju� projektu mo�e





rodzi� powa�ne konsekwencje, wi�c trzeba j� bardzo dobrze rozwa�y�. Zmianamodelu PMLC w trakcie trwania projektu generuje okre�lone korzy�ci i koszty,ma te� swoje wady i zalety. Wi�cej informacji na temat podejmowania tegorodzaju decyzji przedstawi� w cz��ci drugiej.

Oprócz jasno�ci i kompletno�ci celu i rozwi�zania, na etapie wyboru najle-piej dopasowanego modelu PMLC, a by� mo�e nawet tak�e w zwi�zku z jegomodyfikacjami, b�dziesz musia� uwzgl�dni� równie� kilka innych czynni-ków. Jednym z takich czynników jest stopie�, w jakim klient zadeklarowa�swoje merytoryczne zaanga�owanie w realizacj� projektu. Je�eli najlepiej dopa-sowany model PMLC wymaga znacznego i merytorycznego zaanga�owaniaklienta (dotyczy to wielu projektów z drugiej i trzeciej �wiartki), lecz Ty spo-dziewasz si�, �e nie mo�esz liczy� na to zaanga�owanie, prawdopodobniepowiniene� zacz�� poszukiwa� modelu, który nie formu�uje tak wysokichwymaga� w tym wzgl�dzie. Alternatywnym rozwi�zaniem tego problemuby�oby wdro�enie programu zach�caj�cego klienta do zaanga�owania si� nawymaganym poziomie. Tego rodzaju sytuacje zdarzaj� si� do�� cz�sto, dlategote� w cz��ci drugiej wyja�niam, jak nale�y sobie z nimi radzi�.

Zarz�dzaniem projektami zacz��em zajmowa� si� w 1963 roku, czyli na kilka latprzed powstaniem Instytutu Zarz�dzania Projektami (PMI). To ju� ponad45 lat praktyki, w trakcie których obserwowa�em ewolucj� i dojrzewanie tejdziedziny. Pocz�tkowo wi�kszo�� projektów opiera�a si� na prostych wykre-sach Gantta, by stopniowo przekszta�ca� si� w projekty realizowane za pomoc�interdyscyplinarnych zestawów narz�dzi, schematów i procesów, dopasowa-nych do potrzeb konkretnej sytuacji. Zarz�dzanie projektami przesta�o by�zaledwie kolejnym narz�dziem w przyborniku mened�era. Dzisiaj zarz�dzanieprojektami to bardziej sposób na �ycie, szczególnie �e wiele firm przekszta�-ci�o si� w co� w rodzaju organizacji projektowych. Oczywi�cie, ci�gle jeszczew niektórych sytuacjach najlepiej sprawdza� si� b�d� tradycyjne rozwi�zania,jednak ju� dzi� mamy do czynienia z ca�ym zestawem zastosowa�, w przy-padku których stare sposoby zupe�nie si� nie sprawdzaj�. Obowi�zuj�cy para-dygmat musi si� zmieni� i si� zmienia. Wemy na przyk�ad zwinne zarz�dza-nie projektami, które oficjalnie pojawi�o si� na scenie w 2001 roku2. Prze�omten zapocz�tkowa� formalne odej�cie od stosowanych wówczas praktyk.Firmy, które nie uwzgl�dni�y tej zmiany w swoim funkcjonowaniu, ryzykuj�utrat� zarz�dzania projektami jako warto�ciowego zasobu strategicznego.Powiedzenie „Zmieniaj si� albo gi�” nigdy nie by�o bardziej aktualne ni� dzisiaj.Ta niewielka zmiana zaproponowana w 2001 roku da�a pocz�tek ca�emu port-felowi nowych metod zarz�dzania projektem. Wspominam jeszcze o nichw dalszej cz��ci tego podrozdzia�u, natomiast szczegó�owo omawiam je w cz��cidrugiej.

2 Martin Fowler, Jim Highsmith, The Agile Manifesto, „Software Development” 9, No. 8, sierpie� 2001,

s. 28 – 32.




82 Rozdzia 2.

Dlaczego potrzebujemy kolejnego sposobu zarz�dzania projektami? Czy� niemamy ju� wystarczaj�co du�o ró�nych mo�liwo�ci? Owszem, opcji do wyborumamy mnóstwo, jednak nadal zdecydowanie zbyt du�o projektów ko�czysi� kl�sk�. W przesz�o�ci wysi�ki mened�erów projektów nie by�y zbyt owocne —mo�na wskaza� wiele powodów. Moim zdaniem sytuacja ta jest cz��ciowospowodowana faktem, �e nie uda�o nam si� jeszcze w pe�ni okre�li�, w jakisposób — na poziomie praktycznym i funkcjonalnym — dostosowywa� wyko-rzystywane metody do wymaga� projektów, którymi przysz�o nam zarz�dza�w dzisiejszych realiach biznesowych. Zbyt wielu mened�erów podejmujepró�ny trud upychania sze�ciennych klocków w okr�g�e otwory tylko dlatego,�e poza sze�ciennymi klockami nie maj� nic innego. Zarz�dzanie projektamimusimy zacz�� traktowa� jak dziedzin� nauki oraz jak sztuk�, poniewa� takijest w�a�nie jego charakter. Oznacza to, �e naszym zadaniem jest na podsta-wie niepodwa�alnych zasad i koncepcji zbudowa� naukowo zdefiniowan�dziedzin� wiedzy. W�a�nie ten cel staram si� osi�gn�� w niniejszym rozdzialeoraz w ca�ej cz��ci drugiej.

UwagaObserwacja: Dziedzina zarz�dzania projektami nieustannie zmienia swoj�form� i nie osi�gn��a jeszcze stanu docelowego. Niewykluczone, �e nigdygo nie osi�gnie.

W moim przekonaniu rozwi�zanie dla trudno�ci napotykanych przez nasw zarz�dzaniu projektami jest oczywiste. Mened�erowie projektu musz� otwo-rzy� si� na podstawowe zasady, na których opiera si� ta dziedzina w kwestiiuwzgl�dniania zmian, unikania marnotrawstwa �rodków finansowych, uni-kania marnotrawstwa czasu i ochrony pozycji rynkowej firmy. Odk�d tylkopami�tam, opowiadam wszem i wobec, �e uniwersalne rozwi�zania si� niesprawdzaj�. Podstaw� definiowania metody zarz�dzania projektem musi by�charakterystyka danego projektu. Koncepcja ta musi na sta�e zakorzeni� si�w Twoim stosunku do ca�ego zarz�dzania projektami. Musisz przestawi� si�na mentalno��, w ramach której zarz�dzanie projektem zaczyna si� od wyborunajlepiej dopasowanego modelu PMLC (na podstawie charakterystyki kon-kretnego projektu). W�a�nie w tym celu opracowuje si� struktur� RBS. Nast�p-nie trzeba si� zastanowi�, jak dany model mo�na zmodyfikowa� w celu jaknajbardziej efektywnego zarz�dzania konkretnym projektem.

Tradycyjne praktyki zwi�zane z zarz�dzaniem projektami zak�adaj�, �e wyma-gania klienta zostan� jasno i precyzyjnie zdefiniowane jeszcze przed rozpo-cz�ciem fazy planowania. Wi�kszo�� wspó�czesnych teoretyków tego zagad-nienia jest zdania, �e pe�ne i jasne zdefiniowanie wymaga� na pocz�tku pracnad projektem jest po prostu niemo�liwe. Bez wzgl�du na to, czy si� z tympogl�dem zgadzasz, czy nie, warunek ten jest uwzgl�dniany w wi�kszo�ciwspó�cze�nie realizowanych projektów i s� zupe�nie dobre powody, �eby takrobi�. W cz��ci drugiej niniejszej ksi��ki omówimy tego rodzaju sytuacje,a tak�e nieuniknione wnioski o zmian� zakresu projektu. Wyja�ni�, jaki maj�





one wp�yw na procesy realizowane w zwi�zku z zarz�dzaniem projektem.Przy okazji poznasz alternatywne metody zarz�dzania projektami, które pozwa-laj� poradzi� sobie w tych trudnych sytuacjach, a jednocze�nie utrzyma� kon-centracj� na kliencie w ca�ym cyklu zarz�dzania projektem.

Jak wspomina�em we wprowadzeniu do niniejszej ksi��ki, stare metody zarz�-dzania projektami zosta�y wyznaczone i sprecyzowane w �wiecie in�ynierów.Ludzie ci stworzyli co�, co ich zdaniem stanowi�o kompletny i precyzyjnyopis �ycze� klienta. Przyj�to za�o�enie, �e zespó� projektowy dok�adnie rozu-mie rozwi�zanie, które ma wdro�y�, oraz �e potrafi szczegó�owo zaplanowa�proces jego wdra�ania. Niestety, za�o�enie to okaza�o si� b��dne i w rezultacieprojekt nie zosta� zrealizowany w ponad 70 procentach. W celu przypodo-bania si� klientowi wprowadzono pewne poprawki i korekty, jednak by�o ju�za póno. Projekt zako�czy� si� klap�. Tak w�a�nie wygl�da�a rzeczywisto��mened�erów projektu do po�owy lat pi��dziesi�tych, kiedy to komputery sta�ysi� osi�galnym komercyjnie zasobem. Prowadzenie firm za pomoc� kompu-terów nagle sta�o si� zupe�nie mo�liwe, zacz��y si� pojawia� takie nazwy stano-wisk, jak programista, analityk programów, analityk systemów czy architektbaz danych (wówczas jeszcze w najbardziej prymitywnej postaci). wiat biz-nesu i �wiat zarz�dzania projektami przesz�y przemian�, od której nie by�oodwrotu.

Zasz�a zmiana realiów, jednak jako� nie dawa�o si� dostrzec �adnych zmianw stosowanych metodach. W oczach in�ynierów ka�dy projekt przypomina�gwód, a oni dzier�yli w r�ku m�otek. Wydawa�o si�, �e wszystko si� kr�ci —przecie� nikt na nic nie narzeka� albo po prostu nie wiedzia�, jak i na co si�skar�y�, kiedy nie wszystko sz�o zgodnie z planem.

Skoczmy teraz w czasie do lat siedemdziesi�tych. Pod nimbem tajemniczo�ciotaczaj�cym komputery kry� si� kolejny problem, który ju� nied�ugo mia�wyp�yn�� na powierzchni� — chodzi�o o to, �e ludzie biznesu nie umieli odró�-nia� potrzeb od zachcianek. Problem ten wzi�� si� z zachwytu nad kompute-rem, który przedstawiano jako cudowne narz�dzie — wystarczy�o nacisn��przycisk, aby reszta zrobi�a si� sama. Prowadzenie dzia�alno�ci biznesowej mia�osta� si� bajecznie proste. Zachcianki zacz��y przes�ania� faktyczne potrzeby.

Od tamtej pory min��o ju� ponad czterdzie�ci lat, a problem ten nadal ist-nieje. Je�eli masz cokolwiek zapami�ta� z tych rozwa�a�, to zapami�taj to, �ezachcianki klienta prawdopodobnie nie pokrywaj� si� z jego potrzebami.Zachcianki kojarzy si� z rozwi�zaniem kreowanym w g�owie klienta, nato-miast potrzeby s� zwi�zane z samym problemem, który pozostaje jeszczeniezdefiniowany. Mened�era projektu, który �lepo zaakceptuje zachciankiklienta i przyst�pi do realizacji projektu, czeka kube� zimnej wody. Bardzocz�sto zdarza si�, �e na etapie opracowywania rozwi�zania klient zaczyna rozu-mie�, �e to, czego potrzebuje, nie pokrywa si� z tym, o co poprosi�. W tensposób dochodzi do przesuni�� terminów, pojawiaj� si� chochliki zakresu, a�wreszcie dochodzi do nieko�cz�cego si� ci�gu zmian i przeróbek.




84 Rozdzia 2.

Rynek wygl�da dzi� zupe�nie inaczej ni� trzydzie�ci lat temu. Komputery PCmaj� w�a�nie oko�o trzydziestu lat, a przecie� mia�y ogromny wp�yw na zmiany,które zasz�y w tym okresie. Media spo�eczno�ciowe to zjawisko zupe�nie nowe,wi�c jeszcze nie wiemy, jakie pozostawi po sobie skutki. G�ównym czynni-kiem decyduj�cym o tych zmianach rynkowych by� post�p technologiczny.Wykorzystanie technologii w celu jak najszybszego dotarcia na rynek jest dzi�strategi� obowi�zkow�. Strategi� obowi�zkow� jest równie� wprowadzaniena rynek najbardziej innowacyjnych produktów i us�ug, zanim zrobi� tokonkurenci. Kluczowe znaczenie dla ka�dej skutecznej strategii ma tak�etworzenie barier wej�cia dla nowych graczy rynkowych. Jedynym katalizatoremtych strategii jest zarz�dzanie projektami. W jego ramach musz� powsta�metody przystosowane do realiów intensywnych zmian, szybko�ci oraz rosn�-cej z�o�ono�ci. Tradycyjne metody nie nad��aj� za tego rodzaju projektami —nic dziwnego, �e ponad 70 procent wszystkich realizowanych projektów ko�-czy si� niepowodzeniem. Nale�y po�o�y� temu kres. Mened�erowie projektówpotrzebuj� metod zbudowanych na za�o�eniu, �e zmiany s� nieuchronne —�e nale�y wykorzystywa� wiedz� i nowe informacje pozyskiwane ju� w trakcierealizacji procesu. W parze z tymi metodami musz� i�� wbudowane procesy,które pozwol� zintegrowa� zachodz�ce zmiany z wnioskami p�yn�cymi zezdobywanej na bie��co wiedzy.

Model cyklu zarz�dzania projektem (PMLC) to zespó� procesów, na który sk�adaj� si�:� definiowanie zakresu,� planowanie,� wykonanie,� monitoring i kontrola,� zamkni�cie projektu.

Prawid�owy cykl zarz�dzania projektem zawsze zaczyna si� od zdefiniowaniazakresu projektu i zawsze ko�czy si� jego zamkni�ciem. Wszystkie pi�� pro-cesów musi mie� miejsce przynajmniej raz, jednak mo�na je wielokrotniepowtarza� w okre�lonym porz�dku logicznym. Poszczególne grupy procesówzosta�y zdefiniowane w rozdziale 3. Logiczna kolejno�� wyst�powania procesówjest uzale�niona od charakterystyki konkretnego projektu. W niniejszej ksi��cezdefiniuj� pi�� ró�nych modeli PMLC. Wszystkie zosta�y opracowane z my�l�o szczególnych wymaganiach typu projektu, któremu zosta�y przypisane.

W poprzednich wydaniach tej ksi��ki przedstawi�em sposób porz�dkowaniaz�o�onych projektów i zarz�dzania nimi w warunkach niepewno�ci. W zwi�zkuz tym zdefiniowa�em pi�� modeli rozpisanych na cztery �wiartki:� TPM — model liniowy i model stopniowy,� APM — model iteracyjny i model adaptacyjny,� xPM — model ekstremalny,� MPx — model ekstremalny.





Powy�sze pi�� modeli tworzy swego rodzaju kontinuum, które rozci�ga si�od pewno�ci co do rozwi�zania (i cel, i rozwi�zanie s� jasno zdefiniowane),przez cz��ciow� niepewno�� co do rozwi�zania (cel jest jasno zdefiniowany,niestety nie mo�na tego powiedzie� o rozwi�zaniu), a� po pe�n� niepewno��co do rozwi�zania (ani cel, ani rozwi�zanie nie s� jasno zdefiniowane).

Na rysunku 2.2 stopie� pewno�ci jest funkcj� wymaga� i rozwi�zania. Immniej jeste� pewien, �e dysponujesz jasno zdefiniowanymi wymaganiamii rozwi�zaniem, tym dalsze modele z kontinuum niepewno�ci powiniene�wybiera�. Kiedy pojmiesz ju� charakter danego projektu, b�dziesz móg� spo-kojnie zdecydowa� si� na model oferuj�cy Ci najwi�ksze szanse na skuteczneuko�czenie projektu.

Rysunek 2.2. Modele PMLC

Rysunek 2.2 pokazuje, jak wygl�da rozk�ad modeli PMLC na cztery �wiartkiogólnego obrazu projektu, które zosta�y zdefiniowane w niniejszym rozdziale.Zauwa�, �e modele te w pewnym stopniu na siebie zachodz�. Wydawa�obysi�, �e zale�nie od tego, jak bardzo niejasne wydaj� si� wymagania projektui proponowane rozwi�zanie, nale�y dokonywa� wyboru spomi�dzy modeluliniowego, stopniowego, iteracyjnego, adaptacyjnego i ekstremalnego. Takte� w istocie jest. Decyzja w kwestii wyboru modelu najlepszego dla danegoprojektu opiera si� na kilku czynnikach, a jednym z nich jest jasno�� rozwi�za-nia. W przypadku projektów pozostaj�cych na granicy �wiartek TPM i APMzawsze b�dziesz musia� dokona� subiektywnej oceny tego, który z modeliPMLC jest modelem najlepiej dopasowanym. W cz��ci drugiej opisuj� kon-sekwencje tej subiektywnej decyzji.




86 Rozdzia 2.

Metody tradycyjnego zarz�dzania projektamiCzy istnieje lepsza sytuacja ni� ta, w której dok�adnie znasz cel projektu i pro-ponowane rozwi�zanie? To naj�atwiejsza ze wszystkich mo�liwych sytuacjiprojektowych, w dzisiejszym szybko zmieniaj�cym si� �wiecie biznesu wyst�-puje jednak najrzadziej. Dane gromadzone przeze mnie na ca�ym �wieciewskazuj�, �e zaledwie oko�o 20 procent wszystkich projektów mo�na rzetel-nie zakwalifikowa� do �wiartki TPM. S� to zwykle projekty, które organizacjaju� zna, na przyk�ad dlatego, �e ju� kilkakrotnie realizowano tam podobneprojekty. Nie nale�y si� tu spodziewa� niespodzianek. Klient jasno zdefi-niowa� cel projektu, a zespó� projektowy wie, jak ten cel osi�gn��. Zmian te�nie b�dzie wiele. W przypadku takich projektów stosuje si� ró�ne metody zarz�-dzania, musisz wi�c nauczy� si�, w jaki sposób wybra� t� najlepiej dopasowan�do potrzeb konkretnego projektu. Tego rodzaju projekty wi�� si� równie�z tym, �e zespó� projektowy porusza si� po znanym sobie terenie technolo-gicznym. Jego cz�onkowie ju� wielokrotnie korzystali z danej technologii i s�znakomicie przygotowani pod k�tem kreowania rozwi�za� niezb�dnychw realizacji tego rodzaju projektów.

Czynnikiem ograniczaj�cym, charakterystycznym dla metod TPM opartych naplanowaniu, jest brak tolerancji dla zmian. W metodach tych chodzi o osi�-ganie rezultatów zgodnie z ograniczeniami czasowymi i bud�etowymi. Ichstosowanie polega bardziej na trzymaniu si� planu ni� na generowaniu warto-�ci biznesowej. Plan to rzecz �wi�ta, wi�c trzymanie si� planu staje si� wyznacz-nikiem najlepszych zespo�ów projektowych.

Ze wzgl�du na czasy, w których �yjemy, liczba projektów rzetelnie realizowa-nych w ramach metodyki TPM gwa�townie maleje. Wszystkie proste projektyzosta�y ju� wykonane. Projekty pozostaj�ce w �wiartce TPM to projekty, któreby�y ju� wielokrotnie realizowane, wi�c prawdopodobnie istniej� ju� utarteschematy ich wykonania. Metody TPM s� stosowane coraz rzadziej, co otwieradrog� dla zupe�nie nowego zbioru metod, skoncentrowanych bardziej nakliencie oraz na generowaniu warto�ci biznesowej ni� na �cis�ym trzymaniusi� harmonogramu i bud�etu.

Oprócz jasno zdefiniowanego celu i rozwi�zania projekty prawid�owo zakwa-lifikowane do �wiartki TPM charakteryzuj� si� równie� kilkoma innymicechami, opisanymi pokrótce w kolejnych fragmentach.

Niewielka z�o�ono��

Niewielka z�o�ono�� oznacza po pierwsze, �e projekt jest naprawd� prosty,a po drugie, �e cz�sto bardzo przypomina inne, wykonane ju� projekty. Mo�epolega� na bezpo�rednim zastosowaniu znanych i zaakceptowanych zasadbiznesowych, w zwi�zku z czym w jego realizacji b�dzie mo�na wykorzysta�istniej�ce ju� wzory i kod. Tego rodzaju projekty by�y ju� wielokrotnie reali-zowane, w zwi�zku z czym ich wykonanie mo�e sprowadza� si� do zastoso-





wania praktycznie gotowych schematów. Deweloper mo�e odnosi� wra�enie,�e jego zadanie sprowadza si� do stosowania mechanizmu wytnij-wklej. W tegorodzaju przypadkach najbardziej wymagaj�cymi etapami realizacji projektub�d� integracja i testy.

Oczywi�cie zdarzaj� si� — cho� rzadko — sytuacje, w których projekt jest do��z�o�ony, a mimo to dobrze zdefiniowany.

Niewiele wniosków o zmian� zakresu projektu

To w�a�nie tutaj zaczynaj� si� trudno�ci ze stosowaniem metod TPM. Wycho-dzimy z za�o�enia, �e struktury RBS i WBS s� wzgl�dnie kompletne, w zwi�zkuz czym wnioski o zmian� zakresu nie b�d� pojawia� si� w ogóle albo b�dzieich niewiele. Ka�dy wniosek o zmian� zakresu projektu wymaga podj�cia nast�-puj�cych dzia�a�:� Kto� musi zdecydowa�, czy wniosek nale�y podda� analizie jednego

z cz�onków zespo�u projektowego.� Mened�er projektu musi przydzieli� wniosek w�a�ciwemu cz�onkowi

zespo�u projektowego.� Wyznaczony cz�onek zespo�u projektowego dokonuje analizy i sporz�dza

deklaracj� skutków dla projektu (PIS).� Mened�er projektu przedstawia klientowi rekomendacje.� Mened�er projektu wspólnie z klientem podejmuje decyzj� o zatwier-

dzeniu lub niezatwierdzeniu zmiany oraz o sposobie jej ewentualnegowprowadzenia.

� Je�eli wniosek o zmian� zakresu projektu zostaje zaakceptowany, trzebadokona� aktualizacji zakresu projektu, kosztów, harmonogramu, wyma-ga� zasobowych oraz kryteriów akceptacji projektu przez klienta.

Wszystkie te dzia�ania powoduj�, �e cz�onkowie zespo�u projektowego maj�mniej czasu na wykonywanie zada� przewidzianych w harmonogramie pro-jektu. Wystarczy, �e liczba wniosków o zmian� zakresu troch� wzro�nie,a z pierwotnego harmonogramu projektu nic nie zostanie. Co wi�cej, wi�k-szo�� czasu po�wi�conego na planowanie projektu oka�e si� bezwarto�ciowa.

Rozwi�zaniem problemu zbyt cz�stych wniosków o zmian� zakresu projektujest jaka� forma monitoringu i kontroli mened�erskiej. Mened�erskie �rodkikontrolne mog� by� stosowane we wszystkich czterech metodykach (TPM,APM, xPM i MPx), cho� w przypadku ka�dego rodzaju projektu stosuje si�nieco inne rozwi�zania.

Dobrze poznana infrastruktura technologiczna

Dobrze poznana infrastruktura technologiczna to infrastruktura stabilna,która sprawdzi�a si� ju� w przypadku wielu realizowanych projektów. Takiejinfrastrukturze towarzysz� równie� wysokie umiej�tno�ci i kompetencje




88 Rozdzia 2.

zwi�zane z korzystaniem z niej. Je�eli dana technologia jest nowa lub bli�ejnieznana zespo�owi projektowemu, mo�na wybra� jak�� inn� metod� reali-zacji danego projektu. Strategie te zostan� omówione w cz��ci drugiej.

Niewielkie ryzyko

Jednym z warunków stosowania metodyki TPM jest to, aby otoczenie pro-jektu by�o znane i przewidywalne. W przypadku takich projektów nie mo�eby� mowy o niespodziankach. Wszystkie czynniki, które mog� zagrozi� sku-tecznej realizacji projektu, wyst�pi�y ju� kiedy� w przesz�o�ci, w zwi�zku z czymistniej� sprawdzone strategie zabezpieczaj�ce, w ka�dej chwili gotowe do zasto-sowania. Du�e do�wiadczenie powoduje, �e nie wyst�puje ryzyko pope�nie-nia b��du. Klient jest przekonany, �e wymagania, funkcje i cechy zosta�y zde-finiowane w najmniejszych szczegó�ach i w zwi�zku z tym nie ulegn� onezmianie. Mened�er projektu przewidzia� prawdopodobne scenariusze i jestna nie przygotowany (oczywi�cie z pomini�ciem katastrof naturalnych i innychnieprzewidywalnych zdarze�). W projektach realizowanych metodami TPMmo�na mówi� o naprawd� bardzo ograniczonym ryzyku, nie oznacza tojednak, �e proces zarz�dzania ryzykiem mo�na po prostu pomin��. W �adnej�wiartce nie mo�na sobie pozwoli� na zignorowanie tego procesu, cho� wewszystkich �wiartkach stosuje si� inne techniki analizy, monitorowania i ogra-niczania ryzyka.

Do�wiadczone i kompetentne zespo�y projektowe

Projekty realizowane w przesz�o�ci mog� by� znakomitym materia�em szko-leniowym dla cz�onków zespo�ów projektowych. Przypisuj�c ludzi do pracyprzy kolejnych projektach, dajesz im mo�liwo�� zdobywania nowej wiedzyi rozwijania posiadanych umiej�tno�ci. Umiej�tno�ci i kompetencje cz�onkówzespo�u projektowego s� kluczowym czynnikiem sukcesu w realizacji wszyst-kich projektów. Wraz ze zmianami charakterystyki oczekiwanych rezultatówzmienia si� profil zespo�u projektowego, który najlepiej nadaje si� do osi�-gni�cia tych rezultatów. Przy projektach z �wiartki TPM mog� pracowa�mniej do�wiadczeni cz�onkowie zespo�u, a nawet mniej do�wiadczeni mene-d�erowie projektu. Takie zespo�y mog� by� rozproszone geograficznie i nietraci� przy tym na swojej skuteczno�ci.

Projekty TPM oparte na planowaniu

Skoro wszystkie mo�liwe informacje na temat projektu s� znane i uwa�aneza niezmienne, nale�a�oby wybra� taki model PMLC, który pozwoli jak naj-szybciej osi�gn�� za�o�ony cel. Na podstawie wymaga�, oczekiwanej funkcjo-nalno�ci oraz konkretnych wskazanych cech opracowuje si� kompletny planrealizacji projektu. W dokumencie tym wymienia si� wszystkie dzia�ania nie-zb�dne do spe�nienia wymaga�, rozk�ad tych dzia�a� w czasie oraz alokacj�zasobów ludzkich niezb�dnych do wykonania zaplanowanej pracy. ProjektyTPM to bez w�tpienia projekty oparte na planowaniu i realizacji planów.





Poziom ich sukcesu mierzy si� przez pryzmat zgodno�ci z opracowanymplanem.

Ca�a ta wiedza pozwala zarz�dza� tego rodzaju projektami z wykorzystaniemmetodyki TPM. Mo�esz na przyk�ad sformu�owa� kompletn� struktur�podzia�u pracy (WBS), a nast�pnie na tej podstawie oszacowa� czas realizacjiprojektu, oszacowa� zapotrzebowanie na zasoby, opracowa� harmonogramdzia�a� oraz napisa� propozycj� projektu. W ten sposób otrzymujesz bardzozgrabny pakiet dokumentów, którego przygotowanie jest stosunkowo proste.Ach, gdyby� �ycie mened�era projektu by�o a� tak proste… Niestety, takienie jest i w�a�nie z tym wi�� si� najwi�ksze wyzwania. W rozdzia�ach 11. i 12.wyja�niam, w jaki sposób mo�na dostosowa� metodyk� z tej �wiartki do bar-dziej z�o�onych sytuacji.

Dane uzyskane przeze mnie od ponad 10 tysi�cy mened�erów projektu z ca�ego�wiata sugeruj�, �e jakiej� formy tradycyjnego zarz�dzania wymaga góra 20 pro-cent wszystkich realizowanych projektów. Dwa modele opisane w dwóchponi�szych fragmentach s� szczególnymi przyk�adami metodyki TPM.

Liniowy model cyklu zarz�dzania projektem

Zaczn� od najprostszej metody TPM, mianowicie od liniowego modelu PMLC,poniewa� stanowi on fundament wszystkich innych jego wariacji prezento-wanych w tym podrozdziale. Liniowy model PMLC zosta� przedstawiony narysunku 2.3.

Rysunek 2.3. Liniowy model PMLC

Zwró� uwag�, �e na rysunku ka�da grupa procesów pojawia si� tylko raz. Niema p�tli prowadz�cych do powtórzenia danego procesu, wywo�anego nowymiinformacjami pozyskanymi na etapie realizacji dalszego procesu. Jest topowa�na wada wszystkich liniowych modeli PMLC — wiedza pozyskanaw zwi�zku z realizacj� jednej grupy procesów, na przyk�ad rozpocz�cia, niemo�e by� wykorzystana w realizacji wcze�niejszych grup procesów, na przy-k�ad na etapie wyznaczania zakresu projektu. Nie ma mo�liwo�ci cofni�ciasi� w celu poprawienia wypracowywanego rezultatu. Za�ó�my dla przyk�adu,�e projekt polega na napisaniu aplikacji komputerowej. Faza monitorowa-nia i kontroli obejmuje cykl rozwoju systemów, który móg�by sk�ada� si� poprostu z projektowania, budowania, testowania i wdra�ania. Wszystkie tedzia�ania podejmowane s� bez mo�liwo�ci powrotu do wcze�niejszej fazy cyklurozwoju systemów, a wi�c lepsze rozwi�zanie zidentyfikowane na etapie budo-wania nie mo�e zosta� uwzgl�dnione w postaci lepszego, zaktualizowanegoprojektu. Po prostu nie mo�na si� cofn��.




90 Rozdzia 2.

Mo�na by argumentowa�, �e mo�liwo�� cofni�cia si� i poprawienia rozwi�-zania le�y w jak najlepiej poj�tym interesie klienta. Prawdopodobnie tak w�a�niejest, ale skoro jeste� gotów pogodzi� si� z mo�liwo�ci� cofania si� w trakcierealizacji projektu, dlaczego od razu nie wybierzesz modelu PMLC, który tak�mo�liwo�� przewiduje? A do wyboru masz kilka ró�nych opcji.

Z�o�ony przez klienta wniosek o zmian� zakresu projektu zaburza równowag�w harmonogramie liniowego modelu PMLC, prawdopodobnie zaburza te�równowag� planu alokacji zasobów. Co najmniej jeden cz�onek zespo�u pro-jektowego musi dokona� analizy wniosku i wystawi� dokument PIS (doku-ment ten zostanie omówiony szczegó�owo w rozdziale 6.). Oznacza to, �e conajmniej jeden cz�onek zespo�u projektowego zostanie oderwany od zaplano-wanych prac, potencjalnie nara�aj�c ca�y projekt na opónienia.

Nikt nie zabroni Ci pos�ugiwa� si� liniowym modelem PMLC, je�li jednaklepszym wyborem by�by inny model PMLC, powiniene� przygotowa� si� nak�opoty.

Ostrze�enieLiniowy model PMLC nie toleruje �adnych zmian.

Stopniowy model cyklu zarz�dzania projektem

Na pierwszy rzut oka wydaje si�, �e jedyna ró�nica mi�dzy metodami linio-wymi a stopniowymi polega na tym, �e w ramach tego drugiego modelu rezul-taty s� ujawniane stopniowo, zgodnie z harmonogramem. Oznacza to, �e napocz�tku ujawniane jest rozwi�zanie cz��ciowe, a potem dodawane s� do niegokolejne elementy, które sk�adaj� si� w ko�cu na ca�o�� rozwi�zania. Kolejneelementy ujawniane s� tak d�ugo, a� rozwi�zanie b�dzie kompletne. Decyzjao odrzuceniu modelu liniowego i zastosowaniu stopniowego modelu PMLCjest determinowana przez rynek. W obu modelach ca�o�� rozwi�zania jest znanaju� na samym pocz�tku. Wprowadzenie cz��ciowego rozwi�zania na rynekjest form� zdobywania przyczó�ka, który ma by� potem lepszym punktemwyj�cia do uzyskiwania wi�kszego udzia�u w tym rynku. Zalety i wady tegomodelu omówi� szerzej w rozdziale 10.

Stopniowe ujawnianie rozwi�zania odbywa si� w sposób liniowy, przedsta-wiony na rysunku 2.4. Ostatecznie rozwi�zanie jest dok�adnie takie samo,jak gdyby zastosowany zosta� model liniowy. Teoretycznie projekt realizo-wany w modelu stopniowym powinien da� dok�adnie taki sam rezultat i zosta�uko�czony w takim samym czasie, jak gdyby by� prowadzony w modelu linio-wym, jednak model stopniowy wymaga od mened�era projektu nieco wi�k-szych nak�adów pracy, wi�c w praktyce zostanie uko�czony nieco póniej.

Poczynaj�c od bloku „Rozpocz�cie stopnia”, a na bloku „Nast�pny stopie�”ko�cz�c, poszczególne dzia�ania s� rozci�gni�te w czasie.





Rysunek 2.4. Stopniowy model PMLC

Bardziej pog��biona analiza wykaza�aby istnienie istotnych ró�nic mi�dzy stop-niowym a liniowym modelem PMLC. Na szczególn� wzmiank� zas�uguj�dwie poni�sze ró�nice:� Pierwsza z nich dotyczy wniosków o zmian� zakresu projektu. W linio-

wym modelu PMLC tego rodzaju wnioski nie s� mile widziane. Na koniecprac nad harmonogramem uwzgl�dnia si� w nim specjaln� rezerw�mened�ersk�, przewidzian� w�a�nie na ich rozpatrywanie (szczegó�oweinformacje na temat rezerwy mened�erskiej znajdziesz w rozdziale 5.).Struktura stopniowego modelu PMLC decyduje natomiast o tym, �eklient jest wr�cz zach�cany do sk�adania wniosków o zmian� zakresuprojektu. Wszystko dzieje si� w sposób subtelny i nierzucaj�cy si� w oczy.Pocz�tkowe ujawnienie cz��ciowego rozwi�zania daje klientowi i u�yt-kownikowi mo�liwo�� eksperymentowania z tym cz��ciowym rozwi�-zaniem w ramach scenariusza produkcyjnego. W ten sposób dochodzido wskazania obszarów mog�cych wymaga� usprawnie� lub ulepsze�,a st�d ju� krótka droga do wniosków o zmian� zakresu projektu. M�drymened�er projektu przewidzi, �e takie wnioski si� pojawi�, zarezerwujewi�c na nie odpowiedni czas w planie i harmonogramie projektu. Kwesti�te omówi� bardziej szczegó�owo w rozdziale 10.

� Druga ró�nica ma zwi�zek ze sposobem dekompozycji kompletnegorozwi�zania na rozwi�zania cz��ciowe, których opracowywanie trzebazaplanowa� z uwzgl�dnieniem kolejno�ci ich ujawniania. Harmonogramujawniania kolejnych cz��ci rozwi�zania musi uwzgl�dnia� zale�no�ciwyst�puj�ce mi�dzy tymi cz��ciami. Co zrobi� w sytuacji, w którejujawniana cz�� rozwi�zania jest uzale�niona od cech i funkcji, którychopracowanie zaplanowano dopiero w ramach kolejnego ujawnienia?Spójno�� ca�ego harmonogramu w�a�nie leg�a w gruzach. Konieczne s�wówczas znaczne modyfikacje pierwotnego planu, co znacz�co odbijesi� na harmonogramie kolejnych ujawnie�.

Ostrze�enieStopniowy model PMLC sprzyja sk�adaniu niepo��danych wniosków o zmian�zakresu projektu.

Metody zwinnego zarz�dzania projektamiZajmijmy si� teraz sytuacjami, w których dok�adnie wiadomo, co jest potrzebne,nie wiadomo natomiast, jak ten cel osi�gn��. Tego rodzaju projekty znajduj�si� w kontinuum gdzie� pomi�dzy projektami tradycyjnymi i ekstremalnymi.




92 Rozdzia 2.

Wielu mened�erów uzna�o, �e realizowanym przez nich projektom bli�ej dometodyki APM ni� do metodyki TPM lub xPM. Nie ulega w�tpliwo�ci, �egdy nie znamy rozwi�zania, metody TPM si� nie sprawdz�. Aby metodykaTPM mia�a szans� okaza� si� skuteczna, b�dziemy potrzebowa� szczegó�owegoplanu dzia�ania, którego nie da si� jednak opracowa� bez dok�adnej wiedzyna temat tego, do czego si� d��y. Nie zapominajmy jednak o metodach xPM.Zwolennicy zwinnego zarz�dzania projektami zapewne byliby zdania, �ew tej sytuacji dowolna metoda ekstremalnego zarz�dzania projektami powinnaokaza� si� skuteczna. Zgadzam si�, �e mo�na by zastosowa� dowoln� z tychmetod i prawdopodobnie osi�gn�� dobre wyniki. Niestety, w ten sposóbignorowaliby�my fakt, �e wiemy dok�adnie, co jest celem projektu — prze-cie� dysponujemy t� informacj�. Dlaczego zatem nie zdecydowa� si� na metod�,która pozwoli t� wiedz� uwzgl�dni�?

Projekty s�usznie zakwalifikowane do �wiartki APM odznaczaj� si� kilkomacechami charakterystycznymi, które pozwol� sobie pokrótce opisa�.

Istotny problem i nieznane rozwi�zanie

Niektóre projekty po prostu musz� zosta� wykonane — nie ma innego wyboru.Skoro rozwi�zanie nie jest znane, metodyka TPM oka�e si� nieskuteczna,poniewa� wymaga ona sporz�dzenia kompletnych struktur RBS i WBS. Nie-ustannie zadziwia mnie, �e tak wielu mened�erów uparcie wybiera narz�dzianieodpowiednie do realiów czekaj�cego ich zadania (by� mo�e cz�� z nichnie dysponuje niezb�dnymi narz�dziami). Tak naprawd� mo�esz wybiera�tylko spo�ród tych mo�liwo�ci, które pozwalaj� zidentyfikowa� akceptowalnerozwi�zanie poprzez realizacj� projektu. Tego rodzaju projekty stoj� w jaw-nej sprzeczno�ci z wszelkimi znanymi praktykami tradycyjnego zarz�dzaniaprojektem. Najwy�sze kierownictwo firm nie jest zbyt uradowane takim sta-nem rzeczy, poniewa� wszystkie potencjalnie dobre metody ró�ni� si� mi�dzysob� pod wzgl�dem zakresu. Projekt poch�ania okre�lone zasoby, cho� doko�ca nie wiadomo, jakie b�d� jego rezultaty. Cz�� funkcji lub cech rozwi�-zania mo�e by� znana, jednak ta w�a�nie znana cz�� rozwi�zania nie zawieraw sobie wystarczaj�co du�ej warto�ci biznesowej, aby mo�na je by�o wdro�y�.

Okazja biznesowa, której do tej pory nie uda�o si� wykorzysta�

Tego rodzaju projekty dotycz� sytuacji, w której firma traci na niewykorzy-stanej okazji biznesowej i musi znale� sposób na jej wykorzystanie poprzezstworzenie nowego produktu lub us�ugi albo w drodze od�wie�enia istniej�cejju� oferty. Pytanie jest zatem takie: O jak� okazj� biznesow� chodzi i jak mo�naj� wykorzysta�? Rozwi�zanie tego problemu jest na pocz�tku praktyczniezupe�nie nieznane.





Projekty APM maj� kluczowe znaczenie dla organizacji

Na tym etapie powiniene� ju� wiedzie�, �e projekty APM mog� by� niezwykleryzykowne. Je�eli wcze�niejsze próby rozwi�zania danego problemu zawio-d�y, to oznacza to, �e problem jest z�o�ony oraz �e jego akceptowalne roz-wi�zanie mo�e po prostu nie istnie�. Niewykluczone, �e organizacja b�dziemusia�a pogodzi� si� z rzeczywisto�ci� i robi� dobr� min� do z�ej gry. Projektymaj�ce na celu znalezienie rozwi�zania tego rodzaju skomplikowanych pro-blemów mog� mie� wi�ksz� szans� powodzenia, je�eli b�d� skoncentrowanena wybranych elementach problemu albo je�eli b�d� realizowane jako pro-jekty polegaj�ce na usprawnianiu procesów. Informacje na temat planowaniai wdra�ania projektów ci�g�ego doskonalenia procesów i praktyk znajdzieszw rozdziale 15.

Niezb�dne jest merytoryczne zaanga�owanie klienta

Rozwi�zanie uda si� znale� jedynie pod warunkiem nawi�zania meryto-rycznej wspó�pracy mi�dzy klientem a zespo�em projektowym, prowadzonejw atmosferze otwarto�ci i szczero�ci. Dla klienta oznacza to pe�ne uczestnic-two w pracy zespo�u projektowego oraz gotowo�� do nauki i poznawania roliklienta w realiach zwinnego zarz�dzania projektami. Cz�onkowie zespo�u pro-jektowego musz� si� natomiast uczy� specyfiki dzia�alno�ci klienta, a tak�erozmawiania jego j�zykiem. Zadaniem mened�era projektu jest przygotowa�obie strony do wspó�pracy w atmosferze szczero�ci i otwarto�ci. Oznacza torównie�, �e mened�er projektu b�dzie musia� podzieli� si� autorytetem i kom-petencjami przywódczymi z mened�erem wskazanym przez klienta.

Osobi�cie w tego rodzaju sytuacjach preferuj� model wspó�mened�erów pro-jektu. Po prostu dziel� si� obowi�zkami mened�era projektu z przedstawicie-lem klienta. Mo�e to by� mened�er z firmy klienta albo starszy analityk biz-nesowy, przypisany do danej jednostki biznesowej. Przekona�em si�, �e takiuk�ad wzmaga w kliencie poczucie odpowiedzialno�ci za projekt i znacz�cozwi�ksza szans� na ko�cowy sukces.

Projekty APM s� realizowane przez ma�e, powi�zane ze sob� zespo�y

Je�eli realizacja projektu wymaga udzia�u ponad trzydziestu osób, prawdo-podobnie powiniene� podzieli� go na kilka mniejszych projektów o bardziejograniczonym zakresie. Powiniene� wiedzie�, �e projekty APM zwykle nienajlepiej nadaj� si� do rozbudowywania. Je�eli Twój zespó� projektowy liczyponad trzydziestu cz�onków, podziel go na mniejsze zespo�y, odpowiedzialneza jaki� wycinek zakresu ca�ego projektu. Zorganizuj tymczasowe biuro pro-gramu, które zajmie si� kierowaniem i koordynacj� prac mniejszych zespo�ów.

Do �wiartki APM kwalifikuj� si� dwa modele. Pierwszym z nich jest iteracyjnymodel PMLC. Znakomicie nadaje si� on do realizacji projektów, w przypadkuktórych cz�� cech jest nieznana lub niewystarczaj�co precyzyjnie zdefiniowana.




94 Rozdzia 2.

Je�eli rozwi�zanie jest do�� mocno niedoprecyzowane — nieznane lub nieja-sno zdefiniowane s� nie tylko cechy, ale i funkcje — wówczas najlepiej dopa-sowanym modelem okazuje si� adaptacyjny model PMLC.

Istnieje wiele ró�nych metod adaptacyjnych i iteracyjnych, pozwalaj�cychzarz�dza� projektami APM, których cel jest jasno zdefiniowany, nieznanejest natomiast rozwi�zanie czy sposób osi�gni�cia tego celu. Wyobra sobiekontinuum projektów, w ramach którego po jednej stronie znajduj� si� pro-jekty o rozwi�zaniu praktycznie w ca�o�ci znanym i doprecyzowanym, a podrugiej stronie znajduj� si� projekty, w przypadku których rozwi�zanie jestznane i zdefiniowane w bardzo niewielkim stopniu. Wszystkie te projektymieszcz� si� w �wiartce APM. Zastanawiaj�c si� nad tym, w której �wiartcepowiniene� ulokowa� swoje projekty, pami�taj o tym, �e wiele — je�li niewi�kszo�� — kierowanych przez Ciebie projektów ma swoje miejsce w�a�niew �wiartce APM. Je�eli tak w�a�nie jest, to czy nie powiniene� zdecydowa� si�na wybór metodyki odpowiadaj�cej charakterystyce celu i rozwi�zania Twoichprojektów, zamiast na si�� stosowa� metody przystosowane do zarz�dzaniaprojektami o zupe�nie innej charakterystyce?

W moim przekonaniu grupa projektów APM o charakterze adaptacyjnymlub iteracyjnym nieustannie si� powi�ksza. Podczas wszystkich moich pre-zentacji pytam uczestników o cz�stotliwo��, z jak� spotykaj� si� z projektamiAPM. Bardzo rzadko zdarza si�, aby kto� udzieli� odpowiedzi innej ni� ta, �eco najmniej 70 procent realizowanych projektów nale�y do �wiartki APM,kolejne 20 procent to projekty TPM, a pozosta�e 10 procent obejmuje projektyxPM i MPx. Wielu mened�erów projektu usi�uje, niestety, stosowa� metodyk�TPM do projektów APM (by� mo�e po prostu nie dysponuj� �adnymi innyminarz�dziami) i w rezultacie odnosz� bardzo ograniczone sukcesy. Osi�ganeefekty wahaj� si� od umiarkowanych sukcesów a� po ca�kowit� pora�k�. Pro-jekty APM stawiaj� przed mened�erem zupe�nie inne wyzwania, w zwi�zkuz czym trzeba realizowa� je innymi metodami. Metodyka TPM po prostu si�tu nie sprawdza. Od zawsze postuluj�, aby metodyk� kierowania projektemdobiera� do charakterystyki projektu — odwrócenie tej kolejno�ci jest pro-szeniem si� o katastrof�. Moim zdaniem jest przejawem pewnej niekonse-kwencji, �e definiujemy projekt jako niepowtarzalne do�wiadczenie, którenigdy wcze�niej nie mia�o miejsca i które w takich samych okoliczno�ciachju� nigdy si� nie wydarzy, a mimo to nie staramy si� o to, aby metoda reali-zacji takiego projektu równie� by�a niepowtarzalna i wyj�tkowa. Powiedzia�-bym, �e metoda zarz�dzania projektem jest niepowtarzalna tylko w pewnymstopniu, bowiem jej wyj�tkowo�� ogranicza fakt stosowania sprawdzonychi wypróbowanych zestawów narz�dzi, schematów i procesów. Gdyby te stan-dardy nie istnia�y, zarz�dzanie projektem sprowadza�oby si� do czystegochaosu. Co wi�cej, gdyby projekty realizowano w taki sposób, organizacja —przynajmniej na tym polu — nigdy nie by�aby organizacj� ucz�c� si�.





UwagaUwa�am, �e warto to podkre�li�: Definiujemy projekt jako niepowtarzalnedo�wiadczenie, które nigdy wcze�niej nie mia�o miejsca i które w takichsamych okoliczno�ciach ju� nigdy si� nie wydarzy, a mimo to nie staramysi� o to, aby metoda realizacji takiego projektu równie� by�a niepowtarzalnai wyj�tkowa. Moim zdaniem jest to przejaw niekonsekwencji.

Wraz z tym, jak rozwi�zanie zmienia si� z jasno sprecyzowanego w rozwi�-zanie, które nie jest jasno zdefiniowane, pojawiaj� si� liczne sytuacje wyma-gaj�ce od mened�era projektu innego podej�cia. Za�ó�my, �e nieznane s�tylko mniej istotne aspekty rozwi�zania, na przyk�ad kolorystyka t�a i czcio-nek stosowanych na stronie logowania. Co zrobisz w takiej sytuacji? W�a�ci-wym rozwi�zaniem powinno by� zastosowanie metody, która pozwoli w jaknajwi�kszym stopniu wykorzysta� znan� cz�� rozwi�zania. Taka metoda dajemo�liwo�� przedstawienia klientowi prototypu produkcyjnego do oceny. Klientmo�e wówczas okre�li�, co powinno si� w nim znale�, a czego na razie bra-kuje. Na drugim skraju �wiartki APM znajduj� si� projekty, w przypadkuktórych rozwi�zanie jest w znakomitej cz��ci nieznane. Charakteryzuj� si� onezdecydowanie wi�kszym ryzykiem ni� projekty, o których niemal wszystkowiadomo. Potrzebne jest rozwi�zanie i kwesti� priorytetow� jest jego znale-zienie. Jak post�pi�by� w tej sytuacji? Wybierzesz metod� opracowan� z my�l�o poszukiwaniu i opracowywaniu wi�kszej cz��ci rozwi�zania. Metoda tamusi pozwala� w jaki� sposób wyj�� od tego, co wiesz, a nast�pnie d��y� kutemu, co musisz ustali�. W rozdziale 11. przedstawi� opracowan� przeze mnieadaptacyjn� struktur� projektu (APF, od ang. adaptive project framework). APFjest jedynym znanym mi adaptacyjnym modelem PMLC, uwzgl�dniaj�cymstrumienie dzia�a�, stworzone specjalnie z my�l� o odkrywaniu kolejnychaspektów rozwi�zania, a nie o ich wdra�aniu. Strumienie te nazywam „pro-bierczymi torami p�ywackimi”. Ich definicj� i szczegó�ow� charakterystyk�znajdziesz w rozdziale 11.

Istnieje wiele ró�nych metod kierowania projektami APM, lecz wszystkie ��-czy jeden oczywisty fakt — dotycz� one projektów, w przypadku których bezzgadywania nie b�dziesz w stanie opracowa� kompletnej struktury WBS. Jako�e w rzetelnym planowaniu projektu zgadywanki s� nie do pomy�lenia,b�dziesz musia� zdecydowa� si� na metod�, która nie wymaga pe�nej strukturyWBS. Wszystkie metody APM s� sformu�owane w taki sposób, aby w trakcieprac nad projektem umo�liwia� identyfikacj� brakuj�cych aspektów rozwi�za-nia. Kolejne odkrywane elementy s� na bie��co integrowane z rozwi�zaniem.Modele PMLC nale��ce do kategorii APM mo�na podzieli� na dwie grupy:iteracyjne modele PMLC i adaptacyjne modele PMLC. Decyzja w kwestiiwyboru konkretnego modelu zale�y cz��ciowo od pocz�tkowego stopnianiepewno�ci co do rozwi�zania. Przekonasz si� o tym w rozdziale 11., gdziezajmiemy si� dopasowywaniem modeli PMLC z �wiartki APM do bardziejskomplikowanych zastosowa�.




96 Rozdzia 2.

Iteracyjny model cyklu zarz�dzania projektem

Gdy tylko okazuje si�, �e wybrane aspekty rozwi�zania nie s� jasno zdefinio-wane lub s� wr�cz nieznane, powiniene� sk�ania� si� ku jednemu z iteracyjnychmodeli PMLC. W przypadku projektów zwi�zanych z tworzeniem oprogra-mowania najpopularniejszymi modelami s� ewolucyjny model kaskadowy,model Scrum, model Rational Unified Process (RUP) i model Dynamic SystemDevelopment Metod (DSDM). Odwo�ania do tekstów po�wi�conych wszyst-kim czterem modelom znajdziesz w bibliografii w dodatku C. Iteracyjny mo-del PMLC zosta� przedstawiony na rysunku 2.5.

Rysunek 2.5. Iteracyjny model PMLC

By� mo�e zwróci�e� uwag�, �e model ten w do�� du�ym stopniu przypominatworzenie prototypów produkcyjnych. Chodzi mi o to, �e ka�da innowacjaskutkuje powstaniem roboczego rozwi�zania. Celem takiego dzia�ania jestpokazanie klientowi po�redniego, a potencjalnie równie� niekompletnegorozwi�zania, aby móg� on zastanowi� si� nad jego dodatkowymi cechami lubzmianami. Zmiany te s� nast�pnie wprowadzane do prototypu i w ten sposóbpowstaje kolejne niepe�ne rozwi�zanie. Proces jest powtarzany tak d�ugo, a�klient b�dzie w pe�ni usatysfakcjonowany rozwi�zaniem i nie b�dzie mia� ju��adnych zmian do zaproponowania albo a� sko�cz� si� czas lub �rodki finan-sowe przeznaczone na realizacj� projektu. Iteracyjny model PMLC ró�ni si�od modelu stopniowego pod tym wzgl�dem, �e jest przystosowany do uwzgl�d-niania licznych zmian. Zmiana jest wr�cz nieod��cznym elementem tegomodelu.

Iteracyjne modele PMLC z pewno�ci� spe�niaj� wymagania projektów, w któ-rych pojawia si� konieczno�� odkrywania kolejnych aspektów rozwi�za�.Rysunek 2.5 dowodzi, �e pozyskiwanie nowych informacji odbywa si� wrazz ka�d� p�tl� sprz��enia zwrotnego. Ka�da iteracja powoduje powstanie pe�-niejszego rozwi�zania, co jest zwi�zane z faktem, �e klient ma mo�liwo�� zapo-znania si� z bie��c� wersj� rozwi�zania i przedstawienia swoich uwag cz�on-kom zespo�u projektowego. Przyjmujemy wi�c za�o�enie, �e z ka�d� kolejn�iteracj� klient pozyskuje nowe informacje na temat opracowywanego rozwi�-zania. W modelach zwi�zanych z tworzeniem prototypu zespó� projektowyuwzgl�dnia zwykle uwagi klienta w kolejnej wersji prezentowanego prototypu.Metodyka APM charakteryzuje si� zatem wyranym elementem wspó�pracy,który nie jest zauwa�alny w ramach metodyki TPM.





Adaptacyjny model cyklu zarz�dzania projektem

Kolejnym modelem pozwalaj�cym odej�� o krok dalej od w pe�ni zdefinio-wanego rozwi�zania jest adaptacyjny model PMLC. W tym przypadku bra-kuj�ce aspekty rozwi�zania obejmuj� równie� jego funkcjonalno��. Znajdu-jemy si� zatem w skrajnym obszarze �wiartki APM, gdzie o rozwi�zaniu niewiadomo prawie nic. Innymi s�owy, im mniej wiesz na temat poszukiwanegorozwi�zania, tym bardziej powiniene� sk�ania� si� ku adaptacyjnemu mode-lowi PMLC (a nie ku modelowi iteracyjnemu). Problem w tym, �e wszystkieobecnie stosowane modele adaptacyjne zosta�y stworzone na potrzeby pracnad oprogramowaniem. Oczywi�cie, nie wszystkie projekty dotycz� oprogra-mowania, wi�c w kontinuum modeli PMLC istnieje olbrzymia luka. W ramachw�asnej praktyki konsultingowej przekona�em si�, �e jest to powa�na wadametodyki zwinnego zarz�dzania projektami, w zwi�zku z czym postanowi-�em stworzy� adaptacyjn� struktur� projektu (APF), któr� mo�na zastosowa�w realizacji projektów wszelkiego typu. APF jest metod� z zakresu APM, któraw odniesieniu do projektów wszystkich typów wype�nia luk� mi�dzy meto-dyk� TPM a metodyk� xPM. Skutecznie wykorzystywa�em APF w projektachzwi�zanych z pracami nad produktem, projektowaniem procesów bizneso-wych lub usprawnianiem ju� istniej�cych procesów. Adaptacyjna strukturaprojektu zosta�a szczegó�owo opisana w rozdziale 11.

Rysunek 2.6 stanowi graficzne przedstawienie adaptacyjnego modelu PMLC.Na poziomie grup procesów jest on identyczny z modelem iteracyjnym. Ró�-nice staj� si� oczywiste dopiero w ramach poszczególnych grup procesów.Szczegó�ow� charakterystyk� adaptacyjnego modelu PMLC znajdzieszw rozdziale 11.

Rysunek 2.6. Adaptacyjny model PMLC

Ostrze�enieWe wszystkich modelach zwinnego zarz�dzania projektami zakres projektumo�e si� zmienia�.

Metody ekstremalnego zarz�dzania projektamiTrzeci model PMLC znajduje zastosowanie do projektów, w przypadku któ-rych nieznane lub niejasno zdefiniowane s� zarówno rozwi�zanie, jak i cel.Wchodzimy zatem w obszar charakterystyczny dla R&D, tworzenia nowychproduktów i projektów polegaj�cych na usprawnianiu procesów. Mowa tu




98 Rozdzia 2.

o projektach o wysokim ryzyku i du�ej liczbie zmian, a nierzadko równie�du�ej szybko�ci realizacji. Odsetek projektów zako�czonych niepowodzeniembywa w tym przypadku bardzo wysoki.

Kiedy dysponujesz bardzo ograniczon� wiedz� na temat rozwi�zania i celuprojektu, mo�esz nie wiedzie�, jak� metod� taki projekt realizowa�. Jakie narz�-dzia, schematy i procesy oka�� si� najskuteczniejsze w tej sytuacji? Czy cokol-wiek oka�e si� skuteczne? Jedynie najodwa�niejsze, sk�onne podejmowa� naj-wi�ksze ryzyko, najbardziej elastyczne i kreatywne zespo�y projektowe nieul�kn� si� takiego zadania. Niezb�dne jest tu bardzo intensywne zaanga�o-wanie klienta. Kiedy udajesz si� w nieznane, nie powiniene� odchodzi� zbytdaleko, je�eli rami� w rami� nie idzie z Tob� prawdziwy ekspert.

Co robi�, kiedy nie do ko�ca wiadomo, co jest potrzebne? Co w sytuacji,w której cel jest ca�kowicie nieznany? Wiele osób próbowa�o ju� na si�� reali-zowa� takie projekty metodami tradycyjnymi, jednak te po prostu si� niesprawdzaj�. Z my�l� o kierowaniu projektami, których cel jest bardzo niejasnylub w ogóle nieznany, stworzono metody xPM. Doskona�ym przyk�ademtakiego projektu jest projektowanie strony internetowej dla firmy dzia�aj�cejw bran�y B2B bez �adnej dodatkowej specyfikacji. Podobnie jak to ma miej-sce na wczesnych etapach prac badawczo-rozwojowych, budowanie stronyinternetowej dla firmy z bran�y B2B zaczyna si� od zgadywania. Wraz z post�-pem prac klient ocenia przyj�te za�o�enia i daje dalsze wskazówki cz�onkomzespo�u projektowego. Proces ten si� powtarza. Cz��ciowe rozwi�zanie alboprzekszta�ci si� w jego ostateczn� wersj�, albo zostanie porzucone gdzie� podrodze. W wi�kszo�ci przypadków takie projekty nie maj� sztywnego bud�etuani harmonogramu. Brak jasno zdefiniowanego celu i rozwi�zania powoduje,�e projekt jest nara�ony na liczne zmiany. Charakter tych projektów powo-duje, �e niestety nie mieszcz� si� one w sztywnych ramach ogranicze� czasowychi kosztowych.

Projekty kwalifikuj�ce si� do �wiartki xPM oraz kolejne etapy ekstremalnegomodelu PMLC zosta�y szczegó�owo opisane w rozdziale 12.

Projekt xPM jest projektem badawczo-rozwojowym

Celem projektu badawczo-rozwojowego mo�e by� zaledwie przypuszczenieco do po��danego stanu docelowego. Czy ten cel jest osi�galny? W jakim stop-niu jest osi�galny? Odpowiedzi na te pytania szuka si� w trakcie realizacjiprojektu. W przypadku tego rodzaju projektu xPM starasz si� ustali� pewienprzysz�y stan poprzez potencjalnie wykonalne rozwi�zania. Nie znasz ostatecz-nego kszta�tu tego rozwi�zania, wi�c nie masz �adnych podstaw, aby wiedzie�,co jest Twoim celem. Pozostaje mie� nadziej�, �e opracowywane w�a�nie roz-wi�zanie pozwoli osi�gn�� cel oraz �e oba te elementy b�d� mia�y wystarcza-j�c� warto�� biznesow�.





Projekt xPM charakteryzuje si� bardzo du�ym ryzykiem

Ka�da podró� w nieznane jest bardzo ryzykowna — prawdopodobie�stwoponiesienia pora�ki jest bardzo du�e. Nawet je�li uda si� osi�gn�� cel, kosztopracowanego rozwi�zania mo�e okaza� si� zaporowy. Mo�e si� te� okaza�,�e obrany kierunek poszukiwania rozwi�zania jest ca�kowicie b��dny i prowa-dzi jedynie do pora�ki. Je�eli przyj�ty proces zarz�dzania projektem pozwalawcze�nie wykry� takie zagro�enie, zaoszcz�dzisz wiele pieni�dzy i czasu.

W przypadku projektów xPM trudno jest zdefiniowa� pora�k�. Projekt mo�ena przyk�ad nie rozwi�za� pierwotnego problemu, ale mo�e skutkowa� stwo-rzeniem produktu przydatnego w innym obszarze. Najlepszym tego przy-k�adem s� cho�by samoprzylepne karteczki Post-It firmy 3M. Niemal siedemlat po tym, jak niepowodzeniem zako�czy� si� projekt maj�cy na celu opra-cowanie substancji klej�cej o ograniczonej czasowo skuteczno�ci (by� to pro-jekt xPM), jeden z in�ynierów firmy znalaz� zastosowanie dla stworzonegowówczas produktu — w ten sposób powsta�y samoprzylepne karteczki donotowania Post-It (to by� ju� projekt MPx).

Metodyka xPM si�ga najdalszych granic kontinuum projektów. Projektykwalifikowane do �wiartki xPM to projekty, w przypadku których nie da si�jasno zdefiniowa� ani celu, ani rozwi�zania. Przyk�adem mog� by� tu pro-jekty R&D. Dzia�ania zwi�zane z planowaniem s� ograniczone do minimumi podejmowane na bie��co, a cel i rozwi�zanie zostaj� okre�lone dopierow jednej z kolejnych faz realizacji projektu. Nie ulega w�tpliwo�ci, �e modelPMLC dostosowany do potrzeb projektów xPM musi zapewnia� zespo�owiprojektowemu jak najwi�ksz� elastyczno��, czym wyranie ró�ni si� od modeliTPM, które wymagaj� �cis�ego trzymania si� ustalonych procesów. Je�eli w trak-cie realizacji projektu nie pojawi� si� �adne widoki na ustalenie spójnego celui rozwi�zania, klient mo�e w ka�dej chwili przerwa� realizacj� projektu i oszcz�-dzi� w ten sposób zasoby na nast�pn� prób� z zastosowaniem innej metody.

Je�eli na pocz�tku realizacji projektu nie udaje si� jasno zdefiniowa� jego celu,sytuacja bardzo przypomina typowy projekt badawczo-rozwojowy. Co nale�yzrobi� w takiej sytuacji? Powiniene� wybra� tak� metod�, która pozwala jed-nocze�nie doprecyzowa� cel i okre�li� rozwi�zanie. Metoda ta musi obejmowa�kilka równoleg�ych probierczych torów p�ywackich. Równoleg�e probierczetory p�ywackie wyznaczaj� te sposoby post�powania, które oferuj� najwi�k-sze szanse na jednoczesne doprecyzowanie celu i wskazanie rozwi�zania.W zale�no�ci od dost�pnego czasu, bud�etu i zasobów ludzkich dzia�ania temog� by� realizowane kolejno lub jednocze�nie. Probiercze tory p�ywackiemo�na zastosowa� równie� w celu eliminowania potencjalnych celów i roz-wi�za� lub zaw��ania ich liczby. Nie ulega w�tpliwo�ci, �e projekty xPM sta-nowi� ca�kowicie odr�bn� klas� projektów i wymagaj� zupe�nie innej meto-dyki, aby mo�na by�o mówi� o ich skutecznym wykonaniu.

Celem jest nierzadko tylko pewne przypuszczenie co do po��danego stanudocelowego. Pozostaje wówczas liczy� na to, �e w drodze do osi�gni�cia tego




100 Rozdzia 2.

celu uda si� znale� w�a�ciwe rozwi�zanie. Zale�y nam zatem na tym, aby celi rozwi�zanie bieg�y do punktu, w którym powstanie warto�� biznesowa. Wi�-cej informacji na ten temat znajdziesz w rozdziale 12.

Oprócz braku informacji na temat celu i rozwi�zania, projekty kwalifikuj�cesi� do �wiartki xPM charakteryzuj� si� jeszcze kilkoma szczególnymi cechami,które omawiam poni�ej.

Model ekstremalny

Ekstremalny model PMLC zosta� przedstawiony na rysunku 2.7. Model tenju� z samej swej natury jest modelem nieustrukturowanym. Zosta� stworzonyz my�l� o realizacji projektów o niejasno zdefiniowanych celach lub celach,których po prostu nie da si� zdefiniowa� ze wzgl�du na badawczy charakterprojektu. Klient i zespó� projektowy pozyskuj� nowe informacje w poszcze-gólnych fazach realizacji projektu, popychaj�c go tym samym ku ko�cowi.Zwró� uwag�, �e podstawowa ró�nica mi�dzy modelami APM i xPM dotyczygrupy procesów zakresu. W ramach projektu APM zakres jest ustalany jedenraz, na samym pocz�tku prac. Wynika to g�ównie z faktu, �e jasno zdefiniowanyjest cel projektu. W metodyce xPM zakres jest korygowany w ka�dej kolejnejfazie, co ma zwi�zek z faktem, �e cel realizacji projektu mo�e ulega� zmianie.

Rysunek 2.7. Ekstremalny model PMLC

Modele ekstremalne, podobnie jak modele PMLC nale��ce do �wiartki APM,maj� charakter iteracyjny. Powtórzenia dotycz� niesprecyzowanej liczbykrótkich faz (jedna faza zajmuje najcz��ciej od tygodnia do czterech tygo-dni), realizowanych z my�l� o znalezieniu rozwi�zania (oraz celu). Projektmo�e doprowadzi� do wskazania akceptowalnego rozwi�zania, lecz mo�erównie� zosta� w dowolnym momencie anulowany. Od projektów APMró�ni go to, �e nieznany jest cel, a w najlepszym razie kto� ma jaki� bli�ej nie-sprecyzowany pomys�, co mog�oby tym celem by�. W takiej sytuacji klientpowiedzia�by co� w tym stylu: „Rozpoznam to, gdy to zobacz�”. Dla do�wiad-czonego mened�era projektu nie jest to �adna nowo��, poniewa� takie s�owas�ysza� ju� wielokrotnie. Tak czy owak, to na nim spoczywa odpowiedzial-no�� zwi�zana ze znalezieniem rozwi�zania (oczywi�cie z pomoc� klienta).

Modele xPM odró�nia od modeli APM równie� to, �e w ich przypadku odklienta oczekuje si� wi�kszego zaanga�owania zarówno mi�dzy kolejnymifazami, jak i w trakcie ich trwania. W wielu projektach xPM to klient obej-muje rol� lidera, w odró�nieniu od projektów APM, w przypadku którychmamy do czynienia ze wspó�zarz�dzaniem. Dobrym przyk�adem projektówxPM s� badania nad nowymi lekami. Za�ó�my dla przyk�adu, �e celem pro-





jektu jest znalezienie nowego dodatku do �ywno�ci, który zapobiega�by kata-rowi. Jest to niezwykle szeroko zdefiniowany projekt, wi�c nie ma sensu narzu-ca� mu sztywnych ram czasowych ani z góry ustalonego bud�etu. Zespó�projektowy rozpocznie prace najprawdopodobniej od wyboru jakiego� kie-runku lub kierunków bada� i b�dzie liczy� na to, �e kolejne efekty jego pracb�d� spe�nia� dwa poni�sze warunki:� Uko�czona w�a�nie faza realizacji projektu b�dzie wskazywa� nowy,

bardziej produktywny kierunek prac w nast�pnej fazie. Mo�na zatempowiedzie�, �e projekty xPM — podobnie jak projekty APM — polegaj�na nieustannym odkrywaniu nowych informacji.

� Podmiot finansuj�cy projekt b�dzie dostrzega� w uzyskiwanych efek-tach na tyle du�y potencja�, aby w dalszym ci�gu finansowa� realizacj�projektu.

W przypadku projektów xPM nie istnieje ograniczenie w postaci trójk�tazakresu, jak to ma miejsce w przypadku projektów TPM i APM. Z pewno�ci�pami�tasz, �e projekty TPM i APM s� ograniczone zarówno przez ramy cza-sowe, jak i przez bud�et, co ma bardzo powa�ne konsekwencje. „Do ko�catej dekady postawimy cz�owieka na Ksi��ycu i bezpiecznie sprowadzimy goz powrotem” — to bardzo precyzyjne sformu�owanie, które jest od razu ogra-niczone czasowo. Kiedy sko�czy si� czas lub wyczerpi� si� �rodki finansowe,projekt zostaje przerwany. Pewne ograniczenia wyst�puj� równie� w przy-padku projektów xPM, maj� one jednak zupe�nie inny charakter. Projekt xPMzostaje wstrzymany, gdy wyst�pi jedna z dwóch poni�szych sytuacji:� Uda�o si� znale� cel i rozwi�zanie, które maj� okre�lon� warto�� biz-

nesow�. Jednym s�owem: sukces!� Sponsor nie godzi si� dalej finansowa� projektu. Sponsor mo�e zadecy-

dowa� o wstrzymaniu finansowania ze wzgl�du na brak wyranych i war-to�ciowych post�pów albo ze wzgl�du na fakt, �e projekt nie zmierza dowskazania akceptowalnego rozwi�zania. Projekt zostaje anulowany.Pora�ka! Nie wszystko jest jednak stracone. Nierzadko zdarza si�, �etakie projekty s� ponownie uruchamiane w celu poprowadzenia poszu-kiwa� rozwi�zania w nowych kierunkach.

Ostrze�enieEkstremalne modele PMLC mog� powodowa�, �e zespó� projektowy b�dzieposzukiwa� rozwi�zania w zupe�nie niew�a�ciwym miejscu.

Modele cyklu zarz�dzania projektem emertxeZnane jest rozwi�zanie, nieznany jest cel. Wiem, �e w�a�nie przysz�y Ci namy�l reklamy profesjonalnych firm konsultingowych, które oferuj� Ci gotowerozwi�zania Twoich problemów. Takich firm nie brakuje na rynku, z pew-no�ci� wi�c wiesz, co mam na my�li. Masz tylko wskaza� swój problem, a oni




102 Rozdzia 2.

przybiegn� Ci na ratunek ze swoim rozwi�zaniem. Mam tu na my�li zupe�-nie inn� sytuacj�.

Projekty MPx to projekty o charakterze badawczo-rozwojowym, realizowanejednak w odwrotnej kolejno�ci. Projekt badawczo-rozwojowy kojarzy Ci si�zapewne z jakim� okre�lonym stanem docelowym, który ma zosta� osi�gni�tyw drodze realizacji projektu. Kiedy projekt zostanie ju� rozpocz�ty, mo�e si�okaza�, �e konieczna jest modyfikacja po��danego stanu docelowego. Pro-jekt MPx jest zatem odwrotno�ci� projektu badawczo-rozwojowego. Dysponu-jesz okre�lonym rozwi�zaniem, nie wiesz natomiast, jakie b�dzie jego zasto-sowanie (nieznany jest zatem cel). Liczysz na znalezienie zastosowania, któreuda si� osi�gn�� w drodze pewnych modyfikacji znanego rozwi�zania. Je�elioka�e si�, �e znalezione zastosowanie ma warto�� biznesow�, odniesiesz sukces.

Rysunek 2.7 mo�e zatem przedstawia� zarówno projekty xPM, jak i MPx.

Zwró� uwag�, �e w tym przypadku ka�da kolejna faza jest odr�bnym, w pe�nisamodzielnym projektem. Ka�da faza zaczyna si� od okre�lenia zakresu,a ko�czy decyzj� o rozpocz�ciu kolejnej fazy, podejmowan� z ko�cem fazybie��cej. W projektach MPx faza i projekt to w�a�ciwie jedno i to samo.

Ostrze�enieModele emertxe PMLC pozwalaj� zwykle wyznaczy� cel, który jednak niezawsze oferuje po��dan� warto�� biznesow�. Nie daj si� zwie�� ciekawost-kom technicznym i zawsze podejmuj w�a�ciwe decyzje biznesowe.

Opisane tu metody dotycz� projektów MPx, w przypadku których jasno i pre-cyzyjnie zdefiniowane jest rozwi�zanie, nieznany jest natomiast cel. Brzminonsensownie, a jednak takie nie jest (na razie b�dziesz musia� uwierzy� mina s�owo — bardziej szczegó�owe rozwa�ania na ten temat znajdziesz w roz-dziale 12.). Osobi�cie naj�atwiej jest mi my�le� o tych projektach jako o odwró-conej wersji projektów ekstremalnych i st�d te� nazwa „emertxe”. Rozwi�zanielub jeden z jego wariantów jest podstaw� do d��enia do celu, który mo�naz pomoc� tego rozwi�zania osi�gn�� i który ma akceptowaln� warto�� bizne-sow�. Poszukujesz zatem celu, a nie rozwi�zania, jak to ma miejsce w przy-padku projektów xPM. Modele PMLC dla projektów xPM i MPx maj� ze so-b� wiele wspólnego, dlatego te� zosta�y opisane równolegle w rozdziale 12.

Znasz rozwi�zanie, wi�c nie pozostaje Ci nic innego, jak znale� problem,który mo�esz za jego pomoc� wyeliminowa�. Kto� móg�by powiedzie�, �e toraczej temat na artyku� naukowy. Warto jednak spojrze� na to inaczej. To poprostu odwrócony projekt badawczo-rozwojowy. Przedstaw swoje rozwi�za-nie i czekaj, a� kto� zg�osi si� z pasuj�cym do niego problemem. Nie by�by topierwszy raz. Najlepszym tego dowodem jest znana historia samoprzylepnychkartek do notowania Post-It, stworzonych przez firm� 3M. Produkt le�a� napó�ce przez kilka lat, zanim kto� przypadkowo znalaz� dla niego zastosowanie,a potem ca�a historia przesz�a do legendy. Tego rodzaju projekty s� cz�storealizowane w du�ych firmach farmaceutycznych.





Oprócz nieznanego celu oraz jasno zdefiniowanego rozwi�zania istnieje rów-nie� kilka innych cech charakterystycznych dla projektów MPx. Opisuj� jeponi�ej.

Nowa technologia o nieznanym zastosowaniu

Przypomina mi si� historia technologii RFID i jej zastosowania do odczytuinformacji zakodowanych w przedmiotach transportowanych za pomoc�pasów transmisyjnych, a nast�pnie kierowania ich na podstawie tych infor-macji w odpowiednie miejsca. Kiedy technologia ta ujrza�a �wiat�o dzienne,od razu pomy�lano o kilku ró�nych jej zastosowaniach w magazynach. Jed-na z najwi�kszych sieci handlowych �wiata powo�a�a specjalny zespó�, którymia� znale� zastosowania technologii RFID w jej systemach logistycznychi systemach obs�ugi �a�cucha dostaw. Technologia ta charakteryzowa�a si�wówczas precyzj� na poziomie 70 procent, w zwi�zku z czym zespó� oceni�,�e b�dzie ona mia�a znaczn� warto�� biznesow� pod warunkiem, �e uda si�wyranie poprawi� jej dok�adno��. Cel ten uda�o si� osi�gn�� i technologiaRFID jest dzi� powszechnie stosowana w magazynach oraz w procesach dys-trybucyjnych.

Rozwi�zanie, które nie ma swojego problemu

Kilku �wietnych przyk�adów tego typu sytuacji dostarcza komercyjne opro-gramowanie komputerowe. Za�ó�my, �e na rynku w�a�nie pojawi� si� nowysystem zarz�dzania zasobami ludzkimi (HRMS, od ang. human resource mana-

gement system), wyprodukowany przez du�ego i znanego producenta oprogra-mowania. Celem Twojego projektu jest dokonanie oceny przydatno�ci tegosystemu pod k�tem nowego procesu zarz�dzania zasobami ludzkimi, któryzosta� w�a�nie zaaprobowany przez najwy�sze kierownictwo firmy. Jest to chybanajprostszy mo�liwy przyk�ad projektu MPx, bowiem znasz ju� obszar, w któ-rym b�dziesz szuka� zastosowania. Musisz jedynie ustali�, na ile nowy HRMSodpowiada potrzebom firmy i jak� oferuje jej warto�� biznesow�. Istniej�jednak tak�e takie projekty, w przypadku których rozwi�zanie jest ca�kowicienieznane. Przyk�adem niech b�dzie tu sok pozyskiwany z pewnego dziwnegodrzewa z Amazonii. Celem projektu by�oby znalezienie takiego zastosowa-nia tego soku, które mia�oby wystarczaj�co du�� warto�� biznesow�.

Przegl�d modeli PMLCZapoznali�my si� z pi�cioma modelami PMLC, którym warto przyjrze� si�bli�ej i dokona� ich porównania. Je�eli uwa�nie czyta�e� powy�sze fragmenty,zapewne dziwisz si� teraz, dlaczego nie wspominam tu o sze�ciu modelachPMLC. Jest to zwi�zane z faktem, �e modele xPM i MPx s� identyczne, a zatemistnieje tylko pi�� ró�ni�cych si� od siebie modeli. Ca�o�ciowy ogl�d sytuacjiprzedstawia rysunek 2.8.




104 Rozdzia 2.

Rysunek 2.8. Pi�� modeli PMLC

Je�eli przyjrze� si� poszczególnym modelom na poziomie grup procesów,mo�na dostrzec bardzo prosty schemat budowy ca�ego cyklu zarz�dzania pro-jektem. Zanim przejd� do dalszych uwag, chcia�bym si� odnie�� do stosowanejtu terminologii. W modelach APM i xPM pos�uguj� si� terminami iteracja,cykl i faza, które maj� pomaga� w odró�nianiu — odpowiednio — modeluiteracyjnego, adaptacyjnego i ekstremalnego. Rozró�nienie to b�dzie mipotrzebne w dalszych rozwa�aniach, aby nie by�o w�tpliwo�ci, do któregoz modeli si� akurat odnosz�. Aby� móg� jeszcze lepiej pozna� i zrozumie�modele PMLC, chcia�bym tu podkre�li� ich podobie�stwa i wyst�puj�cemi�dzy nimi ró�nice.

Podobie�stwa mi�dzy modelami PMLC

Mo�na wskaza� trzy podobie�stwa mi�dzy modelami:� We wszystkich modelach znalaz�o si� pi�� grup procesów.� Wszystkie modele PMLC zaczynaj� si� od grupy procesów zwi�zanych

z wyznaczaniem zakresu projektu.� Wszystkie modele PMLC ko�cz� si� grup� procesów zwi�zanych z zamy-

kaniem projektu.





Ró�nice mi�dzy modelami PMLC

Ró�nice mi�dzy modelami s� najlepiej widoczne w odniesieniu do stopnianiepewno�ci i niedookre�lenia rozwi�zania:� Stopie� niepewno�ci co do rozwi�zania wyznacza logiczn� kolejno��

stosowania modeli (model liniowy, stopniowy, iteracyjny, adaptacyjny,ekstremalny).

� Efekt rosn�cej niepewno�ci jest równie� widoczny w powtarzanychgrupach procesów — im wi�ksza niepewno��, tym bli�ej pocz�tku cykluzarz�dzania projektem znajduje si� pierwsza powtarzana grupa procesów.

� Im wi�ksza jest niepewno��, w tym wi�kszym stopniu kompleksowedzia�ania planistyczne s� zast�powane dzia�aniami bie��cymi.

� Im wi�ksza niepewno��, tym wi�ksza rola procesów zwi�zanych z zarz�-dzaniem ryzykiem.

� Im wi�ksza niepewno��, tym wi�ksza potrzeba merytorycznego zaanga-�owania klienta.

Wybór najlepiej dopasowanego modelu PMLC

Wybór i adaptacja najlepiej dopasowanego modelu PMLC to decyzja subiek-tywna, podejmowana na podstawie wielu czynników. Ca�y proces decyzyjnyzosta� przedstawiony na rysunku 2.9.

Szczegó�owe informacje na temat modeli PMLC przedstawiam w cz��ci drugiej.Na razie wystarczy, je�li b�dziesz mia� �wiadomo��, �e sam wybór konkretnejmetodyki nie oznacza jeszcze, �e jeste� gotowy do rozpocz�cia prac nad projek-tem. Musisz uwzgl�dni� okre�lone czynniki wewn�trzne i zewn�trzne, a nast�p-nie dokona� ko�cowej korekty i modyfikacji wybranej metody. Wszystkie tezagadnienia zostan� omówione w cz��ci drugiej.

Zaufanie pok�adane w opracowanej strukturze RBS oraz stopie� kompletno-�ci struktury WBS mog�y spowodowa�, �e podj�cie decyzji w kwestii wyborunajlepiej dopasowanej metody oraz najlepiej dopasowanego modelu PMLCby�o relatywnie �atwe. Problem w tym, �e zanim przyst�pisz do realizacji pro-jektu, b�dziesz musia� si� jeszcze napracowa�. Po pierwsze, musisz dokona�oceny ewentualnych skutków oddzia�ywania innych czynników, które zosta�yopisane poni�ej. Po drugie, musisz uwzgl�dni� to oddzia�ywanie, wprowa-dzaj�c niezb�dne modyfikacje do wybranej metody. Modyfikacje te opisuj�w rozdzia�ach 10., 11. i 12. Czynniki, które mam tu na my�li, mog� mie�wp�yw na Twoj� decyzj� w kwestii najlepiej dopasowanego modelu PMLC —mog� nawet t� decyzj� zmieni�. Je�eli dany model PMLC wymaga na przy-k�ad merytorycznego zaanga�owania klienta, a z Twoich dotychczasowychdo�wiadcze� wynika, �e Twój klient nie jest skory do wspó�pracy, b�dzieszmusia� jako� rozwi�za� ten problem — ró�ne mo�liwo�ci dost�pne w takiej




106 Rozdzia 2.

Rysunek 2.9. Proces wyboru modelu PMLC

sytuacji zostan� omówione w cz��ci drugiej. Na razie przyjrzymy si� wspo-mnianym wy�ej innym czynnikom oraz ich potencjalnemu oddzia�ywaniu namodel PMLC.

Ca�kowity kosztIm wy�szy ca�kowity koszt realizacji projektu, tym wy�sza ko�cowa warto��biznesowa i tym wi�ksze ryzyko zwi�zane z projektem. Bez wzgl�du na to,jaki model PMLC wybra�e�, warto po�o�y� nieco wi�kszy nacisk na plan zarz�-dzania ryzykiem, ni� normalnie wymaga�by tego dany model. Je�eli zarz�dza-nie ryzykiem nie nale�y jeszcze do obowi�zków konkretnego cz�onka zespo�uprojektowego, koniecznie usu� to niedopatrzenie. Straty wykazuj� dodatni�korelacj� z ca�kowitym kosztem projektu, w zwi�zku z czym da si� uzasadni�konieczno�� ponoszenia wi�kszych wydatków na ograniczenie ryzyka, ni�trzeba by przewidzie� w przypadku ta�szego projektu.





Czas trwania projektuD�u�sze projekty charakteryzuj� si� wi�kszym stopniem nara�enia na zmiany,wy�szy wskanik rotacji pracowników oraz korekty priorytetów projektowych.�aden z tych czynników nie ma korzystnego wp�ywu na projekt, powiniene�zatem po�wi�ci� wi�cej uwagi swojemu planowi zarz�dzaniami zmianamiprojektu oraz bankowi zakresów. Bank zakresów to zbiór wszystkich niezre-alizowanych pomys�ów zmian oraz ca�kowitego czasu niezb�dnego na ichintegracj� z rozwi�zaniem. Zadbaj o to, aby klient rozumia� konsekwencjezwi�zane z bankiem zakresu i potrafi� zarz�dza� swoimi wnioskami o zmian�zakresu projektu. Wysoki wskanik rotacji pracowników zatrudnionych przyprojekcie mo�e by� niezwykle problematyczny, powiniene� wi�c po�wi�ci�sporo uwagi wszelkim dzia�aniom, które pozwol� t� rotacj� ograniczy�. Zmianypriorytetów projektowych pozostaj� natomiast poza Twoj� kontrol�. Jedyn�rzecz�, któr� kontrolujesz, jest harmonogram realizacji prac, który powinienby� mo�liwie agresywny.

Stabilno�� rynkuKa�de przedsi�wzi�cie realizowane na rynku charakteryzuj�cym si� du��zmienno�ci� ju� z samej swej natury jest bardzo ryzykowne. Mo�esz od�o�y�realizacj� takiego projektu do czasu ustabilizowania si� sytuacji rynkowej alboprzyst�pi� do pracy, zachowuj�c zwi�kszon� ostro�no��. Jednym ze sposobówna ochron� projektu jest w takiej sytuacji stopniowa implementacja rezulta-tów. Niez�ym pomys�em mo�e by� równie� skrócenie odst�pów mi�dzy im-plementacj� kolejnych wyników w stosunku do tego, co pierwotnie zak�adano.Wraz z implementacj� ka�dego kolejnego rezultatu powiniene� na nowopodejmowa� decyzj� o kontynuowaniu projektu lub od�o�eniu go w czasie.

TechnologiaWszyscy zdajemy sobie spraw�, �e zmiany technologiczne zachodz� corazszybciej. Trudno jest nie tylko za nimi nad��y�, lecz równie� mo�liwie naj-skuteczniej je wykorzystywa�. Je�eli bie��ca technologia przynosi oczekiwaneprzez Ciebie skutki, trzymaj si� jej. Je�eli na horyzoncie pojawia si� co� nowego,co pozwoli Ci zyska� przewag� na rynku, by� mo�e powiniene� poczeka� nat� technologi� — pami�taj jedynie, aby dobrze przygotowa� si� do jej wdro-�enia. Pami�taj, �e konkurencja nie �pi, liczy si� zatem czas reakcji.

Klimat biznesowyIm bardziej zmienny jest klimat biznesowy, tym krócej powinien trwa� ca�yprojekt. W przypadku projektów APM krótsze ni� zwykle powinny by� rów-nie� kolejne cykle. W warunkach zmiennego klimatu biznesowego na znacze-niu zyskuje stopniowe ujawnianie rozwi�zania.




108 Rozdzia 2.

Liczba dzia�ów, na które oddzia�uje projektWraz ze wzrostem liczby dzia�ów pozostaj�cych pod wp�ywem realizowanegoprojektu zmienia si� jego dynamika. Zmiana ta jest ju� widoczna na etapiegromadzenia informacji na temat wymaga�. B�dziesz musia� uwzgl�dni�potrzeby kilku ró�nych dzia�ów. Oto kilka kwestii, które powiniene� wzi��w zwi�zku z tym pod uwag�:� Pierwszym potencjalnym skutkiem tej sytuacji jest wyst�pienie chochlika

zakresu. Ka�dy dzia� przedstawi swoj� list� „niezb�dnych elementów”i „elementów niemile widzianych”. Oczywi�cie, pro�by zg�oszone przezposzczególne dzia�y nie musz� by� ze sob� zgodne — wszystkie ewen-tualne sprzeczno�ci i rozbie�no�ci b�d� powodowa� powstanie cho-chlików zakresu. W takiej sytuacji warto rozwa�y� podzia� projektu nawersje, czyli na kilka mniejszych projektów, prowadz�cych do uzyska-nia rozwi�zania w ró�nych wersjach.

� Drugim potencjalnym skutkiem jest wi�ksza cz�stotliwo�� wyst�powa-nia sprzeczno�ci mi�dzy potrzebami zg�aszanymi przez poszczególnedzia�y. Rozwi�zywanie tego rodzaju konfliktów jest jednym z elementówweryfikacji wymaga� projektu.

� Trzeci potencjalny skutek jest zwi�zany z modelem PMLC. Projekty,które obejmuj� wi�ksz� cz�� lub ca�o�� organizacji, cz�sto staj� si� pro-jektami realizowanymi przez wi�ksz� liczb� zespo�ów projektowych. Je�elitaka sytuacja b�dzie mia�a miejsce, zrodzi pewne wa�ne konsekwencje —zagadnienie to zostanie omówione w rozdziale 17.

Uwarunkowania organizacyjneJe�eli Twoja firma stosunkowo cz�sto wprowadza zmiany i dokonuje reorga-nizacji obowi�zków przypisanych przedstawicielom najwy�szego kierownictwa(na przyk�ad raz w tygodniu), to jest to dla Ciebie spory problem. Z kilkuostatnich bada� prowadzonych przez firm� Standish Group wynika, �e naj-cz��ciej podawanym powodem pora�ek projektów jest brak wsparcia ze stronynajwy�szego kierownictwa. Mo�e to mie� zwi�zek mi�dzy innymi z prowa-dzon� reorganizacj�. Wyobra sobie na przyk�ad, �e dotychczasowy sponsorTwojego projektu, który by� gor�cym zwolennikiem jego realizacji i Twoimmentorem, zosta� nagle zast�piony kim� innym. Czy Twój nowy sponsorb�dzie post�powa� tak samo? Je�eli tak, to masz szcz��cie, a je�eli nie, to maszpowa�ny problem. B�dziesz musia� zweryfikowa� list� potencjalnych zagro�e�i przedstawi� propozycje strategii zwi�zanych z ograniczaniem ich skutków.





Umiej�tno�ci i kompetencje zespo�u projektowegoW planie realizacji projektu formu�ujesz pro�b� o przydzielenie Ci kompe-tentnych fachowców, nie oznacza to jednak, �e ostatecznie w�a�nie takich ludzidostaniesz. Czasami ma si� wra�enie, �e dost�pno�� pracownika jest uzna-wana za jedn� z jego kompetencji. Kiedy sam formu�uj� propozycj� wymaga�projektu, prosz� w tym dokumencie o nieco mniej kompetentnych ludzi,a nast�pnie wychodz� z za�o�enia, �e w�a�nie tacy pracownicy zostan� mi przy-dzieleni. Wnioskowanie o najlepszych ludzi prowadzi jedynie do rozczarowa�,kiedy ju� oka�e si�, �e zespó� projektowy sk�ada si� z ludzi drugiego, a nawettrzeciego garnituru. Co do zasady projekty TPM mog� by� realizowane przezzespó� z�o�ony z ludzi o przeci�tnych kompetencjach, którzy nie musz� nawetpracowa� w tym samym miejscu. Projekty APM to ju� inna historia, poniewa�w ich przypadku stosuje si� dwa ró�ne modele PMLC. Kiedy nie znasz cz��cicech rozwi�zania, do realizacji projektu powinni wystarczy� przeci�tnie kompe-tentni ludzie pracuj�cy pod nadzorem. Kiedy natomiast brakuje informacji natemat cz��ci funkcji rozwi�zania, preferowan� opcj� jest zespó� z�o�ony z naj-bardziej kompetentnych pracowników (cho� mog� by� oni wspomagani przezkilka mniej kompetentnych osób pracuj�cych pod nadzorem). Im mniej wieszna temat rozwi�zania, tym wi�cej potrzebujesz najlepszych ludzi — ludzi, którzymog� pracowa� samodzielnie, bez Twojego nadzoru.

Podsumowanie

Definicja ogólnego obrazu projektu jest mojego i tylko mojego autorstwa.Lubi� proste i intuicyjne uj�cia i moja definicja znakomicie spe�nia te warunki.Obejmuje ona równie� absolutnie wszystkie projekty, które dotychczas wyko-nano i które b�d� realizowane w przysz�o�ci, nie widz� wi�c najmniejszegopowodu, aby j� kiedykolwiek zmienia�! Chc� przez to powiedzie�, �e definicjata mo�e stanowi� fundament do wszelkich dalszych rozwa�a� nad modelamiPMLC. Podej�cie to ma w sobie sporo charakteru akademickiego i teoretycz-nego — mo�na wr�cz powiedzie�, �e stanowi zal��ek zarz�dzania projektamijako odr�bnej dziedziny wiedzy. Jednocze�nie definicja ta ma bardzo prostei praktyczne zastosowanie. Stanowi ona podstaw� do podejmowania decyzjiw kwestii wyboru najlepiej dopasowanych metod zarz�dzania projektem. Pod-czas lektury kolejnych rozdzia�ów przekonasz si�, �e b�d� rozwija� ten fun-dament zarówno na p�aszczynie teoretycznej, jak i praktycznej.

Pos�uguj�c si� ogólnym obrazem projektu jako podstaw� zarz�dzania pro-jektami, sformu�owa�em pi�� modeli PMLC na poziomie uszczegó�owieniaodpowiadaj�cym grupom procesów. Poszczególne definicje tych modeli daj�jasny i intuicyjny obraz ró�nic mi�dzy dost�pnymi metodykami — ró�nicete s� zwi�zane ze stopniem niepewno�ci. W ramach poszczególnych modeliPMLC funkcjonuje wiele konkretnych wariantów. Wszystkie zostan� szcze-gó�owo omówione w rozdzia�ach 10., 11. i 12.




110 Rozdzia 2.

Pytania do dyskusji

1. Wyobra sobie metodyk� zarz�dzania projektami, która uwzgl�dnia jedy-nie sze�� kwestii poruszonych w sekcji „Podstawy zarz�dzania projek-tami”, stanowi�cej element tego rozdzia�u. Od mened�era projektu i klientaoczekuje si� wy��cznie odpowiedzi na te sze�� pyta�. Czy taka metodasprawdzi si� w praktyce? Je�eli tak, to jak mo�esz j� zastosowa�? Je�eliuwa�asz, �e metoda ta si� nie sprawdzi, uzasadnij swoje stanowisko.

2. Porównaj definicj� zarz�dzania projektami sformu�owan� przez PMIoraz definicj� skoncentrowan� na warto�ci biznesowej i dokonaj ichanalizy. Przedstaw list� wad i zalet obu tych definicji.

3. Dla ka�dego z pi�ciu modeli PMLC wska� konkretne punkty, w którychniezb�dne jest zaanga�owanie klienta. Jakie dzia�ania podj��by� jakomened�er projektu, aby zapewni� sobie to zaanga�owanie?

4. Okre�l, gdzie w ramach poszczególnych modeli PMLC spodziewa�by�si� najwi�cej pora�ek. Uzasadnij odpowied.

5. Okre�l, gdzie w ramach poszczególnych modeli PMLC spodziewa�by� si�najwi�kszego ryzyka. Jakie dzia�ania ograniczaj�ce to ryzyko wzi��by� poduwag�? Uzasadnij odpowied.

6. Dla ka�dego z pi�ciu modeli PMLC podaj przyk�ad projektu, nad którymsam kiedy� pracowa�e�, a który odpowiada�by definicji danego modelu.Czy zastosowanie odpowiedniego modelu PMLC w przypadku tych pro-jektów poprawi�oby ich rezultaty? Uzasadnij odpowied.

Analiza przypadku. Szybka Pizza (SP)

Jaki model PMLC zastosowaby� w przypadku poszczególnych podsystemów (przyjmowaniezamówie�, przetwarzanie zamówie�, logistyka, nawigacja, zarz�dzanie zapasami, lokalizacjapunktów produkcyjnych)? Uzasadnij odpowied�.




SKOROWIDZ

AAC, Actual Cost, 358ACWP, 359adaptacyjna struktura projektu, Patrz APFadaptacyjne tworzenie oprogramowania, Patrz

ASDadaptacyjny model DSDM, 514adaptacyjny model PMLC, 97, 470–521

APF, 481ASD, 479cechy, 475DSDM, 515monitorowanie i kontrola, 473planowanie, 473rozpoczynanie, 473Scrum, 518stosowanie, 519wady, 477wyznaczanie zakresu, 472zalety, 476

agentdrugoplanowy, 177pierwszoplanowy, 177

AITP, 20akceptacja dla projektu, 279akceptacja rezultatów

formalna, 377nieformalna, 377

aktualizowanieharmonogramu, 206informacji, 347

alokacjafunkcji, 429zasobów, 497

analityka biznesowa, BA, 793analiza

finansowa, 194, 649kosztów i korzy�ci, 195luki, 681modelu CPIM, 677Pareto, 699pola si�, 702progu rentowno�ci, 195przyczyn ród�owych, 695przypadku, 39ryzyka, 125, 132, 194, 648skutków zmiany zakresu, 59SWOT, 733sytuacji bie��cej, 723warto�ci uzyskanej, EVA, 356, 721

AOA, activity-on-the-arrow, 259AON, activity-on-the-node, 259APF, adaptive project framework, 31, 75, 95,

449, 481, 491bank zakresów, 505budowa cyklu, 501implementacja, 512informacja o efektach prac, 484introspekcja, 484metody szeregowania, 488mikrozarz�dzanie, 495odmiany, 511





APF, adaptive project frameworkorientacja na klienta, 483plan cyklu, 494planowanie, 485przegl�d rezultatów wersji, 509punkt kontrolny klienta, 503, 507tory p�ywackie, 506wspó�udzia� klienta, 483zakres wersji, 485, 487

APM, agile project management, 79, 84, 91–97,447–525, 650adaptacyjny model PMLC, 470definiowanie zakresu, 521efektywne wykorzystanie, 521iteracyjny model PMLC, 455monitorowanie i kontrola, 523planowanie, 522rozpoczynanie, 523zamykanie, 524

APPM, agile project portfolio management,650–661cykl procesu, 653etapy, 654niepewno��, 656szybkie zmiany, 656

arkusz PQM, 674ASD, 479

faza spekulacji, 479faza wspó�pracy, 479faza wyci�gania wniosków, 479

asystent techniczny, 213audyt powdro�eniowy, 381, 643

BB2C, business-to-consumer, 542bank zakresów, 318, 364, 505BCG, Boston Consulting Group, 613BCWP, 359BCWS, 359biuro programów, 560

sta�e, 52tymczasowe, 52

biuro projektów, Patrz PO, 752biuro wsparcia projektów, Patrz PSO, 557–602biuro wsparcia projektów przysz�o�ci, 599BP4SO

analityka biznesowa, 599informatyka, 599procesy biznesowe, 599zarz�dzanie projektami, 599

BPI, business process improvement, 692BPM, business process management, 793budowa cyklu, 500, 502budowanie

konsensusu, 308zrównowa�onego portfela, 625

bud�et projektu, 55bufory

kosztowe, 439ograniczonych mo�liwo�ci, 439projektu, 438sekwencji, 438werblowe, 439zasobów, 439

burza mózgów, 308

CCCPM, 432, 435cechy projektu, 62, 180cel

projektu, 536spotkania inicjuj�cego, 295

celekierunkowe, 49ogólne, 49PSO, 566

centralne twierdzenia graniczne, 433CF, critical factors, 672chochlik

cech, 60nadziei, 60wysi�ków, 60zakresu, 59

CMM, capability maturity model, 144, 585, 669CMMI, capability maturity model

integrated, 669COE, center of excellence, 600COP, community of practice, 600COS, conditions of satisfaction, 156, 183, 541CPI, cost performance index, 360, 638, 722CPIM, continuous process improvement

model, 664definicja BPI, 692dokumentacja, 691eliminowanie luki, 692kontrola wyników, 684macierz jako�ci procesów, 672mapa strefowa, 672monitorowanie wskaników, 690ocena i analiza, 677, 681




SKOROWIDZ 813

poziomy dojrza�o�ci procesów, 669procesy biznesowe, 685prognozowanie stanu przysz�ego, 692program doskonalenia, 683stosowanie, 679struktura, 679

CPS, Creative Problem Solving, 301CT, core team, 758

charakterystyka, 759–762cz�onkowie, 760korzystanie, 765wady, 764zalety, 762

CV, cost variance, 359cykl, 493, 498, 521, 538

realizacji APPM, 653realizacji projektu portfelowego, 609sprint, 516szacowania, 248zarz�dzania projektem, 84

czaspracy, 240realizacji, 55, 107, 116, 538trwania dzia�ania, 240, 243

efektywno�� czasu pracy, 243ilo�� wykorzystanych zasobów, 241nieoczekiwane zdarzenia, 243prognozowanie, 244zaanga�owanie osób, 243zmienno�� statystyczna, 244

trwania pierwszego cyklu, 543trwania projektu, 434

cz�stotliwo�� raportowania, 348cz��ciowe finansowanie, 635cz�onkowie

CT, 760PSO, 580zespo�u, 286, 290, 572, 782

czynnikihigieniczne, 119motywuj�ce, 119, 120ryzyka, 192

Ddefinicja

biura projektu, 752biznesowa projektu, 51PMLC, 79portfela projektów, 52projektu, 48

projektu wielozespo�owego, 741projektu zagro�onego, 710PSO, 560superzespo�u, 766wymaga�, 73zarz�dzania projektami, 72zespo�u g�ównego, 759

definiowaniebie��cych potrzeb biznesowych, 731wymaganych zasobów, 251zakresu wersji, 486

deklaracja misji, 679deklaracja skutków dla projektu, PIS, 58, 90, 314dekompozycja, 230

departamentowa, 235dzia�a�, 230, 330fizyczna, 232funkcjonalna, 221, 233hierarchiczna, 221WBS, 229wed�ug celów cz�stkowych projektu, 234wed�ug obszarów geograficznych, 235wed�ug procesów biznesowych, 235wymaga�, 163, 165, 167

design-build-test-implement, 232diagram

Gantta, 233, 257, 350, 352Ishikawy, 695przep�ywu, 257przypadku u�ycia, 177sieci projektu, 256, 258, 334

czytanie, 261diagramowanie pierwsze�stwa, 259model punktów w�z�owych, 259model strza�kowy, 259nast�pnik, 260PDM, 260poprzednik, 260punkty w�z�owe, 260w�skie gard�a, 275w�ze� dzia�ania, 259zale�no�� koniec do ko�ca, 263zale�no�� koniec do pocz�tku, 261zale�no�� pocz�tek do ko�ca, 262zale�no�� pocz�tek do pocz�tku, 262

wypalania, 351diagramy kontekstowe, 173dojrza�o�� procesów i praktyk, 669dokumentacja, 379dokumentacja procesu biznesowego, 691





doradztwo, 561, 572doskonalenie

praktyki i procesu, 664procesów biznesowych, 694

dostarczanie rezultatów, 378jednostka po jednostce, 379równoleg�e, 379stopniowe, 378szokowe, 378

dostawca, 135–149dost�pno�� zasobów

maksymalna, 328planowanie mikropoziomowe, 333

DPMA, 20DSDM, Dynamic Systems Development

Method, 513dyrektor, 787dzia�ania

niepowtarzalne, 48powi�zane, 49�cie�ki krytycznej, 268z�o�one, 49

dzia�anie, 48, 219, 226czas realizacji, 228definiowanie pocz�tku i ko�ca, 228definiowanie rezultatu, 228koszt realizacji, 228niezale�no��, 229podzielne, 274stan zaawansowania, 227

dzielenie zasobów, 749dziewi�� obszarów wiedzy, 115

Eekstremalne zarz�dzanie projektami, Patrz xPMekstremalny model INSPIRE, 533–547ekstremalny model PMLC, 100, 530

cechy, 531wady, 533zalety, 532

elastyczny model projektu, 533elementy sk�adowe POS, 185–193

opis celów cz�stkowych, 189opis celu g�ównego, 187opis kryteriów sukcesu, 190opis problemu, 185opis w�tpliwo�ci, 192

EPSO, Enterprise PSO, 577scentralizowane, 577zdecentralizowane, 577

eskalacja problemówstrategie zapobiegania, 370, 371zapobieganie na poziomie

klienta, 370mened�era projektu, 370mened�era zasobów, 370

etapyprojektu INSPIRE, 535wzrostu PSO, 584zarz�dzania portfelem, 608

EV, Earned Value, 358EVA, earned value analysis, 356–359

Ffazy ASD, 480FDD, feature-driven development, 420FFP, firm fixed price, 143filtrowanie informacji, 324formaty diagramów procesów biznesowych, 172formu�owanie oczekiwa�, 146FTE, full-time equivalent, 767funkcje PSO, 566

Ggenerowanie warto�ci biznesowej, 73grupa procesów, 79, 84, 443

monitorowania i kontroli, 114planowania, 113rozpoczynania, 114wyznaczania zakresu, 112, 154zamykania projektu, 115

Hharmonogram

cyklu, 498dzia�a�, 217kosztów, 638pracy, 217projektu, 217, 257, 268, 330

odchylenie, 357, 358�cie�ka bliska krytycznej, 272�cie�ka krytyczna, 270termin najwcze�niejszego ko�ca, 269termin najwcze�niejszego pocz�tku, 269wskanik realizacji, 360zapas czasu dzia�ania, 271

terminów najpóniejszych, 268, 270terminów najwcze�niejszych, 268, 436zasobów, 326, 334




SKOROWIDZ 815

hierarchizacjaprojektów, 618

kryteria wa�one, 622model porównywania parami, 623niezb�dne, wa�ne, przydatne, 621Q-sort, 620ryzyko-korzy�ci, 624wymuszony ranking, 619

wymaga� projektu, 542, 547histogram, 699histogram w analizie Pareto, 700historia

czasów trwania zada�, 413ryzyka, 414wniosków, 412zarz�dzania, 442

HRMS, human resource management system,103, 454

Iidentyfikacja

CF, 679procesów biznesowych, 679ryzyka, 126wymaga�, 166, 169

IIBA, 73implementacja APF, 512informacje o efektach prac, 227, 484informatyka, IT, 793inicjacja, 535inkubacja, 544INSPIRE, 533–547

etap inicjacji, 535etap inkubacji, 544etap przegl�du, 546etap spekulacji, 540

integracja, 116danych, 362warto�ci uzyskanej, 361wykresów, 361

IRACIS, 71iteracje, 521iteracyjny model PMLC, 96, 454–470

cechy, 460etap monitorowania i kontroli, 459etap planowania, 457etap rozpoczynania, 459etap wyznaczania zakresu, 457etap zamykania, 460model prototypowy, 463

model RUP, 465–468stosowanie, 469wady, 462zalety, 461

JJAD, joint applications design, 211jako��, 117

procesu, 54produktu, 54

j�zyk UML, 176, 511JRP, joint requirements planning, 211

Kkamie� milowy, 351kategorie

inwestycyjne projektów, 617, 630projektów, 615zasobów, 249

klasyfikacja projektów, 62, 64, 180klient, 398kojarzenie personelu z dzia�aniami, 250kolejno�� dzia�a�, 268kompletowanie dokumentacji, 379komunikacja, 122, 397

poza zespo�eminteresariusze, 324

w zespole, 318bezpo�rednie spotkania, 320materia�y w formie pisemnej, 321poczta elektroniczna, 320telefon, 321wideokonferencje, 320

konflikt zasobów, 437konsultacje i opieka merytoryczna, 561, 567konsultant do spraw planowania

projektowego, 213kontrola projektu, 258konwencje diagramowania, 261korzy�ci biznesowe, 643koszt

kontraktu, 144projektu, 55, 116, 253, 332, 538

prognoza bud�etowa, 254prognoza definitywna, 254prognoza rz�du wielko�ci, 254

kosztyodchylenie, 358rzeczywiste, 255, 358wskanik realizacji, 360





kryteriakompletno�ci WBS, 226, 230wa�one, 622

krzywa„S”, 356bólu, 203AC, 360EV, 360PV, 360zaawansowania, 357

ksi�ga projektów, 217

Lliczba

cykli, 493wymaga�, 75

limity zasobów, 50liniowy model PMLC, 89, 409–424

cechy, 410efektywne wykorzystanie, 423stosowanie, 420wady, 417wariant FDD, 421wariant szybki, 420zalety, 415

lista rodzajów ryzyka, 128LSI, learning styles inventory, 291luka dojrza�o�ci, 681

�a�cuch krytyczny, 432

Mmacierz

BCG, 613dystrybucji projektów, 615, 629–631jako�ci procesów, 672modeli PMLC, 80, 391OZWDI, 795rankingowa trójk�ta zakresu, 490ryzyka, 131ryzyko-korzy�ci, 624, 630, 634umiej�tno�ci, 250wykorzystania bufora, 441

maksymalna dost�pno�� zasobów, 328mapa strefowa, 672, 673, 675mapowanie obszarów wiedzy, 150maska zachowa�, 294

MBO, management by objectives, 605mened�er

dzia�ania, 335odpowiedzialny za projekt, 213pakietu roboczego, 335portfela, 611, 644programu, 786projektu, 213, 285, 637

analityka biznesowa, BA, 793informatyka, IT, 793zarz�dzanie procesami biznesowymi,

BPM, 793zarz�dzanie projektami, PM, 793

ST, 768zadania, 783

metodakolejnych ulepsze�, 221�a�cucha krytycznego, 431

historia zarz�dzania, 442odchylenia naturalne, 433odchylenia specjalne, 433opónienie dzia�ania na �cie�ce

krytycznej, 440prognoza przedzia�owa, 434prognoza punktowa, 434przekszta�canie harmonogramu

terminów, 436zakres swobody, 434zarz�dzanie buforami, 439

pseudokodu, 221metody

APM, 91dekompozycji wymaga�, 167dostarczania rezultatów, 378gromadzenia wymaga�, 747MPx, 101PSO, 569szeregowania

MoSCoW, 490porównanie w parach, 490wymuszony ranking, 489

TPM, 86xPM, 97

mikrozarz�dzanie, 229, 495minimalizowanie ryzyka, 133m�odszy mened�er, 784model

ci�g�ego doskonalenia procesów, Patrz CPIMcyklu zarz�dzania projektem, Patrz PMLCdojrza�o�ci organizacyjnej, 669




SKOROWIDZ 817

dojrza�o�ci zarz�dzania projektami, 566,585

DSDM, 96ewolucyjny kaskadowy, 96oceny dojrza�o�ci zarz�dzania projektami,

673PMLC dla procesu APPM, 654podejmowania decyzji, 303porównywania parami, 623projektuj-buduj-testuj-wdra�aj, 234prototypowy, 465punktów w�z�owych, 259RUP, 96Scrum, 96selekcji Grahama-Englunda, 616, 630, 658strza�kowy, 259twórczego pokonywania problemów, 301wzrostu i przetrwania, 616zgodno�ci strategicznej, 627

alokacja zasobów, 613cele cz�stkowe, 612cele g�ówne, 612taktyki, 612warto��, 611

modele PMLC, 79, 85, 103, 443, 740adaptacyjny, 97, 471ekstremalny, 100, 530emertxe, 548, 549iteracyjny, 96, 455liniowy, 89, 409stopniowy, 91, 425

moderowane sesje grupowe, 168monitorowanie

i kontrola, 114, 341–373, 473, 551prac i post�pów, 146ryzyka, 134

MPx, emertxe project management, 79, 84,101–103, 548–552

Nnajlepsze praktyki, 264narz�dzia

graficznediagram Gantta, 350diagram wypalania, 351raport-semafor, 351wykres trendu odchyle�, 351

informatyczne, 561, 570planistyczne, 206

narz�dziePERT, 206Visio, 499

nazwy biur, 564negocjacje kontraktowe, 145niepe�ne obsadzanie projektów, 635niepewno��, 390, 532, 656NPK, termin najpóniejszego ko�ca, 269NPP, termin najpóniejszego pocz�tku, 269NWK, termin najwcze�niejszego ko�ca, 269NWP, termin najwcze�niejszego pocz�tku, 269

Oobliczanie �cie�ki krytycznej, 270ocena

dostawców, 139kompetencji mened�era projektu, 591kompletno�ci RBS, 179odpowiedzi, 141ryzyka, 128zgodno�ci strategicznej projektu, 618

odchyleniagwa�towne, 354naturalne, 433negatywne, 349od planu, 346, 348pozytywne, 349specjalne, 433

odchylenieharmonogramu, 357, 358kosztu, 357, 359standardowe, 353

ograniczanie ryzyka, 133ograniczenia

czasowe, 266logiczne, 264mi�dzyprojektowe, 266produktowe, 179swobodne, 263techniczne, 263zwi�zane z zarz�dzaniem, 265

opisy, 541opónienia

od planu, 354sukcesywne, 353

opónienie dzia�ania na �cie�ce krytycznej, 440opracowywanie struktury WBS, 717oprogramowanie, 205





Ppakiet roboczy, 220, 236

arkusz przydzia�u, 337cel, 335format, 336raport, 338

PCS, process control system, 408PDM, precedence diagramming method, 259PDP, professional development program, 789PDS, project definition statement, 212, 298pi�� grup procesów, 112PIS, 58, 90, 314plan

naprawczy, 733pracy, 337rozwoju zawodowego, 775, 788

aktywno�� profesjonalna, 778bezpo�rednie szkolenie praktyczne, 777po�rednie szkolenie praktyczne, 777zdobywanie do�wiadczenia, 777

utworzenia PSO, 586wdro�enia PSO, 597

planowanie, 113, 473, 485bie��ce, 475cyklu INSPIRE, 545cyklu APF, 496fazy, 550kariery zawodowej, 792mikropoziomowe, 333póniejszych cykli, 543projektu, 201–282

narz�dzia, 207sesja planistyczna, 209

zasobów, 252planowany koszt

planowanej pracy, 359wykonanej pracy, 359

PMBOK, 33, 43, 299PMCA, Project Manager Competency

Assessment, 591PMI, Project Management Institute, 19, 33, 68PMLC, project management life cycle, 30, 71,

84, 712PMMA, project management maturity

assessment, 673PMMM, Project Management Maturity

Model, 566, 570, 585PMO, project management office, 412PMP, Project Management Professional, 571

PO, project office, 752charakterystyka, 753korzystanie, 758wady, 757zalety, 755

poczta elektroniczna, 320podejmowanie decyzji

model 6-etapowy, 305model dyrektywny, 303model konsultacyjny, 303model partycypacyjny, 303

podej�cie z góry na dó�, 223podsystem

logistyczny, 41lokalizacji punktów produkcyjnych, 40nawigacji, 41przetwarzania zamówie�, 40przyjmowania zamówie�, 40zarz�dzania zapasami, 41

podzespó�, 333podzia� wymaga�, 77pokonywanie problemów, 300pora�ki projektów, 397, 578–583, 711–714portfel projektów, 52, 563, 605–661POS, project overview statement, 70, 157,

183–185akceptacja, 196elementy sk�adowe, 185kryteria akceptacji, 199za��czniki, 193

poszukiwanie sytuacji wygrany-wygrany, 307poziomowanie zasobów, 327, 500poziomy dojrza�o�ci procesów, 669–671PQM, process quality matrix, 672praktyka zarz�dzania projektami, 666prawa Murphy’ego, 243prawdopodobie�stwo

osi�gni�cia korzy�ci biznesowych, 624sukcesu technicznego, 624

priorytety zmiennych trójk�ta, 58proces

biznesowy, 170dekompozycji, 220dynamicznego zarz�dzania ryzykiem, 718gwarantowania jako�ci, 118interwencyjny, 723kontroli jako�ci, 118oceny dost�pnych opcji, 733planowania jako�ci, 117poziomowania zasobów, 327weryfikacji pierwotnego celu, 730




SKOROWIDZ 819

wyznaczania zakresu projektu, 156, 157zarz�dzania projektami, 664zarz�dzania zmianami zakresu, 718zarz�dzania zmian�, 316

procesy biznesowe, 679narz�dzia, 694narz�dzia usprawniania, 688skuteczno��, 687wydajno��, 687

prognozaprzedzia�owa, 434punktowa, 434

prognozowanieczasu trwania dzia�ania, 241

dane historyczne, 245podobie�stwo dzia�a�, 244rady ekspertów, 245technika 3 punktów, 247technika delficka, 245technika delficka u�redniaj�ca, 247

ilo�ci potrzebnych zasobów, 249kosztów projektu, 253stanu przysz�ego, 692

program, 51doskonalenia procesów, 663rozwoju zawodowego

aktywno�� profesjonalna, 790bezpo�rednie szkolenie praktyczne, 789po�rednie szkolenie praktyczne, 790struktura BA/PM, 791zdobywanie do�wiadczenia, 789

projekt, 23, 48APM, 93, 109BPI, 692MPx, 102TPM, 88, 109, 154–385

monitorowanie i kontrola, 341–373planowanie, 201–282uruchamianie realizacji, 283–340wyznaczanie zakresu, 154–200zamykanie projektu, 375–385

xPM, 98, 101projektu

cechy, 62cel ogólny, 49czas realizacji, 50, 55, 107harmonogram, 55hierarchizacja, 619klasyfikacja, 62koszt realizacji, 55, 106

limity zasobów, 50sekwencja dzia�a�, 48typy, 65wymagania, 72zakres, 54, 314zasoby, 56

projektyaktywne, 636badawcze, 617badawczo-rozwojowe, 548infrastrukturalne, 617operacyjne, 616opónione, 362, 363polegaj�ce na rozwi�zaniu problemu, 549portfelowe, 606przetrwania, 616taktyczne, 616utrzymania, 617wielozespo�owe, 741wprowadzaj�ce nowe produkty, 617wyprzedzaj�ce harmonogram, 363wzrostowe, 616zagro�one, 709, 711

analiza SWOT, 733analiza sytuacji bie��cej, 723analiza warto�ci uzyskanej, 721dynamiczne zarz�dzanie ryzykiem, 718dzia�ania koryguj�ce, 731, 732gromadzenie wymaga�, 716opracowywanie WBS, 717plan naprawczy, 733przyczyny pora�ek, 578, 711–714przyczyny ród�owe, 726–728strategie interwencyjne, 723strategie prewencyjne, 715szablon procesu interwencyjnego, 735zarz�dzanie zmianami zakresu, 718

strategiczne, 616propozycja projektu

format, 279tre��, 277

prototyp produkcyjny, 463przegl�d, 546przegl�d stanu projektu, 159przyczyny pora�ek, 397, 578–583, 711–714przypadki u�ycia, use case, 175, 511, 541przypisywanie zasobów, 217, 544PSO, project support office, 557–602

centralne, 575doradztwo, 561, 563, 572





etapy wzrostu, 584formu�owanie celów, 566funkcje, 566, 594funkcjonalne, 575konsultacje i opieka merytoryczna, 561,

567korporacyjne, 575, 577miejsce w organizacji, 576, 594misja, 565, 594narz�dzia informatyczne, 561, 570plan wdro�enia, 597–599powo�ane na czas okre�lony, 560, 575powo�ane na sta�e, 560, 575proaktywne, 574projekty zagro�one, 737reaktywne, 574regionalne, 575rzeczywiste, 574statut projektu, 588struktura organizacyjna, 574szkolenia, 561, 563, 570trudno�ci tworzenia, 596tworzenie metod i standardów, 561, 569wirtualne, 574wspieranie projektów, 561, 566zale�no�ci mi�dzyprojektowe, 575zarz�dzanie portfelem projektów, 644

punktkontrolny klienta, 503progowy zadania, 242

PV, Planned Value, 358

QQ-sort, 620

Rraport

Standish Group, 397, 578zamykaj�cy, 383

raportowanie, 748o odchyleniach, 345o post�pach

aktualizowanie informacji, 347cz�stotliwo��, 348dane historyczne, 347narz�dzia graficzne, 350odchylenia od planu, 348prognozy, 347

o stanie portfela, 637

CPI, 638SPI, 638wskanik realizacji harmonogramu,

638wskanik realizacji kosztów, 638wykresy trendu w punktach

kontrolnych, 638o stanie projektu, 221o wyj�tkach, 344

raportybie��ce, 343skumulowane, 344semafory, 344, 351

RBS, requirements breakdown structure, 75,163, 218, 220, 223

reakcje na zagro�enia, 134realne zarz�dzanie

cz�ste zmiany, 25niepewno��, 26ograniczanie kosztów, 26szybkie dzia�anie, 24wzrastaj�ca z�o�ono�� projektów, 26

regu�a S.M.A.R.T., 188, 537rejestr problemów, 365relacje

mi�dzy dzia�aniami, 257, 263zale�no�ci, 262

rezerwa mened�erska, 276, 317rodzaje

adaptacyjnych modeli PMLC, 478buforów, 438iteracyjnych modeli PMLC, 463kontraktów, 143projektów wielozespo�owych, 750raportów, 343ryzyka, 128

ROI, return on investment, 195rozpoczynanie Patrz tak�e uruchamianie

realizacji, 473rozpoczynanie fazy, 551rozrysowanie planowanych uj��,

storyboarding, 511rozwi�zywanie konfliktów

poszukiwanie sytuacji wygrany-wygrany,307

unikanie, 307walka, 307wspó�praca, 307

rozwój zawodowystruktura PM/BA, 788zespo�ów projektowych, 775




SKOROWIDZ 821

równowa�enie portfela, 626cz��ciowe finansowanie, 635model selekcji Grahama-Englunda, 630niepe�ne obsadzanie projektów, 635

równowa�enie zespo�ustyle uczenia si�, 291

RUP, Rational Unified Process, 464–467faza konstrukcji, 467faza opracowywania, 466faza przekazania systemu, 467Faza rozpocz�cia, 466

ryzyka, 126organizacyjne, 127techniczne, 126zewn�trzne, 127

ryzyko, 395analiza, 125arkusz analizy, 132czynniki, 129identyfikacja, 126monitorowanie, 134ocena, 127, 128ocena dynamiczna, 132ocena statyczna, 131ograniczanie, 133

rzeczywiste biura wsparcia projektów, 574rzeczywisty koszt wykonanej pracy, 359

SS.M.A.R.T., 189, 537schemat blokowy, 175, 698schemat restrykcyjny trendu, 720Scrum, 516SDPM, 30SEI, 584sekwencja dzia�a�, 48sesja

COS, 160, 162planowania projektowego, 210

asystent techniczny, 213kierownicy liniowi, 215konsultant, 213mened�er projektu, 213nadzorca procesu, 215plan sesji, 216prowadz�cy, 213przedstawiciel klienta, 214rezultaty, 217statut projektu, 212

zarz�dzaj�cy zasobami, 214zespó� projektowy, 214

planowania wymaga�, 211projektowania aplikacji, 211wspólnego planowania

tworzenie WBS, 226sie� relacji mi�dzy dzia�aniami, 257skracanie harmonogramu projektu, 273SLA, service level agreement, 686SME, subject matter experts, 141specyfikacja, 400specyfikacja funkcjonalna, 54spekulacja, 540SPI, schedule performance index, 360, 638–642,

722spis narz�dzi, 694sponsor projektu, 644spotkanie

dotycz�ce zakresucel, 160efekty, 162grupy, 161program, 161

inicjuj�ce, 294cel, 295definicja projektu, 297harmonogram projektu, 299miejsce, 296program sesji, 297uczestnicy, 296

monitoruj�cecel, 366cz�stotliwo��, 368lista uczestników, 366zakres zagadnie�, 367

zespo�u, 309spójno�� zespo�u, 396ST, super team, 766

charakterystyka, 767–769korzystanie, 772wady, 771zalety, 770

standardy PSO, 569stanowiska PM/BA, 779starszy mened�er, 785statut projektu, 212, 492, 646

ekstremalnego, 537opisy, 646POS, 157, 588za��czniki, 648





stopie�pewno�ci, 85skomplikowania, 390

stopniowy model PMLC, 91, 424–431cechy, 425efektywne wykorzystanie, 430stosowanie, 430wady, 427zalety, 425

strategia portfela, 610kategorie inwestycyjne projektów, 617macierz BCG, 613macierz dystrybucji projektów, 615model wzrostu i przetrwania, 616model zgodno�ci strategicznej, 611

strategieinterwencyjne, 710, 723prewencyjne, 715zapobiegania eskalacji problemów, 371

strukturaAPF, 485BA/PM, 791, 792biura projektu, 752, 753organizacyjna PSO, 574podzia�u pracy WBS, 217, 492, 717podzia�u wymaga� RBS, 75, 163, 218,

401, 492podzia�u zasobów, 251stanowisk PM/BA, 780superzespo�u, 766, 767zespo�u g�ównego, 758

studium wykonalno�ci, 194, 511style uczenia si�, 291, 293superzespó�, ST, 766SV, schedule variance, 358symbole schematu blokowego, 171system HRMS, 453szablon

analizy pola si�, 702analizy przyczyn ród�owych, 695czynników ryzyka, 130diagramu Ishikawy, 695identyfikacji ryzyka, 128procesu interwencyjnego, 735

szeregowanieprogramów doskonalenia, 682projektów, 634rezultatów, 543

szkolenia, 561, 570Szybka Pizza, 39

��cie�ka

bliska krytycznej, 272kariery, 792krytyczna, 270

Ttechnika

3 punktów, 247delficka, 246rozrysowania planowanych uj��, 511

technologia RFID, 103tech-temp, 289tempo zaawansowania prac, 356teoria

motywacji, 119ogranicze�, 431

TOC, Theory of Constraints, 431tor p�ywacki, 506TPM, traditional project management, 27, 79,

84, 86–91, 407–445, Patrz tak�e projekt TPMliniowy model PMLC, 409metoda �a�cucha krytycznego, 431stopniowy model PMLC, 424

tradycyjne zarz�dzanie projektami, Patrz TPMtrend

odchyle�, 351odchylenia gwa�towne, 354opónienia sukcesywne, 353przebieg sukcesywny, 355zmiany harmonogramu, 355

wskanika SPI, 642wskaników, 639

trening wra�liwo�ci, 294trójk�t zakresu projektu, 53, 56–59, 489, 539tworzenie

biblioteki szablonów, 411biur, 558biur programu, 52diagramu kontekstowego, 174diagramu procesu biznesowego, 169, 171diagramu sieci projektu, 256, 259harmonogramu, 257harmonogramu dzia�a�, 330harmonogramu projektu, 268harmonogramu terminów

najwcze�niejszych, 435harmonogramu zasobów, 326metod i standardów, 561, 569




SKOROWIDZ 823

modelu komunikacji, 319pakietów roboczych, 500planu cyklu, 545planu projektu, 204POS, 160prototypu rozwi�zania, 175PSO, 584, 586RBS, 162, 163, 166rejestru problemów, 365statutu projektu POS, 183strategii portfela, 610struktury zarz�dzania projektem, 746szczegó�owego planu, 210warunków satysfakcji, 156–159, 541WBS, 222, 231WBS metod� iteracyjn�, 225WBS na podstawie RBS, 218

twórcze pokonywanie problemów, 301typy

ogranicze� czasowych, 267projektów, 65wymaga�, 177

Uumiej�tno�ci, 250

kategorie, 251poziomy, 251

UML, unified modeling language, 175, 511uruchamianie realizacji, 114, 283–340us�ugi

BP4SO, 600PSO, 561

VVisio, 499

Wwarto�ci progowe wskaników, 704warto��

biznesowa, 71, 404planowana, 358uzyskana, 358WBS, 230

warunki satysfakcji COS, 156, 183, 541w�skie gard�a, 275WBS, work breakdown structure, 76,

218–220, 717kaskadowa metodyka rozwoju systemu, 239

planowanie, 221podej�cie czynno�ciowe, 232, 234podej�cie organizacyjne, 232, 234podej�cie przedmiotowe, 231prezentacja graficzna, 236projektowanie architektury, 221przyk�ad budowy domu, 237raportowanie o stanie projektu, 221stosowanie, 225testowanie kompletno�ci, 226

weryfikacja pierwotnego celu biznesowego, 730w�ze� dzia�ania, 260wideokonferencje, 320wirtualne biuro wsparcia projektów, 574wnioski z poprzedniego cyklu, 546wskanik

realizacji harmonogramu, 360, 638–642, 722realizacji kosztów, 358, 361, 638

wsparcie dla mened�erów projektu, 572wspieranie projektów, 561, 566wst�pny harmonogram projektu, 268wybór

cz�onków zespo�u, 290dostawcy, 141, 143modelu PMLC, 81, 105–108, 181, 579, 746modelu zarz�dzania projektem, 181, 230procesów biznesowych, 681struktury, 772zewn�trznego wykonawcy, 291zrównowa�onego portfela, 657

wydajno��, 205wykres

kontrolny, 697poziomów dojrza�o�ci procesu i praktyki,

677przebiegu pracy, 701punktowy, 702trendu, 639–641trendu odchyle�, 357, 361

wykrywanie odchyle�, 346wymagania, 164

funkcjonalne, 178globalne, 179niefunkcjonalne, 179projektu, 72–77

wymuszony ranking, 619, 629wynagrodzenie, 143wyznaczanie zakresu, 112, 154–200, 472wzór statutu projektu, 186





XxPM, extreme project management, 79, 84,

97–101, 529–547ekstremalny model INSPIRE, 533–547ekstremalny model PMLC, 530etap Incubate, 533etap INititate, 533etap REview, 533etap SPeculate, 533model emertxe PMLC, 548sprawdzanie koncepcji projektu, 539

Zzaanga�owanie klienta, 398, 472, 534zadanie, 220, 226

pakiet roboczy, 236punkt progowy, 242

zakontraktowanie dostawcy, 142zakres

fazy, 549prac, 54projektu, 54, 116, 314, 472projektu TPM, 153wersji

czas trwania cykli, 493liczba cykli, 493

zale�no�ci mi�dzy RBS a WBS, 231zale�no��

koniec do ko�ca, 263koniec do pocz�tku, 261pocz�tek do ko�ca, 262pocz�tek do pocz�tku, 262

zamykaniefazy, 552kontraktu z dostawc�, 149projektów w portfelu, 643projektu, 115, 375–385

akceptacja rezultatów, 377audyt powdro�eniowy, 381dostarczanie rezultatów, 378kompletowanie dokumentacji, 379raport zamykaj�cy, 383

zaopatrzenie, 135ocena dostawców, 139poszukiwanie dostawców, 135wybór dostawcy, 141zakontraktowanie dostawcy, 142zarz�dzanie relacjami z dostawc�, 146

zapas czasu dzia�ania, 271ca�kowity, 272swobodny, 271

zapytanie ofertowe, 135–137zarz�dzanie

aktywnymi projektami, 635, 660bankiem zakresów, 364buforami, 439chochlikami, 59czasem, 116eskalacj� problemów, 369integracj�, 116jako�ci�, 117komunikacj�, 122, 319, 323kosztami, 116oczekiwaniami klienta, 155portfelem projektów, 453, 605–661

aktywne projekty, 636budowanie zrównowa�onego portfela,

625cykl realizacji projektu, 609cz��ciowe finansowanie, 635etapy, 608funkcje PSO, 644hierarchizacja projektu, 619kategorie inwestycyjne projektów, 630kryteria wa�one, 627macierz dystrybucji projektów, 629macierz ryzyko-korzy�ci, 630mened�er portfela, 611model selekcji Grahama-Englunda, 630model zgodno�ci strategicznej, 627niepe�ne obsadzanie projektów, 635ocena zgodno�ci strategicznej, 618projekt aktywny, 610projekt odwo�any, 610projekt uko�czony, 610projekt uszeregowany, 609projekt wybrany, 610projekt zaproponowany, 609projekt zawieszony, 610projekt zgodny ze strategi�, 609przygotowanie projektu, 645przyznanie funduszy, 619raportowanie o stanie portfela, 637równowa�enie portfela, 626sk�adanie propozycji projektu, 649stan projektu, 636statut projektu, 646




SKOROWIDZ 825

strategia portfela, 610zamykanie projektów, 643zwinne, 650

procesami biznesowymi, BPM, 793projektami, 67, 69, 793

ekstremalne xPM, 29metoda �a�cucha krytycznego, 432tradycyjne TPM, 29zwinne APM, 29

projektami wielozespo�owymi, 743–750projektami zagro�onymi, 715przez cele, 605relacjami z dostawc�, 146rozwojem zawodowym, 775ryzykiem, 123skuteczne, 26zakresem, 116zaopatrzeniem, 135zasobami, 325zasobami ludzkimi, 118zmianami zakresu, 748

zasady pracy w zespole, 300zasoby, 56, 217, 325

ludzkie, 118, 249, 250maksymalna liczba jednostek, 328materia�y, 249pomieszczenia, 249�rodki pieni��ne, 249unikalne, 265wyposa�enie, 249

zastosowania WBS, 221zatwierdzanie statutu POS, 197zdobywanie informacji, 35zespo�owe zarz�dzanie problemami, 369

zespó�g�ówny, CT, 758klienta, 289projektowy, 214, 284

cz�stotliwo�� spotka�, 310komunikacja, 319koordynator spotkania, 310lista cech cz�onków, 287maska zachowa�, 294plan rozwoju, 293plan spotka�, 310protoko�y spotka�, 310selekcja cz�onków, 286trening wra�liwo�ci, 294zasady pracy, 300zrównowa�ony, 293

zintegrowany model dojrza�o�ciorganizacyjnej, 669

zlecanie zada�, 289zmiana, 402

harmonogramu, 355zakresu projektu, 314, 316

zmienne opónione, 267zmienno��, 531zwinne zarz�dzanie portfelem projektów,

Patrz APPMzwinne zarz�dzanie projektami, Patrz APMzwinny portfel, 652zwrot z inwestycji, 195




http://program-partnerski.helion.pl

Tytuł oryginału: Effective Project Management: Traditional ...pdf.helion.pl/efzap4/efzap4.pdf ·...

Documents

Transcript of Tytuł oryginału: Effective Project Management: Traditional ...pdf.helion.pl/efzap4/efzap4.pdf ·...