Efektywne zarz…dzanie projektami. Wydanie VI - Helion
Transcript of Efektywne zarz…dzanie projektami. Wydanie VI - Helion
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ść
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
8 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
10 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
12 Efektywne zarz�dzanie projektami
Zarz�dzanie buforami .................................................................................. 439Historia zarz�dzania projektami metod� �a�cucha krytycznego ........... 442
Podsumowanie .................................................................................................... 443Pytania do dyskusji ............................................................................................. 445
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
Podsumowanie .................................................................................................... 525Pytania do dyskusji ............................................................................................. 525
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
14 Efektywne zarz�dzanie projektami
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
Podsumowanie .................................................................................................... 602Pytania do dyskusji ............................................................................................. 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
Poleć książkęKup książkę
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
Podsumowanie .................................................................................................... 704Pytania do dyskusji ............................................................................................. 704
Poleć książkęKup książkę
16 Efektywne zarz�dzanie projektami
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
Podsumowanie .................................................................................................... 740Pytania do dyskusji ............................................................................................. 740
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
Poleć książkęKup książkę
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
Podsumowanie .................................................................................................... 772Pytania do dyskusji ............................................................................................. 773
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
Poleć książkęKup książkę
18 Efektywne zarz�dzanie projektami
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.
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
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-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 71
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:
Poleć książkęKup książkę
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-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 73
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
Poleć książkęKup książkę
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�-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 75
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 77
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.
Poleć książkęKup książkę
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-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 79
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�
Poleć książkęKup książkę
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
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 81
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.
Poleć książkęKup książkę
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�
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 83
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 85
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.
Poleć książkęKup książkę
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-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 87
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 89
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��.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 91
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 93
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.
Poleć książkęKup książkę
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�.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 95
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�.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 97
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
Poleć książkęKup książkę
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�.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 99
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
Poleć książkęKup książkę
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-
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 101
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 103
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 105
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 107
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
Czym jest zarz�dzanie projektami? 109
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.
Poleć książkęKup książkę
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�.
Poleć książkęKup książkę
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
Poleć książkęKup książkę
812 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
814 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
816 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
818 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
820 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
822 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
824 Efektywne zarz�dzanie projektami
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
826 Efektywne zarz�dzanie projektami
Poleć książkęKup książkę