Kierowanie projektem w metodyce Zarządzania Projektami PRINCE 2 – część 1

W dotychczasowych artykułach o Zarządzaniu Projektami (ang. Project Management) zaprezentowane zostały następujące zagadnienia:

  • Wymiary projektu: Produkt, Czas, Budżet i Jakość – parametry definiowania projektu i podstawa do jego oceny i korygowania.
  • Metodyka Zarządzania Projektami
    PRINCE 2 – obowiązkowa metodyka rządu brytyjskiego.
  • Pierwsza faza przedsięwzięcia
    – definicja projektu w Dokumencie
    Inicjacji Projektu (ang. PID).
  • Organizacja projektu
    – zdefiniowanie struktur
    potrzebnych w projektach,
    z określeniem roli poszczególnych ciał w całym cyklu życia projektu.
  • Planowanie projektu – opracowanie
    „mapy przyszłości” dla realizacji
    przedsięwzięcia.

Wszystkie powyższe fazy mają na celu jak najlepsze przygotowanie projektu przed faktyczną jego realizacją. Wszystko jest już przygotowane, pora przystąpić do pracy. Wykonawcy (w metodyce PRINCE 2 określani jako specjaliści techniczni) wykonują kolejne produkty, natomiast Szef Projektu musi wykazać się umiejętnością dowodzenia zespołem i reagowania na bieżące zdarzenia.

What’s get measured, get’s done (John Peters)
Co da się zmierzyć, da się też wykonać

Droga do celu

Nie przypadkiem w kontekście kierowania realizacją projektu pojawiło się określenie ze sfery militarnej: dowodzenie. O ile dotychczasowe prace Szefa Projektu, a więc koncepcję, organizację
i planowanie, można porównać do wysiłku sztabowców wojskowych, o tyle teraz stają się one zbliżone do działań dowódcy liniowego.

Zadaniem Szefa Projektu – najważniejszym, a nawet jedynym – jest osiągnięcie celów projektu. Wszelkie inne aspekty oceniania jego sprawności to jedynie miary przydatne w trakcie działań.

Jak wspomniano na początku cyklu, zadaniem Szefa Projektu – w skrajnym ujęciu można powiedzieć, iż najważniejszym a nawet jedynym – jest osiągnięcie celów projektu. Wszelkie inne oceny jego sprawności to jedynie miary przydatne w trakcie działań. Szef Projektu rozliczany jest zawsze i przede wszystkim z uzyskanego rezultatu. W niektórych przedsięwzięciach jest to właściwie jedyna zasadna miara, w innych – najważniejsza. Korzystając znów z analogii militarnej można przypomnieć, iż w ostatniej dotąd z wielkich wojen wszystkie strony właściwie stosowały zasadę „wojny totalnej”, mając świadomość, iż zapasy te są
"na śmierć i życie". Jedynym interesującym rezultatem było zwycięstwo. Mimo to nietrudno dostrzec wielkie różnice w sposobie realizacji tego celu przez dowódców poszczególnych stron:

  • Jedni dążyli do zwycięstwa kosztem
    zmasowanego uderzenia wielkich sił
    ludzkich, osiągając powodzenie przy
    wielkich stratach.
  • Drudzy preferowali powszechne
    zastosowanie techniki, oszczędzającej
    wysiłek żołnierzy.
  • Jeszcze inni dążyli do jak najbardziej
    starannego przygotowania operacji,
    doprecyzowania każdego szczegółu,
    po czym osiągali zwycięstwo przy
    stosunkowo niewielkich stratach
    własnych.

Każda z tych metod ma swoje zalety, każda może prowadzić do sukcesu, a więc spełnienia zakładanych celów. Nie inaczej oczywiście jest w projektach cywilnych i współczesnych: wiele podejść może równie skutecznie prowadzić do sukcesu. Preferencje zależą – podobnie jak na wojnie – nie tylko od upodobań dowódcy, ale przede wszystkim od posiadanego potencjału. No i nie bez znaczenia jest tradycja prowadzenia przedsięwzięć, jakże widoczna przy porównaniu projektów w naszym kraju i w krajach zachodnich, coś co określa się mianem „kultury organizacji”.

Wymiary sukcesu

Każdy projekt jest mierzony w trzech głównych wymiarach: Produkt, Czas i Budżet. Niedotrzymanie zaplanowanych parametrów w którymkolwiek z tych wymiarów musi być traktowane jako równie poważna porażka projektu, jak jego przerwanie.

Przypomnijmy, iż Szef Projektu otrzymuje zadanie do wykonania opisane przy użyciu trzech wymiarów: produkt, czas i pieniądze. Często dodaje się też wymiar czwarty – Jakość.Rys. 1: Wymiary projektu

Wymiary projektu

Osiągnięcie celów projektu oznacza zrealizowanie wszystkich trzech wymiarów: dostarczenie uzgodnionych produktów, ale w założonym koszcie i z dotrzymaniem terminu. Wykonanie wspaniałych dzieł przy wielokrotnym zawyżeniu kosztów jest na ogół równie poważną porażką projektu, jak nie zrobienie większości produktów, podobnie jak niedotrzymanie terminów. Skrajnym przykładem są projekty o charakterze imprezowym, w których zadaniem jest przygotowanie imprezy, np. wielkiego koncertu dla tysięcy ludzi. Wymaga to przygotowania bardzo licznych produktów: sceny, trybun, środków bezpieczeństwa, toalet, nagłośnienia, mechanizmów promocyjnych, dodatkowych atrakcji, oprawy telewizyjnej, sprzedaży biletów i mnóstwa innych elementów udanej imprezy. Uzyskanie tego wszystkiego choćby dzień po zaplanowanym terminie jest całkowitym fiaskiem przedsięwzięcia, nawet jeśli wszystkie produkty są perfekcyjne i niedrogie.

Pamiętajmy więc, że niedotrzymanie zaplanowanych parametrów
w którymkolwiek z trzech wymiarów jest równie wielką porażką projektu, jak jego przerwanie. Wyobraźmy sobie, że zainstalowany serwer WWW sprawnie obsługuje 100 użytkowników, ale
"zatyka się" przy tysiącu chętnych. Albo też że wdrożenie systemu zarządzania o planowanych kosztach 200 tys. złotych w rzeczywistości kosztuje dwa razy tyle. Czy wreszcie że oprogramowanie oddane do testowania zawiera setki błędów, wymagających kilku iteracji testowania i poprawek. Każdy z tych przypadków jest równie dużą porażką projektu i jego kierownictwa, jak zlikwidowanie przedsięwzięcia przed końcem.

Metodyka PRINCE 2 podkreśla, iż równie ciężkim grzechem projektu jest
nie uzyskanie zakładanych korzyści biznesowych przez wykonany produkt. Spojrzenie takie niezwykle rzadko spotyka się w projektach informatycznych. Kto z nas rozpoczynając projekt dostał dokument opisujący biznesowe cele tworzonego systemu, z określeniem możliwie precyzyjnych miar biznesowych? Większość projektów rozpoczyna się po określeniu licznych i drobiazgowych zadań technicznych, a przecież nie o to chodzi. Można na przykład uznać
"zapewnienie obsługi klientów" jako cel projektu, nie wspominając iż faktycznym celem jest uzyskanie możliwości obsługi dwukrotnie większej liczby klientów czy też skrócenie o połowę czasu ich oczekiwania na obsługę.

Ten biznesowy aspekt powodzenia projektu jest jednym z najważniejszych elementów wyróżnianych przez metodykę PRINCE 2. Każdy projekt powinien być uruchamiany z perspektywą uzyskiwania korzyści biznesowych, zaś do obowiązków Szefa Projektu należy kontrolowanie przez cały czas, czy korzyści te zostaną zyskane. Szersze omówienie tych zagadnień znalazło się w pierwszym artykule niniejszego cyklu, omawiającym uzasadnienie biznesowe i Dokument Inicjacji Projektu.

Wymiary w praktyce

W praktyce kierowania projektem Szef nieustannie musi podejmować decyzje o kompromisach: z czego rezygnować na rzecz ocalenia innych korzyści. Najczęstszym problemem są opóźnienia terminów, z rzadka tylko mieszczące się w granicach tolerancji. Praktyczną zasadą jest, iż dla dotrzymania dat rezygnuje się z części umówionych produktów, niekiedy zaś
– z ich odpowiedniej jakości. Oznacza to, że klient otrzymuje mniej produktów lub niezupełnie takie, jakich oczekiwał, jednak bez opóźnień. Prawda ta jest może brutalna, ale niezwykle życiowa. Podkreślić trzeba, iż tego rodzaju kompromis MUSI być podjęty w porozumieniu z klientem projektu, koniecznie poprzez procedurę Kontroli Zmian (omawianej w kolejnym artykule). Praktyka wskazuje, iż doświadczony klient bez wielkich oporów poświęca część oczekiwanych produktów na rzecz dotrzymania uzgodnionego terminu. Niektórzy twierdzą, iż po umiejętności zawierania takiego kompromisu poznać klasę klienta: czy jest to profesjonalista, czy też półamator. Bo dla praktyków jasne jest, iż kompromisy i rezygnacje są częścią rzeczywistości, do czego trzeba umieć się dostosować i wybierać zgodnie z priorytetami.

Drugim ewentualnym kompromisem jest dotrzymanie parametrów produktów i czasu przy wzroście kosztów projektu. Taka zmiana jest jeszcze łatwiejsza do przeprowadzenia z
klientem – profesjonalistą, zaś jeszcze trudniejsza – z amatorem. Tych ostatnich trzeba przestrzec, iż zwykle wykonawca ma sto sposobów wykazania, iż opóźnienia czy gorsza jakość wynikają nie z jego winy, a więc nie on poniesie konsekwencje niedotrzymania parametrów. Tylko więc brak realizmu i pragmatyki może skłaniać klienta do domagania się realizacji wszystkiego bez odstępstw, włącznie z grożeniem karami czy zerwaniem umowy.

Maszyna projektu

Dla zilustrowania dylematów Szefa Projektu w fazie realizacji skorzystamy z przykładu maszyny o czterech cylindrach ograniczonych tłokami, z bocznym otworem domkniętym balonikiem. Po przygotowaniu maszyny tłoki ustawione są w pewnych położeniach optymalnych, przestrzeń w cylindrach wypełniona jest średnio sprężonym gazem, zaś balonik ryzyka pozostaje w stanie średnio napompowanym. Stan ten obrazuje projekt po pracach organizacyjnych i planistycznych. Maszyna działa poprawnie jedynie wówczas, gdy ciśnienie w cylindrach jest zgodne z pewną ustaloną wartością.

Maszyna projektu

Po upływie pewnego czasu "coś" – przykra rzeczywistość lub liczni operatorzy maszyny (np. ważni decydenci lub nieustępliwy użytkownik)
– zmieniają położenie jednego z tłoków, zmuszając "Kierownika maszyny" czyli Szefa Projektu do przywracania jej stabilności. Oczywiście w odpowiedzi na naciśnięcie jednego z tłoków zwalnia on jeden z pozostałych, dbając o równomierne ciśnienie. Jeżeli jednak nie ma takiej możliwości, wówczas balonik ryzyka niebezpiecznie rośnie, grożąc rozsadzeniem całej
maszyny.

Przekładając ten przykład na język praktyki powiemy, że w razie wzrostu presji na produkt (np. przy żądaniu dostarczenia dodatkowych produktów) będziemy negocjować uzyskanie dodatkowych pieniędzy lub wydłużenie harmonogramu. Przy żądaniach skrócenia harmonogramu zgadzamy się na to po uzyskaniu dodatkowych pieniędzy lub rezygnacji z części zadań, zaś przy obcięciu budżetu – redukujemy produkty lub robimy je dłużej (to ostatnie nie zawsze jest możliwe). Jeśli zaś Szef Projektu jest pozbawiony możliwości takich uzasadnionych działań, rośnie ryzyko niepowodzenia projektu.

Proste? Idea tak, ale praktyka – bardzo rzadko. A niby jest to takie oczywiste.

Metodyka PRINCE 2 podkreśla niezmiernie wagę takiego właśnie sposobu myślenia Szefa Projektu poprzez zwrócenie szczególnej uwagi na mechanizm Kontroli Zmian (o czym w kolejnym
artykule).

Kontrola bez pomiaru jest tylko wyrażaniem opinii

Drabina kierowania projektem

Dla zilustrowania idei kierowania projektem przez Szefa w trakcie realizacji można posłużyć się schematem drabiny. Kolejne szczeble ukazują czynności wykonywane przez niego co jakiś czas – wybrany lub uzgodniony. Zawarty tu schemat sprowadza się do badania rzeczywistości projektu (szczególnie postępu prac), wyciągania wniosków i podejmowania wynikających z tego działań.

Drabina kierowaniem projektem

Szczebel 1 – Kwantyfikacja
Najniższym szczeblem jest kwantyfikacja, rozumiana jako określenie miar postępu. Dla każdego projektu mogą one być inne. Szef Projektu znający się merytorycznie na przedmiocie pracy (np. były informatyk kierujący projektem informatycznym) często określa miary osobiście, jednakże zwykle warto odwołać się do pomocy specjalistów technicznych z danej dziedziny. Dobra kwantyfikacja nie jest łatwa, zaś od jej poprawności zależy cała wartość kierowania projektem.

Przykłady miar postępu:

  • W projekcie sprawdzania kolejnych elementów wyposażenia miarą może być liczba sprawdzonych elementów (miara ta była stosowana w projektach Y2K)
  • Postęp w projekcie instalacji sieci strukturalnej można mierzyć liczbą wykonanych gniazd
  • Przy pracach programistycznych można mierzyć liczbą linii kodu (bardzo kiepska miara), można też odwoływać się do liczby oprogramowanych ekranów interfejsu czy korzystać z wyrafinowanych metod analitycznych (np. analiza punktów funkcyjnych)
  • Przerzucenie jednostek wojska na drugi koniec świata można mierzyć liczbą żołnierzy gotowych do boju w pozycjach wyjściowych, zaś stan ich wyszkolenia można sprawdzać na defiladach (miara stosowana jeszcze niedawno) lub na ćwiczeniach (miara dziś najpowszechniejsza)
  • Postęp w budowie kamienicy mierzymy liczbą pięter, zaś w całym budownictwie – liczbą oddanych metrów kwadratowych (a dlaczego nie w metrach sześciennych?)

Przykłady te ilustrują dwie prawidłowości:

  • Dobre miary są specyficzne dla dziedziny – przedmiotu projektu
  • Pozornie dobrze wyglądające miary często są mylące i pomagają w fałszowaniu rzeczywistości.
  • Popatrzmy na ostatni przykład budowlany. Wiadomo, że szybkość wznoszenia murów jest o wiele większa niż dostrzegalny postęp nieefektownych prac instalacyjno-wykończeniowych, bez których budynek trudno uznać za gotowy. Mimo więc okazałych pięter wyrastających szybko z ziemi szukajmy innych miar rzeczywistego postępu całej budowy. Może więc liczba oddanych mieszkań w kamienicy? Oczywiście bez sensu, bo żadne mieszkanie nie może być uznane za oddane dopóki nie są uruchomione wszystkie instalacje. Jak zatem mierzyć postęp przed nagazowaniem, nawodnieniem i ogrzaniem budynku?

    Prostą z pozoru miarą dla projektu budowy metra może być długość wykopanego tunelu. Oczywiście miara jest źle określona: a gdzie specyfika podłoża, a gdzie wykonanie stacji, a gdzie zajezdnia i system kierowania ruchem?

    W informatyce o przykłady fałszywych miar również nietrudno. Przy instalacji sieci strukturalnej można szybko okablować pomieszczenia, jednak później trzeba podłączyć wszystko do serwera
    – i tutaj liczba gniazdek jest więc zawodna. W przygotowaniu systemu aplikacyjnego pomiar przez liczbę gotowych ekranów interfejsu nieprecyzyjnie oddaje stopień gotowości systemu do eksploatacji. Wiadomo, że niezwykle trudnym i czasochłonnym zadaniem jest migracja danych, której przecież nie mierzy się liczbą ekranów. Nasz użytkownik czeka na działający system, a nie na oprogramowany fantom. Programistom znana jest proporcja czasu między napisaniem programu a starannym jego przetestowaniem: typowo wynosi to 1: 3. W projektach specjalnych (militarnych, kosmicznych) testowanie pochłania jeszcze więcej, o wiele więcej czasu. Podobnie przy wprowadzaniu systemu dla masowych użytkowników: zrobienie systemu to jedno, migracja danych
    – drugie, przeszkolenie użytkowników – trzecie, natomiast praktyczna umiejętność korzystania przez nich z systemu
    – to jest dopiero wysiłek.

    Pamiętajmy, iż w zdecydowanej większości projektów zadanie nie polega na zbudowaniu jakiegoś systemu, lecz na wprowadzeniu go do działania. Dobre miary postępu muszą zatem ujmować wszystkie fazy prac: koncepcyjne, konstrukcyjne i wdrożeniowe.

    Wiele metodyk szczegółowych wprowadza prostą miarę postępu pozwalającą ujmować różnorodne działania: nakłady pracy ludzi mierzone w osobo-dniach czy osobo-miesiącach. Miara ta ma dobre zastosowanie w bardzo wielu projektach, choć jej wartość zależy od precyzji i poprawności oszacowania nakładów pracy w planie projektu. A to jest często bardzo trudne, szczególnie w projektach z udziałem dużej liczby użytkowników.

    Jeszcze bardziej uniwersalną miarą są pieniądze czyli wydatki z budżetu projektu. Przy dobrze skonstruowanym budżecie dla wielu przedsięwzięć jest to miara idealna, świetnie oddająca faktyczny postęp w każdym momencie. Jednak wiele projektów wymaga znacznych nakładów na początku, całkowicie nieproporcjonalnych do postępu; jakże łatwo uzyskać postęp budżetowy poprzez zakupy sprzętu i licencji, a potem dopiero przystępować do żmudnego ustalania wymagań i potrzeb użytkownika. Z kolei przy odłożeniu zakupów na koniec i rozpoczęciu od analiz, projektów i programowania, z pozostawieniem masowego wdrożenia i migracji danych na koniec, również funkcja wydatków jest daleka od liniowej, proporcjonalnej do czasu. Warto jednak pamiętać, iż wydatki budżetowe są miarą stosowaną w świecie najczęściej, szczególnie przy badaniu projektu przez ludzi z wyższego szczebla kontroli.

    Poziom monitorowania zależy od stopnia zaufania do swoich ludzi

    Szczebel 2 – monitorowanie

    Wszystkie powyższe rozważania na temat dobrych i nierzetelnych miar postępu nabierają kolorów na następnym szczeblu naszej drabiny: monitorowaniu. Czynność ta jest po prostu dokonywaniem pomiaru rzeczywistości projektowej przy zastosowaniu naszych uprzednio zdefiniowanych miar, po czym porównaniu pomiaru z wzorcem. Norma British Standard uwzględniana szeroko przez metodykę PRINCE 2 określa monitorowanie jako
    "Porównanie aktualnego stanu projektu z planem w celu zidentyfikowania i objaśnienia odchyleń"
    (BS: 10007).

    Sposobów pomiaru jest sporo, od "zasięgania języka" u członków zespołu, poprzez regularne raporty, do inspekcji doraźnych i osobistego sprawdzania prac przez Szefa.

    Najczęściej stosowane są raporty formalne, okresowe – miesięczne i tygodniowe. Trudno wyobrazić sobie projekt, w którym zrezygnowano z tej metody poznawania rzeczywistości. Raportować powinni szefowie zespołów technicznych do Szefa Projektu, ten z kolei
    – do Komitetu Sterującego (a pośrednio i do sponsora). Warto zapoznawać z raportami miesięcznymi również kluczowych użytkowników, szczególnie jeśli w jakimś stopniu uczestniczą w pracach (informacja zwrotna) lub będą w nie zaangażowani później (system wczesnego ostrzegania). Doświadczony Szef Projektu nigdy jednak nie ogranicza się do czytania papierów czy nawet słuchania swoich podwładnych, lecz zawsze sprawdza osobiście to i owo
    – dużo lub mało, zależnie od zaufania do swoich ludzi. Najlepiej pracuje się w zespołach sprawdzonych, gdzie znany nam jest poziom wiarygodności raportowania ludzi
    – kto koloryzuje rzeczywistość, kto nie raportuje problemów, a kto stale narzeka. Jednak w praktyce rzadko kiedy mamy taki komfort, większość projektów robi się z częścią ludzi po raz pierwszy, co nakazuje wzmożony poziom monitorowania nieformalnego.

    Warto podkreślić, iż raporty okresowe nie powinny być ani zbyt rzadkie, ani zbyt częste. Często zalecanym
    "złotym środkiem" jest pisemny raport miesięczny i tygodniowa
    "odprawa operacyjna" Szefa Projektu z szefami zespołów. Z kolei szef zespołu monitoruje swoich ludzi tygodniowo
    – formalnie (karta pracy) i jedno- dwudniowo mniej formalnie (np. jednozdaniowa wiadomość pocztą elektroniczną).

    Niezależnie od stosowanych metod trzeba pamiętać o celu raportowania. Chodzi w nim o uzyskanie rzetelnego obrazu rzeczywistości projektowej: postępu oraz problemów i zagrożeń.

    Celem raportowania jest uzyskanie rzetelnego obrazu rzeczywistości: postępu, problemów i zagrożeń.

    Kolejny element monitorowania wspomniany w powyższej definicji to porównanie wyników pomiaru z planem. W tym miejscu trzeba wspomnieć o dwóch aspektach omawianych przy planowaniu projektu: dokładności planowania i sensie tworzenia planów.

    Dokładność planowania, a więc szczegółowość podziału na czynności, jak też planowania kosztów i robocizny, zależy właśnie od zamierzonego poziomu monitorowania postępu. Jeśli od naszych specjalistów oczekujemy raportów miesięcznych z postępu, nie planujmy ich działań na poziomie tygodniowym, lecz właśnie miesięcznym. Jeśli z kolei koszty napisania kawałka oprogramowania trudno ustalić przed testowaniem i usuwaniem błędów, planujmy koszt na całość prac związanych z tym fragmentem systemu, bez podziału na fazę programistów i testerów. Zasada doboru właściwej granulacji (poziomu szczegółowości) planowania brzmi:

    jak dokładnie chcesz mierzyć, tak dokładnie musisz planować
    .
    Ani więcej, ani mniej. Plan zbyt szczegółowy jest nieprzydatny, plan zbyt ogólny nie daje podstaw do oceny postępu. 

    Drugi aspekt planowania budzący wiele kontrowersji u specjalistów technicznych to trudności ze zwymiarowaniem nakładów pracy na początku, przy niewielkiej znajomości faktycznego zadania i ewentualnych problemów. Z braku precyzyjnych wymagań użytkowników naciskany przez Szefa główny projektant usilnie unika oszacowania nakładów pracy, jednak w ten sposób uniemożliwia późniejsze badanie postępu, w tym również rozwiązywanie wynikających problemów. Warto przypomnieć zasadę, że
    lepsze mało precyzyjne oszacowanie niż żadne: jeśli nie wiesz, zgadnij.

    Celem porównywania wyników pomiaru stanu projektu i postępu prac z planem jest stwierdzenie, czy wystąpiły odchylenia. Jest to więc porównywanie rzeczywistości z wzorcem dla poznania faktycznej sytuacji projektu. No i oczywiście wyciągnięcie wniosków.

    Bardzo ciekawą, acz niepopularną koncepcją monitorowania i raportowania postępu jest podejście
    "realistyczne", w odróżnieniu od "archeologicznego". Koncepcja ta jest rzadko stosowana, choć jej wprowadzenie ma fundamentalne znaczenie dla podwyższania liczby udanych projektów.
    Tradycyjne raportowanie postępu (‚archeologiczne’) wykazuje, co zrobiono od początku projektu lub od ostatniego przeglądu do dziś. Informacje te są bardzo ciekawe, jednak niezmiernie mało mówią o szansach na pomyślne zakończenie projektu.

    Realistyczne raportowanie postępu głosi, że w raporcie omawiać należy prace pozostałe jeszcze do wykonania do zakończenia projektu. Zamiast informować, co zostało zrobione, należy przekazać, co jeszcze jest do zrobienia żeby dojść do końca zadania. Gdzie więc znajduje się główna różnica między raportem ‚archeologa’ a ‚realisty’? W problemach projektu wynikających z rzeczywistości, w nieprzewidzianych i niezaplanowanych okolicznościach, w pozabudżetowych kosztach, w nierozpoznanej rzeczywistości robienia czegoś po raz pierwszy. Te wszystkie jakże ważne dla oceny kwestie bardzo łatwo jest ukryć w raporcie informującym o przeszłości projektu i nie ukazującym drogi do jego zakończenia. Przywołując poprzedni przykład postępu instalacji sieci strukturalnej mierzonego liczbą gniazd, a jeszcze lepiej
    – przykład z drążeniem tunelu metra, widzimy różnicę na pierwszy rzut oka. Pamiętamy przecież, iż Szef Projektu odpowiada nie za to, żeby ROBIĆ, lecz żeby ZROBIĆ. Niby drobiazg, a różnica kolosalna.

    Postęp prac - podejście realistyczne

    PRINCE 2 o miarach postępu i o samych czynnościach monitorowania mówi niewiele i mało precyzyjnie, gdyż jest to metodyka ogólna, stosowalna w projektach z dowolnej dziedziny technicznej czy biznesowej, natomiast określane miary i sam sposób monitorowania postępu wiążą się ściśle ze specyfiką dziedzinową przedmiotu prac. Ważnym jednak stwierdzeniem PRINCE 2 jest, iż pomiar stanu musi koniecznie odbywać się w punktach krytycznych (ang. Milestones), z których największe znaczenie mają zakończenia etapów zarządczych. W momentach tych wymagane jest uruchomienie pełnego mechanizmu monitorowania: zebranie raportów formalnych od szefów zespołów, sporządzenie zbiorczego raportu dla całego projektu, przedyskutowanie go przez Komitet Sterujący i podjęcie decyzji o przyjęciu i zakończeniu etapu lub kontynuacji prac. Należy też pamiętać, iż przyjmowanie etapu obowiązkowo odbywać się musi z przyjmowaniem szczegółowych planów dla kolejnego etapu, wraz ze wszystkimi niezbędnymi korektami początkowych planów wynikającymi ze stwierdzonego stanu projektu.

    Szef Projektu odpowiada nie za to,
    żeby ROBIĆ, lecz żeby ZROBIĆ.
    Niby drobiazg, a różnica kolosalna.

    Szczebel 3 – kontrola

    Kontrola jest wyciągnięciem wniosków ze stwierdzonego poprzez monitorowanie stanu projektu. Jeśli zidentyfikowane różnice między planem a stanem faktycznym mieszczą się w zaplanowanym zakresie tolerancji, Szef Projektu może z dumą zaraportować, iż projekt biegnie zgodnie z planem. Niestety taki meldunek mamy przyjemność składać raczej rzadko. Najczęściej trzeba pochwalić się, iż to i owo idzie zgodnie z planem, tu i ówdzie są pewne opóźnienia (lepiej powiedzieć to przy użyciu miary, np. 5 dni opóźnienia), ale za to w pewnych nielicznych fragmentach plan wyprzedzamy. I to właściwie wszystko, można spokojnie przystąpić do najsłodszej prerogatywy Szefa Projektu: kierowania.

    Szczebel 4 – Kierowanie

    Określenie kierowania również jest bardzo nieskomplikowane: jest to wyciąganie praktycznych wniosków ze stwierdzeń kontrolnych, a więc używanie władzy Szefa Projektu do wykazania swej ważnej roli w projekcie. No i oczywiście do nakierowania projektu na właściwe tory, z których zboczył on o tyle, o ile wykazały pomiary w punkcie kontrolnym.

    W praktyce kierowanie przez Szefa
    Projektu można określić listą następujących zagadnień:


    • Kontrola postępu, zmian, jakości

    • Działania naprawcze

    • Kierowanie zespołem projektu

    • Komunikacja wewnętrzna

    • Zarządzanie ryzykiem

    • Administracja projektu

    • Przygotowanie odbioru końcowego

    Największą sztuką jest podejmowanie odpowiednich działań naprawczych. Oczywiście są one niezbędne w każdym projekcie, bo nigdy rzeczywistość nie układa się zgodnie z naszymi założeniami i planami. Odchylenia od planu występują zawsze, zawsze więc niezbędne są korekty. Typowe działania korekcyjne to:


    • Przydział dodatkowych zasobów
    • Zmiana zakresu prac
    • Obniżenie jakości produktów
    • Zmiana organizacji zespołu

    Im dłuższy czas realizacji, im większy koszt, im więcej ludzi zaangażowanych w przedsięwzięcie, tym szybciej pojawiają się istotne zagrożenia, wymagające bacznej uwagi Szefa Projektu.

    Przy opóźnieniach lub powiększaniu zakresu prac, ewentualnie napotkaniu nieprzewidzianych komplikacji w produkcji, najczęściej próbujemy uzyskać dodatkowe zasoby. Warto pamiętać, że niełatwym do uzyskania, choć często jedynym dostępnym sposobem jest zażądanie dodatkowych ludzi od naszego klienta/zleceniodawcy. Wprawdzie brzmi paradoksalnie, że klient ma sam zrobić część roboty dla siebie, ale taka właśnie jest rzeczywistość i zwykle łatwo klientowi wykazać, że jeśli nam nie pomoże, najbardziej stratny będzie on sam. Praktykowanym często sposobem jest zatrudnienie ludzi klienta za nasze pieniądze, np. przy wprowadzaniu danych początkowych czy ich korekcie.

    Trzeba też pamiętać, iż w wielu projektach lub w pewnych ich fazach (szczególnie koncepcyjnych) wprowadzanie dodatkowych ludzi nie poprawi sytuacji, a nawet może ją pogorszyć (tzw. krzywa uczenia projektu). Zamiast szukania dodatkowych ludzi warto przemyśleć, jak ułatwić pracę tym, którzy są zaangażowani w nasz projekt. Szczególnie często dotyczy to sytuacji, gdy ludzie ci pracują równocześnie w kilku przedsięwzięciach, zatem uzyskane u przełożonych wycofanie ich z części innych prac da im rzeczywistą większą zdolność pracy dla nas. Inną sytuacją jest niedostateczny postęp wykazywany przez naszych pracowników. Remedium wówczas jest poszukanie specjalistów na zewnątrz, na wolnym rynku lub u klienta, choć zwykle naraża to nasz budżet na dodatkowe koszty.

    Drugą grupę działań korekcyjnych – zmianę zakresu prac –
    ilustrowała częściowo ‚maszyna projektu’. Wspomniano tam, że przy naciskach na przyspieszenie prac trzeba negocjować zmniejszenie ich zakresu. Taki sam sposób zaleca się przy występowaniu opóźnień w projekcie, niezależnie od przyczyn i winy jednej ze stron. Nawet przy ewidentnej winie wykonawcy warto nalegać na klienta, aby ujął nam część roboty do wykonania, gdyż w przeciwnym przypadku katastrofa może być znacznie większa.

    Nagminnym, gdyż łatwym do zastosowania zestawem działań naprawczych jest obniżanie jakości produktów, np. rezygnacja z lepszego testowania, omijanie trudniejszych przypadków, szkolenie użytkowników bez odpowiedniej praktyki, przejście do eksploatacji rzeczywistej bez okresu próbnego itp. Takie sposoby są rzadziej stosowane w budownictwie, gdyż za katastrofy budowlane idzie się do więzienia, natomiast w pozostałych dziedzinach, również w informatyce, powszechnie sięga się po te ‚ukryte rezerwy’.

    Modyfikacja organizacji pracy, szczególnie poprzez zmianę kluczowych osób, jest również bardzo często stosowanym działaniem naprawczym, choć jego skuteczność zależy od konkretnych sytuacji. Warto pamiętać, iż zdolność do podejmowania odważnych decyzji w tym zakresie (np. wymiana zasłużonego pracownika na młodego zdolnego) pokazuje klasę Szefa Projektu, jego umiejętność podejmowania ryzykownych decyzji w trudnej sytuacji.

    Wyjątkowo nie lubianym aspektem kierowania projektem jest konieczność wykonywania prac administracyjnych, których nie znosi większość Szefów Projektów. Przede wszystkim chodzi tu o raportowanie, które najlepiej realizowane jest na początku, kiedy raportować jeszcze nie ma czego, a i występujące problemy są błahe. Po upływie kilku tygodni zapał do raportowania stygnie, zaś problemy zachęcają do ich ukrywania przed okiem Komitetu Sterującego i klienta. I wówczas zwykle ustalone procedury raportowania idą na półkę jako ‚zbędna biurokracja’.

    Kontrola zmian oraz zarządzanie ryzykiem są zagadnieniami samymi w sobie, dlatego też zostaną omówione w odrębnych artykułach.

    Warto podkreślić, iż oba te zagadnienia są niezwykle sumiennie rozpatrywane przez metodykę PRINCE 2. Podobnie metodyka zwraca uwagę na znaczenie wyprzedzającego przygotowywania odbioru końcowego, a więc gromadzenia materiałów umożliwiających poprawne zakończenie projektu, szczególnie wszelkiej dokumentacji związanej z odbiorami produktów, testami i protokołami, której przy większych projektach trzeba zebrać sporo. Wiele o tym powiedzieć mogą Szefowie Projektów finansowanych przez organizacje międzynarodowe (PHARE, Bank Światowy), którzy szybko dowiadują się, jak ważne są wszelkie papierki formalne.

    Metodyka PRINCE 2 wskazuje specyficzne działanie naprawcze, które powinno być rozważane zawsze przy stwierdzeniu poważnych problemów projektu: możliwość jego zatrzymania i rezygnacji z dalszych prac. Wprawdzie trudno spotkać takie decyzje w naszej rzeczywistości społecznej, jednak praktyka większości firm zachodnich daje liczne ich przykłady. PRINCE 2 przypomina, iż w procesie zakończenia etapu oprócz przyjęcia dotychczasowych prac trzeba podjąć decyzję co do dalszych losów projektu, a w szczególności – zaniechać powiększania strat. Decyzję taką szczególnie łatwo podjąć przy wspomnianym powyżej raportowaniu ‚realistycznym’, gdzie każdy raport ukazuje nakłady potrzebne do zakończenia projektu zamiast ‚przekopywania’ historii dotychczasowych sukcesów. Upowszechnienie się takiej właśnie kultury biznesowej pozostawia o wiele więcej pieniędzy na nowe projekty, zamiast topienia ich w kontynuację przedsięwzięć, gdzie droga ku katastrofie jest łatwa do przewidzenia.

    Jednak wymaga to zmiany paradygmatu widzenia roli Szefa Projektu. Obecnie za złego Szefa uważa się tego, który nie dokończył projektu, natomiast z równym potępieniem nie spotyka się ten, kto ukończył przedsięwzięcie niepotrzebne lub przekroczył wszelkie możliwe do wyobrażenia tolerancje miar projektu.

    Mistrz, przyjaciel czy autokrata


    Mówiąc o realizacji projektu nie sposób pominąć omówienia postaci Szefa Projektu. Na ten temat bardzo obszernie wypowiadają się obecnie nauki psychologii i socjologii, jak też zarządzania. W tej właśnie sferze funkcjonowania projektu od kilku lat dokonuje się największy postęp w teorii Zarządzania Projektami.

    Zaprezentujemy tu jedno z wielu podejść do prezentacji roli Szefa Projektu w kierowaniu zespołem.

    Wśród jego zadań wyróżnia się:


    • decydowanie

    • motywowanie

    • koordynację

    Jedna z interesujących kategoryzacji rodzajów – typów psychologicznych Szefów Projektów jest następująca:


    • Mistrz dobrej roboty

    • Przyjaciel

    • Autokrata

    • Trener

    • Demokrata

    • Manipulator

    Przykładowo Mistrz dobrej roboty decyzje podejmuje zwykle sam, w oparciu o swą wiedzę profesjonalną i pragnienie sukcesu. Mobilizuje swoich ludzi do osiągania ambitnych celów, dając osobisty dobry przykład. Rzadko karze i rzadko nagradza. Kieruje ludźmi stawiając na ich odpowiedzialność i chęć odnoszenia sukcesów zawodowych. Daje im dużo swobody i odpowiedzialności za działania. Ingeruje tylko w trudnych sytuacjach.

    Z kolei Trener samodzielnie podejmuje decyzje, informując o ich merytorycznych powodach i sposobach realizacji. Operuje głównie nagrodami za osiąganie dobrych wyników. Nie pozwala zrażać się niepowodzeniami, pomaga ludziom w szukaniu przyczyn trudności. Zachęca do ich doskonalenia się. Mobilizuje do pracy poprzez nacisk na sukcesy. Korzysta z informacji zwrotnych o postępie prac, doradza, przekazuje swoje sugestie. Kontaktuje się z ludźmi na wszystkich stanowiskach pracy.

    Szef Projektu – Demokrata decyduje po konsultacji z podwładnymi, nie podejmuje decyzji, na które oni nie wyrazili zgody. Przekazuje ludziom dużo pozytywnych informacji na temat ich pracy, kształtuje przyjazną atmosferę. Korzyści dzieli w porozumieniu z zespołem. Dobiera ludzi do ról zgodnie z ich zainteresowaniami. Nie zwraca uwagi na sztywną organizację i ścisły podział zadań. Daje dużą samodzielność, nie komentuje negatywnie zdarzeń, informuje o sytuacji w grupie.

    Natomiast Autokrata decyduje sam, na własną odpowiedzialność, na podstawie własnej wiedzy i przekonań. Rzadko konsultuje się z podwładnymi. Stosuje groźby i kary, ocenia pracę równocześnie z oceną ludzi. Utrzymuje dystans do ludzi, chwali głównie za dokładną realizację swoich poleceń. Wymaga szczegółowych sprawozdań i ścisłego trzymania się swoich ról, przestrzegania szczegółowych instrukcji. Nie dopuszcza
    do dyskusji.

    Podobnie charakteryzuje się pozostałe rodzaje osobowości Szefa Projektu i realizowanego przez niego rodzaju zarządzania.

    Oczywiście wszyscy znamy Szefów różnych typów, również Autokratów i Manipulatorów. Bez wahania opowiadamy się za przywództwem Demokraty lub Trenera. Ale czy rzeczywiście? Wielu ludzi dobrze czuje się w strukturach autokratycznych, ze ściśle określonymi zakresami zadań i procedurami działania, z dyrektywnym sposobem zarządzania. W informatyce w wielu przypadkach znakomicie sprawdzają się podejścia demokratyczne i trenerskie, natomiast młodzi ludzie często świetnie pracują w zespole kierowanym przez Mistrza dobrej roboty. Tymczasem w bardzo wielu przedsięwzięciach najlepsze rezultaty uzyskują Szefowie autokratyczni i zadufani w sobie, nie szanujący zbytnio ludzi i traktujący ich narzędziowo. I nie dotyczy to wcale jedynie wojska, lecz również dowolnych innych przedsięwzięć biznesowych. Z kolei sama natura pewnych projektów wymusza niedemokratyczność kierowania, np. w lotach kosmicznych, gdzie bardzo mało jest miejsca na dyskusje, uzgodnienia, sprzężenia zwrotne itp.

    Inną ciekawą klasyfikacją Szefów Projektów jest ich podział na ‚buchalterów’ i ‚przywódców’ oraz wiele szczebli pośrednich-mieszanych.

    Buchalter kieruje projektem głównie poprzez papiery, starannie prowadzi wszelką dokumentację, kontaktuje się z ludźmi poprzez raporty pisemne, nieustannie zestawia harmonogramy, raporty i budżet projektu.

    Przywódca specjalizuje się w tworzeniu wizji i przekazywaniu jej ludziom, w motywowaniu ich do wysiłku i do samodzielnego rozwiązywania większości szczegółów jego ‚twórczych koncepcji’. Sukces uważa głównie za swoją zasługę, za porażkę wini podwładnych.

    Czy jeden z tych typów jest sprawniejszy w uzyskiwanych wynikach? Praktyka pokazuje, że wcale nie. W Zarządzaniu Projektami jest miejsce dla obu typów Szefów: i dla buchaltera i dla natchnionego przywódcy. Jako pewną dyrektywę kierunkową można przyjąć, że osobowość ‚buchaltera’ lepiej sprawdza się w projektach bardziej technicznych niż organizacyjnych, prostszych niż złożonych, krótszych i nie mających bardzo wiele cech nowatorstwa. Natomiast wizjonerski przywódca jest prawie niezbędny w projektach z pogranicza wykonalności, operujących na dużych zespołach ludzi, o dłuższym horyzoncie czasu trwania. Ale jednak obie te postawy pozwalają uzyskać bardzo dobre wyniki, choć na ogół w różnych projektach.

    Fachowiec czy dyletant?

    No i na koniec bardzo specyficzne pytanie do rozstrzygnięcia: czy Szef Projektu powinien być znakomitym fachowcem z dziedziny, którą dany projekt się zajmuje? Problem ten ma szczególne znaczenie w informatyce, gdzie typowa ścieżka awansu prowadzi do Szefa Projektu poprzez liczne stanowiska techniczne: programisty, projektanta, analityka itp. Nagminne jest, iż bardzo dobry specjalista techniczny, szczególnie programista, bywa awansowany na kierownika zespołu, a potem – Szefa Projektu. I nagle pojawia się dramat. Z jednej strony nieszczęsny nominat nie czuje się dobrze w nowej roli, nie uzyskuje sukcesów, z drugiej zaś
    – popełnia liczne błędy techniczne, szczególnie w obszarze estymacji do planowania oraz w kontaktach z klientami i użytkownikami.

    Zarządzanie Projektami nie jest dziedziną techniczną, lecz należy do nauki o organizacji i zarządzaniu, natomiast Szef Projektu to funkcja organizatora, a nie specjalisty
    dziedzinowego.

    Przypomnijmy więc bardzo często niedocenianą prawdę: Zarządzanie Projektami nie jest dziedziną techniczną, lecz należy do nauki o organizacji i zarządzaniu, natomiast Szef Projektu to funkcja organizatora, a nie specjalisty dziedzinowego. Awanse znakomitych specjalistów technicznych rzadko kończą się powodzeniem, najczęściej uzyskuje się sfrustrowanego byłego specjalistę i nienajlepszego szefa. Do wykonywania zawodów specjalistycznych i zarządczych potrzebne są inne umiejętności i cechy, wykorzystuje się w nich odmienne techniki i narzędzia, realizuje całkowicie inne zadania strategiczne i codzienne. I stosunkowo rzadko zdarzają się ludzie dobrze przystosowujący się do roli kierownika przedsięwzięcia i zespołu, jeżeli całe dotychczasowe życie poświęcili doskonaleniu się w określonych umiejętnościach technicznych.

    Przy nieustannym i gwałtownym postępie w informatyce wiedza specjalistyczna starzeje się w 2-3 lata, bardzo łatwo z wybitnego specjalisty stać się byłym specjalistą.

    Drugim wielkim zagrożeniem dla Szefa Projektu wynikającym z doświadczenia technicznego jest jego nieświadomość własnych ograniczeń. Każdy człowiek w nowej sytuacji opiera się przede wszystkim na dotychczasowym doświadczeniu, z trudem dostrzega, iż rzeczywistość się zmieniła i wymaga trochę lub całkiem innych umiejętności. Przy nieustannym i bardzo gwałtownym postępie w informatyce wiedza specjalistyczna starzeje się w 2-3 lata, bardzo więc łatwo z Wybitnego Specjalisty stać się Byłym Specjalistą. I bardzo trudno jest uświadamiać sobie własną niewiedzę w swej dawnej specjalności. Niezmiernie częstym błędem dobrych skądinąd Szefów Projektu jest przecenianie własnego doświadczenia technicznego, stosowanie go szczególnie do estymacji zadań, podpowiadania metod rozwiązania problemów technicznych, pozowania na autorytet przed podwładnymi, których umiejętności specjalistyczne są najczęściej o wiele bardziej aktualne niż
    Szefa. W takich sytuacjach szczególnie niebezpieczny jest autokratyczny i trenerski sposób kierowania projektem, narażający zespół na wiele problemów spowodowanych przez nieco już zwietrzałą wiedzę techniczną Szefa. Pamiętajmy więc, że nasze doświadczenie praktyczne w dziedzinie będącej przedmiotem projektu przydatne jest głównie w jednym obszarze: zarządzaniu ryzykiem. Były specjalista znakomicie rozpozna potencjalne zagrożenia i postara się je obezwładnić, natomiast nienajlepiej zaplanuje harmonogram i oszacuje niezbędne nakłady pracy, jak też może całkowicie utopić projekt narzucając mu własne koncepcje techniczne.

    Zbiorowość doświadczonych Szefów Projektów, uzyskujących wiele praktycznych sukcesów i prowadzących poważne przedsięwzięcia, składa się z ludzi o niesłychanie zróżnicowanych osobowościach, doświadczeniach, sposobie bycia i współpracy z ludźmi. Odmiennie niż w niektórych innych zawodach (np. księgowych, handlowców, konstruktorów itp.) wśród dobrych Szefów Projektów absolutnie nie można znaleźć jednego dominującego typu, jednej osobowości. Pamiętajmy o tym i szukajmy własnego sposobu kierowania, odpowiadającego naszej osobowości, ale również naszemu zespołowi danego projektu, a w szczególności
    – zadaniu do wykonania.

    Pamiętajmy o własnych ograniczeniach. Pamiętajmy o postępie technicznym i starzeniu się wiedzy. Uczmy się nowego zawodu: Szefa Projektu.

    Jerzy Szych
    shake@pol.pl
    prowadził kilkadziesiąt projektów informatycznych. Spędził 10 lat w korporacjach informatycznych w Polsce i za granicą. Obecnie prowadzi projekty i wykłada Zarządzanie Projektami jako samodzielny konsultant.
    Członek Polskiego Towarzystwa Informatycznego i Stowarzyszenia Project Management Polska.