Tytuł oryginału: Effective Project Management: Traditional, Agile, … · 2021. 3. 17. · Tytuł...

Tytuł oryginału: Effective Project Management: Traditional, Agile, Extreme, Seventh Edition

Tłumaczenie: Magda WitkowskaISBN: 978-83-283-3334-5

Copyright © 2014 by John Wiley & Sons, Inc., Indianapolis, Indiana

All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons. Inc

Translation copyright © 2017 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 szkodywynikł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/efzap7Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

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

Printed in Poland.

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

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

http://onepress.pl/rt/efzap7

http://onepress.pl/rf/efzap7

http://onepress.pl/ro/efzap7

http://onepress.pl

http://ebookpoint.pl/r/JH8P6

SPIS TREŚCI

O autorze ............................................................................17

Przedmowa ..........................................................................19

Wprowadzenie .....................................................................21

Część I. Zarządzanie projektami — podstawy 35

Rozdział 1. Czym jest projekt? ................................................................37Definicja projektu ................................................................................................ 38

Sekwencja działań ............................................................................................ 38Niepowtarzalne działania ............................................................................... 38Złożone działania ............................................................................................ 39Powiązane działania ........................................................................................ 39Jeden cel ............................................................................................................ 39Określony czas realizacji ................................................................................ 40Bez przekraczania budżetu ............................................................................. 40Zgodnie z wymaganiami ................................................................................ 40Biznesowa definicja projektu ..........................................................................41

Intuicyjne ujęcie wachlarza projektowego .........................................................41Czym jest program? .............................................................................................. 43Czym jest portfel projektów? .............................................................................. 44Poziom przedsiębiorstwa .................................................................................... 45Trójkąt zakresu projektu ..................................................................................... 45

Zakres ................................................................................................................ 46Jakość ................................................................................................................. 46Koszty ................................................................................................................ 47Czas .................................................................................................................... 47Zasoby ............................................................................................................... 48

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



4 Efektywne zarządzanie projektami

Ryzyko ............................................................................................................... 48Trójkąt zakresu projektu jako zrównoważony system ............................... 48Nadawanie priorytetów zmiennym trójkąta zakresu

pod kątem usprawnień w procesie zarządzania zmianą ......................... 50Trójkąt zakresu projektu w praktyce ............................................................. 50

Klasyfikowanie projektów i jego znaczenie .......................................................51Wskazywanie kryterium klasyfikacji projektów .......................................... 52Klasyfikacja według cech projektów ............................................................. 52Klasyfikacja według typów projektów .......................................................... 54

Współczesne otoczenie projektowe ....................................................................55Duża szybkość ...................................................................................................55Duża zmienność ...............................................................................................55Niższe koszty .....................................................................................................56Rosnący stopień skomplikowania ................................................................ 57Większa niepewność ........................................................................................ 57

Podsumowanie ...................................................................................................... 57Pytania do dyskusji ............................................................................................... 57

Rozdział 2. Czym jest zarządzanie projektami? .........................................59Podstawy zarządzania projektami .......................................................................61

Jaki problem biznesowy ma rozwiązać ten projekt? ....................................61Co będzie trzeba zrobić? ................................................................................. 62Co zostanie zrobione? ..................................................................................... 62Jak to zostanie zrobione? ................................................................................ 62Skąd będzie wiadomo, że to zostało zrobione? ............................................63Na ile skutecznie zostało to zrobione? ..........................................................63

Wyzwania związane ze skutecznym zarządzaniem projektami ......................65Elastyczność i dostosowywanie się .................................................................65Szeroka wiedza na temat firmy i jej systemów ............................................. 67Przejmij kontrolę nad projektem i zarządzaniem nim .............................. 67Zarządzanie projektami to uporządkowany zdrowy rozsądek ................. 68

Zarządzanie chochlikami .................................................................................... 68Chochlik zakresu ............................................................................................. 69Chochlik nadziei ............................................................................................. 69Chochlik wysiłków .......................................................................................... 69Chochlik cech .................................................................................................. 70

Czym tak naprawdę są wymagania projektu? ................................................... 70Modele cyklu zarządzania projektami — wprowadzenie ............................... 75

Metody tradycyjnego zarządzania projektami ............................................ 79Metody zwinnego zarządzania projektami ................................................. 84Metody ekstremalnego zarządzania projektami ......................................... 90Modele cyklu zarządzania projektem emertxe ............................................ 94Przegląd modeli PMLC .................................................................................. 96

Wybór najlepiej dopasowanego modelu PMLC .............................................. 97Całkowity koszt ............................................................................................... 98Czas trwania projektu ..................................................................................... 99Stabilność rynku .............................................................................................. 99




Spis treści 5

Technologia ...................................................................................................... 99Klimat biznesowy ...........................................................................................100Liczba działów, na które oddziałuje projekt ...............................................100Uwarunkowania organizacyjne ....................................................................100Umiejętności i kompetencje zespołu projektowego .................................. 101

Podsumowanie ..................................................................................................... 101Pytania do dyskusji ..............................................................................................102

Rozdział 3. Grupy procesów w ramach zarządzania projektami .................103Definiowanie pięciu grup procesów .................................................................104

Grupa procesów wyznaczania zakresu ........................................................104Grupa procesów planowania ........................................................................105Grupa procesów rozpoczynania ...................................................................106Grupa procesów monitorowania i kontroli ...............................................106Grupa procesów zamykania projektu ..........................................................107

Definiowanie dziesięciu obszarów wiedzy .......................................................107Zarządzanie integracją ...................................................................................108Zarządzanie zakresem ....................................................................................108Zarządzanie czasem ........................................................................................108Zarządzanie kosztami ....................................................................................108Zarządzanie jakością ......................................................................................109Zarządzanie zasobami ludzkimi .................................................................. 110Zarządzanie komunikacją ............................................................................. 111Zarządzanie ryzykiem .................................................................................... 112Zarządzanie zaopatrzeniem ..........................................................................123Zarządzanie relacjami z interesariuszami projektu ...................................137

Mapowanie obszarów wiedzy na grupy procesów ..........................................137Na czym polega mapowanie? ........................................................................138Jak korzystać z mapowania? ..........................................................................138Definiowanie modeli PMLC na podstawie grup procesów .....................138Spojrzenie w przyszłość — mapowanie grup procesów

w celu wyznaczenia złożonych modeli PMLC ........................................139Podsumowanie .....................................................................................................139Pytania do dyskusji ..............................................................................................139

Część II. Tradycyjne zarządzanie projektami 141

Rozdział 4. Wyznaczanie zakresu projektu TPM ......................................143Narzędzia, schematy i procesy stosowane

w wyznaczaniu zakresu projektu ...............................................................144Zarządzanie oczekiwaniami klienta .................................................................145

Odróżnianie potrzeb od zachcianek ...........................................................145Proces wyznaczania zakresu projektu ..........................................................146Spotkanie dotyczące zakresu projektu ........................................................149Efekty spotkania dotyczącego zakresu projektu ........................................152

Podsumowanie ..................................................................................................... 181Pytania do dyskusji .............................................................................................. 181





Rozdział 5. Planowanie projektu TPM ....................................................183Narzędzia, schematy i procesy w planowaniu projektu .................................184Znaczenie planowania ........................................................................................186Pakiety oprogramowania w planowaniu projektów .......................................187

Czy potrzebuję pakietu oprogramowania? .................................................188Narzędzia planowania projektów ................................................................189Ile czasu powinno zajmować planowanie? .................................................. 191

Wspólne sesje planowania projektowego .........................................................192Planowanie sesji ..............................................................................................193Prowadzenie wspólnej sesji planowania projektu ......................................199

Tworzenie struktury podziału pracy ................................................................ 200Tworzenie WBS na podstawie RBS ..............................................................201Zastosowania struktury podziału pracy ..................................................... 203Tworzenie struktury pracy ........................................................................... 204Sześć kryteriów testowania kompletności struktury podziału pracy ..... 207Podejścia do tworzenia struktury podziału pracy ......................................212Prezentacja graficzna struktury podziału pracy .........................................216

Szacowanie ............................................................................................................219Szacowanie czasu trwania projektu ............................................................. 220Ilość zasobów a czas trwania .........................................................................221Zmienność czasu trwania działania ............................................................ 223Sześć metod prognozowania czasu trwania działania .............................. 224Cykle szacowania ........................................................................................... 228Prognozowanie ilości potrzebnych zasobów ............................................ 229Planowanie zasobów ..................................................................................... 232Prognozowanie kosztów ................................................................................233

Tworzenie diagramu sieci projektu .................................................................. 236Tworzenie kompletnego diagramu sieci projektu .................................... 236Korzyści z tworzenia harmonogramu sieciowego .................................... 237Budowanie diagramu sieci metodą diagramowania pierwszeństwa ...... 238Zależności ........................................................................................................241Ograniczenia .................................................................................................. 243Zmienne opóźnione ...................................................................................... 247Tworzenie wstępnego harmonogramu projektu ....................................... 247Analiza wstępnego diagramu sieci projektu .............................................. 252Skracanie harmonogramu .............................................................................253Rezerwa menedżerska ................................................................................... 255

Pisanie skutecznej propozycji projektu ........................................................... 257Treść propozycji projektu ............................................................................ 257Format propozycji projektu ......................................................................... 259

Zgoda na uruchomienie projektu .................................................................... 259Podsumowanie .................................................................................................... 260Pytania do dyskusji ............................................................................................. 260




Spis treści 7

Rozdział 6. Uruchamianie realizacji projektu TPM ...................................263Narzędzia, szablony i procesy niezbędne

do rozpoczęcia prac projektowych ............................................................... 264Rekrutacja zespołu projektowego .................................................................... 264

Członkowie podstawowego zespołu projektowego .................................. 265Zespół klienta ................................................................................................. 269Członkowie zespołu zaangażowani na zlecenie ........................................ 269Jak uwolnić potencjał zespołu projektowego? ............................................271Plan rozwoju zespołu .................................................................................... 272

Prowadzenie spotkania inicjującego ................................................................ 272Cel spotkania inicjującego ........................................................................... 273Część prowadzona przez sponsora ............................................................. 274Część prowadzona przez menedżera projektu .......................................... 275

Ustalanie zasad pracy w zespole ....................................................................... 277W jakich sytuacjach trzeba określić zasady pracy w zespole? .................. 278Kwatera główna zespołu ............................................................................... 287

Zarządzanie zmianami zakresu projektu ........................................................ 288Proces zarządzania zmianami zakresu projektu ....................................... 288Rezerwa menedżerska ................................................................................... 292Bank zakresów ................................................................................................ 293

Zarządzanie komunikacją w zespole ............................................................... 293Tworzenie modelu komunikacji ................................................................. 293Zarządzanie komunikacją poza zespołem ................................................. 297

Alokacja zasobów ............................................................................................... 299Poziomowanie zasobów ............................................................................... 299Odpowiednio wypoziomowany harmonogram ....................................... 302

Strategie poziomowania zasobów .................................................................... 302Wykorzystywanie dostępnych zapasów czasu ............................................303Przesuwanie daty zakończenia projektu .....................................................303Wygładzanie ................................................................................................... 304Alternatywne metody tworzenia harmonogramu działań ...................... 304Wpływ poziomowania zasobów na koszty projektu ................................ 306

Finalizacja harmonogramu projektu .............................................................. 306Pakiety robocze ................................................................................................... 308

Cel zastosowania pakietu roboczego .......................................................... 309Format pakietu roboczego ............................................................................310

Podsumowanie ..................................................................................................... 313Pytania do dyskusji .............................................................................................. 313

Rozdział 7. Monitorowanie i kontrola postępów prac nad projektem TPM ....315Narzędzia, szablony i procesy niezbędne

w monitorowaniu i kontrolowaniu postępów prac ....................................316System raportowania o postępach ....................................................................317

Rodzaje raportów o stanie projektów ..........................................................317Aktualizowanie informacji ...........................................................................321Częstotliwość raportowania ..........................................................................323Odchylenia od planu .....................................................................................323





Stosowanie graficznych narzędzi raportowania .............................................325Diagramy Gantta ............................................................................................325Raporty-semafory ...........................................................................................325Wykresy wypalenia ........................................................................................ 327Trend odchyleń od terminowej realizacji kamieni milowych

(celów cząstkowych) ................................................................................... 328Analiza wartości uzyskanej ........................................................................... 331Integrowanie wykresów trendu odchyleń od terminowej

realizacji kamieni milowych z analizą wartości uzyskanej ....................336Zarządzanie bankiem zakresów .........................................................................339Tworzenie i prowadzenie rejestru problemów ............................................... 340Spotkania monitorujące postępy prac ............................................................. 340

Kto powinien uczestniczyć w spotkaniach monitorujących? ..................341W jakich porach organizować spotkania monitorujące? ..........................341Czemu służą spotkania monitorujące? .......................................................341Zakres spotkań monitorujących ................................................................. 342Codzienne 15-minutowe spotkania monitorujące ....................................343Spotkania poświęcone problemom .............................................................343

Zarządzanie eskalacją problemów ................................................................... 344Strategie na poziomie menedżera projektu ................................................345Strategie na poziomie menedżerów zasobów .............................................345Strategie na poziomie klienta .......................................................................345Strategie zapobiegania eskalacji problemów ............................................. 346

Zgoda na zakończenie projektu ....................................................................... 347Podsumowanie .................................................................................................... 347Pytania do dyskusji ............................................................................................. 348

Rozdział 8. Zamykanie projektu TPM .....................................................349Narzędzia, szablony i procesy niezbędne

w monitorowaniu i kontrolowaniu postępów prac ....................................350Procedury akceptacji rezultatów projektu przez klienta ................................350Zamykanie projektu ............................................................................................350Uzyskanie akceptacji rezultatów projektu przez klienta ............................... 351

Akceptacja nieformalna ................................................................................. 351Akceptacja formalna ...................................................................................... 351

Dostarczanie zamówionych elementów ...........................................................352Podejście stopniowe .......................................................................................352Podejście szokowe ...........................................................................................352Podejście równoległe ......................................................................................353Podejście „jednostka po jednostce” .............................................................353

Kompletowanie dokumentacji projektu ..........................................................353Zgromadzone informacje będą pomocne

przy wprowadzaniu późniejszych zmian do produktu .........................353Na podstawie zapisów historycznych możemy

dokładniej i szybciej prognozować czasy trwaniadziałań i zadań oraz koszty przyszłych projektów .................................353

Dokumentację możemy wykorzystywać jako materiałyszkoleniowe dla przyszłych menedżerów projektów ..............................354




Spis treści 9

W dokumentacji mogą poszukiwać wskazówekzespoły pracujące nad przyszłymi projektami ........................................354

Na podstawie dokumentacji kierownicy liniowi mogą udoskonalaćmetody oceny pracy członków zespołów projektowych ........................354

Audyt powdrożeniowy .......................................................................................355Raport zamykający ..............................................................................................357Świętowanie sukcesu ...........................................................................................358Podsumowanie .....................................................................................................359Pytania do dyskusji ..............................................................................................359

Część III. Zarządzanie projektami złożonymi 361

Rozdział 9. Ogólny obraz projektu a jego stopieńskomplikowania i niepewność ...............................................363Stopień skomplikowania i niepewność a zarządzanie projektami .............. 364

Wymagania ..................................................................................................... 367Elastyczność ................................................................................................... 367Dostosowywanie się ....................................................................................... 369Niepewność i stopień skomplikowania a ryzyko ...................................... 369Niepewność i stopień skomplikowania a spójność zespołu .................... 370Niepewność i stopień skomplikowania a komunikacja ...........................371Niepewność i stopień skomplikowania a zaangażowanie klienta .......... 372Niepewność i stopień skomplikowania a specyfikacja .............................375Niepewność i stopień skomplikowania a zmiany .................................... 377Niepewność i stopień skomplikowania a wartość biznesowa ................. 378

Podsumowanie .................................................................................................... 379Pytania do dyskusji ............................................................................................. 380

Rozdział 10.Zwinne zarządzanie projektami ............................................381Na czym polega zwinne zarządzanie projektami? ..........................................383

Wdrażanie modeli APM ............................................................................... 384Zespoły projektowe APM pracujące w jednym miejscu ........................... 386

Zwinne zarządzanie projektami w wydaniu lean ........................................... 389Iteracyjny model cyklu zarządzania projektem ............................................. 390

Definicja iteracyjnego modelu PMLC ........................................................ 390Adaptacyjny model cyklu zarządzania projektem ..........................................395

Definicja adaptacyjnego modelu PMLC .................................................... 396Adaptacja i integracja narzędzi, szablonów i procesów APM ...................... 400

Definiowanie zakresu kolejnej iteracji lub cyklu .......................................401Planowanie następnej iteracji lub cyklu ..................................................... 402Rozpoczynanie następnej iteracji lub cyklu .............................................. 402Monitorowanie i kontrola następnej iteracji lub cyklu ........................... 403Zamykanie następnej iteracji lub cyklu ...................................................... 403Decyzja o rozpoczęciu następnej iteracji lub cyklu .................................. 403Zamykanie projektu ...................................................................................... 404






Rozdział 11. Ekstremalne zarządzanie projektami .....................................407Na czym polega ekstremalne zarządzanie projektami? ................................ 408

Ekstremalny model cyklu zarządzania projektem ................................... 408Definicja .......................................................................................................... 409

Na czym polega zarządzanie projektami emertxe? ........................................ 409Model cyklu zarządzania projektem emertxe ............................................ 409Kiedy należy stosować model emertxe PMLC? ..........................................410

Stosowanie narzędzi, szablonów i procesów w celu maksymalnieefektywnego wykorzystania modelu xPM .................................................... 411

Definiowanie zakresu kolejnej fazy ............................................................. 411Planowanie następnej fazy ............................................................................ 411Rozpoczynanie następnej fazy .....................................................................412Monitorowanie i kontrola następnej iteracji lub cyklu ............................413Zamykanie fazy ...............................................................................................413Decyzja o rozpoczęciu następnej fazy .........................................................413Zamykanie projektu .......................................................................................414

Podsumowanie .....................................................................................................414Pytania do dyskusji ..............................................................................................414

Rozdział 12. Porównanie liniowych, stopniowych,iteracyjnych, adaptacyjnych i ekstremalnych modeli PMLC .......415Liniowy model cyklu zarządzania projektem .................................................416

Cechy charakterystyczne ...............................................................................417Zalety ............................................................................................................... 420Wady ................................................................................................................ 422Kiedy należy stosować liniowy model PMLC ........................................... 423Konkretne liniowe modele PMLC .............................................................. 423

Stopniowy model cyklu zarządzania projektem ............................................ 426Cechy charakterystyczne .............................................................................. 427Zalety ............................................................................................................... 427Wady ................................................................................................................ 429Kiedy należy stosować stopniowy model PMLC? ..................................... 432Stopniowe modele PMLC ............................................................................ 432

Iteracyjne modele PMLC ................................................................................... 436Cechy charakterystyczne .............................................................................. 437Zalety ............................................................................................................... 438Wady ................................................................................................................ 440Kiedy należy korzystać z iteracyjnego modelu PMLC ..............................441Konkretne iteracyjne modele PMLC .......................................................... 442

Adaptacyjny model PMLC ............................................................................... 454Cechy charakterystyczne .............................................................................. 455Zalety ............................................................................................................... 456Wady ................................................................................................................ 458Kiedy należy stosować adaptacyjny model PMLC? .................................. 458Adaptacyjna struktura projektu .................................................................. 459




Spis treści 11

Ekstremalny model PMLC ............................................................................... 480Charakterystyka projektu ekstremalnego .................................................. 480Zalety ................................................................................................................481Wady ................................................................................................................ 482Konkretne ekstremalne modele PMLC ...................................................... 483Ekstremalny model INSPIRE ...................................................................... 483

Wyzwania związane z przygotowaniem i wykonaniem projektu ................ 497Sponsor ma problem z zaakceptowaniem

zmiennego zakresu projektu ..................................................................... 497Osiągnięcie i podtrzymanie merytorycznego

zaangażowania klienta na wszystkich etapachwybranego modelu PMLC ........................................................................ 497

Dostosowywanie wybranego modelu PMLCdo zmieniających się warunków ............................................................... 498

Generowanie wartości biznesowejw realiach skomplikowanych projektów ................................................. 498

Podsumowanie .................................................................................................... 500Pytania do dyskusji ..............................................................................................501

Część IV. Zarządzanie realiami projektów 503

Rozdział 13. Strategie prewencyjne i interwencyjnew przypadku projektów zagrożonych ....................................505Definicja projektu zagrożonego ....................................................................... 506

Dlaczego projekty stają się zagrożonei dlaczego kończą się porażką? .................................................................. 507

Zarządzanie zagrożonymi projektami ............................................................. 511Strategie prewencyjne ..................................................................................... 511Korzystanie z narzędzi, szablonów i procesów w celu zapobiegania

otrzymywaniu przez projekty statusu zagrożonych ...............................512Strategie interwencyjne ..................................................................................518Szablon procesu interwencyjnego ................................................................531

Role i obowiązki PSO w odniesieniu do zagrożonych projektów ...............533Analiza sytuacji bieżącej ................................................................................535Weryfikacja pożądanego celu .......................................................................535Ocena dostępnych opcji ................................................................................535Opracowanie zmodyfikowanego planu ......................................................535


Rozdział 14. Organizacja projektów wielozespołowych ...............................537Definicja projektu wielozespołowego ...............................................................537Wyzwania związane z zarządzaniem projektami wielozespołowymi ..........539

Praca z zespołami pochodzącymi z różnych firm .................................... 540Praca z zespołami o zdecydowanie niezależnej kulturze ......................... 540Praca z różnymi procesami różnych zespołów ..........................................541Uwzględnianie konkurencyjnych priorytetów ..........................................541





Komunikacja w ramach struktury zespołu ................................................ 542Tworzenie struktury zarządzania projektem ............................................. 542Wybór konkretnego modelu PMLC ........................................................... 542Opracowywanie zintegrowanego planu i harmonogramu projektu ......543Wyznaczanie metody gromadzenia wymagań ...........................................543Wyznaczanie procesu zarządzania zmianami zakresu ............................ 544Definiowanie struktury spotkań zespołu ................................................... 544Wyznaczanie praktycznych poziomów raportowania ............................. 544Dzielenie zasobów między zespołami ........................................................ 545Decyzje kadrowe na różnych etapach realizacji modeli PMLC .............. 545Poszukiwanie swojego zastępcy ................................................................... 546

Klasyfikacja projektów wielozespołowych ...................................................... 546Dwa zespoły .................................................................................................... 546Większa liczba zespołów ............................................................................... 547

Struktura biura projektu ................................................................................... 548Charakterystyka biura projektu .................................................................. 549Zalety biura projektu .....................................................................................551Wady biura projektu ..................................................................................... 552Kiedy należy korzystać z biura projektów? .................................................553

Struktura zespołu głównego .............................................................................. 554Charakterystyka zespołu głównego ............................................................. 554Zalety zespołu głównego ............................................................................... 558Wady zespołu głównego ............................................................................... 559Kiedy należy korzystać z zespołu głównego? ..............................................561

Struktura superzespołu .......................................................................................561Charakterystyka superzespołu ..................................................................... 562Zalety superzespołu ........................................................................................565Wady superzespołu .........................................................................................566Kiedy należy korzystać z superzespołu? ..................................................... 567


Rozdział 15. Biuro wsparcia projektów ....................................................571Przesłanki tworzenia biur zarządzania projektami ....................................... 572Czym jest biuro wsparcia projektów? .............................................................. 574

Jednostka organizacyjna utworzona na stałe albo na określony czas .... 574Portfel usług świadczonych przez PSO ...................................................... 575Określony portfel projektów ....................................................................... 577

Nazewnictwo biur wsparcia projektów ........................................................... 578Definiowanie misji biura wsparcia projektów ............................................... 579Formułowanie celów PSO ................................................................................. 580Funkcje PSO ........................................................................................................ 580

Wspieranie projektów ................................................................................... 580Konsultacje i doradztwo ................................................................................581Tworzenie metod i standardów ....................................................................583Narzędzia informatyczne ............................................................................. 584




Spis treści 13

Szkolenie ......................................................................................................... 584Doradztwo w zarządzaniu zasobami potrzebnymi

do realizacji projektów ............................................................................... 586Struktura organizacyjna PSO ........................................................................... 588

Wirtualne i rzeczywiste biura wsparcia projektów ................................... 588Biura proaktywne i reaktywne ..................................................................... 588Biuro powołane na czas określony i na stałe ............................................. 589Program i projekt ........................................................................................... 589Biuro korporacyjne i funkcjonalne ............................................................ 589Biura centralne i regionalne ......................................................................... 589

Miejsce PSO w organizacji ................................................................................ 590Jak zorientować się, że PSO jest nam potrzebne? ........................................... 592

Raport Standish Group ................................................................................ 592Sygnały wskazujące, że PSO jest organizacji potrzebne ........................... 596

Tworzenie PSO .................................................................................................... 598Etapy wzrostu PSO ........................................................................................ 598Planowanie PSO ............................................................................................. 600

Trudności związane z tworzeniem PSO ...........................................................610Szybkość i cierpliwość .................................................................................... 611Wdrażanie PSO metodą z dołu do góry ......................................................612Myślenie systemowe .......................................................................................612Systemy na poziomie całej organizacji ........................................................612Zarządzanie wiedzą ........................................................................................612Uczenie się .......................................................................................................613Otwarta komunikacja ....................................................................................613

Biuro wsparcia projektów przyszłości ..............................................................613Centralne i regionalne BP4SO ......................................................................614Pracownicy BP4SO ..........................................................................................615Inne uwagi .......................................................................................................616


Rozdział 16. Tworzenie programu ciągłego doskonalenia procesów i zarządzanie nim ...............................619Praktyki i procesy w zarządzaniu projektami ................................................. 620

Proces zarządzania projektami .................................................................... 620Praktyka zarządzania projektami ................................................................ 622

Dojrzałość procesów i praktyk ......................................................................... 625Poziom 1. Ad hoc lub nieformalny ............................................................. 625Poziom 2. Udokumentowane procesy ....................................................... 626Poziom 3. Udokumentowane procesy stosowane przez wszystkich ...... 626Poziom 4. Integracja z procesami biznesowymi ....................................... 626Poziom 5. Ciągłe doskonalenie ................................................................... 627

Ocena dojrzałości procesu i praktyki zarządzania projektami .................... 627Macierz jakości procesów i mapa strefowa ................................................ 627Jakie procesy zdefiniowano dotychczas? .................................................... 634





Stosowanie modelu ciągłego doskonalenia procesów (CPIM) .....................636Etap 1. Podstawy ............................................................................................ 637Etap 2. Ocena i analiza ................................................................................. 638Etap 3. Program doskonalenia ..................................................................... 640Etap 4. Kontrola wyników ............................................................................641

Rola i zakres obowiązków PSO .........................................................................641Narzędzia, szablony i procesy w doskonaleniu procesów biznesowych .....641

Diagramy Ishikawy i analiza przyczyn źródłowych ................................. 642Wykresy kontrolne ........................................................................................ 645Schematy blokowe ......................................................................................... 645Histogramy ..................................................................................................... 646Analiza Pareto ................................................................................................ 647Wykresy przebiegu pracy .............................................................................. 649Wykresy punktowe ........................................................................................ 649Analiza pola sił ............................................................................................... 649Wartości progowe .......................................................................................... 652


Część V. Stan docelowy: model zarządzaniaprojektami na poziomie całego przedsiębiorstwa 655

Rozdział 17. Zarządzanie portfelem projektów .........................................657Wprowadzenie do zarządzania portfelem projektów ................................... 658

Czym jest projekt portfelowy? ..................................................................... 658Czym jest portfel projektów? ....................................................................... 659Czym jest zarządzanie portfelem projektów? ............................................ 660

Główne etapy zarządzania portfelem projektów ........................................... 660Tworzenie strategii portfela ......................................................................... 662Ocena zgodności projektu ze strategią portfela ........................................ 668Hierarchizacja projektu i przyznanie funduszy ........................................ 669Budowanie zrównoważonego portfela, złożonego

z uszeregowanych projektów .................................................................... 675Zarządzanie aktywnymi projektami ........................................................... 683

Rola i funkcje PSO w zarządzaniu portfelem projektów .............................. 692Sponsor projektu ........................................................................................... 692Menedżer portfela ......................................................................................... 692

Przygotowanie projektu do zgłoszenia go do portfela .................................. 693Statut projektu dostosowany do potrzeb zarządzania portfelem ........... 694Dwuetapowe składanie propozycji projektu ............................................. 695Przedkładanie całej propozycji projektu za jednym razem ..................... 695

Zwinne zarządzanie portfelem projektów ...................................................... 697Integracja modelu PMLC w ramach procesu zwinnego zarządzania

portfelem projektów .................................................................................. 699Wyzwania w zarządzaniu zwinnymi portfelami ....................................... 702




Spis treści 15

Wybór zrównoważonego portfela ............................................................... 703Zarządzanie aktywnymi projektami ........................................................... 705


Rozdział 18. Praktyczny model przedsiębiorstwa opartego na projekcie .......709Otoczenie biznesowe — spojrzenie odgórne .................................................. 711

Klimat biznesowy ........................................................................................... 711Okazje rynkowe ..............................................................................................712Potencjał przedsiębiorstwa ............................................................................713Wizja i misja ....................................................................................................715Cele ...................................................................................................................716Strategie ............................................................................................................716Taktyki .............................................................................................................718Struktura zależności w modelu OST ...........................................................719

Proces decyzyjny dotyczący portfela projektów w modelu EPPM .............. 720Etap gromadzenia .......................................................................................... 722Etap analizy .................................................................................................... 723Etap wyboru ................................................................................................... 724Etap rozpoczęcia ............................................................................................ 724Etap wykonania ............................................................................................. 724Etap wdrożenia .............................................................................................. 724Bramy etapów ................................................................................................. 725Co to jest zasób? ............................................................................................. 725Kim są uczestnicy modelu EPPM? .............................................................. 726Macierz projektów RASCI na poziomie przedsiębiorstwa ..................... 728Profilowanie złożonych projektów ............................................................. 729

Analiza przypadku. Tworzenie centrumrozwoju pracowniczego i biznesowego ........................................................ 734

Hipoteza ......................................................................................................... 734Streszczenie ..................................................................................................... 734Potrzeba ...........................................................................................................735Problem ........................................................................................................... 736Rozwiązanie .................................................................................................... 739Składowe modelu WBDC ............................................................................ 740


Słowniczek skrótów ............................................................747

Strona internetowa książki ..................................................751

Bibliografia ........................................................................753

Skorowidz .........................................................................761




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 rozdziału?

Po przeczytaniu rozdziału będziesz potrafił:

Analizować i stosować roboczą definicję zarządzania projektami.

Wymienić wyzwania związane z efektywnym zarządzaniem projektami.

Stosować definicję wymagań nawiązującą do wartości biznesowej.

Uporać się z chochlikami.

Posługiwać się strukturą podziału wymagań (RBS) jako kluczowym narzędziem wyborui dostosowywania najlepiej dopasowanego modelu PMLC.

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ć oddziaływanie złoż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 projektami




60 Rozdział 2.

nieustannie napotykam nowe wyzwania i ciągle uczę się czegoś nowego natemat 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.

Należy koniecznie pamiętać, że efektywne zarządzanie projektami to zajęciekreatywne. Dla doświadczonych praktyków tej dziedziny z pewnością nie jestżadną tajemnicą, że się ona 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! Kiedyś można było oczekiwać gotowego przepisu nazarządzanie przydzielonym projektem i czasami się nawet ten przepis dosta-wało. Jeżeli w Twojej organizacji nadal tak to wygląda, proszę, wykaż się w tejkwestii dużą podejrzliwością. W dzisiejszych czasach musisz sam wymyślić,jak podejdziesz do zarządzania danym projektem. Efektywny menedżer projek-tu ma myśleć, a nie tylko reagować. Dziedzina zarządzania projektami prze-szła w nowy stan, który — w momencie pisania tej książki — nie uformowałsię jeszcze w swej stałej postaci. Prawdę powiedziawszy, praktyka zarządzaniaprojektami może nigdy nie osiągnąć stałej, niezmiennej formy. Świat biznesupodlega nieustannym fluktuacjom i nie należy liczyć na to, że kiedykolwiek sięto zmieni. Realia biznesowe znajdują bezpośrednie przełożenie na to, w jakisposób musisz zarządzać projektami. Stosowane przez Ciebie podejścia będązatem również podlegać nieustannym zmianom. Co to oznacza dla począt-kującego menedżera projektu? Głowa do góry: sprawy nie mają się tak źle, jakmogłoby się wydawać. W części drugiej i trzeciej niniejszej książki dokładnienakreś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ędzieszdysponował 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.




Czym jest zarządzanie projektami? 61

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.

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.Diabeł tkwi jednak w szczegółach. Na potrzeby niniejszej książki postanowiłemnieco tę definicję rozbudować i stworzyć definicję roboczą, którą przedstawięjuż niebawem.

Bez względu na to, jak zdefiniujesz swój proces zarządzania projektem, zaw-sze sprowadzi się on do sześciopunktowego testu przedstawionego w poniż-szej uwadze. Jeżeli zatem projektujesz właśnie proces zarządzania projektemalbo robi to Twoja firma, sprawdź zasadność tego procesu, odpowiadając nasześć poniższych pytań.

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-

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

Project Management Institute, Newtown Square 2013.




62 Rozdział 2.

wiście z większym ryzykiem, co jest spowodowane brakiem precyzyjnej definicjirezultatów. Co więcej, mimo najlepszych chęci zespołu projektowego i klientarezultat może nigdy nie zostać wypracowany.

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ędzie reali-zowany. Nawet w tych rzadkich przypadkach, w których rozwiązanie problemujest znane, możesz nie dysponować ludźmi odpowiednio przygotowanymido realizacji projektu, a nawet jeśli będziesz miał takich ludzi, mogą się oniokazać niedostępni w danym momencie.

W sytuacji, w której rozwiązanie jest przynajmniej częściowo nieznane, możeCi się nie udać określić go do końca. Tak czy owak, musisz udokumentowaćdziałania niezbędne do realizacji projektu. W tym celu należy zdefiniowaćwymagania rozwiązania.

Jeżeli rozwiązanie problemu jest znane, przygotowanie odpowiedniego do-kumentu nie powinno nastręczać trudności, jeżeli jednak rozwiązanie jest choć-by częściowo nieznane, dokument ten będzie raczej powstawał stopniowo —nie będziesz dysponował wystarczającą wiedzą, aby stworzyć go na samympoczą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) — por. rozdział 4.

Jak to zostanie zrobione?

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





Skąd będzie wiadomo, że to zostało zrobione?

Opracowane przez Ciebie rozwiązanie problemu lub sposób na wykorzystanieokazji biznesowej będą stanowić określoną wartość biznesową dla organizacji.To właśnie tutaj kryje się Twoje kryterium sukcesu. Wartość ta będzie pod-stawą do wydania decyzji w kwestii tego, czy Twój projekt w ogóle będzie reali-zowany. Kryteria sukcesu mogą przybrać zatem postać wzrostu przychodów,niższych kosztów lub lepszej jakości usług. Te trzy kategorie wartości bizne-sowej określa się czasem skrótem IRACIS (od ang. increased revenue, avoided costs,improved services). Bez względu na to, o jakich kryteriach sukcesu mówimy, ko-niecznie muszą one zostać wyrażone w formie ilościowej, aby potem nie byłowątpliwości co do tego, czy udało się osiągnąć spodziewane efekty biznesowe.W ramach jednego z elementów audytu powdrożeniowego (por. rozdział 8.)będziesz dokonywał porównania faktycznie wypracowanej wartości bizne-sowej z szacowaną wartością biznesową zadeklarowaną w dokumentacji pro-jektu, która zadecydował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? W nie-których przypadkach na to pytanie można odpowiedzieć dopiero pojakimś czasie.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 te cztery pytania udziela się w ramach audytu powdrożenio-wego, omówionego w rozdziale 8.




64 Rozdział 2.

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:

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 wyraźnie odbiega od wszystkich innych, z którymi mogłeśspotkać się do tej pory. Po pierwsze, jest to jedyna znana mi definicja, którawyraźnie 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. Po drugie, choć równie ważne, kluczowym elementemmojej definicji jest zdroworozsądkowość zarządzania projektem, która ma wy-rażać to, że skuteczne zarządzanie nie może sprowadzać się do stosowaniajednego, uniwersalnego podejścia. Skoro mamy tu do czynienia z podejściemzdroworozsądkowym, to musi ono być nieustannie dopasowywane do zmie-niających się uwarunkowań projektu. Na kartach tej książki postaram sięsformułować zasady efektywnego zarządzania projektami. Definicje mode-li PMLC, przedstawione w podrozdziale zatytułowanym „Modele cyklu za-rządzania projektami — wprowadzenie”, stanowią punkt wyjścia do Twojejpodróży, po ukończeniu której będziesz kompetentnym menedżerem projek-tów. Dzięki lekturze niniejszej książki dowiesz się, że kompetentny i efektyw-ny menedżer projektu jest jednocześ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 skutecz-ne 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.





Wyzwania związane ze skutecznymzarządzaniem projektami

Jak już wspominałem, we współczesnych realiach zarządzania projektamimenedżer projektu oraz klient stają przed licznymi wyzwaniami związanymize skutecznością ich wysiłków. Jeśli chcesz podołać tym wyzwaniom i dosto-sowywać się do specyfiki konkretnych projektów, przyjmij strategię stoso-wania najlepiej dopasowanych modeli PMLC.

Elastyczność i dostosowywanie się

Praktyki tradycyjnego zarządzania projektami (TPM) zostały opracowanei doprecyzowane przez inżynierów, którzy oczekiwali od klienta jasnegosformułowania potrzeb (które dostawali, a przynajmniej tak im się wydawało),wyznaczenia terminu prac i wskazania kwoty, którą klient jest gotowy za tozapłacić. Menedżer projektu dostawał to wszystko niemal podane na tacy.Wszystkie szczegóły były znane, wszystkie niezbędne formularze wypełnio-ne, a we wszystkich rubryczkach widniały właściwe informacje. Wszyscy bylizadowoleni, ponieważ zlecenie było dobrze udokumentowane, można więc by-ło mieć pewność, że rezultaty prac będą odpowiadać przedłożonej dokumenta-cji. Zespół projektowy dokładnie wiedział, jakie rozwiązanie ma opracować,mógł zatem szczegółowo zaplanować prace. To opis naiwnej rzeczywistościmenedżerów projektu, która wyglądała w ten sposób aż do lat pięćdziesiątychXX wieku. W połowie lat pięćdziesiątych komputery znajdowały się na naj-lepszej drodze do tego, aby stać się jednym z praktycznych i komercyjnie do-stępnych zasobów organizacyjnych, nadal jednak pozostawały domeną in-żynierów. Projektami wciąż zarządzali inżynierowie i robili to tak samo, jakwcześniej.

Pierwsze oznaki nadchodzących zmian pojawiły się na początku lat sześć-dziesiątych. Komputery stały się realnym narzędziem stosowanym w kiero-waniu przedsiębiorstwami, zaczęły się więc pojawiać takie stanowiska, jakprogramista, analityk oprogramowania, analityk systemów czy prosty od-powiednik dzisiejszego architekta baz danych. Tak naprawdę byli to inżynie-rowie w przebraniu, lecz oczekiwano od nich, że jakimś cudem porozumiejąsię ze specjalistami w zakresie zarządzania i biznesu (którzy nie mieli naj-mniejszego pojęcia o komputerach oraz o ludziach umiejących komuniko-wać się z tymi maszynami) i wspólnie z nimi opracują i wdrożą systemy biz-nesowe, mające zastąpić procesy wykonywane przez ludzi. Była to całkowitametamorfoza świata biznesu i świata zarządzania projektami — to, co byłowcześniej, minęło bezpowrotnie.

Przekształcaliśmy się w społeczeństwo informacyjne, a tradycyjne zarządza-nie projektami trwało w swojej dotychczasowej postaci. W oczach inżynierówkażdy problem związany z zarządzaniem projektem w obszarze IT wyglądał




66 Rozdział 2.

na gwóźdź, a oni dzierżyli w ręku młotek. Dysponowali jednym rozwiąza-niem, które miało pasować do każdego problemu. Jednym z poważniejszychproblemów, z jakim zmagało się TPM i zresztą zmaga się do dzisiaj, jest róż-nica między potrzebami a zachciankami. Jeżeli masz zapamiętać z tego wprowa-dzenia tylko jedną rzecz, to niech będzie to świadomość, że to, czego klientchce, najprawdopodobniej nie pokrywa się z tym, czego potrzebuje. Jeżelimenedżer projektu ślepo zaakceptuje wszystko to, czego oczekuje od niegoklient, i przystąpi do realizacji projektów, prędzej czy później czeka go bar-dzo nieprzyjemna niespodzianka. Bardzo często w trakcie prac nad rozwią-zaniem klient uświadamia sobie, że potrzebuje jednak czegoś innego niż to,o co poprosił. Stąd bierze się konieczność przesuwania terminów, chochlikizakresu i niekończący się szereg zmian i modyfikacji. Nic dziwnego, że po-nad 70% wszystkich projektów kończy się niepowodzeniem. Trzeba prze-rwać to błędne koło. Potrzebujesz metodyki, u podstaw której leży zmiana— która pozwala wykorzystywać informacje pozyskiwane w całym okresieprowadzenia prac projektowych. Potrzebujesz metodyki, która pozwala wpro-wadzać zmiany wynikające z tych nowych informacji.

W ostatnich czterdziestu latach rozmawiałem z wieloma menedżerami pro-jektów o problemie braku jasności i potencjalnych sposobach radzenia sobiew tej sytuacji. Większość twierdziła, że opracowują rozwiązania zgodne z pier-wotnymi wymaganiami, a następnie podejmują kolejne próby modyfikacjitych rozwiązań, aby dostosować je do bieżących oczekiwań klienta. Pytałemich wówczas: „Skoro wiesz, że będziesz musiał modyfikować gotowe rozwią-zanie w kolejnych iteracjach, dlaczego nie zastosujesz metodyki, która po-zwala pracować nad nim w ten sposób od samego początku?”. Do niedawna,a właściwie do pojawienia się koncepcji zwinnego zarządzania projektami,odpowiedzią na to pytanie była ogłuszająca cisza. Wszystkie zwinne i eks-tremalne metody zarządzania projektami, które pojawiają się dziś w prakty-ce, opierają się na założeniu, że klient będzie zmieniał wymagania na skutekpozyskiwania nowych informacji na temat tego, co jest mu faktycznie po-trzebne. Czasami okazuje się, że potrzeby te wyraźnie się różnią od począt-kowych zachcianek.

Wniosek z tego taki, że zarządzanie projektami jest dziś zupełnie inne niżkiedyś. Internet oraz nieustannie zmieniający się wachlarz nowych techno-logii wycisnęły piętno na współczesnym świecie biznesu. Technologia po-woduje, że większość firm znajduje się w stanie permanentnego niezdecydo-wania. W jaki sposób firma może osiągnąć maksymalną możliwą wartośćbiznesową z wykorzystania internetu? Przedsiębiorstwa zadają sobie dziśjeszcze bardziej fundamentalne pytania: „W jakiej branży działamy?”, „Jakdocieramy do naszych klientów i jak ich obsługujemy?”, „Czego oczekująnasi klienci?”. Era dot.comów nastała błyskawicznie i z wielkim hukiem, byrównie szybko i z równie dużym hukiem odejść w zapomnienie. W latachdziewięćdziesiątych wysoce spekulacyjny kapitał typu venture wprowadził narynek bardzo wiele firm, które upadły jeszcze przed końcem tego samego stu-lecia. Przetrwało tylko kilka z nich, a ich przyszłość i tak jest dziś niepewna.





Popularne kiedyś określenia B2B i B2C zostały dziś zastąpione nowymimodnymi słówkami, takimi jak e-handel, e-biznes czy zarządzanie wiedzą. Miniejednak jeszcze sporo czasu, zanim sytuacja w pełni wróci do normy.

W ten oto sposób dochodzimy do następującego pytania: „Co wynika z tegowszystkiego dla Twojego podejścia do zarządzania projektami?”. Przedewszystkim powinieneś uświadomić sobie, że stosowane metody zarządzaniaprojektem muszą odpowiadać profilowi działalności przedsiębiorstwa. Za-rządzanie projektami musi stać się jednym ze stałych elementów strategii or-ganizacji. Menedżerowie projektu powinni kierować się przede wszystkimpotrzebami firmy, a dopiero potem oczekiwaniami własnych działów. W dzi-siejszych czasach jest to krytyczny czynnik sukcesu. Dodatkowe wyzwaniapojawiają się w związku z wkroczeniem na scenę analityków biznesowych,o czym wspomnę już za chwilę.

Szeroka wiedza na temat firmy i jej systemów

Najlepsi menedżerowie projektu rozumieją kontekst biznesowy, w którymrezultaty projektu będą definiowane, opracowywane i stosowane. Wymagato nie tylko znajomości systemów wewnętrznych oraz ich wzajemnych inte-rakcji, lecz również otoczenia zewnętrznego, czyli systemów związanych z opra-cowywanym rozwiązaniem stosowanych przez dostawców i klientów. Klu-czową rolę w tym obszarze odgrywają analitycy biznesowi i analitycy systemów.To członkowie grupy interesariuszy, o której piszę w rozdziałach 3. i 18. Mo-im zdaniem można dziś uzasadnić słuszność łączenia kompetencji menedżeraprojektu i analityka biznesowego w jedno specjalistyczne stanowisko, naktórym wymaga się odpowiedniego przygotowania i doświadczenia z obutych dziedzin. Rozważania na ten temat wykraczają poza ramy merytorycznetej książki, nie zmienia to jednak faktu, że trzeba zacząć o tym rozmawiać.

UwagaBardziej szczegółowe informacje na ten temat znajdziesz w innej mojejksiążce: The Business Analyst/Project Manager: A New Partnership for Mana-ging Complexity and Uncertainty, John Wiley & Sons, 2011.

Przejmij kontrolę nad projektemi zarządzaniem nim

Osobiście lubię prostotę. W moim przekonaniu sformułowana przeze mniedefinicja ogólnego obrazu projektów — w której posługuję się dwoma zmien-nymi (cel i rozwiązanie) przybierającymi tylko dwie wartości (jasne i niejasne)— jest bardzo prosta i obejmuje wszystkie możliwe projekty. W rezultacie wy-różniam cztery rodzaje metodyki zarządzania projektami:




68 Rozdział 2.

Tradycyjne zarządzanie projektami (TPM), w przypadku którego celi rozwiązanie są jasno określone.

Zwinne zarządzanie projektami (APM), w przypadku którego cel jestjasno określony, a rozwiązanie nie.

Ekstremalne zarządzanie projektami (xPM), w przypadku którego jasnonie jest zdefiniowany ani cel, ani rozwiązanie.

Zarządzanie projektami emertxe (MPx), w przypadku którego roz-wiązanie jest jasno określone, nieznany jest natomiast cel (na pierwszyrzut oka wydaje się, że to bez sensu, zapewniam jednak, że tak nie jest— zagadnienie to wyjaśnię we właściwym czasie).

Wszystkie projekty, które kiedykolwiek zrealizowano i które kiedykolwiekzostaną zrealizowane, kwalifikują się do jednej z tych kategorii. Każda z tychkategorii zawiera własne modele PMLC, a w ramach każdego modelu wyróżniasię przynajmniej jedną konkretną metodę zarządzania projektem. W ramachwszystkich czterech kategorii sformułowałem łącznie pięć modeli PMLC. Towłaśnie one, a właściwie ich rozpoznawanie i stosowanie, są głównym przed-miotem tej książki.

Zarządzanie projektamito uporządkowany zdrowy rozsądek

Definicja zarządzania projektami zdefiniowana w PMBOK jest zwięzła, jasnai precyzyjna. Stanowi solidny fundament dla definiowania grup procesówskładających się na ogół metodyki zarządzania projektami. Moim zdaniemistnieje jednak inna definicja, która przewyższa definicję z PMBOK i znacz-nie bardziej kompleksowo charakteryzuje zarządzanie projektami. Wyrażasię ona w trzech słowach: „uporządkowany zdrowy rozsądek”. Wszystkie pro-jekty są niepowtarzalne i każdy z nich różni się od wszelkich projektów, jakiezrealizowano kiedykolwiek wcześniej. Niepowtarzalność projektów wymagastosowania niepowtarzalnych metod zarządzania nimi, które będą na bieżącodostosowywać się do nowo odkrywanych cech danego projektu. Cechy te poja-wiają się na wszystkich etapach cyklu zarządzania projektem. Menedżer pro-jektu przygotowany na te cechy i potrafiący się do nich dostosować musinieustannie koncentrować się na podejmowaniu działań, które mają największysens w danych okolicznościach. Właśnie dlatego utrzymuję, że zarządzanieprojektami to nic więcej jak uporządkowany zdrowy rozsądek.

Zarządzanie chochlikami

Od czasu do czasu możesz odnosić wrażenie, że członkowie Twojego zespołusą małymi złośliwymi chochlikami, jednak to nie te chochliki mam tu namyśli. Chochliki w rozumieniu niniejszego fragmentu to drobne zmiany w pro-jekcie, wywołane niezauważalnymi (przynajmniej przez pewien czas) działa-





niami członków zespołu. Wiele z nich nie zostaje wykrytych, dopóki wszystkierazem nie stają się źródłem poważniejszego problemu. Powinieneś zwracaćszczególną uwagę na cztery rodzaje chochlików.

Chochlik zakresu

Chochlik zakresu projektu to każda zmiana w projekcie wprowadzona po roz-poczęciu realizacji. Zmiany występują zawsze. Oczekiwanie, że zmiany nienastąpią, byłoby nierealne. Przyczyny zmian są różne i większości z nich nieprzewidzi nawet najbardziej dalekowzroczny klient ani menedżer projektu.Uwarunkowania rynkowe są zmienne. Konkurenci mogą wprowadzać nowewersje produktów lub zapowiadać taki zamiar. W takim przypadku zarządza-jący firmą mogą uznać za konieczne wprowadzenie nowego produktu przedkonkurentami. Chochlik zakresu nie musi być czyimś zawinionym błędem.To po prostu rzeczywistość, na którą trzeba reagować. Bez względu na to, jakdobrą robotę wykonaliście wraz z klientem na etapie planowania projektu,chochliki zakresu i tak będą się pojawiać. Pogódź się z tym!

Twoim zadaniem jako menedżera projektu jest dostosowanie się do tych zmian.Trudna to praca, ale nikt inny jej nie wykona! Bez względu na to, jak zmieni sięzakres, musisz znaleźć sposób, by mimo przeciwności zrealizować projekt.

Chochlik nadziei

Z chochlikiem nadziei mamy do czynienia, gdy jeden z członków zespołu projek-towego ma opóźnienia w stosunku do harmonogramu i ukrywa ten fakt, liczącna to, że nadrobi zaległości, zanim upłynie termin składania następnegoraportu. Stanowi to dla menedżera projektu poważny problem. Nie sposóbzarządzać złożonym projektem, nie powierzając dużej części pracy innymczłonkom zespołu projektowego i menedżerom poszczególnych działań. Niktnie chce przynosić przełożonemu złych wieści; każdy woli zapewnić, żewszystko jest pod kontrolą, choć faktycznie nie jest. Takim spóźnialskimkieruje nadzieja, że uda mu się zdążyć na czas i ukryć bieżące niedociągnięcia.Menedżer projektu musi umieć ocenić, czy otrzymany od członka zespołuraport o stanie projektu jest rzetelny. Nie oznacza to, że musi sprawdzać każdyszczegół każdego raportu. W tym przypadku sprawdzają się kontrole wyrywkowe.

Chochlik wysiłków

Chochlik wysiłków odnosi się do sytuacji, w której członek zespołu, choć pracujew pocie czoła, nie robi żadnych lub prawie żadnych postępów. Każdy z naszapewne zetknął się z projektami, które ciągle były ukończone w 95%, bezwzględu na ilość włożonej pracy. Z cotygodniowych raportów o stanie pro-jektu wynikało, że robione są postępy, jednak ilość pracy pozostałej do wyko-nania wcale nie malała proporcjonalnie. Jedyne, co może zrobić menedżer




70 Rozdział 2.

projektu, oprócz kontroli wyrywkowych, to zwiększenie częstotliwości rapor-tów od tych członków zespołu, co do których istnieje podejrzenie, że efektyw-ność ich pracy zmalała.

Chochlik cech

Chochlik cech projektu jest zjawiskiem zbliżonym do zmiany zakresu. Zdarzasię, że członek zespołu z własnej woli postanawia dodać jakieś cechy i funkcjedo zdefiniowanych już rezultatów projektu, będąc przekonanym, że klientbędzie z tego zadowolony. Problem w tym, że klient z jakiegoś powodu nieokreślił tych cech w wymaganiach. Jeżeli członek zespołu ma silne przeczu-cie, że wprowadzenie nowych cech jest potrzebne, trzeba zastosować formalnąprocedurę, taką jak przy wprowadzaniu do projektu innych zmian.

OdwołanieProces zarządzania zmianą został omówiony w rozdziale 6.

Czym tak naprawdę są wymagania projektu?

Pierwszym ważnym etapem cyklu zarządzania projektem jest wskazanie po-trzeb. Działania te inicjuje sponsor lub klient, a potrzeby te zostają następniedoprecyzowane w formie specyfikacji wymagań. Wymagania określają, copowinny oferować dany produkt lub usługa, aby zaspokajać potrzeby klientai generować oczekiwaną wartość biznesową. Bardziej formalna definicja zostałasformułowana przez członków International Institute of Business Analysis(IIBA) w publikacji „Guide to the Business 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.

3. Udokumentowana postać warunku lub funkcjonalności w rozumieniupunktu (1) lub (2)”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-

2 International Institute of Business Analysis (IIBA), The Guide to the Business Analysis Body of

Knowledge, (Version 2.0), 2009.





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 we wska-zanym czasie i w ramach wskazanych ograniczeń, jest chybione. Takie ujęciew ogóle nie uwzględnia ani pierwiastka biznesowego, ani klienta, ani satys-fakcji odczuwanej przez członków organizacji. Właśnie dlatego ja stawiam nakryterium generowania wartości biznesowej. Czyż to nie oczekiwana wartośćbiznesowa zadecydowała o tym, że projekt w ogóle doczekał się realizacji?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 generująjakąś wartość biznesową. Oto robocza definicja wymagań:

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ą.

Innymi słowy, wymagania opisują to, co dane rozwiązanie ma robić, a nie jakma to robić. Wymagania są zatem niezależne od samego rozwiązania. Wyma-gania rozwiązania można zdefiniować także wówczas, gdy samo rozwiązanienie jest znane. To szczególnie istotne w przypadku złożonych projektów, gdzieczęsto znamy wymagania, ale nie wiemy, jak je spełnić.

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 podstawieoczekiwanej 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.

Powyższa definicja wymagań jest wyraźnie 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.




72 Rozdział 2.

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ć. Gdy ostatniozastosowałem definicję proponowaną przez IIBA, klient i członkowie mojegozespołu wygenerowali ponad 1400 wymagań! Umysł człowieka najzwyczajniejw świecie nie jest w stanie objąć i przyswoić tak dużej liczby wymagań. Wyda-je się wysoce nieprawdopodobne, aby przy takim ujęciu wymagań można byłokiedykolwiek uznać, że sformułowana lista tych wymagań jest kompletna. Li-cząc się z tym, że na etapie prac nad realizacją projektu może dochodzić doodkrycia i sformułowania nowych wymagań, można uznać listę wymagań zakompletną w rozumieniu mojej definicji już na początku realizacji projektu.Warto tu jednak podkreślić, że na tym etapie nikt nie ma jeszcze pełnej wie-dzy na temat dekompozycji tych wymagań. Moja definicja jest bardziej zorien-towana na wartość biznesową niż definicja autorstwa IIBA. Wiedza pozyskanaw trakcie kolejnych cykli realizacji projektu oraz wyciągnięte z niej wnioskipozwalają dokonać dekompozycji wymagań na kolejnych poziomach wy-znaczanych przez funkcje, podfunkcje, procesy, działania i cechy. Pierwszypoziom dekompozycji to poziom funkcjonalny, który można utożsamiaćz wymaganiami w ujęciu definicji sformułowanej przez IIBA. Oznacza to, żena samym początku realizacji projektu można zdefiniować jego wszystkiewymagania, nie można natomiast określić ich szczegółów na poziomie funkcji,podfunkcji, procesów, działań i cech. Te szczegółowe informacje są pozyskiwa-ne wraz z realizacją kolejnych cykli składających się na projekt.

O formułowaniu, gromadzeniu, dekompozycji i kompletności wymagań zde-cydowanie więcej będę miał do powiedzenia w rozdziale 4. oraz w części trze-ciej, skąd dowiesz się, w jaki sposób kompletność wymagań przekłada się nawybór najlepiej dopasowanego 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 ośmiulub dwunastu. Myślę o wymaganiach na wyższym poziomie niż więk-szość moich kolegów po fachu. Zastosowanie definicji zaproponowanejprzez IIBA powoduje, że na początku prac nad projektem sporządzeniekonkretnej listy wymagań jest raczej niemożliwe. Można je poznać do-piero na etapie realizacji projektu. Właśnie takie podejście przyjmujęw ramach mojej adaptacyjnej struktury projektu (APF, od ang. adaptiveproject framework), por. rozdział 12. Dzięki mojej definicji wymagań wyż-szego rzędu istnieje możliwość sformułowania kompletnej listy wymagańjuż na samym początku prac nad projektem. Z moich własnych doświad-czeń wynika, że definicja wyższego rzędu daje klientowi i członkom ze-społu projektowego bardziej holistyczny ogląd projektu i umożliwia po-dejmowanie znacznie lepszych decyzji biznesowych, mających wpływ narozwią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

CechyRBS to w sumie hierarchiczne przedstawienie wszystkiego tego, co na-leży opracować, aby spełnić sformułowane wymagania. Te szczegółoweinformacje można pozyskać i udokumentować wyłącznie w trakcie re-alizacji projektu. RBS zostanie omówiona bardziej szczegółowo w roz-dziale 4., natomiast w rozdziale 5. skupię się na zależnościach międzyRBS a WBS, czyli strukturą podziału pracy.

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.




74 Rozdział 2.

Moja definicja pozwala lepiej gospodarować zasobami występującymiw ograniczonej ilości (pieniędzmi, czasem, ludźmi). 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ązanaz oczekiwaną wartością biznesową, która ma być rezultatem udanej re-alizacji projektu. Wartość biznesowa może stać się również podstawądo nadawania priorytetów poszczególnym wymaganiom, co w przypadkudefinicji IIBA nie jest możliwe.

We wszystkich stosowanych przeze mnie narzędziach, schematach i procesachzawsze najwyżej ceniłem sobie prostotę. W moim odczuciu definicja wyma-gań wyższego rzędu, którą opracowałem, spełnia to kryterium, a poza tymzupełnie dobrze sprawdza się w praktyce. Moi klienci są tego samego zdania.

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 trzeciej 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.

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 trzeciejzdecydowanie bardziej szczegółowo przedstawię sposób podejmowania tychdecyzji.

Modele cyklu zarządzania projektami— wprowadzenie

Aby móc zaplanować czekającą Cię podróż, potrzebujesz ogólnego obrazuprojektu, który byłby na tyle prosty, aby mógł pozostawać aktualny bez względuna zmiany zachodzące w otoczeniu biznesowym. Będzie to Twoja niezmiennamapa drogowa do dalszej analizy i działań. Specjaliści ds. zarządzania pro-jektami już od kilku lat wieszczą, że w tej dziedzinie nie ma rozwiązań uni-wersalnych. Gdyby takowe rozwiązania istniały, życie menedżera projektunie byłoby trudne, a niniejsza książka nie miałaby nawet stu stron. W rzeczy-wistości praca menedżera projektu stanowi, niestety (a dla osób lubiącychprzygody pewnie na szczęście), nie lada wyzwanie i wymaga zaangażowaniapełnego potencjału kreatywnego. Myślenie pod kątem „rozwiązań uniwersal-nych” się nie sprawdza i chyba nigdy się nie sprawdzało. Mam tu oczywiściena myśli fakt, że menedżer projektu powinien na podstawie jego charaktery-styki dobierać narzędzia, schematy i procesy, które są w danej sytuacji od-




76 Rozdział 2.

powiednie. Aby pomóc ci w opracowaniu modelu podejmowania decyzjiw kwestii wyboru właściwego modelu zarządzania projektem, na początek zde-finiuję pokrótce bardzo ogólny obraz projektu, a następnie przedstawię stra-tegię pogłębiania tego obrazu w celu dojścia do konkretnego modelu cyklu za-rządzania projektem (PMLC, od ang. project management life cycle). Dopieropóźniej omówię narzędzia, schematy i procesy, a także ich zastosowanie w od-niesieniu 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 gotowaćwedług przepisów stworzonych przez inne osoby, podczas gdy szef kuchni samtakie przepisy tworzy. Aby osiągnąć pułap, na którym też posiądziesz tę umie-ję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,

monitorowanie i kontrola,

zamykanie projektu.

Model cyklu zarządzania projektem zawsze zaczyna się od definiowaniaprocesu i zawsze kończy się zamykaniem projektu. Wszystkie grupy pro-cesowe muszą mieć miejsce co najmniej jeden raz w ramach cyklu, choćwszystkie mogą zostać powtórzone dowolną liczbę razy.

Poszczególne grupy procesów zostały zdefiniowane w rozdziale 3. Logiczna ko-lejność występowania procesów jest uzależniona od charakterystyki konkret-nego projektu. W niniejszej książce zdefiniuję pięć różnych modeli PMLC.Wszystkie zostały opracowane z myślą o szczególnych wymaganiach typu pro-jektu, któremu zostały przypisane. W związku z tym zdefiniowałem pięć modelirozpisanych na cztery ćwiartki: Ćwiartka 1: TPM — model liniowy i model stopniowy, Ćwiartka 2: APM — model iteracyjny i model adaptacyjny, Ćwiartka 3: xPM — model ekstremalny, Ćwiartka 4: MPx — model ekstremalny.

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





Na rysunku 2.1 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.1. Modele PMLC

Rysunek 2.1 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. Tak teżw istocie jest. Decyzja w kwestii wyboru modelu najlepszego dla danego projek-tu opiera się na kilku czynnikach, a jednym z nich jest jasność rozwiązania.W przypadku projektów pozostających na granicy ćwiartek TPM i APM zawszebędziesz musiał dokonać subiektywnej oceny tego, który z modeli PMLCjest modelem najlepiej dopasowanym. W części trzeciej opisuję konsekwen-cje tej subiektywnej decyzji.

Zarządzaniem projektami zacząłem zajmować się w 1963 roku, czyli na kilkalat przed powstaniem Instytutu Zarządzania Projektami (PMI). Początkowowiększość projektów opierała się na prostych wykresach Gantta, by stopnio-wo przekształcać się w projekty realizowane za pomocą interdyscyplinar-nych zestawów narzędzi, schematów i procesów, dopasowanych do potrzebkonkretnej sytuacji. Zarządzanie projektami przestało być zaledwie kolej-nym narzędziem w przyborniku menedżera. Dzisiaj zarządzanie projektamito bardziej sposób na życie, szczególnie że wiele firm przekształciło się w cośw rodzaju organizacji projektowych. Oczywiście, ciągle jeszcze w niektórych




78 Rozdział 2.

sytuacjach najlepiej sprawdzać się będą tradycyjne rozwiązania, jednak już dziśmamy do czynienia z całym zestawem zastosowań, w przypadku których staresposoby zupełnie się nie sprawdzają. Obowiązujący paradygmat musi się zmie-nić i się zmienia.

Weźmy na przykład zwinne zarządzanie projektami, które oficjalnie pojawi-ło się na scenie w 2001 roku3. Przełom ten zapoczątkował formalne odejścieod stosowanych wówczas praktyk. Firmy, które nie uwzględniły tej zmianyw swoim funkcjonowaniu, ryzykują utratą zarządzania projektami jako warto-ściowego zasobu strategicznego. Powiedzenie „Zmieniaj się albo giń” nigdynie było bardziej aktualne niż dzisiaj. Ta niewielka zmiana zaproponowanaw 2001 roku dała początek całemu portfelowi nowych metod zarządzania pro-jektem. Wspominam jeszcze o nich w dalszej części tego podrozdziału, nato-miast szczegółowo omawiam je w części trzeciej.

Dlaczego potrzebujemy kolejnego sposobu zarządzania projektami? Czyżnie mamy już wystarczająco dużo różnych możliwości? Owszem, opcji dowyboru mamy mnóstwo, jednak nadal zdecydowanie zbyt dużo projektówkończy się klęską. W przeszłości wysiłki menedżerów projektów nie były zbytowocne — można wskazać wiele powodów. Moim zdaniem sytuacja ta jestczęściowo spowodowana faktem, że nie udało nam się jeszcze w pełni okre-ślić, w jaki sposób — na poziomie praktycznym i funkcjonalnym — dosto-sowywać wykorzystywane metody do wymagań projektów, którymi przyszłonam zarządzać w dzisiejszych realiach biznesowych. Zbyt wielu menedżerówpodejmuje próżny trud upychania sześciennych klocków w okrągłe otwory tyl-ko dlatego, że poza sześciennymi klockami nie mają nic innego. Zarządzanieprojektami musimy zacząć traktować jak dziedzinę nauki oraz jak sztukę,ponieważ taki jest właśnie jego charakter. Oznacza to, że naszym zadaniemjest na podstawie niepodważalnych zasad i koncepcji zbudować naukowozdefiniowaną dziedzinę wiedzy. Właśnie ten cel staram się osiągnąć w niniej-szym rozdziale oraz w całej części drugiej oraz trzeciej.

W moim przekonaniu rozwiązanie dla trudności napotykanych przez nasw zarządzaniu projektami jest oczywiste. Menedżerowie projektu musząotworzyć się na podstawowe zasady, na których opiera się ta dziedzina w kwe-stii uwzględniania zmian, unikania marnotrawstwa środków finansowych,unikania marnotrawstwa czasu i ochrony pozycji rynkowej firmy. W związkuz tym pojawiają się praktyki „lean”, które omawiam w rozdziale 10. Odkądtylko pamiętam, opowiadam wszem i wobec, że uniwersalne rozwiązania się niesprawdzają. Podstawą definiowania metody zarządzania projektem musibyć 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ę odwyboru najlepiej dopasowanego modelu PMLC (na podstawie charakterystyki

3 Fowler Martin, Highsmith Jim, The Agile Manifesto, „Software Development” 9, No. 8, sierpień

2001, s. 28 – 32.





konkretnego projektu). Właśnie w tym celu opracowuje się strukturę RBS.Następnie trzeba się zastanowić, jak dany model można zmodyfikować w celujak najbardziej efektywnego zarządzania konkretnym projektem.

Metody tradycyjnego zarządzania projektami

Czy 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. Czynnikiem ograniczającym, charaktery-stycznym dla metod TPM opartych na planowaniu, jest brak tolerancji dlazmian. W metodach tych chodzi o osiąganie rezultatów zgodnie z ograni-czeniami czasowymi i budżetowymi. Ich stosowanie polega bardziej na trzy-maniu się planu niż na generowaniu wartości biznesowej. Plan to rzecz święta,więc trzymanie się planu staje się wyznacznikiem najlepszych zespołów pro-jektowych. To podejście okazało się niesłuszne.

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 innymi ce-chami, opisanymi pokrótce w kolejnych fragmentach.

Niewielka złożoność

Niewielka złożoność oznacza po pierwsze, że projekt jest naprawdę prosty,a po drugie, że często bardzo przypomina inne, wykonane już projekty. Możepolegać na bezpośrednim zastosowaniu znanych i zaakceptowanych zasadbiznesowych, w związku z czym w jego realizacji będzie można wykorzystaćistniejące już wzory i kod. Tego rodzaju projekty były już wielokrotnie reali-zowane, w związku z czym ich wykonanie może sprowadzać się do zastoso-wania praktycznie gotowych schematów. Deweloper może odnosić wrażenie,że jego zadanie sprowadza się do stosowania mechanizmu wytnij-wklej.




80 Rozdział 2.

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 kompetencjezwią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 trzeciej.

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 nie tra-cić przy tym na swojej skuteczności.

Projekty TPM oparte na planowaniu

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

Cała ta wiedza pozwala zarządzać tego rodzaju projektami z wykorzystaniemmetodyki TPM. Możesz na przykład sformułować kompletną strukturępodziału pracy (WBS), a następnie na tej podstawie oszacować czas realizacjiprojektu, oszacować zapotrzebowanie na zasoby, opracować harmonogramdziałań oraz napisać propozycję projektu. W ten sposób otrzymujesz bardzozgrabny pakiet dokumentów, którego przygotowanie jest stosunkowo proste.




82 Rozdział 2.

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 10. i 11.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.2.

Rysunek 2.2. 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ąć.

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 12.

Stopniowe ujawnianie rozwiązania odbywa się w sposób liniowy, przedsta-wiony na rysunku 2.3. Ostatecznie rozwiązanie jest dokładnie takie samo, jakgdyby zastosowany został model liniowy. Teoretycznie projekt realizowanyw modelu stopniowym powinien dać dokładnie taki sam rezultat i zostać ukoń-czony w takim samym czasie, jak gdyby był prowadzony w modelu liniowym,jednak model stopniowy wymaga od menedżera projektu nieco większychnakładów pracy, więc w praktyce zostanie ukończony nieco później.

Rysunek 2.3. Stopniowy model PMLC

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.

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:




84 Rozdział 2.

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.

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 odbije sięna harmonogramie kolejnych ujawnień.

OstrzeżenieStopniowy model PMLC sprzyja składaniu niepożądanych wniosków o zmianęzakresu projektu.

Metody zwinnego zarządzania projektami

Zajmijmy 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.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. Projekty słusznie zakwalifikowane do ćwiart-ki APM odznaczają się kilkoma cechami 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ć tylkospośród tych możliwości, które pozwalają zidentyfikować akceptowalne roz-wiązanie poprzez realizację projektu. Tego rodzaju projekty stoją w jawnejsprzeczności z wszelkimi znanymi praktykami tradycyjnego zarządzania pro-jektem. Najwyższe kierownictwo firm nie jest zbyt uradowane takim stanemrzeczy, ponieważ wszystkie potencjalnie dobre metody różnią się między sobąpod względem zakresu. Projekt pochłania określone zasoby, choć do końcanie wiadomo, jakie będą jego rezultaty i czy wygenerują oczekiwaną wartośćbiznesową.

Okazja biznesowa, której do tej pory nie udało się wykorzystać

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

Projekty APM oparte na zmianie

Projekty TPM były projektami planowymi, natomiast projekty APM to przed-sięwzięcia, w których dominuje zmiana. W projektach TPM zmiana nie jesttolerowana, prowadzi ona do marnotrawstwa czasu i innych zasobów w związ-ku z koniecznością zmiany planów. W projektach APM zmiana jest warunkiemsukcesu. Takie projekty wykorzystują modele planowania „just-in-time”, cooznacza, że pod tym względem nie dochodzi w nich do marnowania zasobów— są „lean”.

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 16.




86 Rozdział 2.

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.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 niekonsekwen-cji, że definiujemy projekt jako niepowtarzalne doświadczenie, które nigdywcześniej nie miało miejsca i które w takich samych okolicznościach jużnigdy się nie wydarzy, a mimo to nie staramy się o to, aby metoda realizacjitakiego projektu również była niepowtarzalna i wyjątkowa. Powiedziałbym, żemetoda zarządzania projektem jest niepowtarzalna tylko w pewnym stopniu,bowiem jej wyjątkowość ogranicza fakt stosowania sprawdzonych i wypró-bowanych zestawów narzędzi, schematów i procesów. Gdyby te standardy nieistniały, zarządzanie projektem sprowadzałoby się do czystego chaosu. Cowięcej, gdyby projekty realizowano w taki sposób, organizacja — przynajm-niej na tym polu — nigdy nie byłaby organizacją uczącą się.

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

Wraz z tym, jak rozwiązanie zmienia się z jasno sprecyzowanego w rozwią-zanie, które nie jest jasno zdefiniowane, pojawiają się liczne sytuacje wyma-gające od menedżera projektu innego podejścia. Załóżmy, że nieznane sątylko mniej istotne aspekty rozwiązania, na przykład kolorystyka tła i czcio-nek stosowanych na stronie logowania. Co zrobisz w takiej sytuacji? Właści-wym rozwiązaniem powinno być zastosowanie metody, która pozwoli w jaknajwiększym stopniu wykorzystać znaną część rozwiązania. Taka metoda dajemożliwość przedstawienia klientowi prototypu produkcyjnego do oceny. Klientmoże wówczas określić, co powinno się w nim znaleźć, a czego na razie bra-kuje. Na drugim skraju ćwiartki APM znajdują się projekty, w przypadku




88 Rozdział 2.

któ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 12. 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 12.

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 kwestii wy-boru konkretnego modelu zależy częściowo od początkowego stopnia nie-pewności co do rozwiązania.

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.4.

Rysunek 2.4. 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 jest





pokazanie 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óżnisię od modelu stopniowego pod tym względem, że jest przystosowany douwzględniania licznych zmian. Zmiana jest wręcz nieodłącznym elementemtego modelu.

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.4 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 wyraźnym elementem współpracy,który nie jest zauważalny w ramach metodyki TPM.

Adaptacyjny model cyklu zarządzania projektem

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




90 Rozdział 2.

Rysunek 2.5 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 10.

Rysunek 2.5. Adaptacyjny model PMLC

OstrzeżenieWe wszystkich modelach zwinnego zarządzania projektami zakres projektumoże się zmieniać.

Metody ekstremalnego zarządzania projektami

Trzeci 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 tuo 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 po-stępem prac klient ocenia przyjęte założenia i daje dalsze wskazówki człon-kom zespołu projektowego. Proces ten się powtarza. Częściowe rozwiązanie





albo przekształci się w jego ostateczną wersję, albo zostanie porzucone gdzieśpo drodze. W większości przypadków takie projekty nie mają sztywnego bu-dżetu ani harmonogramu. Brak jasno zdefiniowanego celu i rozwiązania po-woduje, że projekt jest narażony na liczne zmiany. Charakter tych projektówpowoduje, że niestety nie mieszczą się one w sztywnych ramach ograniczeń cza-sowych i kosztowych.

Projekty kwalifikujące się do ćwiartki xPM oraz kolejne etapy ekstremalnegomodelu PMLC zostały szczegółowo opisane w rozdziale 11.

Projekt xPM jest projektem badawczo-rozwojowym

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

Projekt xPM charakteryzuje się bardzo dużym ryzykiem

Każda podróż w nieznane jest bardzo ryzykowna — prawdopodobieństwoponiesienia porażki jest bardzo duże. Nawet jeśli uda się osiągnąć cel, kosztopracowanego rozwiązania może okazać się zaporowy. Może się też okazać,że obrany kierunek poszukiwania rozwiązania jest całkowicie błędny i prowadzijedynie do porażki. Jeżeli przyjęty proces zarządzania projektem pozwala wcze-ś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 przykła-dem są choćby samoprzylepne karteczki Post-It firmy 3M. Niemal siedem latpo tym, jak niepowodzeniem zakończył się projekt mający na celu opraco-wanie substancji klejącej o ograniczonej czasowo skuteczności (był to projektxPM), jeden z inżynierów firmy znalazł zastosowanie dla stworzonego wów-czas produktu — w ten sposób powstały samoprzylepne karteczki do noto-wania 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łowi




92 Rozdział 2.

projektowemu jak największą elastyczność, czym wyraźnie 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 rozwią-zań lub zawężania ich liczby. Nie ulega wątpliwości, że projekty xPM stano-wią całkowicie odrębną klasę projektów i wymagają zupełnie innej metodyki,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 tegocelu 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 11.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.6. 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.6. 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że rów-nież zostać w dowolnym momencie anulowany. Od projektów APM różnigo to, że nieznany jest cel, a w najlepszym razie ktoś ma jakiś bliżej niespre-cyzowany pomysł, co mogłoby tym celem być. W takiej sytuacji klient powie-działby coś w tym stylu: „Rozpoznam to, gdy to zobaczę”. Dla doświadczonegomenedżera projektu nie jest to żadna nowość, ponieważ takie słowa słyszał jużwielokrotnie. Tak czy owak, to na nim spoczywa odpowiedzialność związanaze znalezieniem rozwiązania (oczywiście z pomocą klienta).

Modele xPM odróżnia od modeli APM również to, że w ich przypadku odklienta oczekuje się większego zaangażowania zarówno między kolejnymifazami, jak i w trakcie ich trwania. W wielu projektach xPM to klient obej-muje rolę lidera, w odróżnieniu od projektów APM, w przypadku którychmamy do czynienia ze współzarządzaniem. Dobrym przykładem projektówxPM są badania nad nowymi lekami. Załóżmy dla przykładu, że celem pro-jektu jest znalezienie nowego dodatku do żywności, który zapobiegałby kata-rowi. Jest to niezwykle szeroko zdefiniowany projekt, więc nie ma sensu narzu-cać mu sztywnych ram czasowych ani z góry ustalonego budżetu. Zespółprojektowy rozpocznie prace najprawdopodobniej od wyboru jakiegoś kie-runku lub kierunków badań i będzie liczył na to, że kolejne efekty jego pracbędą spełniać dwa poniższe warunki: Ukończona właśnie faza realizacji projektu będzie wskazywać nowy,

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

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

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

sową. Jednym słowem: sukces!




94 Rozdział 2.

Sponsor nie godzi się dalej finansować projektu. Sponsor może zadecy-dować o wstrzymaniu finansowania ze względu na brak wyraźnych 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 emertxe

Znane 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 oniprzybiegną 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.6 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ć mi





na słowo — bardziej szczegółowe rozważania na ten temat znajdziesz w roz-dziale 11.). 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 11.

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

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

Nowa technologia o nieznanym zastosowaniu

Przypomina mi się historia technologii RFID i jej zastosowania do odczytuinformacji zakodowanych w przedmiotach transportowanych za pomocąpasów transmisyjnych, a następnie kierowania ich na podstawie tych infor-macji w odpowiednie miejsca. Kiedy technologia ta ujrzała światło dzienne,od razu pomyślano o kilku różnych jej zastosowaniach w magazynach. Jed-na z największych sieci handlowych świata powołała specjalny zespół, którymiał znaleźć zastosowania technologii RFID w jej systemach logistycznychi systemach obsługi łańcucha dostaw. Technologia ta charakteryzowała sięwówczas precyzją na poziomie 70 procent, w związku z czym zespół ocenił,że będzie ona miała znaczną wartość biznesową pod warunkiem, że uda sięwyraźnie 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 manage-ment system), wyprodukowany przez dużego i znanego producenta oprogramo-wania. Celem Twojego projektu jest dokonanie oceny przydatności tego sys-




96 Rozdział 2.

temu pod kątem nowego procesu zarządzania zasobami ludzkimi, który zostałwłaśnie zaaprobowany przez najwyższe kierownictwo firmy. Jest to chyba naj-prostszy możliwy przykład projektu MPx, bowiem znasz już obszar, w którymbędziesz szukał zastosowania. Musisz jedynie ustalić, na ile nowy HRMS od-powiada potrzebom firmy i jaką oferuje jej wartość biznesową. Istnieją jednaktakże takie projekty, w przypadku których rozwiązanie jest całkowicie niezna-ne. Przykładem niech będzie tu sok pozyskiwany z pewnego dziwnego drzewaz Amazonii. Celem projektu byłoby znalezienie takiego zastosowania tegosoku, które miałoby wystarczająco dużą wartość biznesową.

Przegląd modeli PMLC

Zapoznaliś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.7.

Rysunek 2.7. 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 stosowanej





tu terminologii. W modelach APM i xPM posługuję się terminami iteracja,cykl i faza, które mają pomagać w odróżnianiu — odpowiednio — modeluiteracyjnego, adaptacyjnego i ekstremalnego. Rozróżnienie to będzie mipotrzebne w dalszych rozważaniach, aby nie było wątpliwości, do któregoz modeli się akurat odnoszę. Abyś mógł jeszcze lepiej poznać i zrozumiećmodele PMLC, chciałbym tu podkreślić ich podobieństwa i występującemiędzy nimi różnice.

Podobieństwa między modelami PMLC

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

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

kaniem projektu.

Różnice między modelami PMLC

Różnice między modelami są najlepiej widoczne w odniesieniu do stopnianiepewności i niedookreślenia rozwiązania: Stopień niepewności co do rozwiązania wyznacza logiczną kolejność

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

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

Im większa jest niepewność, w tym większym stopniu kompleksowe dzia-ł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.8.

Szczegółowe informacje na temat modeli PMLC przedstawiam w części trze-ciej. Na razie wystarczy, jeśli będziesz miał świadomość, że sam wybór kon-kretnej metodyki nie oznacza jeszcze, że jesteś gotowy do rozpoczęcia prac nadprojektem. Musisz uwzględnić określone czynniki wewnętrzne i zewnętrzne,a następnie dokonać końcowej korekty i modyfikacji wybranej metody. Wszyst-kie te zagadnienia zostaną omówione w części trzeciej.




98 Rozdział 2.

Rysunek 2.8. Proces wyboru modelu PMLC

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, wprowadza-jąc niezbędne modyfikacje do wybranej metody. Modyfikacje te opisuję w roz-działach 9., 10., 11. i 12. Czynniki, które mam tu na myśli, mogą mieć wpływ naTwoją decyzję w kwestii najlepiej dopasowanego modelu PMLC — mogąnawet tę decyzję zmienić. Jeżeli dany model PMLC wymaga na przykład me-rytorycznego zaangażowania klienta, a z Twoich dotychczasowych doświad-czeń wynika, że Twój klient nie jest skory do współpracy, będziesz musiał jakośrozwiązać ten problem — różne możliwości dostępne w takiej sytuacji zostanąomówione w części trzeciej. Na razie przyjrzymy się wspomnianym wyżejinnym czynnikom oraz ich potencjalnemu oddziaływaniu na model PMLC.

Całkowity koszt

Im wyższy całkowity koszt realizacji projektu, tym wyższa końcowa wartośćbiznesowa i tym większe ryzyko związane z projektem. Bez względu na to,jaki model PMLC wybrałeś, warto położyć nieco większy nacisk na plan zarzą-





dzania ryzykiem, niż normalnie wymagałby tego dany model. Jeżeli zarządza-nie ryzykiem nie należy jeszcze do obowiązków konkretnego członka zespołuprojektowego, koniecznie usuń to niedopatrzenie. Straty wykazują dodatniąkorelację z całkowitym kosztem projektu, w związku z czym da się uzasadnićkonieczność ponoszenia większych wydatków na ograniczenie ryzyka, niżtrzeba by przewidzieć w przypadku tańszego projektu.

Czas trwania projektu

Dłuższe projekty charakteryzują się większym stopniem narażenia na zmiany,wyższy wskaźnik 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 (por. rozdział 6.). Bank zakresów to zbiórwszystkich niezrealizowanych pomysłów zmian oraz całkowitego czasu nie-zbędnego na ich integrację z rozwiązaniem. Zadbaj o to, aby klient rozumiałkonsekwencje związane z bankiem zakresu i potrafił zarządzać swoimi wnio-skami o zmianę zakresu projektu. Wysoki wskaźnik rotacji pracowników za-trudnionych przy projekcie może być niezwykle problematyczny, powinie-neś więc poświęcić sporo uwagi wszelkim działaniom, które pozwolą tę rotacjęograniczyć. Zmiany priorytetów projektowych pozostają natomiast pozaTwoją kontrolą. Jedyną rzeczą, którą kontrolujesz, jest harmonogram reali-zacji prac, który powinien być możliwie agresywny.

Stabilność rynku

Każ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.

Technologia

Wszyscy 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.




100 Rozdział 2.

Klimat biznesowy

Im 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 znaczeniuzyskuje stopniowe ujawnianie rozwiązania.

Liczba działów, na które oddziałuje projekt

Wraz 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 uzyskaniarozwią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 14.

Uwarunkowania organizacyjne

Jeż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 (na stronie in-ternetowej Standish Group czytamy: „Nasza organizacja powstała w 1985 rokuz konkretną wizją: gromadzić informacje o autentycznych przypadkach nie-powodzeń biznesowych w branży IT”) wynika, że najczęściej podawanympowodem porażek projektów jest brak wsparcia ze strony najwyższego kierow-nictwa. Może to mieć związek między innymi z prowadzoną reorganizacją.Wyobraź sobie na przykład, że dotychczasowy sponsor Twojego projektu,





który był gorącym zwolennikiem jego realizacji i Twoim mentorem, zostałnagle zastąpiony kimś innym. Czy Twój nowy sponsor będzie postępowałtak samo? Jeżeli tak, to masz szczęście, a jeżeli nie, to masz poważny problem.Będziesz musiał zweryfikować listę potencjalnych zagrożeń i przedstawić pro-pozycje strategii związanych z ograniczaniem ich skutków.

Umiejętności i kompetencje zespołu projektowego

W 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łaszczyźnie teoretycznej, jak i praktycznej.




102 Rozdział 2.

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 9., 10., 11. i 12.

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. Omów przypadki występowania chochlika zakresu w projektach, w któ-rych brałeś udział. Czy menedżerowie tych projektów uporali się z tymchochlikiem? Czy wystąpienie chochlika zakresu da się odwrócić? Od-powiedź uzasadnij.

3. Porównaj definicję zarządzania projektami sformułowaną przez PMIoraz definicję skoncentrowaną na wartości biznesowej i dokonaj ich ana-lizy. Przedstaw listę wad i zalet obu tych definicji.

4. Dla każdego z pięciu modeli PMLC wskaż konkretne punkty, w którychniezbędne jest zaangażowanie klienta. Jakie działania podjąłbyś jako me-nedżer projektu, aby zapewnić sobie to zaangażowanie?

5. Określ, gdzie w ramach poszczególnych modeli PMLC spodziewałbyśsię najwięcej porażek. Uzasadnij odpowiedź.

6. 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ź.

7. 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)

8. Jaki model PMLC zastosowałbyś w przypadku poszczególnych podsys-temów (przyjmowanie zamówień, przetwarzanie zamówień, logistyka,nawigacja, zarządzanie zapasami, lokalizacja punktów produkcyjnych)?Uzasadnij odpowiedź.




SKOROWIDZ

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

Patrz ASD, 450adaptacyjny model

DSDM, 448PMLC, 90, 395–400, 454

cechy, 455monitorowanie i kontrola, 399planowanie, 398rozpoczynanie, 398wady, 458wyznaczanie zakresu, 397zalety, 456

akceptacjadla projektu, 259przez klienta, 374rezultatów

formalna, 351nieformalna, 351

aktualizowanieharmonogramu, 188informacji, 321

alokacjafunkcji, 430zasobów, 299

analityk biznesowy, 155analiza

finansowa, 176kosztów i korzyści, 177

luki, 638modelu CPIM, 634Pareto, 647pola sił, 649, 650progu rentowności, 177przyczyn źródłowych, 643przypadku, 30ryzyka, 113, 120, 175skutków zmiany zakresu, 51SWOT, 529sytuacji bieżącej, 519wartości uzyskanej, EVA, 331–334, 517

AOA, activity-on-the-arrow, 238AON, activity-on-the-node, 239APF, adaptive project framework, 22, 73, 88, 384,

459, 464ciągłe dociekanie, 470cykl życia projektu, 472decyzyjność klienta, 469introspekcja, 470klient i menedżer, 464koncentracja na kliencie, 468kontrakt projektu, 463podstawowe wartości, 468stosowanie, 465wykonanie projektu, 473zakres wersji, 474zespół projektowy, 459

APM, 76, 84–90, 381–405, 697adaptacyjny model PMLC, 396definiowanie cyklu, 401definiowanie iteracji, 401definiowanie zakresu, 401





APMefektywne wykorzystanie, 401iteracyjny model PMLC, 390monitorowanie i kontrola, 403planowanie cyklu, 402planowanie iteracji, 402rozpoczynanie cyklu, 402rozpoczynanie iteracji, 402wdrażanie, 384zamykanie cyklu, 403zamykanie iteracji, 403zespoły projektowe, 386

APPM, agile project portfolio management,697–706cykl procesu, 699etapy, 700niepewność, 702szybkie zmiany, 702

ASD, Adaptive Software Development, 450faza spekulacji, 451faza współpracy, 451faza wyciągania wniosków, 451

asystent techniczny, 195audyt powdrożeniowy, 355, 691

BB2C, business-to-consumer, 491bank zakresów, 293, 339BCG, Boston Consulting Group, 663BCWP, 334BCWS, 334BIC, Business Incubation Center, 742biuro

programów, 574projektów, PO, 548wsparcia projektów, PSO, 571wsparcia projektów przyszłości, 613zarządzania projektami, PMO, 573

biznes, 711BP4SO, 615

analityka biznesowa, 613informatyka, 613procesy biznesowe, 613zarządzanie projektami, 613

bramy etapów, 725budowanie

konsensusu, 283zrównoważonego portfela, 675

budżet projektu, 47burza mózgów, 283

Ccechy projektu, 52, 162cele

kierunkowe, 39ogólne, 39PSO, 580projektu, 485spotkania inicjującego, 273

CF, critical factors, 628charakterystyka projektu ekstremalnego, 480chochlik

cech, 70nadziei, 69wysiłków, 69zakresu, 69

ciągłe doskonalenie procesów, Patrz CPIM, 620CMM, capability maturity model, 131, 599, 625CMMI, capability maturity model integrated, 625COE, center of excellence, 614COP, community of practice, 614COS, conditions of satisfaction, 146, 148, 165CPI, cost performance index, 336, 518, 685–687CPIM, continuous process improvement

model, 620kontrola wyników, 641macierz jakości procesów, 627mapa strefowa, 627ocena i analiza, 634, 638poziomy dojrzałości procesów, 625program doskonalenia, 640stosowanie, 636struktura, 637

CPS, Creative Problem Solving, 279CT, core team, 554

charakterystyka, 554–557członkowie, 555korzystanie, 561wady, 559zalety, 558

CV, cost variance, 334cykl, 401, 488

realizacji APPM, 699realizacji projektu portfelowego, 661sprint, 453szacowania, 228zarządzania projektem, Patrz PMLCżycia projektu APF, 472

czaspracy, 220realizacji projektu, 47, 99, 108, 487trwania działania, 223

efektywność czasu pracy, 223ilość wykorzystanych zasobów, 221




Skorowidz 763

nieoczekiwane zdarzenia, 223prognozowanie, 224zaangażowanie osób, 223zmienność statystyczna, 224

trwania pierwszego cyklu, 492trwania projektu, 220

częstotliwość raportowania, 323częściowe finansowanie, 683członkowie

CT, 555PSO, 594zespołu, 266, 270, 586

czynnikihigieniczne, 111motywujące, 111ryzyka, 174

Ddefinicja

adaptacyjnego modelu PMLC, 396bieżących potrzeb biznesowych, 527biznesowa projektu, 41grup procesów, 104iteracyjnego modelu PMLC, 390PMLC, 76portfela projektów, 44projektu, 38projektu wielozespołowego, 537projektu zagrożonego, 506PSO, 574superzespołu, 562wymagań, 71wymaganych zasobów, 231zarządzania projektami, 64

deklaracjamisji, 637skutków dla projektu, PIS, 50, 289

dekompozycja, 211departamentowa, 215działań, 211, 304fizyczna, 213funkcjonalna, 203, 214hierarchiczna, 203WBS, 210według celów cząstkowych projektu, 214według obszarów geograficznych, 215według procesów biznesowych, 215wymagań, 153, 156

design-build-test-implement, 212diagram

Gantta, 213, 237, 325, 326Ishikawy, 642, 643przepływu, 236

sieci projektu, 236, 237, 308czytanie, 240model punktów węzłowych, 239model strzałkowy, 238następnik, 239PDM, 239poprzednik, 239punkty węzłowe, 240wąskie gardła, 255węzeł działania, 239zależność koniec do końca, 242zależność koniec do początku, 241zależność początek do końca, 242zależność początek do początku, 242

wypalania, 327diagramowanie pierwszeństwa, 239dojrzałość

organizacyjna, CMM, 131, 599, 625procesów i praktyk, 625zarządzania projektami, PMMM, 580, 599

dokumentacja, 353, 354doradztwo, 575, 586doskonalenie

praktyki i procesu, 620procesów biznesowych, 641

dostarczanie rezultatów, 352jednostka po jednostce, 353równoległe, 353stopniowe, 352szokowe, 352

dostawca, 123–37dostępność zasobów

maksymalna, 302planowanie mikropoziomowe, 307

dostosowywanie się, 369DSDM, Dynamic Systems Development

Method, 88, 447działania, 38, 201, 207

czas realizacji, 209definiowanie początku i końca, 209definiowanie rezultatu, 209koszt realizacji, 209niepowtarzalne, 38niezależne, 210podzielne, 254powiązane, 39stan zaawansowania, 208ścieżki krytycznej, 248złożone, 39

dzielenie zasobów, 545dziewięć obszarów wiedzy, 107





Eekstremalne zarządzanie projektami, Patrz xPMekstremalny model

INSPIRE, 483–500PMLC, 92, 408, 480

cechy, 480efektywne wykorzystanie, 411stosowanie, 410wady, 482zalety, 481

elastyczność, 367elastyczny model projektu, 483elementy składowe POS, 166–175

opis celów cząstkowych, 170opis celu głównego, 169opis kryteriów sukcesu, 172opis problemu, 167opis wątpliwości, 173

EPPM, Enterprise-level Project Portfolio Model,710, 720bramy etapów, 725etap analizy, 723etap gromadzenia, 722etap rozpoczęcia, 724etap wdrożenia, 724etap wyboru, 724etap wykonania, 724proces decyzyjny, 720uczestnicy, 726

EPSO, Enterprise PSO, 591scentralizowane, 591zdecentralizowane, 591

eskalacja problemówstrategie zapobiegania, 345, 346

etapanalizy, 723gromadzenia, 722rozpoczęcia, 724wdrożenia, 724wyboru, 724wykonania, 724

etapyprojektu INSPIRE, 484wzrostu PSO, 598zarządzania portfelem, 660

EV, Earned Value, 334EVA, earned value analysis, 331–334, 517ewolucyjny model kaskadowy, 88, 444

Ffazy ASD, 451FFP, firm fixed price, 131filtrowanie informacji, 298

finalizacja harmonogramu projektu, 306formułowanie oczekiwań, 133FTE, full-time equivalent, 563funkcje PSO, 580

Ggenerowanie wartości biznesowej, 71, 498grupa procesów, 76, 104

definiowanie modeli PMLC, 138monitorowania i kontroli, 106planowania, 105rozpoczynania, 106wyznaczania zakresu, 104, 144zamykania projektu, 107

Hharmonogram

działań, 199kosztów, 685pracy, 198projektu, 198, 237, 248, 304

odchylenie, 333, 334ścieżka bliska krytycznej, 252ścieżka krytyczna, 250termin najwcześniejszego końca, 248termin najwcześniejszego początku, 248wskaźnik realizacji, 336zapas czasu działania, 251

terminów najpóźniejszych, 248, 250terminów najwcześniejszych, 247, 249zasobów, 300, 308

hierarchizacjaprojektu, 668

kryteria ważone, 672model porównywania parami, 672niezbędne, ważne, przydatne, 671Q-sort, 670ryzyko-korzyści, 674wymuszony ranking, 669

wymagań projektu, 491, 496histogram, 646

w analizie Pareto, 648historia ryzyka, 419HRMS, human resource management system,

95, 388

Iidentyfikacja

CF, 637procesów biznesowych, 637ryzyka, 114wymagań, 157




Skorowidz 765

IIBA, 70informacje o stanie zaawansowania, 208inicjacja, 485inkubacja, 493INSPIRE, 483–500

etap inicjacji, 485etap inkubacji, 493etap przeglądu, 495etap spekulacji, 489

integracja, 108danych, 337wartości uzyskanej, 336wykresów, 336

inżynier procesu biznesowego, 155IRACIS, 63iteracje, 401iteracyjny model PMLC, 88, 390–395

etap monitorowania i kontroli, 395etap planowania, 393etap rozpoczynania, 394etap wyznaczania zakresu, 392etap zamykania, 395model RUP, 436, 443–446stosowanie, 441wady, 440zalety, 438

JJAD, joint applications design, 192jakość, 109

procesu, 46produktu, 46

JRP, joint requirements planning, 192

Kkamień milowy, 328kaskadowy model

ewolucyjny, 88, 444stopniowy, 433

kategorieinwestycyjne projektów, 666, 678projektów, 665zasobów, 229

klasyfikacja projektów, 51–54, 161klient, 155, 372

akceptacja, 374odpowiedzialność, 374poczucie komfortu, 373

klimat biznesowy, 711kojarzenie personelu z działaniami, 230kolejność działań, 248kolorowe karteczki, 190

komfort klienta, 373kompletowanie dokumentacji, 353komunikacja, 111, 371

poza zespołeminteresariusze, 299

w zespole, 293bezpośrednie spotkania, 294materiały w formie pisemnej, 295poczta elektroniczna, 295telefon, 296wideokonferencje, 295

konsultacje, 575, 581konsultant do spraw planowania projektowego, 195kontrola projektu, 238kontrolowanie postępów prac, 316

narzędzia, 350procesy, 350szablony, 350

konwencje diagramowania, 241korzyści biznesowe, 691koszt

odchylenie, 334rzeczywisty, 235, 334wskaźnik realizacji, 336

kosztykontraktu, 132projektu, 47, 108, 233, 306, 487

prognoza budżetowa, 234prognoza definitywna, 234prognoza rzędu wielkości, 234

kryteria kompletności WBS, 207, 211kryteria ważone, 673krzywa

„S”, 332AC, 335bólu, 185EV, 335PV, 335zaawansowania, 332

księga projektów, 199

Llean, 389liczba wymagań, 73limity zasobów, 40liniowy model PMLC, 82, 416–426

cechy, 417stosowanie, 423wady, 422wariant FDD, 434zalety, 420

lista rodzajów ryzyka, 118luka dojrzałości, 638





Mmacierz

BCG, 663dystrybucji projektów, 665–679jakości procesów, 627modeli PMLC, 365RASCI, 710, 728ryzyka, 119ryzyko-korzyści, 674, 678, 682umiejętności, 230

maksymalna dostępność zasobów, 302mapa strefowa, 627, 629, 631mapowanie

grup procesów, 139obszarów wiedzy, 137, 138

maska zachowań, 272MBO, management by objectives, 657menedżer

działania, 309odpowiedzialny za projekt, 196pakietu roboczego, 309portfela, 662, 692projektu, 153, 155, 194, 265, 275, 685ST, 564zasobów, 155

metodadekompozycji wymagań, 157dostarczania rezultatów, 352gromadzenia wymagań, 543kolejnych ulepszeń, 203pseudokodu, 203

metody, Patrz także modelAPM, 84MPx, 94PSO, 583TPM, 79xPM, 90

mikrozarządzanie, 210minimalizowanie ryzyka, 121model

adaptacyjna struktura projektu, APF, 22, 73,88, 384, 459, 464

adaptacyjne tworzenie oprogramowania, ASD,450

cele, strategie, taktyki, OST, 714, 719ciągłe doskonalenie procesów, CPIM, 620cykl zarządzania projektem, PMLC, 63, 76,

96, 390, 396, 508, 536dojrzałość organizacyjna, CMM, 131, 599, 625dojrzałość zarządzania projektami, PMMM,

580, 599DSDM, 88, 447ekstremalne zarządzanie projektami, xPM,

76, 90–94, 407–411

ekstremalny PMLC, 92, 408, 480kaskadowy, 88, 443, 434liniowy PMLC skoncentrowany na cechach,

FDD, 434ocena dojrzałości zarządzania projektami,

PMMA, 629podejmowania decyzji, 280porównywania parami, 672projektuj-buduj-testuj-wdrażaj, 214prototypowy, 443RUP, 436, 443–446Scrum, 88selekcji Grahama-Englunda, 666, 678, 704, 721strzałkowy, TOA, 238TI/OST, 714WBDC, 716, 734, 740wzrostu i przetrwania, 666zarządzanie portfelem projektów na

poziomie przedsiębiorstwa, EPPM, 710,720

zwinne zarządzanie projektami, APM, 76,84–90, 381–405, 697

moderowane sesje grupowe, 158monitorowanie

i kontrola, 106, 315–348, 399, 413narzędzia, 316prac i postępów, 134procesy, 316ryzyka, 122stanu wykonania, 135szablony, 316wniosków o zmianę wymagań, 134

MPx, 76, 94–96, 407–414

Nnajlepsze praktyki, 243narzędzia

informatyczne, 575, 584planistyczne, 188

narzędziePERT, 188

narzędzie graficznediagram Gantta, 325diagram wypalania, 327raport-semafor, 325wykres trendu odchyleń, 328

negocjacje kontraktowe, 132niepełne obsadzanie projektów, 683niepewność, 186, 363, 369, 372–378, 481, 702NPK, termin najpóźniejszego końca, 249NPP, termin najpóźniejszego początku, 249NWK, termin najwcześniejszego końca, 248NWP, termin najwcześniejszego początku, 248




Skorowidz 767

Oobliczanie ścieżki krytycznej, 250ocena

dojrzałości zarządzania projektami, PMMA,629

dostawców, 126kompetencji menedżera projektu, 605, 606kompletności RBS, 161odpowiedzi, 128ryzyka, 118zgodności strategicznej projektu, 668

oczekiwania klienta, 145odchylenia

gwałtowne, 329negatywne, 324od planu, 320, 323pozytywne, 323

odchylenieharmonogramu, 333, 334kosztu, 332, 334standardowe, 328

odpowiedzialność klienta, 374ograniczanie ryzyka, 121ograniczenia, 243

czasowe, 246logiczne, 244międzyprojektowe, 245produktowe, 160swobodne, 243techniczne, 243związane z zarządzaniem, 245

okazje rynkowe, 712określanie rezultatów biznesowych projektu, 149opieka merytoryczna, 575opóźnienia

od planu, 329sukcesywne, 329

opracowanie struktury WBS, 513oprogramowanie, 187OST, Objectives/Strategies/Tactics, 719

struktura zależności, 719ośrodek inkubowania przedsiębiorczości, BIC,

742otoczenie biznesowe, 711

Ppakiet roboczy, 202, 216

arkusz przydziału, 311cel, 309format, 310raport, 312

PDM, precedence diagramming method, 239PDS, project definition statement, 193, 276pięć

grup procesów, 104modeli PMLC, 500

PIS, 50, 82plan

naprawczy, 529pracy, 311utworzenia PSO, 600wdrożenia PSO, 611

planowanie, 105, 191, 398bieżące, 455cyklu INSPIRE, 494fazy, 411mikropoziomowe, 307na bieżąco, 462późniejszych cykli, 492projektu, 183–261narzędzia, 189sesji, 193zasobów, 232

planowany kosztplanowanej pracy, 334wykonanej pracy, 334

PMBOK, 24PMCA, Project Manager Competency

Assessment, 605PMI, 24, 26, 61PMLC, project management life cycle, 63, 76, 96,

390, 396, 508, 536adaptacyjny, 90, 162, 396, 454dla procesu APPM, 700ekstremalny, 92, 162, 408, 480iteracyjny, 88, 390, 436liniowy, 82, 162, 417porównanie, 415stopniowy, 83, 162, 426

PMMA, project management maturityassessment, 629

PMMM, Project Management Maturity Model,580, 599

PMO, project management office, 419, 573PMP, Project Management Professional, 585PO, project office, 548

charakterystyka, 549korzystanie, 553wady, 552zalety, 551

poczta elektroniczna, 295podejmowanie decyzji

model dyrektywny, 280model konsultacyjny, 281model partycypacyjny, 281





podejściedo tworzenia WBS, 212z góry na dół, 205

podsystemlogistyczny, 31lokalizacji punktów produkcyjnych, 30nawigacji, 31przetwarzania zamówień, 31zarządzania zapasami, 32

podzespół, 307podział wymagań, 74pokonywanie problemów, 278porażki projektów, 371, 507, 592–597porównanie modeli PMLC, 415portfel projektów, 44, 577, 657–706POS, project overview statement, 62, 147, 149, 165,

475akceptacja, 177elementy składowe, 166kryteria akceptacji, 180załączniki, 175

poszukiwanie sytuacji wygrany-wygrany, 282potencjał przedsiębiorstwa, 713poziomowanie zasobów, 299, 301, 302poziomy dojrzałości procesów, 625–627PPMP, Project Portfolio Management Process, 655PQM, process quality matrix, 627praktyka zarządzania projektami, 622prawa Murphy’ego, 223prawdopodobieństwo

osiągnięcia korzyści biznesowych, 674sukcesu technicznego, 674

priorytety zmiennych trójkąta, 50problem biznesowy, 61proces

biznesowy, 637narzędzia, 642

decyzyjny, 720dekompozycji, 202dynamicznego zarządzania ryzykiem, 514gwarantowania jakości, 110interwencyjny, 519kontroli jakości, 110oceny dostępnych opcji, 528planowania jakości, 109poziomowania zasobów, 301weryfikacji pierwotnego celu, 525wyznaczania zakresu projektu, 146, 147zarządzania projektami, 620zarządzania zmianami, 291zarządzania zmianami zakresu, 514

profilowanie złożonych projektów, 729prognozowanie

czasu trwania działania, 221dane historyczne, 224

podobieństwo działań, 224rady ekspertów, 225technika 3 punktów, 226technika delficka, 225technika delficka uśredniająca, 227

ilości potrzebnych zasobów, 229kosztów projektu, 233

program, 43doskonalenia procesów, 619

project champion, 194projekt, 21, 38, 200, 548, 554, 658–660

cechy, 52cel ogólny, 39czas realizacji, 40, 47, 99harmonogram, 47hierarchizacja, 669klasyfikacja, 51koszt realizacji, 47, 98limity zasobów, 40sekwencja działań, 38typy, 54wymagania, 70zakres, 46zarządzanie zmianami zakresu, 288zasoby, 48

projektyaktywne, 684APM, 85, 101badawcze, 667badawczo-rozwojowe, 410infrastrukturalne, 667MPx, 76, 90–94, 407–411operacyjne, 666opóźnione, 338polegające na rozwiązaniu problemu, 410portfelowe, 658przetrwania, 666taktyczne, 666TPM, 81, 101, 144–359

monitorowanie i kontrola, 315–348planowanie, 183–261uruchamianie realizacji, 263–314wyznaczanie zakresu, 144–181zamykanie projektu, 349–359

utrzymania, 667wielozespołowe, 537

definicja, 537dzielenie zasobów, 545gromadzenie wymagań, 543klasyfikacja, 546raportowanie, 544zarządzanie, 539zarządzanie zmianami zakresu, 544

wprowadzające nowe produkty, 667




Skorowidz 769

wyprzedzające harmonogram, 338wzrostowe, 666xPM, 76, 90–94, 407–411zagrożone, 505–507

analiza SWOT, 529analiza sytuacji bieżącej, 519analiza wartości uzyskanej, 517dynamiczne zarządzanie ryzykiem, 514działania korygujące, 527, 528gromadzenie wymagań, 512opracowywanie WBS, 513plan naprawczy, 529, 530przyczyny porażek, 507–510przyczyny źródłowe, 521–524strategie interwencyjne, 518strategie prewencyjne, 511szablon procesu interwencyjnego, 531zarządzanie zmianami zakresu, 514

złożone, 361strategiczne, 666

projektuj-buduj-testuj-wdrażaj, 212propozycja projektu

format, 259treść, 257

prototyp produkcyjny, 442prototypowy model PMLC, 442przedsiębiorstwo

cele, 716klimat biznesowy, 711macierz projektów RASCI, 728misja, 715okazje rynkowe, 712profilowanie złożonych projektów, 729potencjał, 713strategie, 716taktyki, 718wizja, 715

przegląd stanu projektu, 149, 495przesuwanie daty zakończenia projektu, 303przyczyny porażek, 592przypadki użycia, 159przypisywanie zasobów, 199, 493PSO, project support office, 571–616

centralne, 589definicja, 574doradztwo, 575, 577, 586etapy wzrostu, 598formułowanie celów, 580funkcje, 580, 608funkcjonalne, 589konsultacje i opieka merytoryczna, 575, 576,

581korporacyjne, 589, 591miejsce w organizacji, 590, 608

misja, 579, 608narzędzia informatyczne, 575, 576, 584nazewnictwo biur, 578plan wdrożenia, 611–613planowanie, 600portfel usług, 575powołane na czas określony, 589powołane na stałe, 589proaktywne, 588projekty zagrożone, 533reaktywne, 588regionalne, 589rzeczywiste, 588statut projektu, 602struktura organizacyjna, 588szkolenia, 575, 576, 584trudności tworzenia, 610tworzenie, 598tworzenie metod i standardów, 575, 576, 583tworzone na czas określony, 574tworzone na stałe, 574wdrażanie, 612wirtualne, 588wspieranie projektów, 575, 576, 580zależności międzyprojektowe, 589zarządzanie portfelem projektów, 692

punktkontrolny klienta, 478progowy zadania, 222węzłowy, AON, 239

PV, Planned Value, 334

QQ-sort, 670

Rraport Standish Group, 371, 592raportowanie, 544

o odchyleniach, 319o postępach, 317

aktualizowanie informacji, 321częstotliwość, 323dane historyczne, 322narzędzia graficzne, 325odchylenia od planu, 323prognozy, 322

o stanie portfela, 685CPI, 685SPI, 685wskaźnik realizacji harmonogramu, 685wskaźnik realizacji kosztów, 685wykresy trendu w punktach kontrolnych, 686





raportowanieo stanie projektu, 204o wyjątkach, 318

raportybieżące, 317skumulowane, 318zamykające, 357

raporty-semafory, 318, 325RBS, requirements breakdown structure, 73, 152,

200–205, 376reakcje na zagrożenia, 121reguła S.M.A.R.T., 170rejestr problemów, 340relacje

między działaniami, 236, 243zależności, 241

rezerwa menedżerska, 255, 256, 292rodzaje

kontraktów, 131projektów wielozespołowych, 546raportów, 317

ROI, return on investment, 177rozpoczęcie prac projektowych

narzędzia, 264procesy, 264szablony, 264

rozpoczynanie, 106, 263–314, 398fazy, 412

rozwiązywanie konfliktówposzukiwanie sytuacji wygrany-wygrany, 282unikanie, 282walka, 282współpraca, 282

równoważenie portfela, 676częściowe finansowanie, 683model selekcji Grahama-Englunda, 678niepełne obsadzanie projektów, 683

RUP, Rational Unified Process, 436, 443–446faza konstrukcji, 447faza opracowywania, 447faza przekazania systemu, 447faza rozpoczęcia, 447

ryzyko, 369analiza, 113arkusz analizy, 120czynniki, 116identyfikacja, 114monitorowanie, 122ocena, 115, 118ocena dynamiczna, 119ocena statyczna, 119ograniczanie, 121

rzeczywiste biura wsparcia projektów, 588rzeczywisty koszt wykonanej pracy, ACWP, 334

SS.M.A.R.T., 487schemat

blokowy, 645, 646restrykcyjny trendu, 516

Scrum, 453, 454SEI, 598sekwencja działań, 38sesja

COS, 150, 152planistyczna, 199planowania projektowego, 192

asystent techniczny, 195kierownicy liniowi, 196konsultant, 195menedżer odpowiedzialny za projekt, 196menedżer projektu, 194nadzorca procesu, 196plan sesji, 198prowadzący, 194przedstawiciel klienta, 195rezultaty, 198statut projektu, 193zarządzający zasobami, 196zespół projektowy, 195

planowania wymagań, 192projektowania aplikacji, 192wspólnego planowania

tworzenie WBS, 207sieć relacji między działaniami, 236składowe modelu WBDC, 740skracanie harmonogramu, 253, 255SME, subject matter experts, 129specyfikacja, 375

funkcjonalna, 46spekulacja, 489SPI, schedule performance index, 336, 517,

685–690spis narzędzi, 642sponsor, 155, 274, 692spotkania zespołu, 284

dotyczące zakresucele, 150efekty, 152grupy, 150program, 151

inicjujące, 274cel, 273definicja projektu, 276harmonogram projektu, 277miejsce, 274program sesji, 275uczestnicy, 273




Skorowidz 771

monitorującecel, 341częstotliwość, 343lista uczestników, 341zakres zagadnień, 342

weryfikacyjne, 286spójność zespołu, 370sprawdzanie koncepcji projektu, 488Sprint backlog, 453ST, super team, 561

charakterystyka, 562–565korzystanie, 567wady, 566zalety, 565

standardy PSO, 583statut projektu, 193, 694

ekstremalnego, 486POS, 147utworzenia PSO, 602

stopieńpewności, 77skomplikowania, 364, 369, 372, 375–378

stopniowy modelkaskadowy, 433PMLC, 83, 426–501, 432

cechy, 427stosowanie, 432wady, 429zalety, 427

strategieinterwencyjne, 506, 518portfela, 662

kategorie inwestycyjne projektów, 666macierz BCG, 663macierz dystrybucji projektów, 665model wzrostu i przetrwania, 666

prewencyjne, 511zapobiegania eskalacji problemów, 346

strukturabiura projektu, 548, 549organizacyjna PSO, 588podziału pracy, Patrz WBSpodziału wymagań, RBS, 73, 153, 200–205,

376podziału zasobów, 231superzespołu, 561, 562zależności w modelu OST, 719zespołu głównego, 554, 555

studium wykonalności, 176superzespół, ST, 561SV, schedule variance, 334system HRMS, 388szablon

analizy pola sił, 650

analizy przyczyn źródłowych, 643czynników ryzyka, 117diagramu Ishikawy, 643identyfikacji ryzyka, 115procesu interwencyjnego, 531

szeregowanieprogramów doskonalenia, 639projektów, 682rezultatów, 492

szkolenia, 575, 584Szybka Pizza, 30

Śścieżka

bliska krytycznej, 252krytyczna, 250

Ttechnika

3 punktów, 227delficka, 226

technologia RFID, 95tempo zaawansowania prac, 331teoria motywacji, 111termin

najwcześniejszego końca, 248najwcześniejszego początku, 248

TOA, model strzałkowy, 238TPM, 65, 68, 76, 79–84, 141

liniowy model PMLC, 416stopniowy model PMLC, 426

tradycyjne zarządzanie projektami, Patrz TPMtrend

odchyleń, 328odchylenia gwałtowne, 329opóźnienia sukcesywne, 329przebieg sukcesywny, 330zmiany harmonogramu, 330

wskaźnika SPI, 690wskaźników, 687

trening wrażliwości, 272trójkąt zakresu projektu, 45, 48–51, 488tworzenie

biblioteki szablonów, 418biur zarządzania projektami, 572diagramu sieci, 236, 238harmonogramu, 237

działań, 304projektu, 247zasobów, 300

metod i standardów, 575, 583modelu komunikacji, 293





tworzenieplanu cyklu, 494planu projektu, 186POS, 149prototypu rozwiązania, 159PSO, 598, 600RBS, 152, 158rejestru problemów, 340statutu projektu POS, 164strategii portfela, 662struktury zarządzania projektem, 542szczegółowego planu, 192warunków satysfakcji, 146–149, 490WBS, 204, 207, 212WBS na podstawie RBS, 201

twórcze pokonywanie problemów, 279typy

ograniczeń czasowych, 246projektów, 54wymagań, 159

Uuczestnicy modelu EPPM, 726umiejętności, 230

kategorie, 230poziomy, 231

uruchamianie realizacji, 106, 263–314, 398usługi

BP4SO, 614PSO, 575

użytkownik, 155

Wwartości progowe wskaźników, 652wartość

biznesowa, 63, 378, 498dodana, 366planowana, 334uzyskana, 334WBS, 211

warunki satysfakcji, 490COS, 146

wąskie gardła, 255WBDC, 716, 734, 740

obszar biznesu i przedsiębiorczości, 742obszar edukacji, 741obszar studentów i pracowników, 742ośrodek inkubowania przedsiębiorczości, 742

WBS, 198–201, 513kaskadowa metodyka rozwoju systemu, 219planowanie, 203podejście czynnościowe, 212, 214podejście organizacyjne, 213, 215

podejście przedmiotowe, 212prezentacja graficzna, 216projektowanie architektury, 203przykład budowy domu, 217raportowanie o stanie projektu, 204testowanie kompletności, 207

wdrażanie modeli APM, 384weryfikacja pierwotnego celu biznesowego, 526węzeł działania, 240wideokonferencje, 295wirtualne biuro wsparcia projektów, 588wnioski z poprzedniego cyklu, 495wskaźnik realizacji

harmonogramu, 336, 686kosztów, 333, 336, 686wydajności, 333

wspieranie projektów, 575, 580, 586wstępny harmonogram projektu, 247wybór

członków zespołu, 270dostawcy, 129, 130modelu PMLC, 97–100, 162–164, 542, 593modelu zarządzania projektem, 211procesów biznesowych, 638sposobu zarządzania projektem, 162struktury, 568zewnętrznego wykonawcy, 271zrównoważonego portfela, 703

wydajność, 187wygładzanie, 304wykres

kontrolny, 645poziomów dojrzałości procesu i praktyki, 633przebiegu pracy, 649punktowy, 649, 650trendu, 687–689trendu odchyleń, 332, 336

wykrywanie odchyleń, 320wymagania, 153, 367

funkcjonalne, 160globalne, 160niefunkcjonalne, 160projektu, 70–75

wymuszony ranking, 669, 677wynagrodzenie, 131wyznaczanie zakresu, 104, 144–181, 397

spotkanie, 149wzór statutu projektu, 167

XxPM, 76, 90–94, 407–411

ekstremalny model INSPIRE, 483–500ekstremalny model PMLC, 408




Skorowidz 773

etap Incubate, 483etap INititate, 483etap REview, 483etap SPeculate, 483monitorowanie i kontrola, 413planowanie fazy, 411rozpoczynanie następnej fazy, 412zakres fazy, 411zamykanie fazy, 413zamykanie projektu, 414

Zzaangażowanie klienta, 372, 484zadanie, 202, 207

pakiet roboczy, 216zakontraktowanie dostawcy, 129zakres

fazy, 411prac, 46projektu, 46, 108, 288, 397

narzędzia, 144procesy, 144schematy, 144

projektu TPM, 143zależności między RBS a WBS, 212zależność, 241

koniec do końca, 242koniec do początku, 241początek do końca, 242początek do początku, 242

zamykaniefazy, 413kontraktu z dostawcą, 136projektu, 107, 349–359, 404, 414, 691

akceptacja formalna, 351akceptacja nieformalna, 351audyt powdrożeniowy, 355dokumentacja, 353, 354dostarczanie rezultatów, 352raport zamykający, 357

zaopatrzenie, 123ocena dostawców, 126poszukiwanie dostawców, 123wybór dostawcy, 129zarządzanie relacjami z dostawcą, 133

zapas czasu działania, 251, 303całkowity, 251swobodny, 251

zapytanieo informację, 124ofertowe, 123, 125

zarządzaniebankiem zakresów, 339chochlikami, 68czasem, 108eskalacją problemów, 344integracją, 108jakością, 109komunikacją, 111, 293, 297kosztami, 108oczekiwaniami klienta, 145portfelem projektów, 387, 657–706, 710–746

aktywne projekty, 684budowanie zrównoważonego portfela, 675cykl realizacji projektu, 661częściowe finansowanie, 683definicja, 660funkcje PSO, 692hierarchizacja projektu, 669kategorie inwestycyjne projektów, 678macierz dystrybucji projektów, 677macierz ryzyko-korzyści, 678menedżer portfela, 662model selekcji Grahama-Englunda, 678na poziomie przedsiębiorstwa, EPPM,

710, 720niepełne obsadzanie projektów, 683ocena zgodności strategicznej, 668projekt aktywny, 661projekt odwołany, 662projekt ukończony, 662projekt uszeregowany, 661projekt wybrany, 661projekt zaproponowany, 661projekt zawieszony, 662projekt zgodny ze strategią, 661przygotowanie projektu, 693przyznanie funduszy, 669raportowanie o stanie portfela, 685równoważenie portfela, 676składanie propozycji projektu, 695stan projektu, 684statut projektu, 694strategia portfela, 662zamykanie projektów, 691zwinne, 697

projektami, 59, 61adaptacyjny model cyklu, 89, 395aktywnymi, 683, 705definicja, 64dostosowywanie się, 369ekstremalne, xPM, 68, 407elastyczność, 368grupy procesów, 103iteracyjny model cyklu, 88, 390





zarządzanieprojektami

lean, 389model ekstremalny, 92niepewność, 369porażka, 371ryzyko, 369tradycyjne, TPM, 68tworzenie biur, 572stopień skomplikowania, 369wielozespołowymi, 539–546zamykanie projektu, 404, 414złożonymi, 361zwinne, APM, 68, 381

przez cele, 657realiami projektów, 503relacjami z dostawcą, 133relacjami z interesariuszami projektu, 137ryzykiem, 112wiedzą, 612zagrożonymi projektami, 511zakresem, 108zaopatrzeniem, 123zasobami, 299zasobami ludzkimi, 110zespołowe problemami, 344zmianami zakresu, 288, 544

zasady pracy w zespole, 278zasoby, 48, 198, 299

ludzkie, 110, 229maksymalna liczba jednostek, 302materiały, 229pomieszczenia, 229środki pieniężne, 229unikalne, 244wyposażenie, 229

zastosowania WBS, 203zatwierdzanie statutu POS, 179zdobywanie informacji, 26zespołowe zarządzanie problemami, 344zespół

główny, CT, 554klienta, 269projektowy, 195, 264

częstotliwość spotkań, 284komunikacja, 293koordynator spotkania, 285lista cech członków, 267maska zachowań, 272plan rozwoju, 272plan spotkań, 285pomieszczenie, 287protokoły spotkań, 285selekcja członków, 266spotkanie inicjujące, 272trening wrażliwości, 272w APF, 459zarządzanie komunikacją, 293zasady pracy, 278

zintegrowany model dojrzałości organizacyjnej,CMMI, 625

zlecanie zadań, 269zmiana, 377

harmonogramu, 330zakresu projektu, 288, 291

zmienne opóźnione, 247zmienność, 481zwinne

zarządzanie portfelem projektów, Patrz APPMzarządzanie projektami, Patrz APM

zwinny portfel, 698zwrot z inwestycji, 177




http://program-partnerski.helion.pl

Tytuł oryginału: Effective Project Management: Traditional, Agile, … · 2021. 3. 17. · Tytuł...

Documents

Transcript of Tytuł oryginału: Effective Project Management: Traditional, Agile, … · 2021. 3. 17. · Tytuł...