Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
TenStep Project Management Process
1
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Wstęp do wydania polskiego Do tej pory w obszarze polskojęzycznym posługiwano się wyłącznie oryginalnymi wersjami podręczników i formularzy TenStep. Głównie dlatego, że najbardziej fascynujące projekty, realizowane przy użyciu TenStep, zarządzane były przez osoby świetnie znające język angielski. Od czasu, gdy zdecydowano, że TenStep powinien zejść „pod strzechy” niezbędne okazało się wykonanie tłumaczenia metodyki. Zadanie okazało się jednak arcytrudne. Wielu tłumaczy widząc prostotę tekstu nie zdawało sobie sprawę, że największą trudnością jest właśnie to, że o sprawach złożonych TenStep opowiada zrozumiale. Długie miesiące upłynęły na ożywianiu metodyki w języku polskim. Dlatego też wersja polskojęzyczna została nieco zmieniona w stosunku do wersji oryginalnej. Po pierwsze, aby tekst nadal był prosty i zrozumiały. Po drugie, ponieważ biznes w Polsce robi się zdecydowanie inaczej niż w USA, gdzie TenStep ma swoje korzenie. Życzymy wielu sukcesów w projektach realizowanych w metodyce TenStep!
2
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Spis Treści WSTĘP DO WYDANIA POLSKIEGO .................................................................................................................... 2 SPIS TREŚCI....................................................................................................................................................... 3 WITAMY!.......................................................................................................................................................... 5 0.0.1 WARTOŚD ZARZĄDZANIA PROJEKTEM .................................................................................................................. 7 0.0.2 MODEL DOJRZAŁOŚCI ORGANIZACYJNEJ (CMMI) ................................................................................................ 12 0.0.3 STYL JĘZYKA TENSTEP ..................................................................................................................................... 14 0.0.4 JAK KORZYSTAD Z TENSTEP .............................................................................................................................. 15 0.0.5 WYTYCZNE TENSTEP ...................................................................................................................................... 16 0.0.6 MODEL PROCESU TENSTEP ............................................................................................................................. 17 0.0.8 PORÓWNANIA TENSTEP PROJECT MANAGEMENT PROCESS .................................................................................. 22 1.0 DEFINIOWANIE PROJEKTU ........................................................................................................................ 44 1.1 DEFINIOWANIE PROJEKTU / PROCES .................................................................................................................... 60 1.2 DEFINIOWANIE PROJEKTU / TECHNIKI................................................................................................................... 81 1.3 DEFINIOWANIE PROJEKTU / PODSUMOWANIE...................................................................................................... 103 2.0 TWORZENIE HARMONOGRAMU I BUDŻETU ........................................................................................... 107 2.1 TWORZENIE HARMONOGRAMU I BUDŻETU / PROCES ............................................................................................ 109 2.2 TWORZENIE HARMONOGRAMU I BUDŻETU / TECHNIKI .......................................................................................... 146 2.3 TWORZENIE HARMONOGRAMU I BUDŻETU / PODSUMOWANIE ................................................................................ 161 3.0 ZARZĄDZANIE HARMONOGRAMEM I BUDŻETEM.................................................................................. 165 3.1 ZARZĄDZANIE HARMONOGRAMEM I BUDŻETEM / PROCES ..................................................................................... 167 3.2 ZARZĄDZANIE HARMONOGRAMEM I BUDŻETEM / TECHNIKI ................................................................................... 190 3.3 ZARZĄDZANIE HARMONOGRAMEM I BUDŻETEM / PODSUMOWANIE ........................................................................ 214 4.0 ZARZĄDZANIE PROBLEMAMI KRYTYCZNYMI .......................................................................................... 217 4.1 ZARZĄDZANIE PROBLEMAMI KRYTYCZNYMI / PROCES ............................................................................................ 218 4.2 ZARZĄDZANIE PROBLEMAMI KRYTYCZNYMI / TECHNIKI .......................................................................................... 224 4.3 ZARZĄDZANIE PROBLEMAMI KRYTYCZNYMI / PODSUMOWANIE ............................................................................... 236 5.0 ZARZĄDZANIE ZMIANAMI ...................................................................................................................... 239 5.1 ZARZĄDZANIE ZMIANAMI / PROCES .................................................................................................................... 245 5.2 ZARZĄDZANIE ZMIANAMI / TECHNIKI .................................................................................................................. 261 5.3 ZARZĄDZANIE ZMIANAMI / PODSUMOWANIE ...................................................................................................... 267 6.0 ZARZĄDZANIE KOMUNIKACJĄ ................................................................................................................ 270 6.1 ZARZĄDZANIE KOMUNIKACJĄ / PROCES............................................................................................................... 271 6.2 ZARZĄDZANIE KOMUNIKACJĄ / TECHNIKI ............................................................................................................. 296 6.3 ZARZĄDZANIE KOMUNIKACJĄ / PODSUMOWANIE ................................................................................................. 304 7.0 ZARZĄDZANIE RYZYKIEM ........................................................................................................................ 308 7.1 ZARZĄDZANIE RYZYKIEM / PROCES ..................................................................................................................... 309 7.2 ZARZĄDZANIE RYZYKIEM / TECHNIKI ................................................................................................................... 323 7.3 ZARZĄDZANIE RYZYKIEM / PODSUMOWANIE ....................................................................................................... 332 8.0 ZARZĄDZANIE ZASOBAMI LUDZKIMI ...................................................................................................... 335 8.1 ZARZĄDZANIE ZASOBAMI LUDZKIMI / PROCES ...................................................................................................... 335 8.2 ZARZĄDZANIE ZASOBAMI LUDZKIMI / TECHNIKI .................................................................................................... 335 8.3 ZARZĄDZANIE ZASOBAMI LUDZKIMI / PODSUMOWANIE ......................................................................................... 355
3
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.0. ZARZĄDZANIE JAKOŚCIĄ ........................................................................................................................ 358 9.1. ZARZĄDZANIE JAKOŚCIĄ / PROCES..................................................................................................................... 362 9.2 ZARZĄDZANIE JAKOŚCIĄ / TECHNIKI .................................................................................................................... 373 9.3 ZARZĄDZANIE JAKOŚCIĄ / PODSUMOWANIE ........................................................................................................ 390 10.0 ZARZĄDZANIE POMIARAMI .................................................................................................................. 393 10.1 ZARZĄDZANIE POMIARAMI / PROCES ................................................................................................................ 394 10.2 ZARZĄDZANIE POMIARAMI / TECHNIKI.............................................................................................................. 402 10.3 ZARZĄDZANIE POMIARAMI / PODSUMOWANIE ................................................................................................... 409 INFORMACJE DODATKOWE .......................................................................................................................... 411
4
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Witamy! TenStep Project Management Proceses (TenStep) pomaga menadżerom na całym świecie skutecznie zarządzać projektami. Jako światowa sieć TenStep przede wszystkim dostarczamy wiedzy i praktycznych informacji, których potrzebuje każdy menedżer projektu, aby móc odnosić sukcesy. Na tym się koncentrujemy. Zastosowane przez nas podejście „krok po kroku” umożliwia poznawanie zarządzania projektami od kwestii podstawowych do bardziej zaawansowanych, istotnych tylko w realizacji nietypowych projektów. TenStep jest metodyką zarządzania pracą jako projektem. Jest skonstruowany w sposób elastyczny, abyś mógł zarządzać projektem tak, jak tego potrzebujesz. Na przykład, poświęcanie zbyt dużo czasu kwestii zarządzania ryzykiem może nie mieć sensu w projekcie, który wymaga 500 godzin pracy i jest podobny do wielu zrealizowanych już wcześniej. Nie oznacza to, że ignorujesz ryzyka, tylko to, że nie poświęcasz tyle czasu, ile trzeba projektowi, na przykład dotyczącemu wdrożenia nowej technologii w nieznanym otoczeniu. Takie elastyczne i skalowalne podejście uwidacznia się we wszystkich procesach TenStep. Dzięki temu istotnie TenSterp odróżnia się od innych metodyk. Termin „zarządzanie projektem” odnosi się do definiowania, planowania i późniejszego monitoringu, oraz kontrolowania i zakończenia pracy. Zauważ że wszystkie projekty wymagają w jakiś sposób zarządzania. Im większy i bardziej złożony projekt, tym jest ono bardziej formalne i usystematyzowane. Możesz nieformalnie, nieco improwizując zarządzać projektem realizowanym przez dwie osoby i trwającym ok. 200 godzin. Ale nie możesz w ten sam sposób kierować projektem pięcioosobowym przy pracochłonności 1 000 godzin. Projekt dziesięcioosobowy na 5 000 godzin wymaga już formalnego procesu zarządzania, zaś projekt 20-osobowy realizowany w 20 000 godzin i większe, prawdopodobnie będą wymagać nakładu pracy by wybrać, uzgodnić lub opracować jakieś szczególne zasady zarządzania. Aby lepiej zrozumieć procesy TenStep, przyjrzyjmy się na wstępie korzyściom, które osiągniemy przy jego wykorzystaniu oraz dokonajmy przeglądu podstawowych założeń, aby uzyskać ogólną orientację co do sposobu działania TenStep.
0.0.1 Wartość Zarządzania Projektem 0.0.1.1 Model Dojrzałości Organizacyjnej (CMM)
0.0.3 Styl pisania TenStep 0.0.4 Jak korzystać z Procesu TenStep 0.0.5 Zasady TenStep 0.0.6 Ogólny Model Procesu TenStep 0.0.8 Porównaj Proces Zarządzania Projektem TenStep z:
0.0.8.2 Kompendium wiedzy o zarządzaniu projektami (Project
Management Body of Knowledge (PMBOK) 2004®) Instytut Zarządzania Projektami (PMI)
0.0.8.3 PRINCE2® 5
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.4 Six Sigma 0.0.8.5 Agile Development 0.0.8.6 ISO 10006
A teraz… zacznijmy od etapu 1.0 rozpocznijmy grę!
6
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.1 Wartość Zarządzania Projektem 0.0.1.P1 Istnieją firmy, które zyskały reputację jako te, które skutecznie zarządzają projektami. Ale większość organizacji nie cieszy się taką opinią. Czy w Twojej firmie także zdarza się, że:
Projekty są kończone
po terminie, z przekroczonym budżetem i nie spełniają
wymogów Klienta.
Procedury są słabo ustandaryzowane, a kierownicy projektów niekonsekwentnie korzystają z zalecanych technik.
Zarządzanie
projektem jest reaktywne i nie jest postrzegane jako wnoszące
wartości.
Czas
wymagany do zarządzania projektem w sposób pro aktywny (zapobiegawczy) nie jest uwzględniony w harmonogramie, ponieważ został uznany za niepotrzebny.
Projekty są udane pomimo braku planowania i zarządzania projektem, w wyniku
ogromnego wysiłku i pracy po godzinach. Dyscyplina w zarządzaniu projektem jest sposobem na przezwyciężenie tych problemów. Posiadanie właściwych umiejętności zarządzania projektem nie oznacza, że nie natrafiasz na żadne trudności, że ryzyka projektów zmniejszają się ani, że nie będzie niespodzianek. Wartością zarządzania projektem jest to, że w projekcie posługujesz się standardowymi procedurami, które precyzują to jak postępować, aby poradzić sobie z wszystkimi trudnymi lub nieprzewidzianymi sytuacjami. Zarządzanie projektami to procesy, dzięki którym koordynujemy pracę różnych zasobów, aby w sposób przewidywalny osiągnąć zamierzony efekt. Na samym początku jednak należy podkreślić, że zarządzanie projektem nie jest nauką sensu stricte. Co za tym idzie, nie daje stuprocentowej gwarancji sukcesu. Dlaczego? W projekty angażuje się ludzi. Jest to czynnik który powoduje zarówno wzrost niepewności jak i złożoności sytuacji jakie mogą się wydarzyć. Zarządzanie projektem jest więc zarówno nauką, jak i sztuką. Nauką, ponieważ opiera się na sprawdzonych procesach i technikach, dzięki którym wielokrotnie osiągano sukcesy w projektach. Sztuką jest ponieważ bazuje na zarządzaniu ludźmi oraz relacjach z nimi. To wymaga od kierownika projektu dobrej intuicji. Szczególnie w sytuacjach nietypowych i unikalnych, które zdarzają się niemal w każdym projekcie. Dobra metodyka zarządzania projektem opisuje procesy, techniki, wytyczne. Ponieważ zwiększa ona szanse odniesienia sukcesu przez projekt stanowi wartość dla firmy ale jak również dla kierownika projektu etc. Mimo, że zarządzanie projektem angażuje czas i zasoby, koszt ten zwraca się z nawiązką w trakcie trwania projektu poprzez:
Realizację
projektów taniej i w krótszym czasie. Jedną z największych korzyści zastosowania metodyki jest możliwość jej ponownego wykorzystania. Po stworzeniu procesów, procedur i szablonów, można ich używać wielokrotnie (być może uwzględniając niewielkie modyfikacje). Powoduje to przyspieszenie startu
7
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektów oraz skrócenie czasu poznawania reguł zarządzania projektami przez zespół realizatorów.
Oszczędność wysiłku i kosztów poprzez proaktywne zarządzanie zakresem.
W wielu projektach pojawiają się trudności zarządzania zakresem. Skutkuje to wielokrotnie pracą dodatkową, spoza zakresu, która de facto nie była zamawiana. Dzięki procesom zarządzania można lepiej panować nad zakresem, przez to unikać tych trudności.
Rozwiązanie
„pasuje‖ za pierwszym razem dzięki dobremu planowaniu. Problemem wielu projektów jest przepaść między tym, czego oczekuje klient a tym, co dostarcza projekt. Wykorzystanie metodyki, doprowadzi do lepszego planowania projektu. To umożliwi zespołowi oraz sponsorowi upewnienie się, że są zgodni co do przedmiotów dostaw projektu – ich typu, jakości, etc.
Szybsze rozwiązywanie problemów. Zespoły często spędzają za dużo czasu rozwiązując problemy projektu. Często jest tak dlatego, że wcześniej nie opracowano zasad mówiących jak postępować gdy wydarzy się problem. Stosowanie proaktywnych procesów zarządzania problemami krytycznymi, daje możliwość rozwiązywania problemów tak szybko, jak to możliwe poprzez zastosowanie wcześniej opracowanych schematów działania.
Zapobieganie
ryzykom, zanim staną się one faktycznymi problemami. TenStep precyzuje procesy, które pomagają w identyfikacji i zarządzaniu ryzykiem. Dzięki temu można mu zapobiegać lub łagodzić skutki gdy problem wystąpi.
Efektywniejsze
komunikowanie i zarządzanie oczekiwaniami pomiędzy klientami, członkami zespołu i interesariuszami. Wielu problemów pojawiających się przy realizacji projektu można uniknąć poprzez proaktywną i wielopłaszczyznową komunikację. Większość kryzysów projektu nie jest wynikiem konkretnego problemu, a raczej tego, że ktoś został nim zaskoczony. Metodyka TenStep koncentruje się na ułatwieniu organizacji oficjalnej i nieoficjalnej komunikacji.
Tworzenie
przedmiotów dostaw o pożądanej jakości. TenStep opisuje procesy zarządzania jakością. Pomagają one zespołowi zrozumieć potrzeby klienta. Gdy zostaną one poprawnie zdefiniowane, zespół może przystąpić do pracy. Przez wprowadzenie technik kontroli i zapewnienia jakości możliwe jest dokładne wypełnienie oczekiwań Klienta.
Lepsze
zarządzanie finansami. Jest ono wynikiem lepszej definicji projektu, precyzyjniejszej oceny, bardziej formalnego budżetowania i skrupulatnego monitorowania bieżących kosztów projektu w stosunku do budżetu. Wprowadzenie takiego porządku zwiększy kontrolę i przewidywalność finansową.
Szybsza identyfikacja i wstrzymywanie bezsensownych projektów. To takie projekty, w których pierwotna analiza opłacalności jest już nieaktualna. Projekt rozpoczyna się gdy ocena kosztów / korzyści jest korzystna. Ale jeśli projekt jest opóźniony lub przekracza budżet, itd., może osiągnąć stan, gdzie nie będzie sensu go kontynuować. Efektywne zarządzanie projektem pozwala przewidzieć takie sytuacje wcześniej. To umożliwia podjęcie decyzji wstrzymania projektu lub zmiany jego zakresu.
8
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Skoncentrowanie
się na kwestii podejmowania decyzji na podstawie posiadanych danych i pomiarów. Jednym z bardziej zaawansowanych procesów TenStep jest zarządzanie pomiarami. Dostarcza on wskazówek, co do sposobów uzyskiwania danych i informacji o wybranych aspektach projektu. Pomagają one zwiększyć efektywność i wydajność zespołu oraz pozwala ocenić poziom jakości przedmiotu dostawy. Pomiary dostarczają precyzyjnych informacji, czy projekt zakończył się sukcesem.
Lepsze
środowisko pracy. Jeśli projekty odnoszą sukcesy prawdopodobnie wystąpią dodatkowe, niewymierne korzyści. Będą one związane z zespołem projektowym. Ludzie poczują że są współodpowiedzialni za projekt, ich morale wzrośnie. Zachowanie zespołu będzie charakteryzowało się profesjonalizmem. Pracownicy będą bardziej pewni siebie. Ci, którzy narzekają, że zarządzanie projektem to zbędny koszt, zapominają o sednie sprawy - de facto wszystkie projekty są jakoś zarządzane. Pytanie tylko, jak skutecznie? Na przykład:
Twój projekt z pewnością napotka na problemy. Czy chcesz rozwiązywać je w sposób ustalony, czy rozwiązywać problemy równocześnie ustalając sposób pracy nad nimi?
Twój projekt narażony jest na ryzyko. Czy zechcesz je zniwelować zanim się pojawi, czy poczekasz do momentu wystąpienia realnych problemów?
Czy
zamierzasz komunikować się w sposób proaktywny, czy też spróbujesz poradzić sobie z konfliktami i niepewnością spowodowaną brakiem informacji?
Czy
zamierzasz zarządzać zakresem czy będziesz sobie radzić z kosztami i przekraczanymi terminami, wynikającymi z wykonywania większej ilości pracy niż zabudżetowano?
Czy
zamierzasz wbudować w procesy zarządcze i produktowe elementy zarządzania jakością, czy wolisz zajmować się jakością w później, gdy będzie to bardziej kosztowne? Charakterystyki projektu – np. sposoby budowy przedmiotów dostawy etc., nie zmienią się jeśli wykorzystasz formalne zarządzanie projektem. To, co ulega zmianie to sposób radzenia sobie z nieprzewidzianymi sytuacjami w trakcie projektu. Pytanie brzmi: czy problemy mają być rozwiązywane w sposób chaotyczny czy wcześniej sprecyzowany? 0.0.1.P2 Dlaczego nie wszyscy praktykują Efektywne Zarządzanie Projektem? Po przeczytaniu powyższego tekstu, możesz się zastanawiać, dlaczego nie każdy wykorzystuje zarządzanie projektem. Zapytaj siebie „czy sam tego używam?”. Zwykle jest kilka powodów:
Wymaga to zainwestowania czasu i energii. Wielu ludzi uważa się za tzw.
„praktyków”, „realizatorów”. Często nie czują się komfortowo, jeśli mają usiąść i planować, zamiast robić. Jak pokazuje praktyka lepiej oprzeć się pragnieniu pochopnego i natychmiastowego działania. To, że nie ma czasu na planowanie oraz że jest ono trudne – nie oznacza, że jest zbędne! Projekt nie zakończy się
9
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wcześniej, jeśli nie zostanie najpierw właściwie zaplanowany, a później zarządzany racjonalnie i z pewną dyscypliną.
Twoja
organizacja nie jest dostatecznie zaangażowana. Trudno być kierownikiem projektu w organizacji, która nie docenia umiejętności zarządzania projektem. Jeśli poświęcisz czas na stworzenie Definicji Projektu, a klient lub szef pyta, po co tracisz czas, prawdopodobnie nie będziesz zainteresowany dalej procesem planowania. Aby działać najefektywniej, cała organizacja powinna wspierać procesy zarządzania projektem.
Brak
właściwych kwalifikacji. Być może okaże się, że braki w stosowaniu zarządzania projektem to nie kwestia dobrych chęci, ale umiejętności. Czasem zleca się zarządzanie projektami osobom, nie posiadającym doświadczenia, często bez wcześniejszego przeszkolenia. W takich przypadkach, podejmują oni ogromny i niepotrzebny wysiłek – wyważają otwarte drzwi. Nie wykorzystują znanych i opracowanych narzędzi i technik do efektywnego zarządzania projektem, lecz działają według intuicji. Jeśli projekt zakończy się sukcesem, jest niewielka szansa, że ludzie ci będą zainteresowani dalszą karierą kierownika projektu. Jeśli projekt upadnie, prawie na pewno na trwałe zniechęcą się do pracy.
Kierownicy wyższego szczebla uważają, że zarządzanie projektem to jakieś
narzędzie. Na początku wielu sądzi, że chodzi o wprowadzenie jakiegoś narzędzia, oprogramowania. Fakt, niektóre aspekty zarządzania projektem - jak tworzenie budżetu czy zarządzanie planem, mogą wykorzystywać narzędzie. Ale ono nie jest wartością samą w sobie. Istota znajduje się w przewidywalności przedsięwzięć dzięki uporządkowanym i precyzyjnym procesom.
„Spalony temat‖. Gdy rozpoczynasz rozmowę na temat procedur, najlepszych
praktyk czy formularzy, menadżerom może się to kojarzyć z biurokracją, opóźnieniami w decyzjach i niepotrzebną papierkową pracą. Nie widzą oni wartości, jaką wnosi TenStep. Są opinie mówiące, że stosowanie metodyk zarządzania projektami równa się biurokracji i pracy jałowej. Krytyka tego rodzaju często wynika z niewłaściwego dopasowania rozwiązań metodycznych do wielkości projektów, jakie miało miejsce w firmie, w przeszłości. Jeśli należało opracowywać 15-stronicowy Dokument Inicjujący Projekt, przed każdym zadaniem nawet trwającym jedynie 250 godzin, wtedy faktycznie można nie być zainteresowanym metodyką. Choć trudno będzie w takim przypadku przekonać o tym pracowników, to jednak problem nie tkwi w samej idei stosowania metodyki, a jest jedynie wynikiem niewłaściwego jej wyboru lub zastosowania.
Lęk
przed kontrolą ze strony członków zespołu. Wielu ludzi chciałoby wykonywać swoją pracę w sposób twórczy, przy minimum nadzoru. Obawiają się, że formalne techniki wykorzystywane przy zarządzaniu projektem doprowadzą do ścisłej kontroli, która z kolei zagłuszy twórcze zapędy i dobrą atmosferę w pracy. W pewnym sensie jest w tym wiele racji. Niemniej jednak, jednolite procesy i procedury eliminują kreatywność w obszarach, gdzie prawdopodobnie nie jest ona potrzebna. Nie ma potrzeby bycia twórczym, na przykład przy realizacji zmiany zakresu. Wtedy należy jedynie przestrzegać gotowych procesów standardowych.
Lęk przed utratą kontroli ze strony kierownictwa. Aby efektywnie wprowadzać dyscyplinę w zarządzaniu projektami w firmie, należy przekazać kierownikowi projektu pewien poziom władzy. Niektóre organizacje i kierownicy średniego
10
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
szczebla nie chcą tracić jednak kontroli. Chcą oni, aby kierownicy projektów koordynowali te projekty, natomiast sami zastrzegają sobie prawo do podejmowania wszystkich decyzji. Formalne zarządzanie projektem nie będzie możliwe w organizacjach, gdzie taki lęk jest powszechny.
Niektóre
z tych lęków są naturalne i logiczne, podczas gdy inne mogą być nieracjonalne. Ponieważ mogą one powodować opór przy wykorzystaniu formalnego zarządzania projektem, należy je przezwyciężać.
Często
spotkamy się z opinią, że jeśli rezultatem wprowadzenia formalnego zarządzania projektem będzie opóźnienie, większe koszty i niska jakość, będzie to automatycznie oznaczało, że korzystanie z metodyki nie ma sensu.
W rzeczywistości, jest inaczej. Korzystanie ze spójnych technik i procesów zarządzania, zwiększa prawdopodobieństwo zakończenia projektu zgodnie z planem, budżetem i przy zachowaniu należytego poziomu jakości.
Wykorzystując procesy zarządzania projektami, jak wszędzie, należy zachować zdrowy rozsądek.
0.0.1.P3 Jak pozyskuje się metodyki? Nie możesz wprowadzić zarządzania projektem, jeśli nie wierzysz sam, że wprowadzanie procedur jest wartościowe. Po drugie, jeśli nie przekonasz ludzi, że warto je prawidłowo stosować. Skąd wziąć metodykę? Masz dwie możliwości:
1. Opracowanie własnej metodyki. Opracowanie metodyki, która doskonale odzwierciedli filozofię i najlepsze praktyki w Twojej organizacji. Aktualnie jest wiele firm, które nad tym pracują. 2. Zakup metodyki. Przy własnym opracowaniu metodyki, będziesz zaskoczony, że pod koniec będzie ona przypominała większość innych metodyk zarządzania projektem. Bez względu na to, w jaki sposób zostanie ona skonstruowana, w dalszym ciągu wymaga sporządzenia planu, harmonogramu i pomysłu na zarządzanie zakresem, ryzykiem i komunikacją itd. Stąd też, wiele firm wybiera zakup licencji na wykorzystanie istniejącej już metodyki. Te opracowane uprzednio metodyki zazwyczaj posiadają wszystko, czego potrzeba organizacji do osiągnięcia sukcesu. Oczywiście zakup metodyki wymaga w dalszym ciągu jej dostosowania, w celu spełnienia konkretnych potrzeb organizacji. To daje korzyści wynikające z opcji 1, również przy mniejszym wysiłku i niższych kosztach, co z kolei stanowi główną korzyść opisaną w opcji 2.
11
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.2 Model Dojrzałości Organizacyjnej (CMMI) 0.0.2.P1 Model Dojrzałości Organizacyjnej opisuje pięć etapów pokazujących w jakim stopniu firma przestrzega wspólnych i powtarzalnych procesów. Najniższy punkt skali charakteryzuje firmy, które nie stosują powtarzalnych procesów, gdzie większość prac wykonywana jest w sposób chaotyczny i doraźny (improwizacja, działania ad hoc). Najwyższy punkt skali opisuje organizacje, które wykorzystują zdefiniowane i powtarzalne procesy, gromadzą wyniki pomiarów i badań w celu ciągłego ulepszania swoich procesów i poszukiwania twórczych rozwiązań dla bieżącej realizacji zadań. Model Dojrzałości Organizacyjnej był opracowany w latach 1984 – 1987 przez Watts‟a Humphrey‟a i Software Engineering Institute (SEI). Instytut ten, stanowił część Uniwersytetu Carnegie Mellon. Praca została sfinansowana i jest w dalszym ciągu finansowana przez Departament Obrony USA, który od początku poszukiwał sposobów porównania i oceny różnych wykonawców, pracujących nad oprogramowaniem Ciągłe usprawnianie Benchmarking
5 Wspólna metodyka
4 3
Standardowa terminologia / pojedyncze procesy Chaos
2 1
Model Dojrzałości Organizacyjnej zawiera pięć etapów, podczas których dokonuje się oceny organizacji pod względem wprowadzania i przestrzegania standardów w realizacji procesów. 0.0.2.P2 Pięciostopniowy Model Dojrzałości Organizacyjnej (CMMI) Istnieje kilka różnych interpretacji CMMI. Niektóre firmy opracowały jego własne wersje. Etapy mają można scharakteryzować następująco:
Chaos / ad hoc. Twoja organizacja stosuje z kilka narzędzi i technik. Sukces projektów zależy od siły i umiejętności zespołu i kierownika. Organizacja nie wspiera kierowników projektów np. przez tworzenie infrastruktury czy systemów.
12
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Większość organizacji znajduje się na tym poziomie; pomimo to niektóre firmy pół żartem twierdzą, że znajdują na poziomie 0 lub nawet -1.
Pojedyncze
procesy – to etap, gdy organizacja ustandaryzowała jakiekolwiek procesy np. definiowania projektu, ustalania budżetu etc. Nie można mówić jeszcze o wspólnej metodyce, ale niektóre jej elementy są upowszechniane w całej organizacji. Na tym etapie, w firmie stosuje się jednolitą terminologię.
Wspólna metodyka – to etap, gdy organizacja zaczyna posługiwać się jednolitą
metodyką. Techniki, narzędzia i procedury są wyraźnie wyselekcjonowane i rekomendowane przez kierownictwo firmy. Wspiera ono kierowników projektów także we wszystkich ich działaniach.
Benchmarking – to etap gdy w sposób ciągły zbiera się dane dotyczące realizacji
projektów i na szeroką skalę dystrybuuje najlepsze praktyki. Dane służą budowie rankingów najlepszych menedżerów, najlepiej prowadzonych projektów etc.
Ciągłe
doskonalenie – etap nie kończy się. Polega on na ustawicznym przyglądaniu się procedurom, procesom i metodyce, i dokonywaniu w niej zmian.
Czy CMMI jest dla Ciebie właściwe? Czy Twoja firma powinna zastosować się do modelu CMMI? Korzyści standaryzacji komponentów w wielu branżach – IT, przemysł samochodowy, metalurgia – są dobrze znane i udowodnione. Tak samo stosowanie ujednoliconych procesów zalecane przez CMMI jest dużą wartością. Dlaczego? Każdy kierownik projektu rozumie po co się definiuje projekt, jak szczegółowy powinien być plan operacyjny, w jaki sposób zarządzać zakresem, ryzykiem i jakością. Co więcej rozumie to tak samo. Nie są to zapewne nowe koncepcje w Twojej firmie. Wiadomo, że wszystkie procesy powinny zostać zdefiniowane na poziomie organizacyjnym. To pozwoliłoby na ich późniejsze jednolite wykorzystywanie przez wszystkich kierowników projektów. Modelem CMMI możesz posługiwać się jako przewodnikiem w tego rodzaju pracy. Skala CMMI jest jak podróż. Większość firm chce rozpocząć ją jedynie pod warunkiem znalezienia się od razu na poziomie 2. Inni, ambitni, chcą w ciągu roku przesunąć się od poziomu pierwszego do piątego. Jest to tak samo możliwe, jak i bolesne. Pod wieloma względami, wprowadzanie uspójnionych procesów zarządzania projektem jest najtrudniejszą częścią tej podróży. W wielu organizacjach ludzie po raz pierwszy zostaną zobligowani do przestrzegania całego zestawu procedur i z pewnością im się to nie spodoba. Jeśli potrafisz pomyślnie dotrzeć z poziomu 1 do 2, oznacza to, że opracowałeś odpowiedni sposób na implementacji zmian. Dlatego dalsze przejścia do poziomu 3 i wyżej, okażą się łatwiejsze. Cała trudność w rozwoju organizacji w obszarze zarządzania wiąże się z wprowadzaniem zmian kultury organizacyjnej. Przebudowa nawyków nie jest łatwa z wielu względów. Choćby z reguły duży opór wywołuje proces „oduczania” zachowań niepożądanych. Zmiany te są jednak warte przeprowadzenia zwłaszcza, gdy w grę wchodzi obietnica poprawy jednocześnie efektywności i skuteczności działania.
13
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.3 Styl języka TenStep 0.0.3.P1
Zwięzły styl. W opisach procesów, technik i narzędzi dążyliśmy do tak dużej
zwięzłości jak to możliwe. Nikt w biznesie nie używa 1000-stronicowych metodyk. Nie ma czasu na ich przeczytanie, a co dopiero stosowanie. Celem TenStep nie jest dostarczenie wyczerpujących informacji przy opisach każdego z procesów. Wartością TenStep jest to, że jasno określa on minimalny zestaw wiedzy i informacji, które gwarantują sprawne zarządzanie. Stawiamy śmiało hipotezę, że jeśli czegoś nie ma w TenStep oznacza to, że w znacznej większości przypadków jest to po prostu zbędne.
Słowa
„Ty‖ i „Twój‖ odnoszą się do kierownika projektu. Metodyka jest tworzona dla potrzeb kierownika projektu jako głównego odbiorcy tekstu. Założeniem jest, że czytelnik jest kierownikiem projektu lub za chwilę nim zostanie.
Zaimki „on‖ i „jego‖ są używane w celu wprowadzenia spójności i pewnego
uproszczenia. We wcześniejszym wydaniu TenStep, użyliśmy zaimków „on lub ona”, „jego lub jej” tak, aby nie sugerować płci kierownika projektu. Naszym zdaniem, wprowadziło to pewien nieład.
Użycie
terminu „dolary‖. Proces TenStep może odnosić się do kosztów uwzględniając „dolary” jako walutę obowiązującą w projekcie. Jest to oczywiście amerykańska tendencja. Jednak, te same zasady będą stosowane bez względu na to, czy Państwa waluta to dolar amerykański, dolar kanadyjski, euro, złotówka, itp. Jeśli zobaczą Państwo dolary amerykańskie jako walutę użytą w metodyce, proszę zastąpić je walutą swojego kraju.
14
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.4 Jak korzystać z TenStep Po dokonaniu klasyfikacji projektu wg podstawowych kategorii: mały, średni lub duży (1.0.1.2 Ocena wielkości: mały, średni, duży), zacznij od procesu 1.0 – Definiowanie Projektu. Zwróć uwagę, że znajdują się tam opisy o różnych poziomach szczegółowości – w zależności od rodzaju definiowanego projektu. Zanim zaczniesz analizować procesy TenStep – zastanów się, który z trzech typów projektów najbardziej jest zbliżony do twojego. Przegląd wszystkich procesów, które na razie nie dotyczą Twojego projektu jest wartościowy, ponieważ być może znajdziesz dodatkowe informacje, aczkolwiek zajmij się tym w drugiej kolejności. To samo należy zrobić w procesach: 2.0, 3.0 i 4.0. To procesy wykorzystywane w zasadzie we wszystkich typach projektów. Należy rozpocząć od zrozumienia przebiegu procesu dla danej wielkości projektu, a następnie ewentualnie dodać czynności zalecane dla innych typów projektów, jeżeli uznasz, że wymaga tego Twoje przedsięwzięcie. Bardzo istotnym procesem jest Zarządzanie Zmianami (5.0). Jest on bardzo ściśle związany z zdefiniowaniem projektu. Wszystko, co do tej pory przeczytałeś w tej sekcji ma zastosowanie dla projektów małych i średnich. Zarządzanie zakresem dużego projektu powinno być zdecydowanie bardziej rygorystyczne i precyzyjne. Stąd też w dużych projektach zaleca się o wiele dokładniejsze prace nad zakresem, na etapie definiowania projektu. Są one dokładnie opisane w częściach dotyczących definiowania projektu 1.0 i zarządzania zmianami 5.0. Aczkolwiek gdy definiujesz duży projekt po raz pierwszy wspomniana wyżej precyzja nie jest wymagana w pierwszym opracowaniu definicji projektu. Przy niskim poziomie dokładności opisu, musisz uruchamiać kolejne procesy np. planowanie pracy i budżetu, aby zobaczyć związki: definicja – zakres – plan. I dlatego tak ważne jest prawidłowe wstępne określenie kategorii projektu, z jakim masz do czynienia. Gdy już będziesz biegle poruszać się w TenStep, mając do czynienia z dużymi projektami od początku będziesz wiedział jak zachować ten wymagany rygor i dyscyplinę przy pracy nad zakresem. TenStep nie zakłada sekwencyjnego uruchamiania procesów. Najpierw należy zdefiniować i zaplanować projekt. Później będzie można nim zarządzać. Tak więc, procesy 1.0 i 2.0 należy uruchomić najpierw. Procesy od 3.0 do 10.0 realizowane są asynchronicznie, często równolegle. Numeracja procesów TenStep nie jest przypadkowa. Im wyższy numer, tym rzadziej proces jest stosowany. Tak wynika z praktyki. Stąd też łatwo zauważyć, że procesy wyższe opisują czynności dla projektów średnich lub dużych. W mniejszych projektach problemy, których dotyczą procesy 7 – 10 oczywiście występują. Jednak nie ma potrzeby formalnego zarządzania nimi i tworzenia spisanych reguł postępowania. Dla małych projektów TenStep zaleca np. w przypadku ryzyk, problemów ludzkich, jakościowych etc., zachowanie zdrowego rozsądku, wyczucia i intuicji. Najlepiej jest zapoznać się z całym TenStep. To umożliwi elastyczny dobór sposobu zarządzania projektem. Np, masz do czynienia z dużym projektem, ale zarządzanie komunikacją być może należałoby przeprowadzić tak, jak przy projektach średniej wielkości (proces 6.0). Przy dużym projekcie, w przeciwieństwie do małego przedsięwzięcia, może nie być potrzeby gromadzenia wielu pomiarów. W takim przypadku możesz stosować zalecenia odnoszące się do małych projektów itd.
15
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.5 Wytyczne TenStep 0.0.5.P1 Poniżej przedstawiamy główne zasady działania TenStep:
Skalowalność.
Proces zarządzania projektem powinien być skalowalny i elastyczny oraz dopasowany do wielkości projektu. TenStep wyznaje zasadę „mała metodyka dla małych projektów, duża metodyka dla dużych projektów”. Skalowalność odnosi się do poziomu złożoności procesów zarządzania projektem, jak również do poświęconego im czasu i uwagi.
Uniwersalność. TenStep jest zaprojektowany do zastosowania we wszystkich
rodzajach projektów, niezależnie, czy będzie to budowa domu, instalacji elektrycznej, czy też oprogramowania. W zasadzie, we wszystkich projektach występuje planowanie, zarządzanie ryzykiem, zakresem itp.
Proaktywność.
Projektami należy zarządzać w sposób pro aktywny, tzn. zapobiegawczy. Niezależnie od wielkości projektów, ich kierownicy powinni zapobiegać problemom, przeciwdziałać im, a nie czekać do momentu, aż się wydarzą i dopiero wtedy działać.
Partnerstwo zespół projektowy - klient. Udany projekt
wymaga partnerstwa pomiędzy zespołem projektowym a klientem. Bez aktywnego udziału ze strony klienta, projekt jest narażany na większe ryzyko niepowodzenia.
Wcześniejsze
ustalenie procesów zarządzania. Procesy zarządzania projektem powinny być ustalane z pewnym wyprzedzeniem, w sposób jasny i zrozumiały zarówno dla zespołu, jak i klienta. Większość procesów wymaga działań członków zespołu projektowego oraz klienta. Osoby te, nie zrozumieją swojej roli w danym procesie, jeśli nie zostanie on z nimi uprzednio omówiony.
Nadawanie uprawnień kierownikowi projektu.
Kierownicy projektów powinni posiadać odpowiednie uprawnienia decyzyjne, jeśli są odpowiedzialni za zarządzanie projektem sposób gwarantujący, że przedmioty dostawy będą wytworzone. Jeśli kierownik projektu nie ma prawa do podejmowania kluczowych decyzji z punktu widzenia zarządzania projektem, nigdy nie odniesie sukcesu.
16
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.6 Model Procesu TenStep Oto kilka kluczowych kwestii w modelu TenStep. 0.0.6.P1 Asynchroniczne procesy Procesy TenStep nie uruchamiają się według porządku sekwencyjnego, ale asynchronicznie. Aczkolwiek przed uruchomieniem procesu zarządzania planem pracy należy zaplanować projekt. Procesy 1.0 i 2.0 będą więc realizowane wcześniej niż pozostałe. Na etapie realizacji pracy wiele procesów będzie prowadzonych równolegle. Jednakże im dokładniej zaplanuje i zdefiniuje się projekt oraz jego zakres, tym mniej komplikacji będzie podczas realizacji. 0.0.6.P2 Proces 3.0 jest kluczowym z punktu widzenia integralności projektu Proces 3.0 Zarządzanie Planem i Budżetem realizuje zasadę: „Wszystko, co znajduje się w planie, zostanie zrealizowane, a jeśli jakieś zadanie się tam nie znalazło, to nie będzie ono realizowane i nie należy do projektu”. Harmonogram jest centralnym dokumentem w zarządzaniu projektem i wszystkie czynności, z których składają się procesy zarządzania, są w nim ujęte. Należy zarezerwować czas na zadania związane z komunikacją, zarządzaniem zakresem, uaktualnianiem harmonogramu oraz na inne czynności związane z zarządzaniem. Procesy zarządzania nawzajem się więc przenikają. Dodatkowo łączą się one z czynnościami związanymi z budowaniem przedmiotów dostawy, z tzw. cyklem życia projektu. I wszystko to powinno być odzwierciedlone w harmonogramie. Przykłady:
Udzielono zgodę na znaczną zmianę zakresu, która będzie skutkowała większym
nakładem pracy i kosztów (wynik działania procesu 5.0). Jest to typowe połączenie pracy związanej z zarządzaniem projektem i działaniami związanymi z wytwarzaniem przedmiotów dostaw (cykl życia projektu). Wpływ tej zmiany powinien zostać odzwierciedlony w uaktualnionym planie operacyjnym i budżecie (za co odpowiada proces 3.0).
Zidentyfikowano
listę ryzyk i Plan Zarządzania Ryzykiem w celu uniknięcia sytuacji kryzysowej (działania procesu 7.0). Następnie przedstawiono ten Plan wszystkim interesariuszom w celu zaopiniowania (zarządzanie komunikacją 6.0). Ponieważ cała ta praca zabiera dużo czasu i energii, zadania te umieszczane są w harmonogramie (proces 3.0 Zarządzanie Planem i Budżetem).
Cała praca związana z projektem powinna być ujęta w harmonogramie i budżecie. Zarządzanie planem pracy i budżetem to proces, poprzez który odbywa się zarządzanie i kontrola, a także realizowane są wszystkie czynności związane z wytwarzaniem przedmiotów dostawy, począwszy od fazy analizy, poprzez wykonanie a skończywszy na ich wdrożeniu / przekazaniu do implementacji.
17
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.6.P3 Wyższe etapy istotnie zakładają większy poziom uszczegółowienia w zarządzaniu projektem Wyższe etapy istotnie zakładają większy poziom uszczegółowienia w zarządzaniu projektem. Na przykład, mniejsze projekty niekoniecznie potrzebują zarządzania ryzykiem (etap 7.0), ponieważ problem ryzyka nie występuje tam w stopniu, który mógłby powodować jakieś obawy. Podobnie praca wymagana do zarządzania jakością (proces 9.0) oraz do zarządzania pomiarami (proces 10.0), zazwyczaj oznacza, że przy małych i średnich projektach duży wysiłek nie jest potrzebny.
Legenda: rysunek będzie poprawiony 1. Definiowanie projektu 2. Tworzenie Harmonogramu i Budżetu 3. Zarządzanie Harmonogramem i Budżetem 4. Zarządzanie Problemami Krytycznymi 5. Zarządzanie Zakresem 6. Zarządzanie Komunikacją 7. Zarządzanie Ryzykiem 8. Zarządzanie Ludźmi (Zasobami ludzkimi) 9. Zarządzanie Jakością 10. Zarządzanie Pomiarami
18
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.6.P4 Metodyka TenStep Project Management Procesess nie obejmuje Cyklu Życia Projektu Zarządzanie projektem jest zbiorem działań, który ułatwia zespołowi odniesienie sukcesu, poprzez ustalenie reguł postępowania gwarantujących ten sukces. Oprócz czynności zarządczych, które de facto stanowią niewielki procent wykonywanych działań, najważniejsza jest właściwa praca nad przedmiotami dostawy. Jest ona nazywana „cyklem życia projektu”. Każdy typ projektu żyje innym życiem. Inaczej buduje się dom, inne fazy projektu będą w przypadku dokonywania poprawek w procesie produkcji taśmociągu czy zwałowarki, jeszcze inaczej podzieli się projekt szkolenia organizacji z zakresu zarządzania projektem. Aczkolwiek, niezależnie od specyfiki i typu pracy, można znaleźć pewne cechy wspólne. Charakterystyczne dla życia większości projektów. Te elementy wspólne to np. zawsze wykonuje się jakieś analizy. Później, a nie wcześniej, rozpoczyna się budowę prototypu. Budowę produktów testowych można wykonać, gdy prototyp spełnił swoje zadanie. Testy dopiero wskazują czy można rozpocząć implementację rozwiązania. Te działania znajdują się poza zakresem TenStep Project Management Procesess opisywanym w tej metodyce. (Cykl Życia Projektu jest szerzej omówiony w LifecycleStep, informacje na stronie internetowej: www.LifecycleStep.com.) 0.0.6.P5 TenStep nie obejmuje procesu zbierania szczegółowych wymagań Niektóre metodyki zawierają proces zbierania wymogów biznesowych. Traktują go jako część procesu zarządzania projektem. TenStep opisuje sposoby wykonania analizy wymogów na takim poziomie ogólności, aby móc przygotować dokument Definicja Projektu. Jeśli jest to niewystarczające, zbieranie szczegółowych wymagań biznesowoanalitycznych jest częścią metodyki opisującej pełen cykl życia projektu LifecycleStep , szczególny na www.LifecycleStep.com. Od wielu kierowników projektów oczekuje się zaprezentowania dokładnej estymacji kosztów oraz pracochłonności jeszcze na etapie tworzenia Definicji Projektu. Ale przecież szczegółowe wymagania jeszcze nie zostały zbierane i analizowane, jeszcze nie opracowano dokładnych planów. Więc w jaki sposób oszacować pracę, nie posiadając takich danych? Pytanie jest dość istotne. Gdy w TenStep mówimy o szczegółowym zbieraniu wymogów biznesowych, zazwyczaj mamy na myśli Fazę Analizy, która jest częścią cyklu życia projektu. Nie klasyfikujemy tego jako pracę związaną z zarządzaniem projektem, tym bardziej z definiowaniem projektu lub jego planowaniem. Można natomiast wyodrębnić podprojekt, którego przedmiotem dostawy będą precyzyjnie zebrane wymagania biznesowe, stanowiące materiał na podstawie którego oszacuje się koszty projektu, a Sponsor podejmie adekwatne decyzje, czy projekt realizować, czy nie. Pierwsza myśl, jaka przychodzi do głowy (szczególnie młodym kierownikom projektu) mówi: powinno się zdobyć dane i zanalizować wymagania biznesowe przed rozpoczęciem prac nad definicją i szacowaniem pracochłonność. Czy jest to praktyczne podejście? Powiedzmy, że mamy typowy projekt IT. Projekt ten może potrwać około 6 miesięcy, natomiast czas gromadzenia wymogów przewidziano na 6 do 8 tygodni (lub dłużej). Czy powinniśmy wstrzymywać wykonanie wyceny projektu i zatwierdzania jego definicji do momentu zgromadzenia wymogów i wszystkich danych? Jeśli tak, to projekt będzie zrealizowany już w 1/3 przed formalnym zatwierdzeniem kosztów i ostatecznych terminów obowiązujących dla całego projektu. A jeśli ten projekt będzie budzić obawy? Koszty będą zbyt wysokie w stosunku do spodziewanych korzyści? Może się okazać, że wydałeś znaczną ilość środków, na projekt, który nie będzie kontynuowany! Ale jest już
19
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
za późno. I dlatego też TenStep, jak większość metodyk zarządzania projektem, nie obejmuje gromadzenia szczegółowych wymogów biznesowych. Poniżej przedstawiamy trzy podejścia, które pozwolą Ci na ocenę pracy przed zgromadzeniem wymogów biznesowych. (Zakładają one, że gromadzisz wymogi w pierwszym etapie realizacji projektu. Mechanizm ten nazywany jest również „modelem wodospadu”. Następnie korzystasz z technik iteracyjnych - możesz zdobyć szczegółowe wymogi biznesowe w kolejnych iteracjach, podczas trwania projektu).
Oszacuj projekt podczas przygotowywania definicji i budowania planu na
podstawie już zrealizowanych, dodaj jednak 10%. Jest to tradycyjne podejście i w wielu przypadkach jest w dalszym ciągu opłacalne. Niemniej jednak, aby je zastosować musisz mieć doświadczenie w realizacji podobnych projektów. Jeśli znasz mniej więcej ogólnie wymagania biznesowe i nie różnią się one za bardzo od poprzednio realizowanych przedsięwzięć, możesz założyć, że następny projekt będzie kosztował i trwał tyle samo. Dla bezpieczeństwa jednak powinieneś dodać 10% do estymacji. Jeśli okaże się po procesie gromadzenia wymogów szczegółowych, że ocena została przeprowadzona niewłaściwie, należy się zwrócić o zaakceptowanie zmian w budżecie i harmonogramie. Oczywiście, kontrolę estymacji należy przeprowadzić pod koniec każdego z etapów prac.
Podział pracy na mniejsze części. Jeśli nie czujesz się na siłach, aby dokonać
ogólnej oceny projektu, wtedy możesz podzielić projekt na mniejsze podprojekty. Następnie oszacuj koszty i czas trwania tych projektów. Po zakończeniu tej części będziesz mieć zgromadzone dane, które pozwolą Sponsorowi zdecydować o tym, czy rozpoczynać pracę nad zbieraniem wymagań szczegółowych i uruchamiać projekt, czy też nie.
Przybliżona
ocena planu i oszacowanie budżetu oraz potwierdzenie po zgromadzeniu wymogów. Jest to odmiana pierwszej techniki. W niniejszym podejściu, kierownik projektu podaje najlepszą, szacunkową ocenę pracy. W tym samym czasie trwają prace nad tworzeniem harmonogramu i definicji projektu. Niemniej jednak, w oparciu o zasady, których przestrzega firma. Za tę szacunkową ocenę nie odpowiada kierownik projektu. Po zgromadzeniu wymogów, kierownik projektu podaje bardziej szczegółową ocenę pracy. W tym przypadku, kierownik projektu staje się odpowiedzialny za dokonanie takiej oceny.
Wielu kierowników projektów uważa, iż najlepszym podejściem jest iteracyjne (krok po kroku) gromadzenie wymogów. Iteracyjny cykl życia nie daje odpowiedzi w kwestii sposobu dokonywania oceny projektu. W rzeczywistości, podejścia iteracyjne mogą spowodować, że określenie poziomu dokładności stanie się jeszcze trudniejsze do oszacowania. Trzy wyżej wymienione rozwiązania, proponują bardziej realne i wykonalne techniki oceny pracy przed jej rozpoczęciem w granicach błędu 10%. 0.0.6.P6 TenStep nie postrzega zarządzania relacjami z dostawcami jako kluczowych zadań w zarządzaniu projektem Niektóre metodyki odnoszą się w sposób szczególny do pracy z dostawcami oraz pracownikami zatrudnionymi czasowo, wyłącznie do realizacji projektu. TenStep uznaje odbiór, kontrolę dostaw od dostawców, nabywanie i akceptację pracy pracowników czasowych za ważne czynności w projekcie. Jednak nie kwalifikuje ich do działań należących do zarządzania projektem. W wielu firmach zajmują się tym działy zakupów, outsourcingu etc. TenStep zaleca, abyś jako kierownik projektu zapoznał się z tymi 20
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zasadami. Dobrze jest wprowadzić wymóg, by Twoi dostawcy według reguł TenStep raportowali o ryzykach, zakresie, jakości etc., w projekcie. 0.0.6.P7 TenStep nie obejmuje ścieżki przekształcenia idei w propozycję projektu TenStep stosuje się, gdy idea, przypadek biznesowy został już wstępnie przeanalizowany i wiadomo, że danym zagadnieniem należy się zająć, ponadto zyska ono odpowiedni priorytet w pracach oraz finansowanie. Metodyka nie obejmuje procesu gromadzenia idei, analizowania ich zasadności oraz zgodności ze strategią firmy. Jest to opisane bardzo dokładnie przez TenStep Inc., w metodyce PortfolioStep, szczegóły na www.portfoliostep.com. 0.0.6.P8 Oficjalne otwarcie projektu rozpoczyna się po wyznaczeniu kierownika projektu Pierwszym zadaniem kierownika projektu jest formalne zdefiniowanie pracy oraz przygotowanie harmonogramu i budżetu. Za punkt startu projektu TenStep zaleca przyjąć moment gdy formalnie wyznaczono kierownika. Nawet, jeśli zakończy on swoją pracę jedynie na opracowywaniu definicji projektu i budżetu, a później prace przekaże swojemu następcy. Kierownik projektu jest rolą. Nie ma zasadniczego znaczenia to, kto pracuje nad definicją, budżetem i realizacją projektu i czy jest to jedna osoba, czy rolę tę pełnią inni ludzie.
21
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8 Porównania TenStep Project Management Process 0.0.8.P1 Celem tej części opracowania jest porównanie TenStep z innymi metodykami. Głównym zamierzeniem jest omówienie w sposób sprawiedliwy i bezstronny ich różnic oraz podobieństw. Niemniej jednak, jeśli opinie czytelników będą inne od przedstawionych, prosimy o ich zaprezentowanie, przesyłając je na adres
[email protected]. 0.0.8.2 TenStep a PMBOK - The PMI Project Management Body of Knowledge (PMBOK) Third Edition® 0.0.8.3 TenStep a PRINCE2® 0.0.8.4 TenStep a Six Sigma 0.0.8.5 TenStep a Agile Development 0.0.8.6 TenStep a ISO 10006
22
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.2 TenStep a The PMI Project Management Body of Knowledge (PMBOK) Third Edition® 0.0.8.2.P1 Każda metodyka posiada własny sposób opisu procesów, procedur, najlepszych praktyk oraz wzorców. Jeśli przyjrzysz im się bliżej i bardziej wnikliwie, to z pewnością zauważysz wiele podobieństw. Różnice występują również, choć niezbyt nieczęsto. Jednym z najbardziej znanych modeli zarządzania jest PMBOK®), który został opracowane przez PMI (Project Management Institute). PMBOK zawiera wiele cennych informacji i opisuje większość procesów, które można znaleźć również w TenStep. Istnieje jednak różnica w układzie treści – inna numeracja procesów. Ważniejszą różnicą jest to, że PMBOK to metodologia zarządzania projektem, a więc tworzy jedynie fundament, dostarcza podstawowych informacji, mówiących co należy robić w projekcie. Ponieważ nie jest to metodyka, PMOBK nie może być wykorzystany bezpośrednio do zarządzania projektem. Nie zawiera on precyzyjnych opisów działań, które jednoznacznie pokazują jak postępować. PMI wydał oświadczenie w magazynie PMNetwork z roku 2004, że PMBOK® Guide nie jest metodyką oraz zbiorem szczegółowych procedur. Znajdują się tam informacje i definicje, ale nie procedury czy też techniki. Z drugiej strony nic, co zostało opublikowane w TenStep nie jest sprzeczne z PMBOK®. Ponieważ wielu czytających TenStep zna PMBOK®, ten rozdział pokazuje odwzorowanie obszarów wiedzy i procesów zarządzania projektem zawartych w PMBOK®, wraz z odpowiadającym mu procesem TenStep. Czytelnicy, którzy chcieliby wykorzystać model PMBOK® jako podstawę swojego projektu, mogą dokonać przeglądu TenStep PB (PMBOK® Framework), dostępnego na stronie internetowej www.TenStepPB.com. Produkt ten, łączy całą treść TenStep w jeden pełny model PMBOK®. 0.0.8.2.P1 (PMBOK®) Trzecia edycja..
TenStep BP
4. Zarządzanie Integralnością Projektu. 4.1 Opracowanie Charter.
dokumentu
Project Project Charter zawiera informacje umożliwiające zatwierdzenie projektu do realizacji, po uprzednim zdefiniowaniu go. Wiele z nich zawiera również: rozdział 1.0 TenStep - Definiowanie Projektu
4.2 Opracowanie wstępnego Project Scope 1.0 Definiowanie projektu Statement.
23
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.3 Opracowanie projektem.
planu
zarządzania 1.0 Definiowanie projektu
4.4 Kierowanie i zarządzanie wykonaniem W TenStep m.in. w: projektu. 3.0 Zarządzanie harmonogramem i budżetem oraz w pozostałych rozdziałach: 4.0 Zarządzanie krytycznymi
problemami
5.0 Zarządzanie zmianami etc.. 4.5 Monitorowanie i kontrola pracy w Monitorowanie i kontrolowanie Planu ramach projektu. Zarządzania Projektem –: 3.0 Zarządzanie harmonogramem i budżetem. 4.6 Zintegrowana kontrola zmian.
5.0 Zarządzanie zmianami, włącznie z: 5.1.3.1 Zarządzanie konfiguracją.
4.7 Zamknięcie projektu.
Rozpoczęcie i zamknięcie projektu to część ogólna 3.0 Zarządzanie harmonogramem i budżetem.
5. Zarządzanie zakresem projektu. 5.1 Planowanie zakresu.
1.0 Definiowanie projektu . Plan Zarządzania Zakresem Projektu jest częścią Planu Zarządzania Projektem.
5.2 Definiowanie zakresu.
1.0 Definiowanie projektu. Treść Definicji Zakresu jest częścią Definicji Projektu (Project Charter)_.
5.3 Tworzenie struktury podziału pracy 2.0 Tworzenie harmonogramu i (WBS Work Breakdown Structure). budżetu. Struktura Podziału Pracy (WBS) jest częścią procesu tworzenia harmonogramu (planu operacyjnego).
24
5.4 Weryfikacja zakresu.
Ten podproces wymaga zaangażowania klienta i zatwierdzenia głównych przedmiotów dostawy. W TenStep, jest to uznane za część Kontroli Jakości oraz Kryteriów Jakościowych Odbioru gdzie obie kwestie zostały ujęte w etapie 9.0 Zarządzanie Jakością oraz w rozdziale 1.0. Weryfikacja bieżąca może stanowić element odbiorów i weryfikacji Kamieni Milowych projektu (Milestone), co jest zawarte w 3.0 Zarządzanie harmonogramem i budżetem.
5.5 Kontrola zakresu.
Zarządzanie zmianą zakresu jest częścią 5.0 Zarządzanie zmianami.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6. Zarządzanie czasem projektu. 6.1 Definicja zadań.
Określenie zadań elementarnych jest częścią procesu 2.0 Tworzenie harmonogramu i budżetu 6.2 Określanie sekwencji zadań 2.0 Tworzenie harmonogramu i budżetu. 6.3 Szacowanie zasobów 2.0 Tworzenie harmonogramu i budżetu. niezbędnych do wykonania zadań 6.4 Szacowanie czasu trwania 2.0 Tworzenie harmonogramu i budżetu zadań 6.5 Opracowanie harmonogramu. 2.0 Tworzenie harmonogramu i budżetu. 6.6 Kontrola harmonogramu. 3.0 Zarządzanie harmonogramem i budżetem. 7. Zarządzanie kosztami projektu. 7.1 Oszacowanie kosztów. 2.0 Tworzenie harmonogramu i budżetu. 7.2 Tworzenie budżetu. 2.0 Tworzenie harmonogramu i budżetu. 7.3 Kontrola kosztów. 3.0 Zarządzanie harmonogramem i budżetem. 8. Zarządzanie jakością projektu. 8.1 Planowanie jakości. 1.0 Definiowanie projektu oraz 9.0 Zarządzanie jakością. 8.2 Zapewnienie jakości. 9.0 Zarządzanie jakością. 8.3 Kontrola jakości. 9.0 Zarządzanie jakością. 9. Zarządzanie zasobami ludzkimi. 9.1 Planowanie zasobów ludzkich. 1.0 Definiowanie projektu (Obsadzanie stanowisk w projekcie jest opisane w Definicji Projektu – struktura organizacyjna.) Dodatkowe zasady obsadzania stanowisk oraz plany stanowią część procesów zarządzania wiązką projektów (www.PortfolioStep.com). 9.2 Tworzenie zespołu 8.0 Zarządzanie zasobami ludzkimi. projektowego. 9.3 Rozwój zespołu projektowego. 8.0 Zarządzanie zasobami ludzkimi. 9.4 Zarządzanie zespołem 8.0 Zarządzanie zasobami ludzkimi. projektowym. 10. Planowanie komunikacji. 10.1 Planowanie komunikacji. Budowanie planu komunikacji zawiera 1.0 Definiowanie projektu. 6.0 Zarządzanie komunikacją . 10.2 Dystrybucja informacji. 6.0 Zarządzanie Komunikacją. 10.3 Raportowanie w projekcie 3.0 Zarządzanie harmonogramem i budżetem. 6.0 Zarządzanie komunikacją. 10.4 Obsługa interesariuszy. Analiza interesariuszy jest częścią 1.0 Definiowania Projektu. Plan komunikacji dla każdej grupy interesariuszy jest częścią procesu 6.0 Zarządzanie komunikacją. Kwestie związane z obsadzaniem i komunikowaniem problemów krytycznych opisano w kroku 4.0 Zarządzanie kwestiami krytycznymi. 11. Zarządzanie ryzykiem projektu. 25
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
11.1 Plan zarządzania ryzykiem.
Identyfikacja ryzyk to część procesu 1.0 Definiowanie projektu. Bieżąca analiza ryzyk to część procesu 7.0 Zarządzanie ryzykiem. 11.2 Identyfikacja ryzyka. 7.0 Zarządzanie ryzykiem. 11.3 Jakościowa analiza ryzyka. 7.0 Zarządzanie ryzykiem. 11.4 Ilościowa analiza ryzyka. 7.0 Zarządzanie ryzykiem. 11.5 Planowanie odpowiedzi ryzyka. 7.0 Zarządzanie ryzykiem. 11.6 Kontrola i monitoring ryzyka. 7.0 Zarządzanie ryzykiem. 12. Zarządzanie dostawcami projektu. 12.1 Plan zakupów oraz 1.0 Definiowanie projektu. podwykonawstwa. 12.2 Plan zawierania umów. 1.0 Definiowanie projektu. 12.3 Obsługa procesu kontraktacji – 1.0 Definiowanie projektu. odpowiadanie na zapytania oferentów. 12.4 Wybór dostawców. 1.0 Zdefiniowanie projektu-Statut Projektu. 12.5 Administrowanie kontraktami. 3.0 Zarządzanie harmonogramem i budżetem. 12.6 Zamknięcie umowy. Zamknięcie projektu jest częścią etapu 3.0 Zarządzanie Planem operacyjnym i budżetem. Inne Inne Zarządzaniu kwestiami krytycznymi 4.0 Zarządzanie problemami krytycznymi. nie poświęcono zbyt dużo uwagi w Problemy krytyczne to problemy, które mogą PMBOK®. Kompendium to utrudniać prowadzenie projektu, lecz znajdują rzeczywiście odnosi się do kwestii się poza kontrolą zespołu projektowego. krytycznych jako do problemów, które mogą w jakiś sposób zakłócić zespołowi pracę.
26
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.3 Porównanie metodyki TenStep do PRINCE2® 0.0.8.3.P1 Szczegółowe porównanie znajduje się na stronie www.tenstep.pl.
27
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.4 Porównanie TenStep do Six Sigma 0.0.8.4.P1 Informacje ogólne dotyczące Six Sigma Six Sigma odnosi się do filozofii, celu lub metodyki wykorzystywanej do redukcji strat i poprawy jakości, wykonania pod względem kosztów i czasu wszelkich przedsięwzięć. Sigma, to grecka litera, oznaczająca ilość zmian lub poziom wadliwości produktu. (Wada jest zdefiniowana jako wszystko, co powoduje niezadowolenie klienta lub odchylenie od przyjętych tolerancji). Typowa dzisiejsza firma może pracować na trzecim poziomie Sigma, co oznacza, że na 16 możliwości wystąpi jedna wada. Równa się to około 67,000 wad na milion możliwości. Lepsza firma, może znajdować się na czwartym poziomie Sigma, co oznacza 1 wadę na 160 możliwości. Nieźle, ale w dalszym ciągu to ponad 6,000 błędów na milion. Poziom osiągany przez Six Sigma jest równy 3,4 błędy na milion możliwości – do perfekcji niedaleko. Ogólnie rzecz biorąc, Six Sigma to filozofia zapewniająca firmom szereg procesów oraz narzędzi statystycznych, które przyczyniają się zarówno do poprawy jakości, jak i wzrostu opłacalności – bez względu na to, czy firma produkuje wytrzymałe produkty, czy też świadczy usługi. Six Sigma jest procesem długoterminowym, który ma na celu ciągłe ulepszanie. Poprawa taka nie jest możliwa do zrealizowania poprzez restrukturyzację firmy lub po prostu zainwestowanie środków finansowych. Jakość Six Sigma wymaga wytrwałości, poświęcenia i skupienia. Poziom jakości Six Sigma można osiągnąć poprzez ciągłe łączenie systematycznych i strukturyzowanych projektów. Projekty dzieli się według następujących kategorii:
Projekty transakcyjne, obejmujące procesy przedsięwzięć, które wykraczają poza organizację.
Projekty tradycyjne, mające na celu poprawę jakości, które rozwiązują problemy obejmujące różne funkcje w ramach organizacji.
Projekt, firma lub organizacja podejmująca próby osiągnięcia poziomu jakości Six Sigma powinna skoncentrować się na projekcie produktów, usługach oraz procesach. Zasady Six Sigma można zastosować w wielu dziedzinach, m.in. w usługach przemysłowych, administracyjnych, jak również przy obsłudze klienta. Techniki Six Sigma pomagają zredukować pewne zmienności, co z kolei obniża liczbę błędów oraz kosztów operacyjnych przy jednoczesnym wzroście efektywnej wydajności. Techniki te, mogą być również wykorzystane do ulepszania innych obszarów, takich jak np. lojalność klienta, co również przyczynia się do wzrostu wyników finansowych firmy. 0.0.8.4.P2 Analiza Procesu Zarządzania Projektem TenStep Zarządzanie projektem odnosi się do definicji i planowania, a następnie do zarządzania, kontroli oraz zamknięcia projektu. Należy zauważyć, iż wszystkie projekty wymagają pewnego poziomu zarządzania. Im większy i bardziej złożony projekt, tym większa potrzeba wdrożenia formalnego, standardowego i strukturyzowanego procesu. Mniejsze
28
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projekty również wymagają procesów strukturyzowanych, lecz nie tak zawiłych i złożonych. Oczywiście, istnieje cena za wysiłek związany z zarządzaniem projektem, lecz nie należy zapominać o licznych korzyściach, które można również przy tym osiągnąć. Te korzyści jednak dalece przewyższają koszty. Proces TenStep jest podzielony na dziesięć etapów – pierwsze dwa dotyczą definicji i planowania, a kolejnych osiem poświęcono zarządzaniu i kontroli pracy. Etapy te są następujące: 1.0 Definiowanie projektu. Kierownik projektu zajmuje się zdefiniowaniem pracy w celu zagwarantowania zgodności w postrzeganiu produktu dostawy, korzyści i celu przez zespół projektowy oraz przez klienta. 2.0 Tworzenie planu operacyjnego i budżetu. Plan operacyjny jest zasadniczym narzędziem wyznaczającym zespołowi projektowemu zadania do wykonania. 3.0 Zarządzanie Planem operacyjnym i budżetem. Plan operacyjny należy aktualizować. Służy on bowiem do tego, aby informować, ile pracy pozostało jeszcze do wykonania. 4.0 Zarządzanie problemami krytycznymi Wiele pojawiających się problemów rozwiązywanych jest na bieżąco. Niemniej jednak, sprawa sporna pojawia się wtedy, gdy problem zaczyna utrudniać postęp projektu i nie może być rozwiązany przez kierownika projektu ani też przez zespół projektowy bez pomocy z zewnątrz. 5.0 Zarządzanie zmianą. Zakres jest sposobem na zaprezentowanie etapów projektu. Celem zarządzania zmianą zakresu jest gwarancja, iż sponsor (lub jego desygnowany) wyrazi zgodę na jakiekolwiek zmiany wprowadzane do wstępnej umowy dotyczącej zakresu. 6.0 Zarządzanie komunikacją. Właściwa komunikacja w sprawach projektu jest kluczowym czynnikiem sukcesu w zakresie zarządzania oczekiwaniami klienta oraz interesariuszy. 7.0 Zarządzanie ryzykiem. Ryzyko odnosi się do okoliczności i sytuacji w przyszłości, które zaistnieją w sposób nieoczekiwany, poza wszelką kontrolą zespołu projektowego i które – jeśli się pojawią – będą miały niekorzystny wpływ na projekt. Niektórzy kierownicy projektów podejmują próby rozwiązywania potencjalnych problemów jeszcze przed ich pojawieniem się. 8.0 Zarządzanie zasobami ludzkimi. Ogólnie rzecz biorąc, im większy projekt, tym wymagane większe zasoby ludzkie oraz większa dyscyplina, którą musi wprowadzić kierownik projektu przy naborze, obsadzaniu stanowisk oraz zarządzaniu zespołem projektowym. 9.0 Zarządzanie jakością. Celem etapu zarządzania jakością jest, po pierwsze, zrozumienie aktualnych oczekiwań klienta w zakresie jakości, a następnie wprowadzenie proaktywnego planu w celu spełnienia tych oczekiwań. 10.0 Zarządzanie pomiarami. Badania i pomiary są wykorzystywane do gromadzenia ilościowych danych w procesie podejmowania decyzji, a także są miarodajnym źródłem informacji odnośnie spełniania oczekiwań. 0.0.8.4.P3 Porównanie
29
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Proces The TenStep jest wykorzystywany do zarządzania wszelkiego rodzaju projektami o różnych wielkościach. Jednym z podstawowych „etapów” jest proces zarządzania jakością. Inicjatywy dotyczące jakości można wprowadzić zarówno dla konkretnych projektów, jak również dla całych organizacji. Six Sigma jest filozofią organizacyjną, koncentrującą się w szczególności na jakości, tak więc w tym względzie zazębia się z częścią TenStep. Ogólnie, Six Sigma i Proces Zarządzania Projektem są procesami komplementarnymi. Prowadzenie projektów z uwzględnieniem poziomów jakości Six Sigma wymaga standardowego procesu zarządzania projektem. Proces TenStep spełnia tę potrzebę. Podobnie, jeden z dziesięciu etapów Procesu Zarządzania Projektem TenStep obejmuje zarządzanie w zakresie przyjętego poziomu jakości. Six Sigma może zapewnić ogólny fundament dla tego etapu zarządzania jakością. W związku z tym, firma jest w stanie wprowadzić proces TenStep jako swój ogólny proces zarządzania. Ta sama firma może również zastosować Six Sigma jako swoją ogólną filozofię jakości. W sumie nie ma takiej potrzeby, aby firmy wybierały pomiędzy wprowadzaniem procesu TenStep i Six Sigma. Obie metodyki nie konkurują ze sobą w tych samych obszarach i nie spełniają tych samych podstawowych potrzeb. W zamian za to, firmy mogą wykorzystywać obie metodyki w sposób komplementarny – proces TenStep w celu zarządzania projektem, a Six Sigma jako ogólną filozofię jakości.
30
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.5 Porównanie Procesu TenStep do Agile Software Development 0.0.8.5.P1 W ostatnich latach, opublikowano wiele pomysłów dotyczących sposobów uproszczenia procesu rozwoju oprogramowania, łatwiejszych do implementacji oraz bardziej odpowiadającym potrzebom klienta. Ekstremalne programowanie i nieskomplikowane metodyki, to tylko niektóre przykłady. W dniach 11-13 lutego 2001 r. w Utah doszło do spotkania 17 osób reprezentujących podobne poglądy, w celu wypracowania wspólnych metod rozwoju i projektowania oprogramowania. W wyniku tego spotkania, wydano manifest, obejmujący zbiór zasad i filozofii, które przedstawiono poniżej. Podczas gdy większa część filozofii dotyczy aktualnego procesu rozwoju oprogramowania, kilka punktów porusza kwestię zarządzania projektem. Ogólnie, Proces Zarządzania Projektem TenStep docenia ten proces rozwoju w większości obszarów. W kilku natomiast, istnieje pewna rozbieżność opinii. Poniżej prezentujemy Manifest Agile, wraz z uwagami autora, co do tego, w jaki sposób odnosi się on do procesu TenStep.
Manifest Agile Software Development 17 anarchistów stwierdza: Odkrywamy lepsze sposoby rozwoju oprogramowania poprzez realizację tego przedsięwzięcia oraz pomoc innym w tego typu działaniach. Dzięki temu, zaczynamy bardziej cenić:
Proces Zarządzania Projektem TenStep
i Doświadczenie autora wykazuje, że wiele projektów prowadzonych przez organizację ma większe szanse na Praktyczne oprogramowanie nad pełną osiągnięcie sukcesu przy zastosowaniu dokumentację. elastycznego i skalowalnego zbioru Współpracę z klientami nad negocjacje harmonijnych procesów. Jeśli procesy te były wcześniej z powodzeniem kontraktów. wykorzystywane, istnieje większe Reakcję na zmiany nad przestrzeganie prawdopodobieństwo, że Twój projekt planu. również zakończy się sukcesem. Osoby i interakcje narzędzia.
nad
procesy
Zatem, jeśli doceniamy wartości wymienione po stronie prawej, to i tak pozycjom znajdującym się po stronie lewej będziemy przypisywać większe znaczenie. Przestrzegamy następujących zasad: Naszym
31
najwyższym
priorytetem
jest Filozofia Agile promuje rozwój iteracyjny z
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
satysfakcja klienta poprzez szybką i ciągłą przedstawionymi wcześniej wymogami dostawę wartościowego oprogramowania. oraz z kodeksem pracy. Taka postawa jest do przyjęcia, jednakże należy pamiętać, iż rozwój iteracyjny nie dla wszystkich projektów oprogramowania będzie najbardziej właściwy. Jednak tam, gdzie można go zastosować, należy oczywiście taką opcję wziąć pod uwagę i spróbować. W ramach ogólnego rozwoju iteracyjnego nie ma konieczności wcześniejszego przedstawiania wymogów. Niemniej, nawet przy tradycyjnym rozwoju iteracyjnym, w pewnym momencie należy te wymogi przedłożyć ze względu na konieczność dostawy produktu. W tym momencie ma zastosowanie zarządzanie zmianą zakresu. W Agile wymogi projektowe mogą ulec zmianie w każdej chwili. Zamysł jest następujący: klient ma prawo wprowadzać zmiany pod warunkiem, że wyznaczają one priorytety w odpowiedniej iteracji. Na przykład, jeśli klient poprosi o trzy raporty, a później zażąda czwartego, to ten czwarty raport zostanie dodany do listy wymogów bez żadnego problemu. Na pewnym etapie, Pozytywny stosunek do zmian wymogów, klient będzie musiał nadać nowemu nawet w późnej fazie projektowania. raportowi pierwszeństwo, po czym zostanie Procesy Agile wykorzystują zmianę na sporządzony nowy raport. Jeśli budżet korzyść klienta. klienta jest nieokreślony, wtedy formalny proces zmiany zakresu nie istnieje. Wszelkie wymagania klienta zostaną dostarczone. Jeśli jednak klient dysponuje budżetem ustalonym, wtedy nadanie pierwszeństwa jednej zmianie, będzie w zasadzie oznaczało, iż jakaś inna część pracy nie zostanie wykonana. W tym scenariuszu, klient wymusza zarządzanie zmianą zakresu, poprzez zapewnienie, iż jedynie zmiany, którym przypisuje się najwyższą ważność, uzyskują pierwszeństwo przy implementacji, podczas gdy pozostałe nie. Podejście TensStep zakłada, że gdy zdarzają się zmiany biznesowe, zespół projektowy powinien być przygotowany, aby na nie należycie zareagować. Niemniej, zmiany wymogów niosą konsekwencje budżetowe, a także
32
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zawirowania w zakresie terminów dostaw, wymagając dodatkowo zatwierdzenia przez sponsora. Jeśli zespół projektowy tego dokonuje, to mamy do czynienia z zarządzaniem zmianą zakresu. Proces TenStep zaleca rozbicie dużych projektów na szereg mniejszych, z których każdy mógłby być dostarczony powtórnie i szybko. Nie każdy projekt posiada taką elastyczność, ale jeśli jest taka możliwość, Częsta dostawa roboczego to należy ją stosować do mniejszych oprogramowania, od kilku tygodni do kilku projektów. miesięcy. Preferowany jest jednak krótszy Procesy Agile do minimum zmniejszają termin. czas dostawy. W niektórych projektach w zakresie ekstremalnego programowania cykl dostaw jest bardzo krótki – nawet cotygodniowy. Mimo, iż może to być dość trudne, jeśli chodzi o zarządzanie, nie ma w tym nic złego. Wspólna praca biznesmenów projektantów podczas trwania projektu.
33
i Jest to najlepszy sposób, aby pozostać w kontakcie z potrzebami klienta.
Tworzenie projektu w otoczeniu ludzi pełnych motywacji. Zapewnienie im odpowiedniego środowiska pracy oraz wsparcia, a także zaufania w zakresie wykonania zadania.
Czasami, ludzie o silnej motywacji, mają problemy z dostarczeniem projektu na czas. (Zagadnienie to pół wieku temu rozpoznał Deming). Przywiązują oni bowiem zbyt dużą wagę do szczegółów, zaniedbując tym samym budżet i terminy. Jeśli jednak, ci wysoce zmotywowani pracownicy, zawsze będą realizować na czas swoje zadania, to wzrośnie liczba udanych projektów. Czasem pracowników o silnej motywacji, lepiej umieścić w strukturyzowanym środowisku, co ułatwiłoby im odnoszenie sukcesów. Autor uważa, że najlepszym podejściem jest tworzenie projektów w otoczeniu ludzi o wysokiej motywacji, a następnie zapewnienie tym osobom właściwych narzędzi i procesów w celu należytego wykonania pracy.
Najlepszym i najbardziej sprawnym sposobem przekazywania informacji w ramach zespołu projektowego jest bezpośrednia rozmowa.
Komunikacja międzyludzka jest niewątpliwie najlepszym sposobem kontaktu w wielu okolicznościach. Niemniej jednak, istnieją przypadki, gdzie inne środki komunikacji również z powodzeniem funkcjonują, np. poczta elektroniczna jest
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
jak najbardziej odpowiednia przy rozsyłaniu uaktualnionego statutu dla grupy 20 osób. Należy również sporządzić odnoszącą się do tych uaktualnień statutowych dokumentację – jeśli taka informacja jest konieczna. Dokumentacja jest tworzona jedynie w odniesieniu do ważnych informacji. Rzadko kiedy zresztą zespół projektowy dokonuje uaktualnień dokumentacji, zatem po upływie jakiegoś czasu, traci ona swoją ważność.
Robocze oprogramowanie podstawową miarą postępu.
W rozwoju iteracyjnym zastosowanie roboczego oprogramowania pod koniec każdej iteracji jest swoistą miarą postępu. Jednak nie wszystkie projekty można jest zrealizować wykorzystując rozwój iteracyjny (np. implementacja pakietów). Tak więc w większości projektów można monitorować plan za pomocą głównych etapów, w celu zapewnienia zgodności z harmonogramem.
Rozwój Agile kładzie nacisk na 40godzinny tydzień pracy oraz tempo, które Procesy Agile promują zrównoważony można utrzymać na zrównoważonym i w rozwój. Należy umożliwić sponsorom, miarę niezmiennym poziomie. Oczywiście, projektantom i użytkownikom utrzymanie jest to najlepsze podejście przy stałego tempa tego rozwoju. odpowiednim planowaniu oraz zarządzaniu. Techniczna doskonałość oraz trafne Ciągła uwaga poświęcana doskonałości decyzje dotyczące projektowania są technicznej oraz dobry projekt przyczynia istotnymi czynnikami dla funkcjonowania się do podwyższenia sprawności. procesów Agile. Zatwierdzono. Projektanci oprogramowania i klienci powinni w pierwszej kolejności skoncentrować się na Prostota – sztuka maksymalizacji ilości dostawie głównych wymogów. Powoduje niewykonanej pracy – jest niezbędna. to „maksymalizację niewykonanej pracy”. Pozwala również na sprawniejszą dostawę oprogramowania. Z tym założeniem łatwiej byłoby się zgodzić, przy wysokiej wydajności oraz Najlepsza architektura, wymogi i projekty technicznej przewadze każdego z pojawiają się ze strony zespołów. Niemniej jednak, większość samoorganizujących się zespołów. zespołów projektowych nie wykazuje należytej dojrzałości ani też nie posiada odpowiedniego poziomu umiejętności, 34
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
niezbędnego do przygotowywania najwyższej klasy projektów. Architekturę oprogramowania należy przede wszystkim projektować na poziomie organizacji lub firmy. Jeśli jednak to zadanie zostanie powierzone pojedynczym zespołom, to istnieje prawdopodobieństwo wypracowania zazębiających się technologii i powstania chaosu w firmie.
W regularnych odstępach czasu zespół zastanawia się nad sposobem zwiększenia efektywności, a następnie odpowiednio dostosowuje się do tych wytycznych.
Zatwierdzono. Zespoły powinny w sposób ciągły dążyć do zrozumienia swoich mocnych i słabych stron, a także poszukiwać metod poprawy i zwiększenia efektywności procesów zarządzania projektem. Proces TenStep również zakłada, iż należy wprowadzić w firmie zalecane zmiany, aby pomysły dotyczące ulepszenia procesu pracy miały wpływ na cały personel.
—Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agileAlliance.org
35
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
0.0.8.6 Porównanie TenStep do ISO 10006 TenStep jest zgodny z ISO 10006 0.0.8.6.P1 Międzynarodowa Organizacja ds. Standaryzacji (ISO) jest wyspecjalizowaną agencją międzynarodową, promującą rozwój precyzyjnych standardów, które zapewniają zachowanie zgodności produktów, usług i materiałów w krajach członkowskich. Standaryzacja ułatwia międzynarodową wymianę dóbr i usług, a także pomaga w rozwoju współpracy intelektualnej, naukowej, technicznej i ekonomicznej. Wyniki technicznej pracy ISO zostały opublikowane jako międzynarodowe normy. Jeśli firma takie procesy wdroży, co skutkuje otrzymaniem certyfikatu ISO, to produkty wytworzone w ramach tego procesu, spełnią minimalne standardy wszystkich krajów w danym obszarze odniesienia. Międzynarodowe standardy dla projektów zarządzania zostały zaprezentowane w ISO 10006 i są one bardzo podobne do Kompendium Wiedzy na temat Zarządzania Projektem PMBOK®, wydanego przez Instytut Zarządzania Projektami (chociaż standardy ISO są o wiele mniej obszerne). Dokument ISO 10006 sam w sobie jest opracowany na bardzo wysokim poziomie. Procedury/klauzule zaprezentowane w tabeli poniżej zajmują jedynie 20 stron. Proces Zarządzania Projektem TenStep jest istotnie bardziej obszernym i wyczerpującym temat opracowaniem aniżeli norma ISO 10006. Poniższa tabela prezentuje opis normy ISO i pochodzi z dokumentu standardowego ISO 10006. Ostatnia kolumna tabeli przedstawia, w którym miejscu w Procesie TenStep została opisana każda klauzula. Należy zauważyć, że norma ISO 10006 posiada pewne dodatkowe podklauzule oraz pod-podklauzule, które wprowadzają więcej wytycznych i porad z punktu widzenia organizacji. Niemniej jednak, tabela poniżej przedstawia procesy ISO 10006 ściśle odnoszące się do projektów i pochodzi z Załącznika A – Schemat Procesów w Projektach Normy ISO 10006. (Większość klauzul ISO 10006 na poziomie organizacji, zostało ujętych w Pracy Ramowej z zakresu Zarządzania PortfolioStep (www.PortfolioStep.com) i Pracy Ramowej Biura Zarządzania Projektem PMOStep (www.PMOStep.com)). \ ISO 10006
Klauzula
PodPod podkla klauzula uzula
5 Odpowiedzia 5.2 Proces strategiczn 5.2 lność w y. zakresie zarządzania
36
Proces
Opis Procesu
Proces Zarządzania Projektem TenStep
Proces określający kierunek, który 1.0 Definiowanie obejmuje projektu planowanie i 9.0 Zarządzanie Strategiczny. wprowadzanie jakością (Plan systemu jakości) zarządzania jakością, opartego na zastosowaniu
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zasad zarządzania jakością. 6.1 6 Procesy Zarządzanie 6.1.2 związane z zasobami zasobami.
6.1.3
7 Wykonanie
37
Planowanie zasobów.
1.0 Definiowanie Identyfikacja, ocena, projektu planowanie i 2.0 Tworzenie przydział planu odpowiednich operacyjnego i zasobów. budżetu
Kontrola zasobów.
Porównanie faktycznego wykorzystania w stosunku do 3.0 Zarządzanie planem potrzeb w zakresie zasobów operacyjnym i budżetem i podjęcie odpowiedniego działania w razie konieczności.
6.2 Procesy związane z 6.2.2 personele m.
Ustalenie struktury organizacyjnej Ustalenie projektu na miarę struktury potrzeb projektu, 1.0 Definiowanie projektu organizacyjne wraz z podziałem j projektu. ról, ustaleniem władz i odpowiedzialności .
6.2.3
Obsadzanie stanowisk.
Wybór i wyznaczenie 1.0 Definiowanie personelu o projektu odpowiednich 8.0 Zarządzanie kompetencjach zasobami zgodnie z ludzkimi potrzebami projektu.
6.2.4
Rozwój indywidualnych i Rozwój 1.0 Definiowanie zespołowych zawodowy projektu kompetencji i zespołu 8.0 Zarządzanie zdolności do projektowego zasobami podwyższenia . ludzkimi wyników i efektywności projektu.
7.2.2
Rozpoczęcie Ocena wymagań 1.0 Definiowanie projektu i klienta i innych
7.2 Procesy
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
produktu
związane ze współzależ nością.
opracowanie zainteresowanych planu rozwoju stron, tego projektu. przygotowanie planu zarządzania projektem i wprowadzenie innych procesów.
Zarządzanie interakcją.
3.0 Zarządzanie harmonogramem Zarządzanie i budżetem interakcją podczas projektu. 6.0 Zarządzanie komunikacją
7.2.4
Zarządzanie zmianą.
Przewidywanie i 3.0 Zarządzanie zarządzanie harmonogramem zmianami w i budżetem ramach 5.0 Zarządzanie wszystkich zmianą procesów.
7.2.5
Zamknięcie procesów i projektu.
Zamknięcie procesów oczekiwanie reakcje.
Rozwój koncepcji.
1.0 Definiowanie Określenie projektu zakresu produktu.
7.2.3
7.3 Procesy 7.3.2 związane z zakresem.
7.4 Procesy 38
projektu
3.0 Zarządzanie harmonogramem i i budżetem na (Zakończenie projektu)
7.3.3
Dokumentowanie cech produktu w Opracowanie 10.0 Zarządzanie wymiernych zakresu i pomiarami kategoriach i kontrola. poddawanie ich kontroli.
7.3.4
Ustalenie zadań.
Identyfikacja i dokumentowanie 2.0 Tworzenie zadań i etapów harmonogramu i wymaganych do budżetu osiągnięcia celów projektu.
7.3.5
Kontrola działań.
Kontrolowanie 3.0 Zarządzanie pracy harmonogramem prowadzonej w i budżetem ramach projektu.
7.4.2
Planowanie zależności
Identyfikacja panujących
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
2.0 Tworzenie harmonogramu i
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
związane z terminami.
związanych z stosunków zadaniami. logicznych interakcji zależności zadaniach projektu.
budżetu
oraz w
7.4.3
Ocena czasu trwania każdego zadania w 2.0 Tworzenie Ocena czasu związku z harmonogramu i trwania. określonymi budżetu warunkami i wymaganymi zasobami.
7.4.4
Powiązanie celów projektu związanych z terminami, zależnością od Opracowanie innych zadań oraz 3.0 Zarządzanie planu ich długością jako harmonogramem operacyjnego i budżetem praca ramowa . niezbędna do opracowania ogólnego i szczegółowego harmonogramu.
7.4.5
Kontrola realizacji zadań projektu w celu potwierdzenia Kontrola 3.0 Zarządzanie proponowanego planu harmonogramem harmonogramu operacyjnego i budżetem lub podjęcia . właściwych kroków mających na celu uniknięcie opóźnień.
7.5 Procesy 7.5.2 związane z kosztami.
7.5.3
39
i
Opracowanie Oszacowanie kosztorysu dla kosztów. celów projektu.
2.0 Tworzenie harmonogramu i budżetu
Wykorzystanie 2.0 Tworzenie Budżetowani kosztorysu w celu harmonogramu i e. opracowania budżetu budżetu projektu.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.5.4 7.6 Procesy związane z 7.6.2 komunikacj ą.
7.6.3
7.6.4
7.7 Procesy 7.7.2 związane z ryzykiem.
Kontrola kosztów i 3.0 Zarządzanie harmonogramem odchylenia od i budżetem budżetu projektu.
Planowanie komunikacji.
Planowanie komunikacji i systemów informacyjnych projektu.
Zarządzanie informacją.
Udostępnianie niezbędnych 6.0 Zarządzanie informacji komunikacją członkom projektu oraz stronom zainteresowanym.
Kontrola komunikacji.
Kontrola komunikacji zgodnie z zaplanowanym systemem komunikacji.
6.0 Zarządzanie komunikacją
Identyfikacja ryzyka.
Określenie ryzyka związanego z projektem.
1.0 Definiowanie projektu 7.0 Zarządzanie ryzykiem
1.0 Definiowanie projektu 6.0 Zarządzanie komunikacją
7.7.3
Ocena prawdopodobieńst 1.0 Definiowanie projektu wa wystąpienia Ocena ryzyka ryzyka oraz wpływ 7.0 Zarządzanie ryzykiem takich sytuacji na projekt.
7.7.4
Reakcja na ryzyko.
Opracowanie planów odpowiedzi na ryzyko.
1.0 Definiowanie projektu 7.0 Zarządzanie ryzykiem
Kontrola ryzyka
Wprowadzenie i uaktualnienie planów dotyczących ryzyka.
7.0 Zarządzanie ryzykiem
7.7.5
7.8 Procesy 7.8.2 związane z zakupami.
40
Kontrola kosztów.
Identyfikacja i Planowanie i kontrola terminów 1.0 Definiowanie kontrola i rodzaju projektu zakupów. nabywanych produktów.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Dokumentacj a dotycząca wymogów w zakresie zakupów.
Gromadzenie warunków handlowych i wymogów technicznych.
Ocena dostawcy.
Ocena i wybór dostawców i podwykonawców, 1.0 Definiowanie którzy zostaną projektu zaproszeni do dostarczania produktów.
Przetarg ofert.
Wystosowanie zaproszeń do oferentów, ocena, 1.0 Definiowanie negocjacje, projektu przygotowanie i sporządzenie subkontraktu.
Kontrola kontraktu.
Zapewnienie, że wykonanie pracy przez podwykonawców spełnia wymogi kontraktowe.
3.0 Zarządzanie harmonogramem i budżetem
Poprawa.
Wytyczne na temat sposobu korzystania z projektów przez początkujące organizacje.
9.0 Zarządzanie jakością 10.0 Zarządzanie Pomiarami
8.2
Pomiary i analizy.
Wytyczne na 9.0 Zarządzanie temat pomiarów jakością oraz uprawomocnienia 10.0 Zarządzanie Pomiarami danych w celu ciągłej poprawy.
8.3.1
Ciągłe dokonywanie ulepszeń przez początkujące organizacje.
Kroki, które powinna podjąć organizacja w celu zapewniania ciągłej poprawy procesów projektu.
9.0 Zarządzanie jakością 10.0 Zarządzanie Pomiarami
8.3.2
Ciągłe Informacja, którą ulepszanie w organizacja
9.0 Zarządzanie jakością
7.8.3
7.8.4
7.8.5
7.8.6
8.1 8 Pomiary, Procesy analiza i związane z 8.1 udoskonalen udoskonal ia aniem.
8.2 Pomiary i analizy.
8.3 Ciągła poprawa.
41
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
1.0 Definiowanie projektu
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
organizacji projektu.
projektu powinna 10.0 Zarządzanie Pomiarami dostarczyć początkującej organizacji, w celu umożliwienia ciągłego ulepszania.
Nie ujęto w ISO 10006
4.0 Zarządzanie problemami krytycznymi
Nie ujęto dokładnie w ISO 10006
5.0 Zarządzanie zmianą
Nie ujęto dokładnie w ISO 10006
6.0 Zarządzanie komunikacją
Nie ujęto dokładnie w ISO 10006
9.0 Zarządzanie jakością
Powyższy model jest chroniony prawem autorskim do ISO 2003.
42
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 1 Definiowanie Projektu
43
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0 Definiowanie Projektu 1.0.P1 Prawdopodobnie słyszałeś o projektach, które zakończyły się fiaskiem, nie przyniosły spodziewanych efektów. Być może sam w takim projekcie uczestniczyłeś. Analizując przyczyny niepowodzenia, prawdopodobnie doszedłeś do wniosku, że zabrakło właściwego planowania lub poświęcono na nie za mało uwagi. Krótkie terminy realizacji projektów stają się powodem jak najszybszego rozpoczynania prac. Ale aby właściwie zrealizować projekt należy go zdefiniować i zaplanować. Jako kierownik projektu musisz sprawić, że jest on jednolicie rozumiany. Powinieneś upewnić się, że zarówno zespół projektowy jak i klient podobnie rozumieją jakiego rodzaju efekty ma przynieść, jakie są pożądane przedmioty dostaw, jakie są akceptowalne terminy, koszty oraz jak będzie przebiegać realizacja prac i kto będzie zaangażowany w prace. Czas poświęcony na planowanie i definiowanie projektu nie jest zmarnowany. Szczególnie po zakończeniu trudnego projektu docenisz jego wartość. Ważne czynniki, dla których nie warto rezygnować z definiowania i planowania to:
Zrozumienie
projektu. Cele, przedmioty dostaw (szczególnie kryteria ich odbioru), zakres, ryzyka, koszty itd. są zebrane i precyzyjnie opisane w Definicji Projektu. Daje to pewność, że zarówno zespół jak i sponsor zgadzają się i tak sam rozumieją to co ma być wykonane.
Weryfikacja pierwotnych założeń przedsięwzięcia. Przy wstępnej akceptacji,
szacowanie kosztów i czasu trwania może być obarczone dużym błędem - nawet do ±50%. Jednak w chwili uruchamiania projektu estymacje powinny być poprawione tak, aby mieściły się w granicach błędu do ±10%. Może się okazać, że definiując projekt odkrywasz, że kosztuje on znacznie więcej niż podczas estymacji wstępnych. Przykładowo, projekt wymagający 10 000 godzin pracy może być wstępnie akceptowalny, ale jeśli po szczegółowej analizie wartość ta wzrośnie do 20 000 godzin, realizacja może stracić sens.
Zapewnienie
dostępności zasobów w odpowiednim czasie. Dzięki zrozumieniu projektu i utworzeniu harmonogramu uwzględniającego zasoby można zadbać o to, aby były one dostępne w projekcie w odpowiednim czasie.
Utworzenie
punktów kontrolnych umożliwiających ocenę postępów prac. Dzięki utworzeniu harmonogramu bazowego (i umieszczeniu w nim kamieni milowych) można na bieżąco śledzić, gdzie projekt jest oraz gdzie według tego harmonogramu być powinien.
Walidacja
procesów zarządzania projektem. Procedury powinny zostać poddane dyskusji i przedstawione klientom i członkom zespołu projektowego. Dzięki temu, przed projektem każdy jego uczestnik zna swoją rolę oraz pożądany sposób postępowania. Mniejsze projekty wymagają krótszej fazy planowania, a większe dłuższej. To jak bardzo napracujesz się przy planowaniu i jak dużo czasu zajmie ci ta faza zależy od kilku czynników: od sprawności pozyskania i umiejętności przetwarzania informacji, od ich jakości i ilości, a także od szybkości pozyskiwania niezbędnych zatwierdzeń od klienta. Czasami osiągnięcie porozumienia z klientem w sprawie zakresu, harmonogramu i 44
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
kosztów projektu jest bardzo trudne. Dlatego, aby uniknąć nieporozumień w przyszłości, czynności te wykonuje się z wyprzedzeniem. 1.0.P2 Przed rozpoczęciem projektu Przed rozpoczęciem projektu (fazy: analiza, konstruowanie, testowanie etc.) powinno się zadbać o kilka spraw:
Uzyskanie
zgody Klienta na rozpoczęcie procesu planowania projektu. Zwykle z góry zakłada się, że Klient zgodzi się na planowanie pracy, gdyż jest zainteresowany projektem. Jednak w sytuacji, gdy projekt nie był poprzedzony wstępną analizą biznesową i w jej wyniku nie został zatwierdzony do dalszego rozpracowywania, uruchomienie definiowania projektu powinno być poprzedzone uzyskaniem formalnej zgody.
Formalne
zdefiniowanie projektu. W TenStep wykonuje się to stosując dokument Definicja Projektu, który obejmuje: cele, zakres, założenia, przedmioty dostaw, budżet, itp. (W przypadku średnich lub małych projektów taką rolę może pełnić Skrócona Definicja Projektu (Abbreviated Project Charter) lub Zlecenie Usługi (Service Request)).
Utworzenie harmonogramu prac. Harmonogram jest niezbędny do zarządzania pracą w projekcie. Zawiera punkty kontrolne lub kamienie milowe, które pozwalają ocenić, czy prowadzone prace idą we właściwym kierunku i mogą być kontynuowane.
Uzyskanie zgody Klienta na rozpoczęcie prac projektowych. Klient, składając podpis pod dokumentem definiującym projekt, w sposób formalny potwierdza wyrażenie zgody na rozpoczęcie prac. Dokument musi być podpisany także przez sponsora.
Ustalenie i zatwierdzenie procedur zarządzania projektem. Procedury opisują sposób, w jaki kierownik projektu zamierza zarządzać komunikacją, ryzykiem, jakością, zakresem, itd. Są niezbędne dla dużych projektów, mniej istotne w przypadku mniejszych projektów.
Pozyskanie
zasobów do zespołu projektowego. Aby zrealizować projekt musisz dysponować odpowiednimi ludźmi. Czasami już zatwierdzone do realizacji projekty ulegają opóźnieniu z powodu braku ludzi o odpowiednich kwalifikacjach.
1.0.P3 Zrozumienie projektów Zanim dowiesz się, jak definiować projekt, powinieneś wiedzieć co to jest „projekt‟. Znajomość definicji tego pojęcia ułatwi ci określenie, którą z technik zarządzania projektem należy zastosować. Procedury zarządzania projektem muszą być dostosowane do wielkości projektu. Pamiętaj, że duże projekty wymagają większej dyscypliny i formalizacji niż mniejsze. Zapoznaj się z rozdziałami:
1.0.1 Co to jest projekt? 1.0.1.1 Daty rozpoczęcia i zakończenia projektu 45
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.2 Zarządzanie projektem a cykl życia projektu 1.0.3 Zarządzanie projektem a zarządzanie produktem 1.0.4 Rola kierownika projektu 1.0.P4 Klasyfikowanie projektów (małe, średnie, duże) Procedury zarządzania projektami TenStep zawierają szczegółowe wytyczne postępowania w zależności od wielkości przedsięwzięcia. Dlatego zacznij od kategoryzacji swojego projektu. W niektórych firmach projekt 6-cio miesięczny wymagający nakładu 10,000 godzin będzie uważany za duży. W innych organizacjach ten sam projekt uznany zostanie za mały. TenStep rekomenduje pewne wskazówki odnośnie skalowania projektów, jednak każda organizacja powinna zdefiniować własne rozsądne kryteria. 1.0.P5 Klasyfikowanie twojego projektu ze względu na wielkość (mały, średni, duży) Po zebraniu informacji dotyczących twojego projektu ustal które techniki będziesz stosować. Może zdarzyć się tak, że mały projekt będzie realizowany przy użyciu technik przeznaczonych dla dużego, np. ze względu na jego krytyczne znaczenie dla organizacji. Z drugiej strony, duży projekt może być zarządzany nieformalnie tak, jak mały np. z uwagi na jego prostotę i niewielkie znaczenie dla całej organizacji. 1.1 Definiowanie Projektu/ Proces 1.2 Definiowanie Projektu/ Techniki 1.3 Definiowanie Projektu/ Podsumowanie
46
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.1 Co to jest projekt?
1.0.1.P1 Zanim zostaniesz dobrym kierownikiem projektu musisz się upewnić, że praca jakiej się podjąłeś, jest faktycznie projektem. Niektórzy twierdzą, że w pewnym sensie każdy rodzaj pracy to projekt. Jednak nie do końca jest to prawdą. W rzeczywistości w nauce o zarządzaniu wyróżnia się wiele rodzajów prac: wspierające, operacyjne, zarządcze, projektowe, itd.
wspierające
(support) wiążą się z wspieraniem już stosowanych rozwiązań. Przykładowo, w branży komputerowej, prace wspierające mogą wiązać się z udzielaniem odpowiedzi na pytania, uczestniczeniem w regularnych spotkaniach, rozwiązywaniem problemów powstających w systemach produkcyjnych, itd. W branży handlowej wsparcie może oznaczać odpowiadanie na pytania klientów, modyfikowanie istniejących kontraktów, poprawianie błędnych faktur, itd.
Prace operacyjne to rutynowe zadania wykonywane podczas realizacji procesów biznesowych. Dla osoby prowadzącej księgowość może to oznaczać sprawdzanie raportów, bilans rachunków, zamykanie okresów rozliczeniowych, itd.
Prace zarządcze są niezbędne w przypadku zarządzania i kierowania ludźmi i procesami biznesowymi. Cechą charakterystyczną wszystkich wymienionych powyżej rodzajów prac jest to, że obejmują one rutynowe czynności ciągłe i wynikają z zakresu obowiązków służbowych pracowników (oraz z tzw. procesów biznesowych). Są to prace wykonywane dziś, jutro, za miesiąc, i zawsze. Projekty nie są częścią codziennej rutyny. Cechą charakterystyczną ich jest to, że posiadają datę rozpoczęcia i zakończenia. W zależności od kultury organizacyjnej firmy i stosowanych standardów, wydarzenia rozpoczynające i kończące projekt mogą być różne. Więcej informacji znajdziesz w rozdziale 1.0.1.1. Inne cechy charakterystyczne projektu to:
Unikalność. Projekty mogą być podobne do wcześniej zrealizowanych, ale pod względem ram czasowych, zasobów, aktualnego otoczenia biznesowego, itd., każdy projekt jest inny. Z tej właśnie cechy projektów wynika konieczność ich definiowania.
W wyniku realizacji projektu powstaje jeden lub więcej przedmiotów dostaw. Projekty mają przydzielane zasoby – ludzie, pieniądze, narzędzia, maszyny etc. Projekty posiadają zdefiniowany zakres pracy. Projekty mogą mieć różny czas trwania: dwudziestogodzinne, 100 lub 100 000godzinne. Dlatego, mimo iż wytworzenie małego przedmiotu dostawy jest projektem, to nie wymaga takiej formalizacji jak w przypadku większych projektów. Jeśli masz do czynienia z projektem 10-godzinnym - po prostu go wykonujesz. Całe planowanie, analiza i struktura – istnieją w twojej głowie. Projekty 50-godzinne w większości również są po prostu „robione”. Chociaż może tutaj wystąpić niewielkie planowanie, jakieś komunikowanie i rozwiązywanie problemów. W projekcie 200-godzinnym prawdopodobnie wystąpi zbyt dużo pracy, aby móc planować „w głowie”. Być może 47
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
będziesz musiał tutaj zdefiniować projekt i zbudować prosty harmonogram. Projekt 5 000-godzinny wymaga już strukturalizowanego i sformalizowanego zarządzania. Zaś projekt 100 000-godzinny jest zbyt duży i wymaga zbyt dużo pracy, aby można go traktować jako jeden spójny projekt. Dlatego należy podzielić go na mniejsze powiązane ze sobą podprojekty. Kryteria stosowane do klasyfikowania projektów przedstawiono w rozdziale 1.0.1.2 Klasyfikowanie projektów (małe, średnie, duże). Pamiętaj, że są to tylko wytyczne, które muszą zostać zweryfikowane i przystosowane do kultury twojej organizacji. Zanim uruchomisz procedury zarządzania projektem TenStep, upewnij się, że praca, którą masz do wykonania jest projektem, i że przyjęty stopień strukturalizowania i sformalizowania jest adekwatny do wielkości projektu.
48
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.1.1 Daty rozpoczęcia
i zakończenia projektu 1.0.1.1.P1 Jedną z cech charakterystycznych projektu jest to, że posiada datę rozpoczęcia i zakończenia. Sposób zdefiniowania tych dat może być różny w różnych organizacjach. Poniżej przedstawiono kilka propozycji zdefiniowania daty rozpoczęcia projektu.
Powstanie pomysłu. Takie podejście znacznie cofa datę rozpoczęcia do czasu
przed sformalizowaniem projektu. Na pierwszy rzut oka wydaje się mało sensowne. Jeśli w twojej firmie mierzy się czas od powstania pomysłu do jego realizacji, przyjęcie tej definicji początku projektu może ułatwić skracanie tego okresu. Etap definiowania pomysłu podlegając reżimowi TenStep stanie się kontrolowany oraz będzie można nim zarządzać.
Zatwierdzenie budżetu.
Takie zdefiniowanie jest nieco bardziej konkretne od poprzedniego. Zakładamy, że pomysł już powstał i jest w tak zaawansowanym stadium, że przeanalizowano i określono również koszty oraz korzyści biznesowe. Projekt został także poddany procesowi priorytetyzacji i został przyjęty rzeczywisty budżet. Pamiętaj, że budżet mógł zostać zatwierdzony w poprzednim okresie planistycznym, a jego realizacja jest możliwa dopiero teraz. W tym okresie wiele mogło się zmienić. Dlatego takie zdefiniowanie czasu rozpoczęcia w wielu organizacjach może okazać się zbyt wczesne.
Wyznaczenie
kierownika projektu. Takie podejście jest częściej spotykane. Trudno założyć rozpoczęcie projektu przed wyznaczeniem jego kierownika. Planowanie i definiowanie projektu, a następnie realizacja prac projektowych jest głównym zadaniem kierownika projektu. Zarządzanie projektem, w którego definiowaniu nie brało się udziału jest niebywale trudne. Może powodować chaos i konflikty. Dlatego niniejsza definicja daty rozpoczęcia projektu, równoznaczna z wyznaczeniem kierownika projektu, jest rekomendowana w metodyce TenStep.
Zatwierdzenie przez sponsora Definicji Projektu. W niektórych organizacjach oficjalne uruchomienie projektu następuje, gdy utworzono definicję projektu i plan, uzyskano akceptację tych dokumentów przez Klienta. Dopiero wtedy Sponsor wydaje zgodę na rozpoczęcie prac projektowych, w których jednym z pierwszych zadań jest skompletowanie zespołu projektowego.
Zainicjowanie
spotkania otwierającego projekt - kickoff meeting. W tym przypadku prace związane z planowaniem i definiowaniem traktowane są jako zadania „przed-projektowe” i muszą się zakończyć przed zorganizowaniem spotkania otwierającego – kickoff meeting. Przed kickoff meeting klient musi zatwierdzić uruchomienie projektu a zespół projektowy musi zostać skompletowany. Z powodu konieczności wcześniejszego wykonania omówionych prac, większość organizacji uważa kickoff meeting za termin zbyt późny.
1.0.1.1.P2 Dlaczego data rozpoczęcia jest tak istotna? Możesz się zastanawiać, czy data rozpoczęcia projektu ma jakiekolwiek znaczenie. Jeśli w twojej organizacji nic się nie dzieje, jeśli przedsięwzięcia są uznawane za projekty, faktycznie, data ta nie ma znaczenia. Brak zdefiniowania daty rozpoczęcia nie oznacza 49
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
przecież, że przedsięwzięcie przestaje być projektem. Jest oczywiste, że projekt został rozpoczęty w konkretnym momencie. Istnieje taki punkt na osi czasu, kiedy projekt nie był realizowany oraz taki, gdy był w trakcie realizacji. W związku z tym w pewnym momencie projekt faktycznie się „rozpoczął”. Stwierdzenie, że projekt jest rozpoczęty najczęściej wiąże się z następującymi kwestiami:
Odpowiedzialność
zespołu projektowego. Trudno jest obarczać ludzi odpowiedzialnością za zadania, nad którymi nie mają pełnej kontroli. Dlatego kierownik projektu powinien ponosić odpowiedzialność za projekt dopiero od momentu, kiedy został wyznaczony do pełnienia tej roli – wcześniejsze prace i decyzje nie były przez niego kontrolowane. Podobnie jest z odpowiedzialnością zespołu projektowego. Z tego powodu rozpoczęcie projektu powinno być jednoznaczne z wyznaczeniem kierownika projektu. Członkowie zespołu zaś powinni być odpowiedzialni za wszystko, co wydarzy się po zatwierdzeniu Definicji Projektu i harmonogramu lub po kickoff meeting.
Usprawnienie
procesu. Wiele firm śledzi na bieżąco całkowity czas trwania projektów i próbuje go stopniowo skracać. Ważne jest, aby w całej firmie daty rozpoczęcia i zakończenia projektów były tak samo zdefiniowane. W przeciwnym przypadku prowadzone statystyki nie będą miały większego sensu.
Finanse / Księgowość. Praca przy projekcie – szczególnie inwestycyjnym może
być księgowana dwojako. Po pierwsze, jako koszt bieżący lub po drugie, jako składowa nakładu inwestycyjnego. Przykład: budując halę fabryczną wytwarzasz środek trwały. Jego wartość tworzą koszty materiałów oraz koszty pracy przy jego wytworzeniu. Dlatego pracę można uznać za koszt prosty lub za nakład inwestycyjny, podlegający późniejszej amortyzacji. Zatem ze względów finansowych nie jest obojętne kiedy projekt się rozpoczął.
Porównanie
z innymi firmami. Jeśli chcesz porównać szybkość realizacji projektów w twojej firmie z innymi, upewnij się, że daty rozpoczęcia i zakończenia są tak samo rozumiane. Jeśli w twojej firmie projekt uznaje się za rozpoczęty z chwilą wyznaczenia kierownika, a w innej – po kickoff meeting, może to sugerować błędnie, że realizacja w twojej firmie trwa dłużej.
1.0.1.1.P3 Daty zakończenia projektu Podobnie jak przy definiowaniu daty rozpoczęcia, również data zakończenia może być rozumiana w różny sposób. Poniżej przedstawiono dwa często występujące podejścia. Po pierwsze, oficjalne zakończenie projektu może być związane z organizacją spotkania zamykającego. Ale kiedy organizować to spotkanie? Gdy pozytywnie zakończono odbiór wszystkich przedmiotów dostaw? A może 30 dni po zakończeniu wszystkich zadań zapisanych w harmonogramie? A może po zakończeniu rozliczeń i napisaniu podsumowania projektu? Drugie podejście jest takie, że projekt kończy się z chwilą wyczerpania pieniędzy. W przypadku wielu projektów taka definicja nie ma sensu. Jednak zakończenie projektu w momencie wyczerpania środków jest niemal nieuniknione. Taka definicja nie daje także odpowiedzi na podstawowe pytanie, jak określić koniec projektu. Najczęściej następujące zdarzenia mogą stanowić o zakończeniu projektu:
50
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Zatwierdzenie. Z pewnością najwcześniejszą z możliwych datą zakończenia jest
formalne zatwierdzenie przedmiotów dostaw przez sponsora. Takie podejście stosowane jest w prawie wszystkich projektach. Przedmioty dostaw wytwarzane są na czyjeś zlecenie. Logiczne jest, że projekt nie zostanie ukończony zanim zlecający nie będzie usatysfakcjonowany. Może okazać się, że po przekazaniu przedmiotów dostawy do odbioru, konieczne będzie wykonanie jakichś poprawek. Projekt więc nie zakończy się. Zostanie on uznany za zakończony dopiero, gdy przedmioty dostaw zostaną odebrane ostatecznie. Możliwe jest zakończenie projektu również w przypadku, gdy końcowe przedmioty dostaw zostały odrzucone i nie planuje się dalszych prac.
Implementacja. Efektem wielu projektów jest wdrożenie produktu lub usługi. W
ten sposób realizowane są projekty IT, modyfikacje linii technologicznych, przygotowanie organizacji do sprzedaży nowego produktu etc. Zazwyczaj przed wdrożeniem nowej usługi, w całej organizacji, wymagane jest zatwierdzenie sponsora. Implementacja następuje później. Może być pojedynczym zdarzeniem lub serią powiązanych podprojektów. W tego typu przedsięwzięciach projekt nie kończy się z chwilą akceptacji sponsora (jak opisano w punkcie powyżej), ale po zakończeniu całego wdrożenia.
Przekazanie
przedmiotu dostawy do działu wsparcia. W wyniku projektu dostarczasz nowe rozwiązanie (np. system IT), które budujesz od etapu analizy i konstruowania, przez wszystkie fazy cyklu życia. Wtedy najczęściej przedsięwzięcie kończy się gdy rozwiązanie (system IT) przejmuje dział, który będzie zajmował się serwisowaniem i utrzymywaniem tego rozwiązania. A jeśli rozwiązanie będzie utrzymywane przez twój dział, projekt powinien zakończyć się, gdy nowy właściciel procesu biznesowego zaraportuje gotowość do pełnej eksploatacji oraz utrzymania przedmiotu dostawy.
Implementacja z jednym cyklem produkcyjnym. Jeśli projekt buduje system,
urządzenie, procedurę, które mają wytwarzać jakiś inny produkt finalny, wtedy często projekt uznaje się za zakończony, gdy przetestowano pozytywnie jego działania „na żywym organizmie”. Przykładowo, jeśli w wyniku projektu powstaje system wspomagający comiesięczne rozliczenia, projekt kończy się po pierwszym prawidłowym wykonaniu raportu przez nowe oprogramowanie. Członkowie zespołu projektowego najlepiej znają program, potrafią najszybciej zareagować w przypadku pierwszych problemów. Mogą ewentualnie na bieżąco wprowadzać jakieś korekty do budowanego oprogramowania.
Wyznaczenie daty zakończenia projektu nie zawsze jest proste. Data powinna być uzgodniona i zatwierdzona przez głównych interesariuszy przed rozpoczęciem projektu. Takie porozumienie pozwoli uniknąć sytuacji, w której ogłaszasz zwycięstwo, by zaraz po tym odkryć, że według innych wciąż masz przed sobą wiele pracy.
51
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.1.2 Klasyfikowanie projektów (małe, średnie, duże)
1.0.1.2.P1 Procesy zarządzania projektami TenStep dostosowane są do wielkości projektów. Każda organizacja, która stosuje procedury TenStep musi sama dookreślić kryteria do klasyfikacji projektu ze względu na ich wielkość. TenStep przyjmuje trzy podstawowe kryteria: 1) Pierwszym kryterium jest szacunkowa pracochłonność. Ogólne wytyczne TenStep są następujące:
Wielkość
Pracochłonność
Mały
1-250 godzin
Średni
251 – 5000 godzin
Duży
ponad 5000 godzin
W twojej firmie wartość te dla poszczególnych klas mogą być inne. Ważne jest to, że im większy projekt, tym większa strukturalizacja i formalizacja procedur zarządzania nim. 2) Drugim czynnikiem jest poziom doświadczenia kierownika projektu. Jeśli kierownik projektu posiada duże doświadczenie, można zlecić mu kierowanie dużymi projektami bez ścisłego nadzoru lub projektami o większej pracochłonności. Z drugiej strony niedoświadczonemu kierownikowi można powierzyć kierowanie projektem o pracochłonności 2.000 godzin w sposób przewidziany dla dużego projektu, ponieważ jego wykonanie będzie wymagało dodatkowego wsparcia i kontroli. 3) Trzecim czynnikiem jest złożoność oraz znaczenie biznesowe projektu. Na przykład projekt o pracochłonności 1.000 godzin i kluczowym znaczeniu biznesowym może być zarządzany jak duży projekt. A projekt trwający 5.000 godzin może być zarządzany jak mały projekt, jeśli zarządzałeś wcześniej dwoma projektami podobnej wielkości i z doświadczenia wynika, że jest to łatwy projekt niskiego ryzyka. Powyższe sposoby klasyfikacji zostały uzależnione głównie od pracochłonności i nazwane małymi, średnimi i dużymi, gdyż jest to intuicyjne, łatwe do zrozumienia i wytłumaczenia. Jednak de facto przymiotnik mały, średni, duży odnosi się do poziomu kontroli, jaki organizacja chce mieć nad realizacją projektu. Jeśli projekt jest ważny, strategiczny i ryzykowny organizacją będzie zarządzać nim jak dużym, niezależnie od tego jaka będzie pracochłonność. Jeśli projekt będzie pracochłonny, ale łatwy, znany – organizacja może stosować do zarządzania nim techniki mniej formalne (nazywane potocznie procedurami dla małych projektów).
52
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.2 Zarządzanie projektem a cykl życia projektu 1.0.2.P1 Jaka jest różnica pomiędzy zarządzaniem projektem i cyklem życia projektu? Polega na tym że, zarządzanie projektem to czynności związane z definiowaniem, planowaniem, kontrolowaniem, monitorowaniem i zamknięciem projektu. Cykl życia – to praca związana z wytwarzaniem przedmiotów dostawy. Tworzenie harmonogramu zakwalifikujemy jako czynności należące do zarządzania projektem. Ale większość zadań przewidzianych w nim jest pracą związaną z wytwarzaniem przedmiotów dostaw projektu. Należy ona do „cyklu życia”. Projekty mogą być zarządzane przy pomocy podobnych lub takich procedur zarządzania projektami, niezależnie od tego co projekt wytwarza. We wszystkich powinno wystąpić definiowanie i planowanie, zarządzanie zakresem, ryzykiem, jakością etc. TenStep precyzuje najoszczędniejszy zbiór działań, jakie należy podjąć by tymi obszarami zarządzać. Unikatowość projektu związana jest z tym, że każdy projekt wytwarza inne przedmioty dostawy, a co za tym idzie jego cykl życia jest inny. Na przykład budowa mostu jest zupełnie inna niż wytwarzanie rozwiązań IT, czy tworzenie nowego produktu. Pomimo, że projekty są niepowtarzalne, podejście do wytworzenia przedmiotów dostawy może być podobne, składać się z analogicznych faz. Dlatego mówi się o tzw. modelu cyklu życia projektu. Na przykład model „wodospadu” – najpierw skupiasz się na zrozumieniu wymagań, potem projektujesz rozwiązania, następnie tworzysz je i testujesz, a na końcu wdrażasz. Każdy z wymienionych obszarów nazywany jest fazą (faza analizowania, faza projektowania, faza budowania, etc).Czy może być coś prostszego? Gdybyś nie wiedział nic o metodykach zarządzania projektami i budował plan projektu od tzw. czystej kartki, prawdopodobnie intuicyjnie ułożyłbyś zadania w modelu wodospadu! Proces zarządzania projektem TenStep Analiza
Projektowanie
Produkcja
Testowanie
Wdrożenie
Cykl życia
Realizując nawet mały projekt, przechodzisz przez te etapy. Niektóre z nich mogą być zrealizowane, jako chwila spokojnego namysłu. Może się wydawać, że przy 40-godzinnym projekcie można pominąć fazę analizy i projektowania, od razu przejść to fazy realizacji (produkcji). Ale czy rzeczywiście? Bardziej prawdopodobne jest to, że w Zleceniu na podstawie którego wykonujesz projekt będzie już opisana pożądana praca (czyli ktoś wcześniej przeprowadził analizę i zebrał wymagania). Dlatego twoim kolejnym krokiem będzie jedynie przemyślenie i ułożenie sobie w głowie planu działania (design). W ten sposób rzeczywiście przechodzisz do realizacji (produkcja) fazy testowania (test) oraz wdrożenia (implement). Istnieją wiele inne modele cyklu życia niż klasyczny model wodospadu. Chociaż może on być stosowany we wszystkich projektach, inne mogą okazać się bardziej skuteczne i efektywne, gdyż opracowuje się je dla danego typu projektów. Na przykład
53
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
znane są specyficzne modele cyklu życia wytwarzania przedmiotów dostawy w IT, modele dla działów badawczo rozwojowych etc.
1.0.3 Zarządzanie projektem a zarządzanie produktem 1.0.3.P1 Projekty a produkty Produkty są czymś namacalnym co wytwarza organizacja w wyniku swojego działania. Dzielimy je na towary i usługi. Produkty powstają najczęściej w wyniku pracy zorganizowanej procesowo. Dotyczy to szczególnie produktów wytwarzanych masowo. Zdarzają się także produkty =budowane poprzez projekt. Najczęściej na jednostkowe zamówienie klienta. Osoba odpowiedzialna za analizę jakie produkty są atrakcyjne dla klientów, opłacalne dla organizacji, zajmująca się koordynacją procesu projektowania produktu, jego wytwarzania i sprzedaży nazywana jest kierownikiem produktu. Rola kierownika produktu jest różna w zależności od tego, w jakiej fazie cyklu życia produkt się znajduje. Poniżej wymieniono niektóre jego odpowiedzialności dla produktu tworzonego na potrzeby wewnętrzne i sprzedażowe. Inicjacja
Identyfikacja i sprecyzowanie pomysłu, aby mógł być poddany dalszej analizie. Określenie możliwości wykorzystania produktu. Analiza biznesowa Sprawdzenie, stosując standardową procedurę planowania rozwoju nowego produktu, obowiązującą w organizacji, czy opłaci się realizacja pomysłu. Projekt W momencie uruchomienia projektu budowania produktu, zarządzanie projektem i produktem mogą się pokrywać, szczególnie gdy kierownik produktu pełni rolę kierownika projektu. Nie jest to korzystna sytuacja z praktycznego punktu widzenia. Częściej spotykanym rozwiązaniem jest rozdzielenie ról. Kierownik projektu odpowiedzialny za sprawy planowania pracy i egzekwowania jej realizacji (zarządzanie projektem). Kierownik produktu odpowiada za sprawy merytoryczne:
testowanie nowych produktów i ich kolejnych wersji, pilotaż produktu. określenie, na podstawie testów i wstępnych projektów, gotowości produkcyjnej. rozwój produktu, jego nowych wersji. Utrzymanie i wsparcie
54
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Tutaj rozpoczyna się długoterminowe zarządzanie produktem. Uzyskanie środków na sfinansowanie pracy, podobnie jak wytworzenie produktu może potrwać kilka miesięcy. Faza rozwijania produktu i jego doskonalenia może trwać przez kilka następnych lat. Wspieraniem i rozwijaniem produktu może zajmować się kierownik produktu, ale bardziej prawdopodobne jest zaangażowanie wyznaczonej do tego celu odrębnej komórki.
Pełnienie
funkcji pierwszego „styku” koordynacyjnego i komunikacyjnego dla sprzedawców produktu.
Monitorowanie wskaźników sprzedaży. Śledzenie dystrybucji produktu. Przyjmowania od personelu zamówień na wersje dedykowane produktu. Integrowanie i dodawanie nowych wersji produktów (sprzedaż produktów) Zarządzanie finansami
Koordynowanie
negocjacji dotyczących kontraktów, umów zakupowych, umów
serwisowych.
Zapewnienie budżetu dla utrzymania produktu. Określanie procedur anulowania lub redukcji kosztów utrzymania w zależności od tendencji sprzedażowych produktu.
Zarządzanie wprowadzaniem produktu na rynek
Koordynowanie
procesu certyfikacji nowych wersji produktu (na potrzeby sprzedażowe i wewnętrzne).
Planowanie
i zarządzanie wdrożeniem nowych wersji produktu (na potrzeby sprzedażowe i wewnętrzne).
Wycofanie produktu
Określenie, kiedy produkt powinien być wycofany z rynku. Planowanie i zarządzanie wycofaniem produktu z rynku. Wycofanie (wyłączenie) produktu z rynku.
55
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.4. Rola kierownika projektu
1.0.4.P1 Nowy pracownik w kancelarii przedsiębiorstwa zauważył starszego mężczyznę siedzącego w rogu i sortującego pocztę, ważącego paczki, przyklejającego znaczki i wykonującego inne proste prace. Zapytał kierownika: „kim jest ten mężczyzna?”, a kierownik odpowiedział: „To Joe. Pracuje w firmie od 35 lat i wkrótce odejdzie na emeryturę”. „Naprawdę?” - spytał nowy - „I cały czas pracował w kancelarii?” „Nie, odszedł parę lat temu, ale po kilku latach pracy jako kierownik projektu poprosił o przeniesienie z powrotem.” Na pierwszy rzut oka wydaje się, że zdefiniowanie roli kierownika projektu jest bardzo łatwe. I w teorii prawdopodobnie jest. Problem polega na tym, że zakres uprawnień i odpowiedzialności może się różnić zależnie od przedsiębiorstwa. Metodyka TenStep określa ogólnie obowiązki kierownika projektu, dlatego jest konieczne zdefiniowanie tej roli w twojej organizacji w sposób maksymalnie precyzyjny. 1.0.4.P2 Definicja ogólna Kierownik projektu (w niektórych firmach nazywany koordynatorem projektu, liderem zespołu projektowego) to osoba, która odpowiada za zarządzanie projektem w sposób gwarantujący osiągnięcie sukcesu. 1.0.4.P3 Odpowiedzialność za zarządzania projektem Co to znaczy, że kierownik odpowiada za zarządzanie projektem w sposób gwarantujący osiągnięcie sukcesu? Postępując zgodnie z TenStep, najpierw musisz zdefiniować projekt i zbudować plan operacyjny oraz określić budżet. Tu rozpoczyna się twoja odpowiedzialność jako kierownika projektu. Jeśli projekt ruszył i okazało się, że zakres jest niedookreślony, jesteś za to odpowiedzialny. Jeśli projekt jest prowadzony według harmonogramu, który jest nieadekwatny, nieaktualny, niedookreślony - odpowiadasz za to jako kierownik projektu. Zdefiniowanie projektu oznacza, że wszyscy zainteresowani (kierownik, zespół, sponsor, interesariusze) jednoznacznie rozumieją cele projektu, jego zakres, ryzyka, podejście realizacyjne, budżet, etc. To, że kierownik odpowiada za zarządzanie projektem w sposób gwarantujący sukces nie oznacza, że całą pracę musi wykonać osobiście. Do tworzenia Definicji Projektu (Project Charter) i harmonogramu może być zaangażowany cały zespół. Jednak odpowiedzialność za efekt tych prac ponosi kierownik projektu. Po rozpoczęciu projektu zadaniem zarządzanie i kontrolowanie pracy, w tym:
kierownika
Zarządzanie
projektu
jest
skuteczne
harmonogramem w celu uzyskania pewności, że praca została przydzielona do realizacji i wykonana z zachowaniem ustalonego terminu, budżetu oraz na adekwatnym poziomie jakości.
56
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Identyfikowanie,
śledzenie,
zarządzanie
i
rozwiązywanie
problemów
krytycznych.
Proaktywne
zarządzanie zakresem - wykonane mają być tylko uzgodnione przedmioty dostaw, chyba że w ramach zarządzania zakresem zatwierdzono zmiany.
Proaktywne informowanie o projekcie wszystkich interesariuszy. Identyfikowanie, analizowanie i minimalizowanie ryzyk projektowych. Zapewnienie, że wszystkie przedmioty dostawy zostaną wykonane
na
uzgodnionym poziomie jakości.
Definiowanie i zbieranie miar projektowych, w celu udokumentowania postępu
prac oraz zapewnienia, że wytwarzane przedmioty dostaw są akceptowalne. Ponownie należy tu podkreślić, że kierownik projektu nie wykonuje fizycznie całej pracy, ale w jego gestii leży dopilnowanie wszystkiego. Dlatego Osoba zarządzająca projektem powinna być dobrze zorganizowana i zorientowana na proces, posiadać umiejętności: wytyczania celów i ich realizacji, prowadzenia jednocześnie wielu zadań, logicznego myślenia, umieć określać przyczyny problemów, szacować budżet i zarządzać nim oraz cechować się wysoką samodyscypliną. 1.0.4.P4 Odpowiedzialność za zarządzanie ludźmi Poza umiejętnościami „procesowymi” kierownik projektu powinien umiejętnie zarządzać ludźmi. Umiejętności przydatne w tym zakresie:
Dyscyplinowanie
pracowników i organizowanie ich pracy w celu uzyskania pewności, że wszyscy stosują się do przyjętych standardów i procedur.
Kierowanie
członkami zespołu tak, aby postępowali oni wg wytycznych, przekazanie wizji efektów projektu w taki sposób, aby zespół ją zaakceptował i dołożył starań do jej wykonania.
Wyznaczanie rozsądnych, ambitnych i jasnych oczekiwań względem ludzi oraz egzekwowanie ich wypełnienie. Dotyczy to również dostarczania informacji zwrotnej członkom zespołu projektowego.
Budowanie zmotywowanego zespołu, który będzie pracował na rzecz projektu i
innych członków zespołu. Im większy zespół i projekt, tym umiejętność budowania zespołu jest ważniejsza.
Proaktywne
komunikowanie w mowie i piśmie oraz umiejętność aktywnego
słuchania.
Powtórzmy znowu: to kierownik projektu jest odpowiedzialny za zarządzanie projektem gwarantujące osiągnięcie sukcesu. Jeśli zespół ma słabe morale i nie dotrzymuje terminów, ty jako kierownik projektu, powinieneś rozwiązać ten problem. Jeśli członkowie zespołu nie rozumieją dokładnie co i kiedy powinni robić, to ty - jako kierownik projektu - jesteś za to odpowiedzialny, powinieneś im w tym pomóc.
57
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.0.4.P5 Pełnienie wielu ról Zależnie od wielkości i złożoności projektu, kierownik oprócz zarządzania projektem może dodatkowo przyjąć na siebie inne obowiązki. Na przykład może zająć się zbieraniem informacji niezbędnych do określenia potrzeb i wymagań biznesowych. Kierownik projektu może na przykład poświęcać na zarządzanie projektem 45% swojego czasu, na analizy biznesowe 25% czasu, a na prace planistyczne 15% czasu i na sporządzanie dokumentacji 15% czasu. Nie oznacza to, że do obowiązków kierownika należy praca analityczna czy sporządzanie dokumentacji. Raczej, że projekt nie jest aż tak duży, aby wymagał pełnoetatowego zaangażowania kierownika projektu. W pozostałej części etatu kierownik projektu może pełnić inne role - analityk biznesowy, projektant etc. Zależnie od wielkości projektu oraz kultury organizacyjnej, kierownik projektu może pracować w jednym z trzech modeli:
Cały etat poświęca na zarządzanie projektem (dotyczy dużych przedsięwzięć). Zarządza wieloma małymi / średnimi projektami - w każdym jest kierownikiem projektu co daje pełny etat.
Łączy różne role w tym samym projekcie (jak w przykładzie powyżej). 1.0.4.P6 Odpowiedzialność w organizacji o strukturze macierzowej Dziś w firmach często spotyka się strukturę macierzową (patrz 1.2.4 Definiowanie Projektu/ Organizacja projektu). Organizacja macierzowa charakteryzuje się bardziej efektywnym wykorzystaniem zasobów ludzkich. Członkowie zespołu delegowani są do pracy w projekcie czasowo na pełny etat lub jego część. Jednocześnie podlegają swojemu przełożonemu funkcjonalnemu / liniowemu. Może to utrudniać pozyskiwanie ludzi do pracy w projektach. Istnieje także niebezpieczeństwo, że członkowie zespołu będą wykonywać w pierwszej kolejności prace zlecone przez kierowników funkcjonalnych / liniowych niż przez kierownika projektu. Tu, jako kierownik projektu, musisz działać proaktywnie:
Chociaż członkowie zespołu projektowego funkcyjnie nie podlegają kierownikowi
projektu, to ich praca w projekcie powinna być również brana pod uwagę podczas okresowej oceny pracownika. Możesz podjąć próbę pozyskania większego zaangażowania członków zespołu w prace projektowe poprzez uświadomienie, że jesteś zobowiązany do dostarczania informacji o jakości ich pracy w projekcie. Powinno to być uzgodnione z kierownikiem funkcyjnym i przez niego również podane do wiadomości członkom zespołu. Brak informacji zwrotnej o pracy członków zespołu ze strony kierownika projektu, jak i ze strony kierownika funkcyjnego, może skutkować niedotrzymywaniem terminów przez zespół, etc.
Stosuj do rozwiązania problemów typowych dla organizacji macierzowej techniki i
procedury TenStep. Przede wszystkim, jeśli masz wątpliwości co do dostępności i jakości pracy zespołu, powinieneś to przedstawić jako ryzyko projektu i opracować jakieś działania, jakie zostaną podjęte w odpowiedzi na to ryzyko. Jeśli zespół nie dotrzymuje ważnych terminów, zgłoś to jako problem krytyczny i zastosuj zarządzanie problemem krytycznym (Issue). Szukaj przyczyn problemu. Na przykład terminy mogą być nie dotrzymywane, bo członkowie zespołu są odciągani od pracy w projekcie do innej przez szefów funkcyjnych. W tym
58
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wypadku możesz komunikować się z tymi przełożonymi lub ze sponsorem projektu.
Zadbaj, aby członkowie zespołu proaktywnie komunikowali się z tobą. Brak takiej
komunikacji może spowodować, że ludzie nie będą dotrzymywać terminów i nie sygnalizując o trudnościach, wpędzą kierownika projektu w frustrację. Na przykład, jeśli członek zespołu ma termin wykonania zadania na koniec tygodnia, ale z powodu trzydniowych problemów z produkcją nie jest w stanie tego zrobić – powinien wcześniej powiadomić o tym kierownika projektu, aby ten mógł podjąć stosowne działania. Jeśli członek zespołu nie dotrzymuje terminów i nie informuje o tym kierownika projektu odpowiednio wcześnie - nie spełnia stawianych przed nim oczekiwań. Proaktywna komunikacja obowiązuje również kierownika projektu. Upewnij się, że członkowie zespołu znają oczekiwania względem nich, terminy wykonania zadań itd. Kierownik projektu powinien komunikować się także z kierownikami funkcyjnymi. Jest to ważne szczególnie gdy pracownicy otrzymują sprzeczne polecenia od kierownika funkcyjnego i kierownika projektu, lub gdy nie mogą wykonać poleceń o od obu kierowników gdyż jest na to za mało czasu i trzeba coś wybrać. Zarządzanie w strukturze macierzowej sprowadza się do złożonego i delikatnego równoważenia działań między kierownikami projektu a kierownikami obszarów funkcjonalnych. W tym samym czasie, kiedy pracujesz w projekcie, ty sam jak i członkowie twojego zespołu nie zaangażowani w projekt na cały etat, mogą mieć dodatkowe obowiązki poza projektem. Władza kierownika projektu w takich sytuacjach jest zawsze ograniczona. Wtedy szczególnie nie zapominaj o angażowaniu sponsora – w sumie to jego projekt! Jeśli zaistnieje taka potrzeba, sponsor może wpłynąć na kierowników funkcyjnych, aby zapewnili dostępność pracowników w takim zakresie, jaki jest wymagany dla projektu. 1.0.4.P7 Odpowiedzialności za projekt bez posiadania odpowiednich uprawnień decyzyjnych W niektórych organizacjach kierownik projektu jest odpowiedzialny za powodzenie projektu (czyli zarządzanie nim w sposób gwarantujący osiągnięcie sukcesu) nie posiadając odpowiednich uprawnień do podejmowania decyzji. Przykładem tego jest zarządzanie zespołem w organizacji o strukturze macierzowej, wspomniane powyżej. Zazwyczaj jesteś proszony o zarządzanie projektem, nie mając bezpośredniej władzy nad zasobami. Może się wtedy okazać, że twoje możliwości rozwiązywania problemów są ograniczone, gdyż nie zajmujesz dość wysokiego stanowiska w organizacji i będziesz musiał zwracać się po pomoc do kierownictwa wyższego szczebla. Również twoja innowacyjność i elastyczność może być hamowana przez wewnętrzne uwarunkowania polityczne i bierność organizacji. Wszystkie powyższe sytuacje wywołują frustracje. Jednym ze sposobów radzenia sobie z nimi jest zdefiniowanie ról i odpowiedzialności w Definicji Projektu (Project Charter). Na przykład, jeśli nie masz budżetu lub wydatki muszą być zatwierdzane przez zwierzchników – uwzględnij to w procesie zatwierdzania wydatków. Dzięki temu, jeśli później pojawią się problemy, będzie wiadomo kto ma uprawnienia do podejmowania decyzji. Tak właściwie w większości przypadków frustracja nie jest wynikiem braku władzy, ale niejasnych sytuacji. Jeśli kierownik projektu nie posiada uprawnień decyzyjnych, ważne jest, aby wiedzieć kto je ma i jaką procedurę należy uruchomić, aby uzyskać odpowiedni wynik.
59
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1 Definiowanie Projektu / Proces
1.1.P1 Wszystkie projekty powinny rozpoczynać się od fazy definiowania. W przypadku małego projektu nie potrzeba zbierania wielu informacji, dlatego faza ta jest stosunkowo krótka. W większych projektach konieczność jasnego zrozumienia oczekiwań staje się ważniejsza, a uzgodnienie końcowych przedmiotów dostaw - trudniejsze. Poniższe rozdziały opisują procesy definiowania pracy w zależności od wielkości projektu. 1.1.1 Małe projekty – Proces Zlecenia usługi (Service Request) 1.1.2 Średnie projekty 1.1.3 Duże projekty
60
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.1 Definiowanie Projektu / Małe projekty
1.1.1.P1 Wprowadzenie W małych projektach definicja opisuje sposób wykonania kilku zadań wymagających niewielkiego nakładu pracy. W większości firm nie są one w ogóle postrzegane jako projekty. W twojej firmie tego typu prace mogą być nazywane zleceniem wykonywanym w ramach jakichś umów ramowych bądź pracą wspierającą wykonywaną ad hoc. TenStep wszystko to nazywa projektami. Z reguły zadania te spełniają kryteria projektu. Praca jest nietypowa, ma określoną datę rozpoczęcia oraz zakończenia, w jej wyniku powstaje (lub jest ulepszany) przedmiot dostawy, itp. W wielu organizacjach tego typu projekty realizowane są w ramach pracy operacyjnej. Podjęcie decyzji, czy małe zadanie ma być wykonywane i zarządzane jak praca operacyjna czy jako mały projekt, może być trudne. Rozróżnienie stosowane przez TenStep opiera się na określeniu czy zadanie może, czy musi być wykonane. Jeśli problem wymaga szybkiej reakcji, musi być rozwiązany natychmiast – z pewnością stanowi pracę operacyjną. Jeśli problem można poddać priorytetyzacji i można pracować nad nim później – w TenStep jest postrzegany jako mały projekt. Małe projekty zazwyczaj to praca nietypowa, jej czas trwania jest krótki a pracochłonność niska. Na przykład:
Modyfikacje
(rozwój) procesów i systemów produkcyjnych. Często istnieją uciążliwe wady i błędy w procesach, ale ich rozwiązanie można przesunąć na okres późniejszy. Oznacza to, że rozwiązanie problemu ma niski priorytet biznesowy w porównaniu z innymi zadaniami i można z nim „żyć” przez jakiś czas.
Małe usprawnienia procesu. Małe zmiany w procesach
będące wynikiem nowych wymogów prawnych, podatkowych lub audytowych. Zadania te nie przynoszą dodatkowej wartości biznesowej. Mieszczą się jednak w definicji pojęcia „projekt”. Zakwalifikowanie pracy jako mały projekt nie zmniejsza jej wagi ani wartości. Oznacza, że istnieje dowolność w określeniu czasu jej realizacji. Na przykład, jeśli zadanie to jest odpowiednio ważne, można je przesunąć na początek kolejki i rozpocząć natychmiast. Można też wstrzymać realizację rozpoczętego zlecenia, jeśli pojawi się zadanie o większej wartości biznesowej. Dla tego rodzaju pracy charakterystyczne jest to, iż podlega ona priorytetyzacji - w przeciwieństwie do zadań realizowanych w skutek sytuacji kryzysowej. Zazwyczaj wszystkie małe prace mogą być dokumentowane, oceniane oraz priorytetyzowane w oparciu o dokument Zlecenia usługi (Service Request). 1.1.1.P2 Proces Zlecenia usługi (Service Request) Formalne Definiowanie Projektu w małych projektach zabiera niewiele czasu. Definiowane są tylko niektóre elementy pracy w krótkim (jedno- dwustronicowym) dokumencie nazywanym: Zlecenie usługi (Service Request). Proces przypisywania osób do pracy w małym projekcie jest inny niż w średnich i dużych. W dużych przedsięwzięciach prace zazwyczaj są przydzielane konkretnym 61
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
osobom i uruchamiane po zakończeniu fazy definiowania. Liczba zgłaszanych propozycji małych projektów może być większa niż zdolności przerobowe zespołu w danym momencie. Dlatego należy ustalić proces zbierania Zleceń i przydzielania do nich zespołów realizacyjnych, w zależności od priorytetów. Należy również ustalić sposób kontrolowania projektów i zapewnienia wykonywania przede wszystkim najważniejszych prac. Można skorzystać z poniższego procesu Zlecenie usługi :
1
Rola
Proces Zlecenie usługi - dotyczy małych projektów
Klient
Złożenie Zlecenia usługi Klient, z pomocą kierownika projektu (jeśli jest ona konieczna) wypełnia formularz Zlecenie usługi (Service Request). Robi to mimo, że praca może być niewielka, Zlecenie usługi staje się formalną definicją projektu. Zawiera ono: krótki opis wymaganej pracy, priorytet i oszacowaną wartość biznesową projektu, jego koszty. Podpisane przez klienta Zlecenie jest jednoznacznym dowodem akceptacji zlecanej pracy. Formularz: Zlecenie usługi (Service Request).
2
Kierownik Projektu
Sprawdzenie i doprecyzowanie informacji zawartych w Zleceniu usługi Kierownik projektu (lub menedżer liniowy) czyta Zlecenie i sprawdza, czy rozumie co ma być wykonane. Jeśli konieczne, doprecyzowuje z klientem kwestie niejasne. Kierownik projektu musi znać rangę zlecenia (jego znaczenie dla klienta) oraz to, czy zlecenie może być uruchomione w dowolnym momencie, czy np. dopiero po zakończeniu jakiegoś innego zadania.
62
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3
Kierownik Projektu
Wstępne oszacowanie pracochłonności, kosztów oraz czasu trwania Kierownik projektu - posiadający odpowiednie doświadczenie i dobrze rozumiejący pracę, która ma być wykonana, wykonuje wstępne estymacje pracochłonności i czasu trwania. Podaje wyłącznie rzędy wielkości, Wpisuje te dane do formularza Zlecenie usługi (Service Request). Może się zdarzyć, że klient po zapoznaniu się z przewidywaną pracochłonnością zmieni swoje priorytety. Jeśli jest ona większa niż zakładał, priorytet zadania może zostać obniżony. Jeśli przewidywania są niższe, priorytet zadania może wzrosnąć i praca będzie wykonana wcześniej. Jeśli kierownik projektu nie może wykonać oszacowań, powołuje się do tego specjalny zespół. Jeśli w dalszym ciągu nie ma nikogo, kto byłby w stanie wykonać estymacje, wtedy zlecenie przesuwane jest do rejestru prac oczekujących, (backlog) a klient musi podjąć decyzję, czy chce odrywać kogoś od pracy, by zajął się pozyskiwaniem informacji i przygotował wycenę. Zgrubne szacowanie stosuje się jedynie w celu ustalenia priorytetów. Bardziej szczegółowych wyliczeń można dokonać już po kwalifikacji zadania do realizacji.
4
Kierownik Projektu
Uruchomienie Zlecenia lub przesunięcie go do rejestru prac oczekujących Kierownik projektu wraz z klientem oceniają zlecenie w odniesieniu do innych prac w toku i prac oczekujących. Sprawdzają wolne moce przerobowe i umiejętności zespołu, aby określić, czy realizacja zlecenia może zostać uruchomiona od razu. Jeśli wymagane zasoby nie są dostępne lub jeśli praca ma niższy priorytet niż pozostałe zlecenia, umieszczana jest na liście prac oczekujących. Lista prac oczekujących (backlog) zawiera wszystkie zgłoszone, oszacowane i określone pod względem ważności prace, które nie zostały jeszcze przydzielone do realizacji.
5
63
Kierownik projektu, klient
Okresowe sprawdzanie zadań na liście prac oczekujących Kierownik projektu wraz z klientem regularnie przeglądają listę prac oczekujących . Podczas tego przeglądu należy ponownie określić priorytety uwzględniając nowe Zlecenia, Zlecenia oczekujące i projekty w realizacji. Jeśli priorytet Zlecenia usługi jest wystarczająco wysoki i dostępne są odpowiednie zasoby, praca może być przesunięta do realizacji. Jeśli Zlecenie usługi z listy prac oczekujących jest bardziej krytyczne niż prace w trakcie, następuje ich zatrzymanie realizowanej pracy i przesunięcie na listę prac oczekujących .
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6
Członek zespołu
(Po zakwalifikowaniu do realizacji) Ocena wstępnych informacji zawartych w Zleceniu usługi Członek zespołu, po przydzieleniu mu zlecenia do realizacji, powinien sprawdzić, czy informacje zawarte na Zleceniu usługi są poprawne oraz, czy wykonane szacunki są właściwe. Jeśli nie są, należy udokumentować nowe informacje, poddać je pod natychmiastową dyskusję i sprawdzić, czy będą miały wpływu na zmianę priorytetu. Na przykład, klient chce uruchomić mały 40-godzinny projekt. Jeśli bardziej szczegółowe oszacowanie wykaże, że będzie to praca 80 godzinna, klient może nie chcieć, żeby zadanie zostało od razu wykonane. Mogą istnieć inne ważniejsze zgłoszenia, których realizacja zajmie mniej czasu.
7
64
Wszyscy
Uruchomienie projektu wg Zlecenia
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.2 Definiowanie Projektu / Średnie projekty
1.1.2.P1 Wprowadzenie W przypadku małych projektów można polemizować jak bardzo rygorystycznie nimi zarządzać. W średnich projektach nie ma już miejsca na takie dyskusje – praca powinna być zdefiniowana i zarządzana jako projekt. W dalszym ciągu należy pamiętać o skalowalności - proces definiowania nie jest tutaj aż tak złożony, jak w przypadku dużych projektów. Projekt musi być jasno zdefiniowany, ale przedmioty dostaw nie muszą być tak obszernie i szczegółowo opisane jak w Definicji Projektu (Project Charter). Dokumentem definiującym średni projekt jest Skrócona Definicja Projektu (Abbreviated Project Charter).
1
2
3
65
Rola
Definiowanie średnich projektów
Kierownik projektu
Zebranie podstawowych informacji
Kierownik projektu
Ustalenie procesu zatwierdzania definicji
Kierownik projektu, główni interesariusze
Spotkanie z głównymi interesariuszami w celu definiowania pracy
Sprawdź, czy i jakie materiały są dostępne na temat twojego projektu. Mogą to być dokumenty opisujące przedmioty dostaw wcześniejszych, analogicznych projektów, notatki, e-maile, itp. W wielu przypadkach klient, przed uruchomieniem projektu sporządza jakieś analizy opłacalności projektu lub określa wartość projektu z punktu widzenia całego biznesu. Wszystkie powyższe informacje powinny być zebrane przed rozpoczęciem definiowania pracy, gdyż ich znajomość pomaga we właściwym zrozumieniu tego, co ma być wykonane.
Z kierownikiem funkcyjnym i sponsorem, ustal ścieżkę zatwierdzania dokumentu Skrócona Definicja Projektu (Abbreviated Project Charter). Np. należy określić, czy sponsor zatwierdza Definicję przed innymi intersariuszami, czy po tym jak inni przejrzą ten dokument i naniosą swoje uwagi. Należy również wskazać osoby, które będą akceptować ostatecznie dokument oraz osoby, które otrzymają do wiadomości kopię zatwierdzonej definicji. Średnie projekty są zbyt małe, aby zabierały zbyt dużo uwagi sponsora oraz kadry kierowniczej. Dlatego też proces zatwierdzania może być mniej formalny, niż w przypadku dużych projektów.
Przeprowadź
spotkanie z właściwymi intersariuszami (kierownikami, klientami, członkami zespołu, innymi zainteresowanymi stronami) w celu zrozumienia ich sposobu postrzegania zamówionej pracy. Przed spotkaniem upewnij się, że sam wiesz jakie informacje są ci niezbędne, aby zdefiniować projekt. Przejrzyj formularz Skróconej Definicji
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Projektu (Abbreviated Project Charter). Jeśli nie będziesz rozumiał znaczenia poszczególnych sekcji tego dokumentu, nie będziesz w stanie zadać właściwych pytań. Skrócona Definicja Projektu obejmuje m.in.:
Opis
sytuacji bieżącej. Określa okoliczności powstania projektu. Pozwala zrozumieć powód, dla którego przedsięwzięcie jest przeprowadzane.
Zakres.
Rozdział dotyczący zakresu opisuje przedmioty dostawy oraz granice logiczne projektu. Określa czym projekt jest, a czym nie jest. Do każdego przedmiotu dostawy dołącz krótki opis czym się zajmujemy w projekcie wytwarzając ten przedmiot, a czym nie. Więcej szczegółów znajdziesz w rozdziale: 5.0.1. Zakres może zostać określony na wiele sposobów, jednakże w przypadku średnich projektów należy skupić się na przedmiotach dostawy.
Estymacja
pracochłonności. Określ wymagany nakład pracy oraz przedstaw sposób oszacowania tej wartości. Więcej informacji znajdziesz w rozdziale: 2.1.1
Estymacja
czasu trwania. Znając szacowaną wartość pracochłonności projektu, przystąp do oszacowania czasu jego trwania - w oparciu o znaną ilość dostępnych zasobów. Jeśli ustalona jest data rozpoczęcia projektu, można również określić prawdopodobną datę zakończenia. Więcej informacji znajdziesz w rozdziale: 2.1.1
Estymacja kosztów. Koszt pracy należy określ na podstawie
wyliczonej pracochłonności. Dodaj wszelkie koszty nie związane z pracą takie jak: koszty sprzętu, oprogramowania, szkolenia, podróże, itp. Więcej informacji znajdziesz w rozdziale: 2.1.1
Główne
założenia. Aby dany projekt mógł się pomyślnie zakończyć, muszą wystąpić pewne warunki zewnętrzne. Pożądane zdarzenia o wysokim prawdopodobieństwie wystąpienia definiuje się jako założenia. (Definicja pojęcia założenia została omówiona bardziej szczegółowo w rozdziale 7.0 Zarządzanie ryzykiem.) Zidentyfikowaniu założeń sprzyja zastosowanie techniki “burzy mózgów” przeprowadzonej z klientami, intersariuszami oraz członkami zespołu. Więcej informacji znajdziesz w rozdziale: 7.1.3 Zarządzanie ryzykiem / Założenia.
Główne ryzyka. W trakcie realizacji projektu mogą wystąpić
zdarzenia, które mogą stanowić zagrożenie dla projektu. Jeśli istnieje duże prawdopodobieństwo wystąpienia - należy je zidentyfikować jako ryzyka. (Pojęcie ryzyko zostało szczegółowo w rozdziale: 7.0 Zarządzanie ryzykiem.) Więcej informacji znajdziesz w rozdziale: 7.1 Zarządzanie ryzykiem / Proces.
66
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Formularz: Skrócona Definicja Projektu. 4
5
Kierownik projektu
Utworzenie pierwszej wersji Skróconej Definicji Projektu
Kierownik projektu
(Opcjonalnie) Przekazanie propozycji Skróconej Definicji Projektu do weryfikacji
Zapisz wszystkie dostępne informacje i dane na temat projektu, tworząc pierwszą wersję Skróconej Definicji Projektu. Informacje z definicji będą przydatne do budowy harmonogramu z kolei harmonogram posłuży jako materiał uzupełniający do Skróconej Definicji Projektu. Więcej informacji na temat budowania harmonogramu i budżetu znajdziesz w rozdziale: 2.0 Budowanie planu pracy i budżetu. Pamiętaj, że dokument definiujący projekt tworzysz nie dla siebie lecz dla innego odbiorcy. Dlatego powinien być napisany prostym i zrozumiałym językiem.
„Puść w obieg” propozycję Skróconej Definicji Projektu w niewielkim gronie znaczących interesariuszy, którzy mogą dać konstruktywną informację zwrotną. (Wstępna wersja harmonogramu zazwyczaj nie jest rozpowszechniana, chyba że na wyraźną prośbę). W projektach średniej wielkości przekazanie do weryfikacji draftu dokumentu definiującego projekt nie jest obowiązkowe i istnieje możliwość przesłania do zatwierdzenia propozycji Skróconej Definicji Projektu bezpośrednio do sponsora. 6
Kierownik projektu
(Opcjonalnie) Modyfikacja Skróconej Definicji Projektu w oparciu o uzyskane informacje zwrotne Wprowadź korekty do Skróconej Definicji Projektu uwzględniając zgłoszone uwagi, opinie i sugestie. Miej świadomość, że nie wszystkie uzyskane informacje będą tak samo wartościowe. To kierownik projektu wraz ze sponsorem decydują, które z nich należy uwzględnić.
7
8
Kierownik projektu
Zatwierdzenie Skróconej Definicji Projektu
Kierownik projektu
Przekazanie zatwierdzonej właściwym interesariuszom
Proces zatwierdzenia dokumentu jest taki sam jak opisano w punkcie 2. Więcej informacji na temat obiegu dokumentów i różnych sposobów uzyskiwania akceptacji znajdziesz w rozdziale 1.2 Definiowanie Projektu/ Techniki. Skróconej Definicji Projektu
Roześlij kopie zatwierdzonej Skróconej Definicji Projektu jak również Planu oraz procedur zarządzania projektem wszystkim zainteresowanym interesariuszom, w tym członkom zespołu projektowego. 9
67
Kierownik projektu
Opracowanie / zatwierdzenie planu zarządzania projektem.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ważne jest, aby plan zarządzania projektem został zaakceptowany zanim projekt zostanie uruchomiony. Do tworzenia planu zaangażuj swoich zwierzchników, członków zespołu projektowego po stronie klienta oraz pozostałych interesariuszy. Zdecydowanie łatwiej jest obsługiwać np. wnioski o zmianę zakresu, jeśli istnieje zatwierdzona procedura, aniżeli poprzez tworzenie procedury i jednoczesne obsługiwanie wniosków. Biorąc pod uwagę rozmiar projektu - procedury nie powinny być zbyt szczegółowe. Wykorzystaj istniejące w organizacji procedury zarządzania projektem lub Plan zarządzania projektem dla podobnego projektu. 10
68
Wszyscy
Uruchomienie prac w średnim projekcie
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.3 Definiowanie Projektu / Duże projekty 1.1.3.P1 Wprowadzenie W dużych projektach definiowanie projektu musi odbyć się przed uruchomieniem prac. Jeśli mały lub średni projekt nie zostanie właściwie zdefiniowany, konsekwencje błędu prawdopodobnie nie będą zbyt drastyczne. Jeśli projekt nawet 500-godzinny zabierze na realizację dwa razy więcej czasu niż przewidywano, nie będzie to miało katastrofalnego wpływu na firmę. W przypadku dużych projektów jest inaczej. Na przykład, jeśli w wyniku słabego zdefiniowania projekt został oszacowany na 10 000 godzin, a faktycznie zajmie 35 000 godzin, takie niedoszacowanie może okazać się bardzo bolesne dla twojego działu i całej firmy. Im większy projekt, tym więcej potrzeba czasu na z Definiowanie Projektu. Ale by proces ten przebiegał sprawnie upewnij się, że posiadasz wystarczająco dużo informacji i wiesz co masz zrobić w projekcie. Abyś mógł dojść do porozumienia ze sponsorem w kwestii celów projektu, przedmiotów dostawy, szacowanych kosztów oraz czasu trwania, zakresu, itp. posługuj się jak największą ilością informacji i danych, zawartych w dokumentacji. Proces definiowania dużego projektu jest podobny do procesu definiowania średniego. Różnica polega na tym, że w dużym projekcie trzeba zdefiniować więcej danych, a tym samym wydłuża się czas niezbędny na realizację fazy planowania. 1.1.3.P2 Proces definiowania dużego projektu wygląda w sposób następujący:
1
2
69
Rola
Określanie dużych projektów
Kierownik projektu
Zebranie podstawowych informacji
Kierownik projektu, sponsor
Ustalenie procesu zatwierdzania definicji
Sprawdź, czy i jakie materiały są dostępne na temat twojego projektu. Mogą to być dokumenty opisujące przedmioty dostaw wcześniejszych, analogicznych projektów, notatki, e-maile, itp. W wielu przypadkach klient, przed uruchomieniem projektu sporządza jakieś analizy opłacalności projektu lub określa wartość projektu z punktu widzenia całego biznesu. Wszystkie powyższe informacje powinny być zebrane przed rozpoczęciem definiowania pracy, gdyż ich znajomość pomaga we właściwym zrozumieniu tego, co ma być wykonane. A w przypadku dużego projektu jest to kluczowe.
Z kierownikiem funkcyjnym i sponsorem, ustal ścieżkę zatwierdzania dokumentu Definicja Projektu (Project Charter). Np. należy określić, czy sponsor zatwierdza Definicję przed innymi intersariuszami, czy po tym jak inni przejrzą ten dokument i naniosą swoje uwagi. Należy również wskazać osoby, które będą akceptować ostatecznie dokument oraz osoby, które otrzymają do wiadomości kopię
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zatwierdzonej definicji. 1.1.3.P3 Planowanie zakresu
3
Kierownik projektu
Utworzenie procesu zarządzania zakresem Proces zarządzania zakresem opisuje działania, które zastosujesz do zdefiniowania zakresu w projekcie oraz sposób zarządzania jego zmianami. Jeśli w twojej organizacji nie utworzono do tej pory standardowego procesu zarządzania zakresem, który mógłbyś jedynie dostosować do specyficznych uwarunkowań swojego projektu – musisz zaprojektować proces zarządzania zakresem w projekcie na własne potrzeby.
1.1.3.P4 Definiowanie zakresu 4
Kierownik projektu, kluczowi interesariusze
Przeprowadzenie spotkań z głównymi interesariuszami w celu zdefiniowania pracy Przeprowadź spotkania z właściwymi intersariuszami (kierownikami, klientami, członkami zespołu, innymi zainteresowanymi stronami) w celu zrozumienia ich sposobu postrzegania zamówionej pracy. Przed spotkaniem upewnij się, że sam wiesz jakie informacje są niezbędne, aby zdefiniować tej klasy projekt. Przejrzyj formularz Definicji Projektu (Project Charter). Jeśli nie będziesz rozumiał znaczenia poszczególnych sekcji dokumentu, nie będziesz w stanie zadać właściwych pytań właściwym osobom. Definicja Projektu obejmuje:
Podsumowanie
menedżerskie (opcjonalnie). Cały dokument Definicja projektu może okazać się za duży i za trudny do przyswojenia przez decydentów. Dlatego można dodać rozdział zawierający łatwe do przeczytania streszczenie. Pamiętaj, że ma to być streszczenie dokumentu definiującego konkretny projekt, a nie samego projektu.
Opis
sytuacji bieżącej. Określa okoliczności powstania projektu. Pozwala zrozumieć powód, dla którego przedsięwzięcie jest przeprowadzane. Przedstawia wartość biznesową. Często jest logicznym uzasadnieniem zamierzeń i celów.
Zamierzenia.
Opisują jak projekt wpisuje się w cele strategiczne organizacji. Więcej informacji na temat zamierzeń i celów znajdziesz w rozdziale: 1.2.1 Definiowanie Projektu / Zamierzenia i cele.
Cele 70
projektu. Ten rozdział opisuje stan, jaki ma być
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
osiągnięty po zakończeniu projektu. Cele operacyjne projektu powinny wprost nawiązywać do przedmiotów dostaw. Więcej informacji na temat zamierzeń i celów operacyjnych znajdziesz w rozdziale: 1.2.1 Definiowanie Projektu / Zamierzenia i cele.
Zakres.
Rozdział dotyczący zakresu opisuje przedmioty dostawy oraz granice logiczne projektu. Określa czym projekt jest, a czym nie jest. Do każdego przedmiotu dostawy dołącz krótki opis, aby było jasne jakie produkty zostaną wytworzone przez projekt, a jakie nie. Ułatwi to znacznie zarządzanie zmianami zakresu w czasie realizacji projektu. W opisie przedmiotów dostawy dodatkowo uwzględnij bardziej szczegółowe zagadnienia:
Dane potrzebne do realizacji projektu, dane które są poza zakresem projektu
Działy, na które projekt ma i nie ma wpływu Procesy biznesowe objęte i nie objęte zakresem projektu
Transakcje biznesowe objęte i nie objęte zakresem projektu
Inne projekty, na które dany projekt ma wpływ Inne informacje precyzujące co jest w zakresie poza zakresu projektu Więcej szczegółów znajdziesz Definiowanie zakresu.
w
rozdziale:
i
5.0.1
Estymacja
pracochłonności. Określ pracochłonność oraz przedstaw sposób oszacowania jej wartości. Może się okazać, że aby uzyskać dokładność szacowania na poziomie (± 10%), będziesz musiał w tym samym czasie pracować nad dokumentem definiującym projekt i nad planem pracy. Więcej informacji znajdziesz w rozdziale: 2.1.1 Budowanie Planu operacyjnego / Estymacje.
Estymacja
czasu trwania. Znając szacowaną wartość pracochłonności projektu, przystąp do oszacowania czasu trwania projektu - w oparciu o założoną ilość dostępnych zasobów. Jeśli znana jest data rozpoczęcia projektu, można również określić prawdopodobną datę zakończenia. Może się okazać, że aby uzyskać dokładność szacowania na poziomie (± 10%), będziesz musiał w tym samym czasie pracować nad dokumentem definiującym projekt i nad planem pracy. Więcej informacji znajdziesz w rozdziale: 2.1.1 Budowanie Planu operacyjnego / Estymacje.
Estymacja
kosztów. Oszacuj koszt pracy bazując na wyliczonej pracochłonności. Dodaj wszelkie koszty nie
71
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
związane z pracą takie jak: koszty sprzętu, oprogramowania, szkolenia, podróże, itp. Może się okazać, że aby uzyskać dokładność szacowania na poziomie (± 10%), będziesz musiał w tym samym czasie pracować nad dokumentem definiującym projekt i nad planem pracy. Więcej informacji znajdziesz w rozdziale: 2.1.1 Budowanie Planu operacyjnego / Estymacje.
Główne
założenia. Aby dany projekt mógł się pomyślnie zakończyć, muszą wystąpić pewne warunki zewnętrzne. Pożądane zdarzenia o wysokim prawdopodobieństwie wystąpienia definiuje się jako założenia. (Definicja pojęcia założenia została omówiona bardziej szczegółowo w rozdziale 7.0 Zarządzanie ryzykiem.) Zidentyfikowaniu założeń sprzyja zastosowanie techniki “burzy mózgów” przeprowadzonej z klientami, intersariuszami oraz członkami zespołu. Więcej informacji znajdziesz w rozdziale: 7.1.3 Zarządzanie ryzykiem / Założenia.
Główne ryzyka. W trakcie realizacji projektu mogą wystąpić
zdarzenia, które mogą stanowić zagrożenie dla projektu. Jeśli istnieje duże prawdopodobieństwo wystąpienia - należy je zidentyfikować jako ryzyka. (Pojęcie ryzyko zostało szczegółowo w rozdziale: 7.0 Zarządzanie ryzykiem.) Więcej informacji znajdziesz w rozdziale: 7.1 Zarządzanie ryzykiem / Proces.
Organizacja
projektu. Schemat organizacyjny dużych projektów zazwyczaj jest dość rozległy odwzorowując zaangażowanie różnych interesariuszy w pracę. Na przykład, po stronie klienta może zostać powołany kierownik projektu, który będzie raportował do sponsora. W projekcie może wystąpić rola sponsora wykonawczego, który w codziennych sprawach będzie reprezentował sponsora głównego. Główni interesariusze mogą tworzyć komitet kierujący, sprawujący strategiczną opiekę nad projektem. Jeśli dostawcy będą pełnić formalną rolę – powinno to zostać ujęte w schemacie organizacyjnym (trzy główne sposoby organizacji zespołów projektowych opisano w rozdziale: 1.2.4 Definiowanie Projektu / Organizacja projektu). Poszczególne role w projekcie opisano w rozdziale: 1.2.2 Definiowanie Projektu/ Role i odpowiedzialności. W przypadku dużych projektów również korzystne może się okazać zdefiniowanie sposobu tworzenia i zatwierdzania przedmiotów dostaw. Szczegółowy opis znajdziesz w rozdziale 1.2.3 Definiowanie Projektu / Odpowiedzialność w organizacji macierzowej. Inną pomocną techniką jest przeprowadzenie analizy interesariuszy – kim są i jakie są ich potrzeby. Szczegółowy opis znajdziesz w rozdziale: 1.2.5 Definiowanie Projektu/
72
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Analiza Interesariuszy. Formularz: Definicja Projektu (Project Charter) 5
6
7
Kierownik projektu
Utworzenie pierwszej wersji Definicji Projektu
Kierownik projektu
Przekazanie propozycji Definicji Projektu do weryfikacji
Kierownik projektu
Modyfikacja Definicji Projektu w oparciu o uzyskane informacje zwrotne
Zapisz wszystkie dostępne informacje i dane na temat projektu, tworząc pierwszą wersję Definicji Projektu. Informacje z definicji będą przydatne do budowy harmonogramu z kolei harmonogram posłuży jako materiał uzupełniający do Definicji Projektu. Więcej informacji na temat budowania harmonogramu i budżetu znajdziesz w rozdziale: 2.0 Budowanie planu pracy i budżetu. Pamiętaj, że dokument definiujący projekt tworzysz nie dla siebie lecz dla innego odbiorcy. Dlatego powinien być napisany prostym i zrozumiałym językiem.
„Puść w obieg” propozycję Definicji Projektu w niewielkim gronie interesariuszy, którzy mogą dać konstruktywną informację zwrotną. Wstępna wersja harmonogramu zazwyczaj nie jest rozpowszechniana, chyba że na wyraźną prośbę.
Wprowadź korekty do Definicji Projektu uwzględniając zgłoszone uwagi, opinie i sugestie. Miej świadomość, że nie wszystkie informacje zwrotne będą tak samo wartościowe. To kierownik projektu wraz ze sponsorem decydują, które z nich należy uwzględnić – które są istotne i mogą wpłynąć na przejrzystość i kompletność dokumentu. 8
Kierownik projektu
(Opcjonalnie) Przekazanie uaktualnionej Definicji Projektu do ponownej weryfikacji większej grupie osób Wprowadź kolejne poprawki w oparciu o uzyskane opinie.
1.1.3.P5 Weryfikacja zakresu 9
73
Kierownik projektu
Zatwierdzenie Definicji Projektu Proces zatwierdzenia dokumentu jest taki sam jak opisano w punkcie 2 niniejszego procesu. Więcej informacji na temat obiegu dokumentów i różnych sposobów uzyskiwania akceptacji znajdziesz w rozdziale 1.2 Definiowanie Projektu/ Techniki.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10
Kierownik projektu
Przekazanie zatwierdzonej interesariuszom
Definicji
Projektu
właściwym
Roześlij kopie zatwierdzonej Definicji Projektu jak również Planu oraz procedur zarządzania projektem do wszystkich zainteresowanych interesariuszy, w tym do członków zespołu projektowego.
74
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.3.P6 Plan zakupów 11
Kierownik projektu
(Opcjonalnie) Utworzenie planu i strategii zarządzania relacjami z dostawcami Jeśli dokonujesz w swoim projekcie zakupów produktów lub usług, powinieneś ustalić strategię dokonywania zakupów i ich plan. Czasami będziesz po prostu stosował się do przyjętych procedur i wykorzystywał już zawarte umowy ramowe z dostawcami. Pozyskując kontrahentów będziesz bazował na ustalonej w firmie liście dostawców. Możesz też ustalić z Działem Zakupów, że na potrzeby swojego projektu utworzysz własny plan zarządzania relacjami z dostawcami. Więcej informacji na temat tworzenia planu zaopatrzenia znajdziesz w rozdziale: 1.1.3.1 Planowanie zakupów w projekcie. Dla większości zespołów projektowych identyfikacja i wybór dostawcy jest częścią normalnych prac realizacyjnych. Oznacza to, że jest on realizowany w początkowym etapie, po uruchomieniu prac projektowych. Jednakże może się zdarzyć, że te czynności muszą być wykonane w ramach procesu definiowania projektu przed uruchomieniem prac. Jeśli musisz wykonać tę pracę teraz – zapoznaj się z rozdziałem 1.1.3.2. Znajdziesz w nim omówienie zagadnień dotyczących procesu identyfikacji i wyboru dostawców.
1.1.3.P7 Opracowanie procedur zarządzania projektem 12
Kierownik projektu
Opracowanie Planu Zarządzania Projektem Ważne jest, aby plan zarządzania projektem został utworzony w formie dokumentu przed rozpoczęciem projektu, przy udziale twoich zwierzchników, członków zespołu projektowego po stronie klienta oraz pozostałych zaangażowanych interesariuszy. Zdecydowanie łatwiej jest obsługiwać np. wnioski o zmianę zakresu pracy, jeśli istnieje zatwierdzona już odpowiednia procedura, aniżeli poprzez tworzenie procedury i obsługiwanie wniosków równocześnie. Im większy projekt, tym formalizacja i strukturalizacja planu zarządzania projektem muszą być większe. Jeśli jesteś w posiadaniu planu zarządzania projektem dla podobnego projektu lub jeśli twoja organizacja posiada już opracowany zestaw procedur dla dużych projektów – skorzystaj z nich. Dokumenty mogą istnieć oddzielnie lub być scalone w formie jednego dokumentu: plan zarządzania projektem. Dokument ten obejmuje:
Definicja Projektu Role i odpowiedzialności Harmonogram, Struktura podziału pracy (WBS), 75
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Plan zarządzania zakresem, Plan zarządzania jakością, Plan zarządzania personelem Plan komunikacji, Plan zarządzania ryzykiem Plan Zatwierdzanie projektu Pozostałe przedmioty dostawy, plany i procedury zgodnie z wymaganiami. 1.1.3.P8 13
76
Wszyscy
Uruchomienie prac w dużym projekcie
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.3.1 Planowanie zakupów w projekcie
1.1.3.1.P1 Zakupy są związane z pozyskiwaniem dóbr i usług na zewnątrz firmy. W szczególności termin ten jest związany z dostawcami oraz partnerami zewnętrznymi. Nie odnosi się on do wewnętrznych struktur organizacyjnych. (Dla potrzeb TenStep przyjęto, że terminy zakupy oraz zaopatrzenie oznaczają to samo.) Jest to obszar, o którym kierownik projektu powinien posiadać pewną wiedzę. Jakkolwiek w wielu firmach, a być może w większości, zaopatrzenie nie jest domeną kierownika projektu. Kierownik projektu zazwyczaj nie ma stosownych uprawnień, aby zawierać kontrakty w imieniu firmy i zazwyczaj nie powierza mu się zarządzania już zawartymi kontraktami. Jak wcześniej wspomniano – zazwyczaj jest to odpowiedzialność Działu Zakupów. PMBOK® opisuje sześć procesów w ramach Zarządzania zaopatrzeniem w projekcie.
Planowanie zakupów to proces określenia rodzaju i terminu zakupu produktów.
Zazwyczaj jest kontrolowany przez kierownika projektu ze względu na fakt, że centralny Dział Zakupów nie posiada wiedzy na temat każdej potrzeby poszczególnych zespołów projektowych. Plan zakupów jest budowany przez zespół projektowy i zgodnie z jego decyzjami.
Planowanie
kontraktów to proces związany z określaniem wymagań dla wszystkich produktów oraz usług na potrzeby projektu. Utworzenie planu jest odpowiedzialnością zespołu projektowego. Jest to moment, kiedy należy rozpocząć wyszukiwanie potencjalnych dostawców towarów i usług. Większość projektów nie wymaga stosowania jakichś szczególnych rozwiązań. Jeśli w zrealizowanych już projektach korzystano z podobnych produktów i usług, prawdopodobnie jesteś w posiadaniu listy przedsiębiorstw, z którymi twoja firma podpisała umowy ramowe na dostarczanie towarów i usług, których i ty potrzebujesz do realizacji swojego projektu. Zazwyczaj dotyczy to zasobów, surowców, sprzętu komputerowego, itp.)
Rozesłanie zapytania ofertowego. Jeśli w poprzednim kroku nie było możliwe
wskazanie firmy, która mogłaby dostarczyć potrzebne towary i usługi, rozpocznij proces zbierania ofert. Jego wynikiem będzie długa lista sprzedawców. Uzyskasz również informacje o możliwościach poszczególnych sprzedawców i proponowanych cenach. Kolejny krok to zawężenie tej listy do oferentów najbardziej spełniających twoje wymagania. Proces zbierania ofert może oczywiście być przeprowadzony przez członków zespołu projektowego, jakkolwiek zazwyczaj zajmuje się tym Dział Zakupów. Tak, czy inaczej, postępowanie ofertowe powinno być zgodne z obowiązującą procedurą, bądź ktoś z Działu Zakupów powinien czuwać nad pracą zespołu projektowego i udzielać stosownej pomocy i wsparcia, tak aby niezbędne środki finansowe zostały zarezerwowane na koncie, i zostały wybrane odpowiednie firmy.
Wybór
sprzedawców to proces, podczas którego następuje faktyczny wybór sprzedawcy, który zajmie się dostawą produktów lub usług. Podobnie jak poprzednio - zespół projektowy może dokonać ostatecznego wyboru, ale zazwyczaj zajmują się tym Zakupy w oparciu o istniejące procedury. W niektórych firmach ostateczną decyzję podejmą Zakupy, ale uwzględniając opinię zespołu projektowego. W większości firm kontrakty nie będą zawierane tylko na podstawie opinii kierownika projektu. Zwykle to Zakupy, prawdopodobnie we współpracy z
77
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Działem Prawnym, realizują proces wyboru dostawcy i przeprowadzają z nim negocjacje.
Administrowanie kontraktem to proces zarządzania relacjami z kontrahentem. Podczas realizacji codziennych działań kierownik projektu może współpracować z menedżerem odpowiedzialnym za twoją firmę po stronie dostawcy, Jednak ich działania zawsze powinny być zgodne z zapisami zawartymi w umowie. Wszelkimi zmianami umowy zajmuje się Dział Zakupów i Dział Prawny.
Wygaśnięcie kontraktu ma miejsce, jeśli umowa została zawarta tylko na czas
realizacji konkretnego projektu. Na przykład, jeśli przedmiotem umowy było dostarczenie surowców dla konkretnego projektu, to kontrakt wygasa wraz z jego zakończeniem. Jeśli sprzedawca dostarcza również inne towary, kontrakt prawdopodobnie będzie w dalszym ciągu obowiązywał. W przypadku wygaśnięcia kontraktu nadzór nad płatnościami końcowymi i formalnym zamknięciem umowy sprawuje Dział Zakupów. Zespół projektowy zaś, we współpracy z Zakupami, czuwa, aby cała zakontraktowana praca została dostarczona. Przekazuje opinię na temat współpracy z dostawcą.
78
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.1.3.2 Wybór dostawcy
1.1.3.2.P1 Często firmy szukają dostawców w związku z konkretnymi potrzebami. Proces wyboru dostawcy jest zazwyczaj prosty, choć w przypadku niektórych usług / towarów może być długotrwały. Poniższej przedstawione techniki mogą zostać wykorzystane w większości procesów selekcji. Poniższy proces został opisany na dość wysokim poziomie uogólnienia i aby mógł być użyty w konkretnym projekcie będzie wymagał doszczegółowienia, 1.1.3.2.P2 Planowanie kontraktów
1
Rola
Proces selekcji dostawcy
Kierownik projektu
Zebranie potrzeb biznesowych i utworzenie ich hierarchii Trudno jest wybrać dostawcę, jeśli nie zna się wymagań. W związku z tym pierwszym krokiem jest zebranie ich. Zadaj sobie następujące pytania:
Z jakich usług oferowanych przez dostawcę skorzystamy? Jaki problem mają one rozwiązać? Jakie możliwości musi posiadać dostawca, abyśmy mogli
z
nim współpracować? Często nie będziesz w stanie określić wszystkich wymagań tylko przez zadawanie pytań klientowi. Może on nie wiedzieć wszystkiego, co jest potrzebne do określenia w 100% kompletnych i właściwych wymagań. W przypadku zwykłego projektu brakujące wymagania możesz dodać uruchamiając procedurę zarządzania zmianą zakresu. W przypadku wyboru dostawcy powinieneś zgromadzić wymagania przy „pierwszym podejściu”. Może być za późno na uzupełnianie ich po dokonaniu wyboru. Każde wymaganie powinno zostać ocenione pod względem ważności. Do tego celu możesz użyć skali numerycznej lub klasyfikacji: wysoki/ średni/ niski lub inne skale. Przedstaw do weryfikacji i zatwierdzenia sporządzoną listę wymagań wobec dostawców wraz z przyjętymi wagami: swojemu sponsorowi, głównym klientom i interesariuszom.
1.1.3.2.P3 Rozesłanie zapytania ofertowego 2
79
Kierownik projektu
Sporządzenie długiej listy dostawców Po zebraniu wymagań, rozpocznij poszukiwanie dostawców, którzy będą mogli zaspokoić twoje potrzeby. Możesz wykorzystać Internet, czasopisma branżowe, możesz też pozyskać informacje od innych firm, itp. Celem tych działań jest stworzenie obszernej, (lecz nie
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wyczerpującej) listy potencjalnych oferentów. Dzięki temu uzyskasz pewność, że nie przeoczyłeś żadnego z potencjalnych dostawców. 3
Kierownik projektu
Sporządzenie krótkiej listy dostawców Dokonaj wstępnej ogólnej oceny długiej listy. Na przykład, niektórzy oferenci mogą działać na rynku od niedawna. Inni mogą być zbyt drodzy. Celem tego działania jest utworzenie, krótkiej listy oferentów, którzy będą w stanie odpowiedzieć na twoje potrzeby. Roześlij Zapytanie Ofertowe (Request for Proposal) do firm znajdujących się na krótkiej liście. Jeśli długa lista nie jest zbyt obszerna można wysłać zaproszenie do wszystkich. Jednak liczbę oferentów trzeba zmniejszyć do takiej, aby było możliwe dokonanie porównania ofert i zauważenia różnić między nimi.
1.1.3.2.P4 Wybór dostawcy 4
5
Kierownik projektu
Weryfikacja krótkiej listy dostawców
Kierownik projektu
Wybór końcowy i negocjowanie kontraktu
Ta czynność może się okazać najtrudniejszą w procesie wyboru. Musisz sklasyfikować dostawców pod kątem ich możliwości i stopnia wypełnienia wymagań, nadać każdemu z nich stopień ważności. Możesz również przeprowadzić rozmowy ze oferentami, przejrzeć strony internetowe, itp. Liczbowe kalkulacje zazwyczaj oparte są na iloczynie stopnia spełnia wymagań i stopnia ważności. Oferent z najwyższym wynikiem dla każdego z wymagań prawdopodobnie jest tym, który w najwyższym stopniu zaspokoi twoje potrzeby. Po zakończeniu tego etapu, uzyskasz uporządkowaną listę oferentów najbardziej odpowiadających twoim wymaganiom.
W wielu organizacjach zespół projektowy sporządza rekomendację wyboru i przekazuje proces do Działu Zakupów lub Zaopatrzenia. W tym momencie powinieneś posiadać wszelkie niezbędne informacje do podjęcia decyzji. Jeśli wybierasz głównego dostawcę, powinieneś posiadać odpowiednie argumenty dla poparcia swojej rekomendacji. Jeśli dokonujesz wyboru kilku oferentów, możesz zdecydować się na tylu ilu tylko potrzebujesz. Po dokonaniu ostatecznego wyboru, może zaistnieć konieczność negocjowania kontraktu. Jeśli proces nie będzie szedł we właściwym kierunku, musisz być przygotowanym na negocjacje z oferentami, którzy zostali umieszczeni na niższych pozycjach na twojej liście - pod warunkiem, że w dalszym ciągu będą spełniali wymagania.
80
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2 Definiowanie Projektu / Techniki W poniższym rozdziale użycie terminu „definicja projektu” oznacza każdy dokument pełniący tę rolę w projekcie. Odpowiednio do klasy projektów dokumentem definiującym projekt jest Zlecenie Usługi, Skrócona Definicja Projektu, pełna Definicja Projektu. 1.2.P1 Równoczesna praca nad Definicją Projektu oraz Planem operacyjnym projektu Nie istnieje z góry ustalona sekwencja działań podczas definiowania pracy (rozdział 1.0) i tworzenia planu i budżetu (rozdział 2.0). Oznacza to, że nie definiujesz najpierw pracy, a potem dopiero budujesz plan i budżet. Niektóre rozdziały w Definicji Projektu, takie jak estymacje pracochłonności i czasu trwania, nie mogą zostać opisane bez ogólnego harmonogramu. Nie można również zakończyć pracy nad planem bez zatwierdzenia Definicji Projektu. Na przykład nie możesz rozpocząć tworzenia harmonogramu i budżetu bez uzyskania ogólnego zatwierdzenia przedmiotów dostaw i zakresu. Również pomocne przy tworzeniu harmonogramu i budżetu może być opisane w Definicji Projektu ogólne podejście realizacyjne. W pewnym stopniu Definiowanie Projektu i tworzenie harmonogramu i budżetu musi być wykonywane równocześnie. Analogicznie, powinny być opracowywane dwa główne przedmioty dostaw pierwszych procesów zarządzania projektem: Definicja projektu i Plan projektu. Przekonasz się, że pozyskując informacje dotyczące zakresu i przedmiotów dostaw, będziesz mógł budować ogólny plan. W miarę pozyskiwania informacji o pracy, będziesz mógł uzupełniać definicję o dalsze szczegóły. Po opisaniu przedmiotów dostaw, zakresu, założeń i podejścia realizacyjnego, będziesz miał wystarczająco dużo informacji, aby uzupełnić utworzony na wysokim poziomie ogólności harmonogram. Ten ogólny harmonogram może posłużyć ci do wykonania estymacji budżetu, pracochłonności i czasu trwania – te dane wykorzystasz w Definicji Projektu. 1.2.P2 Dzielenie dużych projektów na mniejsze Dni mega-projektów już się skończyły. Bardzo trudno zarządzało się nimi. Dlaczego?
Im większe projekty, tym dłuższe. Im dalej w przyszłość, mniej pewne i wyraźne są działania, jakie powinny być podjęte.
Im większe projekty, tym trudniej je zrozumieć i właściwie zaplanować, wykonać prawidłowe szacowania pracochłonności, czasu trwania oraz kosztów.
Warunki biznesowe i techniczne ulegają zmianie wraz z upływem czasu, co czyni planowanie założeń dla przyszłości bardzo niepewnymi. To co jest oczywiste dziś może ulec drastyczniej zmianie w przyszłości.
W
dużych i długich projektach trudno jest utrzymać entuzjazm i wsparcie organizacji.
Trudno
jest planować zapotrzebowanie na zasoby oraz ich dostępność w przyszłości. A to utrudnia właściwe oszacowanie jakie wparcie uzyskasz w przyszłych pracach.
81
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Bardzo duże zadania są zbyt trudne i złożone, żeby traktować je jako pojedyncze projekty. Lepiej jest je dzielić na mniejsze, którymi będzie łatwiej zarządzać i każdą z nich traktować jak oddzielny projekt z własną definicją i planem. Długie przedsięwzięcie np. informatyczne może zostać rozbite na osobne następujące po sobie projekty oparte na cyklu życia rozwiązań IT. Najpierw uruchamia się projekt mający na celu wykonanie prac analitycznych. Po jego zakończeniu otwierany jest następny projekt, wykorzystujący zdobytą wiedzę, w celu zaprojektowania rozwiązania IT. Następnie rozpoczyna się projekt konstruowania / testowania i w końcu projekt wdrażający przyjęte rozwiązanie. Inne większe projekty można rozbić na mniejsze, uruchamiane równocześnie. Niektóre większe zadania mogą stanowić kombinację mniejszych projektów, z których część będzie wykonywana równocześnie, a część sekwencyjnie. Każdy zespół będzie pracował nad realizacją małego projektu, jednak całość prac musi być koordynowana tak, aby wszystko zakończyło się sukcesem. 1.2.P3 PROGRAM jako forma koordynacji kilku powiązanych projektów Po podzieleniu dużego projektu na kilka mniejszych niezbędne jest zapewnienie koordynacji i zarządzania całością prac. W tym celu tworzy się “program”, który jest rodzajem parasola rozpiętego nad grupą powiązanych projektów. Każdy z projektów jest zarządzany przez swojego kierownika - zatrudnionego na cały lub część etatu. Program zaś jest koordynowany przez kierownika programu. W wyniku programu nie powstają odrębne przedmioty dostaw ponieważ są one wytwarzane przez zespoły projektowe. Celem programu jest:
Zapewnienie całościowego kierowania projektami Zapewnienie efektywnej komunikacji pomiędzy powiązanymi projektami Zapewnienie centralnego punktu kontaktu dla klienta i zespołów projektowych Ustalanie w jaki sposób pojedyncze projekty powinny być zdefiniowane, aby zapewnić powodzenie całego przedsięwzięcia.
1.2.P4 Praca z klientem w przypadku trudności ze zdefiniowaniem projektu Często zdarza się, że kierownik projektu ma zbyt wygórowane oczekiwania wobec jakości informacji jaką może pozyskać od klienta. W wielu przypadkach klient nie będzie znał odpowiedzi na pytania dotyczące projektu. N oznacza to, że klient nie wie co robi. Szczególnie w dużych projektach, klient ma wizję produktu końcowego, choć jeszcze nie jest w stanie doprecyzować poszczególnych przedmiotów dostaw. Może się również zdarzyć, że nie będzie mógł wiele powiedzieć na temat zakresu, ryzyk, organizacji projektu, itp. Bazując na niekompletnych informacjach, kierownik projektu może uleć pokusie „zgadywania” niektórych szczegółów. Nie jest to dobre. Jeśli „zgadujesz” każdy taki szczegół musisz sprawdzić, czy twoja intuicja jest zbieżna z oczekiwaniem klienta. Jeśli jesteś w sytuacji braku informacji i niemożliwości ich uzyskania, rozważ trzy kierunki postępowania:
Ustal co wiesz, a czego nie wiesz - przed uruchomieniem prac projektowych. Spróbuj określić koszty i czas trwania projektu, i poprzez szacowanie definiuj kolejne elementy projektu.
82
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Podziel projekt na kilka mniejszych projektów (jak opisano wcześniej). Nawet jeśli
końcowego wyniku nie da się jasno zdefiniować, będzie istniała pewna ilość dobrze zdefiniowanej pracy, co z kolei dostarczy informacji potrzebnych do zdefiniowania końcowego rozwiązania. Zdefiniuj projekt tylko do takiego momentu w czasie, do którego rozumiesz i potrafisz z klientem „zobaczyć” pracę wyraźnie, bez „zgadywania”. Następnie zdefiniuj i zaplanuj kolejne projekty dla zabezpieczenia wykonania pozostałej pracy tak dokładnie, jak pozwalają na to posiadane przez ciebie informacje. Na przykład możesz utworzyć projekt do zbierania wymagań biznesowych i następnie wykorzystywać wyniki tego projektu do zdefiniowania kolejnego projektu w celu uzyskania końcowych przedmiotów dostaw.
Jeśli nie możesz podzielić projektu na mniejsze, zaplanuj pracę na najbliższe 90 dni. Szczegółowo planuj prace krótkoterminowe, a prace długoterminowe pozostawiaj w pewnym stopniu niedookreślone. Po miesiącu zaplanuj następne 30 dni. I tak do momentu, gdy z upływem czasu uzyskasz lepsze zrozumienie o co chodzi. Fakt nikłej wiedzy o projekcie, przedmiotach dostawy etc. umieść na liście ryzyk. W miarę zdobywania informacji możesz również szczegółowo przeanalizować estymacje i współpracując ze sponsorem, upewnić się, że dalsza kontynuacja prac projektowych jest zasadna.
1.2.P5 Zrozumienie ról i odpowiedzialności w projekcie W małych projektach organizacja jest bardzo prosta – może być zidentyfikowany kierownik projektu oraz klient/ sponsor. Osoba zarządzająca projektem może być również jedyną osobą pracującą nad tym projektem. Jednak w dużych projektach może być konieczna złożona i sformalizowana struktura organizacyjna. Może ona obejmować: członków zespołu projektowego, sponsora wykonawczego, sponsora projektu, kierownika po stronie klienta, dyrektora projektu, komitet sterujący, dostawców, klientów i inne osoby. Pamiętaj, że im więcej osób zaangażowanych w dany projekt, tym ważniejsze jest, aby każdy miał jasność co do swojej roli i odpowiedzialności w projekcie. Na przykład ostatnią rzeczą, której można chcieć, jest aby ktoś udzielał porad tak, jakby był sponsorem, a jest tylko interesariuszem, tyle że na kierowniczym stanowisku. Budując strukturę organizacyjną projektu i definiując role i ich odpowiedzialności, powinieneś uwzględnić wszystkich głównych uczestników. Zazwyczaj typowe role i odpowiedzialności można określić wcześniej i używać ich w różnych projektach. Typowe role i odpowiedzialności zostały opisane w rozdziale: 1.2.2 Definiowanie Projektu / Role i odpowiedzialności. 1.2.P6 Pozyskiwanie akceptacji właściwych osób Uzyskaj formalne zatwierdzenie Definicji Projektu. Istnieje wiele sposobów na uzyskanie formalnej akceptacji projektu. I tu także najważniejsze jest planowanie. W małych projektach prawdopodobnie wystarczy zatwierdzenie przez głównego klienta lub sponsora projektu – w postaci podpisu dokumentu papierowego lub zatwierdzenie drogą elektroniczną. Nie może się to odbywać ustnie! W większych projektach, we współpracy ze swoim kierownikiem funkcyjnym i sponsorem projektu, ustal kto dokona formalnego zatwierdzenia Definicji Projektu, kto
83
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
nieformalnego, a kto tylko otrzyma kopię zatwierdzonego dokumentu do wiadomości. Za punkt wyjścia możesz przyjąć następujące podejście:
Sponsor projektu oraz główni interesariusze. Są głównymi zatwierdzającymi dokumenty w sposób formalny. Dotyczy to zarówno Definicji Projektu (Project Charter) jak innych dokumentów wytworzonych w trakcie realizacji pracy, które wymagają zatwierdzenia. Dokumenty mogą być zatwierdzane w formie papierowej lub elektronicznie. W tym miejscu należy zwrócić uwagę, że powinieneś zachować kopię dokumentującą zatwierdzenie. Sponsor oraz inni główni interesariusze powinni dostać do weryfikacji najpierw wstępną, a nie końcową, wersję dokumentu. Ostateczne zatwierdzenie powinno być tylko formalnością. Nie należy dopuszczać do sytuacji, kiedy starasz się o uzyskanie końcowego zatwierdzenia, a sponsor ma dalszym ciągu pytania lub wątpliwości.
Inni interesariusze szczebla kierowniczego. Dokonują nieformalnej akceptacji. Oznacza to, że możesz przyjąć, że jeśli nie zgłosili uwag do dokumentu definiującego projekt, to zatwierdzili go - innymi słowy: przyjęli do akceptującej wiadomości. Wyślij do nich kopię Definicji Projektu. Powiadom ich, że chcesz aby przejrzeli dokument i odesłali swoją opinię, szczególnie, jeśli mają pytania lub wątpliwości. Wyznacz termin odesłania uwag z jednoczesnym poinformowaniem, że brak odpowiedzi w zadanym terminie uznasz za jednoznaczne z brakiem uwag. Jeśli będą mieli jakieś pytania, skieruj ich do sponsora projektu. Ważne jest, aby osoby te otrzymały wstępną wersję dokumentu i miały czas na odpowiedź. Wszystkie wątpliwości dotyczące Definicji Projektu powinny być rozwiane przed wysłaniem ostatecznej wersji do końcowego formalnego zatwierdzenia. Nie dopuść, aby wątpliwości i uwagi tej grupy interesariuszy opóźniały proces zatwierdzania już po przekazaniu finalnej wersji do sponsora.
Inne
zainteresowane strony. Prześlij im kopię Definicji Projektu, wyraźnie zaznaczając, że dokument jest przekazywany jedynie w celach informacyjnych. Nie wysyłaj im dokumentu do akceptacji. Zarezerwuj sobie czas na wyjaśnienie im wszelkich wątpliwości, aby lepiej mogli zrozumieć zawartość dokumentu. Jednak nie dokonuj już żadnych zmian. Jeśli pojawią się poważne wątpliwości, osoba która je wnosi, powinna udać się bezpośrednio do sponsora.
1.2.P7 Ustanowienie zasady potrójnego ograniczenia (Triple Constraint) po zatwierdzeniu Definicji Projektu Efektem realizacji definiowania i planowania pracy (proces 1 i 2) jest uzyskanie ze sponsorem porozumienia co do pracy jaka jest do wykonania, kosztów oraz czasu trwania pracy. Te trzy główne składniki utworzą tzw. ”potrójne ograniczenie”. Głównym założeniem potrójnego ograniczenia jest to, że jeśli jeden z czynników ulegnie zmianie, przynajmniej jeden - jeśli nie dwa pozostałe - muszą również ulec zmianie. (Potrójne ograniczenie jest opisywane na kilka sposobów. Koszty mogą być zastąpione pracochłonnością, co ma sens, jeśli koszty pracy są tylko wewnętrzne i nie ma żadnych kosztów nie związanych z pracą. Czasami zakres zastępowany jest jakością i wtedy skupia się on na uzyskaniu właściwego poziomu jakości dla danych kosztów i czasu trwania. Jest to nieco węższy zakres potrójnego ograniczenia, ale ogólna zasada pozostaje taka sama).
84
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ko sz t
ia an t rw as Cz
Pojęcie to można łatwo wizualizować – potrójne ograniczenie to trójkąt, na którego bokach opisane są kolejno: koszt, czas trwania oraz zakres pracy.
Zakres pracy
Cz a
st
Ko sz t
Jeśli zakres pracy poszerza się, koszty i / lub data zakończenia muszą również wzrosnąć. - Jeśli masz więcej pracy do wykonania, wzrośnie również koszt (pracochłonność) i być może wydłuży czas trwania pracy. (Podobnie, jeśli zredukujesz zakres pracy, koszt (pracochłonność) i / lub czas powinien również się zmniejszyć).
rw a
ni a
Zakres pracy
a Cz
n oś
ie
nia le ma
s Ko
r zt
wa s tr je
Jeśli zostaniesz poproszony o przyspieszenie projektu i zakończenie go wcześniej niż planowano, logiczne będzie wnioskowanie o zredukowanie pracy. Jeśli jednak będziesz miał dostarczyć tę samą pracę w krótszym czasie – wartość opisana na trzecim boku musi się zwiększyć, aby utrzymać równowagę. Jest to zasadne, gdyż będziesz musiał zwiększyć koszt (pracochłonność), zabezpieczając pracę w nadgodzinach lub wykorzystując więcej zasobów, aby zakończyć pracę wcześniej.
Zakres pracy bez zmian
1.2.P8 Scalenie całej dokumentacji zarządzania projektem w plan zarządzania projektem Plan zarządzania projektem to wewnętrzny przedmiot dostawy, który zbiera różnego rodzaju dokumenty zarządzania projektem utworzone w wyniku procesów 1.0 Definiowanie Projektu oraz w 2.0 Budowanie harmonogramu i budżetu. Warto tu zauważyć, że każdy z tych dokumentów może istnieć oddzielnie. Plan zarządzania projektem zawiera następujące dokumenty:
Definicja Projektu (Project Chart); Role i odpowiedzialności, itp.; harmonogram, Struktura Podziału Pracy; Plan Zarządzania Projektem; Plan Zarządzania Zakresem, Plan operacyjny oraz Plan zarządzania kosztami; 85
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Plan Zarządzania Jakością, Plan Zarządzania Personelem; Plan Komunikacji, Plan Zarządzania Ryzykiem; Procedury zatwierdzania projektu; Inne dokumenty związane z zarządzaniem projektem. Plan zarządzania projektem może mieć formę jednolitego dokumentu / katalogu. Możesz na przykład ustalić, że w jednym segregatorze będziesz przechowywał wszystkie dokumenty i to będzie właśnie twój Plan zarządzania projektem. Możesz też utworzyć na serwerze specjalny katalog o nazwie Plan zarządzania projektem i w nim przechowywać wersje elektroniczne. 1.2.P9 Zrozumienie wyrażonych i rzeczywistych potrzeb Definicja Projektu szczegółowo opisuje projekt. Opisuje potrzeby klienta, jak również estymacje pracochłonności, czasu trwania oraz kosztów koniecznych do zaspokojenia tych potrzeb. Potrzeby klienta definiowane są bardziej szczegółowo poprzez zbieranie wymagań biznesowych. W wielu przypadkach na początku projektu klient nie wie czego chce, nie jest świadomy swoich rzeczywistych potrzeb. Te, wyrażone przez niego, stanowią podstawę Definicji Projektu i wymagań biznesowych, często nie są zbieżne z potrzebami rzeczywistymi, które mogą ewoluować w trakcie realizacji projektu. Ważne jest, aby kierownik projektu i zespół projektowy był tego świadomy. Może też być tak, że klient doskonale wie czego chce, ale nie umie tego wyrazić. Klient jednak ma prawo do zmiany swoich wymagań w trakcie prowadzenia prac projektowych – zmiany te obsługiwane są przez proces zarządzania zmianami zakresu. Co zespół projektowy może zrobić z wyrażonymi przez klienta potrzebami? Uzyskać bazując na nich zatwierdzenie Definicji Projektu i sformułowanych wymagań biznesowych. Należy pamiętać, że zespół projektowy powinien dołożyć wszelkiej staranności, aby zidentyfikować rzeczywiste potrzeby klienta. W tym celu można wykorzystać takie techniki jaki jak: zadawanie pytań, zebranie informacji od wszystkich głównych interesariuszy i ponowne zadawanie pytań klientowi, jeśli sformułowane wymagania nie brzmią sensownie, itp. Im potrzeby rzeczywiste będą bliższe wyrażonym przez klienta, tym lepiej zrealizujesz projekt! 1.2.P10 Utworzenie odrębnego projektu mającego zdefiniować pracę w projekcie – Discovery Project. Definiowanie Projektu w dużych projektach lub programach ma tendencję do przedłużania się i rozmywania. Często zabiera tak dużo czasu, że samo w sobie mogłoby stanowić odrębny projekt. Dlatego zasadnym jest czasem uruchomienie oddzielnego projektu, zwanego Discovery Project. Ma on na celu zdefiniowanie projektu jaki chcesz zrealizować i utworzenie jego harmonogramu. Dla lepszego zrozumienia (rozdzielenia Discovery Project od projektu definiowanego) przyjmijmy w tym paragrafie, że Discovery Project powołamy dla zdefiniowania i zaplanowania Programu. Głównym przedmiotem dostawy Discovery Project jest kompletna Definicja Programu, Plan zarządzania programem i harmonogram programu. Wszystkie główne biznesowe przedmioty dostaw zostaną wytworzone w wyniku realizacji Programu, o ile jego 86
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Definicja (wytworzona podczas Discovery Project) zostanie zaakceptowana i prace uruchomione. Discovery Project mogą mieć różną wielkość. Po przeprowadzeniu estymacji czasu trwania i pracochłonności, będziesz mógł zaklasyfikować Discovery Project jako projekt mały, średni, a nawet duży. Pamiętaj, że klasyfikujesz nie Program, ale poprzedzający go Discovery Project. Jeśli Discovery Project wydaje się mały, możesz opisać go stosując Zlecenie Usługi i zarządzać nim jak małym przedsięwzięciem. Jeśli zdaje się, że na planowanie Programu poświęcisz więcej czasu, Discovery Project powinna opisywać Skrócona Definicja Projektu, a przy zarządzaniu powinieneś korzystać z procesów i technik dla średniego projektu. Jeśli na zaplanowanie projektu należy poświęcić bardzo dużą ilość czasu już sam Discovery Project może być dużym projektem, a przy zarządzaniu powinieneś korzystać z procesów i technik dla dużego projektu. W chwili zakończenia Discovery Project powinny być utworzone następujące dokumenty: Definicja Programu, Plan zarządzania Programem oraz Harmonogram Główny Programu. Proces zatwierdzania tych dokumentów powinien stanowić część Discovery Project. Po zatwierdzeniu Program może zostać uruchomiony w każdej chwili. Ponieważ, w wyniku realizacji Discovery Project, faza planowania została wykonana, można rozpocząć zarządzanie planem operacyjnym i budżetem (proces 3.0).
87
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.1 Definiowanie Projektu / Zamierzenia i cele
1.2.1.P1 Terminy zamierzenia (golas) i cele (obiectives) nie są definiowane w sposób ścisły przez żadną dyscyplinę naukową. Ujęcie TenStep bazuje na praktycznym ich rozumieniu oraz prakseologicznych podstawach. Zamierzenia (ang. golas, zwane często celami strategicznymi) to ogólne określenia, pozwalające zrozumieć co ma być osiągnięte w wyniku realizacji projektu, z punktu widzenia całej organizacji. Teoretycznie powinny one pokazywać związek projektu ze strategią oraz konkretnymi procesami biznesowymi. Jednak w praktyce dość często firma nie dysponuje spisaną strategią i aktualnym opisem procesów, stosowanym w codziennej pracy. Cele (objectives) to określenia szczegółowe, opisujące namacalne efekty, przedmioty dostaw wytworzone w wyniku projektu, stan jaki chcemy osiągnąć po zrealizowaniu projektu.9 1.2.1.P2 Zamierzenia biznesowe TenStep nie używa terminu “zamierzenia projektu”. Zamierzenia odnoszą się do poziomu organizacji, cele zaś do projektu. Zamierzenia to określenia, opisujące to co mamy uzyskać poprzez projekt z perspektywy biznesu, np. “zwiększenie ogólnego poziomu zadowolenia klientów dzwoniących do call center". Ponieważ zamierzenia odnoszą się do korzyści biznesowych w sposób ogólny, w praktyce często okazuje się, że do ich osiągnięcia konieczna jest realizacja więcej niż jednego projektu. W zilustrowanym wyżej przykładzie, dla zwiększenia satysfakcji klientów kluczowymi mogą okazać się: czynnik technologiczny, procedury, poziom wiedzy odbierających telefony, reorganizacja helpdesku, czy modyfikacja systemu nagród w firmie. A zatem aby zamierzenie było zrealizowane najprawdopodobniej trzeba będzie zrealizować więcej projektów. Zamierzenia powinny ściśle pokazywać spodziewane korzyści biznesowe np.: odnosić się do kosztów, szybkości i / lub jakości etc. W przykładzie nacisk położony jest na jakość serwisu, prawdopodobnie dlatego, że ma ona związek z jakimiś współczynnikami biznesowymi (lojalność klientów, współczynnik odejść etc.). Nawet, jeśli projekt nie wspiera biznesu bezpośrednio, powinien istnieć związek pośredni. Na przykład, infrastruktura informatyczna projektu związana z instalacją nowych serwerów może w dalszej perspektywie przyspieszyć reakcję na potrzeby klienta, zwiększyć wydajność lub wpłynąć na inne korzyści biznesowe. Jeśli projekt nie przynosi wartości biznesowej, to taki projekt nie powinien być uruchamiany. Jeśli możesz zmierzyć czy zamierzenie zostało osiągnięte, to prawdopodobnie jest ono określone zbyt szczegółowo i jest bardziej celem operacyjnym. Jeśli zamierzenie nie zostanie osiągnięte poprzez kilka projektów, poziom opisu jest prawdopodobnie zbyt ogólny. W powyższym przykładzie można przewidzieć jeden lub dwa projekty, dzięki którym można zwiększyć poziom satysfakcji klienta. Zrealizowanie zamierzenia, którego celem jest uzyskanie najwyższego stopnia zadowolenia klienta, nie jest możliwe do osiągnięcia przez żaden pojedynczy projekt. Może stanowić wskazanie właściwego ogólnego kierunku, ale może nigdy nie zostać osiągnięte.
88
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ważne jest zrozumienie zamierzeń biznesowych, nawet jeśli nie stanowią one części Definicji Projektu. Zamierzenia są ważniejsze z perspektywy prowadzenia biznesu. Kierownik projektu musi rozumieć zamierzenia biznesowe, które mają zostać osiągnięte dzięki realizacji projektu. Nie istnieją zamierzenia projektu - istnieją cele projektu. 1.2.1.P3 Cele projektu Cele opisują stan, jaki ma być osiągnięty dzięki realizacji projektu. Cele powinny być opisane szczegółowo, aby była możliwa ocena stopnia ich realizacji. (Zamierzenia pozostawia się w pewnym stopniu niedookreślone.) Dobre cele operacyjne są skonkretyzowane i prosto wyrażone, dadzą się zmierzyć, są atrakcyjne, realistyczne i określone w czasie (Simple, Measurable, Attractive / Achievable, Realistic and Timebound (SMART). (SMART jest techniką służącą określeniu danego celu. Cel niekoniecznie musi spełniać całą zasadę SMART, aby uznać go za ważny. Z pewnością – musi być mierzalny i określony w czasie) Przykładem zapisu celu operacyjnego może być: "usprawnienie systemu telefonicznego helpdesk do 31 grudnia – czas oczekiwania przez klienta na uzyskanie połączenia nie powinien przekraczać dwóch minut".
Zauważ, że opis celu jest bardziej konkretny i specyficzny niż opis zamierzenia. Cel można zmierzyć – czasem oczekiwania przez klienta na połączenie w usprawnionym systemie helpdesku.
Możesz
założyć, że cel jest ambitny, ale i możliwy do wykonania oraz realistyczny.
Cel ma określone ramy czasowe – realizacja powinna zostać zakończona do 31
grudnia. Cele powinny wprost nawiązywać do przedmiotów dostaw projektu, choć nie są opisem ich cech. Jeśli nie można określić przedmiotów dostaw, które gwarantują osiągniecie danego celu, oznacza to, że cel został opisany zbyt ogólnie. Z drugiej jednak strony, jeśli cel opisuje cechy charakterystyczne danego przedmiotu dostawy, to jego opis jest zbyt szczegółowy. Jeśli zawiera cechy i opisy funkcjonalność, to jest to wymaganie biznesowe, a nie cel (requirements). Jeśli projekt jest częścią programu, cele projektu powinny być zbieżne z celami programu. 1.2.1.P4 Znaczenie celu Cele są istotne, gdyż pokazują, że kierownik projektu i sponsor osiągnęli porozumienie odnośnie głównej idei, jakiej służy realizacja projektu. Czasem może zdarzyć się tak, że poszczególne przedmioty dostaw projektu mogą być niezrozumiałe dla sponsora, ze względu na to, że są częścią jakiegoś złożonego procesu technologicznego, wynikają z jakichś zawiłych kwestii technicznych lub prawnych. Ale cele projektu muszą być opisane językiem prostym i zrozumiałym dla wszystkich zainteresowanych, by pokazywały precyzyjnie do czego chcemy dojść po zakończeniu prac.
89
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.1.P5 Definiowanie celów przed uruchomieniem projektu Cele projektu oraz zamierzenia biznesowe powinny być zdefiniowane i uzgodnione przed rozpoczęciem projektu. Przedmioty dostaw projektu są tworzone w oparciu o nie. W wielu projektach łatwiej jest zidentyfikować wytwarzane przedmioty dostaw niż realizowane przez nie cele. W takim przypadku ustal ze sponsorem dlaczego te przedmioty dostaw mają być wytworzone. Odpowiedź na to pytanie powinna pomóc w odkryciu celów projektu, a wtedy upewnij się, że cele współgrają z zamierzeniami biznesowymi. Jeśli zidentyfikujesz, że dostarczane są przedmioty dostaw, których nie można powiązać ani z celami projektu, ani z zamierzeniami biznesowymi, poważnie zastanów się dlaczego ta praca jest wykonywana. Dobrym sposobem na zdefiniowanie celów i równoczesne konsensusu jest spotkanie wszystkich głównych interesariuszy.
90
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
osiągnięcie
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.2 Definiowanie Projektu / Role
i odpowiedzialności 1.2.2.P1 Projekty różnych wielkości wymagają różnej organizacji pracy. W małych projektach prosta struktura organizacyjna wystarczy. Może się składać z głównego sponsora, kierownika projektu oraz zespołu projektowego, lub tylko z kierownika projektu i sponsora projektu. W większych projektach zaangażowanych jest więcej osób. I jest bardzo ważne, aby osoby te rozumiały czego się od nich oczekuje i jaką rolę mają do wypełnienia. W niniejszej sekcji opisano niektóre powszechnie występujące w projektach role.
Interesariusze
Dostawcy
Klienci Sponsor Użytkownicy
Klienci (Clients). Są to osoby (lub grupy osób), będących bezpośrednimi beneficjentami produktu wytworzonego przez projekt. To dla nich projekt zostaje podejmowany. Inne określenie klientów to konsumenci. W metodyce TenStep są oni jednak nazywani klientami.
Kierownik projektu po stronie klienta (Client Project Manager). Jeśli projekt
jest wystarczająco duży, klient może wyznaczyć kierownika projektu po swojej stronie. Na przykład w projekcie informatycznym, kierownik projektu będzie odpowiedzialny za kompletne rozwiązania informatyczne. Jednak po stronie klienta mogą istnieć projekty, które wspierają realizację tego przedsięwzięcia. Odpowiedzialny za nie będzie kierownik projektu po stronie klienta. Kierownik projektu informatycznego oraz kierownik projektu po stronie klienta będą ze sobą współpracować w celu stworzenia i wdrożenia pełnego rozwiązania. Kierownik projektu po stronie klienta jest zazwyczaj wyznaczany przez sponsora i jest odpowiedzialny za:
91
Zarządzanie wszystkimi projektami po stronie klienta w celu zapewnienia wsparcia w budowie końcowego rozwiązania.
Zapewnienie niezbędnych zasobów po stronie klienta, w tym zebranie wymagań, zapewnienie gotowości użytkowników do przeprowadzenia testów i odbycia szkoleń.
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Modyfikowanie i wdrażanie po stronie Klienta wymaganych procesów i procedur postępowania w celu wsparcia przyjętego rozwiązania.
Zabudżetowanie zasobów po stronie klienta.
Kierownik
funkcyjny / obszaru funkcjonalnego (Functional Manager). Kierownik funkcyjny jest osobą, do której składa się raporty wewnątrz danej organizacji funkcyjnej. Jest to zazwyczaj osoba, która dokonuje sprawdzenia wydajności pracowników. Kierownik projektu może również pełnić funkcję kierownika funkcyjnego (ale nie musi). Sytuacja, gdy kierownik funkcyjny nie jest tą samą osobą co kierownik projektu jest charakterystyczna dla organizacji macierzowej.
Kierownik
programu (Program Manager). Kierownik programu zarządza programem, kieruje ogólnym planowaniem, dostarcza wytycznych dotyczących realizacji projektów wchodzących w skład programu, rozstrzyga kwestie sporne dotyczące zakresu projektów programu, wszyscy kierownicy projektów raportują do niego.
Dyrektor projektu (Project Director). W metodyce
rola ta jest przypisana do przełożonego kierownika projektu. Jego odpowiedzialność jest elastyczna i powinna zostać zdefiniowana w procesie Definiowania pracy. Istnienie roli dyrektora projektu wskazuje, że w wielu organizacjach kierownik projektu nie ponosi całkowitej odpowiedzialności za zarządzanie gwarantujące osiągnięcie sukcesu przez projekt. Zazwyczaj przełożony funkcyjny kierownika projektu też odgrywa pewną rolę przy zapewnieniu zasobów, pomaga w rozwiązywaniu trudnych problemów krytycznych, zajmuje się polityką organizacyjną, itp.
Kierownik projektu (Project Manager).
Jest to osoba posiadająca uprawnienia do zarządzania projektem, w tym kierowanie procesem planowania oraz wytworzenia wszystkich przedmiotów dostaw. Kierownik projektu jest odpowiedzialny za zarządzanie budżetem, Planem operacyjnym oraz nadzór nad stosowaniem procedur zarządzania projektem (zarządzanie zakresem, kwestiami krytycznymi (Issues), ryzykiem, itp.). Więcej szczegółów znajdziesz w rozdziale 1.0.4 Rola kierownika projektu.
Zespół projektowy (Project Team). Członkowie zespołu projektowego mogą być zatrudnieni w projekcie na cały lub część etatu. Zespół jest odpowiedzialny za:
Tworzenie przedmiotów dostaw projektu
Informowanie kierownika projektu o sprawach związanych z kwestiami krytycznymi, zmianami zakresu, ryzykiem oraz jakością
Proaktywne komunikowanie i wypełnianie stawianych im oczekiwań.
Zrozumienie pracy, którą należy wykonać Planowanie przydzielonych zadań bardziej szczegółowo - jeśli konieczne Realizowanie przydzielonej pracy z zachowaniem budżetu, terminów oraz zadanej jakości
Zespół projektowy może składać się z pracowników jednego pionu organizacyjnego lub z wielu różnych pionów organizacyjnych firmy. Zespół międzywydziałowy jest
92
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
charakterystyczny dla organizacji o strukturze macierzowej. Członkowie zespołu projektowego stanowią odrębną grupę interesariuszy.
Kierownik
ds. jakości (Quality Manager). W przypadku dużych projektów zarządzanie jakością może zająć znaczną część czasu przeznaczonego na zarządzanie projektem. W takim przypadku warto wyznaczyć kierownika ds. jakości, który będzie odpowiedzialny za sporządzenie planu jakości, utworzenie procedur kontroli i zapewnienia jakości oraz sprawdzanie czy są one przestrzegane, za udzielanie wsparcia członkom zespołu w rozwiązywaniu problemów krytycznych związanych z jakością.
Kierownik
ds. ryzyka (Risk Manager). W dużych projektach zarządzanie ryzykiem może stanowić znaczną część pracy kierownika projektu. Może być zasadne wyznaczenie osoby, która zajmie się koordynowaniem procesu zarządzania ryzykiem. Kierownik projektu będzie w dalszym ciągu odpowiedzialny za ryzyka projektowe, jednak to kierownik ds. ryzyka będzie kontrolował proces identyfikacji, klasyfikacji oraz określania wagi ryzyka, jak również monitorowanie Planu zarządzania ryzykiem, aby zapewnić jego prawidłowe wykonanie.
Sponsor (sponsor oraz sponsor zarządzający). Sponsor jest osobą posiadającą
najwyższą władzę w projekcie. Sponsor zapewnia finansowanie projektu, rozwiązuje kwestie krytyczne oraz zmiany zakresu, zatwierdza główne przedmioty dostaw i dostarcza ogólne wytyczne. Odpowiada również za projekt w danej organizacji. W zależności od projektu oraz pozycji sponsora w strukturze organizacji, może delegować codzienne swoje obowiązki sponsorskie na sponsora zarządzającego. Jeśli zostanie wyznaczony sponsor zarządzający, to reprezentuje on sponsora w zwykłych sprawach i podejmuje większość decyzji wymagających zgody sponsora. Jeśli decyzja jest zbyt poważna, sponsor zarządzający przekaże ją do sponsora do dokonania wyboru. Dodatkowo sponsor:
Definiuje cele biznesowe projektu; Reprezentuje interesy projektu na wyższym szczeblu kierownictwa; Decyduje, czy projekt zakończył się sukcesem. Jeśli projekt nie
był w pełni
udany, sponsor określa stopień powodzenia;
Uzyskuje aprobatę co do wydatków; Monitoruje postępy projektu; Monitoruje środowisko biznesowe, aby
upewnić się, że projekt nadal spełnia
potrzeby biznesowe;
Przewodniczy komitetowi sterującemu, jeśli takowy istnieje. Sponsor jest właścicielem projektu oraz wytworzonych przez niego rozwiązań. Kierownik projektu jest odpowiedzialny za udane wykonanie projektu, natomiast sponsor jest odpowiedzialny za dostarczenie korzyści biznesowych organizacji.
Interesariusz (Stakeholder). Osoba lub grupa osób, która ma udział lub interes w wynikach projektu. Zazwyczaj interesariusze to członkowie organizacji. Mogą to być członkowie zespołu projektowego, klienci wewnętrzni, kierownictwo, pracownicy, administratorzy, itp. Z projektem mogą być również związani
93
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
interesariusze zewnętrzni – tacy jak dostawcy, inwestorzy, grupy społeczne bądź organizacje rządowe.
Komitet
sterujący (Steering Committee). Komitet sterujący jest grupą interesariuszy najwyższego szczebla, odpowiedzialnych za przekazywanie wytycznych odnośnie ogólnego kierunku strategii. Rola ta może być przejęta przez sponsora, jednak w przypadku, gdy projekt przebiega w poprzek organizacji, sponsor może nie chcieć podejmować wszystkich decyzji - komitet sterujący może składać się z przedstawicieli różnych pionów organizacyjnych, na które wpływa projekt. Komitet sterujący nie przejmuje uprawnień sponsora, lecz pomaga rozszerzyć jego perspektywę patrzenia na aspekty strategiczne związane z projektem oraz zaangażowanie większej części organizacji. W skład komitetu sterującego wchodzić bezpośredni klienci i pośredni interesariuszy.
Dostawcy
(Suppliers / Vendors). Pomimo tego, że firmy mogą posiadać wewnętrznych dostawców, termin „dostawcy” TenStep zawsze odnosi do zewnętrznych firm lub osób dla nich pracujących. Mogą to być podwykonawcy pracujący pod kierownictwem twojej firmy, lub zapewniający materiały, sprzęt, podzespoły komputerowe, oprogramowanie, itp. W zależności od ich roli, mogą być ujęci w schemacie organizacyjnym projektu lub nie. Przykładowo, jeśli dostawca jest partnerem w tworzeniu krytycznego komponentu – może być ujęty w schemacie. Jeśli jest to dostawca oferujący ogólnie dostępny sprzęt - nie stanowi część zespołu.
Użytkownicy (Users). Są to osoby, które będą faktycznie użytkować przedmioty
dostaw projektu. Czasami są bardzo zaangażowani w projekt – w działania związane z określeniem wymagań biznesowych. Ale mogą też nie być zaangażowani aż do chwili testowania rozwiązań. Czasami określenie użytkowników wypracowanego rozwiązania jest ważne ze względu na konieczność przypisania im pewnych odpowiedzialności. Użytkownikami mogą być pracownicy klienta lub osoby spoza jego organizacji. Na przykład, jeśli dana firma wdraża system rejestracji czasu pracy, klientem projektu będzie Dział Kadr. Jednakże użytkownikami będą pracownicy każdej komórki organizacyjnej, która objęta będzie działaniem tego systemu.
94
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.3 Definiowanie Projektu / macierz odpowiedzialności
1.2.3.P1 W dużych projektach w proces tworzenia i zatwierdzania przedmiotów dostaw może być zaangażowana duża grupa osób. Czasami jest to bardzo proste – jedna osoba tworzy dokument, inna go zatwierdza. Ale może być tak, że przedmiot dostawy wytwarzany jest przez wiele osób. Również zatwierdzanie odbywa się przez różne osoby o różnych uprawnieniach. W takim przypadku pomocnym może być utworzenie macierzy odpowiedzialności dla przedmiotów dostaw. Macierz pozwala na usystematyzowanie oczekiwań wobec osób pełniących poszczególne role w projekcie. Na przykład chcesz sprawdzić, czy członkowie komitetu sterującego muszą zatwierdzać dokument definiujący wymagania biznesowych (Business Requirements). Macierz może opisać każdą rolę. W kolumnach zapisano role w projekcie, w wierszach poszczególne przedmioty dostaw. Odpowiedzialność roli biznesowej względem przedmiotu dostawy określa komórka leżąca na przecięciu kolumny i wiersza.
Sponsor projektu
Dyrektor projektu
Kierownik projektu
Zespół projektowy
Komitet kierujący
Definicja Projektu
A
A
C
R
A
Plan komunikacji
A
R
C
R
A
Wymagania biznesowe
A
R
R
C
A
Raporty stanu
R
R
C
R
R
“A” oznacza, że dana osoba (rola) zatwierdza przedmiot dostaw. “R” oznacza, że dana osoba (rola) dokonuje recenzji przedmiotu dostawy. “C” oznacza, że dana osoba (rola) wytwarza przedmiot dostawy. Zazwyczaj jest tylko jedna osoba odpowiedzialna za wytworzenie przedmiotu dostawy, pomimo że wiele osób może dostarczać wsad. W powyższej tabeli Definicja Projektu tworzona jest przez kierownika projektu, zatwierdzana przez sponsora projektu, dyrektora projektu oraz komitet sterujący, recenzowana przez zespół projektowy. Wymagania biznesowe tworzone są przez zespół projektowy, weryfikowane przez kierownika i dyrektora projektu, a zatwierdzane przez sponsora projektu i komitet sterujący. Celem macierzy jest określenie odpowiedzialności poszczególnych ról w odniesieniu do przedmiotów dostaw. Ma ona pomóc w uzyskaniu jasności i porozumienia odnośnie tego kto co robi, odzwierciedlając tak dużo szczegółów jak to konieczne. Na przykład „zespół projektowy” mógłby być opisany w dwóch kolumnach: osoba
95
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
odpowiedzialna za zdefiniowanie (wytworzenie) wymagań biznesowych i pozostali członkowie zespołu projektowego. Po utworzeniu matrycy należy ją przedstawić do zatwierdzenia. Jeśli zostanie to wykonane na etapie definiowania pracy, można ją dodać jako załącznik do Definicji Projektu. Jeśli matryca została stworzona w trakcie fazy analizy, powinna być rozesłana jako odrębny dokument. Najważniejszą cechą dobrej macierzy odpowiedzialności jest przejrzystość. Musi ona odzwierciedlać oczekiwania i zadania osób. Na przykład, jeśli sponsor deleguje zatwierdzenie jakiegoś dokumentu na podwładnego, powinno to być wyraźnie pokazane w macierzy. Szczególnie, gdy chce by w jakichś przypadkach sam mógł zdecydować o zatwierdzeniu tego dokumentu. Przykłady innych oznaczeń odpowiedzialności opisano poniżej. Możesz w swoim projekcie zdefiniować własny kod oznaczeń. Pamiętaj tylko o wyjaśnieniu jego znaczenia pozostałym uczestnikom projektu.
A – zatwierdza przedmioty dostaw R – przegląda i recenzuje przedmioty dostaw (dostarcza informacji zwrotnej) C – tworzy przedmiot dostawy (może się pojawić C (1) dla podstawowego, C (2) dla pomocniczego)
I – dostarcza wsad N – jest informowany o zakończeniu pracy nad przedmiotem dostawy
96
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.4 Definiowanie Projektu / Organizacja projektu
1.2.4.P1 Sposób, w jaki zorganizowany jest zespół projektowy jest bezpośrednio związany ze strukturą całej organizacji. Istnieją trzy główne struktury organizacyjne. 1.2.4.P2 Funkcjonalna W organizacji funkcjonalnej, zespół projektowy składa się z pracowników z tego samego działu. Wszystkie zasoby, których potrzebuje zespół projektowy pochodzą z konkretnej jednostki organizacyjnej. Dla przykładu, jeśli projekt jest związany z finansami, zasoby projektu pochodzą z Działu finansowego. Jeśli w danym projekcie potrzebne są zasoby informatyczne, finansowe i prawne, będą one dostępne z Działu finansowego. Drugim sposobem zdobywania pracowników dla projektu w organizacji funkcjonalnej jest wykonywanie poszczególnych części projektu w przez różne jednostki organizacyjne w tym samym czasie. Na przykład, duży projekt potrzebuje zasobów z działu finansowego, zakupów, informatycznego oraz z produkcji. W organizacji funkcjonalnej projekt zostałby rozbity w oparciu o jednostki organizacyjne i każda z nich wykonywałaby swoją część stosunkowo niezależnie. Dział informatyczny wykonywałby swoje zadanie. finansowy swoje, a produkcja i zakupy swoje. Pod koniec wszystkie niezależne rozwiązania zostałyby zintegrowane w jedno końcowe rozwiązanie. Największą zaletą projektów o organizacji funkcjonalnej jest fakt, że istnieje tam określone zwierzchnictwo. Kierownik projektu jest zazwyczaj również kierownikiem funkcyjnym. Nie ma również konieczności negocjowania z innymi jednostkami organizacyjnymi spraw związanych z zasobami - pochodzą z tej samej komórki organizacyjnej. Inną zaletą tego typu organizacji projektu jest to, że członkowie zespołu znają się - wszyscy pracują w tej samej komórce. Członkowie zespołu wnoszą również pewien zasób wiedzy o projekcie. Główną wadą organizacji funkcjonalnej jest fakt, iż dany obszar funkcjonalny może nie posiadać wszystkich specjalistów do realizacji projektu. Projekt finansowy z elementami informatycznymi, na przykład może mieć trudności z uzyskaniem właściwych zasobów informatycznych takich jak administratorzy bazy danych - jedyni dostępni pracownicy mogą być zaangażowani w pracę w swoim dziale. Kolejną wadą jest to, że członkowie zespołu projektowego mogą mieć inne obowiązki. Ponieważ może nie być potrzeby zaangażowania ich na cały etat do projektu, mogą zostać wyznaczeni do pracy w innych projektach. Zazwyczaj będą pełnić funkcję wspierającą, aby projekt zakończył się w terminie. 1.2.4.P3 Projektowa W przypadku bardzo dużych projektów korzystne jest utworzenie działów funkcjonalnych w ramach zespołu projektowego. Jest to szczególnie pomocne, gdy duże programy angażują setki ludzi przez długi okres. Zaletą jest to, że kierownik projektu jest również kierownikiem funkcyjnym. Pozwala to koncentracja na projekcie. Dla każdego członka zespołu projekt stanowi pierwszoplanowe zadanie. Jedną z wad jest podwajanie zasobów, gdyż niewystarczające zasoby muszą być duplikowane w różnych projektach. Przykładowo duży projekt może mieć swój własny dział kadr, który może duplikować centralny dział kadr. Mogą się również pojawić
97
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
niejasności co do relokacji ludzi oraz zasobów po zakończeniu projektu. W organizacji funkcjonalnej pracownicy w dalszym ciągu będą mieli prace w swoim dziale. W organizacji czysto projektowej nie jest jasne, gdzie zostaną przydzieleni po zakończeniu projektu. 1.2.4.P4 Macierzowa Organizacja macierzowa pozwala danym jednostkom funkcjonalnym skupić się na konkretnych kompetencjach biznesowych. Do projektów pozyskuje się specjalistów z całej organizacji. Na przykład administratorzy baz danych mogą raportować do jednego działu funkcjonalnego, ale zostaną przydzieleni do różnych projektów w innych działach. Prawnicy mogą zgłaszać się do Działu prawnego, ale zostaną przydzieleni do projektu w dziale, który potrzebuje ekspertyzy prawnej. Zazwyczaj pracownicy raportują do jednej osoby funkcyjnej, chociaż pracują dla jednego lub dwóch kierowników projektu z innych działów. Główną zaletą organizacji macierzowej jest wydajna alokacja zasobów. Szczególnie tych rzadkich, które nie mogą być w pełni wykorzystane tylko przez jeden projekt. Na przykład specjaliści od modelowania danych mogą nie być wykorzystywani na cały etat tylko przez jeden projekt, ale wykorzystanie ich przy wielu projektach da cały etat. Organizacja macierzowa jest również najbardziej elastyczna w przypadku zmiany potrzeb i priorytetów biznesowych. Główną wadą jest złożony proces raportowania. Niektóre osoby mogą raportować do kierownika funkcyjnego, dla którego wykonują tylko niewielką ilość pracy, a faktycznie pracują dla jednego lub więcej kierowników projektów. Istotne dla pracowników staje się rozwijanie umiejętności zarządzania czasem, aby móc spełnić oczekiwania różnych kierowników. Organizacja macierzowa wymaga również komunikacji i współpracy pomiędzy wieloma kierownikami funkcyjnymi i kierownikami projektów, wykorzystujących te same zasoby.
98
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.2.5 Definiowanie Projektu / Analiza interesariusza
1.2.5.P1 Interesariusze to osoby lub grupy osób, która ma udział lub interes w wynikach projektu. Zazwyczaj interesariusze to członkowie organizacji. Mogą też to być klienci wewnętrzni, kierownictwo, pracownicy, administratorzy, itp. Z projektem mogą być również związani interesariusze zewnętrzni – tacy jak dostawcy, inwestorzy, grupy społeczne bądź organizacje rządowe. W małych projektach zazwyczaj nie ma potrzeby zajmowania się i zarządzania relacjami z całym środowiskiem interesariuszy. W miarę jak projekt staje się większy, grupa interesariuszy rośnie. W przypadku dużego i zróżnicowanego środowiska interesariuszy warto przeprowadzić jego analizę - możesz potrzebować ich pomocy, wsparcia lub przekazywać im informacje o postępach prac w projekcie. Analiza interesariuszy pomoże w określeniu różnych grup interesariuszy i ich roli w projekcie. Przeprowadź analizę interesariusza zgodnie z poniższym procesem. Rola 1
Proces Analizy Interesariuszy
Kierownik Identyfikacja interesariuszy projektu, Nie można przeprowadzić analizy interesariuszy bez wcześniejszego zespół rozpoznania, kim oni są. Stosując technikę burzy mózgów, przy projektowy udziale członków zespołu projektowego, dokonaj identyfikacji wszystkich możliwych interesariuszy. Poniżej wylistowano przykłady możliwych interesariuszy.
Sponsor Klient Dyrektor projektu Wyższe kierownictwo wykonawcze Zespół projektowy Użytkownicy końcowi Dostawcy Inne działy/ projekty Firmy partnerskie Osoby trzecie (dostawcy, inwestorzy,
związki, organizacje rządowe) Ważne jest, aby uznać zespół projektowy za specyficzną grupę interesariuszy. Pozwoli to kierownikowi projektu na skupienie się na jego potrzebach i upewnieniu się, że są one brane pod uwagę przez cały czas trwania projektu.
99
Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2
Kierownik Określanie ważności każdego interesariusza projektu, Przyjrzyj się każdemu interesariuszowi i określ, jak jest ważny dla zespół końcowego sukcesu projektu lub co się stanie, jeśli interesariusz nie projektowy będzie związany z projektem. Dokonaj klasyfikacji interesariuszy pod względem znaczenia – wysokie/ średnie/ niskie. Na przykład, jeśli projekt jest realizowany bez problemów, interesariusz ma małe znaczenie. Jeśli pomyślna realizacja projektu bez udziału interesariusza nie jest możliwa – prawdopodobnie jego znaczenie jest wysokie. Ocena ważności interesariusza jest istotna z tego względu, że czasami spędza się zbyt dużo czasu na pracę z intersariuszami o małym znaczeniu dla projektu, zaniedbując interesariuszy ważnych. Kolejnym obszarem wymagającym zbadania jest to jaką władzę ma interesariusz: czy może zablokować lub utrudniać rozwój projektu, czy może wpłynąć na to, by projekt rozwijał się płynnie? Dla przykładu, jeśli interesariusz nie będzie angażował się w projekt i nie wpłynie na jego rozwój - zaklasyfikujesz go jako mający małe znaczenie. Jeśli interesariusz będzie miał duży wpływ na projekt (negatywny bądź pozytywny) - zaklasyfikujesz go jako mający duże znaczenie.
3
Kierownik Określanie poziomu zainteresowania projektem każdego interesariusza projektu, zespół Stopień zainteresowania projektem każdego z interesariuszy może być projektowy różny. W niektórych przypadkach interesariusz może oczekiwać czegoś konkretnego po projekcie i chciałby być informowany o jego postępach i angażowany możliwie często. Inny interesariusz może być w niewielkim stopniu zainteresowany projektem i uzyskiwać tylko konieczne informacje. Tutaj również możesz zastosować klasyfikację zainteresowania przydzielając ich do trzech grup: duże/ średnie/ niskie.
4
Kierownik Określanie wpływu każdego interesariusza na projekt projektu, Możesz mieć długą listę osób i organizacji, których projekt będzie zespół dotyczył w różnym stopniu. Określ, jaki wpływ mają te osoby. projektowy Niektórzy interesariusze mogą zablokować projekt. Inni nie mają władzy formalnej, lecz są wpływowi. Informacje te pomogą ci w doborze sposobu komunikacji. Niektórzy mogą być zainteresowani tym co się robisz - innych może to w ogóle nie obchodzić. Pogrupuj zidentyfikowanych interesariuszy tak, aby móc określić najlepszy sposób zarządzania nimi.
5
Kierownik Zrozumienie emocjonalnego podejścia każdego z interesariuszy projektu, Zrozumienie emocjonalnego podejścia każdego interesariusza jest zespół bardzo ważne dla projektu. Musisz mieć jasność co do bieżących projektowy opinii interesariuszy i ich reakcji na projekt - czy będą wspierać projekt, czy nie? Dowiedz się co lub kto wpływa na opinie interesariuszy i wykorzystaj tę wiedzę do sformułowania planu zaangażowania.
100 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W wielu przypadkach zespół powinien poradzić sobie z określeniem stanowiska każdego z interesariuszy. Jednak w przypadku, gdy nie jest to możliwe, należy umówić się na spotkanie z danym interesariuszem i wyjaśnić sprawy bezpośrednio z nim. 6
7
Kierownik Określanie sposobu zaangażowania każdego interesariusza projektu, Określ rodzaj czynności, lub nawet ogólne podejście, jakie zostanie zespół podjęte w stosunku do poszczególnych interesariuszy, aby projektowy zaspokoić ich potrzeby. Jest oczywiste, że więcej będziesz pracował z grupą ważniejszych interesariuszy z punktu widzenia projektu –, niż z grupą interesariuszy o niższym priorytecie. Celem tego etapu jest zdefiniowanie czynności, które musi wykonać zespół, aby zaspokoić oczekiwania wszystkich interesariuszy. Z pewnością będziesz często komunikował się z wieloma z nich, dlatego wiele z tych czynności może być ujętych również w Planie komunikacji. Można skorzystać z poniższej tabeli podczas dyskusji na temat zaangażowania interesariusza.
Kierownik projektu
Znaczenie / Zainteresowanie
Styl zarządzania
Duże znaczenie i duże zainteresowanie.
Jest to najważniejsza grupa interesariuszy. Osoby te powinny być w pełni zaangażowane w projekt. Dołóż najwyższej staranności, aby poznać i spełnić ich oczekiwania.
Duże znaczenie lecz małe zainteresowanie
Poznawaj i zaspokajaj potrzeby. Nie angażuj bardzo, nie narzucaj się, zawracaj głowy, dopóki musisz.
ich za nie nie
Małe znaczenie, lecz duże zainteresowanie.
Ta grupa powinna być właściwie poinformowana. Komunikuj się z nimi regularnie, aby zapobiec narastaniu dużych problemów krytycznych. (Uwaga: grupa ta może być bardzo pomocna przy definiowaniu i planowaniu projektu).
Małe znaczenie i małe zainteresowanie.
Monitoruj tę grupę, aby sprawdzić, czy podczas trwania projektu nie zmieni się ich status. Jeśli do tego dojdzie – rozważ sposób zajmowania się nimi.
Uzyskiwanie porozumienia z interesariuszami, kiedy jest to konieczne.
101 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W wielu przypadkach, interesariusze oczekują czegoś od projektu. Czasami czegoś oczekuje się od nich - zadbaj, aby interesariusze rozumieli te oczekiwania i upewnij się, że zgadzają się na współpracę (np. dostarczenie zasobów, czasu, środków finansowych, uwag, informacji zwrotnej, itp.). 8
Kierownik projektu
Dodanie czynności do Planu operacyjnego Wszystkie zidentyfikowane czynności dodaj do harmonogramu pracy projektu. Uzupełnij osoby odpowiedzialne za ich wykonanie, ramy czasowe, szacowaną pracochłonność, itp.
102 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
1.3 Definiowanie Projektu / Podsumowanie
1.3.P1 Przedmioty dostaw: W Bibliotece TenStep dostępne są następujące formularze:
Zlecenie usługi (Service Request) Skrócona Definicja Projektu (Abbreviated Project Charter) Definicja Projektu (Project Charter) Procedury zarządzania projektem (Project Management Procedures) Lista kontrolna dla planowania (Planning Compliance Checklist) Plan projektu (Project Plan) Macierz odpowiedzialności (Responsibility Matrix) Krótka informacja o zadaniu (Simple Statement of Work) Analiza SWOT (SWOT Analysis) Dane teleadresowe zespołu (Team Directory) 1.3.P2 Harmonogram czynności Wielkość Konieczne informacje Czynność Sprawdzenie wyjaśnienie usługi
Mały
Nakład
Uwagi
i 1-2 godziny Zlecenia
Kierownik projektu sprawdza, czy rozumie pracę.
Przygotowanie ogólnej 1-4 godziny estymacji nakładów, kosztów, oraz czasu trwania.
Ocena pracy w przypadku Zlecenia usługi raczej nie trwa zbyt długo.
Przypisanie zlecenia do 1 godzina obsługi lub przesunięcie do prac oczekujących (backlog)
Jeśli zadanie ma duży priorytet, można przydzielić je do obsługi konkretnemu członkowi zespołu. W innym zostaje jako praca oczekująca w backlog .
Okresowy przegląd prac 1 godzina oczekujących
Należy sprawdzać oczekujące (backlog) klientem.
(Po przyporządkowaniu) 1-2 godziny Ocena informacji początkowych zawartych w Zleceniu usługi (Service 103 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
prace wraz z
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Request) Czynność
Nakład
Uwagi
Zebranie pod- 1-2 godziny stawowych informacji Określanie procesu 1 godzina zatwierdzania
Należy określić, kto sprawdza, zatwierdza, a kto otrzymuje do wiadomości kopię Skróconej Definicji Projektu.
Zorganizowanie Różnie spotkania z głównymi interesariuszami w celu zdefiniowania pracy
Iteracyjne Definiowanie Projektu.
Utworzenie pierwszego 2-4 godziny szkicu Skróconej Definicji Projektu
Średni
Udokumentowanie 1-3 godziny procedur zarządzania projektem (Opcjonalnie) Przekazanie weryfikacji Skróconej Projektu
Dobrze by było, gdyby istniały standardowe procedury, które są wykorzystywane w projektach w danej organizacji.
1-2 godziny do draftu Definicji
Uzupełnienie 1-3 godziny dokumentów w oparciu o zebrane opinie Zatwierdzanie Skró- 1-2 godziny conej Definicji Projektu Udostępnienie 1 godzina zatwierdzonej Skróconej Definicji Projektu wszystkim zainteresowanym
Duży
Czynność
Nakład
Zebranie podstawowych informacji
1-4 godziny
Określanie procesu zatwierdzania
2 godziny
Należy określić, kto sprawdza, zatwierdza, a kto otrzymuje do wiadomości kopię Definicji Projektu.
Zorganizowanie spotkania z głównymi interesariuszami w celu zdefiniowania pracy
Różnie
Iteracyjne Definiowanie Projektu. Czas trwania - dni lub tygodnie w zależności od wielkości projektu.
Uwagi
104 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Utworzenie pierwszego szkicu Skróconej Definicji Projektu
5-10 godzin
Udokumentowanie procedur zarządzania projektem
2-3 godziny
Dobrze by było, gdyby istniały standardowe procedury, które są wykorzystywane w projektach w danej organizacji. Dobrze by było, gdyby istniały standardowe procesy, które można dostosować do konkretnych projektów.
(Opcjonalnie) Utworzenie strategii i planu zarządzania dostawcami. (Opcjonalnie) Przekazanie do weryfikacji draftu Definicji Projektu
1-2 godziny
Uzupełnienie dokumentów w oparciu o zebrane opinie
1-3 godziny
(Opcjonalnie) Przekazanie uzupełnionych dokumentów szerszej grupie zainteresowanych osób do weryfikacji
1-3 godziny
Zatwierdzanie Definicji Projektu
1-2 godziny
Udostępnienie zatwierdzonej Definicji Projektu wszystkim zainteresowanym
1 godzina
105 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 2 Tworzenie harmonogramu i budżetu
106 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.0 Tworzenie harmonogramu i budżetu 2.0.P1 Harmonogram i budżet projektu są tworzone równocześnie z definicją projektu przedmiotem dostawy procesu 1.0. Harmonogram daje podstawy, aby upewnić się, że zespół projektowy wie, co ma zrobić. Wiele osób czuje się niepewnie przy tworzeniu harmonogramu. I jest to zazwyczaj związane z niewłaściwym zdefiniowaniem projektu. Trudno jest bowiem stworzyć dobry harmonogram, jeśli kierownik projektu nie jest tak naprawdę pewien, co projekt ma dostarczyć. Budżet przedstawia ilość funduszy przeznaczonych na dany projekt. W zależności od organizacji oraz sposobu prowadzenia księgowości, budżet może zawierać tylko zewnętrzne koszty projektu (dostawców, sprzęt komputerowy, oprogramowanie, materiały, itp.). Niektóre organizacje dołączają również do budżetu wewnętrzne koszty pracy. Organizacje te zazwyczaj rozksięgowują wewnętrznie koszty i przenoszą je na klienta lub do działu klienta, który zlecił projekt. Metodyka TenStep nie opisuje sposobu prowadzenia analiz finansowych, które są konieczne do podjęcia decyzji, czy projekt powinien zostać uruchomiony, czy też nie. Analizy finansowe mogą być bardzo proste - polegać na wyliczeniu prostych relacji kosztów do korzyści, wskaźników, np. zwrotu z inwestycji (ROI), wewnętrznej stopy zwrotu (IRR) itp. Proces uzasadniania opłacalności projektu został opisany w PortfolioStep Portfolio Management Process. W TenStep, zakłada się, że ogólna analiza finansowa oraz uzasadnienie uruchomienia projektu zostały zakończone, a projekt został wstępnie zaakceptowany. Proces 1.0 - definiowanie projektu pomaga w uzgodnieniu ze sponsorem co ma być wykonane w ramach projektu. Na etapie budowy harmonogramu i budżetu kierownik projektu określa, w jaki sposób zadania zostaną wykonane. Istnieje wiele technik tworzenia harmonogramu projektu. Najprostsze jest użycie harmonogramów już zrealizowanych projektów, jako punktu wyjścia. Jednak ze względu na to, że każdy projekt z definicji jest unikalny może być to trudne. Drugim wariantem jest szukanie wzorców dla projektów o podobnej charakterystyce (analogiczna pracochłonność, czas trwania, koszty etc. aczkolwiek przedmiot dostawy zupełnie różny). Jeśli w twojej firmie wdraża się po raz pierwszy pakiet jakiegoś oprogramowania, może być użyteczne przejrzenie harmonogramów z innych wdrożeń informatycznych. Mogą dostarczyć dość cennych wskazówek. Jeśli nie ma wcześniejszych harmonogramów projektów lub wzorców można użyć technikę Struktury Podziału Prac (WBS). WBS to technika służąca do identyfikacji pracy do wykonania. Polega ona na analizie projektu z ogólnej perspektywy, a następnie na rozbijaniu zadań na części, aż do zadań elementarnych, które należy wykonać. W tworzeniu WBS może brać cały zespół. W większości przypadków technika WBS może być używana do tworzenia harmonogramu od zera. Jeśli pracownicy wiedzą za mało, by stworzyć WBS dla projektu (lub przynajmniej dla pierwszych trzech miesięcy projektu) prawdopodobnie nie są oni na etapie, kiedy powinni rozpocząć projekt! W takim przypadku można spróbować zdefiniować i zaplanować fazę analiz, która z pewnością będą wykonywane w projekcie. Kiedy zakończona będzie już faza analizy, powinno się mieć wystarczającą ilość informacji do zdefiniowania pozostałej części pracy.
107 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.0.P2 Związek pomiędzy definiowaniem i planowaniem projektu Definiowanie projektu to proces o numerze jeden, a planowanie otrzymało numer dwa. Jednak te cyfry nie muszą oznaczać kolejności uruchamiania procesów. Zazwyczaj nie można zakończyć definicji projektu bez rozpoczęcia tworzenia ogólnego harmonogramu projektu. W wielu przypadkach muszą one być wykonywane równolegle. Zbieranie informacji dotyczących zakresu i przedmiotów dostaw będzie miało miejsce przy równoczesnym określaniu czasu przeznaczanego na projekt. Później można zacząć prace nad oszacowaniem pracochłonności i czasów trwania. W miarę budowania definicji pojawi się więcej szczegółów do harmonogramu. Kiedy zostaną zakończone przedmioty dostawy, zakres, podejście realizacyjne, założenia oraz ryzyka, powinno się mieć wystarczającą ilość informacji w harmonogramie, aby określić budżet, pracochłonności oraz czas trwania. A to jest konieczne do uzupełnienia definicji projektu. 2.1 Tworzenie Planu i budżetu / Proces 2.2 Tworzenie Planu i budżetu / Techniki 2.3 Tworzenie Planu i budżetu / Podsumowanie
108 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1 Tworzenie harmonogramu i budżetu / Proces 2.1.P1 Rozdział ten opisuje proces tworzenia harmonogramu i budżetu. Dla małego projektu harmonogram może zostać stworzony bez specjalnej formalizacji. W przypadku projektów średnich lub dużych istnieje kilka technik, które można do tego użyć. Najlepszym sposobem (jak wspomniano wcześniej) może być wykorzystanie podobnego harmonogramu z poprzedniego projektu, lub wzorca jako punktu wyjścia. Jeśli jednak takie dokumenty nie istnieją, można użyć techniki Struktury Podziału Prac (WBS). 2.1.P2 Małe projekty Zazwyczaj nie istnieją formalne procesy stosowane do tworzenia harmonogramu dla małego projektu. Projekty te są takiej wielkości, że czynności oraz ich kolejność można łatwo ułożyć w myślach. Zazwyczaj w projekt zaangażowana jest jedna lub dwie osoby, nie jest więc trudno określić, co kto ma robić. Pomimo, że łatwo jest ułożyć harmonogram, musi on zostać jakoś zapisany. Do małych projektów można wykorzystać np.: MS Project. Można również wykorzystać arkusz kalkulacyjny lub nawet zwykłą kartkę papieru. Chodzi tylko o to, aby usiąść z innymi członkami zespołu (jeśli w projekcie jest więcej niż jedna osoba) i spisać zadania, które trzeba wykonać. Spisany harmonogram ułatwi pozostałym członkom zespołu oraz klientowi zrozumienie zadań, które mają zostać wykonane. Podobnie jak harmonogram projektu tak i budżet dla małych projektów jest również łatwy do określenia. Zazwyczaj ma się do czynienia z prostą kombinacją kosztów pracy oraz kosztów nie związanych z pracą. Przy małych projektach nie pojawią się raczej inne kategorie kosztowe – szkolenia, tworzenia zespołu, etc. Jeśli posiadamy już wstępne oszacowania nakładów, kosztów oraz czasu trwania, można użyć formularz Zlecenia Usług (Service request) dla małego projektu. 2.1.P3 Średnie i duże projekty Im większy jest projekt, tym trudniejsze staje się tworzenie harmonogramu w sposób niesformalizowany. W rozdziale: 2.2. Techniki znajdują się informacje o tym. jak korzystać z harmonogramów poprzednich projektów lub z wcześniej utworzonych wzorców. Jest to zazwyczaj najlepszy i najszybszy sposób wykonania tej pracy. Jednak dla potrzeb tego rozdziału założono, że harmonogram projektu i budżet muszą być utworzone od podstaw. Najlepszym sposobem zrobienia tego jest posłużenie WBS.
109 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ogólny proces jest następujący:
Role
Tworzenie harmonogramu projektu od podstaw.
2.1.P4 Zbieranie istniejących dokumentów
1
Kierownik projektu.
Przeanalizuj definicję projektu. Zwróć szczególną uwagę na sekcje: przedmioty dostaw (okres w jakim mają być wytworzone), podejście realizacyjne, estymacje, ryzyka oraz założenia. Definicja projektu może nie być jeszcze zakończona, użyj wtedy dostępnych, najbardziej aktualnych wersji roboczych. Definicja projektu oraz inne dokumenty powinny zostać zebrane i przeanalizowane przed rozpoczęciem tworzenia WBS, by nie okazało się w trakcie pracy nad harmonogramem, że coś zostało pominięte.
2.1.P5 Definicja czynności / Tworzenie Struktury Podziału Prac (WBS)
2
Kierownik projektu.
1.0 Przedmiot dostaw (opcjonalny)
(opcjonalny)
1.1 Pakiet pracy 1
1.2 Pakiet pracy 2
1.3 Pakiet pracy 3
1.2.1 Zadanie 1
1.2.2 Zadanie 2
1.2.3 Zadanie 3
1.2.2.1 Czynność 1
1.2.2.2 Czynność 2
1.2.2.3 Czynność 3
Tworzenie pierwszego poziomu WBS. Celem WBS jest zidentyfikowanie wszystkich elementów pracy, jaka ma zostać wykonana. Należy najpierw określić duże części pracy. Na tym etapie ważne jest tylko, aby pod koniec procesu cała praca została zidentyfikowana. Na przykład podział pracy może być następujący: “planowanie / analiza / projekt / konstrukcja / testowanie / wdrażanie” daje to nam ogólny obraz projektu. Rozbicie może zostać wykonane według przedmiotów dostaw. Na przykład: “aplikacja online / dane magazynu / dane hali / narzędzia zapytań od użytkowników. Można również rozbić pracę na jakąkolwiek strukturę o ile ilustruje ona pracę do wykonania. Nie jest ważne na tym etapie ustalanie kolejności pracy! Ważne jest, aby określić próg estymacji, a także wiedzieć, jak bardzo
110 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
należy rozdrobnić zadania. Więcej informacji patrz: 2.1.2 Tworzenie harmonogramu projektu i budżetu. Proces rozbijania większej pracy na mniejsze zadania. Zakończona Struktura Podziału Pracy przypomina odwrócone (do góry nogami) drzewo czynności. Projekt (jako całość) zaznaczony jest jako poziom 0, a najbardziej ogólne składowe projektu zapisane są jako poziom 1. 3
Kierownik projektu.
Szacowanie pracochłonności zadań Po zakończeniu podziału pracy, należy oszacować pracochłonność każdego elementu. Istnieje kilka technik, które można zastosować w tym celu. (Więcej szczegółów dotyczących szacowania, patrz: 2.1.1 Ocenianie oraz 2.2.1 Techniki oceniania). Kiedy określi się już pracę dla każdego komponentu, należy sprawdzić, czy spełnia ona poniższe kryteria.
Czy
ustalona pracochłonność estymacji? (Więcej informacji, harmonogramu i budżetu).
jest mniejsza niż próg patrz: 2.1.2 Tworzenie
Czy rozumiemy każde zadanie, na każdym poziomie WBS?
Później każda czynność zapisana w WBS stanie się zadaniem w harmonogramie projektu. Nie należy w nim umieszczać czynności, których nikt w zespole nie rozumie. Jeśli rozumiemy zadania w WBS oraz jeśli szacowany poziom pracochłonności zadań jest mniejszy niż próg estymacji, nie należy dalej rozdrabniać pracy. Te zaś części pracy, które wymagają więcej pracochłonności niż próg estymacji, lub komponenty pracy, których nie rozumiemy powinny być dalej dekomponowane. 4
Kierownik projektu.
Dekompozycja zadań poziomu pierwszego na prace cząstkowe Należy po kolei przejrzeć zadania zapisane na poziomie 1 WBS, i określić jakie główne czynności należy wykonać, aby zadania te uznać za zrealizowane. W ten sposób powstaje drugi poziom WBS. Kiedy zakończony zostanie drugi poziom, należy ponownie oszacować, czy czasochłonność czynności jest większa niż próg estymacji. Należy również ustalić, czy rozumiemy zadania, które należy wykonać. Jeśli czasochłonność jest większa niż szacowany próg lub jeśli nie rozumie się zadania, należy dalej dekomponować zadania. Te części pracy, które są zrozumiałe oraz mniejsze niż próg estymacji, nie muszą już być dekomponowane. Proces dekompozycji zadań na bardziej szczegółowe (poziom WBS 3-4) powinien być kontynuowany, aż praca zostanie przedstawiona w WBS jak najbardziej szczegółowo. Zadania są rzadko rozbijane głębiej niż do poziomu piątego.
111 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W projektach dużych często zbyt mało wiemy, aby rozbić pracę na szczegółowe zadania. Jeśli nie daje się zdekomponować zadań – mogą pozostać opisane na dość dużym poziomie ogólności, o ile nie muszą być zrealizowane w najbliższym czasie. Najprawdopodobniej na trzy miesiące przed rozpoczęciem realizacji danej części pracy będziesz wiedzieć już wystarczająco dużo, aby dokonać ich dekompozycji. Ponieważ na tym etapie nie wiadomo jeszcze kiedy zadania będą wykonywane, dopiero przy ustalaniu sekwencji zadań (budowie diagramu sieciowego) będziesz wiedzieć dokładniej ile masz czasu na zebranie informacji o niezdekomponowanych zadaniach. Wtedy okaże się do kiedy należy je precyzyjnie zaplanować. 5
Kierownik projektu.
Szacowanie pracochłonności dla wszystkich zdekomponowanych zadań. Gdy WBS jest już zakończony należy przyporządkować pracochłonność wszystkim zadaniom elementarnym. (To takie zadania, które są na najniższym poziomie WBS lub nie są rozbite mniejsze czynności). Można użyć technik oszacowywania z działu: 2.1.1 i 2.2.1. Dodatkowe wskazówki do tworzenia WBS patrz: 2.1.6. Po zakończeniu WBS można już tworzyć plan kont kosztów projektu, co jest przydatne w szacowaniu kosztów. Więcej informacji patrz 2.1.7 Plan kont kosztowych.
2.1.P6 Określanie kolejności czynności
6
Kierownik projektu.
2.1.P6 Tworzenie diagramu sieciowego WBS Zadanie 1 Czynność 1.1
Start
Zadanie 2
Czynność 1.2
1.1
Czynność 2.1
Zadanie 3
Czynność 2.2
1.2
2.1
Czynność 3.1
Czynność 3.2
2.2
3.1
Koniec
3.2
Zadania, które są zawierają w sobie zdekomponowane zadania elementarne, nazywane są zadaniami sumarycznymi. Pierwszym etapem przekształcenia WBS na diagram sieciowy jest przeglądnięcie wszystkich zadań elementarnych (nie sumarycznych!) i ułożenie ich w kolejności chronologicznej.
112 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Należy pamiętać, aby ująć także te części pracy, które na etapie tworzenia WBS nie zostały zdekomponowane do postaci zadań elementarnych. 7
Kierownik projektu.
Określanie ścieżki krytycznej projektu. Kiedy ukończy się już określanie kolejności zadań, harmonogram projektu będzie składał się z jednego zadania początkowego, jednego końcowego, a między nimi będą leżały zadania elementarne, tworząc kilka, kilkanaście lub kilkadziesiąt „ścieżek” (jak na rysunku w p.6). Jedna z nich jest ważniejsza niż pozostałe, gdyż jest ścieżką krytyczną. Jest to ta sekwencja zadań, która zawiera zadania trwające najdłużej (między startem i końcem projektów). To ona wpływa na datę ostatecznego zakończenia projektu. Więcej informacji patrz: 2.1.8 Ścieżka krytyczna. Po zakończeniu budowy diagramu sieciowego zidentyfikuj ścieżkę krytyczną.
8
Kierownik projektu.
Analiza kolejności zadań i ustalenie relacji pomiędzy nimi. Kiedy określiło się wstępnie kolejność zadań, należy wykonać to powtórnie. Tym razem należy sprawdzić relacje i zależności pomiędzy zadaniami. Najczęstszym typem powiązania zadań jest taki, że jedna czynność nie może zostać rozpoczęta, jeśli nie została zakończona inna. W wielu przypadkach, dwie (lub więcej) czynności muszą zostać zakończone przed rozpoczęciem innej. Należy sprawdzić wszystkie relacje między zadaniami i ustalić które należy wykonać w kolejności a które równocześnie z innymi. Ten etap jest kluczowy do stworzenia dobrego harmonogramu projektu do rozpoczęcia projektu. Więcej informacji w rozdziale: 2.1.4 Relacje i zależności między zadaniami.
9
Kierownik projektu.
Identyfikacja ograniczeń czasowych Istnieją zadania, które mają związek z jakąś określoną datą. Muszą one rozpocząć się lub zakończyć do określonego dnia. Np., deklaracje VAT należy wypełnić i wysłać do 25 dnia każdego miesiąca, przedmiot dostawy ma być wykonany przed zebraniem Rady Dyrektorów w określonym dniu, lub do określonego dnia należy złożyć zamówienie u sprzedawcy. Zaleca się dużą ostrożność w ustalaniu jednoznacznych dat. Bardzo często wywołuje to bałagan w harmonogramie. Programy wspierające planowanie bardzo niejednoznacznie sygnalizują.
2.1.P7 Przypisywanie zasobów do zadań 10
Kierownik projektu.
Przyporządkowywanie zasobów. Do tej pory stworzony został harmonogram bez określania jakichkolwiek zasobów. Na tym etapie należy je przypisać do poszczególnych zadań. Jeśli znamy nazwiska realizatorów – przyporządkowujemy je bezpośrednio do zadań. Jeśli nie, tworzymy
113 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
tzw. zasoby indykatywne, czyli oparte o nazwy ról. Jeśli wiemy, że zadanie X będzie musiał wykonać jakiś analityk biznesowy, a zadanie Y będzie realizowane przez jakiegoś specjalistę od marketingu bezpośredniego – tworzymy zasób analityk biznesowy oraz pracownik merytoryczny działu marketingu. W późniejszym czasie, role te obsadzimy znajdując konkretnych realizatorów.
2.1.P8 Budowa harmonogram projektu
11
12
Kierownik projektu.
Tworzenie wstępnego harmonogramu projektu.
Kierownik projektu.
Równoważenie zasobów.
Jeśli używasz narzędzia wspierającego proces planowania projektu na tym etapie masz już gotowy wstępny harmonogram. W oparciu o czasochłonność, zasoby oraz ograniczenia, narzędzie obliczy precyzyjnie całkowity czas trwania projektu (od początku do końca). Harmonogram w takiej postaci może być przydatny w dalszym budowaniu definicji projektu.
W poprzednich etapach procesu planowania przyporządkowałeś zasoby do zadań, koncentrując się wyłącznie na tym, aby zidentyfikować kto jest w stanie wykonać daną pracę. Przeanalizuj teraz to, jak zasoby obciążone są pracą w kolejnych tygodniach. Często można zauważyć, że niektóre zasoby pracują zdecydowanie za dużo w jednym tygodniu (np. po 22 godziny dziennie) a w innym, zdecydowanie za mało. Dlatego teraz należy sprawdzić jak zasoby są obłożone pracą. Może się to okazać bardzo trudnym zadaniem w przypadku dużych projektów lub gdy w planowaniu nie było używane żadne narzędzie wspomagające. Analiza zasobów oraz dokonywanie zmian, by zrównoważyć obciążenie pracą zwane jest równoważeniem lub bilansowaniem zasobów. Można posłużyć się kilkoma dość oczywistymi technikami:
Zadania wykonywane równolegle zaplanować sekwencyjnie. Na
przykład, dwie czynności szacowane są na 80 godzin łącznie. W harmonogramie realizowane są przez jednego pracownika w tydzień. Należy więc określić, która czynność ma być wykonana jako pierwsza, a która jako druga. Jest to jedyne wyjście, jeśli nie można do tych zadań zatrudnić dodatkowych osób.
Przydzielić
część pracy innej osobie o podobnych umiejętnościach, która w danym momencie nie jest nadmiarowo obłożona innymi obowiązkami.
Znaleźć okres w projekcie, gdzie nie wykonuje się szczególnie
dużo zadań i przenieść w to miejsce zadanie, którego nie można wykonać w pierwotnie zaplanowanym okresie. Na przykład czynność trwa 5 dni. Nie leży na ścieżce krytycznej. Zadanie po niej następujące zaczyna się dopiero za 30 dni od
114 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
planowanego pierwotnie jej zakończenia. Nic więc się nie stanie, jeśli zrealizujemy ją 30 dni później. Pracownicy mogą wykonywać najpierw pilniejsze czynności, a tuż po ich zakończeniu zajmą się pracą zaległą.
Zmiana
podziału zasobów. Jeśli dwoje (lub więcej) ludzi zostało przyporządkowanych do danej czynności, należy sprawdzić, czy jedną osobę można skierować do pracy nad inną czynnością, przy której brakuje zasobów, nawet jeśli pierwsza czynność zostanie zakończona później. Podobnie, dodatkowe zasoby, nie mające dużo zadań można dodać do czynności, aby przyspieszyć jej wykonanie.
Według harmonogramu Joe ma zbyt dużo pracy w dniu 8 i 9. Po zrównoważeniu zasobów niektóre zadania zostały przesunięte na dzień 10, a reszta na dzień 11. Termin zakończenia pracy Joe przesuwa się wprawdzie o jeden dzień, ale nie jest przeciążony zadaniami. 13
Kierownik projektu.
Korekty harmonogramu i dodanie kamieni milowych. Po oszacowaniu czasochłonności dla każdej czynności oraz przyporządkowanych zasobów, można ponownie dokonać analizy projektu i sprawdzić, jak długo będą trwały prace. Na tym etapie mamy już pierwszy prawdziwy harmonogram projektu.
2.1.P9 Szacowanie kosztów
115 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
14
Kierownik projektu.
Szacowanie kosztów projektu. Koszty usług i towarów nabywanych z zewnątrz organizacji możesz oszacować analizując poprzednie projekty, oferty dostawców etc. Jeśli przypisałeś stawki godzinowe pracownikom projektu – możesz sprawdzić ile wynosi wewnętrzny koszt pracy. Teraz należy dodać wszelkie koszty wewnętrzne niezwiązane z pracą: delegacje, koszty administracyjne, narzuty etc. Po zsumowaniu powyższych mamy obraz ogólnych kosztów projektu.
2.1.P10 Zamykanie harmonogramu projektu 15
Kierownik projektu.
Przegląd harmonogramu Czy czujesz, że harmonogram jest logiczny, dobrze skonstruowany i realny? Jeśli masz wątpliwości – przejrzyj go ponownie i spróbuj je rozwiać. Nie możesz nie wierzyć w harmonogram, który zamierzasz zrealizować! Na etapie zatwierdzania projektu przez sponsora oraz innych menedżerów nie będziesz umiał go skutecznie bronić, jeśli nie będziesz mieć pewności, że jest dobrze wykonany. Na przykład, z harmonogramu może wynikać, że projekt potrwa dziesięć miesięcy, ale na wykonanie można przeznaczyć tylko osiem. W takim przypadku należy sprawdzić inne alternatywy, takie jak: dodanie zasobów, pracę w nadgodzinach, usunięcie niektórych czynności, itp. TenStep zaleca przygotowanie harmonogramu z dokładnością +/10%, zanim rozpoczniesz pracę.
16
17
Kierownik projektu.
Dodanie kamieni milowych.
Kierownik projektu.
Zapisanie harmonogramu w obecnej formie, jako bazowego.
Należy określić, kiedy główne przedmioty dostaw zostaną zakończone i w tych miejscach wstawić kamienie milowe. Kamień milowy to czynność, która nie zabiera żadnego czasu. Jest to swego rodzaju punkt kontrolny. Pomaga zarządzać pracą na poziomie ogólnym. Raportując osiągnięcie kamieni milowych można pokazać czy projekt idzie zgodnie z harmonogramem, czy jest opóźniony.
Kiedy już harmonogram projektu został zakończony, a projekt został zaakceptowany, należy zachować bieżącą kopię jako plan bazowy. W późniejszym okresie, kiedy zarządza się projektem, zaktualizowany harmonogram będzie można porównać do bazowego. Umożliwi to analizowanie tempa realizacji projektu, trendów, opóźnień etc.
2.1.P11 Budżetowanie kosztów 116 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
18
Kierownik projektu.
Przegląd budżetu Jeśli masz wątpliwości w odniesieniu do budżetu – analogicznie jak w przypadku planu – przejrzyj go ponownie i spróbuj rozwiać wszystkie kwestie wątpliwe. Nie możesz nie wierzyć w oszacowane koszty projektu! Na etapie zatwierdzania projektu przez sponsora oraz innych menedżerów, podobnie jak w przypadku harmonogramu, nie będziesz umiał skutecznie obronić budżetu, jeśli nie będziesz mieć pewności, że jest dobrze wykonany. TenStep zaleca przygotowanie budżetu projektu z dokładnością +/10% zanim rozpoczniesz pracę.
18
Kierownik projektu.
Finalizowanie ostatecznego budżetu Gdy harmonogram projektu został zakończony i oszacowałeś koszty projektu, można stworzyć budżet projektu. W niektórych projektach może to być jeden budżet skonsolidowany. W przypadku większych projektów można ustalić plan kont kosztowych dla każdego typu kosztów, dla odrębnych faz projektów, w układzie rodzajowym kosztów etc.
117 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.1 Tworzenie harmonogramu i budżetu / Szacowanie 2.1.1.P1 To, co odróżnia dobrego menedżera projektu od początkującego, to umiejętność prawidłowego oszacowania kosztu i czasu poszczególnych zadań projektu. Dobry menedżer – jeśli zna się na tym, czego dotyczy projekt, na podstawie własnego doświadczenia poda wycenę kosztów i czasu, która nie będzie w efekcie odbiegać za bardzo od rzeczywistych wartości. Jeśli zaś nie będzie orientować się w tym, co realizuje projekt, jako doświadczony menedżer użyje technik oraz narzędzi, które pomogą mu zdobyć dane do oszacowań na podstawie wiedzy innych ludzi. W zasadzie umiejętność dokonywania trafnych estymacji jest jedną z najbardziej cenionych cech menedżera projektu. Poniższe sekcje opisują proces szacowania pracochłonności, kosztów oraz czasu trwania. 2.1.1.P2 Zanim rozpoczniesz Zanim rozpoczniesz szacowania:
Sprawdź czy dobrze rozumiesz na czym polega twoje zadanie oraz praca do
wykonania. Wiele problemów jest wynikiem tego, że osoba dokonująca oszacowań nie wie, z czym dokładnie wiąże się praca, jaka ma być wykonana w projekcie. Należy unikać szacowania pracy, której się nie rozumie. Nie oznacza to, że musisz znać każdy szczegół. Dodawanie rezerw (wyjaśnione poniżej) jest sposobem na poradzenie sobie z niepewnością co do szacunków.
Określ,
kto powinien być zaangażowany w proces szacowania. Kierownik projektu może (lecz nie musi) wiedzieć wystarczająco dużo, aby przeprowadzić oszacowania samemu. Dobrym pomysłem jest poszukanie pomocy wśród członków zespołu, klientów, ekspertów, itp. Zazwyczaj pomaga to w bardziej dokładnym wykonaniu szacunków.
Określ,
czy są jakieś warunki brzegowe w szacowaniu. Jeśli istnieją ograniczenia ważne jest, aby były znane na początku. Powinieneś wiedzieć, czy klient oczekuje jakości Six-Sigma w przedmiotach dostawy czy można zastosować zasadę 80/20. Możliwe jest również, że będziesz miał ustalony budżet, którego nie można zwiększyć. (Wyjściem będzie zredukowanie zakresu pracy, jeśli będzie to konieczne, by zmieścić się budżecie). Wiedza o tych ograniczeniach pomoże osobom dokonującym szacowania przyjąć odpowiednie założenia co do kosztów, czasu trwania i jakości.
Stosuj wiele technik jednocześnie. Jeśli jest to możliwe, użyj dwóch lub więcej
technik do szacowania. Jeśli wyniki szacowania kilkoma technikami są zbliżone, będą one bardziej wiarygodne. Jeśli wyniki są różne, należy sprawdzić czy dane, na jakich budujemy oszacowania w każdej z technik są porównywalne oraz założenia jakie przyjęliśmy w procesie szacowania są adekwatne. W takim
118 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
przypadku można spróbować użyć trzeciej (lub czwartej) techniki, aby sprawdzić, które ze wstępnych oszacowań mogą być wiarygodne, a które należy odrzucić. 2.1.1.P3 Szacowanie pracochłonności Najpierw należy określić pracochłonność zadań. Następnie dopiero można przeprowadzić estymacje czasu trwania oraz kosztów. Do oceniania pracochłonności należy użyć poniższego procesu:
1
2
3
Role
Szacowanie pracochłonności
Kierownik projektu.
Określanie poziomu dokładności oszacowania.
Kierownik projektu.
Tworzenie wstępnego oszacowania pracochłonności.
Kierownik projektu.
(opcjonalne) Korekta oceny pracochłonności w oparciu o wiedzę na temat realizatorów zadań / przypisanych zasobów
Zazwyczaj, im dokładniejsze muszą być oszacowania, tym więcej szczegółów dotyczących projektu musisz wziąć pod uwagę. Co za tym idzie, będziesz potrzebować na to więcej czasu. Jeśli zostałeś poproszony o podanie przybliżonego rzędu wielkości (ROM) (-25% +75%), możesz wykonać tę pracę bardzo szybko. Do szacowania na tym poziomie bierze się pod uwagę wyłącznie bardzo ogólne dane. Można przedstawić oszacowanie ROM w oparciu o swoją własną wiedzę lub intuicję. Jeśli musisz przedstawić dokładne oszacowania (w granicach 10%), należy poświęcić na to więcej czasu dokładnie analizując szczegóły wykonania pracy.
Należy oszacować każdą czynność dla całego projektu przy użyciu technik opisanych w dziale: 2.2.1 Techniki szacowania.
Ustalając pracochłonność bierzesz pod uwagę wydajność przeciętnego pracownika. Oszacowania mogą być oparte na twoim doświadczeniu, jeśli już kiedyś realizowałeś analogiczne zadanie. Zdarza się, że masz już doświadczenia z określonymi pracownikami, którzy zostali przydzieleni do projektu. W takich przypadkach możesz korygować oszacowania pracochłonności ustalone dla przeciętnego pracownika w górę lub w dół, bazując na tym jak pracują twoi ludzie. Na przykład możesz oszacować czynność na 40 godzin. Wiesz jednak, że wykonawca jest niedoświadczonym praktykantem. W takim przypadku możesz podwoić oszacowanie do 80 godzin. Inne zadania mogły zostać zaplanowane na 200 godzin. Wiesz jednak, że zatrudniasz doświadczonego specjalistę. Możesz wtedy zredukować szacunki do 150 godzin. 4
Kierownik projektu.
Dodawanie godzin pracy personelu pomocniczego specjalistów wykorzystywanych okazjonalnie
oraz
Upewnij się, że wziąłeś pod uwagę godziny dla pracowników niepełnoetatowych. Są to ludzie, którzy nie będą pracować w 119 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projekcie na stałe, mogą być potrzebni do zadań specjalistycznych lub zwykłej pracy administracyjnej lub technicznej. Ponieważ są oni zazwyczaj z zewnątrz zespołu projektowego, lub ich obecność w projekcie jest niemal oczywista, możesz zapomnieć dodać ich czynności do WBS. 5
Kierownik projektu.
(opcjonalne) Dodawanie godzin na wprowadzanie poprawek i korekt. W świecie idealnym przedmioty dostawy projektu będą poprawne za pierwszym razem. W rzeczywistych projektach tak się nie dzieje. Harmonogramy, które nie biorą pod uwagę usuwania wad, poprawek i korekt, mogą okazać się niedoszacowane. Nie pomyl czasu zarezerwowanego na poprawki ze zmianami zakresu! Jeśli wytwarzasz przedmiot dostawy, który nie spełnia wszystkich początkowych wymogów lub ma problem z jakością, może być konieczne jego przerobienie. Jeśli początkowe przedmioty dostaw nie są do zaakceptowania ze względu na dodatkowe zapotrzebowanie na nowe cechy, funkcje lub wymagania, należy zastosować zarządzanie zmianą zakresu. Istnieje kilka sposobów brania pod uwagę czasochłonności i czasu związanych z przeróbką.
Powiększanie
oszacowań zadań. To prawdopodobnie najczęściej stosowana technika. Jeśli uważasz, że wykonanie przedmiotu dostawy będzie wymagało 50 godzin, od razu powiększasz tę liczbę biorąc pod uwagę prace konieczne do jednej lub większej ilości poprawek. W efekcie zadania trwają 55 lub 60 godzin. To najprostszy sposób. Jednak istotnie zaciemnia obraz zawarty w harmonogramie. Gdy ktoś będzie analizować twój harmonogram za jakiś czas, planując analogiczny projekt, tego rodzaju estymacje wprowadzą go w błąd.
Dodawanie
odrębnych zadań. Szacujesz pracochłonność wykonania przedmiotu dostawy tak, jakby nie potrzebował poprawek. Następnie dodajesz zadania jednoznacznie opisujące wprowadzanie poprawek. Szacujesz ich pracochłonność, czas trwania oraz koszty. Ten sposób bardzo klarownie ilustruje proces budowy przedmiotu dostawy oraz wprowadzania poprawek. Będzie łatwiejszy w zrozumieniu dla osób trzecich.
Dodawanie
„buforów‖ czasowych. Zamiast przerabiać pojedyncze przedmioty dostaw, pod koniec fazy ich wytworzenia dodajesz blok zadań – rezerwę na poprawki. Pracochłonność oraz koszty związane z buforem mogą być ustalone w sposób procentowy lub być sumą godzin przeznaczonych na poprawianie każdego z osobna przedmiotu dostawy.
6
Dodawanie czasu na zarządzanie projektem. Zarządzanie projektem zabiera czas oraz generuje koszty. Należy
120 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
przyporządkować jakiś czas na zarządzanie projektem. Powinieneś dodać ok. 15% pracochłonności na zarządzanie projektem. Na przykład, jeśli projekt szacowany jest na 12,000 godzin (7 - 8 osób), konieczny jest pełnoetatowy kierownik projektu (1800 godzin). Jeśli projekt szacowany jest na 1000 godzin, czas kierowania projektem wyniesie 150 godzin. Nie będzie to okres wystarczający dla pełnoetatowego kierownika projektu. Albo będzie niepełnoetatowy, albo będzie miał również dodatkowe zadania nie związane z zarządzaniem projektem. 7
Dodawanie rezerw na obsługę sytuacji nieprzewidzianych i kryzysowych. Rezerwy te używane są, aby odzwierciedlić niepewność oraz ryzyko związane z oszacowaniem. Jeśli zostaniesz poproszony o oszacowanie źle zdefiniowanego projektu, możesz dodać 50%, 75% lub więcej, aby odwzorować niepewność. Jeśli oszacowanie ma zostać wykonane szybko, mogą być konieczne większe rezerwy. Nawet jeśli masz czas, aby stworzyć w miarę dokładne oszacowania, rezerwy te mogą w dalszym ciągu wynosić 10-25%. Jeśli nie dodasz rezerw, oznacza to że w 100% ufasz oszacowaniu. Jest to uzasadnione, jeśli w przeszłości wykonano projekt podobnego rodzaju. Ale bierz pod uwagę to, że każdy projekt realizowany jest w innych okolicznościach. Rezerwy na obsługę sytuacji nieprzewidzianych i kryzysowych, najlepiej jest wyszczególnić jako odrębna pozycja w budżecie oraz umieścić w harmonogramie. Jeśli twoja organizacja nie pozwoli na dołączenie tego rodzaju rezerwy, nie masz wyboru. Będziesz musiał dodać rezerwy zawyżając szacunki wszystkich podstawowych zadań. Nie jest to preferowana technika i należy jej unikać tak bardzo jak się da. Jeśli organizacja nie akceptuje faktu niepewności oszacowań lub nie przyjmuje do wiadomości, że świat może nie być idealny, zwiastuje to problemy dla kierownika projektu o wiele trudniejsze, niż tylko zatwierdzanie harmonogramu.
8
Obliczanie całkowitej czasochłonności. Należy dodać wszystkie oszacowania dla wszystkich komponentów pracy opisanych powyżej.
9
Sprawdzenie i korekta - jeśli jest to konieczne. Czasami, kiedy dodasz wszystkie komponenty, oszacowanie wydaje się zbyt duże lub zbyt małe. Jeśli nie wygląda to dobrze, należy cofnąć się i w pierwszej kolejności przeanalizować założenia jakie przyjęliśmy w procesie. Być może gdy dokonasz w nich zmiany, problem rozwiąże się. Należy również upewnić się, że model oszacowania jest rozsądny. Na przykład, jeśli jakieś zadanie się powtarza można wstępnie oszacować całkowitą jego pracochłonność poprzez pomnożenie pracochłonności jednego zadania przez ilość tych zadań. Podczas analizy możesz się zorientować, że pracochłonność sumy zadań zmniejszy się,
121 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
ponieważ zadanie stanie się rutyną. Należy również upewnić się, że podobne zadania mają podobne oszacowania, a jeśli nie, należy to poprawić. 10
Dokumentowanie wszystkich założeń. Na pewno nigdy nie będziesz znał wszystkich szczegółów projektu podczas planowania. Dlatego też ważne jest, aby udokumentować wszystkie założenia przyjęte podczas oszacowania. W razie jakichkolwiek wątpliwości, zarówno podczas zatwierdzania harmonogramu i budżetu, jak i w czasie ich przeglądów, będziesz mógł precyzyjnie odpowiadać na każde pytanie dotyczące oszacowania.
122 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.1.P4 Szacowanie czasu trwania Pracochłonność zazwyczaj jest podawana w godzinach, czas trwania w dniach. Drugą ważną informacją jest data zakończenia zadania. Na przykład, mylące może być powiedzenie, ze projekt będzie trwał trzy miesiące, ponieważ nie wiesz dokładnie, czy będzie to oznaczało 90 dni kalendarzowych czy 60 dni roboczych. Można natomiast powiedzieć, że szacowany czas trwania projektu wynosi 90 dni, a data końcowa to 31 stycznia 2011r. Jeśli podajesz oszacowania czasu trwania w ten sposób (szacowana ilość dni oraz termin zakończenia) są one jednoznaczne. Gdyby każdy pracował osiem godzin dziennie i był w 100% wydajny, można by było łatwo obliczyć czas trwania poprzez wykorzystanie pracochłonności podzielonej przez ilość osób wykonujących zadanie. Na przykład, jeśli zadanie szacowane jest na 80 godzin i masz do niej przyporządkowaną jedną osobę, a osoba ta pracuje przez osiem godzin, wtedy czas trwania wyniesie (80 / 1 / 8) = 10 dni. Podobnie, jeśli przyporządkujesz cztery osoby na pełen etat, czas trwania wyniesie (80 / 4 / 8) = 2,5 dnia. Jednak świat nie jest idealny. Dlatego też można ustalić czas trwania czynności przy użyciu następującego procesu.
1
2
3
Role
Szacowanie czasu trwania
Kierownik projektu.
Ustalenie godzin produktywnych.
Kierownik projektu.
Ustalenie, ile zasobów będzie realizować zadania.
Kierownik projektu.
Ustalenie ilości dostępnych dni roboczych.
Zacznij od ustalenia ile godzin średnio możemy uznać za produktywne w każdym dniu pracy. Jeśli pracochłonność zadania wynosi 40 godzin, w praktyce nie jest możliwe, że zostanie ono zakończone w ciągu tygodnia bez nadgodzin. Można uznać, że przeciętnie 6,5 godziny poświęca się dziennie na pracę. Pozostała część to rozmowy, rozkładanie materiałów, przerwy na chwilę nic nierobienia etc. Więcej szczegółów patrz: 2.1.5 Określanie godzin produktywnych.
Zazwyczaj im więcej ludzi realizuje zadanie, tym prędzej zostanie ono zakończone. Dwóch pracowników może wykonać dane zadanie szybciej niż jeden. Nie musi to jednak być zrobione dwa razy szybciej. Podobnie, trzecia osoba może przyspieszyć prace, lecz nie do jednej trzeciej pierwotnego czasu. W pewnym momencie dodawanie zasobów nie będzie przyspieszało pracy. Może ją nawet wydłużać.
Należy brać pod uwagę wakacje, dni wolne oraz szkolenia. Nie zostały one wzięte pod uwagę w ustalaniu produktywności w pierwszym punkcie, ponieważ czas gdy zespół świadomie i oficjalnie nie pracuje nad projektem może zostać zaplanowany z góry. Na przykład podczas trzymiesięcznego projektu, jeden członek zespołu może nie przyjść do pracy przez dwa dni. Inny może wziąć dziesięć dni urlopu. Aby zapewnić większą dokładność harmonogramu należy
123 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
brać pod uwagę dni, podczas których nasz zespół nie będzie pracować nad projektem. 4
5
Kierownik projektu.
Ustalenie ile % etatu pracownik pracuje przy projekcie.
Kierownik projektu.
Uwzględnienie obniżania się produktywności pracowników pracujących w wielu projektach.
Jeśli przydzielisz pracownikowi wykonanie zadania, a pracuje on na pół etatu w projekcie, zajmie mu ono dwa razy więcej czasu, niż gdyby pracował w pełnym wymiarze nad tym zadaniem. Jeśli pracochłonność zadania wynosi 40 godzin, a pracownik, który został przydzielony do projektu na 25% swojego etatu, prawdopodobnie wykona zadanie w czasie cztery razy dłuższym.
Jeśli jedna osoba pracuje w wielu projektach lub projekt realizuje równolegle ze swoimi codziennymi obowiązkami (pracą operacyjną), należy brać pod uwagę obniżenie produktywności takiego pracownika. „Przestawienie się” z jednego projektu na drugi zabiera czas. Często różne zadania wymagają innego rodzaju koncentracji, przeorganizowania stanowiska pracy itd. Przy dwóch projektach „czas przestawienia się: wynosi ok. 10%, przy trzech i więcej – ok. 25%. Na przykład, załóżmy, że jedna osoba dzieli czas na trzy projekty po 24, 10 i 6 godzin w tygodniu. Kierownik projektu powinien wstępnie założyć rzeczywistą wydajność zbliżoną do 20, 8 i 4 godzin na tydzień. Może ona spaść jeszcze i wynosić odpowiednio 16, 6 i 3 godzinom tygodniowo. 6
Kierownik projektu.
Wlicz do kalkulacji czasu trwania czas opóźnień i czas oczekiwania. Niektóre czynności wymagają niewielkiej pracochłonności, ale mają długi czas przestoju. Na przykład czas trwania wymagany na zatwierdzenie przedmiotu dostawy. Możesz szacować pracochłonność na kilka godzin. Jednak akceptacja może potrwać kilka dni lub tygodni.
7
8
Kierownik projektu.
Identyfikacja ograniczeń wynikających z dostępności zasobów.
Kierownik projektu.
Dokumentowanie wszystkich założeń.
Kiedy tworzysz wstępny harmonogram, identyfikujesz zadania, które można wykonać sekwencyjnie oraz te, które mogą zostać wykonane równolegle. Jeśli masz wystarczającą ilość zasobów, wszystkie zadania zaplanowane jako równoległe, zostaną tak zrealizowane. Jednak często nie możesz wykonać zadań jednocześnie, ponieważ nie masz odpowiedniej ilości ludzi. Wtedy równoległe zadania muszą zostać wykonane sekwencyjnie. Niektóre z zadań mogą wymagać specyficznych umiejętności lub uprawnień. Trzeba także zapewnić, by w projekcie w odpowiednim czasie, osoby takie mogły pracować.
Na pewno nigdy nie będziesz znał wszystkich szczegółów projektu podczas planowania. Dlatego też ważne jest, aby udokumentować
124 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wszystkie założenia przyjęte podczas oszacowania. W razie jakichkolwiek wątpliwości, zarówno podczas zatwierdzania harmonogramu i budżetu, jak i w czasie ich przeglądów, będziesz mógł precyzyjnie odpowiadać na każde pytanie dotyczące oszacowania. 2.1.1.P5 Szacowanie kosztów Po przyporządkowaniu zasobów można oszacować koszty.
1
Role
Szacowanie kosztów.
Kierownik projektu.
Szacowanie kosztów pracy. Na poziomie ogólnym koszty projektu szacowane są poprzez sumowanie kosztów pracy i kosztów nie związanych z pracą. Koszty pracy mogą zostać wyliczone poprzez przemnożenie pracochłonności każdego zadania i stawek godzinowych pracowników, którzy je realizują. W wielu firmach nie oblicza się kosztów pracy, jeśli realizują ją pracownicy wewnętrzni. Nie oznacza to, że praca nie generuje kosztów ale że firma nie płaci za nią dodatkowo. Koszt pracowników z zewnątrz musi zostać zawsze oszacowany i uwzględniony w budżecie. Należy określić typ zewnętrznych zasobów oraz stawkę godzinową dla nich. Następnie należy przemnożyć stawkę godzinową przez ilość godzin, na które każdy pracownik zostanie przyporządkowany do projektu. Jeśli nie jesteś pewny rzeczywistych kosztów zasobów, musisz dokonać jakiś założeń. Na przykład, mogą istnieć jakieś średnie stawki za godziny pracy jaką firma do tej pory wypłacała pracownikom zewnętrznym. Jeśli nie wiesz czy będziesz korzystać z zasobów zewnętrznych musisz przyjąć jakieś założenia. Albo, że nie będziesz korzystać z nich, albo że skorzystasz z nich w jakimś wymiarze. Pamiętaj, że założenia te muszą być udokumentowane.
2
Kierownik projektu.
Szacowanie kosztów personalnych nie związanych z pracą. Koszty personalne nie związane z pracą obejmują koszty nie związane bezpośrednio z poborami pracowników oraz z kosztami pracowników zewnętrznych. Niektóre z tych kosztów, takie jak: wydatki na szkolenie i tworzenie zespołu, związane są z ludźmi. Jednak w dalszym ciągu nie są one traktowane jako niezwiązane z pracą, gdyż nie odnoszą się do wynagrodzeń pracowników. Należy również zauważyć, że w niektórych firmach, koszty pracy zawierają tylko koszty pracowników a nie koszty pracy kupowanej od firm zewnętrznych. Każdy kierownik projektu musi być świadomy zasad księgowania w swojej własnej firmie, aby móc we właściwy sposób alokować środki związane i niezwiązane z pracą. Koszty nie związane z pracą obejmują zazwyczaj:
sprzęt komputerowy i oprogramowanie 125 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
podróże szkolenia tworzenie zespołu sprzęt materiały etc. 3
Kierownik projektu.
Dokumentowanie wszystkich założeń. Na pewno nigdy nie będziesz znał wszystkich szczegółów projektu podczas planowania. Dlatego też ważne jest, aby udokumentować wszystkie założenia przyjęte podczas oszacowania. W razie jakichkolwiek wątpliwości, zarówno podczas zatwierdzania harmonogramu i budżetu, jak i w czasie ich przeglądów, będziesz mógł precyzyjnie odpowiadać na każde pytanie dotyczące oszacowania.
126 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.2 Tworzenie harmonogramu i budżetu / Próg estymacji 2.1.2.P1 Podczas tworzenia harmonogramu zazwyczaj nie wie się na tyle dużo, aby wpisać wszystkie szczegółowe zadania za pierwszym razem. Zamiast tego należy najpierw określić duże grupy zadań (makrozadania), a następnie rozbić je na mniejsze części. Te części są dalej rozbijane na bardziej szczegółowe zadania. Technika ta określana jest jako tworzenie Struktury Podziału Pracy (WBS). Właściwym pytaniem, które należy zadać jest to: jak małe powinny być zadania, aby nie musiały być już dalej dzielone? Tego rodzaju pytanie związane jest progiem estymacji. Praca może być rozbita na zadania mniejsze niż próg estymacji, natomiast nie powinno się zostawić pracy, której szacunkowa wielkość przewyższa ten próg. Próg może mieć różną wielkość w zależności od wielkości projektu oraz stopnia jego zrozumienia. Poniższe kryteria mogą zostać użyte jako wytyczne. Dla typowego dużego projektu (powiedzmy 5000 godzin lub więcej) jakakolwiek praca dłuższa niż 80 godzin powinna być rozbita na mniejsze części. Średnie projekty (powiedzmy 1000 godzin) powinny mieć czynności nie dłuższe niż 40 godzin. Jeśli projekt jest mały (około 200 godzin) powinno rozbić się czynności na prace nie dłuższe niż 20 godzin. Identyfikowanie pracy mniejszej niż próg pozwala na lepsze zarządzanie nią. Na przykład jeśli pracochłonność projektu wynosi 250 godzin i składa się on z trzech zadań po 80 godzin każde, nie dasz rady zareagować, gdyby się okazało, że praca została wykonana źle i trzeba ją powtórzyć w dużej części. Jeśli największe zadanie trwa 20 godzin, a pozostałe są mniejsze, jesteśmy w stanie znacznie lepiej monitorować przebieg prac i określić, czy zadanie jest wykonywane zgodnie z planem. Jeśli nie wiesz zbyt wiele o zadaniu, a będzie ono realizowane w przyszłości, możesz pozostawić je opisane na dużym poziomie ogólności. Zajmiesz się nim, gdy zdobędziesz więcej informacji. Możesz także podzielić projekt na mniejsze podprojekty. Dzięki temu dopiero wtedy zdekomponujesz niezrozumiałe zadania, jeśli poprzedzające podprojekty zakończą się pomyślnie. Dekompozycja zadań na mniejsze, poniżej progu estymacji, zmusza do przemyślenia projektu i polepsza zrozumienie pracy. Te dwa czynniki – zdolność do efektywnego zarządzania pracą i zrozumienia – powinny wskazywać jaka jest ostateczna wielkość progu estymacji. 2.1.2.P2 Próg estymacji czasu trwania Zazwyczaj zadania powinny być tak zaplanowane, aby ich czas trwania mieścił się w dwóch cyklach raportowania zespołu projektowego. Na przykład, jeśli otrzymujesz cotygodniowe raporty od zespołu w harmonogramie nie powinno znaleźć się żadne zadanie, które trwa dłużej niż dwa tygodnie. Dzięki temu zadania bieżące (raportowane przez zespół) zawsze będą dawały się podzielić na trzy grupy: już zrealizowane (w tym tygodniu), obecnie realizowane (z terminem zakończenia do następnego raportu) oraz oczekujące na rozpoczęcie. Jeśli natomiast masz zadanie, które trwa pięć tygodni, możliwe jest, że minie pięć tygodni zanim zorientujesz się na pewno, że dana czynność zostanie wykonana zgodnie z harmonogramem. W pięciu kolejnych raportach wykonawca zanotuje, że zadanie jest realizowane. I może się okazać dopiero w ostatnim 127 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
tygodniu, że przez te pięć tygodni praca została ledwo rozpoczęta. Co będziesz mógł wtedy zrobić by zdążyć? Jest to przykład gdy zadanie musi zostać rozbita przynajmniej na dwa mniejsze zadania. Pozwoli to na znacznie szybsze reagowanie. Należy zauważyć, że próg estymacji czasu trwania jest używany, kiedy harmonogram jest finalizowany, a nie kiedy tworzony jest WBS. Kiedy tworzony jest WBS, znamy tylko szacunkową pracochłonność i posługujemy się ogólnym progiem estymacji w dekomponowaniu zadań. Po przypisaniu zasobów można dopiero ocenić, czy próg estymacji czasu trwania zadań nie zostanie przekroczony.
128 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.4 Tworzenie harmonogramu i budżetu / Relacje i zależności między zadaniami 2.1.4.P1 Kiedy tworzy się diagram sieciowy, każde zadanie z WBS zostaje powiązane z co najmniej dwoma zadaniami – czynnością poprzedzającą (poprzednik) i następującą po nim (następnik). W wielu przypadkach jest więcej niż jeden poprzednik i następnik. Istnieje kilka sposobów przedstawienia tych relacji. Najczęstszą techniką jest technika zwana Diagramową Metodą Pierwszeństwa (PDM). (technika jest czasami nazywana AON.). W technice PDM czynności umieszczane są w ramkach, a ramki są łączone strzałkami ukazującymi pierwszeństwo. Najczęstsza relacja to taka, kiedy jedna czynność nie może zostać rozpoczęta, zanim inna nie została zakończona. Określa się to jako relacja: “koniec - początek”. Istnieją jednak różne sposoby na połączenie ze sobą czynności.
koniec – początek - Czynność B nie może zostać rozpoczęta, jeśli czynność A
nie została zakończona. To jest najczęstsza relacja pomiędzy wieloma projektami. Na przykład (powyżej) należy zainstalować nowy komputer, zanim można będzie zainstalować nowe oprogramowanie.
początek – koniec - Czynność A musi zostać rozpoczęta zanim zakończy się czynność B. Jest to bardzo rzadka zależność. Na przykład (powyżej) załóżmy, że
129 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
chcesz nawozić swój ogród. Zanim to jednak będzie możliwe, rośliny muszą zostać podlane. Dlatego też osoba B musi podlewać rośliny do momentu, kiedy osoba A będzie przygotowana do rozpoczęcia nawożenia. Oznacza to, że osoba A musi rozpocząć nawożenie. Dopiero wtedy osoba B będzie mogła przestać podlewać ogród. Należy zauważyć, że osoba A może rozpocząć podlewanie w dowolnym momencie, natomiast osoba B może zakończyć naważenie w dowolnym momencie. Relacja związana jest tylko z rozpoczęciem czynności A do zakończenia czynności B. Innym przykładem tego rodzaju relacji jest sztafeta. Gdzie kończący zawodnik biegnie z pałeczką przez pewien czas obok zawodnika, który za moment ją przejmie. Później oddający pałeczkę przez moment towarzyszy przejmującemu. I wreszcie na tej samej relacji jest oparta cała wymiana pokoleń. Rodzice nie mogą umrzeć, zanim nie zaczną żyć ich dzieci.
start – start - Czynność A musi się rozpocząć, zanim będzie można rozpocząć
czynność B. na przykład, (powyżej) załóżmy, że ktoś maluje nam ściany w jednym pomieszczeniu, a w drugim ktoś kładzie tapety. Chcesz zminimalizować ogólny zamęt. Wtedy obydwie czynności muszą być wykonane w tym samym czasie. Relacja jest następująca: osoba A musi rozpocząć malowanie ścian. Następnie osoba B będzie mogła rozpocząć kładzenie tapet. Relacja ta jest oparta na czasie rozpoczęcia czynności. Czas zakończenia czynności nie jest powiązany. Jedna czynność może się zakończyć znacznie później niż druga. W tym przypadku tapeciarze mogą być gotowi do pracy, ale nie mogą jej zacząć, dopóki nie rozpocznie się malowanie.
koniec – koniec - Czynność A musi zostać zakończona, zanim będzie można
zakończyć czynność B. Na przykład, (powyżej) załóżmy, że gotujesz obiad i chcesz zakończyć gotowanie głównych dań w tym samym czasie. Oznacza to, że indyk musi zostać przygotowany (A) zanim zakończymy gotowanie ziemniaków (B). Relacja ta oparta jest na czasie zakończenia. Czynności mogą zostać rozpoczęte w dowolnym momencie pod warunkiem, że zakończą się w tej kolejności.
130 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.5 Tworzenie harmonogramu i budżetu / Określanie godzin produktywnych 2.1.5.P1 Szacowania zaczynamy od pracochłonności. Bez tego nie można w sposób dokładny wyznaczyć czasu trwania oraz kosztów. Jednym z głównych czynników prawidłowej konwersji pracochłonności na czas trwania jest określenie, ile godzin pracy można zarezerwować na projekt w typowym dniu pracy. Na przykład, jeśli zadanie oceniasz na 40 godzin pracy, jest mało prawdopodobne, że zakończysz je w ciągu pięciu ośmiogodzinnych dni pracy. Nikt nie jest 100 % wydajny. Bez uwzględnienia tego faktu, możliwe jest, że przy dobrze określonej pracochłonności, źle określisz w czas trwania i termin zakończenia pracy. Potrzebny jest “czynnik realności”, aby zamienić pracochłonności na czas trwania. Należy określić średnią ilość godzin, które dana osoba faktycznie przepracowuje w ciągu dnia. Nazywane są one godzinami produktywnymi. Przy ustalaniu współczynnika produktywności weź pod uwagę takie rzeczy jak: interakcje społeczne, przemieszczanie się na spotkania, rozkładanie notebookówv i rzutników, rozmowy telefoniczne, etc. Współczynnik produktywności uwzględnia również czas, który potrzebny jest pracownikom do rozpoczęcia pracy rano (tzw. czas prannego rozruchu) i to, że wydajność spada po południu. Można spróbować przedstawić ilość godzin produkcyjnych na dzień dla każdej osoby w zespole. Będzie to jednak bardzo uciążliwe. Powszechnie akceptowana ilość godzin produktywnych na ośmiogodzinny dzień pracy to 6,5. Nie oznacza to, że osoba nie może być w pełni wydajna w jakimś dniu całe osiem godzin. Przedstawia to jednak przeciętną wydajność osoby w długim okresie. O przyjętych założeniach dotyczących harmonogramu, a szczególnie średniej produktywności należy rozmawiać z zespołem projektowym. Ludzie powinni wiedzieć czego się od nich oczekuje. Muszą mieć także możliwość powiedzenia, czy czynniki zewnętrzne nie utrudnią im przeznaczania wyznaczonego czasu na projekt. Wiedząc to będziesz mógł albo starać się zmienić im przydział obowiązków (jeśli codzienna praca utrudnia im realizację projektu), albo będziesz musiał skorygować założenia dotyczące godzin produktywnych i wprowadzić zmiany do harmonogramu. Jeśli w twoim projekcie pracują osoby zatrudniane z zewnątrz firmy (na umowy zlecenia, pracownicy czasowi etc.) w ich przypadku także należy uwzględnić współczynnik produktywności. Na przykład osoby te też będą udzielać się towarzysko i będą przemieszczać się np. na spotkania. W ich przypadku godzin produktywnych będzie więcej ok. 7 – 7,25h w ośmiogodzinnym dniu. Niestety, płacić należy za wszystkie osiem godzin! Spójrz na przykład. Załóż, że masz zadanie, którego pracochłonność szacowana jest na 80 godzin. Jeśli pracownik wykorzysta pełen czas pracy, to zakończenie zadania zajmie mu trochę ponad dwanaście dni (80 / 6,5 godzin produktywnych). Jeśli zadanie będzie realizował pracownik z zewnątrz poświęci na to samo zadanie jedenaście dni (80 / 7,25 godzin produktywnych). 131 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.6 Tworzenie harmonogramu i budżetu / Podstawy tworzenia Struktury Podziału Pracy (WBS) 2.1.6.P1 Poniżej opisane dodatkowe techniki oraz porady dotyczące tworzenia Struktury Podziału Pracy (WBS). 2.1.6.P2 Tworzenie zadań elementarnych i sumarycznych Jeśli spojrzysz na WBS i uznasz, że dane zadanie musi zostać rozbite na mniejsze, zadanie które zostało rozbite po dekompozycji nazywa się zadaniem sumarycznym, a nowe, uszczegółowione - zadaniem elementarnym. Zadanie sumaryczne nie ma własnej pracochłonności, czasu trwania ani kosztu. Przypisana pracochłonność i koszty są najwyżej sumą tych zadań, z których zadanie sumaryczne się składa. Zadania elementarne to takie, które nie zostały rozbite na mniejsze podzadania i czynności. Zadanie sumaryczne uznaje się za zrealizowane jedynie wtedy, gdy wszystkie zadania elementarne umieszczone pod nim, są zakończone. Jeśli stwierdzimy, że nie jest to prawdą, że zadania sumarycznego nie możemy uznać za w pełni zrealizowanego po zakończeniu wszystkich zadań elementarnych umieszczonych pod nim, należy zidentyfikować i dodać zadania elementarne, które należy wykonać, aby uznać sumaryczne za zrealizowane. 2.1.6.P3 Użycie Techniki żółtych karteczek (Post-It Note) do tworzenia WBS Zaskakująca może być jak wiele osób wykorzystująca żółte karteczki oraz ściany do stworzenie pierwszego szkicu WBS. Technika ta jest bardzo prosta. Zgromadź właściwe osoby w tym samym pomieszczeniu (członkowie zespołu, klient etc.). Zacznij od napisania na karteczkach nazw głównych przedmiotów dostawy – jeden przedmiot na jednej karteczce. Jeśli któryś z przedmiotów jest zbyt duży, można utworzyć drugi poziom WBS, opisujący drobniejsze przedmioty dostawy. Karteczki te (drugi poziom) umieść pod bardziej ogólnym przedmiotem dostawy poziomu pierwszego. Najczęściej jednak udaje się zapisać przedmioty dostawy na jednym poziomie. Następnie dla każdego przedmiotu dostawy określ zadania i czynności, które należy wykonać, aby go stworzyć. Każda czynność wpisz na osobnej karteczce. Zadania umieszczaj pod konkretnym przedmiotem dostaw, do którego się odnoszą. Jeśli wiadomo, w jakiej kolejności należy wykonać te czynności, można je ułożyć w sekwencję. Jednak nie jest to na tym etapie istotne. Ważne jest zidentyfikowanie całej pracy. Teraz przeanalizuj wszystkie zadania wymagane do stworzenia każdego przedmiotu dostawy i oszacuj ich pracochłonność. Jeśli jest ona większa niż próg estymacji, zadanie powinno być zdekomponowane. Każde zadanie elementarne przedstawiane jest przy pomocy osobnej karteczki. Wszystkie zadania elementarne
132 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
opisujące zadanie sumaryczne umieść pod nim. Kontynuuj ten proces, aż praca konieczna do wykonania wszystkich przedmiotów dostaw zostanie rozbita na czynności o pracochłonności mniejszej niż próg estymacji. Bardzo często przedmioty dostaw będą mieć różną ilość poziomów. Duże przedmioty dostaw mogą mieć ich więcej, a przy małych, może okazać się, że już na drugim poziomie znajdują się zadania o pracochłonności mniejszej niż próg estymacji. Zaletą tej techniki jest fakt, że dany zespół może zobaczyć całą pracę. Karteczkami można łatwo. Po zakończeniu można całego WBSa przenieść do narzędzia wspomagającego planowania. 2.1.6.P4 Technika budowania WBS – identyfikacja zadań i przedmiotów dostaw Często trudno jest rozpocząć WBS ponieważ nie wiadomo, co umieścić na samej górze oraz jak rozbijać poszczególne zadania. Pomimo, że jest wiele sposobów na rozpoczęcie WBS, zazwyczaj skup się na przedmiotach dostaw. Jeśli założysz, że najwyższy poziom (zerowy) ilustruje ogólnie cały projekt, następne poziomy mogą przedstawiać przedmioty dostaw. Po opisaniu przedmiotów dostaw, można opisać zadania konieczne do wytworzenia przedmiotów dostaw. Harmonogram jest przecież złożony z tych zadań. WBS pomaga w ich identyfikacji i powiązaniu z przedmiotami dostaw. Istnieją jeszcze co najmniej dwie opcje definiowania WBS na poziome 1:
opisanie
zaangażowanych pionów lub departamentów, takich jak: Sprzedaż, Marketing, IT, itp. Następny poziom będzie opisywał przedmioty dostaw, które wykona każda jednostka.
odwzorowanie na poziomie 1 Cyklu Życia Projektu; np.: analiza, projektowanie,
konstrukcja, testowanie. Jeśli jest to logiczny sposób przedstawienia poziomu 1, to poziom 2 powinien opisywać przedmioty dostaw powstałe w wyniku każdego etapu cyklu życia.
Więcej informacji także w rozdziale: 2.1.6.1 Przykład WBS. 2.1.6.P5 Techniki dekompozycji zadań sumarycznych Kiedy zespół tworzy WBS pojawiają się pytania o to, jak szczegółowe powinny być zadania elementarne. Od tego zależy to, kiedy należy przerwać proces dekompozycji pracy. Po części odpowiedź znajdziesz w: 2.1.2 Tworzenie harmonogramu i budżetu / Próg estymacji. Oto inne rzeczy, które należy brać pod uwagę podczas dekompozycji zadań:
Zadanie
elementarne nie powinno zawierać w sobie podzadań, które są nie powiązane i nie ciągłe. Na przykład, jeśli mamy zadanie: “Tworzenie strategii testowania i szkolenia”, powinno ono zostać rozbite na dwa odrębne. Strategia testowania oraz strategia szkolenia nie muszą być powiązane, a tym bardziej ciągłe. Być może każde z nich jeszcze wymaga dekompozycji.
Zadanie elementarne powinno być wykonywane przez jedną osobę lub grupę
powiązanych ze sobą osób. Jeśli mamy zadanie wymagające pracy różnych osób, powinno zostać rozbite tak, aby podzadanie opisywało pracę każdej
133 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
poszczególnej osoby lub grupy. Należy pamiętać, że zadania elementarne zostaną ostatecznie przeniesione do harmonogramu. Nie można pozwolić, żeby znalazło się tam jedno zadanie przyporządkowane dwóm różnym grupom lub dwóm różnym osobom (nie związanym ze sobą). Trudno byłoby nad nim panować!
Praca powinna zostać rozbita do poziomu, który jest łatwy do kontrolowania przez
kierownika projektu. Teoretycznie harmonogram może zostać podzielony do poziomu, na którym każda czynność trwa jedną lub dwie godziny. Oczywiście rozbijanie zadań aż tak szczegółowo nie ma sensu. Ani członek zespołu, ani kierownik projektu nie będzie potrzebował opisu pracy na tak szczegółowym poziomie.
2.1.6.P6 Nie należy tworzyć zbyt ―smukłych‖ WBSów W zależności od podejścia do WBS identyfikacja przedmiotów dostaw może objąć od jednego do trzech poziomów. Podstawową zasadą jest nieprzekraczanie pięciu poziomów dla każdego przedmiotu dostawy. Jeśli jest ich więcej sprawdź, czy nie definiujesz zadań na zbyt szczegółowym poziomie. Po drugie, mogłeś zdefiniować zbyt szeroko przedmioty dostaw. W takim przypadku należy sprawdzić, czy duży przedmiot dostaw nie mógłby zostać rozbity na mniejsze. Praca związana z mniejszymi przedmiotami dostaw nie powinna wymagać aż tylu poziomów. 2.1.6.P7 Rozbijanie dużych projektów na fazy i etapy Terminy „etap” i „faza” mają bardzo podobne znaczenie. Uwidaczniają one podział projektu na logicznie uzasadnione części, np. według cyklu życia projektu – faza analizy, projektowania etc. Ważne jest, aby dążyć do ujednolicenia hierarchii tych terminów. Jeśli uznamy, że faza opisuje większą część, a etap to składowa fazy, to dobrze jest, by podział ten stosowany był we wszystkich projektach. Jeśli zdecydujemy odwrotnie, że etap jest większy, a faza to składowa część etapu – nie robi to żadnej różnicy – o ile będzie to stosowane konsekwentnie. Drugą ważną sprawą jest to, że faza i etap powinny kończyć się jakimś kamieniem milowym lub przedmiotem dostawy. Musimy ustalić co będzie świadczyć o tym, że zakończyliśmy etap 1 i możemy wejść do etapu 2. 2.1.6.P8 Tworzenie słownika WBS dla dużych projektów Zazwyczaj słownik nie będzie potrzebny, lecz jeśli w WBS znajdują się setki (lub tysiące) zadań elementarnych, trudno będzie opanować taką złożoność. Słownik pomaga porządkować zadania elementarne i sumaryczne. Może zawierać krótkie opisy, wyjaśnienia np. numerów kodów zadań z WBS (1.1, 1.1.1, 1.1.2, itp.). Będzie to szczególnie pomocne, gdy WBS będzie używany w kolejnych projektach, w przyszłości. 2.1.6.P9 Zadania sumaryczne jako kamienie milowe w harmonogramie Do diagramu sieciowego wpisujemy wyłącznie zadania elementarne z WBS. Aby poprawić jego czytelność, warto jest dodać kamień milowy po ostatnim zadaniu elementarnym, które kończy zadanie sumaryczne. Będzie to pomagało w zorientowaniu się czy projekt ogólnie realizuje zakładany harmonogram.
134 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.6.P10 Rozbijaj zadania sumaryczne na dwa lub więcej zadania elementarne Nie ma sensu zapisywanie tylko jednego zadania elementarnego pod sumarycznym. Jeśli coś takiego zauważysz musisz:
rozbić zadanie sumaryczne, albo: usunąć zadanie sumaryczne, a elementarne przyporządkować do innego zadania sumarycznego. 2.1.6.P11 Zadania elementarne powinny pokazywać co ma być wykonane Zadania elementarne w WBS zostaną umieszczone w harmonogramie. Dlatego powinny być tak nazwane, by jednoznacznie wskazywać na to, co w ich wyniku ma być robione (jakie czynności). Na przykład zamiast „analiza rynku” należy wpisać „przeprowadzenie analizy rynku”, zamiast „Plan testowania” należy wpisać „Tworzenie planu testowania”. W harmonogramie zadanie elementarne nie może być rzeczownikiem, gdyż rzeczownikami określamy wyłącznie przedmioty dostawy. 2.1.6.P12 Nie umieszczaj cech przedmiotów dostawy w WBS Zadania elementarne z WBS zostaną przeniesione do harmonogramu. Dlatego muszą być sformułowane syntetycznie i prosto. Jakby wyglądał harmonogram projektu ,gdyby zawierał opisy np.: „edytor CMS, którego głównym elementem jest prosty interfejs” lub “latarka, która musi być w stanie działać 25 metrów pod wodą”. Cechy przedmiotów dostaw zapisuje się w innych dokumentach. 2.1.6.P13 Dla dużych projektów WBS można zostawić na poziomie pakietów marko zadań W dużych projektach umieszczanie szczegółowych przedmiotów dostaw i zadań elementarnych może być niewygodne. Zostawia się więc go na poziomie makrozadań i zadań. Ważne jest jednak, aby za dekompozycję każdego był odpowiedzialny jakiś zespół. On przetworzy i zdekomponuje makrozadanie na etapie planowania operacyjnego.
135 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.6.1 Tworzenie harmonogramu i budżetu / Przykłady WBS 2.1.6.1.P1 WBS jest pierwszym etapem tworzenia harmonogramu. To nie jest harmonogram sam w sobie. Ważne jest, aby używać WBS do identyfikacji pracy - wszystkich głównych zadań, które należy wykonać. Nie jest ważne na tym etapie określanie kolejności zadań czy szacowanie czasu trwania i kosztów. Zostanie to wykonane później. Poniżej znajdują się typowe przykłady WBS. WBS Rodzajowe (klasyczne) Przykład pokazuje rodzajowe rozbicie przedmiotu dostawy na pakiety zadań, zadania i czynności. Poziomy pakietów pracy oraz czynności są nieobowiązkowymi. Twoje WBS może przejść od przedmiotów dostawy do zadań.
1.0 Przedmiot dostaw (opcjonalny)
(opcjonalny)
1.1 Pakiet pracy 1
1.2 Pakiet pracy 2
1.3 Pakiet pracy 3
1.2.1 Zadanie 1
1.2.2 Zadanie 2
1.2.3 Zadanie 3
1.2.2.1 Czynność 1
1.2.2.2 Czynność 2
1.2.2.3 Czynność 3
136 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
WBS w oparciu o główne fazy projektu Fazy znajdujące się na poziomie 1 nie muszą być opisane według porządku chronologicznego. 0.0 Projekt XXX
1.0 Faza 1 Analiza
3.0 Faza 3 Tworzenie
2.0 Faza 2 - Projekt
1.1 Wymagania procesu
2.1 Udogodnienia
1.2 Wymagania danych
2.2 Sprzęt
3.1.1 Peru
2.3 Ludzie
3.1.2 Chiny
1.2.1 Ustalenie pól bazy danych 1.2.2 Zainstalowanie narzędzia do modelowania danych
3.1 Lokalizacja
2.3.1 Pełny etat
3.1.3 Kanada
2.3.2 Niepełny etat
3.2 Badanie
2.3.3 Tymczasowi
3.3 Nowe projekty
1.3 Projekt koncepcyjny
WBS w oparciu o chronologię W przykładzie tym WBS oparte jest o kolejność głównych komponentów, które należy wykonać.
0.0 Pływalnia
1.0 Krajobraz
2.0 Roboty gruntowe
3.0 Beton
4.0 Instalacja hydrauliczna
1.1 Projekt krajobrazu
2.1 Tworzenie wykopu
3.1 Tworzenie form
4.1 Budowa pompowni
1.2 Zamówienie / otrzymanie sadzonek krzewów
2.2 Usuwanie ziemi
3.2 Nalewanie betonu/stygnięcie
4.2 Instalowanie instalacji hydraulicznej
1.3 Sadzenie krzewów
2.3 Tworzenie konturów
3.3 Usuwanie form
4.3 Instalowanie pomp
1.4 Tworzenie drewnianych pomostów
2.4 Przywożenie górnej warstwy gleby
3.4 Malowanie i kafelkowanie
4.4 Instalowanie sprzętu do czyszczenia
137 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
WBS w oparciu o przedmioty dostaw Należy najpierw określić wszystkie przedmioty dostaw, a następnie podzielić je na prace. 0.0 Projekt multimedialny
1.0 Książka
2.0 CD
3.0 Taśma wideo
1.1 Pisanie
2.1 Tworzenie
3.1 Tworzenie
1.2 Publikowanie
2.2 Nagrywanie
3.2 Nagrywanie
1.3 Produkcja
2.3 Produkcja
3.3 Produkcja
1.4 Sprzedaż
2.4 Sprzedaż
3.4 Sprzedaż
1.4.1 Detaliczna
2.4.1 Detaliczna
3.4.1 Detaliczna
1.4.2 Wysyłkowa
2.4.2 Wysyłkowa
3.4.2 Wysyłkowa
138 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.7 Tworzenie harmonogramu i budżetu / plan kont kosztowych 2.1.7.P1 Wiele projektów ma jeden ogólny budżet, który zawiera wszystkie koszty projektu: pracy, sprzętu, oprogramowania, materiałów, itp. Jest to dobre dla małych i średnich projektów. Jednak, kiedy projekt się rozrasta, pomocne będzie rozbicie ogólnego budżetu na mniejsze, szczegółowe. Koncepcja ta jest podobna do rozbijania długotrwałego projektu na podprojekty. Budżet cząstkowy umożliwia lepsze kontrolowanie kosztów i wydatków w codziennym zarządzaniu projektem. Można również szybciej zauważać potencjalne problemy z kosztami, niż w przypadku jednego skonsolidowanego budżetu. Konta kosztowe powinny służyć do alokowania budżetu na najniższym poziomie. Są one formalnie utworzone w zakładowej księdze głównej, tak, że twój budżet jest właściwie podzielony między te konta. Wszelkie wydatki projektu są więc księgowane na tym właśnie poziomie rozdrobnienia. Konta mogą być zorganizowane na kilka sposobów. Jedno podejście – to proste podzielenie różnych typów kosztów na różne konta. W tym podejściu, mógłbyś mieć konto dla kosztów pracy, kosztów pracy kupowanej na zewnątrz, kosztów sprzętu, oprogramowania, szkoleń, podróży itp. Innym sposób strukturalizowania kont kosztowych jest oparty na WBS. Po zakończeniu WBS można utworzyć konta dla każdej grupy powiązanych zadań. Teoretycznie można by stworzyć konto dla każdego zadania. Nie ma to jednak sensu. Zamiast tego można tworzyć osobne kont i budżet dla każdej fazy, etapu czy kamienia milowego (czyli dla każdego ukończonego przedmiotu dostawy lub ich grupy). Jeśli utworzysz plan kont dla powiązanych zadań bazując na WBS, istnieje kilka opcji śledzenia wykonania budżetu. Można sprawdzać tylko koszty pracy (wewnętrzne i zewnętrzne) związane z zadaniami. Inną opcją jest śledzenie wszystkich kosztów pracy oraz kosztów pozapłacowych związanych z konkretnymi zadaniami. Różne typy kosztów można zdefiniować przy pomocy subkont w ramach każdego konta. Oczywiście, im bardziej szczegółowe są rachunki kosztów, tym więcej pracy będzie przy tworzeniu, alokowaniu i śledzeniu budżetu. Jednak jeśli dany projekt jest duży i kosztowny, dobrym pomysłem jest wykorzystanie tej techniki. W bardzo dużych projektach, budżet na pojedyncze konto kosztowe może być większy niż cały budżet projektu w niektórych organizacjach.
139 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.1.8 Tworzenie harmonogramu i budżetu / Ścieżka krytyczna
Jeśli używa się narzędzia do planowania projektu, czynności na ścieżce krytycznej są często oznaczone czerwonym kolorem!
2.1.8.P1 Ścieżka krytyczna to układ zadań, w którym opóźnienie któregokolwiek elementu spowoduje opóźnienie daty zakończenia całego projektu. Zawsze śledź ścieżkę krytyczną. Dzięki temu będziesz wiedział, czy możesz pozwolić na przedłużenie realizacji danego zadania oraz jak długie może być opóźnienie. Poza tym, gdy projekt będzie opóźniony nie ma sensu angażować dodatkowych pracowników w zadania, które nie leżą na ścieżce krytycznej. Zauważ, że ścieżka krytyczna może zostać określona tylko wtedy, kiedy ustaliłeś powiązania wszystkich zadań w harmonogramie. Jeśli istnieje jakiekolwiek zadanie (poza początkowym i końcowym) które nie ma przypisanego poprzednika i następnika –nie wyznaczysz prawidłowej ścieżki krytycznej! 2.1.8.P2 Logika ścieżki krytycznej W każdym projekcie bez względu na to, jak jest skomplikowany, istnieją czynności, które można rozpocząć wcześniej lub zakończyć później bez wpływu na termin zakończenia całego projektu. Ten elastyczny okres - pomiędzy najwcześniejszym momentem rozpoczęcia zadania i najpóźniejszym momentem, kiedy MUSI zostać ono rozpoczęte zwany jest buforem. Analogicznie, bufor ten występuje między najwcześniejszym momentem, gdy zadanie może zostać zakończone, a momentem kiedy zadanie MUSI być zakończone najpóźniej. Z definicji, zadania na ścieżce krytycznej mają zerową elastyczność, czyli nie mają żadnych buforów. Zadania na ścieżce krytycznej nie mogą zostać rozpoczęte wcześniej, ponieważ czekają na zakończenie innych zadań. Nie mogą również zostać zakończone później, gdyż opóźni to rozpoczęcie następnych zadań. Wszystkie one są ściśle powiązane ze sobą. Ścieżka krytyczna składa się z najdłuższej sekwencji zadań. Jeśli jedna z czynności na ścieżce krytycznej jest spóźniona, cały projekt zostanie opóźniony (chyba że można nadrobić stracony czas w innym miejscu na ścieżce krytycznej).
140 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ścieżka A
A
Ścieżka B
B
Ścieżka C Ścieżka D
F C E
I D
G
O
P
K H
L N
M Q
J Koniec Czas
Ścieżka B jest ścieżką krytyczną, ponieważ wszystkie czynności na niej następują od razu po sobie. Nie ma ona żadnego bufora. Inne ścieżki są elastyczne. To oznacza, że w pewnym momencie będą czekały, na zakończenie innych zadań, aby cały projekt mógł się zakończyć. Na przykład, projekt trwa dziewięć miesięcy. Twoje narzędzie planowania identyfikuje ścieżkę krytyczną. Załóżmy, że na ścieżce krytycznej znajdują się 22 zadania. Wszystkie mają inny czas trwania i pracochłonność. Oszacowano, że drugie zadanie na ścieżce krytycznej zostanie zakończone w ciągu ośmiu dni. W trakcie trwania projektu okazuje się, że zadanie to będzie tak naprawdę trwać dziewięć dni. W takiej sytuacji cały projekt będzie trwał dziewięć miesięcy i jeden dzień. Opóźnienie wykonania drugiego zadania o jeden dzień spowoduje przesunięcie harmonogramu dla całego projektu też o jeden dzień. Jeśli nie można nadrobić straconego czasu w innym miejscu, na ścieżce krytycznej, projekt na pewno zostanie opóźniony. 2.1.8.P3 Dlaczego ścieżka krytyczna jest ważna? Tak naprawdę w wielu przypadkach nie ma potrzeby określania ścieżki krytycznej. Odnosi się to szczególnie do małych projektów. Jednak dla dużych i bardziej złożonych projektów ważne jest, aby zrozumieć ścieżkę krytyczną. Jeśli projekt ma tendencję do opóźnienia oraz jeśli aktywnie próbuje się wrócić na „zaplanowane tory”, bardzo ważne jest, aby zidentyfikować czynności na ścieżce krytycznej. Jeśli nie można przyśpieszyć zadań na ścieżce krytycznej, data końcowa dla całego projektu pozostanie taka sama. Dodanie dodatkowych zasobów do zadań, które nie znajdują się na ścieżce krytycznej może pozwolić na wcześniejsze zakończenie tych czynności. Nie wpłynie to jednak na datę końcową całego projektu. Jedyna szansa na to, by wpłynąć na datę zakończenia projektu, jest związana ze zdolnością skrócenia ścieżki krytycznej. 2.1.8.P4 Ścieżka krytyczna może się zmienić Może istnieć wiele ścieżek krytycznych, Zazwyczaj występuje to wtedy, gdy zaplanowano wiele zadań równolegle. Jest bardzo możliwe, że w trakcie projektu, ścieżka krytyczna będzie się zmieniać. Gdy jedne zadania się opóźnią, a inne przyspieszą – zadania ze starej ścieżki mogą oczekiwać na zakończenie jakichś prac. Wtedy na pewno zadania oczekiwane stają się krytyczne. Rozważmy podobny przykład, (najdłuższa ścieżka to 22 zadania planowane na dziewięć miesięcy). Załóżmy, że istnieje dodatkowa ścieżka, zawierająca 19 zadań, które 141 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zabierają 8 ½ miesiąca. Jeśli spróbuje się przyspieszyć harmonogram i zakończyć pracę w ciągu ośmiu miesięcy, zaczynają się problemy. Najpierw skupiasz się na ścieżce krytycznej trwającej dziewięć miesięcy. Jednak, kiedy ścieżka ta zostaje zredukowana do 8 ½ miesiąca, druga ścieżka stanie się także krytyczna, gdyż trwa tyle samo. Dalsze skracanie pierwszej ścieżki krytycznej nie spowoduje już wcześniejszego zakończenia projektu. Zakończenie drugiej ścieżki w dalszym ciągu zajmie 8 ½ miesiąca. W takim przypadku obie ścieżki muszą zostać skrócone. Można sprawdzić, czy są zadania wspólne dla obu ścieżek i przyspieszyć je. Innym sposobem zmiany ścieżki jest sytuacja, kiedy ścieżka krytyczna ma opóźnienie. W powyższym przykładzie, załóżmy, że jedna z czynności na trwającej 8 ½ miesiąca ścieżce zajmie dodatkowe trzy tygodnie. Ponieważ istniały tylko dwa tygodnie bufora w relacji do pierwszej, dziewięciomiesięcznej ścieżki, stanie się ona teraz ścieżką krytyczną. Przesunie to również zakończenie całego projektu o jeden tydzień. 2.1.8.P5 Obliczanie ścieżki krytycznej
ES
EF
1 dzień
1 dzień ES – najwcześniejsze rozpoczęcie EF – najwcześniejsze zakończenie
LS
LF
LS – najpóźniejsze rozpoczęcie LF – najpóźniejsze zakończenie
Ścieżkę krytyczną można obliczyć „ręcznie”. Wylicz najwcześniejsze daty rozpoczęcia (ES) oraz najwcześniejsze dat zakończenia (EF) dla każdego zadania – idąc od początku do końca projektu. Następnie idź od końca projektu i cofaj się sprawdzając najpóźniejsze możliwe daty rozpoczęcia (LS) oraz najpóźniejsze daty zakończenia (LF) dla każdego zadania. Różnica pomiędzy najwcześniejszą a najpóźniejszą datą rozpoczęcia każdego zadania to bufor (różnica ta powinna ona być równa różnicy najwcześniejszego i najpóźniejszego terminu zakończenia zadania). Następnie sprawdź, która (które) sekwencja ma zerowy bufor. Jest to ścieżka krytyczna.
142 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W przód
1
5
__
4 dni 0
__
__
3 dni
__
1 dzień
1
__
1 dzień
__
2 dni
1
6
__
5 dni
__
6 dni
Metoda „w przód”: rozpocznij od pierwszego zadania w diagramie sieciowym od obliczaniu najwcześniejszej daty rozpoczęcia zadania (ES) oraz najwcześniejszej daty zakończenia(EF). Wyznacz te wielkości analizując kolejne, następujące zadania, aż do zadania ostatniego.
4 dni __
3 dni __
__
1 dzień __
11
12
1 dzień __
2 dni
__
12
5 dni __
14
6 dni __
6
12
W tył Kiedy zostaną określone daty najwcześniejszego rozpoczęcia i zakończenia metodą „w przód” należy przeliczyć najpóźniejsze daty rozpoczęcia i zakończenia metodą „w tył”.
143 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Cofając się od zadania ostatniego, do zadania pierwszego w diagramie sieciowym. Obecnie wszystkie pakiety oprogramowania wspierającego planowanie i zarządzanie projektem automatycznie wyznacza ścieżkę krytyczną.
1
5
5
8
4 dni 0
1
4
8
3 dni
Bufor = 3
8
9
1 dzień
8 11Bufor = __
11 12 Bufor = __
1 dzień 0
Bufor = 0
12
14
2 dni 1
12 14 Bufor = __ 1
6
6
5 dni 1
12
6 dni
Bufor = 0
6
6
Bufor = __
12
Bufor = Najpóźniejsze Zakończenie – Najwcześniejsze Zakończenie 2.1.8.P6 Bufor zadania, ścieżki, projektu Bufor zadania to ilość czasu o jaką może zostać opóźnione zadanie bez jakichkolwiek konsekwencji. Jest to czas, jaki dzieli planowane zakończenie zadania od planowanego rozpoczęcia następującej po nim czynności. Jeśli zadanie B może rozpocząć się pięć dni po zakończeniu zadania A bez wpływu na inne zadania, bufor zadania A wynosi pięć dni. Bufor ścieżki to okres o jaki można bez konsekwencji opóźnić daną ścieżkę. Upływa on od daty zakończenia ostatniego zadania na ścieżce do daty rozpoczęcia kolejnego, następującego po nim zadania. Bufor ten jest sumą buforów wszystkich zadań na tej ścieżce. Jeśli jedno zadanie z wykorzysta trochę swojego bufora, zmniejsza tym samym bufor całej ścieżki dostępny dla kolejnych zadań. Na przykład powiedzmy, że masz trzy czynności na ścieżce – A, B, C – każda z buforem pięciu dni. Bufor ścieżki również wynosi 5 dni. Jeśli czynność A rozpocznie się na czas i zakończy planowo, czynność B w dalszym ciągu ma 5 dni buforu. Jednak jeśli czynność A zostanie opóźniona o trzy dni, bufor ścieżki zostanie również zredukowany o trzy dni. Pozostaną dwa dni bufora ścieżki. W krańcowym przypadku załóżmy, że zakończenie czynności A zabierze dodatkowe 15 dni. Dla czynności B i C oznaczać to będzie, że nie mają żadnego bufora. Należy pamiętać, że bufor ścieżki wyznaczany jest dla całej ścieżki. Jeśli jedna czynność zużyje cały bufor ścieżki, brak będzie bufora dla pozostałych czynności na ścieżce. Przy zerowym buforze jest to teraz ścieżka krytyczna.
144 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Bufor projektu to suma wszystkich buforów pomiędzy wszystkimi zadaniami na wszystkich ścieżkach. Jeśli całkowity bufor jest wysoki, masz zazwyczaj więcej opcji co do alokowania zasobów i łatwiej zakończysz projekt w terminie. Jeśli bufor projektu jest niewielki, ryzyko harmonogramowe wzrasta ze względu na mniejszą elastyczność. Jeśli dany projekt zacznie się opóźniać, trudniej będzie przemieścić zasoby, ponieważ opóźnienie kolejnej ścieżki, może sprawić, że stanie się ona ścieżką krytyczną.
145 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.2 Tworzenie harmonogramu i budżetu / Techniki 2.2.P1 Używanie poprzednich podobnych harmonogramów oraz gotowych wzorów harmonogramów Technika WBS może zostać zawsze użyta, aby stworzyć harmonogram od zera. Jednak WBS nie jest zawsze najbardziej efektywnym sposobem planowania. Najlepszym sposobem jest próba zmodyfikowania i ponownego użycia harmonogramu, który został stworzony wcześniej. Na przykład, jeśli podobny projekt został już kiedyś zakończony, należy zacząć od tego projektu. Potraktować go jako wzór i odpowiednio modyfikować. Oszczędzi to nakładów związanych z etapem identyfikacji niezbędnych prac. Jest to szczególnie wartościowe, jeśli poprzedni kierownik projektu uaktualniał harmonogram. Wtedy będziemy mieć dostęp do wielu informacji m.in. pokazujących relację harmonogramu bazowego do rzeczywistego. Jeśli nie mamy harmonogramu z podobnego projektu, należy sprawdzić, czy firma posiada gotowe wzory harmonogramów. Na przykład, dana firma może mieć opracowaną własną realizacji projektów o danej specyfice. W takim przypadku należy sprawdzić, czy twój projekt odpowiada jednemu ze wzorów. Jeśli tak- można go użyć jako punktu wyjścia. Należy jednak być ostrożnym. Gotowe wzory z takiej metodyki mogą być za duże lub za skomplikowane. Autor tworząc je, mógł dążyć do tego by były uniwersalne i adekwatne dla danego typu projektu. Po stwierdzeniu, że dany wzorzec pasuje, kierownik projektu musi przeanalizować zadania zapisane w nim i usunąć te, które nie mają zastosowania w jego projekcie. 2.2.P2 Tylko jedna osoba może być odpowiedzialna za zadanie Typowym błędem jest przyporządkowanie dwóch lub więcej osób do zadania bez określenia, kto jest osobą odpowiedzialną. Powoduje to, że ludzie mogą liczyć na zaangażowanie lub poczucie obowiązku innych, a praca, która ma się szybko rozpocząć, zostanie nietknięta. Trudno jest wyciągać konsekwencje wobec takiego stanu rzeczy. Każdy będzie uważać, że to ktoś inny zawinił. 2.2.P3 Określenie zasobów indykatywnych, następnie konkretnych osób W wielu przypadkach, w trakcie tworzenia harmonogramu nie znasz nazwisk realizatorów zadań. Nie wiesz kto będzie w zespole, szczególnie, gdy określasz zasoby dla długiego projektu. W tych przypadkach należy użyć tzw. zasobów indykatywnych. Na przykład trzy miesiące po rozpoczęciu projektu będziesz potrzebował zamodelować dane. W harmonogramie zaznacz jedynie rodzaj pracownika, jaki będzie niezbędny np. model danych nr 1. Potem, kiedy będzie się zbliżał termin, gdy będzie potrzebna konkretna osoba, uaktualnisz harmonogram, wpisując konkretne nazwisko.
146 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.2.P4 Angażuj ludzi do projektu na pełen etat, jeśli jest to możliwe W wielu przypadkach zespół projektowy składa się z pracowników pełnoetatowych oraz niepełnoetatowych. Zazwyczaj jest to związane z rozmiarem organizacji, rozmiarem projektu, dostępnymi środkami oraz tym, jak zorganizowany jest dział funkcyjny. Jednak jeśli możesz, powinieneś w projekcie najpierw wykorzystywać ludzi pracujących na pełen etat. Na przykład, więcej zostanie wykonane przez jednego pełnoetatowego pracownika niż przez pięciu, którym przyporządkowane jest po 20% pracy, wynika to choćby z różnej produktywności oraz czasu potrzebnego na „przestawienie się”. Zasoby niepełnoetatowe mają inne zadania, priorytety oraz kierowników. Jest to szczególnie widoczne, jeśli pracownicy mają obowiązki częściowo związane z projektem a częściowo z pracą operacyjną. Sprawy bieżące, codzienne są z reguły ważniejsze w stosunku do projektu. Również w wielu przypadkach pracownicy nie są w stanie efektywnie zarządzać różnymi obowiązkami. To wymusza większą kontrolę przez kierownika projektu. 2.2.P5 Zbieranie dodatkowej informacji zwrotnej, jeśli kierownik projektu nie zna wszystkich szczegółów Kierownik projektu jest osobą odpowiedzialną za zarządzanie projektem w sposób gwarantujący sukces. Jest osobą, która musi stworzyć wiarygodny harmonogram, Jeśli ktoś inny tworzył wstępny harmonogram, musi on zostać przeanalizowany i zmodyfikowany przez kierownika projektu. Kierownik zatwierdza ramy czasowe, budżet oraz przedmioty dostaw, których tworzenie opisuje harmonogram. W innym przypadku kierownik projektu zbyt łatwo mógłby pozbyć się odpowiedzialności za wykonanie planu. Nie mógłby być odpowiedzialny za harmonogram, którego nie stworzył. TenStep nie dopuszcza czegoś takiego! Ponieważ kierownik projektu nie zawsze posiada odpowiednią ilość informacji, aby samemu stworzyć cały plan, może skorzystać z dwóch głównych technik:
Stworzenie szkicu i przesłanie go interesariuszom. W tej technice kierownik projektu tworzy wstępny szkic harmonogramu. Mogą w to być również zaangażowani inni członkowie zespołu. Kiedy szkic zostanie zakończony przedstawiany jest interesariuszom w celu uzyskania informacji zwrotnej. Podczas procesu sprawdzania, zadania są dodawane, zmieniane lub usuwane. Kierownik projektu zbiera informacje zwrotne i modyfikuje harmonogram.
Istnieją
dwa potencjalne zagrożenia korzystania z tej techniki. Pierwsza. Interesariusze mogą nie być jeszcze w pełni zaangażowani w projekt. Mogą zignorować zupełnie harmonogram przesłany przez kierownika lub przeanalizować go bardzo pobieżnie, nie przekazując swoich uwag.
Po
drugie, jeśli harmonogram jest szczegółowy i długi, prawdopodobnie większość interesariuszy nie będzie w stanie go zrozumieć. W takim przypadku musi być pokazany na poziomie makrozadań, zadań głównych i ważniejszych kamieni milowych. W tej sytuacji interesariusze mogą nie udzielić wartościowych wskazówek kierownikowi projektu.
147 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Tworzenie
WBS oraz harmonogramu angażując bezpośrednio interesariuszy. W tej technice harmonogram jest tworzony podczas jednej lub wielu sesji wraz z głównymi interesariuszami. Możliwe jest zebranie wszystkich interesariuszy na sesję trwającą jeden lub więcej dni. Celem sesji będzie osiągnięcie konsensusu co do tego, co ma zostać wykonane. Jeśli projekt jest duży, możliwe, że konieczne będzie spotkanie się z głównymi interesariuszami w grupach. Na przykład, możemy organizować sesje w każdym dziale. Później tworzony harmonogram projektu poprzez konsolidację harmonogramów cząskowych. Zaletą tej techniki jest pełne zaangażowanie i aktywny udział interesariuszy. Muszą oni być w pełni przekonani co do pracy, którą należy wykonać. Technika ta może (ale nie musi) trwać dłużej i wymagać więcej pracy niż opcja pierwsza. Zależy to od ilości sesji, które muszą być przeprowadzone oraz od tego, jak szybko wyniki sesji mogą zostać skonsolidowane i odesłane do osób w nich uczestniczących w celu uzyskania ich akceptacji.
2.2.P6 Realizacja projektów w sztywnych terminach (Timeboxing) W świecie idealnym daty zakończenia projektu uzyskiwane byłyby w oparciu o wyliczenie ilości prac do wykonania oraz ilość dostępnych zasobów. Niestety nie zawsze to jest możliwe. Czasami istnieje narzucona data, do której praca musi zostać zakończona. Na przykład może ona zostać określona przez regulacje prawne lub inne planowane wydarzenie. Może ona również zbiegać się z inną inicjatywą w firmie. Taka sytuacja określana jest jako “timebox”. W wolnym tłumaczeniu oznacza to, że mamy określony okres (box) czasu na wykonanie całej pracy oraz nieprzekraczalne terminy, które zostały ustalone „na sztywno”. Nieprzekraczalna, ustalona z góry data końcowa nie jest sama w sobie zła. Podnosi to rangę projektu, zmusza do zrozumienia wartości biznesowej przedsięwzięcia, mobilizuje zespół projektowy i zmusza do koncentracji na projekcie. Może się jednak pojawić problem, jeśli kierownik projektu oraz zespół nie wierzą, że uda im się wykonać pracę przed określonym terminem. W takim przypadku kierownik projektu powinien odnieść się do tego jak do problemu krytycznego. Możliwe są następujące rozwiązania:
Przyporządkowanie
większej ilość zasobów do projektu. Wprawdzie każdej dodatkowej osoby może deprecjonować wartość projektu. Może sprawiać, że np, w systemie motywacyjnym ta sama pula pieniędzy będzie dzielona na większą liczbę pracowników.
Zespół pracujący w nadgodzinach. Należy być świadomym, że każda dodatkowa
godzina jest mniej produktywna od poprzedniej oraz że dłuższe nadgodziny będą tak naprawdę miały negatywny wpływ na morale pracowników.
Przekonanie klienta, aby zmniejszyć jakość wymaganą od przedmiotów dostaw. Określanie, czy niektóre przedmioty dostaw mogą zostać wyprodukowane w terminie późniejszym niż ustalony. W tych przypadkach 90 % rozwiązania może zostać wykonana w przewidzianym terminie, reszta zaraz po nim.
2.2.P7 Stosowanie wielu technik szacowania pracy, jeśli jest to możliwe
148 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ważną częścią tworzenia harmonogramu jest dokładne oszacowanie czasu trwania, pracochłonności i kosztów zadań. Szczegóły patrz: 2.2.1 Techniki szacowania.
149 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.2.P8 Spędzanie więcej czasu przed projektem, by zaoszczędzić czas później Czy większość problemów napotykanych podczas projektu nie pojawia się, gdy zbliża się koniec projektu? Niektórzy kierownicy projektu celowo przyspieszają planowanie, analizę oraz projektowanie rozwiązania, ponieważ uważają, że znajdą wszelkie błędy np. w procesie testowania. Niestety im później wyłapie się błędy, tym więcej czasu i nakładów trzeba poświęcić, aby je naprawić. Choć definiowanie projektu i budowanie harmonogramu trwa (czasem nie mało czasu), powinno to pomóc zaoszczędzić czas i koszty w całym projekcie. Na przykład spędzenie większej ilości czasu na planowaniu oszczędzi czas przy analizie. Spędzenie większej ilości czasu na analizie sprawi, że prace będą przebiegały sprawniej. Poświęcenie czasu na sprawdzaniu przedmiotów dostaw zmniejszy ilość błędów i oszczędzi czas przy testowaniu. Dokładne testowanie zaoszczędzi czas poświęcony na wdrażanie i serwis. Oczywiście, nie należy planować i analizować zbyt dokładnie. To w niczym nie pomoże. Należy być skrupulatnym w pracy i nie należy się spieszyć. Czas poświęcony wcześniej zwróci się podczas projektu. 2.2.P9 Tworzenie harmonogramu dla etapu definiowania i planowania pracy Procesy tworzenia Definicji Projektu, harmonogramu i budżetu mogą zabrać dużo czasu. Może również to być bardzo skomplikowane. Dlatego praca ta nie powinna być chaotyczna i improwizowana, z tych samych powodów, dla których tworzysz harmonogram dla przyszłego projektu. Zaraz po swojej nominacji, kierownik projektu powinien stworzyć krótki harmonogram procesu definiowania i planowania. Jeśli proces planowania potrwa dwa tygodnie, kierownik projektu powinien stworzyć harmonogram na przy najmniej dwa, trzy tygodnie. Harmonogram ten zawiera wszystkie czynności organizacyjne oraz czynności związane z planowaniem oraz formalnego zatwierdzania Definicji Projektu i harmonogramu Zaleca się, aby harmonogram definiowania i planowania był budowany w oparciu o jednolity dla całej organizacji, zdefiniowany i zaakceptowany proces planowania i zatwierdzania projektu. 2.2.P10 Określanie, czy będzie się zapisywać rzeczywistą pracochłonność Należy bardzo wcześnie podjąć decyzję, czy będziesz odnotowywać faktyczną pracochłonności w harmonogramie. Na przykład załóżmy, że pracochłonność zadania wyniesie 40 godzin, a czas trwania 10 dni. Wiesz, kiedy dane zadanie zostanie zakończone, możesz więc porównać szacowany czas trwania oraz faktyczny. Jednak, czy będziesz zapisywać, czy pracochłonność faktycznie wyniosła 40 godzin? Zanotowanie rzeczywistej pracochłonności wymaga większego zaangażowania ze strony zespołu projektowego. Zespół musi zapisywać i raportować rzeczywisty czas poświęcony na wykonanie przydzielonych zadań. Ma to ogromną wartość. Pomaga w osiągnięciu dokładniejszych oszacowań w przyszłości. Jednak wiele organizacji nie odnotowuje rzeczywistych pracochłonności, wtedy szczególnie trudno będzie przekonać do tego zespół. 2.2.P11 Minimalizowanie czasu niepotrzebnego oczekiwania i przestojów Jeśli projekt składa się z jednej ścieżki krytycznej i kilku zaledwie innych ścieżek, o ogromnych buforach, może to powodować, że zadania zbyt długo czekają na prace po 150 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
nich następujące. Taki nadmierny „luz” w harmonogramie nie jest również wskazany. Diagram sieciowy jest nadmiernie rozciągnięty i taka sytuacja może mieć następujące konsekwencje:
Wielu
pracowników jest angażowanych w projekt. Po wykonaniu zadania przerywają pracę, po jakimś czasie znów „wchodzą” do projektu itd. To może powodować potencjalne problemy z ich dostępnością, szczególnie, że projekty o jakich mowa, mają relatywnie długi czas trwania.
W zadaniach poza ścieżką krytyczną często pracujesz z ludźmi na niepełny etat.
W okresie „przestoju” najczęściej szuka im się pracy niezwiązanej z projektami, aby przeczekali. Ale gdy nagle zaistnieje konieczność nieplanowanych prac, może okazać się trudne znalezienie realizatorów. Ludzie ci mogą być zaangażowani w inne, nie projektowe zajęcia. Podobnie płynne zmienianie przydzielanych zadań może nie być możliwe.
Z perspektywy wszystkich pracowników nie pracujących na ścieżce krytycznej
może się wydawać, że nie ma pośpiechu w pracach. Innymi słowy, będziesz miał jednego lub dwóch pracowników pracujących na ścieżce krytycznej i z określonymi terminami, podczas gdy reszta ma duże okresy przestoju w swoim harmonogramie. Może to być demotywujące dla zapracowanych.
2.2.P12 Brak czasów oczekiwania i przestojów Jeśli istnieje ryzyko związane ze zbyt dużą ilością luzu, istnieje również ryzyko zbyt „ściśniętych” harmonogramów. Jeśli masz zbyt mało luzu w harmonogramie, to małe opóźnienia na danej ścieżce sprawią, że staje się ona ścieżką krytyczną. Najlepiej jeśli harmonogram projektu można by tak tworzyć, aby ścieżki, które nie są krytyczne były “pełne, ale nie zbyt pełne”. Tak, aby grupy pracowników można było wykorzystać w danym projekcie bardziej efektywnie. 2.2.P13 Wpisywanie zadań w narzędziu do planowania w kolejności chronologicznej Im większy jest dany projekt, tym bardziej krytyczne jest wykorzystanie narzędzia do tworzenia harmonogramu i budżetu. Pomimo tego, że można wpisać zadania do narzędzia w dowolnej kolejności, łatwiej je będzie zrozumieć, jeśli wpiszesz je (lub posortujesz) w kolejności chronologicznej. To znaczy, że czynności, które mają być wykonane we wczesnej fazie, powinny być zapisane najpierw. Natomiast czynności z późniejszej fazy powinny pojawić się później. 2.2.P14 Planowanie z góry krytycznych zasobów Niektóre z ryzyk projektu związane są z zasobami i wymagają wcześniejszego rozważenia, w jaki sposób zareagujemy, jeśli będziemy musieli wymienić lub dodać ludzi. W niektórych przypadkach trzeba z góry planować, jak i skąd weźmiemy pracowników, jeśli zdarzy się coś nieprzewidzianego. Poniżej znajduje się kilka przykładów, jak planować z wyprzedzeniem zabezpieczenia projektu na wypadek problemów z ludźmi oraz zasobami.
Liczy
się czas. W wielu projektach, jeśli praca zajmuje więcej czasu niż przewidywałeś, możesz wnioskować o dodatkowy czas oraz budżet. Jeśli jednak termin jest krytyczny i nie może zostać przesunięty, możesz nie mieć czasu na poszukiwanie nowych ludzi, żeby zrealizować projekt. Podobnie, jeśli zespół
151 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
opuści jeden z członków, w bardzo krótkim czasie trzeba będzie znaleźć zastępstwo. Jednak jeśli terminy są niezmienne, a przedmioty dostaw krytyczne, trzeba mieć koncepcje, jak zabezpieczyć się na wypadek, gdyby nowi lub inni ludzie byli potrzebni. Na przykład, spójrz na projekty sprzed kilku lat, które miały przygotować całą światową informatykę na nadejście roku 2000. Gdy rozpoczynał się trzeci kwartał 1999 roku i potrzebowałeś więcej ludzi, nie było czasu ani chwili na ich poszukiwanie. Trzeba było mieć uprzednio przygotowany, gotowy plan zdobycia pracowników w krótkim okresie. Np. oznaczało to posiadanie własnych pracowników w rezerwie albo podpisane umowy z ludźmi z zewnątrz, gotowymi do podjęcia pracy w każdym momencie. Zasoby kupowane jednostkowo są droższe. Niekiedy zasoby będą tańsze, jeśli kupisz je hurtowo, a bardzo drogie, jeśli będą zamawiane jednostkowo. Na przykład, jeśli tworzone rozwiązanie wymaga nowego sprzętu komputerowego, można zauważyć, że cena jednostki jest niższa przy zakupie hurtowym. Powiedzmy, że potrzebujesz 100 ruterów. Dostawca może przedstawić bardzo atrakcyjną cenę za zakup hurtowy – 50 lub 60% ceny jednostkowej. W takim przypadku możesz zdecydować się na kupno 110, aby mieć dziesięć w rezerwie. Zrobisz tak, ponieważ cena zakupu dodatkowych dziesięciu jednostek (jako części większego zakupu) jest znacznie niższa niż przy późniejszym zakupie dziesięciu jednostek (ceny będą wtedy znaczenie wyższe). Długi czas pozyskiwania ekspertów. Zawsze sprawdzaj czy wystarczająco szybko będziesz mógł zaangażować w projekt specjalistów i ekspertów wysokiej klasy, jeśli będą oni nagle potrzebni. Na przykład, jeśli projekt ma za zadanie ustawienie nowej linii produkcyjnej, możesz potrzebować ekspertów od mało znanych, skomplikowanych urządzeń. Jednym ze sposobów radzenia sobie z takimi problemami, jest zakontraktowanie u dostawcy, z góry, na wszelki wypadek pracowników potrafiących udzielić wsparcia w zakresie wykorzystania tych urządzeń. Jeśli z twojego zespołu zrezygnuje ekspert ds. linii technologicznej, nie wpłynie to znacząco na prace projektu. Nie w każdym projekcie musisz z góry szczegółowo analizować dostępność i koszty pozyskania zasobów. Jednak jeśli masz intuicję, że twój projekt wymaga rzadkich zasobów lub trudnych do pozyskania pracowników, zadbaj o to, aby projekt nie został zatrzymany z powodu ich braku.
152 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
2.2.1 Tworzenie harmonogramu i budżetu / Techniki szacowania 2.2.1.P1 Techniki szacowania Poniżej opisano najważniejsze i najbardziej użyteczne techniki szacowania. Oczywiście, wiedza na temat estymacji jest znacznie szersza. TenStep zaleca korzystanie z niej. Dokładne opisy szczegółowych technik estymacji statystycznej, analiz ekonometrycznych, etc., są poza zakresem samej metodyki TenStep. Techniki estymacji można podzielić m.in. na dwie grupy:
top – down – polegają na szacowaniu całego projektu, a następnie poprawianie
tej estymacji poprzez oszacowania szczegółowe makrozadań, zadań, itd. Do tej rodziny należą estymacje oparte o dane historyczne, analogie etc. Techniki należące do tej kategorii są z reguły szybsze, jednak mniej dokładne.
bottom – up – to techniki pozwalające oszacować projekt po przez zsumowanie
estymacji szczegółowych – do takich technik należy choćby szacowanie bazujące na WBS. Techniki te są bardziej dokładne, aczkolwiek trwają i kosztują więcej, niż wykonanie szacowań metodą top – down. Dlatego najlepiej jest stosować jednocześnie kilka technik szacowania, szczególnie top – down. Poniżej przykłady najczęściej stosowanych:
Analiza
poprzednich projektów. Jest to jak do tej pory najlepszy sposób oszacowania projektu. Jeśli dana organizacja gromadzi informacje o faktycznej pracochłonności prowadzonych projektów, mogą one być pomocne w estymacji nowych przedsięwzięć. W tej metodzie najpierw poszukujesz projektów możliwie zbliżonych do twojego, realizowanych dawniej. Następnie porównujesz jak pierwotnie szacowano pracochłonność z tym ile faktycznie pracy potrzeba było na wykonanie projektu. Do określenia pracochłonności w twoim projekcie możesz użyć rzeczywistych pracochłonności projektów historycznych. Jednakże dobrze jest przejrzeć dokumentację lub odnaleźć osoby realizujące ten projekt. Może okazać się, że np. duże różnice między pracochłonnością planowaną i rzeczywistą wynikały z jakichś specyficznych warunków, które nie wystąpią w twoim projekcie.
Analiza
analogicznych projektów. Technika ta bazuje także na danych historycznych i to najlepiej projektów o zbliżonej charakterystyce do naszego. Wykorzystujemy ją, gdy kierownik nie analizował pracochłonności rzeczywistej. Oszacowania dokonujemy poprzez analizę czasów trwania zadań i czynności. Uznajemy, że jeśli projekt trwał dłużej o 20% to analogicznie o tyle wzrosła jego pracochłonność. Na przykład załóżmy, że wcześniejszy projekt został oszacowany na sześć miesięcy i 2000 godzin. Jeśli projekt faktycznie zakończył się w ciągu sześciu miesięcy, istnieje wysokie prawdopodobieństwo, że pracochłonność projektu wyniosła również około 2000. Z drugiej strony, jeśli projekt był przeładowany i zajął siedem miesięcy, możemy przyjąć, że pracochłonność wyniosła około 2300.
153 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Analiza
proporcji . Jeśli w organizacji był realizowany projekt o podobnej tematyce, ale większy lub mniejszy, warto przyjrzeć się mu dokładniej i metodą ustalania proporcji oszacować nowy projekt. Na przykład możesz obliczyć, że pracochłonność wymagana do zakończenia instalacji oprogramowania dla biura w Warszawie wynosi 500 godzin. Istotnym czynnikiem dla oszacowania jest ilość stanowisk na którym będzie instalowane oprogramowanie w danym biurze. Jeśli w Gdańsku jest dwa razy więcej stanowisk, możesz założyć, że pracochłonność wyniesie tam 1000 godzin.
Analiza opinii ekspertów. W wielu przypadkach będziesz musiał udać się do wewnętrznego lub zewnętrznego eksperta, aby uzyskać pomoc w szacowaniu. Na przykład, jeśli po raz pierwszy używasz nowej technologii, możesz potrzebować pomocy zewnętrznej jednostki badawczej. Może ona przedstawić Ci informacje potrzebne do szacowania. Wielokrotnie szacunki te oparte są na doświadczeniach innych firm. Możesz również skorzystać z eksperta wewnętrznego, który mógł szacować podobną pracę wielokrotnie.
Analiza
Delphi. Technika Delphi (technika delficka) jest podobna do opinii ekspertów. W tym przypadku pyta się jednocześnie kilku ekspertów. Najpierw należy zidentyfikować dwie lub więcej osoby, które będziemy uważać za ekspertów w danej dziedzinie. Następnie należy opowiedzieć im o zadaniu. Powinni teraz osobno określić pracochłonność, wraz z założeniami, które zostały przez nich przyjęte. Jeśli szacunki są zbliżone, nie powinieneś mieć problemu z użyciem średniej z nich w końcowych estymacjach. Może się zdarzyć, że oszacowania nie są zbliżone lub że niektóre szacunki są zbliżone do innych, a kolejne nie. W takiej sytuacji prześlij komplet estymacji ekspertom, niech przeanalizują ponownie wszystkie poprzednie oszacowania, wraz z przyjętymi założeniami. Możliwe jest, że gdy grupa ekspertów przejrzy opinie innych, uwspólni poglądy na temat szacowanych wielkości. Jeśli nie, należy użyć wartości wspólnych dla większości ekspertów, a opinię odrębną, możemy potraktować jako ryzyko oszacowań. Na przykład, jeśli trzech ekspertów oceniło pracę na około 1000 godzin, a jeden uważa, że zajmie 2000 godzin, będziemy oszacujemy pracę na 1000 godzin, z zastrzeżeniem, że pracochłonność może się zwiększyć dwukrotnie (w oparciu o opinię jednego eksperta).
Druga opcją jest (jeśli mamy czas i ochotę) poproszenie o inne opinie ekspertów.
Jeśli nowe opinie będą zbliżone do uzyskanej wcześniej wielkości, da nam to więcej pewności. Będziesz miał mniej pewności (będzie większe ryzyko), jeśli nowe oszacowania będą odbiegały od poprzednich.
WBS.
Proces tworzenia WBS opisano w rozdziale 2.1. Jednym z powodów budowania WBS jest łatwiejsza estymacja pracy. W dużych projektach może być trudno oszacować pracochłonność. Jednak, gdy praca zostanie rozbita na mniejsze zadania, poszczególne jej części dają się łatwiej oszacować. Kiedy oszacowałeś już wszystkie części, należy je zsumować, aby poznać ogólną pracochłonność.
Metoda
PERT (Program Evaluation and Review Technique). PERT służy obliczeniu bardzo prawdopodobnych wielkości pracochłonności i czasu trwania. Oblicza się je przeliczając trzy wielkości: wariant najbardziej pesymistyczny (P), w którym nic się nie udaje; wariant najbardziej optymistyczny (O), w którym wszystko się udaje; wariant najbardziej prawdopodobny (M), zakładający normalne problemy i możliwości. Te trzy wielkości podstawia się do PERT: (O + 4M + P)/6. Na przykład
154 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
załóżmy, że szacowana praca najprawdopodobniej zajmie 10 godzin. Najlepszy przypadek (wszystko się udaje) wynosi 6 godzin. Najgorszy (nic się nie udaje) wynosi 26. Z tego wynika szacowanie (6 + 4(10) + 26)/6. Odpowiedź to 72/6, lub 12 godzin. Należy zauważyć, że liczby zostały zaokrąglone pesymistycznie, aczkolwiek wariant jest nadal zbliżony do wartości prawdopodobnej. Zaleca się stosowanie analizy PERT przy użyciu programów wspomagających planowanie.
Modelowanie parametryczne. W tej technice musi istnieć wzór pozwalający na
użycie algorytmu, który pomógłby w całym procesie szacowania. Na przykład, jeśli wiesz, że możesz wybudować kilometr jednopasmowej drogi na płaskim terenie za jeden milion dolarów, powinieneś łatwo obliczyć wartość dla dziesięciu kilometrów czteropasmowej autostrady na płaskim terenie (40 milionów dolarów). Jeśli zostaniesz poproszony o stworzenie 40 nowych raportów, powinieneś najpierw ocenić czasochłonność dla “typowego raportu (typowy dla małych, średnich i dużych raportów). Następnie należy przemnożyć średnią pracochłonność raportu przez 40, żeby określić końcową wartość.
Analiza
funkcjonalności. Niektóre firmy budujące oprogramowanie używają analizy funkcjonalności jako podstawy do oszacowania projektu. Analiza funkcjonalności pozwala określić złożoność aplikacji. Aplikacja posiadająca ok. 100 funkcji jest o wiele bardziej uboga niż aplikacja realizująca 1.000 funkcji.
Bez analizy wielu szczegółów, funkcjonalność odnosi się do rozmiaru aplikacji z punktu widzenia użytkownika. Użytkownik widzi raporty, widoki, pliki danych, tabelki, inne systemy etc. Aplikacja z 80 ekranami oraz 20 raportami jest większa niż aplikacja z 20 screenami i 5 raportami. Ten sposób analizy wielkości jest niezależny od technologii oraz języka programowania. Aplikacja z mniejszą ilością ekranów może wymagać więcej linii kodów. Na tym etapie nie jest to jednak istotne, zwłaszcza gdy chodzi o określenie rzędów wielkości.
2.2.1.P2 Szacowanie w fazach Największym problemem w oszacowaniu, szczególnie dużych projektów, jest to, że nie wiemy co należy robić w bardzo odległej przyszłości. Łatwo jest zaplanować pracę na najbliższe trzy miesiące, trudniej na sześć, a bardzo trudno jest dokładnie zaplanować pracę na dziewięć miesięcy do przodu. Jednym z powodów jest choćby to, że najbliższe decyzje mogą mieć ogromny wpływ na to, co będzie dziać się później. I nasze bardzo dokładne plany sporządzone dziś, już za chwile, mogą okazać się nieaktualne. Im dłuższy okres, tym więcej niepewności. Najlepiej jest duży projekt podzielić na serię małych projektów. Każdy jest osobno definiowany, planowany i zarządzany, a prawdopodobieństwo sukcesu małego projektu jest zdecydowanie większe. Na początku szacujemy najbliższe projekty bardzo dokładnie. Te w dalszej przyszłości pozostawiamy na relatywnie dużym poziomie ogólności. Gdy zakończymy najbliższe projekty, wtedy dopiero poprawiamy stopień szczegółowości oszacowania dalszych prac. Zakończenie każdego projektu może być punktem kontrolnym. Patrząc na rzeczywistą pracochłonność, czas trwania i koszty, możemy poprawiać i modyfikować estymacje kolejnych projektów. 2.2.1.P3 Szacowanie kosztów stałych i zmiennych
155 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Koszty zmienne to takie, które ulegają zmianie w zależności od tego, ile jednostek jest wykorzystywanych. Na przykład prace zlecone płatne za godzinę. Im więcej godzin pracy zleceniobiorcy tym większe są koszty projektu. Koszty stałe to takie, które są niezmienne, w zależności od wykorzystania. Na przykład, jeśli budujesz dom koszty działki będą stałe, nie zmienią się w zależności wielkości domu. Ważne jest aby pamiętać, że zasoby generujące koszty stałe powinny być wykorzystane maksymalnie. A zasoby generujące koszty zmienne, możliwie jak najoszczędniej. Jeśli już wynająłeś pomieszczenie na projekt, niech odbywa się tam jak najwięcej spotkań, niech pracuje tam jak najwięcej osób. Wtedy użyteczność wydanego dolara na salę wzrasta. Zupełnie nierozsądne byłoby wynajmowanie sal do spotkań (płatnych za godzinę), mając do dyspozycji opłaconą salę. 2.2.1.P4 Zależność czasu i zasobów w realizacji zadania Zadania uzależnione od zasobów są wtedy, jeśli czas trwania zmieni się, gdy przydzielimy więcej zasobów. Na przykład, możesz oszacować, że jednej osobie wybudowanie dachu zajmie 200 godzin. Jeśli dana osoba będzie pracować przez czterdzieści godzin tygodniowo, zakończenie pracy zajmie jej pięć tygodni. Jeśli zatrudnisz dwie osoby do wykonania tej pracy, pracochłonność w dalszym ciągu będzie wynosić 200 godzin, ale praca zostanie wykonana tylko w 2 1/2 tygodnia. Jeśli do wykonania zadania przyporządkujesz pięć osób, prace mogą zostać wykonane w ciągu tygodnia (oczywiście czas trwania może nie zmniejszać się w tak klarowny sposób, jak w tym przykładzie). Jeśli czynność jest niezależna od zasobów, czas jej trwania pozostaje ten sam bez względu na zaangażowane zasoby. Na przykład, jeśli uczestniczysz w jednodniowych zajęciach, czynność zajmie Ci osiem godzin. Jeśli na szkolenie wyślesz dwie osoby, zajęcia nie zostaną przez to skrócone. Podobnie z czasem potrzebnym na zastygnięcie cementu lub na wysłanie listu. Ilość zaangażowanych osób nie ma wpływu na długość trwania tych czynności. Jeśli zobaczymy, że przydzielanie dodatkowych zasobów nie ma wpływu na czas trwania (lub będzie miało niewielki wpływ) wtedy takie zadanie jest niezależna od zasobu i jednocześnie jest ograniczeniem czasowym w projekcie. 2.2.1.P5 Dodanie czasu spotkań i uzgodnień do oszacowań projektu Jeśli spotkania nie są organizowane z inicjatywy kierownika projektu (np. spotkania działów) nie są brane pod uwagę w harmonogramie projektu. Często opóźniają one jednak projekt. Aby uwzględnić ten czas w harmonogramie możesz obniżyć szacowaną pracę produktywną / dzień (powiedzmy z 6,5 godziny na dzień do 5,5 godzin). Z drugiej strony, spotkania powiązane z projektem powinny być wpisane do harmonogramu. Czas poświęcony na uzgodnienia dotyczące przedmiotu dostawy oraz ich odbiór etc. także musi znaleźć się w harmonogramie. Jeśli spotkania te generują dodatkowe koszty, zamieszczamy je w budżecie. 2.2.1.P6 Rozpoczynanie zakresu determinanty W wielu przypadkach jesteś proszony o podanie ogólnych oszacowań projektu lub zadania. Zazwyczaj chodzi o podanie rzędu wielkości - na przykład ok. 1.000 godzin. Oszacowania mogą być podawane nie jako liczba, ale zakres. Odzwierciedla on poziom 156 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
niepewności. Możesz ocenić pracochłonność projektu na 1000 godzin lub stwierdzić, że będzie ona w zakresie od 500 do 1500 godzin. Innym sposobem na przekazanie tej samej informacji jest oszacowanie - 1.000 godzin, plus/minus 50%. Jeśli nie jesteś zupełnie pewien, margines błędu może wynosić plus minus 100% lub więcej.
Im dokładniejsze są szacunki tym większy jest podawany margines błędu. 2.2.1.P7 Model Monte Carlo Metoda Monte Carlo pozwala na dokładniejsze oszacowanie np. daty zakończenia projektu lub jego pracochłonności, uwzględniając przy tym różne scenariusze – pesymistyczne, realne i optymistyczne. Najpierw określ trzy wielkości dla każdego ważniejszego zadania: optymistyczną, oczekiwaną i pesymistyczną. Następnie podaj prawdopodobieństwo wystąpienia każdego ze scenariuszy dla każdego zadania (10%, 80%, 10%). W kolejnym kroku zasymuluj (używając narzędzia do planowania projektu) przebieg projektu. W ogólności twoje narzędzie np. tysiąckrotnie przeliczy czas trwania projektu, wybierając losowo scenariusz każdego z zadań, używając podanego przez Ciebie rozkładu prawdopodobieństwa. Następnie narzędzie pokaże wynik statystyczny, jaki uzyskany został przy większości (np. 80%) prób losowych. Wynik ten można przyjąć w oszacowaniach jako najbardziej prawdopodobny. 2.2.1.P8 Typowe błędy szacowania Poniżej znajduje się lista typowych problemów przy szacowaniu, których należy unikać.
Nie branie pod uwagę całej pracy. Częstym problemem, typowym dla ogólnych
szacunków jest, pomijanie jakiegoś zadania, którego nie postrzegasz jako element projektu. Często zaniża się szacowania pracy potrzebnej do wytworzenia przedmiotów dostaw, lub nie dodaje się wszystkich zadań wymaganych do zakończenia przedmiotu dostawy.
157 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Pobożne życzenie. Każdy, kto przeprowadzał szacowanie pracy, wie, że może istnieć
presja ze strony klienta, aby utrzymać oszacowania na jak najniższym poziomie. W końcu klient chce przecież dostać to, czego żąda, przy jak najniższej możliwej pracochłonności (i po najniższych kosztach). Wiele osób wykonujących estymacje ma tendencję do ulegania tej presji. Planujący w końcu zaczyna „życzyć” sobie, aby praca zakończyła się zgodnie z oczekiwaniami klienta, zamiast rzetelnie planować
Odnoszenie
się do najbardziej optymistycznego scenariusza. Klient żąda, aby praca została wykonana jak najszybciej. Twój kierownik chce, aby praca została wykonana jak najszybciej. I ty zaczynasz myśleć, że możesz wykonać pracę szybko. Jednak z reguły wpadniesz w kłopoty, ponieważ bierzesz pod uwagę jedynie optymistyczny scenariusz. A co jeśli pojawią się problemy? Czy kierownik i klient będą przyznawać się, że byli optymistami?
Zakładanie lepszej jakości pracy niż jest to możliwe. Problem ten związany jest szacowaniem opartym na założeniu, że praca będzie zawsze bardzo dobrej jakości. Jednak w trakcie, gdy projekt jest realizowany, zdajesz sobie sprawę, że Twoje zdolności, aby egzekwować wysoką jakość, są ograniczone. W wyniku tego pojawia się konieczność wprowadzania poprawek i korekt.
Skupienie się na dostępnym budżecie. W tym przypadku klient ma określoną wielkość budżetu. Kierownik projektu myśli, że jest szansa na wykonanie prac w dostępnym budżecie. Skupia się na tym, aby zaplanować projekt za dostępne pieniądze. Jest to szczególnie bolesne w skutkach, gdy budżet Klienta jest wielokrotnie zaniżony.
Brak obiektywizmu. Brak obiektywizmu wkrada się w estymację niemal przez cały czas. Czasem prowadzi to do ulegania pesymizmowi, czasem obiektywizmowi. Nadmierny optymizm skutkuje niedoszacowaniem kosztów i czasu, może to być związane z:
Tendencją do myślenia, że zadanie jest proste.
Tendencją do myślenia, że zespół może wykonać więcej, niż naprawdę może.
Nie braniem pod uwagę ryzyk projektu, problemów krytycznych, błędów w komunikacji, itp.
Nadmierny pesymizm spowoduje przecenienie pracy i może być spowodowany:
złymi doświadczeniami z podobnych projektów w przeszłości.
Niechęcią do wykonania pracy. Estymacje są zawyżane, gdyż planujący ma nadzieję że projekt zostanie odrzucony.
2.2.1.P9 Weryfikacja estymacji przez nowy zespół Zazwyczaj zespół projektowy tworzony jest, aby zdefiniować projekt, stworzyć harmonogram i budżet, a następnie zrealizować. Możliwe jest, że budżet i definicja powstały wcześniej, np. ponieważ projekt trzeba było oszacować na potrzeby budżetu rocznego firmy a powstawał on w roku ubiegłym. W takich przypadkach zespół projektowy może zostać powołany później. Jego zadaniem będzie zrealizowanie pracy oszacowanej i zabudżetowanej wcześniej. Jeśli taka sytuacja ma miejsce, jedną z pierwszych prac zespołu jest weryfikacja tych oszacowań. Nie należy doprowadzać do 158 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
sytuacji, kiedy wykonujesz zadanie w oparciu o czyjeś szacunki bez ich szczegółowego przeglądu. Jeśli projekt był niedoszacowany i nie wyjdzie, będziesz obciążony porażką, choć nie ty zawiniłeś. W takich sytuacjach należy niezwłocznie zweryfikować budżet i plan, jeśli budzą wątpliwości, należy to niezwłocznie zgłosić.
2.2.1.P10 Dołączanie do oszacowań pracochłonności oraz kosztów po stronie Klienta Pracochłonność klienta związana jest z jego czasem, jaki poświęca na sprawdzenie i zaakceptowanie przedmiotów dostaw, przedstawianie wymagań, uczestniczenie w spotkaniach, branie udziału w szkoleniu, itp. Niektóre firmy chcą znać całkowitą pracochłonności i koszty projektu, włączając w to pracę po stronie klienta. To, czy włączyć godziny klienta w swoich szacowaniach, należy omówić ze sponsorem. Jeśli szacunki dotyczące projektu zawierają godziny i koszty klienta, godziny muszą zostać przedstawione osobno. 2.2.1.P11 Należy być przygotowanym, że oszacowania zostaną uznane za zbyt wysokie Po przygotowaniu oszacowań, trzeba sprawdzić, czy klient nie będzie twierdził, że liczby są za duże. Powinieneś wytłumaczyć Klientowi jak one powstały. Jeśli klient nadal upiera się, że projekt jest przeszacowany możesz postępować według poniższych zaleceń.
Należy ustalić, czy klient ma jakieś dodatkowe informacje, które pozwoliłyby na zmianę założeń i oszacowań. Na przykład, jeśli data zakończenia jest elastyczna, może oszacowania mogą zostać zrewidowane w oparciu o nowe informacje.
Należy
ustalić, czy wymagania ogólne mogą zostać zmniejszone. W wielu przypadkach pierwotny opis przedmiotu dostawy jest raczej listą życzeń. Po zrewidowaniu kosztów, jest bardzo prawdopodobne, że klient zrezygnuje z niektórych elementów i obniży jakość, zmniejszy zakres prac.
Jeśli do budżetu dodano rezerwę, aby odzwierciedlić wysokie ryzyko niepewności
oszacowań, należy poprosić klienta o więcej czasu na zebranie większej ilość informacji.
Należy
zaproponować zmiany w przebiegu projektu tak, aby najpierw przeprowadzić fazę szczegółowej analizy. Po jej zakończeniu, należy dokonać ponownego oszacowania pozostałych faz projektu w oparciu o to, co jest faktycznie do zrobienia. Całkowita pracochłonność oraz koszty mogą - ale nie muszą - być niższe, ale przy najmniej oszacowania będą bardziej wiarygodne.
2.2.1.P12 Przygotowanie dokumentu uzasadniającego estymacje Kiedy zostaniesz poproszony o przedstawienie szacunków dla dużego zadania, należy rozważyć przygotowanie odrębnego dokumentu uzasadniającego estymacje. Nie musi to być długi dokument. Chodzi tylko o przedstawienie na jakich podstawach dokonano oszacowań. Oprócz przedstawienia tylko końcowych oszacowań lub ich zakresu, należy przedstawić następujące informacje: 159 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jak rozumiane jest szacowane zadanie. Proces przygotowania szacunków. Wykorzystana technika szacowania. Szacunki pracochłonności (oraz czas trwania i koszty, jeśli są konieczne). Dodatkowe informacje na wypadek, gdyby sponsor chciał je przejrzeć.
Na
przykład, WBS, Definicja Projektu etc.
Założenia wzięte pod uwagę przy szacowaniu. Poziom niepewności (wyrażony w wielkości rezerw budżetowych etc.) Docenisz wartość tego dokumentu, jeśli nie będzie zgody, co do przedstawionych estymacji, i będziesz je musiał obronić. Będzie to zdecydowanie utrudniało w ogólnie krytycznym komentowaniu liczb. Ludzie mają często trudności w polemice z faktami. Gdy szacunki nie będą dalej akceptowane, możesz zostać poproszony o zmianę swoich oszacowań lub wykorzystanie innej techniki. Można dokonać ponownej oceny w oparciu o nowe kryteria. Nikt jednak nie zaatakuje Ciebie, jako autora estymacji. 2.2.1.P13 Dokładność szacowania Oczekiwany poziom dokładności oszacowań może być różny. Jeśli na przykład projekt jest w fazie wstępnej propozycji, klient może poprosić Cię o ogólne oszacowanie. Realizacja projektu na tym etapie jest niepewna, takie same będą szacunki. W wielu przypadkach szacunki są używane tylko do określania rzędu wielkości. Tak, aby osoba, od której wyszła propozycja zrozumiała, czy praca zajmie 1000 czy też 100 000 godzin. Technika ta nazywa się Przybliżony Rrząd Wielkości (Rough Order of Magnitude (ROM). Jeśli wstępne szacunki pracy wynosiły 1000 godzin, można zaproponować szacunek ROM wynoszący 750 -1750 godzin. Na tym etapie może on być nawet o100% wyższy. W miarę przechodzenia projektu do dalszych etapów zatwierdzania, osoba dokonująca szacunków zdobywa więcej informacji, co do oczekiwań i przedmiotów dostaw. A to pozwala również na dokładniejsze szacowanie. Kiedy projekt jest przeznaczony do wstępnej realizacji w danym okresie, powinieneś być w stanie ocenić go z większą precyzją (możliwe że -15% do +25%). Innymi słowy, jeśli szacowałeś pracę na 1000 godzin, możesz zaproponować zakres 850 – 1250 godzin. Kiedy zacznie się już praca, kierownik projektu oraz zespół powinni ponownie ocenić szacunki po formalnym zdefiniowaniu pracy oraz stworzeniu harmonogramu i budżetu. Szacunki, które zostaną stworzone, będą bliższe poziomowi błędu -5% do +10%. Czyli, jeśli szacowałeś pracę na 1000 godzin, powinieneś mieć pewność, że dokończysz projekt w przedziale od 950 do 1100 godzin. Oszacowanie RZĄD WIELKOŚCI (KONCEPTUALNE)
DOKŁADNOŚĆ -25% - +75%
CEL
Ocena projektu lub alternatyw.
160 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
WSTĘPNE (BUDŻET)
Ostateczne
- 15% - +25%
Określanie budżetu, funduszy rezerwowych dla projektu.
- 5% - +10%
Określanie faktycznego budżetu projektu po zbudowaniu definicji projektu.
2.3 Tworzenie harmonogramu i budżetu / Podsumowanie 2.3.P1 Przedmioty dostaw: W bibliotekach formularzy TenStep dostępne są poniższe przedmioty dostaw.
Plan projektu. Podsumowanie szacowania kosztów. Szacowanie pracochłonności i kosztów . Podsumowanie kamieni milowych. Wymagania dotyczące zasobów. 2.3.P2 Zadania w harmonogramie
Rozmiar Konieczne informacje Mały
Przy małych projektach harmonogram można stworzyć od razu lub stworzyć go w myślach. Czynność
Nakład Uwagi
Zebranie istniejących 1-2 dokumentów godzin Trudno jest określić szacowany czas tych Tworzenie pierwszego różnie czynności. Zależy to jak duży i złożony jest poziomu WBS. WBS. Średni Duży
Szacowanie pracochłonności dla różnie komponentów pracy na tym poziomie. Sprawdzanie, praca musi rozbita.
Należy powtarzać te oraz powyższe czy czynności, aż cała praca jest zrozumiała a zostać różnie pracochłonność oszacowana na poziomie niższym niż próg estymacji.
161 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W poprzednich etapach istotne było, czy Szacowanie pracy czynność jest większa, niż próg estymacji. pod względem różnie Teraz należy ocenić pracę, podając szczegółów. szczegółowe czynności. Tworzenie diagramu sieciowego poprzez sekwencjonowanie różnie szczegółowych komponentów pracy na poziomie ogólnym. Sprawdzanie sekwencji pracy po raz drugi w celu różnie sprawdzenia szczegółowych zależności. Sprawdzanie czy istnieją zadania mające związek z różnie konkretnymi terminami. Przyporządkowywanie różnie zasobów. Tworzenie wstępnego różnie harmonogramu. “Poziomowanie” zasobów.
otwarte
Modyfikacje harmonogramu
Należy modyfikować zasoby oraz inne różnie komponenty harmonogramu, aż będzie wyglądał na wykonalny
Szacowanie kosztów. różnie Sprawdzenie Trzeba czuć się komfortowo, aby móc harmonogramu oraz różnie obronić harmonogram. Inaczej nie będzie ram czasowych. dobry. Ustalanie milowych.
kamieni 1-2 godzin
Zachowywanie bieżących harmonogramu bazowego
12 godzin
162 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
163 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 3 Zarządzanie harmonogramem i budżetem
164 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.0 Zarządzanie Harmonogramem i budżetem 3.0.P1 Jeśli zastosowałeś się do procesów 1 i 2, stworzyłeś Definicję Projektu, Harmonogram i budżet. Teraz musisz zarządzać przy ich pomocy, aby zapewnić, że projekt zostanie zakończony zgodnie z planem i w ramach budżetu. Nigdy nie będziesz dobrym kierownikiem projektu, jeśli nie będziesz potrafił uaktualniać harmonogramu i jeśli nie będziesz tego robić. Pamiętaj, że choć harmonogram jest tylko wewnętrznym przedmiotem dostawy, to opisuje pracę, która musi zostać zrealizowana, kolejność czynności, pracochłonność, która jest wymagana, przydzielone zasoby, itd. Zarządzanie harmonogramem to dowód, że rozumiesz ale i kontrolujesz pracę! Harmonogram powinien pokazywać jak wyobrażasz sobie projekt i pracę twojego zespołu, w każdym detalu, w przyszłości. Im bardziej złożony projekt, tym więcej będzie bieżących zmian w tych wyobrażeniach. To dlaczego, zarządzanie Harmonogramem projektu jest tak ważną umiejętnością. Kierownik projektu musi na bieżąco analizować Harmonogram (minimum raz na tydzień) i określać bieżący stan projektu. W oparciu o te informacje kierownik modyfikuje harmonogram, zmienia kolejność zadań lub ich realizatorów. 3.0.P2 Integralność projektu i procesów zarządzania projektem Podczas definiowania projektu (proces 1.0) nie tylko określasz co jest do zrobienia, ustalasz przedmioty dostawy, zakres etc. Na tym etapie bardzo często tworzysz lub doprecyzowujesz w jaki sposób będzie zarządzać się zakresem, problemami krytycznymi, ryzykami, jakością etc. Innymi słowy, w tym etapie budujesz Plan Zarządzania Projektem. Kiedy projekt jest realizowany – w zasadzie wszystkie procesy wpływają na siebie poprzez proces Zarządzania Harmonogramem i budżetem. Gwarantuje to nadrzędna zasada TenStep: „To, co jest w harmonogramie, musi być wykonane‖. Innymi słowy, cała praca należąca do projektu powinna być w harmonogramie a jeśli jakakolwiek czynność nie jest w harmonogramie, nie powinno się nad nią pracować, ponieważ nie należy do projektu.
165 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Harmonogram jest „centrum” zarządzania projektem. Wszystkie procesy zarządzania projektem są z nim zintegrowane. To tu zapisuje się zadania oraz rezerwuje się czas na komunikowanie się, zarządzanie zakresem, aktualizację harmonogramu etc. Przykłady:
Wniosek
o zmianę zakresu został zatwierdzony. Zatwierdzono zwiększenie pracochłonności oraz zaakceptowano większe koszty (proces 5.0). W tej sytuacji kierownik projektu natychmiast aktualizuje w budżet i harmonogram (integrując tę zmianę z dotychczasowym planem projektu).
Zidentyfikowano nowe
ryzyka. Aby im zapobiec opracowałeś plan (koncepcję) zarządzania tym ryzykiem. Uaktualniasz Plan Zarządzania Ryzykiem (proces 7.0). Zaktualizowany Plan Zarządzania Ryzykiem przesyłasz ważniejszym interesariuszom do wiadomości (stosując procedury komunikacyjne – proces 6.0). Przykład obrazuje integrację procesów zarządzania ryzykiem i komunikowania się poprzez zarządzanie harmonogramem. Zarówno nowy plan zarządzania ryzykiem, jak i działania komunikacyjne powinny zostać dodane do harmonogramu projektu podczas najbliższej aktualizacji.
Zauważyłeś, że praca jest zbyt niskiej jakości i zgłosiłeś problem krytyczny. Aby
rozwiązać problem, decydujesz się na zebranie większej ilości danych i informacji. Dodajesz do harmonogramu zadania dotyczące zbierania tych pomiarów. To prowadzi do modyfikacji procesu kontroli jakości. Kontaktujesz się więc ze wszystkimi interesariuszami, aby zapobiegać dalszym trudnościom i proaktywnie zarządzać oczekiwaniami. Cała ta praca będzie odzwierciedlona w Planie harmonogramie i budżecie. Proces ten zapewnia więc integrację procesów zarządzania, wykonanie wszystkich niezbędnych zadań prowadzących do powstania przedmiotów dostawy. Zapewnia, że wszystko jest pod kontrolą kierownika, a harmonogram zawsze odzwierciedla aktualny stan projektu.
3.1 Zarządzanie Harmonogramem i budżetem / Proces 3.2 ZARZĄDZANIE HARMONOGRAMEM I BUDŻETEM / TECHNIKI 3.3 Zarządzanie Harmonogramem i budżetem / Podręcznik
166 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1 Zarządzanie Harmonogramem i budżetem / Proces Kierownik projektu powinien zastosować jeden z poniższych procesów, aby zarządzać harmonogramem i budżetem, w zależności od rozmiaru projektu. 3.1.1 Małe projekty 3.1.2 Średnie projekty 3.1.3 Duże projekty
167 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.1 Zarządzanie harmonogramem i budżetem / Mały projekt 3.1.1.P1 Zarządzanie harmonogramem i budżetem (Mały projekt)
1
2
3
4
Rola
Zarządzanie Harmonogramem i budżetem (Mały projekt)
Kierownik projektu.
Cotygodniowo aktualizuj harmonogram.
Kierownik projektu, członkowie zespołu.
Sprawdź status zadań
Kierownik projektu..
Przeglądaj pracę w toku i przydzielaj nowe zadania.
Kierownik projektu.
Określ, czy zakończysz projekt w ustalonym terminie i budżecie.
Przejrzyj harmonogram. Zidentyfikuj zadania zaplanowane do realizacji i wykonane. Odznacz je wyraźnie, jako „zakończone”.
Sprawdź, czy są jakieś zadania, które powinny być wykonane, ale nie są. Jeśli zadanie jest opóźnione, skontaktuj się jego wykonawcami, aby dowiedzieć się, co się dzieje.
Przeglądaj jaki jest status zadań w toku. Przydzielaj nowe zadania, zgodnie z harmonogramem. Uzyskaj od każdego członka zespołu potwierdzenie, że wie jak wykona zadanie w ramach przydzielonego budżetu i terminu. Czasem wykonawca może chcieć trochę czasu na sprawdzenie czy praca nadal jest możliwa do wykonania w zadanym czasie i budżecie. (Zobacz: 3.1.7 Potwierdzanie oszacowań pracy przez zespół)
Oceń pozostałą pracę, aby zobaczyć, czy projekt będzie wykonany w terminie oraz za ustalony budżet. Możesz uznać, że chociaż niektóre zadania są wykonane później niż planowano, inne mogą być wykonane wcześniej i cały projekt zakończy się zgodnie z oczekiwaniami. 5
6
Kierownik projektu.
Zatwierdź pozostałą pracę
Kierownik projektu, sponsor.
Podejmij działania korygujące, jeśli są potrzebne.
Zmodyfikuj harmonogram tak, aby odzwierciedlał on pozostałą do wykonania pracę.
W małych projektach raczej nie występują duże problemy z harmonogramem i budżetem. Z reguły wszystkie problemy da się obejść poprzez rozmowy z zespołem projektowym.
168 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.2 Zarządzanie harmonogramem i budżetem / Średnie projekty 3.1.2.P1 Zarządzanie harmonogramem średnich projektów
1
Rola
Zarządzanie harmonogramem i budżetem (Średni Projekt)
Kierownik projektu.
Zbierz najnowsze informacje i uaktualniaj harmonogram W średnich projektach najczęściej aktualizuje się harmonogram raz w tygodniu. Nie aktualizuj rzadziej, niż co dwa tygodnie, okres miesiąca jest zbyt długi. Jeśli przeglądy harmonogramu są za rzadko, między nimi realizowanych jest za dużo zadań. Jeśli wystąpią problemy, mogą być odkryte zbyt późno. Podczas przeglądu zbierz informacje o statusie zadań od każdego członka zespołu i uaktualnij harmonogram. Zidentyfikuj zadania zaplanowane do realizacji i wykonane. Odznacz je wyraźnie, jako „zakończone”.
2
3
4
Kierownik projektu, członkowie zespołu.
Zapisz rzeczywiste koszty i pracochłonność (opcjonalnie).
Kierownik projektu.
Przejrzyj cały harmonogram
Kierownik projektu, członek zespołu.
Prześledź raporty na temat harmonogramu
Jeśli w projekcie odnotowuje się rzeczywistą pracochłonność i koszty, zbierz dane od członków zespołu i zapisz je w harmonogramie. Faktyczną pracochłonność mogą zawierać raporty indywidualne o statusie zdań lub można jest uzyskać od zespołu w czasie zebrań projektowych. Możesz również zautomatyzować proces dzięki użyciu narzędzia do planowania. Członkowie zespołu mogą wtedy sami, bezpośrednio uaktualniać harmonogram – odnotowywać rzeczywistą pracochłonność, zaznaczać status wykonywanych zdań itd.
Po uaktualnieniu przejrzyj cały harmonogram, aby zobaczyć, czy projekt będzie wykonany według pierwotnych oszacowań pracochłonności, kosztu i czasów trwania. Możesz uznać, że chociaż niektóre czynności mogą być opóźnione, inne mogą być wykonane wcześniej i cały projekt zakończy się zgodnie z oczekiwaniami
Sprawdź, czy są jakieś inne czynności, które powinny być wykonane, ale nie są, które nie zostały objęte raportami zespołu. Informacje te mogą być zebrane poprzez uruchomienie stosownego raportu z twojego narzędzia planowania. Czasem, jeśli harmonogram jest rozbudowany, może umknąć jakieś zadanie. Jeśli są takie czynności, które są opóźnione, skontaktuj się z osobą, która jest(s przydzielona, aby zobaczyć, co się dzieje. Mogły pojawić się jakieś problemy, które muszą być rozwiązane przez ciebie. Może
169 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
okazać się, że ilość czasu potrzebnego do wykonania zadania była niedoszacowana. Kierownik projektu i członkowie zespołu muszą określić, jak dużo dodatkowego czasu będzie potrzebne do wykonania pracy. Następnie uaktualnij harmonogram. 5
Kierownik projektu.
Szukaj symptomów potencjalnych problemów Symptomy problemów to np.:
Małe
odchylenia (na plus i na minus) zaczynają się powiększać, szczególnie we wczesnej fazie projektu
Odkrywasz, że nadal pracuje się nad zadaniami, o których myślałeś, że zostały już zakończone
Musisz użyć niezaplanowanych nadgodzinach, aby zadania zakończyły się według ustalonych terminów
Jakość przedmiotu dostawy zaczyna się pogarszać Zaczyna się oszczędzać czas na kontroli jakości, testowaniu,
zarządzaniu projektem Jeśli analogiczne zjawiska zaczynają występować, kierownik projektu powinien zaktualizować / zacząć realizować plan zarządzania ryzykiem. Jeśli nie możesz poradzić sobie z powyższymi problemami, musisz zgłosić problem krytyczny. (Zobacz także rozdział 3.2). 6
7
Kierownik projektu.
Oceń ścieżkę krytyczną projektu.
Kierownik projektu.
Przydziel pracę członkom zespołu.
Ścieżka krytyczna jest sekwencją czynności, które musza być wykonane w czasie, aby cały projekt został wykonany w terminie. (Więcej patrz rozdział: Tworzenie harmonogramu i budżetu / Ścieżka krytyczna). Ważne jest, aby zrozumieć ścieżkę krytyczną i wiedzieć, na których czynnościach należy się skoncentrować. Przesunięcie dodatkowych zasobów (np. pracowników) do zadań spoza ścieżki krytycznej nie doprowadzi do wcześniejszego zakończenia projektu. Nawet jeśli myślisz, że znasz ścieżkę krytyczną pamiętaj, że może się zmienić!
Po aktualizacji harmonogramu i budżetu, sprawdź która praca musi być wykonana w ciągu następnych trzech tygodni. Zadania te powinna być przydzielona właściwym członkom zespołu. Rozdział zadań może być ogłaszany w czasie spotkań zespołu projektowego. Ważne jest, aby wszyscy członkowie zespołu znali swoje zadania, szczególnie kiedy mają je wykonać (Więcej informacji o przydzielaniu zadań w rozdziale: 3.2 Techniki). Uzyskaj potwierdzenie od każdego członka zespołu że wykona pracę w ramach przydzielonego czasu i budżetu. Czasem wykonawca może chcieć trochę czasu na sprawdzenie czy praca nadal jest możliwa do wykonania w zadanym czasie i budżecie. (Zobacz: 3.1.7
170 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Potwierdzanie oszacowań pracy przez zespół)
8
Kierownik projektu.
Poinformuj o ryzyku harmonogramowym Jak tylko zidentyfikujesz jakieś ryzyko harmonogramowe, powinieneś poinformować o tym sponsora i interesariuszy. Może okazać się, że termin jest tak ważny, że sponsor może zwiększyć budżet projektu, nadać mu wyższy priorytet lub może zdecydować o ograniczeniu zakresu i wykonaniu jedynie najważniejszych prac.
3.1.2.P2 Zarządzanie budżetem
9
Kierownik projektu.
Przeglądaj budżet Podczas realizacji projektu dokonuj przeglądu budżetu systematycznie. Nawet jeśli projekt przeglądasz w okresie tygodniowym lub dwutygodniowym okres sporządzania przeglądu budżetowego może być wyznaczony przez procedury księgowe / finansowe obowiązujące w twojej firmie. W celu uzyskania większej ilości informacji o potencjalnych problemach z budżetem, zobacz: 3.1.4 Zarządzanie budżetem projektu.
10
Kierownik projektu.
Uaktualniaj (szacowany) budżet projektu. Po aktualizacji harmonogramu powinieneś również sprawdzić szacowania kosztu pozostałej pracy. Patrząc na relacje zaplanowane koszty / dotychczasowe koszty, określ, czy pozostałe zadania uda się zrealizować w zaplanowanym budżecie. Jeśli trendy wykorzystania dotychczasowego budżetu pokazują, że dążysz do przekroczenia budżetu całościowego projektu, musisz proaktywnie zareagować, aby nie dopuścić do przekroczenia budżetu.
11
Kierownik projektu, sponsor, interesariu sz.
Poinformuj o ryzyku budżetowym Jak tylko zidentyfikujesz jakieś ryzyko budżetowe, powinieneś poinformować o tym sponsora i interesariuszy. Może okazać się, że budżet i koszty są tak ważne, że sponsor może wydłużyć terminy zakończenia projektu, nadać mu wyższy priorytet lub może zdecydować o ograniczeniu zakresu i wykonaniu jedynie najważniejszych prac.
3.1.P3 Zamykanie projektu Rola
Zakończ realizację (cykl życia) projektu (Średni projekt).
171 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
12
Kierownik projektu.
Zakończ pracę. Gdy projekt zbliża się do końca, upewnij się, że w harmonogramie zaplanowałeś zadania formalnego zakończenia prac. Kierownik projektu nie może uważać projekt za wykonany, jeśli nie zostaną zrealizowane zadania zakańczające projekt. Kończąc projekt, powinieneś zachować takie samo zdyscyplinowanie jak podczas zarządzania całym projektem. Zobacz: 3.1.3.2 Zarządzanie harmonogramem i budżetem / Zakończenie projektu.
172 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.3 Zarządzanie Harmonogramem i budżetem / Duże projekty 3.1.3.P1 Uruchamianie projektu Rola
Uruchamianie (cyklu życia) projektu (Duży projekt).
Kierownik projektu, zespół projektu.
Zorganizuj zebranie rozpoczynające projekt (Kickoff meeting). Rozpocznij realizację projektu od spotkania rozpoczynające projekt – Kickoff meeting. Zobacz: 3.1.3.1 Zarządzanie harmonogramem i budżetem / Rozpoczęcie projektu.
3.1.3.P2 Kontrola Planu operacyjnego.
1
Rola
Zarządzanie harmonogramem i budżetem (Średni /Duży projekt).
Kierownik projektu
Zbierz najnowsze informacje i uaktualniaj harmonogram W dużych projektach najczęściej aktualizuje się harmonogram raz na dwa tygodnie, okres miesiąca jest zbyt długi. Jeśli przeglądy harmonogramu są za rzadko, między nimi realizowanych jest za dużo zadań. Jeśli wystąpią problemy, mogą być odkryte zbyt późno. Podczas przeglądu zbierz informacje o statusie zadań od każdego członka zespołu i uaktualnij harmonogram. Zidentyfikuj zadania zaplanowane do realizacji i wykonane. Odznacz je wyraźnie, jako „zakończone”.
2
Kierownik Zapisz rzeczywiste koszty i pracochłonność (opcjonalnie). projektu, Jeśli w projekcie odnotowuje się rzeczywistą pracochłonność i członkowi koszty, zbierz dane od członków zespołu i zapisz je w e zespołu. harmonogramie. Faktyczną pracochłonność mogą zawierać raporty indywidualne o statusie zdań lub można jest uzyskać od zespołu w czasie zebrań projektowych. Możesz również zautomatyzować proces dzięki użyciu narzędzia do planowania. Członkowie zespołu mogą wtedy sami, bezpośrednio uaktualniać harmonogram – odnotowywać rzeczywistą pracochłonność, zaznaczać status wykonywanych zdań itd.
3
Kierownik projektu.
Przejrzyj cały harmonogram Po uaktualnieniu przejrzyj cały harmonogram, aby zobaczyć, czy projekt będzie wykonany według pierwotnych oszacowań pracochłonności, kosztu i czasów trwania. Możesz uznać, że chociaż niektóre czynności mogą być opóźnione, inne mogą być wykonane wcześniej i cały projekt zakończy się zgodnie z oczekiwaniami
173 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4
5
Kierownik projektu, członek zespołu.
Prześledź raporty na temat harmonogramu
Kierownik projektu.
Uruchom dodatkowe raporty na temat harmonogramu
Sprawdź, czy są jakieś inne czynności, które powinny być wykonane, ale nie są, które nie zostały objęte raportami zespołu. Informacje te mogą być zebrane poprzez uruchomienie stosownego raportu z twojego narzędzia planowania. Czasem, jeśli harmonogram jest rozbudowany, może umknąć jakieś zadanie. Jeśli są takie czynności, które są opóźnione, skontaktuj się z osobą, która jest(s przydzielona, aby zobaczyć, co się dzieje. Mogły pojawić się jakieś problemy, które muszą być rozwiązane przez ciebie. Może okazać się, że ilość czasu potrzebnego do wykonania zadania była niedoszacowana. Kierownik projektu i członkowie zespołu muszą określić, jak dużo dodatkowego czasu będzie potrzebne do wykonania pracy. Następnie uaktualnij harmonogram.
Uruchom dodatkowe raporty z narzędzia planowania, aby pomóc określić, jak projekt posuwa się na przód. Na przykład, przyjrzyj się obciążeniu zasobów, aby upewnić się zespół nie ma zbyt dużej lub zbyt małej ilości zadań. Z raportów wstępnych może wynikać, że jest wykonywany zgodnie z harmonogramem, na przykład, ponieważ niektórzy z członków zespołu maja zaplanowane po 80 godzin tygodniowo. Jeśli zachowałeś harmonogram bazowy, możesz uruchomić raporty porównujące go z bieżącym harmonogram i prześledzić ewentualne rozbieżności. Chociaż dostępne są setki raportów kierownicy projektów, zazwyczaj uruchamiają niewielką ich ilość. Prawdopodobnie sam dopracujesz się tego, które raporty są najbardziej wartościowe.
3.1.3.P3 Monitoruj i kontroluj prace projektu 6
Kierownik projektu.
Szukaj symptomów potencjalnych problemów Większość problemów, zanim wystąpi, jest sygnalizowana różnorodnymi zjawiskami. Doświadczony menedżer wie doskonale, że zanim powstanie opóźnienie nie do nadrobienia, powstaje to pierwsze, niegroźne, małe opóźnienie. Zanim przekroczy się budżet, zostaje wydany ten pierwszy dolar za dużo. Dlatego nie należy lekceważyć syndromów potencjalnych problemów i śledzić drobiazgi, trendy, powtarzające / nasilające się zjawiska. Symptomy problemów to np.:
Małe
odchylenia (na plus i na minus) zaczynają się powiększać, szczególnie we wczesnej fazie projektu
Odkrywasz, że nadal pracuje się nad zadaniami, o których myślałeś, że zostały już zakończone
Musisz użyć niezaplanowanych nadgodzinach, aby zadania zakończyły się według ustalonych terminów
174 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jakość przedmiotu dostawy zaczyna się pogarszać Zaczyna się oszczędzać czas na kontroli jakości, testowaniu,
zarządzaniu projektem Jeśli analogiczne zjawiska zaczynają występować, kierownik projektu powinien zaktualizować / zacząć realizować plan zarządzania ryzykiem. Jeśli nie możesz poradzić sobie z powyższymi problemami, musisz zgłosić problem krytyczny. (Zobacz także rozdział 3.2). 7
Kierownik projektu.
Zmodyfikuj harmonogram – rozbij najbliższe zadania na czynności Raz w miesiącu zmodyfikuj zadania w harmonogramie tak, aby pokazywał precyzyjnie to, jak wyobrażasz sobie najbliższą pracę projektu. Gdy tworzony był harmonogram dużego projektu wiele z zadań z przyszłości mogło być niedookreślonych i opisanych bardzo ogólnie. Co miesiąc sprawdzaj, czy masz wystarczająco dużo informacji, aby prace te zdekomponować do poziomu zadań elementarnych i czynności. Powinieneś upewnić się, że harmonogram na następne trzy miesiące zawiera zadania i czynności oszacowane na mniej niż 40 godzin. Czasem może zostać jakieś zadanie o pracochłonności 80 godzin, o ile będziesz je umiał kontrolować. Jeśli jakiekolwiek zadanie przekracza wartość 40 godzin i nie jest łatwo je kontrolować – musisz je zdekomponować na mniejsze. Zauważ, że krok ten odnosi się do pierwotnie zidentyfikowanej pracy. Nie wolno tu dodawać nowych zadań, których nie zakłada zakres projektu. Oczywiście można zmienić zakres, ale jest to wykonane w wyniku procesu 5.0 Zarządzanie zmianami.
8
Kierownik projektu.
Oceń ścieżkę krytyczną projektu. Ścieżka krytyczna jest sekwencją czynności, które musza być wykonane w czasie, aby cały projekt został wykonany w terminie. (Więcej patrz rozdział: Tworzenie harmonogramu i budżetu / Ścieżka krytyczna). Ważne jest, aby zrozumieć ścieżkę krytyczną i wiedzieć, na których czynnościach należy się skoncentrować. Przesunięcie dodatkowych zasobów (np. pracowników) do zadań spoza ścieżki krytycznej nie doprowadzi do wcześniejszego zakończenia projektu. Nawet jeśli myślisz, że znasz ścieżkę krytyczną pamiętaj, że może się zmienić!
3.1.3.P4 Kierowanie i zarządzanie wykonywaniem projektu 9
Kierownik projektu.
Przydziel pracę członkom zespołu. Po aktualizacji harmonogramu i budżetu, sprawdź która praca musi być wykonana w ciągu następnych trzech tygodni. Zadania te powinna być przydzielona właściwym członkom zespołu.
175 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Rozdział zadań może być ogłaszany w czasie spotkań zespołu projektowego. Ważne jest, aby wszyscy członkowie zespołu znali swoje zadania, szczególnie kiedy mają je wykonać (Więcej informacji o przydzielaniu zadań w rozdziale: 3.2 Techniki). Uzyskaj potwierdzenie od każdego członka zespołu że wykona pracę w ramach przydzielonego czasu i budżetu. Czasem wykonawca może chcieć trochę czasu na sprawdzenie czy praca nadal jest możliwa do wykonania w zadanym czasie i budżecie. (Zobacz: 3.1.7 Potwierdzanie oszacowań pracy przez zespół) 10
Kierownik projektu.
Poinformuj o ryzyku harmonogramowym Jak tylko zidentyfikujesz jakieś ryzyko harmonogramowe, powinieneś poinformować o tym sponsora i interesariuszy. Może okazać się, że termin jest tak ważny, że sponsor może zwiększyć budżet projektu, nadać mu wyższy priorytet lub może zdecydować o ograniczeniu zakresu i wykonaniu jedynie najważniejszych prac.
3.1.3.P5 Zarządzanie budżetem 11
Kierownik projektu.
Przeglądaj budżet Podczas realizacji projektu dokonuj przeglądu budżetu systematycznie. Nawet jeśli projekt przeglądasz w okresie tygodniowym lub dwutygodniowym okres sporządzania przeglądu budżetowego może być wyznaczony przez procedury księgowe / finansowe obowiązujące w twojej firmie. W celu uzyskania większej ilości informacji o potencjalnych problemach z budżetem, zobacz: 3.1.4 Zarządzanie budżetem projektu.
12
Kierownik projektu.
Uaktualniaj (szacowany) budżet projektu. Po aktualizacji harmonogramu powinieneś również sprawdzić szacowania kosztu pozostałej pracy. Patrząc na relacje zaplanowane koszty / dotychczasowe koszty, określ, czy pozostałe zadania uda się zrealizować w zaplanowanym budżecie. Jeśli trendy wykorzystania dotychczasowego budżetu pokazują, że dążysz do przekroczenia budżetu całościowego projektu, musisz proaktywnie zareagować, aby nie dopuścić do przekroczenia budżetu.
13
Kierownik projektu, sponsor, interesariu sz.
Poinformuj o ryzyku budżetowym Jak tylko zidentyfikujesz jakieś ryzyko budżetowe, powinieneś poinformować o tym sponsora i interesariuszy. Może okazać się, że budżet i koszty są tak ważne, że sponsor może wydłużyć terminy zakończenia projektu, nadać mu wyższy priorytet lub może zdecydować o ograniczeniu zakresu i wykonaniu jedynie najważniejszych prac.
176 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
177 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.3.P6 Przegląd kamieni milowych 14
Kierownik projektu.
Zatwierdź status projektu przy każdym kamieniu milowym Przy osiągnięciu kamienia milowego, zespół powinien zrobić krótką przerwę, aby upewnić się, że wcześniejsza praca została prawidłowo wykonana i że zespół i klient są gotowi, aby przejść do następnej fazy. Czasami te kryteria nazywane są kryteriami wyjścia i wejścia lub „bramkami”. Zobacz: 3.1.5 Przeglądy kamieni milowych. Dzięki temu przy każdym kamieniu można sprawdzić czy projekt nadal spełnia oczekiwania sponsora i klienta.
3.1.3.P7 Zarządzanie kontraktem 15
Kierownik projektu, dostawcy.
Sprawdź stan wykonania kontraktów realizowanych przez dostawców / firmy zewnętrzne Powinieneś dokładnie śledzić wszystko to, co realizują podmioty trzecie – dostawcy / firmy outsourcowane. Musisz być pewien, że dostawca jest w stanie dostarczyć to co zamówiłeś do projektu. Pracuj systematycznie w tym celu z account managerem, odpowiedzialnym za relacje z twoją firmą. W wielu firmach pomoc w zarządzaniu relacjami z dostawcami świadczą działy prawne lub działy zakupów. Dodatkowe informacje o zarządzaniu pracą outsourcowaną znajdziesz w rozdziale 3.1.6.
3.1.3.P8 Zamykanie projektu. 3.1.P3
12
Rola
Zakończ realizację (cykl życia) projektu (Średni projekt).
Kierownik projektu.
Zakończ pracę. Gdy projekt zbliża się do końca, upewnij się, że w harmonogramie zaplanowałeś zadania formalnego zakończenia prac. Kierownik projektu nie może uważać projekt za wykonany, jeśli nie zostaną zrealizowane zadania zakańczające projekt. Kończąc projekt, powinieneś zachować takie samo zdyscyplinowanie jak podczas zarządzania całym projektem. Zobacz: 3.1.3.2 Zarządzanie harmonogramem i budżetem / Zakończenie projektu.
3.1.3.P8 Zakończenie kontraktu 17
Kierownik projektu .
Zakończ wszystkie kontrakty. Zakończ wszystkie kontrakty zawierane na rzecz projektu. Poinformuj o tym odpowiednie działy (zakupów, prawny). Szczególnie jest to ważne, gdy dostawca realizuje także inne prace na rzecz twojej firmy. Wtedy przekaż swoje sugestie dotyczące jakości współpracy osobie odpowiedzialnej za kontakty z danym dostawcą.
178 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.3.1 Zarządzanie harmonogramem i budżetem / Rozpoczęcie projektu 3.1.3.1.P1 Projekty nie zawsze przechodzą przez zorganizowany proces planowania, zatwierdzania i realizacji. Aby uniknąć sytuacji, kiedy interesariusze, klienci, sponsorzy inaczej postrzegają ten sam projekt rozpocznij pracę od zorganizowania Kickoff meeting. Celem spotkania rozpoczynającego (Kickoff meeting) jest: 1. formalne powiadomienie wszystkich interesariuszy, że projekt się rozpoczął 2. upewnienie się, że wszyscy tak samo rozumieją projekt (cele, zakres itd), Zebranie to jest czasem, aby zebrać wszystkich członków zespołu, klientów i interesariuszy i formalnie rozpocząć projekt. Poniżej zamieszczono sugestie co do przebiegu takiego spotkania:
Przedstaw obecnych. Podsumuj Definicję Projektu, w tym:
Cel projektu Zakres Przedmioty dostawy Ryzyka Założenia Szacowany budżet, pracochłonność, czas trwania Wszelkie ograniczenia (zasobowe i terminowe)
Omów
role i obowiązki zespołu projektowego, klientów i interesariuszy. Jeśli cokolwiek jest w tym zakresie niejasne lub niejednoznaczne – nie zawahaj się poświęcić czas na objaśnienie każdej nieścisłości.
Przejrzyj podejście realizacyjne harmonogram. To zobrazuje ludziom, jak projekt będzie realizowany. W szczególności, jeszcze raz przypomni ludziom, co i kiedy będą musieli zrobić w projekcie.
Odpowiedz na pytania. Potwierdź ostatecznie, że projekt już się rozpoczął / jest gotowy do startu.
Inne punkty do rozważenia na spotkaniu:
Uczestnicy.
Na ogół powinni być obecni: zespół projektowy, klient i interesariusze. Jeśli miałoby być zbyt wielu uczestników – zaproś jedynie najważniejszych uczestników. Z pozostałymi, albo spotykasz się na osobnych zebraniach, albo informujesz ich mailem o najważniejszych sprawach.
179 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Długość. Każdy Kickoff meeting ma inną długość, od jednej godziny do dwóch
dni. Dłuższe spotkania są szczególnie ważne, jeśli projekt jest bardzo złożony lub kontrowersyjny.
Przygotowanie.
Nigdy nie będziesz miał drugiej szansy, aby zrobić dobre pierwsze wrażenie. Jeśli zebranie jest niezorganizowane i chaotyczne ludzie uznają je za stratę czasu, ale i projekt nie będzie postrzegany pozytywnie już na starcie. Kierownik projektu musi przygotować spotkanie, uzyskać zgodę na jego organizację, rozesłać zaproszenia i plan spotkania oraz zadbać, aby w danym terminie nic nie przeszkodziło mu w prowadzeniu Kickoff meeting.
180 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.3.2 Zarządzaj harmonogramem i budżetem / Zakończenie projektu 3.1.3.2.P1 Tak jak ważne jest, aby formalnie rozpocząć projekt, tak samo istotne jest, aby zakończyć go w sposób odpowiedni. Jeśli projekt jest zamknięty – automatycznie zespół projektowy rozwiązuje się, a kierownik nie odpowiada już za zarządzanie. Jeśli więc po wykonaniu pracy zamierza się ocenić pracowników, podsumować projekt i nabyte doświadczenia, uzupełnić dokumentację itd., zadania te nie mogą odbyć się po zakończeniu projektu. Jeśli projekt został przerwany lub zakończył się fiaskiem, zanim pozwoli się „rozejść” zespołowi, także z reguły trzeba wykonać wiele czynności. Gdy tworzysz harmonogram, pomyśl o tym jak i kiedy zakończysz projekt. Poniżej kilka sugestii:
Zorganizuj zebranie zakańczające projekt. Zebranie powinno być zorganizowane
z zespołem projektowym, sponsorem i interesariuszami. Będzie ono miało na celu podsumowanie projektu. Techniki i procesy, które zadziałały szczególnie dobrze, lub szczególnie słabo, są zapisywane jako kluczowe wnioski projektu. Jest dobrym zwyczajem wielu firm, aby wnioski te były rozsyłane do różnych grup i osób zainteresowanych podnoszeniem kwalifikacji w obszarze zarządzania projektami. Kluczowe wnioski, które wydają się działać w wielu projektach, w wielu okolicznościach, mogą być podniesione do rangi najlepszej praktyki i być wykorzystywane we wszystkich projektach.
Plan zebrania powinien być skoncentrowany na tym, co projekt miał osiągnąć i co projekt w rzeczywistości osiągnął. Weź pod uwagę następujące sugestie:
Omów cel zebrania. Ustala zasady obowiązujące na spotkaniu (opcjonalnie). Wymień, co projekt powinien osiągnąć. Opisz co projekt w rzeczywistości osiągnął. Omów skąd wzięły się różnice (jeśli zidentyfikowano rozbieżności) Omów co nauczył się zespół dzięki projektowi Uporządkuj pracę, która zespół ma jeszcze wykonać, zanim
zostanie
rozwiązany.
Ogłoś
sukces lub porażkę. Czasami oczywiste jest, że projekt był całkowicie udany lub nie. W wielu przypadkach rezultaty nie są jednak jednoznaczne. Na przykład, główne przedmioty dostawy mogą być wykonane, ale projekt przekroczył budżet, albo zespół projektowy dostarczył na czas i w ramach budżetu, ale rozwiązanie spełniało tylko 80% wymagań biznesowych. Dlatego ważne jest, aby jasno sprecyzować co jest kryterium osiągnięcia sukcesu, zanim prace zostaną rozpoczęte. Najczęściej o tym czy projekt zakończył się sukcesem decyduje to, czy zrealizowaliśmy 100% celów. W małych i średnich projektach cele mogą nie być jednak precyzowane. W takim przypadku można uznać, że projekt zakończył się powodzeniem, jeśli wszystkie przedmioty dostaw wykonano na czas, zgodnie z
181 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wymaganiami, za ustalony budżet. Zespół przygotowuje dla sponsora sprawozdanie, w którym dowodzi, że cele / przedmioty dostaw zostały zrealizowane zgodnie z oczekiwaniami. Ostatecznie o uznaniu sukcesu projektu decydują klient i sponsor. Więcej informacji w rozdziale 6.1.1.1 P1.
Przekazanie
rozwiązanie do działu, który będzie używał go w pacy operacyjnej. Jeśli rozwiązanie będzie używane po zakończeniu projektu, powinno ono być przekazane do odpowiedniego działu. Przekazanie to obejmuje: dostarczenie dokumentacji związanej z rozwiązaniem, wsparcia i wiedzy dla użytkowników, itd.
Przekaż dokumentację projektu (w stosownych przypadkach).
Czasem dział przejmujący przedmiot dostawy może chcieć dokumentację projektową – definicję, harmonogram prac, plan zarządzania projektem etc. Ustala jak zostaną one przekazane, komu, kiedy i w jakiej formie.
Przeprowadź ocenę pracowników. Po zakończeniu projektu kierownik projektu oraz zespół może być poddany ocenie pracy. Według ustalonej metody kierownik ocenia podwładnych, oni zaś dalszych podwładnych etc.
Rozwiąż zespół
projektowy. Po zakończeniu projektu każdy członek zespołu powinien zostać gdzieś przydzielony. Dla niektórych ludzi może to oznaczać realizację nowych projektów. Dla ludzi na umowach może to oznaczać koniec ich zatrudnienia. Dla pracowników niepełnoetatowych (w projekcie) może to oznaczać powrót do ich pełnoetatowych obowiązków sprzed projektu. Niektórzy członkowie zespołu mogą przejść do działu wsparcia, aby kontynuować pracę nad tym samym rozwiązaniem. Kierownik projektu jest odpowiedzialny za zaplanowanie procesu zamykania i umieszczenie odpowiednich zadań w harmonogramie. Powinny być one postrzegane jako istotne części projektu. Projekt nie jest uważany za ukończony, zanim nie zostaną wykonane czynności zamknięcia!
182 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.4 Zarządzanie Harmonogramem i budżetem / Zarządzanie budżetem projektu 3.1.4.P1 Wskazówki ogólne Jeśli rejestrujesz wydatki projektu w narzędziu do zarządzania projektem przegląd budżetu będzie bardzo prosty. Porównanie rzeczywistych wydatków z planowanymi pojawi się po prostu, kiedy uruchomisz odpowiedni raport. Czasem zdarza się, że narzędzia wspomagające zarządzanie projektem są zintegrowane z systemami finansowo księgowymi. Wtedy wszystkie informacje będą zgromadzone „w jednym miejscu”. Jednak najczęściej będziesz musiał, dokonując przeglądów budżetu, analizować różne dokumenty – arkusze kalkulacyjne, tabele etc. lub używać wydzielonego systemu finansowego. Powinieneś odnotowywać, niezależnie od używanego narzędzia, wszystkie wydatki poniesione do tej pory - koszty pracy, wyposażenia, materiałów etc. Potem porównywać te dane z oryginalnym budżetem. Termin „budżet” może odnosić się do całkowitego budżetu projektu, lub do zbioru wszystkich aktywnych kont kosztowych, w danym momencie projektu. Nie zawsze możesz mieć porównanie „jeden-do jednego”(konto-do-konta). Jest kilka powodów, dla których projekt może wyglądać, jakby miał problemy z budżetem, gdy w rzeczywistości ich nie ma.
Pewne koszty mogą być zabudżetowane, ale w innym okresie czasu. Jeśli w tym
okresie zapłacisz za znaczący zakup, który był pierwotnie planowany na następny okres, wtedy nie powinno Cię zaskakiwać, że formalnie rzecz biorąc przekroczyłeś budżet. Taki rodzaj „technicznego” przekroczenia budżetu z czasem zniknie.
Może wydawać się, że przekroczyłeś budżet, ale mogłeś go nie przekroczyć, jeśli
również wyprzedzasz nieco harmonogram. Jeśli Twój projekt jest zgodny z harmonogramem, ale przekracza budżet, to może to być problem. Jakkolwiek, jeśli Twój projekt wyprzedza harmonogram, może być dobrze, że trend przekroczenia Twojego budżetu rośnie. Na przykład, może zapłaciłeś nadgodziny zleceniobiorcy, aby wyprzedzić harmonogram. W tym przypadku, przy zakończeniu projektu, powinno się okazać, że projekt wykonał się w ramach pierwotnie przydzielonego budżetu.
Następujące scenariusze ilustrują sytuacje przekroczenia budżetu, gdzie projekt rzeczywiście jest zagrożony. Jeśli trend wykorzystania budżetu rośnie w związku z poniższymi sytuacjami, działania korygujące będą niezbędne.
Projekt
dąży do przekroczenia budżetu, ponieważ niektóre z czynności zabierają więcej prachchłonności, niż szacowana. Powodem może być praca w nieplanowanych nadgodzinach lub stosowanie większej ilości zasobów niż szacowane. W tym przypadku, jeśli trend będzie trwał nadal, budżet projektu może być zagrożony. Powinno to być podniesione jako ryzyko budżetowe, chyba że są okoliczności łagodzące, które umożliwią odwrócenie się trendu.
Twoje oszacowania kosztów mogą okazać się, że są niewłaściwe, ponieważ
mogłeś niedoszacować koszty pracy czy pozapłacowe. Jeśli posiadasz w
183 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
budżecie rezerwę szacunkową, możesz ją wykorzystać do zrównoważenia błędów szacunkowych. Jeśli nie posiadasz takiej rezerwy - będziesz musiał podjąć proaktywne działanie korygujące.
Jest możliwe, że obowiązkowe czynności lub koszty projektu były przeoczone
podczas estymacji. Jeśli teraz ta praca lub wydatek są wymagane, możesz nie być w stanie skutecznie przeprowadzić formalnej zmiany zakresu. W tym przypadku powinno zostać obsłużone ryzyko budżetowe, o ile było przewidziane. Ostatecznie mogą zaistnieć okoliczności łagodzące, które umożliwią Ci odzyskanie pieniędzy poprzez oszczędności gdzie indziej.
Możesz wykonywać czynności, które są poza zatwierdzoną Definicją projektu lub wymaganiami businessowymi. W takim razie, praca ta powinna zostać zatrzymana aż do skutecznego przeprowadzenia formalnej zmiany zakresu. Nawet jeśli sytuacja przekroczenia budżetu może być złagodzona poprzez oszczędności kosztów w innym miejscu projektu, wnioski o zmianę zakresu nie powinny móc wpływać na projekt zanim nie zostaną zatwierdzone.
Jeśli wystąpi taka sytuacja, kierownik projektu musi bardziej dociec, czy jest to problem, potencjalny problem lub czy może wcale nie ma problemu.
184 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.5 Zarządzanie Harmonogramem i budżetem / Przeglądy kamieni milowych 3.1.5.P1 Wskazówki ogólne Przy osiągnięciu kamienia milowego, zespół powinien zrobić krótką przerwę, aby upewnić się, że wcześniejsza praca została prawidłowo wykonana i że zespół i klient są gotowi, aby przejść do następnej fazy. Czasami te kryteria nazywane są kryteriami wyjścia i wejścia lub „bramkami”. Pytania jakie stawia się po osiągnięciu kamieni milowych oraz elementy projektu podlegające kontroli są niemal identyczne w każdym projekcie, w każdej fazie. Dlatego dobrze jest utworzyć listę kontrolną ułatwiającą dokonanie przeglądu projektu przy każdym ważniejszym kamieniu milowym. Można powiedzieć, że przeglądy te są w pewien sposób elementami procesu zapewnienia jakości. Jeśli kamień milowy został osiągnięty, oznacza to, że przedmioty dostaw sygnalizowane tym właśnie kamieniem zostały już odebrane i nie muszą już podlegać przeglądowi. Dlatego po osiągnięciu kamienia milowego analizujemy prawidłowe działanie procesów. Uzyskiwanie formalnego zatwierdzenia wykonania kamieni milowych oraz zgody na dalsze działania ważne jest z kilku powodów.
Zespół
musi upewnić się, że realizuje oczekiwania klienta, a nie własne wizje przedmiotu dostawy. Na przykład, jeśli rozpoczniesz fazę projektowania bez dokładnego zebrania wymagań, możesz zaprojektować rozwiązanie, które nie zaspokaja całkowicie potrzeb klienta. W konsekwencji może się okazać, że będzie trzeba poświęcić czas i środki na dokonanie poprawek.
Musisz upewnić się, że projekt jest nadal akceptowany przez sponsora, ma budżet i
zasoby. Wykonanie przeglądu i uzyskanie formalnej aprobaty do kontynuowania pracy pozwoli na realizowanie dalszej pracy. Jeśli kontynuujesz bez formalnej aprobaty, może okazać się, że tracisz zasoby na pracę, która nie ma już wystarczająco wysokiego priorytetu. Zgoda na kontynuowanie pracy zazwyczaj wyrażona jest podczas spotkania sponsora, klienta oraz interesariuszy z kierownikiem projektu. Plan takiego spotkania może być następujący:
Omów celu spotkania. Dokonaj przeglądu kryteriów
wyjścia z fazy projektu (czyli tych warunków na podstawie których twierdzisz, że faza jest zakończona)
Przekaż do odbioru jakiegoś przedmiotu dostawy Dokonaj przeglądu budżetu Dokonaj przeglądu zaległej pracy danej fazy
Dokonaj przeglądu kryteriów wejścia dla następnej fazy. Potwierdź kosztorysy dla pracy w tej fazie oraz w pozostałej części projektu Potwierdź, że powody dla jakich robisz projekt są aktualne 185 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Potwierdź dostępność zasobów dla reszty projektu. Potwierdź, że sponsor jest nadal zainteresowany projektem Potwierdź ogólny harmonogram następnej fazy.
Uzyskaj oficjalną aprobatę do kontynuowania pracy
Oficjalna aprobata dla kontynuowania pracy oznacza, że zadania wykonane aż do tego momentu są w porządku i że zespół może teraz skoncentrować się na następnej fazie.
186 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.6 Zarządzanie Harmonogramem i budżetem / Zarządzanie projektami wykorzystującymi prace podwykonawców 3.1.6.P1 Wskazówki ogólne Outsourcing w projektach jest dzisiaj bardziej powszechny niż kiedykolwiek. Chociaż można zlecić niemal każde zadanie, to jednak nie można wydelegować nadzoru nad pracą realizowaną przez stronę trzecią. Kierownik projektu (choć i on może być outsourcowany) musi zapewnić, że projekt jest realizowany zgodnie z planem i oczekiwaniami. Jeśli wszystko idzie dobrze nie jest to zadanie wymagające wielkiego wysiłku. Niestety, w wielu przypadkach, dostawca działa niezgodnie z oczekiwaniami. O takich sytuacjach powinieneś wiedzieć tak szybko, jak to możliwe. Wielu ludzi nie wie co robić, gdy w ich projekcie występuje outsourcing. Po części dlatego, że w takich projektach część ról jest przesunięta poza obszar organizacji i pełnią je pracownicy strony trzeciej, a część niejako dubluje się. W normalnym projekcie kierownik projektu przydziela zadania, zarządza problemami krytycznymi, zakresem, ryzykiem, jakością, itd. Upewnia się też, że praca jest wykonana na czas i że projekt jest realizowany tak, jak powinien. Jest on obarczony odpowiedzialnością za zarządzanie gwarantujące sukces projektu. Inni ludzie dbają o zapewnienie jakości, np. grupa zapewnienia jakości lub sponsor i kierownik projektu. Nie są oni zainteresowani znajomością wszystkich szczegółów dotyczących tego, co się dzieje. Muszą natomiast umieć zadać odpowiednie pytania, aby być pewnym, że sprawy rozwijają się tak jak powinny. W projekcie gdzie występuje outsourcing role te nie zmieniają się, ale są realizowane przez innych ludzi. Osobą rozdzielającą zadania, dbającą o zakres i ryzyka jest kierownik projektu po stronie dostawcy. W tej sytuacji tak naprawdę przyjmujesz rolę menedżera ds. zapewnienia jakości. Musisz umieć zadać odpowiednie pytania, aby upewnić się, że kierownik projektu dostawcy wykonuje swoją pracę prawidłowo. Niekoniecznie musisz znać wszystkie detale. Musisz natomiast wiedzieć czy projekt rozwija się tak, jak oczekiwano. 3.1.6.P2 Co sprawdzać na początku? Najpierw sprawdź czy dostawca stworzył dokumentację, którą każdy projekt powinien posiadać. Na przykład, czy jest stworzona Definicja Projektu lub inny dokument pełniący tę funkcję? Musisz upewnić się, że dostawca zdefiniował projekt prawidłowo. Powinieneś zatwierdzić ten dokument. Dostawca musi również posiadać harmonogram projektu. Gdy projekt jest realizowany, musisz znać daty kluczowych kamieni milowych oraz punktów kontrolnych, które pozwolą Ci sprawdzić i jednoznacznie ocenić stan prac. Ty i sponsor powinniście formalnie zatwierdzać ważniejsze kamienie milowe. Jeśli dokonywana jest częściowa płatność za zrealizowanie kamienia milowego, musisz upewnić się, że kryteria odbioru są spełnione i płatność dla dostawcy może zostać uruchomiona. W zależności od typu projektu, możesz wymagać regularnych spotkań zespołu projektowego i formalnych raportów postępów prac. Pytania, które musisz zadać na początku projektu to: 187 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Czy
dokument Definicja Projektu (lub analogiczny) został zatwierdzony przez właściwych interesariuszy i kierowników w twojej firmie?
Czy
obie strony jednoznacznie rozumieją wzajemne oczekiwania? Czy umowa jasno precyzuje przedmioty dostawy, terminy, budżety, kryteria odbioru pracy etc.?
Czy został stworzony pełny harmonogram projektu? Jakiego planu zarządzania projektem będzie używał dostawca,
aby kontrolować
projekt?
Czy wyjaśniono dostawcy, jakie zasoby będą potrzebne z twojej firmy i kiedy będą one dostępne?
Czy
zostało uzgodnione kilka kamieni milowych, aby móc dokonać przeglądu pracy?
3.1.6.P3 Pytania, jakie należy zadawać gdy projekt jest w toku Gdy projekt jest realizowany, musisz nieustannie zadawać pytania, aby określać bieżący stan projektu. Można organizować zebrania z zespołem, wymagać systematycznych raportów oraz dokonywać przeglądu projektu podczas osiągnięcia kolejnych kamieni milowych. Rodzaje pytań, które należy zadać przy każdym kamieniu milowym obejmują:
Czy przedmioty dostawy wyszczególnione w dokumencie definiującym projekt zostały wykonane?
Czy przedmioty dostawy zostały zatwierdzone przez firmę? Jeśli dostawca spełnił oczekiwania, czy zostały uruchomione płatności? Czy dostawca może klarownie wyjaśnić, gdzie projekt się znajduje,
a gdzie
powinien teraz być?
Czy
wszystkie przyszłe przedmioty dostawy wyszczególnione w dokumencie definiującym projekt zostaną wykonane?
Czy problemy krytyczne, zakres i ryzyko są zarządzane tak jak ustalono w planie zarządzania projektem?
Czy umowa lub dokument definiujący projekt powinny być uaktualnione, aby odzwierciedlić jakiekolwiek znaczące zmiany w projekcie?
Gdy zrozumiesz swoją role, łatwiej jest zadać właściwe pytania, aby upewnić się, że wszystko rozwija się tak jak powinno. W celu uzyskania pełniejszej listy pytań, zobacz Listę kontrolną procesu zapewnienia jakości znajdującą się w bibliotece TenStep.
188 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.1.7 Zarządzanie harmonogramem i budżetem / Potwierdzanie oszacowań pracy przez zespół 3.1.7.P1 Jednym z podstawowych obowiązków kierownika projektu jest zbudowanie harmonogramu i przydzielanie członkom zespołu zadań do wykonania. Po tym jak przydzielisz pracę członkom zespołu, powinieneś obarczyć ich odpowiedzialnością za wykonanie jej zgodnie z oczekiwaniami. Na pozór, to brzmi bardzo trywialnie. Jednakże, czy jest to naprawdę uczciwe i bezkonfliktowe? Kierownik projektu bardzo nie lubi sytuacji, gdy ma zrealizować zdefiniowany przez kogoś innego projekt, według czyjegoś harmonogramu i budżetu. Podobnie może być z pracownikami. Jeśli nie uczestniczyli w budowaniu harmonogramu, mogą nie zaakceptować ilości godzin przydzielonych do konkretnych zadań. Po drugie, nawet jeśli podejmą się tej pracy, nie będą się czuć odpowiedzialni za wykonanie jej według ustalonych ram. Są dwa sposoby, aby sprawić, że członkowie zespołu będą czuli się odpowiedzialni za swoje zadania – wykonanie ich zgodnie z harmonogramem i budżetem. Po pierwsze, możesz zaangażować ludzi w budowanie harmonogramu i budżetu. Czasem nie jest to możliwe. Jednak jeśli jest, przynosi dobre rezultaty. Gdy w planowaniu biorą udział doświadczeni specjaliści powstałe oszacowania są bardziej wiarygodne, niż gdyby tworzył je sam kierownik. Z drugiej strony, członkowie zespołu mogą nie być znani z imienia i nazwiska, gdy projekt jest planowany. Wtedy twórcy początkowych harmonogramów muszą przyjąć jakieś założenia „średniej” wydajności zespołu. W tym przypadku stosowne jest, aby przydzielając zadania członkom zespołu pytać ich, czy oszacowanie czasu i kosztu wydaje się rozsądne. Jeśli członkowie zespołu potwierdzają, że praca jest do zrealizowania w zadanych granicach, wtedy możesz obarczyć ich odpowiedzialnością, za wykonanie jej w ramach tych oszacowań. Oczywiście, gdy przydzielasz zadanie, członkowie zespołu mogą nie wiedzieć wystarczająco dużo, aby stwierdzić, czy estymacje są rozsądne, czy nie. Może to zająć trochę czasu, czasem będzie możliwe dopiero po rozpoczęciu zadania. W tym przypadku przydzielasz zadanie według pierwotnych oszacowań pracochłonności i kosztu. Następnie prosisz członków zespołu, aby stwierdzili, czy praca może być zrealizowana w ramach tych wielkości. Jeśli członek zespołu czuje, że estymacje są nieprawidłowe, musi poinformować cię o tym TAK SZYBKO, JAK TO MOŻLIWE. Wtedy jest on zobowiązany do dostarczenia bardziej realistycznej, własnej estymacji. Następnie można uzgodnić i wynegocjować ostateczną wersję oszacowań i kontynuować pracę. Najważniejsze w tym scenariuszu jest to, że członek zespołu informuje natychmiast, gdy uzna, że pierwotne estymacje są niedoszacowane. Nie jest akceptowalna sytuacja, gdy poinformuje, że nie dotrzyma terminu w momencie, gdy właśnie on upłynął.
189 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2 Zarządzanie Harmonogramem i budżetem / Techniki 3.2.P1 Techniki przywracania zgodności prac z harmonogramem Mimo, że monitorujesz swój projekt w sposób ciągły, nie oznacza to, że nigdy nie przekroczysz terminów. Dzięki proaktywnemu zarządzaniu harmonogramem bardzo szybko zauważysz, że projekt ma tendencję do opóźnień. Jeśli nic z tym nie zrobisz, na pewno nie wykonasz pracy na czas. Jest znanych wiele technik korygujących, dzięki którym można przywrócić zgodność projektu pierwotnymi ustaleniami dotyczącymi terminów. Aczkolwiek nie ma prostych, uniwersalnych recept. Zobacz: 3.2.3. 3.2.P2 Techniki przywracania zgodności projektu z budżetem Jeśli regularnie monitorujesz koszty, powinieneś bardzo szybko zauważyć, jeśli dążysz do przekroczenia budżetu. Proces kontroli jest w pewnym stopniu trudniejszy, niż zarządzanie harmonogramem. Niezgodności rzeczywistych kosztów ponoszonych przez projekt z planowanym budżetem może wynikać z większej liczby powodów, niż w przypadku harmonogramu. Zobacz: 3.2.4. 3.2.P3 Upewnij się, że członkowie zespołu wiedzą, jakie są ich zadania Jednym z podstawowych obowiązków kierownika projektu jest przydzielanie zadań członkom zespołu. Jednakże, niektórzy kierownicy nie do końca rozumieją co jest istotą zadania, które ma być wykonane. A co za tym idzie nie potrafią wydelegować osoby, która będzie odpowiedzialna za realizację tego zadania. Powoduje to wiele zamętu w zespole i jest częstą przyczyną opóźnień. Jeśli zarządzasz projektami już jakiś czas, prawdopodobnie spotkałeś taki problem. Pewnie nie raz zdarzyło ci się spytać członka zespołu o postęp realizacji jakiegoś krytycznego zadania i mógł on oznajmić, że nie zdawał sobie sprawy, że w ogóle był odpowiedzialny za nie. Dobrym sposobem sprawdzenia, czy ludzie zrozumieli wytyczne oraz wiedzą co ma się dziać w najbliższym czasie jest odpytanie ich, jak ich zdaniem będzie przebiegać praca w następnym tygodniu. Nie musisz tego robić zawsze, z każdym członkiem zespołu. Jednakże, warto zapytać raz na jakiś czas, lub gdy nadchodzący okres jest bardzo istotny dla powodzenia projektu. Jeśli członkowie zespołu wiedzą czego się od nich oczekuje, oznacza to, że przydzielasz zadania jasno i klarownie. Jeśli zapytani udzielają odpowiedzi innych niż oczekujesz, może to oznaczać, że musisz pracować nad swoją komunikatywnością. Jeśli członkowie zespołu doskonale rozumieją pracę, ale nie dostarczają jej na czas, możesz mieć problem z wydajnością. Jeśli nie rozumieją czego się od nich oczekuje to problem z komunikacją. Gdy przydzielisz zadania członkom zespołu powinni oni:
Znać nazwę zadania w harmonogramie Umieć wyjaśnić, co jest potrzebne do wykonania zadania 190 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Znać daty rozpoczęcie i zakończenia. Musisz być pewny, że pracownik wie kiedy zadanie może się rozpocząć i kiedy powinno się zakończyć. Członek zespołu musi wiedzieć, że jeśli nie może wykonać zadania w terminie, musi poinformować cię tak szybko, jak to możliwe.
Znać
szacunkową pracochłonność. Powinieneś przekazać szacunkową pracochłonność, wymaganą do wykonania zadania. Ma to zazwyczaj drugorzędne znaczenie w porównaniu z datą planowanego zakończenia pracy. Jeśli członek zespołu nie może wykonać czynności w ramach szacunkowej pracochłonności, musi on poinformować ciebie tak szybko, jak to możliwe. Jednakże, w większości projektów, jeśli czynność jest wykonywana według harmonogramu, nie jest tak ważne, czy praca zajmuje więcej czy mniej rzeczywistej pracochłonności.
Znać
szacunkowe koszty. Jeśli członek zespołu nie może wykonać pracy w granicach oszacowanych kosztów, musi poinformować cię tak szybko, jak to możliwe. Jeśli czynność generuje wyłącznie koszty pracy, nadwyżka przekraczająca budżet będzie bezpośrednio związana z kosztem pracy. Jednakże, jeśli podczas realizacji czynności powstają koszty nie związane z pracą, możliwe jest, że to one mogą spowodować przekroczenie budżetu.
Wiedzieć
jaki jest pożądany przedmiot dostawy. Członek zespołu musi rozumieć jaki jest pożądany przedmiot dostawy. Jeśli przedmiot ten musi spełniać jakieś kryteria jakości, członek zespołu powinien znać je.
Znać
relacje tego zadania z innymi. Upewnij się, że członek zespołu zna powiązania jego zadania z innymi - tymi, które oczekują na zakończenie jego zadania lub tymi, które muszą być wykonane, zanim będzie mógł rozpocząć pracę.
Wiedzieć kim są Inni wykonawcy. Jeśli nad tym samym zadaniem pracuje wielu ludzi, muszą oni się znać. Po za tym wykonawcy muszą wiedzieć kto personalnie jest odpowiedzialny za zrealizowanie zadania.
3.2.P4 Zarządzaj w granicach tolerancji Gdy zarządzasz harmonogramem i budżetem, nie musisz być dokładny co do minuty lub dolara. Nie powinieneś również proaktywnie zgłaszać wniosku o zaakceptowanie zmian, jeśli twój projekt w jednym tygodniu przekracza o jeden dzień jakiś niezbyt ważny termin a o jeden dzień wyprzedza harmonogram w następnym tygodniu. Twój klient nie oczekuje tego poziomu dokładności. Jako kierownik projektu, powinieneś rozmieć poziom tolerancji dla twojego projektu. Na przykład, powiedzmy, że uaktualniasz Twój harmonogram i zdajesz sobie sprawę, że przekroczyłeś budżet o 1.000 $. Czy powinieneś zgłosić problem krytyczny lub ryzyko budżetu? Czy powinieneś poinformować klienta? To zależy od poziomu tolerancji. Jeśli posiadasz budżet 10.000 $, prawdopodobnie powinieneś być zaniepokojony, ponieważ możesz przekroczyć budżet o 10%. Ale jeśli projekt posiada budżet milion dolarów, wtedy tysiąc dolarów nie jest wcale istotną kwotą. Byłbyś uznany na bohatera, gdybyś projekt tej wielkości zrealizował z dokładnością do tysiąca dolarów! Zachowaj zdrowy rozsądek i ustal z klientem poziom tolerancji dla budżetu i terminów.
191 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.P5 Rozważ ZARZĄDZANIE harmonogram i budżet
WARTOŚCIĄ
WYPRACOWANĄ
by
lepiej
rozumieć
Projekty, szczególnie duże, nigdy nie są wykonywane dokładnie tak, jak są zaplanowane. Niektóre zadania kończą się wcześniej inne później. Czasami nie jest łatwo określić, czy projekt jest opóźniony czy wyprzedza plan. Podobnie, czasami ciężko jest stwierdzić, czy przekroczyłeś budżet, czy nie. Spójrzmy na prosty przykład. Powiedzmy, że masz sześciomiesięczny projekt. Pracujesz już trzy miesiące. Twój harmonogram mówi, że wydałeś 50% budżetu, ale zdajesz sobie sprawę, że faktycznie wydałeś już 65% budżetu. Czy masz problem? Jeśli wykonałeś tylko połowę pracy, możesz mieć kłopoty. Ale co, jeśli w rzeczywistości realizujesz już zadania, które miały być robione dopiero za miesiąc? Jeśli wszystkie prace poszły szybciej, może to mieć sens. Faktycznie w tym momencie projektu przekraczasz budżet. Jeśli w trzecim miesiącu wykonałeś 90 % pracy i wykorzystałeś budżet w 65 % całości, w rzeczywistości jesteś w całkiem niezłej sytuacji. Aby powyższa sytuacja byłą jednoznaczna korzysta się z metody zarządzania wartością wypracowaną. Jest to metoda określania postępu projektu, wziąwszy pod uwagę to gdzie jesteś w relacji do tego gdzie powinieneś być. Więcej w rozdziale: 3.2.2 Zarządzanie harmonogramem i budżetem / Wartość Wypracowana. 3.2.P6 Ustal, kto może uaktualniać harmonogram i budżet W większości projektów jedynie kierownik projektu jest odpowiedzialny za harmonogram i on uaktualnia go cotygodniowo. Jednakże, są inne opcje zwłaszcza w dużych projektach. W niektórych przypadkach kierownik projektu może poprosić każdego członka zespołu, aby zaznaczał w harmonogramie postępy w swoich pracach. W tym wypadku członkowie zespołu na co dzień odznaczają wykonane zadania. Jeśli nie zdążyli, poprawiają datę końcową, aby wskazać, kiedy zadanie będzie wykonane. Mogą oni również zapisywać rzeczywistą pracochłonność zadań. W większości przypadków, członkowie zespołu nie mogą przydzielić sobie zadań, dodawać nowych czynności lub zmienić harmonogramu. Dla każdego dużego projektu, powszechne jest również, że jeden lub więcej ludzi jest wyznaczony do uaktualniania harmonogramu w imieniu kierownika projektu. Ludzie ci są czasami nazywani administratorami projektu. Mogą oni otrzymać informacje od członków zespołu i uaktualnić bieżący status i rzeczywiście przepracowane godziny. Mogą mieć dostęp do standardowych raportów kierownika projektu i otrzymywać informacje od członków zespołu, reprezentując kierownika projektu. Kierownik otrzymuje końcową analizę oraz jest informowany o najważniejszych wydarzeniach. Administrator projektu wykonuje większość pracy związanej z harmonogramem, ale nadal obowiązkiem kierownika projektu jest śledzenie i rozumienie, co się dzieje w projekcie i podejmowanie właściwych decyzji, aby pomyślnie wykonać zadania. 3.2.P7 Nie oznaczaj procentowo stopnia wykonanych prac Większość narzędzi wspierających zarządzanie projektem posiada pole do wprowadzenia procentu wykonania dla każdego zadania. Zanim czynność rozpocznie się, jest to 0% wykonania. Gdy jest ona ukończona, jest to 100% wykonania. Jednakże trudno zrozumieć co może znaczyć jakakolwiek inna cyfra. Na pierwszy rzut oka, jeśli członek zespołu pracował 20 godzin w zadaniu oszacowanym na 40 godzin, 192 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
powiedziałbyś, że wykonał 50% pracy. Ale czy faktycznie zrobił połowę? Może w tym czasie zrobił wszystko, a może tylko 10%? Jeśli pozwolisz, by w raportach realizator określał procent wykonania zadania, będzie to bardzo nieścisłe. Najczęściej gdy czynność opóźnia się, ludzie deklarują „90 % wykonania”. Z reguły w pierwszym tygodniu opóźnienia, członek zespołu mówi, że zrobione jest 90%, w następnym tygodniu zrobione jest 95%, w następnym tygodniu zrobione jest 99%, itd. Lepszym sposobem jest zapytać: „Kiedy praca będzie zrobiona?”. Jeśli harmonogram pokazuje, że czynność powinna być wykonana w piątek i praca nie jest zrobiona, nie pytaj członka zespołu o procent wykonania. Zamiast tego, zapytaj: „Kiedy praca będzie zrobiona?”. Pytanie to daje konkretną informację, którą możesz umieścić w harmonogramie. Po drugie, wykonawca składa bardzo poważne względem ciebie zobowiązanie, które możesz egzekwować. 3.2.P8 Zarządzaj zadaniami poprzez egzekwowanie daty zakończenia W wielu organizacjach zespół nie odnotowuje rzeczywistej pracochłonności zadań. O ile nie jest to ważne dla firmy, kierownik projektu może czuć się upoważniony do zarządzania zadaniami wyłącznie w oparciu o daty ukończenia zadań i nie przejmować się pracochłonnością. Na przykład załóż, że zadanie jest zaplanowana na 40 godzin i trwa dwa tygodnie. Jeśli praca jest zrobiona w przeciągu dwóch tygodni, nie jest ważne, czy rzeczywiście pracochłonność wyniosła 35 godzin czy 50. Było by to ważne, jeśli tylko różnica w pracochłonności spowoduje, że planowana data innej przydzielonej czynności będzie opóźniona. Pracochłonność ważna jest w procesie szacowania, ponieważ pomaga ona ustalić daty ukończenia oraz w miarę rozsądnie obciążyć zasoby. Ale gdy zadania zostaną przydzielone, najważniejsze jest wykonanie pracy na czas. Jest jeden ważny wyjątek. Jeśli praca jest wykonywana przez zasób, który wynagradzasz godzinowo. Wtedy ważne jest, aby monitorować poprzez pracochłonność i datę zakończenia. Teraz ma znaczenie, czy 40 godzinna czynność zajęła 50 godzin. 3.2.P9 Stosuj kamienie milowe, aby sprawdzać postępy prac Kamień milowy jest planowym wydarzeniem, które oznacza ukończenie znaczącego przedmiotu dostawy lub zestawu powiązanych przedmiotów dostawy. Kamień milowy z definicji posiada zerowy czas trwania i nie wymaga pracochłonności. Kamienie milowe są ważne dla kierowników i sponsora, ponieważ dzięki nim można zatwierdzić bieżący stan projektu i zweryfikować jak wygląda jego przyszłość. W szczególności przy każdym kamieniu milowym możesz wykonać, poniższe czynności.
Potwierdź, że praca zrobiona aż do tego momentu, jest odebrana. Klient powinien
móc zatwierdzić jakiekolwiek przedmioty dostawy wytworzone, aż do tego momentu.
Upewnij się, ze reszta harmonogramu obejmuje wszystkie zadania konieczne do wykonania całości projektu.
Sprawdź
ponownie pracochłonność, czas trwania i oszacowania kosztów dla pozostałej pracy. W oparciu o uprzednią pracę wykonaną do teraz, możesz mieć dużo lepsze wyczucie, czy pozostałe estymacje są wiarygodne. Jeśli nie są,
193 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
będziesz musiał zmodyfikować harmonogram. Jeśli wydaje się, że budżet i terminy nie zostaną dotrzymane, zgłoś problem krytyczny.
Opublikuj raport o stanie projektu, oraz wykonaj inne zadania ustalone w Planie komunikacji.
Dokonaj
przeglądu planu zarządzania ryzykiem oraz sprawdź czy pojawiło się jakieś nowe ryzyko.
Uaktualnij
wszystkie inne dzienniki i raporty wymagane w planie zarządzania
projektem. Te czynności powinny być wykonywane regularnie, ale fakt osiągnięcia kamienia milowego jest dobrym momentem, aby nadrobić zaległości, zorientować się, co jest dalej i przygotować się, aby ruszyć do przodu. 3.2.P10 Poddaj się audytowi projektu, aby zweryfikować harmonogram i budżet W wielu przypadkach pożądane jest, aby strona trzecia (osoby z zewnątrz) dokonały oceny sposobu stosowania procesów zarządzania projektem oraz sprawdzenia, że projekt realizowany jest zgodnie z oczekiwaniami. Tą „stroną trzecią” mogłaby być jakakolwiek wykwalifikowana osoba lub firma. W niektórych przypadkach twoja organizacja może posiadać specjalistę mającego kompetencję do wykonywania audytów projektów. Możliwe jest, że dyrektor projektu lub sponsor mogliby również wykonać taki audyt. Audyt powinien być wykonany na wniosek kierownika projektu lub kierownika funkcjonalnego w ramach procesu zarządzania jakością. W niektórych przypadkach (projekty rządowe) mogą być wymagane audyty okresowe, jako część kontraktu. W każdym razie audyt zewnętrzny powinien zapewnić interesariuszom projektu, że w projekcie stosowane są skuteczne procesy zarządzania projektem i że projekt wydaje się być na właściwej drodze. Audyt projektu skupia się na zapewnieniu jakości – zadając pytania o procesy stosowane, aby dobrze wykonać przedmioty dostawy. Więcej informacji o technikach zapewnienia jakości możesz znaleźć w: 9.2.3 Zarządzaj jakością / Zapewnienie jakości. 3.2.P11
Kontroluj intensywnie niezrealizowane
gdy
zadania
‗ukończone‘
okazują
się
Czasami członek zespołu mówi, że czynność jest wykonana, ale w rzeczywistości nie jest ona całkiem zakończona. Może to się zdarzyć z następujących powodów:
Czynność powinna być wykonana i członek zespołu wierzy, że potrzebuje tylko
małej ilości czasu, aby ją wykonać. Woli powiedzieć, że jest ona wykonana i następnie szybko ją skończyć, niż narazić się na konsekwencje opóźniania.
Czynność jest „ukończona” przez członka zespołu, ale nie jest odebrana. Członek
zespołu może zaraportować, że praca jest wykonana, ale gdy przedmiot dostawy jest sprawdzany, może zostać uznane, że jest on niedokończony lub wymaga poprawek. Aby uniknąć takich sytuacji, upewnij się, że dla wszystkich znaczących przedmiotów dostawy ustalono proces zatwierdzania i że w harmonogramie pozostawiłeś czas na 194 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
proces zatwierdzania i poprawki. Wówczas nie ma rozbieżności - przedmiot dostawy jest ukończony, ponieważ albo został on zatwierdzony, albo odrzucony. Jeśli zadanie nie kończy się przedmiotem dostawy i nie masz za bardzo pomysłu jak sformalizować proces uznawania czy zadanie jest zakończone – po prostu pracuj nad komunikacją z zespołem.
195 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.P12 Zarządzaj harmonogramem stosując Action Item Action Item są niczym więcej niż pracą, która musi być zrobiona, aby wykonać zadanie, odpowiedzieć na zaległe pytanie, itd. Praca jest zazwyczaj zgłaszana ad-hoc, powiedzmy jako wynik jakiegoś spotkania i zazwyczaj ma być wykonana do następnego zebrania. Jedną techniką zapewnienia, że Action Item są wykonane, jest umieszczenie ich w harmonogramie. W celu uzyskania dalszych informacji, zobacz: 3.2.1 Zarządzanie Action Item. 3.2.P13 Zastosuj pojęcie potrójnego ograniczenia, aby zarządzać kosztem, harmonogramem i zakresem Efektem realizacji definiowania i planowania pracy (proces 1 i 2) jest uzyskanie ze sponsorem porozumienia co do pracy jaka jest do wykonania, kosztów oraz czasu trwania pracy. Te trzy główne składniki utworzą tzw. ”potrójne ograniczenie”. Głównym założeniem potrójnego ograniczenia jest to, że jeśli jeden z czynników ulegnie zmianie, przynajmniej jeden - jeśli nie dwa pozostałe - muszą również ulec zmianie. (Potrójne ograniczenie jest opisywane na kilka sposobów. Koszty mogą być zastąpione pracochłonnością, co ma sens, jeśli koszty pracy są tylko wewnętrzne i nie ma żadnych kosztów nie związanych z pracą. Czasami zakres zastępowany jest jakością i wtedy skupia się on na uzyskaniu właściwego poziomu jakości dla danych kosztów i czasu trwania. Jest to nieco węższy zakres potrójnego ograniczenia, ale ogólna zasada pozostaje taka sama).
Ko sz t
ia an t rw as Cz
Pojęcie to można łatwo wizualizować – potrójne ograniczenie to trójkąt, na którego bokach opisane są kolejno: koszt, czas trwania oraz zakres pracy.
Zakres pracy
Cz a Ko sz t
Jeśli zakres pracy poszerza się , koszty i / lub data zakończenia muszą również wzrosnąć. Jeśli masz więcej pracy do wykonania, wzrośnie również koszt (pracochłonność) i być może wydłuży czas trwania pracy. (Podobnie, jeśli zredukujesz zakres pracy, koszt (pracochłonność) i / lub czas powinien również się zmniejszyć).
196 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Zakres pracy
st
rw a
ni a
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
a Cz
n oś
ie
nia le ma
s Ko
r zt
wa s tr je
Jeśli zostaniesz poproszony o przyspieszenie projektu i zakończenie go wcześniej niż planowano, logiczne będzie wnioskowanie o zredukowanie pracy. Jeśli jednak będziesz miał dostarczyć tę samą pracę w krótszym czasie – wartość opisana na trzecim boku musi się zwiększyć, aby utrzymać równowagę. Jest to zasadne, gdyż będziesz musiał zwiększyć koszt (pracochłonność), zabezpieczając pracę w nadgodzinach lub wykorzystując więcej zasobów, aby zakończyć pracę wcześniej.
Zakres pracy bez zmian
3.2.P14 Zarządzaj detalami oraz sprawami ogólnymi projektu, w zależności od sytuacji Jednym z powszechnych obowiązków wszystkich kierowników jest zarządzanie ludźmi i zarządzanie pracą (jeśli nie robisz tego, nie jesteś naprawdę kierownikiem). Wszyscy kierownicy muszą mieć aktualne, istotne i dokładne informacje po to, aby mogli oni skutecznie zarządzać swoimi ludźmi i pracą. Sztuką jest, oczywiście, wiedzieć, jak dużo informacji potrzebujesz i na jakim poziomie. Niektórzy kierownicy lubią trzymać się z dala od szczegółów. Mogą powiedzieć, czy praca jest ogólnie zgodna z harmonogramem, ale nie to nad czym pracują członkowie zespołu w danym momencie. Taka postawa może być odebrana jako stanie na uboczu i brak zainteresowania projektem. Problemem jest, że czasami ci kierownicy muszą zająć się szczegółami projektu, aby ustalić, co się dzieje. Nie są w stanie tego zrobić, wolą trzymać się ogółów, nawet gdy projekt jest w nieładzie. Z drugiej strony, mógłbyś cały czas stać nad ludźmi – pytając ich, jak sprawy idą, pomagając im rozwiązać problemy, przedzielając część z ich pracy komuś innemu, jeśli wygląda jakby byli trochę w tyle. Spotkałeś się pewnie i z taką postawą kierowników. Są oni tzw. „mikrokierownikami”. W rzeczywistości poświęcając tak dużo czasu na szczegóły wykonują pracę dwa razy dłużej. Ci kierownicy wywołują również frustrację części zespołu, ponieważ wydaje się, że całkowicie nie mają zaufania do ludzi. Wielu kierowników obawia się określenia mianem „mikrokierownika” z powodu negatywnych konotacji. Jednakże, czasami musisz przydzielić prace i otrzymać informacje zwrotne z dużą częstotliwością. Dzieje się to zazwyczaj w przypadku, jeśli jest właśnie krytyczny moment projektu. Jest to szczególnie istotne, jeśli zespół projektowy nie dostarcza informacji zwrotnej, którą potrzebujesz, aby dokładnie zrozumieć, gdzie projekt się znajduje. Dobrym podejściem do zarządzania jest bycie kierownikiem sytuacyjnym. Ten rodzaj kierownika zapewnia ogólne kierowanie i instruowanie zespołu i próbuje usunąć jakiekolwiek przeszkody. Jednakże, jeśli projekt zostaje z tyłu, lub gdy projekt dochodzi do miejsca, gdzie wiele musi się wydarzyć w krótkich okresach czasu, kierownik ten może szybko przejść do zarządzania szczegółami. 3.2.P15 Bądź proaktywny i bardzo komunikatywny podczas zarządzania projektami z nierealistycznymi terminami Jeśli projektowi, którym zarządzasz wyznaczono nierealne terminy, pierwszą rzeczą jaką powinieneś zrobić, jest omówienie tego ze sponsorem. Ustal w tej rozmowie, czy są jakiekolwiek czynniki, z powodu których tak a nie inaczej wyznaczono terminy realizacji
197 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektu. Na przykład, są one ustalone z powodów czysto biznesowych lub projekt jest związany z jakimś innym, niezależnym od nas wydarzeniem. Z drugiej strony, klienci ustalają jakieś daty ponieważ sami uznają je za stosowne. To niekoniecznie ułatwia ci zadanie. Poprzez lepsze zrozumienie powodu ram czasowych, może ci być łatwiej zmotywować siebie i zespół do pracy. Gdy zrozumiesz dlaczego terminy zostały wyznaczone tak nierealnie, możesz skorzystać z kilku technik.
Spróbuj
zwiększyć zasoby. Wszystkie projekty wymagają pewnego czasu i kosztu, aby stworzyć przedmiot dostawy, ujęty w zakresie projektu. Jeśli odkryjesz, że koszty oraz zakres nie są stałe, porozmawiaj ze sponsorem o zwiększeniu zasobów dostępnych dla projektu. Dodanie zasobów do projektu, powoduje wzrost kosztów, ale może umożliwić realizację projektu w terminie.
Zmniejsz zakres. Porozmawiaj ze sponsorem o zmniejszeniu zakresu projektu. Zobacz, czy są elementy, bez których mogą odebrać projekt w terminie?
Zidentyfikuj
i zarządzaj terminem jako ryzykiem projektu. Wykorzystanie procedur zarządzania ryzykiem pomoże w opanowaniu ewentualnej eskalacji oczekiwań. Po drugie, prawdopodobnie ułatwi gromadzenie informacji dotyczących ryzyka przekroczenia terminu.
Zarządzaj zakresem z zerową tolerancją. Po pierwsze, absolutnie kluczowe jest
to, jak zarządzasz zakresem. Nie zwiększaj zakresu bez wyraźnej zgody sponsora. Po drugie, zdyscyplinowane zarządzanie zakresem zapewni, że dostarczysz tylko to, co było pierwotnie obiecane a jakimkolwiek zmianom towarzyszyć będzie odpowiedni wzrost budżetu.
Zarządzaj agresywnie harmonogramem. W projekcie o jakim mowa nie masz marginesu błędu. Nie możesz pozwolić sobie na jakikolwiek brak precyzji. Gdy monitorujesz harmonogram, traktuj niedotrzymane terminu jako poważny problem i poświęcaj czas, aby odkryć przyczyny powodujące poślizg.
Szukaj
możliwości ulepszenia procesu. Na koniec, spójrz uczciwie na harmonogram i podejście realizacyjne. Porozmawiaj z zespołem, klientami i sponsorem o tym co usprawnić w procesie budowy przedmiotu dostawy, by przyspieszyć projekt. Jeśli nawet nie uzyskasz wartościowych informacji, na pewno sprawisz, że wszyscy poczują się bardziej zainteresowani doprowadzeniem projektu do końca.
3.2.P16 Kierownicy projektów muszą ustalać jakieś nieprzekraczalne terminy, nawet jeśli klient ich nie ustala Wiele projektów posiada wiążące terminy, które są skutkiem ograniczeń biznesowych, kalendarza podatkowego lub powiązania z innymi projektami. Jednakże, wiele projektów nie posiada takiego terminu. W rzeczywistości Twój sponsor może chcieć, aby projekt był ukończony tak szybko, jak to możliwe, ale nie ma powodu by ustanawiać konkretną datę. Wszystkie projekty z definicji wymagają daty końcowej. Gdy zarządzasz projektami, które nie posiadają wiążącego terminu, ważnym jest, aby z zespołem taki termin ustalić. Nadal tworzysz dokument definiujący projekt i harmonogram w oparciu o dostępne zasoby. Gdy zespół zgadza się z harmonogramem, wówczas termin zakończenia prac staje się wiążący. 198 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Zespół projektowy bez wiążącego terminu nie będzie skoncentrowany i wykonanie zadań zajmie mu znacznie więcej czasu, niż w rzeczywistości potrzebował. Jest to również sposób upewnienia się, że projekty nie trwają bez końca, nawet jeśli klient nie czuje pospiechu,
199 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.1 Zarządzanie Harmonogramem i budżetem / Zarządzanie Action Item 3.2.1.P1 Action Item jest zadaniem, które wymaga dość szybkiego wykonania. Z definicji Action Item nie mogą być zaplanowane z wyprzedzeniem. Powstają one ad-hoc np. podczas spotkań lub jako produkt uboczny pracy nad czymś innym. Action Item powstaje wtedy, gdy zespół nie ma wystarczającej wiedzy, umiejętności ani czasu, aby rozwiązać daną sprawę od razu. W wielu przypadkach Action Item nie są dużymi zadaniami, choć czasem są dość znaczne. Przykłady Action Item obejmują np. przesyłanie do kogoś określonych informacji które muszą być specjalnie zebrane, organizowanie nieplanowanych spotkań, wykonanie szybkiego oszacowania jakiejś dodatkowej części pracy. Czasami Action Item jest ustalony w celu zbadania obszaru, gdzie może leżeć potencjalny problem projektu. Z tego powodu, są czasami mylone z problemami krytycznymi. Problem krytyczny jest problemem, który ma znaczny wpływ na projekt, jeśli zostanie pozostawiony bez rozwiązania. Action Item może prowadzić do odkrycia problemu krytycznego lub ryzyka ale Action Item sam w sobie, nie jest problemem krytycznym. Są dwa powszechne podejścia stosowane do zarządzania Action Item. Najlepszym podejściem jest dopisanie go jako czynności dodatkowej w harmonogramie. Zasób i data końcowa są ustalane i czynność ta jest wówczas monitorowana jak jakaś normalne zadanie. Ogólnie rzecz biorąc, jest to podejście, które utrzymuje Action Item w jednym miejscu i pozwala kierownikowi projektu na przestrzeganie zasady że, „jeśli czegoś nie ma w harmonogramie, nie będzie się nad tym pracowało w ramach projektu”. To podejście pozwala kierownikowi projektu widzieć wpływ Action Item na harmonogram. Na przykład, jeśli przydzielisz Action Item osobie na ścieżce krytycznej, spowodujesz opóźnienie w projekcie. Drugim podejściem jest utworzenie osobnego rejestru Action Item. Jeśli stosujesz tę technikę – możesz przeglądać na każdym spotkaniu projektowym rejestr Action Item i wykreślać te, które zostały już zrealizowane.
200 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.2 Zarządzanie harmonogramem i budżetem / Wartość wypracowana 3.2.2.P1 Czy kiedykolwiek byłeś zapytany, jak idą prace w Twoim projekcie? Samo pytanie, choć jest nieprecyzyjne, jest często zadawane. Odpowiedź wówczas, jest równie pozbawiona precyzji: „trzymamy się harmonogramu”. To brzmi stosownie. Mogłeś nawet powiedzieć: „Zrobiliśmy około połowy” lub: „Mamy wykonane 90%”. Jeśli nie posiadasz aktualnego harmonogramu, wiesz, że Twoja odpowiedź jest po prostu domysłem. Jeśli posiadasz dobry harmonogram i aktualizujesz go powinieneś wiedzieć precyzyjnie jak dużo pracy ci pozostało i kiedy realnie zakończysz projekt. Ale czy wykonałeś 50% lub 90%? Kto to wie! 3.2.2.P2 Wartość wypracowaną Pojęcie wartości wypracowanej ustalono by unikać zgadywania podczas określania, gdzie projekt faktycznie jest. W teorii pojęcie to jest bardzo interesujące. Stosowanie go pozwala kierownikowi projektu, wiedzieć dokładnie, jak projekt jest zaawansowany, jak dużo pracy pozostaje, jaki będzie prawdopodobny rzeczywisty koszt i data zakończenia i najróżniejsze inne interesujące informacje. Czy dzisiaj w swoim projekcie stosujesz wartość wypracowaną? Prawdopodobnie nie. Nie stosujesz jej, ponieważ twoja organizacja także jej nie stosuje. Używanie techniki wartości wypracowanej w Twoim projekcie wymaga olbrzymiego poziomu dyscypliny i wspólnego, stosowanego w praktyce zestawu procesów. Trudno jest zastosować wartość wypracowaną tylko w jednym projekcie, ponieważ nikt więcej nie zrozumiałby, co robisz i dlaczego. 3.2.2.P3 Historia Początków teorii wartości wypracowanej należy szukać w XIX w. gdy ówcześni kierownicy próbowali zoptymalizować wykorzystanie zarówno linii produkcyjnych, jak i powierzchni magazynowych swoich fabryk. Działania te były możliwe jedynie przy zastosowaniu jakiegoś precyzyjnego miernika. Wartość wypracowana była dobrym sposobem na polepszenie precyzji pomiarów. W latach 60-tych XX wieku Departament Obrony USA nakazał stosowania wartości wypracowanej w projektach powiązanych z obronnością. Jeśli rząd zleca realizację projektu wartego setki milionów lub miliardów dolarów, chce precyzyjnej informacji o postępach prac, a nie komunikatów w rodzaju: „wygląda, że jesteśmy zgodnie z planem”. Obliczenia wartości wypracowanej obrazują, gdzie dokładnie projekt się znajduje, w stosunku do tego gdzie być powinien. Jeśli trendy wskazują, że projekt mógłby przekroczyć budżet lub termin, stosując wartość wypracowaną, będziemy o tym wcześniej ostrzeżeni. Niestety, wielu ludzi wierzy, że standardy zaprojektowane przez Departament Obrony są zdecydowanie nieporęczne. Ich stosowanie wnosi znikomą wartość dodaną. To, co powinno być wartościowym narzędziem zarządzania projektem, stało się postrzegane jako obciążenie projektu. Ta opinia o wartości wypracowanej jako o 201 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
obciążeniu może być jednym z powodów tego, że nigdy metoda ta nie odniosła sukcesu w prywatnym biznesie. 3.2.2.P4 Podstawowe pojęcia wartości wypracowanej Wartość wypracowana jest sposobem pomiaru postępu prac. Wartość projektu budowana jest jedynie poprzez wykonywanie zadań. Z perspektywy klienta, wartość biznesowa jest osiągnięta, gdy projekt jest wykonany w całości. Jeśli projekt zostanie zatrzymany w momencie, gdy zrealizowano 90 % zadań, wartość biznesowa może wynosić zero. Jednakże, wartość wypracowana patrzy na to inaczej wartość projektu jest naliczana narastająco, kiedy projekt jest wykonywany. Gdy zrealizowane jest 50% zadań, możesz powiedzieć, że 50% wartości wypracowanej projektu zostało zrealizowane. Ogólną ideą wartości wypracowanej jest porównanie tego, gdzie rzeczywiście jesteś w stosunku do tego, gdzie planowałeś być. Powiedzmy, że pracujesz obecnie nad czynnościami 49, 87, 88, 100 i 108 z harmonogramu, i że wszystkie czynności przed nimi zostały wykonane. Wartość wypracowana pozwala zidentyfikować zadania, które do tej pory zostały zrealizowane w projekcie. Następnie możesz sprawdzić, które powinny być wykonane do tej pory. Porównując obie wielkości masz precyzyjną informację, czy projekt jest realizowany zgodnie z harmonogramem, jest opóźniony czy też prace przyspieszyły. Licencja: 1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Poprzez porównanie rzeczywistych wydatków z zaplanowanymi analogicznie możesz sprawdzić, czy realizujesz budżet, czy go przekraczasz. Teraz przez zestawienie obu wyników analiz dotyczących harmonogramu i budżetu możesz uzyskać wiele cennych informacji. Możesz wydawać budżet szybciej niż przewidywałeś, ale co, jeśli powodem jest to, że prace również przyspieszyły? Np., możesz wydawać więcej, ponieważ zespół może wykonywać więcej pracy niż zaplanowano. Nie jest to oznaką problemu. Podobnie, jeśli projekt jest opóźniony, ale również wydałeś mniej, nie od razu jest to problem. Być może, nie jesteś w stanie przydzielać zadań zespołowi tak szybko jak zaplanowałeś. Projekt jest opóźniony w stosunku do harmonogramu, w równym stopniu, jak współczynnik wydatków. Jeśli jest ustalona data końcowa projektu, może to stanowić problem. Ale jeśli jest ona elastyczna, o ile trzymasz się budżetu, także nie ma powodu do obaw. Wartość wypracowana daje informacje, by podejmować właściwe decyzje. W literaturze prezentuje się różnie sposób obliczenia wartości wypracowanej. Głównie jest to kombinacja trzech rodzajów wielości: Są to:
Wartość wypracowana, Rzeczywisty koszt Planowana wartość. Spójrzmy na każdą nich bardziej szczegółowo.
202 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.2.P5 Wartość wypracowana (EV) Wartość wypracowana jest obliczana poprzez dodawanie zapisanych w budżecie kosztów każdej czynności, która została wykonana. (Pamiętaj, to nie jest rzeczywisty koszt czynności, ale koszt zapisany w budżecie.) Spójrz na poniższy przykład: Dzisiejsza Data: 31 Marca Wykonana czynność
A
B
C
D
Data zakończenia
10 Marca
15 Marca
31 Marca
5 Kwietnia
Koszty zapisane w budżecie
20
10
15
5
Rzeczywisty koszt
20
5
20
10
Powiedzmy, że wykonałeś czynności A, B, C i D. Czy możesz o09dgadnąć prosty wzór na znalezienie wartości wypracowanej? To jest (20 + 10 + 15 + 5) razem - 50. Musisz ustalić jak liczyć czynności, jeśli były one w trakcie wykonywania. Jedna opcja to nie wliczać jej (zero % wartości) jeśli jest w trakcie realizacji. W momencie zakończenia, przyjąć, że jest warta 100% wyceny budżetowej. Innymi słowy, gdy czynność B rozpoczyna się, EV wynosi zero. Gdy czynność B kończy się, EV wynosi 10. Inną opcją jest ustalenie zrealizowanej, częściowej wartości. Na przykład, gdy czynność B rozpoczyna się, EV wynosi zero. Gdy czynność jest w toku, możesz wliczyć 50% wartości, - EV 5. Gdy czynność B kończy się, dajesz jej pełne EV 10. EV jest podstawową miarą tego, jak dużą wartość projekt uzyskał do tej pory. Samoistnie, nie powie ona zbyt wiele. Tak więc, używasz jej w połączeniu z innymi obliczeniami, aby określić status projektu. 3.2.2.P6 Rzeczywisty koszt (AC) Aby obliczy tą liczbę, dodaj rzeczywisty koszt całej pracy, która została wykonana do tej pory w projekcie. To mogłoby obejmować koszty pracy wewnętrznej i zewnętrznej. Jeśli posiadasz zautomatyzowany system finansowy, nie jest to zbyt trudnym zadaniem. Jeśli nie możesz zdobyć wszystkich kosztów automatycznie, może to być bardzo czasochłonne. Jeśli Twój projekt składa się tylko z pracy ludzi, wówczas koszty i pracochłonność będą porównywalne. Spójrzmy ponownie na nasz przykład. Dzisiejsza Data: 31 Marca Wykonana Czynność
A
B
C
D
Data zakończenia
10 Marca
15 Marca
31 Marca
5 Kwietnia
Koszty Planowane w Budżecie
20
10
15
5
Rzeczywisty Koszt
20
5
20
10
203 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Rzeczywisty koszt czynności od A do D wynosi (20 + 5 + 20 + 10) razem 55. Od razu można zauważyć, że rzeczywiste koszty wykonanej pracy są większe, niż koszty zaplanowane w budżecie. To może zwiastować problem. Ponownie, jeśli czynność jest w toku, mógłbyś użyć tych samych opcji, które były omówione przy EV, aby określić, czy objąć rzeczywisty koszt, czy pewien procentowy przydział (od 0 do 100%). 3.2.2.P7 Planowana wartość (PV) To jest suma planowanych w budżecie kosztorysów dla całej pracy, która była zaplanowana, że będzie wykonana do dzisiaj (lub do jakiejkolwiek określonej daty). Dzisiejsza Data: 31 Marca Wykonana Czynność
A
B
C
D
Data zakończenia
10 Marca
15 Marca
31 Marca
5 Kwietnia
Koszty Planowane w Budżecie
20
10
15
5
Rzeczywisty Koszt
20
5
20
10
Teraz masz trochę więcej informacji. Ponieważ dzisiejszą datą jest 31marca, planowana wartość wynosi A + B + C (20 + 10 + 15) - 45. Nie policzyłeś czynności D, ponieważ jej wykonanie nie było zaplanowane do 31 marca. Teraz złóżmy razem te wielkości. Dzisiejsza Data: 31 Marca Wykonana Czynność
A
B
C
D
Pozostała Praca
Data zakończenia
10 Marca
15 Marca
31 Marca
5 Kwietnia
31 Lipca
10
15
5
5
20
10
Koszty Planowane 20 w Budżecie Rzeczywisty Koszt
20
500
?
3.2.2.P8 Odchylenie harmonogramu (SV) Odchylenie harmonogramu (SV) mówi, czy realizujesz projekt z wyprzedzeniem, lub czy projekt jest opóźniony. SV to EV – PV. W naszym przykładzie powyżej, EV wynosi 50 (20 + 10 + 15 + 5) i PV wynosi 45 (20 + 10 + 15). Zauważ, że różnicą jest czynność D. Ponieważ praca w tej czynności została wykonana, jest ona wliczona do EV. Ponieważ jej wykonanie nie było zaplanowane do 31 marca, nie jest ona wliczona do PV Odchylenie harmonogramu wynosi 5 (50 – 45). Jeśli wynik jest dodatni, to znaczy, że wykonałeś więcej pracy niż było początkowo zaplanowane. Prawdopodobnie wyprzedzasz plany. Podobnie, jeśli SV jest ujemne, projekt jest opóźniony w stosunku do harmonogramu.
204 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.2.P9 Odchylenie kosztu (CV) Odchylenie kosztu obrazuje obecny stan finansów projektu w porównaniu do planowanego budżetu. CV wyliczona jako EV – AC. Jeśli odchylenie kosztu jest dodatnia, to znaczy, że koszt zaplanowany w budżecie na wykonanie pracy był większy niż to, co rzeczywiście było wydane. Jeśli CV jest ujemne, może w tym momencie przekraczasz budżet. W naszym przykładzie CV jest ujemne. EV wynosi 50. AC wynosi 55. Zatem, odchylenie kosztu wynosi –5 (EV 50 – AC 55), co oznacza, że przekroczyłeś budżet. 3.2.2.P10 Wskaźnik wykonania harmonogramu (SPI) Współczynnik obliczamy przez podzielenie EV / PV. Jest to stosunek pomiędzy zaplanowanym w budżecie kosztem pracy oraz kosztem pracy, która była zaplanowana, aby była wykonana do dnia dzisiejszego. To daje współczynnik realizacji harmonogramu. Jeśli wynik jest większy niż 1,0, projekt wyprzedza pierwotny plan. W przykładzie powyżej, SPI jest równe (50 / 45) czyli 1,11. To oznacza, że Twój zespół wykonał w przybliżeniu 11% więcej pracy, niż to co było zaplanowane. Jeśli trend będzie trwał nadal, skończysz zużywając do wykonania projektu 11% czasu mniej od tego, który był zaplanowany. 3.2.2.P11 Wskaźnik wykorzystania budżetu (CPI) To jest stosunek EV / AC. Pokazuje relację pomiędzy wartością wypracowaną i rzeczywistym kosztem pracy, która była wykonana. Jeśli wynik jest mniejsze niż 1,0, projekt przekracza budżet. W naszym przykładzie CPI wynosi (50 / 55) czyli 0,91. CPI o wielkości 0,91 znaczy, że aby wykonać tą sama pracę na każde 91$ wydatków zaplanowanych w budżecie, Twój projekt wydaje 100$. Jeśli trend będzie trwał nadal, gdy projekt będzie wykonany, skończysz przekraczając budżet. 3.2.2.P12 Prawdopodobny budżet realizacji projektu (BAC) BAC może być wyrażony w godzinach lub pieniądzach. Jest to rzeczywisty koszt (AC) plus planowany w budżecie koszt pozostałej pracy. Jeśli CPI nie jest 1,0, to znaczy, że wydajesz pieniądze niezgodnie z zaplanowanym budżetem. Nie ma powodu by wierzyć, że później będzie inaczej. Dlatego jeśli CPI nie wynosi jeden, BAC obliczymy jako AC + (zaplanowany w budżecie koszt pozostałej pracy / CPI). Jeśli dotychczas przekraczasz budżet o 10 %, pozostała praca, zabierze również 10% więcej i budżet przy zakończeniu projektu byłby również przekroczony o 10%. W naszym przykładzie powyżej, AC wynosi 55 i zaplanowany w budżecie koszt pozostałej pracy wynosi 500. Szacunkowy budżet przy zakończeniu byłby: 55 + (500 / 0,91) w przybliżeniu: 604,5. Ponieważ nasz całkowity budżet wynosi: 550, to pokazuje, że przekroczysz go w przybliżeniu o 10%.
205 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.3 Zarządzanie harmonogramem i budżetem / Techniki korygujące harmonogram 3.2.3.P1 Ludzie, którzy pracują w zespołach projektowych wiedzą, że jest dużo rzeczy, które mogą pójść źle i doprowadzić projekt do przekroczenia jego terminu. Na przykład, pewna praca może być trudniejsza, niż pierwotnie przewidywano. Możesz mieć jakieś zmiany w projekcie, które doprowadzą do konieczności zaangażowania nowych ludzi, aby być na bieżąco. Czasami odkrywasz, że czynności były po prostu niedoszacowane. Wiele razy odkryjesz, że dążysz do przekroczenia terminu zakończenia projektu. Twoim pierwszym obowiązkiem jako kierownika projektu jest podjęcie prób określenia przyczyny. Jeśli szukasz środków naprawczych, bez poznania przyczyny, jesteś podatny na ponowne występowanie sytuacji w przyszłości. Co powinieneś zrobić po tym, jak poznasz przyczynę? Czy powinieneś powiadomić klienta i przesunąć datę końcową projektu? Jeszcze nie. Następnym obowiązkiem kierownika projektu i zespołu projektowego jest podjęcie próby korekty harmonogramu, które przywrócą projekt na właściwą drogę. Jeśli jest to początku długiego projektu - masz wiele możliwości. Jeśli jesteś pod koniec, może być mniej opcji. Następujące techniki mogą być zastosowane w zależności od Twojej sytuacji. Zauważ, że lista ta nie jest w kolejności ważności. W pewnych sytuacjach niektóre techniki mogą działać lepiej, inne gorzej. 3.2.3.P2 Pracuj w godzinach nadliczbowych Ludzie nienawidzą tego. Jeśli pracują więcej godzin, może spadać ich produktywność. Godziny nadliczbowe mogą być najlepszą opcją, pod koniec projektu. W ramach rekompensaty np. będziesz mógł dać każdemu płatny, dodatkowy urlop, by wynagrodzić wysiłek. Gdy jesteś na początku projektu jednak, warto rozważyć inne opcje. 3.2.3.P3 Przydziel zasoby na ścieżkę krytyczną Kierownik projektu musi najpierw zidentyfikować zadania, które znajdują się na ścieżce krytycznej. Przecież w końcu, jeśli projekt dąży do przekroczenia terminu, z definicji to ścieżka krytyczna jest opóźniona. Następnie powinieneś zobaczyć, czy są zasoby, które mogą być przesunięte z innych czynności, aby pomóc w czynnościach na ścieżce krytycznej. To pozwoli na przywrócenie projektu na właściwą drogę, poprzez przyspieszenie czynności ścieżki krytycznej, opóźniając lub wydłużając część pracy, która znajduje się poza ścieżką krytyczną. Bądź jednak ostrożny – opóźnienie części pracy może skończyć się zmianą ścieżki krytycznej. 3.2.3.P4 Zamień zasoby na ścieżce krytycznej Jedną z przyczyn jaką możesz spotkać jest to, że masz jednego lub więcej pracowników, którzy nie są tak wydajne jak zaplanowałeś. Być może, dzieje się to dlatego, że nie 206 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
posiadają oni odpowiednich umiejętności lub nie są tak wydajni w konkretnej dziedzinie, jak w innych obszarach. Sprawdź czy można zamienić ludzi. Zamiana zasobów oznacza, że zwalniasz członka zespołu i wprowadzasz inną osobę, spoza zespołu. (To główna różnica względem techniki wymienionej powyżej). 3.2.3.P5 Sprawdź powtórnie wszystkie zależności Niektóre czynności muszą być wykonane w pewnej sekwencji. Na przykład, jeśli budujesz dom, nie możesz rozpocząć stawiania szkieletu, zanim fundament nie będzie wylany i wysuszony. Sprawdź relacje między zadaniami. Może okazać się, że niektóre zależności między zadaniami zostały określone niewłaściwie i można je zmienić. Może wydawać się, że zadania muszą być wykonywane kolejno, a mogą one w rzeczywistości być zrobione równolegle. Czasami oprogramowanie do planowania przypadkowo dodaje jakieś relacje, jeśli popełnisz (nieświadomie) jakiś błąd. Czasami kierownik projektu celowo ustala jakieś zależności, ale po późniejszym przeglądzie decyduje, że w rzeczywistości dana relacja nie istnieje. Było by sensowne, aby członkowie zespołu przejrzeli także harmonogram, aby zobaczyć, czy znajdą oni jakieś relacje, o których kierownik projektu myśli, że są uzasadnione, ale o których oni wiedzą, że są nieuzasadnione. Zależności między zadaniami powinny być podwójnie sprawdzone. 3.2.3.P6 Sprawdź czynności niezależne od zasobów Są czynności których, czasy trwania są stałe, nie zmieniają się nawet gdy zwiększymy ilość zasobów. Na przykład, szkolenia, czas schnięcia konstrukcji betonowej etc. Każda z takich czynności powinna być przeanalizowana – czy ramy czasowe są prawidłowo zdefiniowane. Być może, są założenia, które mogłyby być zmienione. Na przykład, jeśli przydzielisz trzy dni na dotarcie kontraktu do klienta, być może długość mogłaby być zmniejszona do jednego dnia poprzez zapłacenie więcej za dostawę w ciągu 24 godzin. Jeśli masz dwudniową przerwę na wyschnięcie betonu, być może czas mógłby być skrócony poprzez wypożyczenie wentylatorów wdmuchujących powietrza na beton. 3.2.3.P8 Fast tracking Fast tracking oznacza, że patrzysz na czynności, które są normalnie wykonane według kolejności sekwencyjnej i planujesz je równolegle. Na przykład, przy stawianiu domu szkielet nie może być zbudowany, aż fundament nie będzie suchy. Jednakże, jeśli dom jest wystarczająco duży, możesz przyspieszyć poprzez rozpoczęcie wznoszenia szkieletu po stronie domu, gdzie fundament był wylany jako pierwszy. Fundament stwardnieje tam najpierw i można wznosić ramy z tej strony, podczas gdy w innych miejscach fundament nadal by wysychał. Innym sposobem, w którym mógłbyś przyspieszyć, byłoby rozpoczęcie budowania ścian na ziemi, podczas gdy fundament wysychałby tak, aby ściany mogłyby być wznoszone szybciej, gdy fundament wyschnie. Fast tracking zawsze pociąga za sobą ryzyko zwiększenia kosztów oraz spadku jakości. Dobrą praktyką opartą na doświadczeniu jest to, że czynności ustawione w sekwencji – A musi się zakończyć by rozpocząć B robione są na „zakładkę”. Gdy A jest w dwóch trzecich rozpoczynamy B. 207 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.3.P9 ―Zero tolerancji‖ zmiany zakresu Wiele projektów dąży do przekroczenia terminu, ponieważ wykonują więcej pracy, niż było początkowo zaplanowane. Jest to prawdopodobnie skutek słabego zarządzania zmianą zakresu. Jednakże, jeśli jesteś zagrożony niedotrzymaniem terminu, kierownik projektu musi pracować z klientem i członkami zespołu nad tym, aby zapewnić, że bez przejścia przez stosowane procedury zarządzania zmiany zakresu, żadna nieplanowana praca nie będzie wykonywana – nawet jeśli jest to tylko jedna godzina. Cała energia powinna pójść na wykonanie pracy, która została uzgodniona i cała dodatkowa praca musi być uznawana za niepożądaną. 3.2.3.P10 Popraw procesy Gdy szukasz przyczyny opóźnień projektu, możesz odkryć, że niektóre z wewnętrznych procesów pracy mogłyby być poprawione. Kierownik projektu powinien zabiegać o informacje zwrotne od członków zespołu i szukać sposobów, które leżą w granicach jego uprawnień, aby usprawnić działanie procesów. Na przykład, być może organizujesz codzienne spotkania zespołu, które nie wnoszą wartości i mogą być zredukowane do jednego w tygodniu. Możesz również odkryć, że występują wąskie gardła z zatwierdzaniem przedmiotów dostawy. Jeśli odkryjesz, że występują opóźnienia spowodowane przez zewnętrzne procesy, spróbuj negocjować zmiany w tych procesach – przynajmniej tymczasowo. Na przykład, możesz odkryć, że czynności są opóźniane, ponieważ ludzie muszą przygotować się do oceny rocznej. Jest to bez wątpienia ważne, być może jednak moment oceny może być zmieniony, aby pozwolić na wykonanie zgodnie z harmonogramem krytycznych czynności projektu. 3.2.3.P11 Odbuduj poczucie obowiązku w zespole projektowym Czasami terminy są niedotrzymywanie tak często i powszechnie, że zespół już nie czuje się zobowiązany do trzymania się harmonogramu i budżetu. Może to się zdarzyć, jeśli jedni członkowie zespołu konsekwentnie nie dotrzymują terminów bez konsekwencji. Inni zastanawiają się, dlaczego tylko oni muszą ciężko pracować, aby wyrobić się w terminach. Gdy to się stanie, kierownik projektu powinien porozumieć się z członkami zespołu, aby zmotywować ich do wykonania przydzielonej pracy zgodnie z harmonogramem. Kierownik projektu powinien poprosić każdego członka zespołu o osobiste zobowiązanie się do dołożenia staranności, aby zrealizować budżet i harmonogram. 3.2.3.P12 Pracuj nad morale Zespół będzie pracował ciężej i wykonywał obowiązki lepiej, jeśli nie spędza czasu na narzekania i uchylanie się od pracy. Kierownik projektu powinien odbudować poczucie zespołowości i zintegrować zespół. 3.2.3.P13 Zmniejsz zakres pracy lub zmień datę zakończenia projektu Ostateczna opcją jest negocjowanie ze sponsorem zmniejszenia zakresu. Jeśli pozostała praca jest w całości istotna dla rozwiązania, taka dyskusja jest ostatecznością. 208 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Można próbować wykonać projekt w ustalonym czasie, ale z mniejszą niż pierwotna funkcjonalnością. Następnie pozostałą pracę wykonać jako projekt uzupełniający. Inną alternatywą jest w ostateczności, wnioskowanie o przesunięcie terminu. Omawiane warianty są ostatecznością. Powinieneś najpierw spróbować innych opcji, aby by projekt wrócił na właściwą drogę. Powinieneś uciekać się do zmniejszenia zakresu lub prośby o więcej czasu, tylko gdy zawiodą wszystkie inne narzędzia i techniki. 3.2.3.P14 Sprawdź nieobowiązkowe uzależnienia Gdy nakreślisz powiązanie pomiędzy wszystkimi czynnościami, zauważysz, że niektóre z czynności mają mocne relacje, inne słabe. W wielu przypadkach jedna czynność musi podążać za inną. Jednakże, w wielu przypadkach odkryjesz, że pewne czynności muszą być zrobione w danym okresie i że jest tylko kilka czynności, które być mocno powiązane. Pierwszy przypadek oznaczany jest jako obowiązkowa zależność, a drugi przypadek jest nieobowiązkową zależnością. Ważne jest, aby znać różnicę. Może uda się „rozpiąć” relacje i niektóre prace wykonać wcześniej?
209 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.2.4 Zarządzanie harmonogramem i budżetem / Techniki korygujące budżet 3.2.4.P1 Gdy projekt jest uruchamiany, sponsor i klient zgadzają się zapłacić za przedmioty dostawy jakąś kwotę. Jeśli się ona zmieni – może okazać się, że cały projekt nie ma już sensu z punktu widzenia biznesu. Zarządzanie budżetem znacznie różni się w poszczególnych firmach. W wielu organizacjach budżety projektów zostają ustalone wcześniej i kierownik projektu posiada bardzo niewielką elastyczność, radząc sobie ze zmianami w tych budżetach. Po tym jak budżet zostanie uchwalony, próba zwiększenia go, jeśli praca kosztuje więcej niż przewidywano, może zająć dużo czasu. W wielu organizacjach, budżet jest bez znaczenia dla kierownika projektu. Te organizacje zazwyczaj stosują do projektów wewnętrzne zasoby i nie posiadają procesu rozliczeniowego do zarządzania kosztami projektów. Kierownicy projektów tworząc harmonogram, próbują zmieścić się w zaplanowanych ramach czasowych. Nie mają za to uprawnień, aby szacować lub zarządzać kosztami projektów. Jeśli regularnie monitorujesz koszty, powinieneś móc łatwo stwierdzić, czy projekt dąży do przekroczenia budżetu. Ten proces jest w pewnym stopniu trudniejszy niż zarządzanie harmonogramem. Może być wiele powodów, dla których informacje finansowe nie są tak dobre lub tak dokładne. Przy planowaniu wiesz od razu, czy nie dotrzymasz daty końcowej. Przy budżecie, nie zawsze możesz to wiedzieć. Jest kilka powodów, przez które zarządzanie budżetem jest bardziej złożone. 1. Po pierwsze, rzadko wydajesz pieniądze w stałym tempie. Tak więc, musisz zrozumieć, ile spodziewałeś się wydać w czasie jednego okresu, jak również ile rzeczywiście wydałeś. W większości firm informacje finansowe nadchodzą z opóźnieniem. Na przykład, mógłbyś nie znać finansowego statusu Twojego projektu w bieżącym miesiącu, aż do upłynięcia znacznej części następnego miesiąca, gdy zostaną opublikowane raporty finansowe. 2. Czas księgowania jest następnym problemem. Musisz wiedzieć, kiedy Twoja firma uznaje wydatki w Twoim systemie finansowym. Mógłbyś uznać wydatek, gdy otrzymasz fakturę, lub być może nie uznać, aż nie zapłacisz tej faktury, co może być dokonane znacznie później. Jeśli Twoja firma stosuje wewnętrzny system zamówień, Twój projekt może w rzeczywistości obciążony gdy wprowadzane jest zamówienie, nawet jeśli rzeczywista faktura nie jest zapłacona przez kolejne tygodnie. W zależności od tych i innych warunków, Twój budżet może być obciążany za wcześnie i być raportowany jako zagrożony, mimo, że w rzeczywistości tak nie jest. 3. Innym potencjalnym problemem z budżetem jest to, że obciążenia mogą zostać dokonane błędnie, z jednego projektu do innego. Jedną z pierwszych czynności kierownika projektu, gdy otrzyma on najnowsze raporty budżetowe, jest potwierdzenie, że szczegóły są poprawne. Wymaga to od niego (lub jego przedstawiciela), aby przejrzał każdą pozycję na liście. W zależności od zasad finansowych w Twojej organizacji, może być wiele możliwości takich pomyłek. Mógłbyś mieć wspaniałe oprogramowanie księgowe, ale jeśli ktoś wprowadzi
210 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
niepoprawny kod projektu, możesz zostać obciążony wydatkami z projektu kogoś innego. Takie porządkowanie nie jest zwykle bardzo pracochłonne – jeśli wykonujesz je co miesiąc. W większości organizacji, jeśli kierownik projektu znajdzie błąd, odpowiednia poprawka zostanie wykonana. Kierownik projektu musi wówczas upewnić się, że w następnym miesiącu zaksięgowano korektę. Oczywiście, występują również przypadki, gdy Twoje wydatki mogą obciążyć kogoś innego. Tak, więc jeśli wiesz, że brakuje Ci pewnych kosztów, zgłoś to do personelu księgowego, aby je wyśledzić. Jeśli po prostu założysz, że wydatek cię ominie, możesz być bardzo zaskoczony później, gdy inny kierownik projektu odkryje, że obciążenia jego projektu są mylne. Jeśli, po upewnieniu się, że wszystkie wydatki związane z projektem są zaksięgowane, odkryjesz, że Twój projekt dąży do przekroczenia budżetu - musisz najpierw znaleźć przyczynę tego zjawiska. Będziesz miał wtedy dużo lepsze pojęcie o tym, jakie rozwiązania są dostępne, aby spróbować powrócić projekt na właściwą drogę. Jest kilka technik, które możesz zastosować, aby spróbować trzymać na wodzy wydatki lub aby powrócić w granice Twojego budżetu. 3.2.4.P2 Pracuj w niepłatnych nadgodzinach Opcje te wykorzystują sytuacje, gdzie Twoi pracownicy nie są opłacani za nadgodziny. Jest to zazwyczaj pierwsze miejsce gdzie sięgnie kierownik projektu. Logika jest taka, że możesz mieć wykonane więcej pracy za ten sam koszt, ponieważ nie musisz płacić Twoim wewnętrznym zasobom za nadgodziny. Jeśli projekt dobiega końca, możesz również być w stanie przydzielić porównywalny czas wolny od pracy, tuż po projekcie. Jednakże, powyższa metoda, nie jest dobra na dłuższy czas. 3.2.4.P3 Zamień zasoby ludzkie Jeśli Twój projekt dążył do przekroczenia terminu, mogłeś zamienić zasoby tak, aby przywrócić Twój projekt do wytycznych z harmonogramu. Zazwyczaj zamieniałeś wtedy niedoświadczone i mniej wydajne zasoby na takie, które są wydajniejsze i bardziej doświadczone. Jednakże, gdy masz do czynienia z sytuacją przekroczenia budżetu, masz odwrotną motywację. Może warto zobaczyć, czy są tańsze zasoby, które mogą być zastosowane do czynności wykonywanych w tej chwili drogo. W rzeczywistości, jeśli ograniczenie kosztów jest ważniejsze niż nieprzekraczalny termin, możesz chcieć, aby praca zajęła więcej czasu, jeśli ostatecznie może ona być pomyślnie wykonana przy zmniejszonym koszcie. Ta technika mogłaby również być zastosowana, aby zamienić zasoby zewnętrzne na etatowych pracowników, jeśli pracownicy kosztowaliby Twój projekt mniej. 3.2.4.P4 Wyeliminuj lub zastąp koszty nie związane z pracą Tak jak powyżej, możliwe jest wykorzystanie mniej kosztownych materiałów czy usług niż te, które pierwotnie zapisano w budżecie. Na przykład, możesz poprosić handlowców, aby zatrzymywali się w sieci tańszych hoteli, zamiast bardziej ekskluzywnych. Możesz zobaczyć, czy członkowie zespołu mogą wykorzystać stary sprzęt, zamiast nowych maszyn. Możesz zastąpić pierwotnie zaplanowane w budżecie formalne zajęcia szkoleniowe tańszym szkoleniem, opartym na e-learningu lub coachingiem zespołu. Może musisz wysłać jedną osobę na delegację, zamiast dwóch, które były wcześniej planowane. 211 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
W każdym z tych przypadków, próbujesz zaspokoić pierwotną potrzebę, ale poprzez użycie mniej kosztownej alternatywy. 3.2.4.P5 Zastosuj ―Zero tolerancji‖ zmiany zakresu Technika ta może być zastosowana, aby pomóc naprawić projekt, który albo przekracza termin, albo budżet. Projekty zaczynają przekraczać budżet, ponieważ wykonują one więcej pracy, niż było początkowo zaplanowane w skutek złego zarządzania zmianą zakresu. Jeśli jesteś zagrożony niedotrzymaniem Twojego budżetu, musisz skontaktować się z klientem i członkami zespołu, aby zaznaczyć, że absolutnie żadna nieplanowana praca nie powinna być wymagana ani wykonywana – nawet jeśli jest to tylko jedna godzina – chyba że wywołane jest formalne zarządzanie zmiany zakresu. Cała energia powinna pójść na obniżanie kosztów i na wykonanie jedynie tej pracy, która została uzgodniona, chyba że otrzymasz dodatkowe środki w ramach formalnej zmiany zakresu. 3.2.4.P6 Zastosuj rezerwę budżetu. (Jeśli ją posiadasz) Jeśli masz szczęście, Twój początkowy budżet obejmował rezerwę szacunkową przeznaczoną do obsługi niepewności oszacowań i ryzyka połączonego z Twoim kosztorysem. Nic niezwykłego nie byłoby w 10% na taką rezerwę. Jest ona z natury oddzielona od budżetu projektu. Jeśli możesz wykonać projekt w granicach Twojego początkowego budżetu, rezerwa powinna cała być zwrócona do firmy. Jeśli odkryjesz, że Twoja sytuacja przekroczenia budżetu spowodowana jest przez czynności, które kosztują więcej niż szacowano, budżet rezerwy może być wykorzystany. Kiedy to robisz, upewnij się, że Twój sponsor i kluczowi interesariusze o tym wiedzą, abyś poradził sobie z ich oczekiwaniami dotyczącymi sposobów finansowania rezerwowego. 3.2.4.P7 Popraw procesy Mogą być przekroczenia kosztów spowodowane przez niewydolne wewnętrzne procesy. Zdobądź informacje zwrotne od członków zespołu i szukaj sposobów, które znajdują się w granicach uprawnień Twojego zespołu, aby usprawnić działanie procesów. Jeśli są implikacje kosztów spowodowane przez procesy zewnętrzne, spróbuj negocjować zmiany w procesach na stałe lub przynajmniej tymczasowo. 3.2.4.P8 Odnów zobowiązania Popracuj z członkami zespołu, aby ocenić pozostałą do wykonania pracę i kosztorysy i uzyskaj zobowiązanie do wykonania pozostałej pracy w granicach budżetu. (Zobacz: część 3.2.3 o odzyskiwaniu zobowiązań) 3.2.4.P9 Ponownie zaoferuj lub renegocjuj zewnętrzne kontrakty We wcześniejszych technikach przyglądałeś się możliwościom wymiany zasobów ludzkich i wyeliminowania lub zamiany pozycji niezwiązanych z pracą. Jednakże, zasoby kupowane na zewnątrz nie muszą być wymieniane lub zamieniane. Może być po prostu możliwe renegocjowanie warunków. Jeśli posiadasz pracę kontraktową, być może, możesz negocjować zmniejszenie opłat. Być może Twój dostawca oprogramowania weźmie mniej pieniędzy za swój produkt. Wszystkie Twoje zewnętrzne koszty powinny 212 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
być ocenione, aby zobaczyć, gdzie mogą być osiągnięte oszczędności. W wielu przypadkach dostawca będzie skłonny pracować z Tobą przy niższych cenach – szczególnie, jeśli inną opcją jest całkowite porzucenie jego produktów lub usług. Jednakże, w pewnych przypadkach dostawca może być skłonny wymienić jedną korzyść na inną. Na przykład, być może zasób kontraktowy zmniejszy swoją stawkę w zamian za dodatkowe godziny pracy. Być może dostawca weźmie mniej pieniędzy w zamian za wcześniejszą zapłatę. Im większa jest wartość Twoich zewnętrznych kontraktów, tym bardziej elastycznie musisz negocjować różne warunki. Jeśli przekroczyłeś budżet, szczególnie w dużym projekcie, wszyscy dostawcy powinni być poddani przeglądowi odnośnie potencjalnych oszczędności kosztów. 3.2.4.P10 Zmniejsz zakres pracy lub poproś o większy budżet Opcją, która jest zwykle zawsze jest dostępna dla obu sytuacji - przekroczenia budżetu i przekroczenia terminu - jest ocena pozostałej pracy i negocjowanie z klientem, aby usunąć część tej pracy z projektu. Jeśli pozostała do wykonania praca jest w całości ważna dla konstruowanego rozwiązania, ta dyskusja nadal mogłaby się w odbyć – jako ostatnia deska ratunku. Można rozważyć opcję, aby wykonać projekt w granicach budżetu ale z mniejszą funkcjonalnością i następnie wykonać, w terminie późniejszym, uzupełniający projekt. Można także wnioskować o dodatkowy budżet i ocenić, czy możesz wykonać pierwotnie zamówioną pracę, jeśli dostaniesz więcej pieniędzy. Nie jest to alternatywa, którą wybiera się, gdy tylko zaczynasz przekraczać budżet. Powinieneś najpierw spróbować innej dostępnej opcji, aby spróbować samodzielnie powrócić do pierwotnego budżetu. Powinieneś uciekać się do zmniejszenia zakresu lub prośby o więcej pieniędzy, tylko gdy zawiodą wszystkie inne narzędzia i techniki. 3.2.4.P11 Utwórz bardziej szczegółowe konta kosztowe Skoro trudno jest zarządzać czynnościami, które posiadają długi czas trwania, może również być trudne zarządzanie budżetem, jeśli finansowanie jest całościowe. W obu przypadkach, problem powstaje, ponieważ masz trudności w zrozumieniu, gdzie się znajdujesz w danym czasie. Jedyną techniką zapewniającą większą kontrolę nad budżetem jest wtedy użycie bardziej szczegółowej analityki kont kosztowych. Na kontach tych przydzielane będą fundusze dla Twojego projektu po to, abyś miał precyzyjniejszą kontrolę. Zamiast posiadania jednego dużego budżetu ze wszystkimi Twoimi kosztami możesz rozdzielić Twój całkowity budżet na jednostki kosztowe niższego poziomu. Na przykład, mógłbyś założyć rachunek kosztów dla każdej fazy Twojego projektu. Mógłbyś również założyć rachunek kosztów dla każdego przedmiotu dostawy. Ponieważ te budżety są teraz przydzielone na niższym poziomie, jesteś w stanie wiedzieć dużo wcześniej, czy masz problemy budżetowe.
213 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3.3 Zarządzanie Harmonogramem i budżetem / Podsumowanie 3.3.P1 Przedmioty dostawy: Poniższe przedmioty dostawy dostępne są w Bibliotekach szablonów TenStep.
Uaktualniony Harmonogram projektu Dziennik Action Item Dziennik Działania Korygującego Dziennik Rozbieżności Szczegółowego Kosztorysu Kosztów Lessons Learned Protokół Zebrania Lista Kontrolna Ukończenia projektu Plan Kickoff Meeting Wniosek o zmianę przydziału Kosztów 3.3.P2 Czynności dodawane do harmonogramu Zauważ, że część ta obejmuje tylko czynności związane z zarządzaniem harmonogramem. Część zarządzania Harmonogramem obejmuje uaktualnianie statusu problemów krytycznych, ryzyka, wniosków zmiany zakresu, itd. Jednakże czynności te będą opisane w krokach związanych z tymi funkcjami zarządzania projektem. Rozmiar Potrzebna Informacja Mały
Małe projekty nie wymagają określonych czynności wokół zarządzania i uaktualniania harmonogramu. Czynność
Pracochłonność Uwagi
1-4 godzin
Tygodniowo. Zawsze przydzielone kierownikowi projektu, chociaż niektóre uaktualnienia mogą również być przydzielone członkom zespołu. Zazwyczaj wykonywane w piątek lub w poniedziałek.
Uaktualnij i potwierdź bieżące wydatki 1-4 godzin w stosunku do budżetu.
Tygodniowo lub miesięcznie, w zależności od dostępności informacji budżetowych. Rzeczywiste wydatki projektu powinny być porównane z szacowanym budżetem, który byłby do tej pory wydany. Jeśli projekt wydaje się dążyć do przekroczenia budżetu,
Uaktualnij harmonogram Średni
214 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
działania korygujące zainicjowane. Czynność
powinny
być
Wysiłek Uwagi
3-6 godzin
Tygodniowo lub dwutygodniowo. Zawsze przydzielone kierownikowi projektu, chociaż niektóre uaktualnienia mogą również być przydzielone członkom zespołu. Może(gą) być osoba(y) przydzielona do wykonania części prac związanej z uaktualnianiem harmonogramu. (Osoba ta czasami jest nazywana administratorem projektu.) Zazwyczaj wykonywane w piątek lub w poniedziałek.
Uaktualnij i potwierdź bieżące 2-4 wydatki w stosunku godzin do budżetu.
Tygodniowo lub miesięcznie, w zależności od dostępności informacji budżetowych. Rzeczywiste wydatki projektu powinny być porównane z szacowanym budżetem, który byłby do tej pory wydany. Jeśli projekt wydaje się dążyć do przekroczenia budżetu, działania korygujące powinny być zainicjowane.
Uaktualnij harmonogram Duży
215 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 4 Zarządzanie problemami krytycznymi
216 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.0 Zarządzanie problemami krytycznymi 4.0.P1 Problem krytyczny to formalnie określony problem, który przeszkadza lub wręcz w uniemożliwia kontynuowanie projektu i nie może być całkowicie rozwiązany przez kierownika projektu lub/i zespół projektowy bez pomocy z zewnątrz. Jeśli pojawia się problem, który kierownik projektu i zespół mogą i są w stanie rozwiązać, to jest to tylko jeden ze zwykłych problemów jaki pojawią się w codziennej pracy i są rozwiązywane na bieżąco. Aby zakwalifikować go jako „problem krytyczny” musi on znacznie utrudniać lub uniemożliwiać kontynuowanie projektu i jednocześnie jego rozwiązanie musi leżeć poza możliwościami (uprawnieniami) kierownika projektu i jego zespołu. Jest to moment w którym należy uruchomić opisywany tu proces zarządzania problemami krytycznymi, uświadomić odpowiednich ludzi co do jego istoty i jak najszybciej starać się rozwiązać problem. Zarządzanie problemami krytycznymi to jeden z fundamentalnych procesów metodyki TenStep. Jest to również umiejętność, którą każdy kierownik projektu musi posiąść w stopniu doskonałym. Wiele projektów będzie musiało radzić sobie z rozwiązywaniem problemów krytycznych. Nie mogą one bowiem (z definicji) zostać zignorowane lub przesunięte na okres późniejszy. Jedyny sposób na sprawną realizację przedsięwzięcia to ich szybkie i sprawne rozwiązywanie. 4.1 Zarządzanie problemami krytycznymi / Proces 4.2 Zarządzanie problemami krytycznymi / Techniki 4.3 Zarządzanie problemami krytycznymi / Podsumowanie
217 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.1 Zarządzanie problemami krytycznymi / Proces 4.1.P1 W niniejszym rozdziale opisane zostały procesy użyte do zarządzania problemami krytycznymi. Procesy te mogą zostać zmodyfikowane odpowiednio do danego projektu, a następnie dołączone do Planu zarządzania projektem. Dokument ten powstaje w procesie 1.0 Definiowanie pracy. Należy pamiętać, że problem krytyczny musi być „formalnie określony”. Oznacza to, że jest on wystarczająco dobrze zrozumiały, aby zostać udokumentowany. Innymi słowy: jeśli nie rozumiesz istoty problemu w taki sposób, aby go dokładnie opisać, nie jesteś w stanie rozwiązać go. Do „formalnego określenia” problemów krytycznych używane są: Formularz zgłoszenia problemu krytycznego oraz Dziennik problemów krytycznych. 4.1.1 Zarządzanie problemami krytycznymi w małych projektach 4.1.2 Zarządzanie problemami krytycznymi w średnich projektach 4.1.3 Zarządzanie problemami krytycznymi w dużych projektach
218 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.1.1 Zarządzanie problemami krytycznymi / Małe projekty 4.1.1.P1 Zazwyczaj nie oczekuje się, że podczas małego projektu pojawi się wiele problemów krytycznych. Nawet jeśli jakieś problemy się pojawiają, zwykle bywają szybko rozwiązywane. W przypadku jednak, gdy pojawi się rzeczywisty problem krytyczny, należy użyć poniższego procesu.
1
2
Rola
Zarządzanie problemami krytycznymi (Małe projekty)
Kierownik projektu, członek zespołu.
Identyfikacja problemu.
Kierownik projektu.
Określenie, czy krytycznym.
Problemy mogą zostać zauważone przez każdego z członków zespołu. Informacja o nich powinna zostać przekazana na piśmie (list, email, itp.) kierownikowi projektu. Nie jest konieczne stosowanie oficjalnego formularza. problem
jest
rzeczywistym
problemem
Kierownik projektu określa, czy problem może zostać rozwiązany w ramach jego możliwości i uprawnień, czy też trzeba go zakwalifikować jako problem krytyczny. 3
Kierownik projektu.
Analizowanie problemu alternatywnych rozwiązań.
krytycznego
i
przygotowanie
Kierownik projektu przygotowuje plan rozwiązania problemu krytycznego. Jeśli to możliwe, identyfikuje alternatywne rozwiązania. W każdym przypadku należy określić wpływ na harmonogram i budżet projektu. 4
5
6
Kierownik projektu, sponsor, interesariu sze.
Uzyskanie zgody na rozwiązanie
Kierownik projektu.
Dodawanie planu działań korygujących do harmonogramu.
Kierownik projektu.
Dokumentowanie problemu krytycznego w Raporcie stanu.
Kierownik projektu przedstawia sponsorowi (i właściwym interesariuszom) odpowiednie analizy wpływu problemu krytycznego na projekt oraz wypracowane alternatywy rozwiązań. Może przedstawić także własną rekomendację. Informacje te są podstawą do ewentualnej dyskusji i podjęcia przez sponsora ostatecznej decyzji o rozwiązaniu.
Kiedy uzgodniono już rozwiązanie, należy dodać właściwe czynności naprawcze do bieżącego harmonogramu. W ten sposób rozwiązanie problemu krytycznego stanie się częścią pracy do wykonania.
Opis problemu krytycznego, jego bieżący stan oraz wybrane rozwiązanie
219 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
są opisywane w kolejnym Raporcie stanu projektu.
4.1.2 Zarządzanie problemami krytycznymi / Średnie projekty 4.1.2.P1
1
2
Role
Zarządzanie problemami krytycznymi (Średnie projekty)
Kierownik projektu.
Określanie problemu.
Kierownik projektu.
Określenie, czy problem jest rzeczywistym problemem krytycznym.
Kierownik projektu uzyskuje od interesariuszy (włączając w to członków zespołu projektowego, klientów, sponsorów, itp.) wszelkie informacje na temat potencjalnych problemów krytycznych. Problemy te powinny zostać udokumentowane na piśmie i przekazane do kierownika projektu przy użyciu Formularza zgłoszenia problemu krytycznego (opcjonalnie) lub pocztą elektroniczną.
Kierownik projektu określa, czy problem może zostać rozwiązany w ramach jego możliwości i uprawnień, czy też trzeba go zakwalifikować jako problem krytyczny. 3
Kierownik projektu.
Wpisanie problemu krytycznego do Dziennika problemów krytycznych. Jeśli jest to problem krytyczny, kierownik projektu wpisuje go do Dziennika problemów krytycznych w celu śledzenia przebiegu jego rozwiązania.
4
Kierownik projektu, sponsor.
Określanie, kto musi zostać zaangażowany w rozwiązywanie problemu. Kierownik projektu określa kogo należy zaangażować w rozwiązywanie problemu krytycznego. Zwykle zaangażowany będzie sponsor. Może się jednak zdarzyć, że nie będzie on miał właściwej wiedzy na temat rozwiązania. Rozwiązanie może wymagać ekspertyzy technicznej czy prawnej. Problem może być związany z konkretnym kontraktem i będzie wymagał pomocy ze strony właściwego działu firmy. Ważne jest, aby być od początku świadomym, kogo należy zaangażować w ostateczne rozwiązanie problemu krytycznego. Dopiero w gronie odpowiednich osób powinny zostać wypracowane scenariusze możliwych rozwiązań.
5
Kierownik projektu,
Przyporządkowywanie członków zespołu do analizy alternatyw. Kierownik
projektu
przyporządkowuje
220 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
problem
krytyczny
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6
7
8
9
10
członek zespołu.
członkowi zespołu projektowego (lub sobie) w celu przeprowadzenia analizy wypracowanych wcześniej rozwiązań. Członek zespołu sprawdza poszczególne opcje (scenariusze) rozwiązań i dla każdej z opcji określa wpływ na projekt w odniesieniu do budżetu, harmonogramu i zakresu.
Kierownik projektu, sponsor, interesariusz.
Uzyskanie zgody na rozwiązanie
Kierownik projektu.
Dokumentowanie rozwiązania.
Kierownik projektu.
Dodawanie planu działań korygujących do harmonogramu.
Kierownik projektu.
Uaktualnianie Definicji Projektu
Kierownik projektu.
Komunikowanie przy użyciu Raportu o stanie .
Kierownik projektu przedstawia sponsorowi (i właściwym interesariuszom) odpowiednie analizy wpływu problemu krytycznego na projekt oraz wypracowane alternatywy rozwiązań. Może przedstawić także własną rekomendację. Informacje te są podstawą do ewentualnej dyskusji i podjęcia przez sponsora ostatecznej decyzji o rozwiązaniu.
Kierownik projektu dokumentuje wybrane rozwiązanie oraz podjęte działania w Dzienniku problemów krytycznych. Jeśli wykorzystano wcześniej Formularz zgłoszenia problemu krytycznego, należy go formalnie zamknąć i dołączyć do dokumentacji.
Kiedy uzgodniono już rozwiązanie, należy dodać właściwe czynności naprawcze do bieżącego harmonogramu. W ten sposób rozwiązanie problemu krytycznego stanie się częścią pracy do wykonania.
Jeśli rozwiązanie problemu krytycznego powoduje zmiany w budżecie, pracochłonności lub czasie trwania projektu, należy uaktualnić bieżącą Definicję Projektu.
Kierownik projektu informuje członków zespołu projektowego i innych interesariuszy o stanie i sposobie rozwiązania problemu krytycznego stosując do tego metody określone w Planie komunikacji (włączając w to Raport stanu projektu).
221 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.1.3 Zarządzanie problemami krytycznymi / Duże projekty 4.1.3.P1 Duże projekty
1
Role
Zarządzanie problemami krytycznymi (Duże projekty)
Kierownik projektu.
Określanie problemu i dokumentowanie go przy użyciu Formularza zgłoszenia problemu krytycznego. Kierownik projektu uzyskuje od interesariuszy (włączając w to członków zespołu projektowego, klientów, sponsorów, itp.) wszelkie informacje na temat potencjalnych problemów krytycznych. Problemy krytyczne mogą zostać zgłoszone w formie ustnej lub pisemnej ale muszą zostać oficjalnie udokumentowane przy użyciu Formularza zgłoszenia problemu krytycznego.
2
Kierownik projektu.
Określenie, czy problem jest rzeczywistym problemem krytycznym. Kierownik projektu określa, czy problem może zostać rozwiązany w ramach jego możliwości i uprawnień, czy też trzeba go zakwalifikować jako problem krytyczny.
3
Kierownik projektu.
Wpisanie problemu krytycznego do Dziennika problemów krytycznych. Jeśli jest to problem krytyczny, kierownik projektu wpisuje go do Dziennika problemów krytycznych w celu śledzenia przebiegu jego rozwiązania.
4
Kierownik projektu, sponsor.
Określanie, kto musi zostać zaangażowany w rozwiązywanie problemu. Kierownik projektu określa kogo należy zaangażować w rozwiązywanie problemu krytycznego. Zwykle zaangażowany będzie sponsor. Może się jednak zdarzyć, że nie będzie on miał właściwej wiedzy na temat rozwiązania. Rozwiązanie może wymagać ekspertyzy technicznej czy prawnej. Problem może być związany z konkretnym kontraktem i będzie wymagał pomocy ze strony właściwego działu firmy. Ważne jest, aby być od początku świadomym, kogo należy zaangażować w ostateczne rozwiązanie problemu krytycznego. Dopiero w gronie odpowiednich osób powinny zostać wypracowane scenariusze możliwych rozwiązań.
5
Kierownik projektu,
Przyporządkowywanie członków zespołu do analizy alternatyw. Kierownik
projektu
przyporządkowuje
222 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
problem
krytyczny
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
członek zespołu.
członkowi zespołu projektowego (lub sobie) w celu przeprowadzenia analizy wypracowanych wcześniej rozwiązań. Członek zespołu sprawdza poszczególne opcje (scenariusze) rozwiązań i dla każdej z opcji określa wpływ na projekt w odniesieniu do budżetu, harmonogramu i zakresu. Wyniki jego pracy zapisywane są w Formularzu zgłoszenia problemu krytycznego.
6
7
8
9
10
11
Kierownik projektu, sponsor, interesariusz.
Uzyskanie zgody na rozwiązanie
Kierownik projektu.
Zamykanie Dziennika problemów krytycznych.
Kierownik projektu.
Dokumentowanie rozwiązania.
Kierownik projektu.
Dodawanie planu działań korygujących do harmonogramu.
Kierownik projektu.
Uaktualnianie Definicji Projektu
Kierownik projektu.
Komunikowanie przy użyciu Raportu o stanie .
Kierownik projektu przedstawia sponsorowi (i właściwym interesariuszom) odpowiednie analizy wpływu problemu krytycznego na projekt oraz wypracowane alternatywy rozwiązań. Może przedstawić także własną rekomendację. Informacje te są podstawą do ewentualnej dyskusji i podjęcia przez sponsora ostatecznej decyzji o rozwiązaniu.
Kierownik projektu dokumentuje rozwiązanie krytycznego w Dzienniku problemów krytycznych.
problemu
Kierownik projektu dokumentuje wybrane rozwiązanie oraz podjęte działania w Formularzu zgłoszenia problemu krytycznego. Dokument ten należy następnie formalnie zamknąć i dołączyć do dokumentacji.
Kiedy uzgodniono już rozwiązanie, należy dodać właściwe czynności naprawcze do bieżącego harmonogramu. W ten sposób rozwiązanie problemu krytycznego stanie się częścią pracy do wykonania.
Jeśli rozwiązanie problemu krytycznego powoduje zmiany w budżecie, pracochłonności lub czasie trwania projektu, należy uaktualnić bieżącą Definicję Projektu.
Kierownik projektu informuje członków zespołu projektowego i innych interesariuszy o stanie i sposobie rozwiązania problemu krytycznego stosując do tego metody określone w Planie komunikacji (włączając w to Raport stanu projektu).
223 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.2 Zarządzanie problemami krytycznymi / Techniki 4.2.P1 Techniki rozwiązywania problemów. Ludzie tworzą i rozwiązują problemy od tysięcy lat. W ostatnich kilku dekadach rozwinięto formalne techniki pomocne przy rozwiązywaniu problemów. Techniki te mogą być także bardzo pomocne przy rozwiązywaniu problemów krytycznych w projektach. Spośród wielu istniejących poniżej przedstawiono wybrane trzy:
Zarządzanie problemami krytycznymi / Analiza przyczynowo-skutkowa. Zarządzanie problemami krytycznymi / Analiza przyczyn podstawowych (RCA). Zarządzanie problemami krytycznymi / Analiza Pareto. 4.2.P2 Rozwiązywanie problemów krytycznych najszybciej jak to możliwe. Definicja problemu krytycznego mówi, że wpływa on negatywnie przebieg projektu i nie może być rozwiązany przez kierownika i zespół projektowy w ramach ich uprawnień. Wynika z tego, że problemem krytycznym należy się zająć niezwłocznie. Jeśli problem został faktycznie zakwalifikowany jako problem krytyczny, kierownik projektu musi przyjąć na siebie odpowiedzialność za jego rozwiązanie. W związku z tym warto, aby uwzględnił on w swoim harmonogramie czynności związane ze śledzeniem pacy nad rozwiązywaniem obsługiwanych problemów. Jeśli nie ma konieczności szybkiego rozwiązania problemu, lub jeśli problem pojawia się co jakiś czas, należy ponownie sprawdzić, czy jest to rzeczywiście problem krytyczny. Może się okazać, że jest to potencjalny problem (Ryzyko) lub trudne zadanie (Action Item), które może zostać rozwiązane później, w innym, właściwym sobie, trybie. Problemy krytyczne z natury muszą być rozwiązywane szybko. 4.2.P3 Należy dociekać przyczyn podstawowych a nie tylko symptomów. Kiedy pojawia się problem krytyczny, powinien być rozwiązany tak szybko, jak jest to możliwe. Jednak należy dociec podstawowych przyczyn problemu a nie tylko reagować na symptomy. Rozwiązanie przyczyn podstawowych problemu spowoduje, że nie pojawi się on ponownie podczas projektu. Przyczynę podstawową można znaleźć zadając serię pytań: “dlaczego?”. Dlaczego powstał problem krytyczny? Kiedy odpowie się na to pytanie należy ponownie zadawać pytanie: „dlaczego?”. Jeśli nie można podać odpowiedzi na pytanie, prawdopodobnie jest się blisko przyczyny podstawowej. Dalsze informacje - patrz: 4.2.2 Zarządzanie problemami krytycznymi / Analiza przyczyn podstawowych (RCA). 4.2.P4 Czasami trzeba wybrać którąś ze złych alternatyw. Po przejrzeniu procesów i technik do zarządzania problemami krytycznymi można odnieść wrażenie, że uda się rozwiązać każdy problem, jeśli zna się właściwą technikę. W rzeczywistości jednak można napotkać problemy krytyczne, co do których nie ma dobrych, jasnych rozwiązań. W niektórych przypadkach może być trudno określić jakiekolwiek dobre opcje rozwiązań. W innych przypadkach pojawiające się problemy 224 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
krytyczne trudno rozwiązać nie ze względu na brak opcji, lecz ze względu na trudności w zdobyciu akceptacji dla rozwiązań spośród wielu alternatyw. Można również znaleźć się w sytuacji, gdy ma się kilka opcji, które nie są optymalne, a ostatecznym rozwiązaniem może być to, które jest najmniej ofensywne. Przykładem tego dylematu jest problem krytyczny związany z polityką wewnętrzną w organizacji. Zazwyczaj, kiedy problem zaczyna łączyć się z polityką wewnętrzną, trudno będzie znaleźć idealne rozwiązanie. Istnieje tu bowiem więcej czynników podejmowania decyzji, niż tylko zwykłe spokojne badanie faktów. Kiedy problem staje się polityczny, zatwierdzone rozwiązanie może okazać się gorsze niż optymalne dla danego zespołu projektowego. Jednakże w tej sytuacji rozwiązanie, które nie jest perfekcyjne, może być lepsze niż impas lub perspektywa zaakceptowania jeszcze gorszej alternatywy. W takich sytuacjach należy sprawić, aby osoby podejmujące decyzję o rozwiązaniu zrozumiały, że przesuwanie decyzji nie sprawia, że wynik będzie lepszy do przyjęcia. Kierownik projektu powinien starać się zdobyć rozwiązanie tak szybko, jak to możliwe, aby projekt mógł być kontynuowany. Jeśli problem krytyczny jest problemem politycznym, kierownik projektu będzie musiał polegać na sponsorze oraz innych interesariuszach spośród decydentów – ich zrozumienie i pomoc może okazać się niezbędna. 4.2.P5 Tworzenie wytycznych: kiedy członkowie zespołu mogą podejmować decyzje? Przy ciągłym podkreśleniu wagi zgłaszania problemów krytycznych oraz potencjalnych zmian zakresu do kierownika projektu, członkowie zespołu mogą odnieść wrażenie, że nie są w stanie podejmować żadnych decyzji. Nie należy powodować takich odczuć. Będąc kierownikiem projektu, należy zachęcać ludzi do przyjmowania obowiązków i podejmowania decyzji, kiedy jest to konieczne. Pomaga to w zachowaniu płynności w pracy zespołu i pozwala poszczególnym osobom na zdobywanie doświadczenia. Kierownik projektu musi zachęcać członków zespołu do samodzielnego zajmowania się codziennymi problemami. Powinni oni zgłaszać się do niego tylko w wyjątkowych przypadkach. Tak samo kierownik projektu powinien rozwiązywać jak najwięcej problemów samodzielnie i prosić sponsora o pomoc tylko przy prawdziwych problemach krytycznych. Członkowie zespołu mogą spróbować zadać sobie poniższe pytania zanim zdecydują, czy potrzebują zewnętrznej pomocy, czy też mogą podjąć decyzję samodzielnie:
Czy problem ma wpływ na pracochłonność, czas lub koszt? Jeśli tak, należy udać się do kierownika projektu.
Czy decyzja będzie wymagała wyjścia poza zakres lub poza wcześniej ustaloną specyfikację? Jeśli tak, należy udać się do kierownika projektu.
Czy decyzja narusza czyjeś interesy lub ma charakter polityczny? Jeśli tak należy udać się do kierownika projektu.
Czy
decyzja będzie powodowała niewypełnienie wcześniej zobowiązań? Jeśli tak, należy udać się do kierownika projektu.
ustalonych
Czy decyzja wystawi projekt na ryzyko w przyszłości? Jeśli tak, należy udać się do kierownika projektu.
225 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jeśli na żadne z powyższych pytań nie odpowiedziano twierdząco, członek zespołu może podjąć decyzję samodzielnie. Mimo, że lista ta jest dość krótka, okazuje się, że większość decyzji wymaganych w codziennej pracy nie spełnia powyższych kryteriów. Pozwala to więc podejmować decyzje na szczeblu zespołu lub poszczególnych jego członków. 4.2.P6 Zrozumienie różnicy pomiędzy Problemami krytycznymi a Action Item. W wielu przypadkach kierownicy projektów nie używają Dziennika problemów krytycznych do identyfikacji i do śledzenia prawdziwych problemów krytycznych. Wiele spraw, które zostały sklasyfikowane jako problemy krytyczne są tak naprawdę ryzykami (potencjalnymi problemami) lub po prostu kwestiami wymagającymi podjęcia jakiegoś działania (Action Item). Action Item to czynności czy zadania, które mogą, ale nie muszą być związane z problemami krytycznymi w projekcie. Ponieważ problemy krytyczne to problemy obszerne, mocno wpływające na projekt - nie powinno ich być zbyt wiele w jednym czasie. Jeśli w Dzienniku problemów krytycznych znajduje się zbyt wiele pozycji - prawdopodobnie zapisywane są tam, niepotrzebnie, właśnie Action Items. Więcej informacji na temat Action Items, patrz: 3.2.1 Zarządzanie Planem operacyjnym / Action Item. 4.2.P7 Za identyfikacją problemu powinno iść rozwiązanie. Problemy krytyczne mogą zostać zgłoszone przez członków zespołu, klientów lub innych interesariuszy. Dobrą praktyką jest zachęcanie pracowników do pomocy w identyfikacji rozwiązań problemów krytycznych. Kiedy członek zespołu zidentyfikuje potencjalny problem krytyczny, należy poprosić go o przedstawienie jednego lub więcej możliwych rozwiązań tego problemu. Praktyka ta pozwala członkom zespołu bardziej utożsamiać się z projektem i czuć za niego odpowiedzialność. Pomoże również kierownikowi projektu w szybszym określeniu możliwych kierunków działań. Jeśli członek zespołu zaproponuje jedno lub dwa realne rozwiązania, problem może okazać się możliwy do rozwiązania przez kierownika projektu i nigdy nie osiągnie statusu problemu krytycznego. 4.2.P8 Angażowanie klienta w zarządzanie problemami krytycznymi. Zarządzanie problemami krytycznymi przebiega sprawniej, jeśli cały zespół projektowy już od samego początku działa zgodnie z właściwymi temu procesowi procedurami. Jeśli problemy krytyczne pojawiają się we wczesnej fazie projektu, należy upewnić się, że nie tylko korzysta się z procedur ale też angażuje się klienta projektu w ich rozwiązanie. W związku z tym, że problemy krytyczne stają się bardziej pilne kiedy projekt zbliża się ku końcowi, nie mogą one być pierwszymi, w które zaangażowany jest klient. Odpowiednio wcześniejsze doświadczenie przez klienta pracy nad rozwiązywaniem problemów krytycznych sprawi, że będzie on postrzegał je jako przejściowe przeszkody, na które projekt od czasu do czasu natrafia. A kierownik projektu potrafi zwykle znaleźć szybko stosowne rozwiązanie. Jeśli klient nie był wcześniej zaangażowany w procedury zarządzania problemami krytycznymi, a stanie się tak z konieczności pod koniec projektu, może to spowodować więcej strat niż korzyści. Jego obawy o termin czy jakość i ewentualne gwałtowne reakcje mogą być dużą przeszkodą w rozwiązaniu problemu. 4.2.P9 Dzielenie dużych problemów krytycznych na mniejsze.
226 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jeśli problem krytyczny wygląda na tak duży, że trudno go zrozumieć i rozwiązać w zwykły sposób, należy podzielić go na logiczne mniejsze „podproblemy” krytyczne. W wielu przypadkach rozwiązanie pierwszego w kolejności podproblemu krytycznego będzie generowało rozwiązania dla pozostałych. Jeśli nie, taki podział pozwoli przynajmniej zrozumieć komponenty problemu krytycznego tak, aby można je było rozwiązać pojedynczo. 4.2.P10 Poszukiwanie wspólnych przyczyn. Czasami można zaobserwować pojawienie się wielu różnorodnych problemów krytycznych w krótkim okresie. Należy wtedy sprawdzić, czy nie są one czasem ze sobą powiązane. Jeśli tak, należy rozwiązać ten problem krytyczny, który wydaje się być najbardziej podstawowy, który może być przyczyną pozostałych. Rozwiązanie tego problemu krytycznego może w konsekwencji doprowadzić do rozwiązania kolejnych. Jeśli problemy wyglądają na niezależne, należy próbować rozwiązać najpierw te, które mają najbardziej negatywny wpływ na projekt. 4.2.P11 Dotrzymanie terminów przez zespół i przez klienta. Wielu kierowników projektów spotyka się w swojej codziennej pracy z sytuacjami, gdzie muszą dotrzymać określonych terminów z bardzo niewielką, jeśli nie zerową elastycznością. To często trudne zadanie. Zdarza się także, że sami klienci utrudniają pracę, poprzez nie dotrzymywanie własnych zobowiązań na czas. Bywają niedostępni, kiedy są potrzebni, lub nie akceptują krytycznych przedmiotów dostaw, mimo że oświadczyli, że je zaakceptują. Może to prowadzić do opóźnienia projektu, w przypadku gdy zdarzenia te leżą na ścieżce krytycznej. Z perspektywy zarządzania projektami należy zarządzać ryzykiem, problemami krytycznymi, zakresem oraz komunikacją w sposób proaktywny. W związku z powyższym można podjąć następujące działania:
Zarządzanie
terminami klientów jak ryzykiem. Zakwalifikowanie wydarzeń związanych z angażowaniem klienta jako ryzyk pozwala na zakomunikowanie obaw kierownika projektu i skupienie uwagi na zagrożeniu przez cały czas trwania projektu. Identyfikowane są także dodatkowe czynności, które pozwolą obsłużyć ewentualne ryzyko, jeśli wystąpi.
Zarządzanie komunikacją i oczekiwaniami. Proaktywne komunikowanie (oparte
o Plan Komunikacji) powinno spowodować, że klient będzie rozumiał, jakie są oczekiwania względem niego i jakie konsekwencje dla niego niesie niedotrzymywania przez niego ustalonych terminów.
Zarządzanie przekroczonymi terminami
jak problemami krytycznymi. Jeśli (nawet pomimo Planu zarządzania ryzykiem), klient przekroczy ustalone dla niego terminy reakcji czy odpowiedzi - pojawi się problem krytyczny. Należy wtedy postąpić zgodnie z zasadami zarządzania problemami krytycznymi (zidentyfikowanie i opracowanie rozwiązań problemu). Kierownik projektu nie posiada bezpośredniego zwierzchnictwa nad klientami, tak więc procedury zarządzania problemami krytycznymi pozwolą mu jedynie na to, by zostać zauważonym przez własnego przełożonego i menedżerów klienta. A także na uzyskanie od nich odpowiednich decyzji. Pomimo, że kierownik projektu staje się bezwiednie odpowiedzialny za skutki zachowań klienta, które są przecież poza jego kontrolą, nie wolno mu zapominać, że jest
227 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
on odpowiedzialny za proaktywne zarządzanie projektem i ma kontrolę nad odpowiednimi procesami zarządczymi. Za pomocą posiadanych narzędzi, uprawnień i w ramach ustalonych procedur może on sprawić, że dotrzymywanie terminów będzie ważne dla każdej ze stron.
228 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.2.1 Zarządzanie problemami krytycznymi / Analiza przyczynowo-skutkowa 4.2.1.P1 Technika przyczynowo-skutkowa jest sposobem na analizowanie złożonych problemów, które mają wiele powiązanych ze sobą przyczyn. Jednym z głównych aspektów tej techniki jest użycie diagramu przyczynowo-skutkowego. Ze względu na pojawianie się diagramu, technika ta zwana jest również Diagramem rybich ości lub Diagramem Ishikawy, od nazwiska Kaoru Ishikawa, japońskiego profesora, który wynalazł go w 1943r. Korzyści płynące z tej techniki są następujące:
Pozwala na sprawdzenie różnych kategorii przyczyn. Stymuluje kreatywność poprzez proces burzy mózgów. Przedstawia wizualne wyobrażenie problemu oraz prawdopodobnych
kategorii
przyczyn. 4.2.1.P2 Tworzenie Diagramu rybich ości. Zastosuj następujący proces, aby stworzyć Diagram Rybich Ości:
1
2
Role
Tworzenie Diagramu rybich ości.
Kierownik projektu, członkowie zespołu.
Opisywanie problemu.
Kierownik projektu, członkowie zespołu.
Tworzenie ―kręgosłupa‖.
Problem należy opisać po prawej stronie diagramu. Może to być faktyczny problem lub symptom. Na tym etapie jeszcze tego nie wiadomo.
Należy narysować poziomą strzałkę w kierunku ramki. Strzałka ta będzie spełniać rolę kręgosłupa, na którym pojawiać się będą dalsze większe lub mniejsze przyczyny. Duża rotacja pracowników
3
Kierownik projektu, członkowie
Identyfikowanie głównych kategorii przyczyn i łączenie ich na kręgosłupie. Należy określić (wymyślić, zidentyfikować) potencjalne przyczyny i
229 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zespołu.
podzielić je na główne kategorie. Przykładami głównych kategorii mogą być: ludzie, procesy, materiał, sprzęt, środowisko, itp. Główne kategorie identyfikowane są przy użyciu techniki burzy mózgów. Tak więc na tym etapie nie należy przejmować się ustalaniem, czy dana kategoria skupia potencjalną przyczynę, czy też nie. Należy je tylko przedstawić. Należy zostawić odpowiednią ilość miejsca pomiędzy głównymi kategoriami, aby można było dodać później bardziej szczegółowe przyczyny. Każda z większych kategorii zostanie szczegółowo sprawdzona. Kierownictwo
Lokalizacja
Duża rotacja pracowników
Korzyści/
Rynek
świadczenia
4
Kierownik projektu, członkowie zespołu.
Szukanie szczegółowych przyczyn dla każdej kategorii. Należy kontynuować burzę mózgów, szukając szczegółowych wyjaśnień głównych kategorii przyczyn określonych powyżej. Należy przedstawić bardziej szczegółowe przyczyny na poziomych liniach, które łączą się z właściwą dużą kategorią. Kierownictwo
Lokalizacja
Nie jest wystarczająco elastyczne Trudny dojazd Nie skupione wystarczająco na zatrzymaniu pracowników Małe miasto / wieś
Brak różnorodności
Duża rotacja pracowników
Duże zapotrzebowanie Płaca podstawowa zbyt mała
na pracowników Wzrost płac
Rynek
No 401K
Korzyści/ świadczenia
5
Kierownik projektu, członkowie
(Nieobowiązkowe) Sprawdzenie dodatkowych przyczyn bardziej szczegółowo. Czasami, wyszczególnione przyczyny będą miały inne drobniejsze
230 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6
7
8
zespołu.
przyczyny. Jeśli tak jest, należy połączyć je dodatkowymi liniami. Trzy poziomy szczegółów to zazwyczaj limit tego diagramu.
Kierownik projektu, członkowie zespołu.
Analizowanie i szeregowanie przyczyn.
Kierownik projektu, członkowie zespołu.
Określenie, które obszary mają największy wpływ i największe szanse powodzenia.
Kierownik projektu, członkowie zespołu.
Tworzenie przyczyn.
Po przeprowadzeniu burzy mózgów co do głównych kategorii oraz bardziej szczegółowych potencjalnych przyczyn, należy rozpocząć analizę zebranych informacji. Każda główna przyczyna oraz potencjalne szczegółowe przyczyny z nią połączone powinny zostać ocenione, należy pamiętać, że lista powstała w wyniku burzy mózgów, podczas której wykorzystano wszystkie pomysły. Teraz należy określić te punkty, które wydają się być bardziej prawdopodobną przyczyną (lub jedną z przyczyn). Należy zaznaczyć te punkty, które wyglądają najbardziej obiecująco i powinny być dalej sprawdzane.
Jeśli nie został osiągnięty oczywisty konsensus co do głównych obszarów badań, należy zastosować głosowanie, zmniejszając ilość możliwości do takich, które mają największe szanse powodzenia. planu
działań
do
rozwiązania
zaznaczonych
Należy pamiętać, że może być kilka potencjalnych połączonych przyczyn, w wyniku których powstaje problem. Plan działań musi brać pod uwagę te zależności. Jeśli szczegółowe przyczyny są w dalszym ciągu zbyt rozległe, lub jeśli nie wiadomo wystarczająco dużo, można do nich przyporządkować jedną lub więcej osób, które po spotkaniu przeprowadzą dalsze badania.
231 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.2.1.P3 Inne zasady dla sesji przyczynowo-skutkowej. Podczas sesji należy używać tych dodatkowych zasad i technik.
Należy
upewnić się, że wszyscy zgadzają się co do problemu, który należy rozwiązać. Procedura burzy mózgów może stać się chaotyczna, jeśli ludzie będą starali się rozwiązywać różne problemy.
Należy wykorzystać techniki burzy mózgów, aby zebrać wstępną listę głównych
kategorii oraz szczegółowych przyczyn. Wszystkie pomysły powinny być na niej zawarte. Dyskusja powinna być ograniczona do zrozumienia problemu. Nie należy sprawdzać, czy pomysły są dobre czy nie.
Może pojawić się tendencja do przeskakiwania z głównych kategorii od razu do rozwiązań. Należy upewnić się, że przejrzy się wszystkie główne i szczegółowe przyczyny przed przejściem do rozwiązywania problemu.
Należy upewnić się, że cała grupa widzi Diagram rybich ości. Połączenia i relacje powinny być widoczne.
Nie należy tworzyć zbyt szczegółowych diagramów. Jeśli jedna z kategorii staje się zbyt duża, można ją przesunąć na inny diagram.
Należy
zdawać sobie sprawę z podobnych szczegółowych przyczyn, które pojawiają się w różnych głównych kategoriach. Może to być wskazówką co do przyczyny podstawowej.
232 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.2.2 Zarządzanie problemami krytycznymi / Analiza przyczyn podstawowych (RCA) 4.2.2.P1 Czasami w trakcie rozwiązywania problemu okazuje się, że w rzeczywistości to co wydawało się być problemem podstawowym, jest raczej problemem powiązanym, a nie faktyczną przyczyną problemu. Weźmy pod uwagę poniższy, klasyczny przykład. Kierownik zakładu przechodzi obok linii montażowej i zauważa kałuże wody na podłodze. Wiedząc, że woda stanowi zagrożenie bezpieczeństwa, prosi brygadzistę o sprowadzenie kogoś z mopem i wytarcie kałuży. Kierownik zakładu jest dumny z siebie. “Zlikwidował” potencjalne zagrożenie dla bezpieczeństwa. Jednakże brygadzista jest podejrzliwy. Nie zna przyczyny pojawienia się kałuży. Nie było jej tu wczoraj. Zastanawia się więc, co mogło spowodować pojawienie się kałuży w dniu dzisiejszym. Dlatego też zaczyna szukać przyczyny podstawowej zadając pytanie „dlaczego?”. Odkrywa, że przyczyną kałuży wody jest przeciek w górnej rurze. Ponownie zadaje pytanie “dlaczego?” i odkrywa, że rura przecieka, ponieważ zostało ustawione zbyt duże ciśnienie wody. Ponownie zadaje pytanie “dlaczego?” i odkrywa, że zawór ciśnienia jest zepsuty. Ponownie zadaje pytanie “dlaczego?” i nie otrzymuje dalszych odpowiedzi. Wadliwy zawór jest podstawową przyczyną problemu. Tak więc zawór zostaje naprawiony a to powoduje, że woda na podłodze fabryki już się więcej nie pojawia. Analiza przyczyn podstawowych jest sposobem na identyfikację podstawowej przyczyny problemu. W powyższym przykładzie było wiele okazji do rozwiązania niewłaściwego problemu. Najpierw kierownik zakładu mógł zamówić dostawę większej ilości mopów (tak żeby były dostępne w hali produkcji). Brygadzista mógł nakazać wymianę górnej rury. Jednak te rozwiązania byłyby zmarnotrawione. Nie rozwiązałyby problemu ze względu na to, że skupiły się na symptomach a nie samym problemie. Analiza przyczyn podstawowych jest wykonywana zazwyczaj poprzez zadawanie kilku pytań „dlaczego?”. Tak jak w powyższym przykładzie należy zadać sobie pytanie: „dlaczego problem się pojawił?”. Wtedy odnajdzie się jedna lub więcej przyczyn. Dla każdej z tych przyczyn należy ponownie zadań pytanie „dlaczego?”. Jeśli można na nie odpowiedzieć, oznacza to, że pierwsza odpowiedź była prawdopodobnie symptomem spowodowanym przez podstawową przyczynę. Należy kontynuować zadawanie pytania „dlaczego?” aż do momentu, gdy nie można już uzyskać logicznej odpowiedzi. Ten najniższy poziom jest zazwyczaj przyczyną podstawową i to on wpływa na pojawianie się symptomów. W trakcie analizy można odkryć więcej niż jedną przyczynę podstawową. Kiedy zidentyfikowano już przyczynę(y) podstawową(e) należy wdrożyć Plan rozwiązania problemu. Po jego wykonaniu symptomy również powinny zniknąć.
233 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.2.3 Zarządzanie problemami krytycznymi / Analiza Pareto 4.2.3.P1 Analiza Pareto może zostać użyta, kiedy napotyka się wielorakie problemy powiązane lub zwykłe problemy o wielu przyczynach. Dzięki tej technice można również zebrać informacje o tym, jak często pojawia się dany problem lub przyczyna. Celem Analizy Pareto jest obserwowanie problemu i określanie częstotliwości jego występowania. Daje to informacje, które można użyć do uszeregowania nakładów pod względem ważności. Gwarantuje to również poświęcaniu czasu tam, gdzie będzie to miało największy pozytywny wpływ. Analiza Pareto oparta jest na klasycznej zasadzie 80/20. Oznacza to, ze 20% przyczyn podstawowych powoduje 80% wystąpień problemów. Na przykład, powiedzmy, że problem polega na uszkodzeniu produktu (w oparciu o kilka przyczyn) na taśmie produkcyjnej. Poprzez obserwację oraz zbieranie danych, określonych zostaje osiem przyczyn. Zamiast naprawiać przyczyny na chybił trafił, Analiza Pareto może ukazać, że 80% wystąpień problemów spowodowanych jest pierwszymi trzema przyczynami. W ten sposób wiadomo, które przyczyny należy rozwiązać w pierwszym rzędzie. Narzędzie związane z tą techniką rozwiązywania problemów nazywa się Diagramem Pareto. Jest to tabela, wykres lub histogram pokazujący każdy z problemów i częstotliwość ich występowania. Tworzony jest następujący sposób:
1
3
Role
Tworzenie Diagramu Pareto
Kierownik projektu, członkowie zespołu.
Należy stworzyć tabelę i podać wszystkie zaobserwowane problemy i przyczyny.
Kierownik projektu, członkowie
Dla każdego problemu należy określić ilość wystąpień w określonym okresie czasu.
Problem 1
115
Problem 2
25
Problem 3
50
Problem 4
5
Problem 5
5
Problem 6
15
Należy ułożyć problemy od najczęstszego do najrzadszego w oparciu o ilość przypadków.
234 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zespołu. 4
Kierownik projektu, członkowie zespołu.
Należy stworzyć nową kolumnę dla sumy narastającej. Problem 1
115
53%
Problem 3
50
77%
Problem 2
25
88%
Problem 6
15
95%
Problem 4
5
98%
Problem 5
5
100 %
Warto zwrócić uwagę jak ważne informacje uzyskujemy w ten sposób. Pomimo, że określono ogółem sześć problemów, należy w pierwszej kolejności rozwiązać problemy nr 1 i nr 3 (wszystkie problemy są podobne). Przy takim podejściu osiągnięta zostanie największa korzyść. Jeśli zamiast tego podejmie się decyzję o pracy nad problemami nr 4 i nr 5, wyniki pracy będą prawie znikome. Nie oznacza to, że nie należy rozwiązywać tych problemów. Analiza Pareto ukazuje kolejność rozwiązywania problemów. Daje również wyobrażenie o relatywnej wartości otrzymywanej po rozwiązaniu każdego z problemów. Zdecydowanie nie należy używać takich samych nakładów, rozwiązując problem nr 5 jak w przypadku rozwiązywania problemu nr 1. To się po prostu nie opłaca (oczywiście można ustalić, że problem nr 6 da się rozwiązać szybko. Dlatego też warto go wybrać na początek. Diagram Pareto nie mówi nam, co mamy robić. Daje nam tylko informacje, potrzebne do podjęcia najlepszej decyzji). Zwykle wyniki Diagramu Pareto są przedstawione w formie histogramu lub wykresu słupkowego. Pozwala to lepiej wyobrazić sobie prezentowane wartości.
235 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4.3 Zarządzanie problemami krytycznymi / Podsumowanie 4.3.P1 Przedmioty dostawy Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Formularz zgłoszenia problemu krytycznego. Dziennik problemów krytycznych. 4.3.P2 Harmonogram – czynności Rozmiar
Małe
Niezbędne informacje W małych projektach nie jest konieczne planowanie działań związanych z zarządzaniem problemami krytycznymi. W szczególnych przypadkach można stosować czynności przeznaczone dla średnich projektów. Czynność
pracochłonność
Uwagi
1-2 godziny
Co tydzień. Czynność przypisana zawsze do kierownika projektu. Służy sprawdzeniu, czy problemy krytyczne są obsługiwane właściwie oraz czy Dziennik problemów krytycznych jest systematycznie uzupełniany.
otwarte
Należy dodać do harmonogramu zadanie dla każdego problemu krytycznego, który został przyporządkowany do przeanalizowania członkowi zespołu.
Rozwiązywanie problemów krytycznych.
otwarte
Jeśli rozwiązanie problemu krytycznego wymaga wykonania dodatkowych zadań, powinny one zostać dodane do harmonogramu.
Czynność
pracochłonność
Uwagi
Sprawdzenie statusu problemów
1-2 godziny
Co tydzień. Czynność przypisana zawsze do kierownika projektu.
Sprawdzenie statusu problemów krytycznych.
Średnie Analiza problemów krytycznych.
Duże
236 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Służy sprawdzeniu, czy problemy krytyczne są obsługiwane właściwie oraz czy Dziennik problemów krytycznych jest systematycznie uzupełniany.
krytycznych.
Analiza problemów krytycznych.
Rozwiązywanie problemów krytycznych.
Uaktualnienie Definicji projektu.
otwarte
Należy dodać do harmonogramu zadanie dla każdego problemu krytycznego, który został przyporządkowany do przeanalizowania członkowi zespołu.
otwarte
Jeśli rozwiązanie problemu krytycznego wymaga wykonania dodatkowych zadań, powinny one zostać dodane do harmonogramu.
otwarte
Jeśli rozwiązanie problemu krytycznego wymaga wprowadzenia zmian do Definicji projektu aby odzwierciedlić zmiany w kosztach, pracochłonności lub czasie trwania – należy dodać odpowiednie czynności do harmonogramu.
237 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 5 Zarządzanie zmianami
238 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.0 Zarządzanie zmianami 5.0.P1 Mówi się czasem, że jedyną stałą rzeczą na świecie jest zmiana. Można zaplanować wszystko perfekcyjnie, ale i tak nie da się przewidzieć wszystkich potencjalnych zmian, jakie mogą się pojawić w trakcie realizacji projektu. Im jest on dłuższy tym większe prawdopodobieństwo wydarzenia się takich zmian. To właśnie jeden z powodów, dla których metodyka TenStep pozwala na to, aby początkowa definicja (Proces 1 – Definiowanie projektu) i planowanie (Proces 2 – Budowanie planu i budżetu) nie były perfekcyjne. Kierownik projektu i jego zespół muszą dołożyć wszelkich starań, aby ich praca była możliwie najlepsza, na podstawie tego, co wiedzą w tym konkretnym momencie. To wystarczy. A potem trzeba tylko rozsądnie i skutecznie zarządzać zmianami. Jest wiele aspektów projektu w jakich mogą pojawić się zmiany:
Zmiany zakresu projektu Zmiany konfiguracji Wszystkie pozostałe zmiany
Ten rozdział metodyki TenStep omawia wszystkie aspekty zmian. W większości projektów najważniejszym z nich będą zmiany zakresu. Temu właśnie zagadnieniu poświęca się tu najwięcej miejsca. 5.0.P2 Zmiany zakresu projektu. Zakres jest terminem używanym w celu określenia logicznych granic projektu. Pojęcia zakresu używa się zatem do zdefiniowania tego co zostanie i tego co nie zostanie dostarczone w ramach projektu. W większych projektach zakres projektu może obejmować organizacje, których on będzie dotyczył, związane z nim, transakcje, rodzaje danych, technologie etc. Jeśli przyjrzeć się powodom, dla których niektóre projekty się nie powiodły, zazwyczaj przyczyna tkwi w dwóch problemach. Albo zespół projektowy nie poświęcił wystarczająco dużo czasu na zrozumienie i zdefiniowanie pracy do wykonania i/lub brakowało zarządzania zakresem projektu. Nawet, jeśli kierownik projektu dobrze zdefiniował ten zakres, największym wyzwaniem okazuje się zarządzanie projektem tak aby nie wyszedł on poza wcześniej uzgodnione ramy. Celem zarządzania zmianami zakresu projektu jest ochrona wykonalności zatwierdzonej Definicji projektu i innych zatwierdzonych wymagań tego przedsięwzięcia. Definicja zawiera ogólny zakres projektu i precyzyjną listę przedmiotów dostaw odzwierciedlające wymagania biznesowe klienta. Kierownik projektu i zespół, podejmując się projektu, zobowiązują się dotrzymać terminu wykonania i ram budżetowych skonstruowanych w oparciu o zakres. Jeśli przedmioty dostawy zmienią się w trakcie realizacji projektu (a to zazwyczaj oznacza, że klient zamawia dodatkowe produkty), szacowane koszty, pracochłonność i czas trwania projektu mogą okazać się nie aktualne. Jeśli sponsor zgodzi się na uwzględnienie w zakresie pracy tych nowych produktów, kierownik projektu ma prawo oczekiwać, że zarówno budżet jak i termin realizacji zostanie odpowiednio zmieniony (zazwyczaj zwiększony). Dopiero taka zmiana
239 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
pozwoli na zrealizowanie dodatkowych zadań. Nowo oszacowane pracochłonność i czas trwania projektu stają się jedynymi obowiązującymi.
koszty,
Zdarza się, że kierownicy projektów postrzegają zarządzanie zakresem projektu jako konieczność powiedzenia klientowi: „Nie” w momencie, gdy sygnalizuje on chęć wprowadzania zmian. Stają się strażnikami pierwotnych ustaleń (co może także skutkować podenerwowaniem i uczuciem dyskomfortu). Nie mają jednak racji. Intencją zarządzania zmianą jest umożliwienie sponsorowi podejmowania decyzji, które będą skutkowały modyfikacją zakresu projektu. To bardzo istotne. Tylko nieliczni klienci bowiem potrafią określić wszystkie wymagania z wyprzedzeniem. W związku z tym zazwyczaj trzeba wprowadzać pewne modyfikacje w trakcie realizacji projektu. Zmiany takie mogą być niezbędne dla osiągnięcia właściwych rezultatów lub ważne z innych przyczyn biznesowych. Dlatego wprowadzenie ich do projektu, mimo, że wcześniej nie planowane, okazuje się konieczne. Kierownik projektu i zespół projektowy muszą umieć dostrzec potrzebę takich zmian. Jeśli to nastąpi - stosować się do formalnego procesu zmiany zakresu projektu. Spowoduje to, że sponsor projektu otrzyma wszelkie niezbędne informacje do podjęcia decyzji o zmianie. Będzie to m.in. analiza korzyści biznesowej, jaką niesie zmiana; wpływ na koszty projektu, wpływ na czas trwania projektu. 5.0.P3 Zmiany konfiguracji. Zarządzanie konfiguracją to termin określający identyfikację, nadzór i zarządzanie wszystkimi aktywami projektu i charakterystykami (metadane) tych aktywów. W niektórych organizacjach ten proces jest rozumiany bardzo wąsko, jako zarządzanie aktywami materialnymi. 5.0.P4 Wszystkie pozostałe zmiany. Projekt może doświadczyć zmian, które nie koniecznie mieszczą się w ramach pojęcia „zarządzanie zmianami zakresu” czy „zarządzanie konfiguracją”. Wtedy można przypisać je w kategorii „ogólnej” zarządzania zmianami. Na przykład, kiedy jeden z członków zespołu projektowego rezygnuje i musi zostać zastąpiony. Nie jest to zmiana zakresu projektu ani też zmiana konfiguracji. Jest to zmiana ogólna. W takim przypadku konieczne może okazać się odnotowanie tego faktu jako „zmiany zasobów”, określenie skutku takiej zmiany, zaktualizowanie harmonogramu związanymi z nią czynnościami itd. Pod wieloma względami będzie to proces podobny do tego gdzie zmienia się zakres, jakkolwiek wspomniana zmiana nie jest skutkiem formalnego wniosku zmiany zakresu projektu. Jedną z zasadniczych różnic pomiędzy zarządzaniem zmianami ogólnymi i zarządzaniem zmianami zakresu jest to, że w przypadku zmiany zakresu wymagane są: formalne zgłoszenie chęci zmiany i formalna zgoda na taką zmianę. Dodatkową konsekwencją będzie także konieczność uaktualnienia budżetu i harmonogramu projektu. W przypadku zmian ogólnych takie działania zwykle nie będą miały miejsca. Na przykład, w opisanym powyżej przypadku, kiedy nastąpiła konieczność wymiany członka zespołu projektowego, nie mamy wątpliwości, co do tego, że nastąpiła zmiana, i że miała ona wpływ na projekt. Jednak nie będzie ona zwykle skutkować modyfikacją budżetu czy harmonogramu. Gdyby tak się jednak stało - nie należy automatycznie zakładać, że uzyskamy na to zgodę. 5.0.1 Zarządzanie zmianami / Definiowanie zakresu. 240 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1 Zarządzanie zmianami / Proces. 5.2 Zarządzanie zmianami / Techniki. 5.3 Zarządzanie zmianami / Podsumowanie.
5.0.1 Zarządzanie zmianami / Definiowanie zakresu 5.0.1.P1 Definiowanie zakresu jest przypuszczalnie najważniejszą częścią początkowego definiowania i planowania projektu. Jeśli nie wiadomo, co jest przedmiotem dostawy projektu i jakie są jego granice, szanse na powodzenie są znikome. Jeżeli zakres projektu nie zostanie należycie określony – także zarządzanie nim będzie praktycznie niemożliwe. Celem definiowania zakresu jest dokładny opis i osiągnięcie porozumienia, co do logicznych granic projektu. Opis zakresu ma określać, to co mieści się w ramach projektu oraz to co jest poza jego granicami. Im więcej aspektów zakresu projektu zostanie zidentyfikowanych, tym lepiej będzie można nim zarządzać. Następujące informacje mogą okazać się pomocne w definiowaniu zakresu projektu: Przedmioty dostawy, które mieszczą się w zakresie projektu i te poza zakresem. W zakresie opisane powinny być bezwzględnie przedmioty dostaw. (W dokumencie Definicja Projektu jest na to miejsce w osobnej rubryce.) Przede wszystkim jednak te, które będą odbierane przez sponsora (tzw. Zewnętrzne przedmioty dostaw) lub podlegają opiniowaniu (lub zatwierdzeniu) przez klienta. Nie ma natomiast potrzeby wymieniania wewnętrznych dokumentów projektu takich jak harmonogram, projekt techniczny czy scenariusze testowe. Z jednej strony może się okazać, że sponsor nie zrozumie tych produktów, z drugiej – zwykle ich nigdy nie zobaczy. Główne procesy cyklu życia (np. produktu), które mieszczą się w zakresie projektu i te poza zakresem. Projekt może na przykład zawierać tylko fazę analizy, a nie zawierać faz projektowania, konstruowania czy testowania. Rodzaje danych, które mieszczą się w zakresie projektu i te poza zakresem. “Rodzaje danych” odnoszą się do takiej kategorii przedmiotów dostawy jak: dane finansowe, dane o sprzedaży, dane pracownicze etc. Trzeba ustalić czy projekt obejmuje pewne rodzaje danych, i czy jakichś wyraźnie nie obejmuje. Źródła danych (lub bazy danych), które mieszczą się w zakresie projektu i te poza zakresem. Podobnie jak rodzaje danych, z tym tylko wyjątkiem, że źródeł mówimy o danych zagregowanych, takich jak: Baza danych klientów, finansowa księga główna, system fakturowania etc. (Takie źródła danych mogą mieć więcej niż jeden rodzaj danych.) Działy, które są zaangażowane w projekt i te, które w nim nie uczestniczą. Na przykład projekt może dotyczyć Działu zasobów ludzkich i Działu księgowości, natomiast Dział produkcji może być poza zakresem projektu. Główna funkcjonalność, która mieści się w zakresie projektu i ta poza zakresem. Na przykład funkcjonalności: wsparcie w podejmowaniu decyzji i
241 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
skonsolidowane raporty zarządcze mogą mieścić się z zakresie projektu, natomiast przetwarzanie danych w innych celach może pozostawać poza zakresem.
242 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.0.1.P2 Użyjcie znanych danych jako punktu wyjściowego. Kiedy projekt zostaje przedstawiony do sfinansowania, zwykle znane są już główne cele i większość przedmiotów dostaw. Może istnieje nawet swego rodzaju zarys zakresu projektu. Każda taka informacja, która została wcześniej przygotowana, powinna być użyta jako punkt wyjściowy dla bardziej szczegółowych prac nad zakresem projektu w Definicji projektu. Jeśli istnieją wątpliwości czy informacje, które posiadasz, są wystarczające do zdefiniowania jasnego i dokładnego zakresu projektu - należy zwrócić się do sponsora i zebrać dodatkowe informacje. Jest to jeden z najważniejszych punktów procesu definiowania i planowania. Kierownik projektu, definiując zakres, powinien przyjrzeć się najpierw celom projektu. Istnieje reguła, która mówi, że każdy cel projektu powinien być odzwierciedlony w co najmniej jednym przedmiocie dostawy – a lista przedmiotów dostaw jest podstawową częścią definicji zakresu. Po wypracowaniu głównych przedmiotów dostawy, które projekt zrealizuje przychodzi czas na zadanie innych pytań w celu określenia pozostałych aspektów zakresu. Przedmioty dostawy określają, co będzie efektem realizacji tego projektu. Można też określić, jakie działy będą zaangażowane w realizację projektu, jakie rodzaje danych będą potrzebne i jakie główne cechy i funkcjonalności będą konieczne, jakie technologie, terytorium etc. W celu dodatkowego wyjaśnienia i skontrastowania zakresu projektu można też określić okoliczności spoza tego zakresu poprzez opisanie przedmiotów dostawy, które nie będą wytworzone podczas realizacji projektu, wskazać działy, które nie będą objęte projektem oraz cechy i funkcje, które nie będą wykorzystane etc. Oczywiście liczba rzeczy spoza zakresu może być nieskończona. Dlatego dla potrzeb zdefiniowania zakresu projektu celowym będzie przedstawienie tych stwierdzeń, które pomogą określić granice projektu i wspomnieć o tych obszarach, co, do których czytelnik może mieć wątpliwości. Na przykład, jeśli rozważa się wytworzenie oprogramowania księgowego, można stwierdzić, że funkcjonalność Rachunki do zapłaty może być w obrębie zakresu, natomiast powiązany z tym System zakupów będzie poza zakresem projektu. Wtedy umieszczenie obu z nich w opisie zakresu ma swoje uzasadnienie, ponieważ procesy Zakupów i Rachunków do zapłaty są ze sobą powiązane i mogą budzić wątpliwości w odniesieniu do zakresu projektu. Nie należy jednak wymieniać każdego innego systemu spoza zakresu – tylko te, które mogą być niejasne dla czytelnika. Dobrą praktyką jest także udokumentowanie, które działy w firmie mieszczą się w obrębie zakresu projektu, a które nie. Pozwoli to czytelnikom na stwierdzenie, czy są oni zaangażowani w realizację i czy oczekuje się od nich, że będą pomagać przy projekcie czy też nie. Także pracownicy owych działów będą wiedzieć, że mogą zostać poproszeni o udział zespole projektowym lub w komitecie sterującym. 5.0.1.P3 Uspójnianie celów i zakresu. Kiedy zdefiniowano już zarówno cele jak i zakres, warto się upewnić, czy są one spójne. Nie powinny istnieć żadne cele, które odwołują się do przedmiotów dostawy nie zdefiniowanych w zakresie projektu. Trudno będzie osiągnąć cel niczego (z perspektywy tego celu) nie wytwarzając. Podobnie jest z uwzględnianiem w zakresie projektu przedmiotów dostawy, które nie są związane z realizacją wytyczonych celów. Jeżeli zostaną zidentyfikowane takie przedmioty dostawy, należy zadać pytanie: Dlaczego one się tu pojawiły? Skoro, z definicji, cele uszczegóławiają zamierzenia projektu, to po co pracować nad przedmiotami, które nie pomagają w realizacji tych zamierzeń?
243 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jeśli cele i przedmioty dostawy w odpowiedniej sekcji Definicji projektu nie przystają do siebie, trzeba się zastanowić, w jaki sposób je uspójnić. Jeżeli wyznaczono cel, któremu nie przypisano żadnego przedmiotu dostawy, należy ponownie rozpatrzeć, czy cel ten jest ważny. Jeśli pozostaje istotny - należy dodać lub zmodyfikować przedmioty dostawy tak, aby przyczyniały się do osiągnięcia tego celu. Jeśli zaistnieje przypadek, że to przedmiot dostawy nie będzie miał spójnego z nim celu, należy zadać sobie pytanie, czy przedmiot ten jest naprawdę ważny. Jeżeli tak nie jest - należy usunąć go z projektu. W przeciwnym razie należy wspólnie ze sponsorem zidentyfikować i zapisać taki cel biznesowy, który ów przedmiot zrealizuje. Często cel taki istnieje, tylko nie został wystarczająco wyraźnie uświadomiony lub zwerbalizowany.
244 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1 Zarządzanie zmianami / Proces 5.1.P1 W tym rozdziale opisane zostały procesy zarządzania zmianami. Procesy te mogą być modyfikowane w razie potrzeby. Jeśli tak się stanie, należy je umieścić w Planie zarządzania projektem, który jest tworzony w trakcie procesu 1.0 Definiowanie Projektu. 5.1.1 ZARZĄDZANIE ZMIANAMI / MAŁE PROJEKTY
5.1.2 Zarządzanie zmianami / Średnie Projekty 5.1.3 Zarządzanie zmianami / Duże Projekty
245 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1.1 Zarządzanie zmianami / Małe Projekty 5.1.1.P1 Zarządzanie zmianami zakresu projektu. Ponieważ małe projekty są dużo łatwiejsze do zdefiniowania i zazwyczaj trwają niezbyt długo - nie występuje w nich wiele żądań zmian. Te, które się pojawiają to w większości zmiany zakresu projektu. Nawet, jeśli taka zmiana zakresu się pojawi, jej wymiar jest zwykle także niewielki. Oto prosty proces, który powinien być stosowany w takich przypadkach.
1
2
3
4
5
Osoba
Zarządzanie zmianami zakresu (małe projekty)
Kierownik projektu, członek zespołu.
Zidentyfikowanie zgłoszenia zmiany zakresu.
Kierownik projektu.
Sprawdzenie, czy jest to rzeczywista zmiana zakresu.
Kierownik projektu.
Określ wpływu zmiany na projekt.
Kierownik projektu, Kierownik ze strony klienta.
(Opcjonalnie) Obsłużenie niewielkich zmian
Sponsor.
Przekazanie informacji sponsorowi.
Zmiana zakresu może zostać zgłoszona przez każdego członka zespołu projektowego. Wniosek taki powinien zostać wysłany do kierownika projektu na papierze lub pocztą elektroniczną. Nie ma konieczności korzystania z formalnych formularzy.
Kierownik projektu sprawdza, czy wniosek dotyczy w rzeczywistości zmiany zakresu projektu (rozumianej jak to opisano powyżej).
Kierownik projektu określa wpływ wnioskowanej zmiany zakresu na projekt w dziedzinie kosztów, pracochłonności i długości czasu trwania. Jeśli istnieje kilka różnych alternatyw, kierownik projektu określa wpływ każdej z nich.
Jeśli wnioskowana zmiana nie zmieni pierwotnych kosztów projektu, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą samodzielnie podjąć decyzję o tym, czy zmiana taka powinna być wprowadzona. Jest jednak pewien warunek. Sponsor projektu musiał wcześniej formalnie udzielić takich uprawnień kierownikowi projektu – zazwyczaj do pewnego poziomu kosztów i pracochłonności.
Właściwa analiza, wpływ na projekt i istniejące alternatywy są prezentowane sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 4 opisanym powyżej). Jeśli sponsor nie zgodzi się na wnioskowaną zmianę i wiążące się z nią skutki zmiana zakresu nie zostaje wprowadzona.
246 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6
7
Kierownik projektu.
Uzupełnienie harmonogramu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Jeśli wniosek o zmianę zakresu zostanie zatwierdzony, należy dodać do harmonogramu zadania realizujące tę zmianę.
Wniosek o zmianę, status bieżący zmiany oraz wybrana decyzja powinny zostać udokumentowane w Raporcie o stanie projektu.
247 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1.2 Zarządzanie zmianami / Średnie Projekty 5.1.2.P1 Zarządzanie zmianą zakresu W średnich projektach oprócz zmian zakresu pojawiają się także żądania innych zmian. Proces został opisany poniżej. Zarządzanie zmianami zakresu (Średnie projekty). Osoba 1
2
3
4
5
6
Kierownik projektu.
Zidentyfikowanie zgłoszenia zmiany zakresu.
Kierownik projektu.
Sprawdzenie, czy jest to rzeczywista zmiana zakresu.
Kierownik projektu.
Wprowadzenie wniosku o zmianę do Dziennika zmian zakresu.
(Osoba zgłaszająca wniosek)
Opisanie wartości biznesowej zmiany.
Kierownik projektu, członek zespołu.
Wyznaczenie osoby do zbadania zmiany zakresu.
Kierownik projektu, kierownik ze strony klienta.
(Opcjonalnie) Obsłużenie niewielkich zmian
Potencjalne zmiany zakresu mogą zostać zgłoszone przez różnych interesariuszy, m.in.: zespół projektowy, klientów, sponsorów, etc. Wnioski o taką zmianę powinny zostać dostarczone w formie pisemnej kierownikowi projektu w postaci Formularza zgłoszenia zmiany zakresu (nieobowiązkowy) lub pocztą elektroniczną.
Kierownik projektu sprawdza, czy wniosek dotyczy w rzeczywistości zmiany zakresu projektu (rozumianej zgodnie z definicją).
Kierownik projektu wprowadza do Dziennika zmian zakresu informację o nowym wniosku i charakterze zmiany w celu śledzenia procesu jej wprowadzania.
Osoba, która składa wniosek o zmianę zakresu powinna zdefiniować jej wartość biznesową dla projektu. Informacja ta będzie niezbędna, aby sponsor mógł podjąć ostateczną decyzję.
Kierownik projektu przydziela zadanie zbadania wpływu zmiany na projekt członkowi zespołu projektowego lub sobie samemu.
Jeśli wpływ na koszty, pracochłonność i czas trwania nie będzie większy od przyjętego progu (powiedzmy poniżej 20 roboczogodzin), a realizacja projektu w dalszym ciągu będzie możliwa zgodnie z wcześniej ustalonymi wskaźnikami dla kosztów, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą zatwierdzić taki wniosek o zmianę zakresu samodzielnie. Jest jednak pewien warunek. Sponsor projektu musi wcześniej formalnie udzielić takich
248 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
uprawnień kierownikowi projektu, ustalając wysokość progów decyzyjnych - zazwyczaj w pieniądzach lub roboczogodzinach oraz ewentualne inne warunki. 7
Sponsor.
Przekazanie informacji sponsorowi. Wniosek o zmianę zakresu zawierający właściwą analizę wpływu na projekt i istniejące alternatywy jest prezentowany sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 6 opisanym powyżej).
8
9
10
11
Kierownik projektu.
Zapisanie decyzji w Dzienniku zmian zakresu.
Kierownik projektu.
Uzupełnienie harmonogramu.
Kierownik projektu.
Uaktualnienie Definicji projektu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Jeśli sponsor nie zgodzi się na wnioskowaną zmianę, wniosek powinien zostać zamknięty, a do Dziennika zmian zakresu należy wpisać klauzulę: ”nie zatwierdzono”.
Jeśli wniosek o zmianę zakresu zostanie zatwierdzony, należy dodać do harmonogramu zadania realizujące tę zmianę. Jeśli to konieczne, należy uaktualnić także budżet i termin zakończenia projektu.
Aktualna Definicja projektu zatwierdzone zmiany zakresu.
powinna
zostać
uzupełniona
o
Status bieżący zmiany oraz wybrana decyzja powinny zostać zakomunikowane członkom zespołu oraz innym interesariuszom zgodnie z metodami przyjętymi w Planie komunikacji a także udokumentowane w Raporcie o stanie projektu.
5.1.2.P2 Kontrola zmian zintegrowanych.
1
2
Osoba
Zarządzanie zmianami ogólnymi (średnie projekty)
Kierownik projektu.
Udokumentowanie zmiany w Dzienniku zmian.
Kierownik projektu, członek zespołu.
Wyznaczenie osoby do zbadania zmiany.
Czasem zmiany są wynikiem wcześniej przemyślanego wniosku, innym razem po prostu się zdarzają i istnieje potrzeba zarządzania nimi reaktywnie. Zmiany takie powinny być odnotowane w Dzienniku zmian.
Kierownik projektu przydziela zadanie zbadania wpływu zmiany na projekt członkowi zespołu projektowego lub sobie samemu.
249 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3
4
Kierownik projektu, kierownik ze strony klienta.
Obsłużenie niewielkich zmian
Sponsor.
Przekazanie informacji sponsorowi.
Jeśli wpływ na koszty, pracochłonność i czas trwania nie będzie większy od przyjętego progu (powiedzmy poniżej 20 roboczogodzin), a realizacja projektu w dalszym ciągu będzie możliwa zgodnie z wcześniej ustalonymi wskaźnikami dla kosztów, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą zatwierdzić taki wniosek o zmianę samodzielnie.
Wniosek o zmianę zawierający właściwą analizę wpływu na projekt i istniejące alternatywy jest prezentowany sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 3 opisanym powyżej). 5
6
7
Kierownik projektu.
Zapisanie decyzji w Dzienniku zmian.
Kierownik projektu.
Aktualizacja harmonogramu i budżetu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Decyzję sponsora należy odnotować w Dzienniku zmian.
Jeśli wniosek o zmianę zostanie zatwierdzony, należy dodać do harmonogramu i budżetu zadania realizujące tę zmianę. W związku z tym, że nie jest to zmiana zakresu – nie zawsze będzie konieczność wykonywania tego kroku.
Status bieżący zmiany oraz wybrana decyzja powinny zostać zakomunikowane członkom zespołu oraz innym interesariuszom zgodnie z metodami przyjętymi w Planie komunikacji a także udokumentowane w Raporcie o stanie projektu.
250 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1.3 Zarządzanie zmianami / Duże projekty W dużych projektach występuje możliwość pojawienia się trzech rodzajów zmian – zmian zakresu, zmian ogólnych i zmian konfiguracji. Każda z nich mogłaby być opisywana osobnym procesem. Można by także stworzyć jeden proces obsługujący je wszystkie. W tym rozdziale procesy te opisane są oddzielnie. 5.1.3.P1 Kontrola zakresu.
1
2
3
4
5
Osoba
Zarządzanie zmianami zakresu (duże projekty)
Kierownik projektu.
Zidentyfikowanie zgłoszenia zmiany zakresu.
Kierownik projektu.
Sprawdzenie, czy jest to rzeczywista zmiana zakresu.
Kierownik projektu.
Wprowadzenie wniosku o zmianę do Dziennika zmian zakresu.
(Osoba składająca wniosek).
Opisanie wartości biznesowej zmiany.
Kierownik projektu, sponsor.
Określenie wpływu badań nad wnioskiem na projekt.
Potencjalne zmiany zakresu mogą zostać zgłoszone przez różnych interesariuszy, m.in.: zespół projektowy, klientów, sponsorów, etc. Wnioski o taką zmianę powinny zostać dostarczone w formie pisemnej kierownikowi projektu w postaci Formularza zgłoszenia zmiany zakresu lub pocztą elektroniczną.
Kierownik projektu sprawdza, czy wniosek dotyczy w rzeczywistości zmiany zakresu projektu (rozumianej zgodnie z definicją).
Kierownik projektu wprowadza do Dziennika zmian zakresu informację o nowym wniosku i charakterze zmiany w celu śledzenia procesu jej wprowadzania.
Osoba, która składa wniosek o zmianę zakresu powinna uzasadnić jej wartość biznesową dla projektu. Informacja ta będzie niezbędna, aby sponsor mógł podjąć ostateczną decyzję.
Kierownik projektu musi oszacować wpływ podejmowanych działań dotyczących przeanalizowania wniosku o zmianę - na projekt w dziedzinie pracochłonności, kosztów i czasu trwania. Jeśli czas na przeanalizowanie wniosku jest znikomy, kierownik projektu powinien kontynuować pracę. Jeżeli natomiast czas, który należy poświęcić na badanie wpływu zmiany zakresu na projekt, może spowodować opóźnienia w
251 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projekcie (np. przesunięcia terminów oddania przedmiotów dostawy), o tym, czy wniosek powinien zostać poddany badaniu musi zadecydować sponsor. Jeśli sponsor udzieli wstępnej zgody na kontynuację, konieczne może być uaktualnienie harmonogramu i budżetu tak, aby odzwierciedlały czynności związane z badaniem nowej zmiany zakresu. Jeśli sponsor nie wyrazi zgody na badanie wniosku, wtedy sprawę tą należy zamknąć i nadać jej klauzulę: „nie zatwierdzono” w Dzienniku zmian zakresu. 6
7
Kierownik projektu, członek zespołu
Wyznaczenie osoby do zbadania zmiany zakresu.
Kierownik projektu, menedżer ds. klienta.
(Opcjonalnie) Obsłużenie niewielkich zmian
Kierownik projektu przydziela zadanie zbadania wpływu zmiany zakresu na projekt członkowi zespołu lub sobie.
Jeśli wpływ zmiany na koszty, pracochłonność i czas trwania nie będzie większy od przyjętego progu (powiedzmy poniżej 20 roboczogodzin), a realizacja projektu w dalszym ciągu będzie możliwa zgodnie z wcześniej ustalonymi wskaźnikami dla kosztów, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą zatwierdzić taki wniosek o zmianę zakresu samodzielnie. Jest jednak pewien warunek. Sponsor projektu musi wcześniej formalnie udzielić takich uprawnień kierownikowi projektu, ustalając wysokość progów decyzyjnych - zazwyczaj w pieniądzach lub roboczogodzinach oraz ewentualne inne warunki. Celem tego kroku jest zapobieganie wysyłaniu do sponsora wniosków o zatwierdzenie licznych drobnych zmian.
8
Sponsor.
Przekazanie informacji sponsorowi. Wniosek o zmianę zakresu zawierający właściwą analizę wpływu na projekt i istniejące alternatywy jest prezentowany sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 7 opisanym powyżej).
9
10
11
Kierownik projektu.
Zapisanie decyzji w Dzienniku zmian zakresu.
Kierownik projektu.
Zamknięcie formularza Wniosku o zmianę zakresu.
Kierownik
Uzupełnienie harmonogramu i budżetu.
Jeśli sponsor zgodzi się na wnioskowaną zmianę, wybraną decyzję należy wpisać do Dziennika zmian zakresu.
Kierownik projektu powinien uzupełnić Wniosek o zmianę zakresu o wybraną decyzję a następnie zamknąć dokument i złożyć go do akt.
252 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
12
13
projektu.
Jeśli wniosek o zmianę zakresu zostanie zatwierdzony, należy dodać do harmonogramu zadania realizujące zmianę. Jeśli to konieczne, należy uaktualnić także budżet i termin zakończenia projektu.
Kierownik projektu.
Uaktualnienie Definicji projektu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Aktualna Definicja projektu powinna zatwierdzone zmiany zakresu.
zostać
uzupełniona
o
Status bieżący zmiany oraz wybrana decyzja powinny zostać zakomunikowane członkom zespołu oraz innym interesariuszom zgodnie z metodami przyjętymi w Planie komunikacji a także udokumentowane w Raporcie o stanie projektu.
5.1.3.P2 ZMIANA KONFIGURACJI.
Więcej szczegółów na temat tego zagadnienia znajduje się w punkcie 5.1.3.1 Zarządzanie konfiguracją
1
2
3
4
Osoba
Zarządzanie zmianami konfiguracji (duże projekty).
Kierownik projektu.
Zidentyfikowanie zgłoszenia zmiany konfiguracji.
Kierownik projektu.
Sprawdzenie, czy jest to rzeczywista zmiana konfiguracji.
Kierownik projektu.
Wprowadzenie wniosku o zmianę do Dziennika zmian konfiguracji.
(Osoba zgłaszająca wniosek).
Opisanie wartości biznesowej zmiany.
Potencjalne zmiany konfiguracji mogą zostać zgłoszone przez różnych interesariuszy, m.in.: zespół projektowy, klientów, sponsorów, etc. Wnioski o taką zmianę powinny zostać dostarczone w formie pisemnej kierownikowi projektu w postaci Formularza zgłoszenia zmiany konfiguracji lub pocztą elektroniczną.
Kierownik projektu sprawdza, czy wniosek dotyczy w rzeczywistości zmiany konfiguracji projektu (rozumianej zgodnie z definicją).
Kierownik projektu wprowadza do Dziennika zmian konfiguracji informację o nowym wniosku i charakterze zmiany w celu śledzenia procesu jej wprowadzania.
Zdarza się, że zmiany konfiguracji nie są niezbędne, a zgłaszane są z przyczyn pozabiznesowych. Osoba, która składa wniosek o zmianę konfiguracji powinna uzasadnić jej wartość biznesową dla projektu. Informacja ta będzie niezbędna, aby sponsor mógł podjąć ostateczną decyzję.
253 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5
Kierownik projektu, Sponsor.
Określenie wpływu badań nad wnioskiem na projekt. Kierownik projektu musi oszacować wpływ podejmowanych działań dotyczących przeanalizowania wniosku o zmianę - na projekt w dziedzinie pracochłonności, kosztów i czasu trwania. Jeśli czas na przeanalizowanie wniosku jest znikomy, kierownik projektu powinien kontynuować pracę. Niektóre zmiany konfiguracji mogą mieć radykalny wpływ na harmonogram projektu i koszty poprzez konieczność modyfikacji wielu komponentów i/lub aktywów projektu. Jeżeli więc czas, który należy poświęcić na badanie wpływu zmiany konfiguracji na projekt, może spowodować opóźnienia w projekcie (np. przesunięcia terminów oddania przedmiotów dostawy), o tym, czy wniosek powinien zostać poddany badaniu musi zadecydować sponsor. W związku z tym, że nie jest to zmiana zakresu - sponsor może zgodzić się na badanie wniosku ale nie przydzielić na nie dodatkowego czasu czy środków. Jeśli sponsor nie wyrazi zgody na badanie wniosku, wtedy sprawę tą należy zamknąć i nadać jej klauzulę: „nie zatwierdzono” w Dzienniku zmian konfiguracji.
6
7
8
Kierownik projektu, członek zespołu.
Wyznaczenie osoby do zbadania zmiany konfiguracji.
Kierownik projektu, menedżer ds. klienta.
Obsłużenie niewielkich zmian
Sponsor,
Przekazanie informacji sponsorowi.
Kierownik projektu przydziela zadanie zbadania wpływu zmiany konfiguracji na projekt członkowi zespołu lub sobie.
Jeśli wpływ zmiany na koszty, pracochłonność i czas trwania nie będzie większy od przyjętego progu (powiedzmy poniżej 20 roboczogodzin), a realizacja projektu w dalszym ciągu będzie możliwa zgodnie z wcześniej ustalonymi wskaźnikami dla kosztów, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą zatwierdzić taki wniosek o zmianę konfiguracji samodzielnie.
Wniosek o zmianę konfiguracji zawierający właściwą analizę wpływu na projekt i istniejące alternatywy jest prezentowany sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 7 opisanym powyżej). 9
10
Kierownik projektu.
Zapisanie decyzji w Dzienniku zmian konfiguracji.
Kierownik
Zamknięcie formularza Wniosku o zmianę konfiguracji.
Jeśli sponsor zgodzi się na wnioskowaną zmianę, wybraną decyzję należy wpisać do Dziennika zmian konfiguracji.
254 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
11
12
projektu.
Kierownik projektu powinien uzupełnić Wniosek o zmianę konfiguracji o wybraną decyzję a następnie zamknąć dokument i złożyć go do akt.
Kierownik projektu.
Uzupełnienie harmonogramu i budżetu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Jeśli wniosek o zmianę konfiguracji zostanie zatwierdzony, należy dodać do harmonogramu zadania realizujące zmianę. Jeśli to konieczne, należy uaktualnić także budżet i termin zakończenia projektu. W związku z tym, że nie jest to zmiana zakresu – kierownik projektu może nie otrzymać zgody na zwiększenie harmonogramu czy budżetu. Należy to negocjować ze sponsorem uwzględniając charakter zmiany.
Status bieżący zmiany oraz wybrana decyzja powinny zostać zakomunikowane członkom zespołu oraz innym interesariuszom zgodnie z metodami przyjętymi w Planie komunikacji a także udokumentowane w Raporcie o stanie projektu.
5.1.3.P3 Kontrola zmian zintegrowanych.
1
2
3
4
Osoba
Zarządzanie zmianami (duże projekty)
Kierownik projektu.
Zidentyfikowanie zgłoszenia zmiany.
Kierownik projektu.
Sprawdzenie, czy jest to rzeczywista zmiana.
Kierownik projektu.
Wprowadzenie wniosku o zmianę do Dziennika zmian.
(Osoba zgłaszająca wniosek).
Opisanie wartości biznesowej zmiany.
Potencjalne zmiany mogą zostać zgłoszone przez różnych interesariuszy, m.in.: zespół projektowy, klientów, sponsorów, etc. Wnioski o zmianę powinny zostać dostarczone w formie pisemnej kierownikowi projektu w postaci Formularza zgłoszenia zmiany lub pocztą elektroniczną.
Kierownik projektu sprawdza, czy wniosek dotyczy w rzeczywistości zmiany w projekcie.
Kierownik projektu wprowadza do Dziennika zmian informację o nowym wniosku i charakterze zmiany w celu śledzenia procesu jej wprowadzania.
Zdarza się, że zmiany nie są niezbędne, a zgłaszane są z przyczyn pozabiznesowych. Osoba, która składa wniosek o zmianę powinna uzasadnić jej wartość biznesową dla projektu. Informacja ta będzie niezbędna, aby sponsor mógł podjąć ostateczną decyzję.
255 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5
Kierownik projektu, sponsor.
Określenie wpływu badań nad wnioskiem na projekt. Kierownik projektu musi oszacować wpływ podejmowanych działań dotyczących przeanalizowania wniosku o zmianę - na projekt w dziedzinie pracochłonności, kosztów i czasu trwania. Jeśli czas na przeanalizowanie wniosku jest znikomy, kierownik projektu powinien kontynuować pracę. Jeżeli czas, który należy poświęcić na badanie wpływu zmiany na projekt, może spowodować opóźnienia w projekcie (np. przesunięcia terminów oddania przedmiotów dostawy), o tym, czy wniosek powinien zostać poddany badaniu musi zadecydować sponsor. W związku z tym, że nie jest to zmiana zakresu - sponsor może zgodzić się na badanie wniosku ale nie przydzielić na nie dodatkowego czasu czy środków. Jeśli sponsor nie wyrazi zgody na badanie wniosku, wtedy sprawę tą należy zamknąć i nadać jej klauzulę: „nie zatwierdzono” w Dzienniku zmian.
6
7
8
Kierownik projektu, członek zespołu.
Wyznaczenie osoby do zbadania zmiany.
Kierownik projektu, menedżer ds. klienta.
Obsłużenie niewielkich zmian
Sponsor.
Przekazanie informacji sponsorowi.
Kierownik projektu przydziela zadanie zbadania wpływu zmiany na projekt członkowi zespołu lub sobie.
Jeśli wpływ zmiany na koszty, pracochłonność i czas trwania nie będzie większy od przyjętego progu (powiedzmy poniżej 20 roboczogodzin), a realizacja projektu w dalszym ciągu będzie możliwa zgodnie z wcześniej ustalonymi wskaźnikami dla kosztów, pracochłonności i czasu trwania, kierownik projektu wspólnie z kierownikiem ze strony klienta mogą zatwierdzić taki wniosek o zmianę konfiguracji samodzielnie.
Wniosek o zmianę zawierający właściwą analizę wpływu na projekt i istniejące alternatywy jest prezentowany sponsorowi projektu do zatwierdzenia (jeśli nie podjęto decyzji w punkcie 7 opisanym powyżej). 9
10
Kierownik projektu.
Zapisanie decyzji w Dzienniku zmian.
Kierownik projektu.
Zamknięcie formularza Wniosku o zmianę.
Jeśli sponsor zgodzi się na wnioskowaną zmianę, wybraną decyzję należy wpisać do Dziennika zmian.
Kierownik projektu powinien uzupełnić Wniosek o zmianę o wybraną decyzję a następnie zamknąć dokument i złożyć go do akt.
256 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
11
12
Kierownik projektu.
Uzupełnienie harmonogramu i budżetu.
Kierownik projektu.
Uzupełnienie Raportu o stanie projektu.
Jeśli wniosek o zmianę zostanie zatwierdzony, należy dodać do harmonogramu zadania realizujące zmianę. Jeśli to konieczne, należy uaktualnić także budżet i termin zakończenia projektu. W związku z tym, że nie jest to zmiana zakresu – kierownik projektu może nie otrzymać zgody na zwiększenie harmonogramu czy budżetu. Należy to negocjować ze sponsorem uwzględniając charakter zmiany.
Status bieżący zmiany oraz wybrana decyzja powinny zostać zakomunikowane członkom zespołu oraz innym interesariuszom zgodnie z metodami przyjętymi w Planie komunikacji a także udokumentowane w Raporcie o stanie projektu.
257 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.1.3.1 Zarządzanie zmianami / Zarządzanie konfiguracją. 5.1.3.1.P1 Zarządzanie konfiguracją to termin na określenie identyfikacji, śledzenia oraz zarządzania wszystkimi aktywami projektu. (Terminu tego można też używać w odniesieniu do organizacji, ale w tej publikacji będzie on odnosić się wyłącznie do projektów.) Zarządzanie zmianami zakresu na przykład można by traktować jako jeden z komponentów całego procesu zarządzania konfiguracją. Z powodów opisanych poniżej, w metodyce TenStep potraktowano ten proces jako dodatkowy. W wielu projektach nie podejmuje się działań o charakterze związanym z konfiguracją, np. śledzenie historii aktywów fizycznych typu sprzęt, zapasy, surowce. Jeżeli w ogóle należy je ewidencjonować, dzieje się to na poziomie całej firmy lub danego działu funkcjonalnego. Na przykład, zarządzanie i ewidencjonowanie komputerami. Kierownik projektu w konkretnym projekcie może potrzebować komputerów osobistych dla swojego zespołu, ale nie musi on śledzić ani ewidencjonować tych aktywów. Jeśli w projekcie przywiązuje się wagę do ewidencjonowania aktywów, jest to zazwyczaj w zakresie obowiązków specjalistów w zespole, rzadko kierownika projektu. Na przykład, jeśli projekt ma na celu zbudowanie samolotu, ewidencjonowanie materiałów jest niezbędne. Zazwyczaj zadanie to przydziela się jednak grupie specjalistów. Jeśli projekt dotyczy rozwoju oprogramowania komputerowego, trzeba będzie ewidencjonować jego kod źródłowy. Są jednak specjalizowane narzędzia IT do kontroli zmian oprogramowania, które będą używane do zarządzania tymi aktywami. Nie wydaje się więc, żeby było to kluczowe zagadnienie w zarządzaniu projektem. Pomimo tego, co zostało tu napisane, niektóre duże projekty muszą zarządzać aktywami. Jeśli tak jest, kierownik projektu może używać technik z rozdziału 5.2 Zarządzanie zakresem / Techniki. Oto komponenty procesu zarządzania konfiguracją: Planowanie. Należy zaplanować z wyprzedzeniem wytworzenie procesów, procedur, narzędzi, dokumentów i baz danych niezbędnych do zarządzania aktywami projektu. Koniecznym może być także ustalenie, które aktywa są ważne, jak je będą definiowane, dzielone na kategorie, klasyfikowane, zliczane, raportowane etc. Wyniki takiego planowania z wyprzedzeniem powinny zostać zapisane w Planie zarządzania konfiguracją. Rzeczy, które będziesz śledzić w ramach zarządzania konfiguracją w modelu CMMI nazywane są „elementami konfiguracji”. Planowanie jest niezwykle istotną częścią procesu zarządzania konfiguracją, ponieważ jest wiele sposobów, na które można by zdefiniować elementy konfiguracji. Definicja taka może zawierać tylko charakterystykę lub informacje o aktywach, a nie same aktywa. Z drugiej strony, elementy konfiguracji mogą być interpretowane dość szeroko, obejmując np.:
Dokumentację i wszystkie przedmioty dostawy zarządzania projektem. Opisy przedmiotów dostaw i formatki. 258 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Wymagania biznesowe, w którym to przypadku proces zarządzania konfiguracją będzie także zawierał proces zarządzania zamianą zakresu.
Elementy wyglądu. Kod źródłowy - w tym przypadku proces zarządzania konfiguracją będzie zawierał proces zarządzania zmianami oprogramowania.
Scenariusze testów, plany testów, przypadki testowe etc. Sprzęt komputerowy i oprogramowanie. Ostateczne produkty w postaci oprogramowania. Inne aktywa materialne projektu, a w tym: meble, zapasy, maszyny etc.
Częścią procesu planowania powinno być nadanie numerów ewidencyjnych każdemu rodzajowi elementu konfiguracji. Śledzenie. Ważne jest, aby już na początku projektu wiedzieć, jakie jest „saldo otwarcia” elementów konfiguracji. W wielu przypadkach elementy konfiguracji mogą jeszcze nie istnieć w tym momencie. W innych, takich jak aktywa materialne, projekt może jakieś posiadać. Celem procesu śledzenia jest zapewnienie, że w trakcie projektu będzie możliwe zidentyfikowanie wszystkich zmian w konfiguracji. Niezbędne będą procesy i systemy pozwalające określić, kiedy dane aktywa są przydzielone do projektu, gdzie jest ich miejsce w projekcie, co się z nimi stanie, kto jest za nie odpowiedzialny i jak są one zwalniane. Ponieważ każdy projekt ma ściśle określony początek i koniec – generalnie wszystkie aktywa muszą gdzieś się znaleźć po jego zakończeniu. Mogą stanowić one część finalnego przedmiotu dostawy, mogą być przekazane do odpowiedniej jednostki w organizacji, mogą zostać zezłomowane, wyrzucone etc. Należy szczegółowo przeanalizować każdy główny przedmiot dostawy i wskazać skąd pochodzą wszystkie jego elementy i gdzie się będą znajdować po zakończeniu projektu. Zarządzanie. Zarządzanie aktywami oznacza zapewnienie ich bezpieczeństwa, ochrony i właściwego użycia. Oto przykład: Nie jest dobrze jeśli system pokazuje, że na początku projektu zakupiono drogie aktywa, które nie były wtedy potrzebne i do tego momentu nikt ich nie używa. Ponadto system ewidencji może wskazać, że te drogie elementy znajdują się w niestrzeżonym magazynie. Czy to dobre miejsce dla nich? Zarządzanie konfiguracją wiąże się z nabywaniem we właściwym czasie tylko koniecznych aktywów i magazynowaniem ich w odpowiednim miejscu. Raportowanie. Kierownik projektu musi być w stanie zaraportować stan zarządzanych przez niego aktywów, w szczególności ich rodzaj, ilość, miejsce, a także dane finansowe, które ukazują koszty, budżet, amortyzację etc. Audyt. Audyt polega na potwierdzeniu faktycznego stanu elementów konfiguracji (jakiekolwiek one są), ich zgodności ze stanem oczekiwanym Wiele projektów miewa poważne problemy, kiedy zapomina o ewidencji aktywów materialnych (np.: materiałów, zapasów, kodu i innych elementach konfiguracji) oraz jeśli charakterystyka przedmiotów dostawy różni się od pierwotnych oczekiwań. Proces audytu stosuje się, aby potwierdzić, że elementy konfiguracji są zgodne z oczekiwaniami. Oczekiwania te oparte są na pierwotnym „bilansie otwarcia” z naniesionymi wszystkimi zmianami jakie przeprowadzono do tej pory. Dla aktywów 259 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
materialnych będzie to oznaczać, że inwentaryzacja potwierdzi liczbę posiadanych aktywów. Jeśli elementy konfiguracji są opisami czy też innymi danymi, audyt oznaczać będzie sprawdzenie, czy zgadzają się one ze sposobem wytwarzania i bieżącym stanem przedmiotów dostawy. Jeżeli wynik audytu będzie różnić się od oczekiwanych rezultatów, oznacza to, że proces śledzenia konfiguracji jest nieodpowiedni i należy go usprawnić. Konieczne będzie określenie, w jaki sposób konfiguracja może się zmieniać w czasie i sprawdzić, czy poprawiony proces umożliwia potwierdzenie tych zmian. Audyty konfiguracji są trudne i kosztowne w sensie zasobów i czasu. Pomimo to, są one konieczne, aby ostateczne rozwiązania były kompletne i poprawne. Także aby sprawdzić, czy wszystkie zaangażowane aktywa konfiguracji były konieczne i służyły osiągnięciu oczekiwanych rezultatów projektu. Istotne jest także, aby, co jakiś czas, sprawdzana była integralność samego procesu zarządzania konfiguracją. Można to wykonać np. poprzez kontrolę stanu bieżącego elementów konfiguracji - fizyczne zliczenie tych elementów i zestawienie ich z oczekiwanymi wynikami z systemu zarządzania konfiguracją. Warto także audytować proces zmiany konfiguracji w celu sprawdzenia, czy jest on prawidłowo realizowany. Jeśli w projekcie stosowane jest zarządzanie konfiguracją, warto wyznaczyć jedną osobę jako menedżera konfiguracji. Może być to zajęcie realizowane w niepełnym wymiarze godzin, w zależności od tego, jak dużo aktywów jest objętych ewidencją i zarządzaniem. Osoba taka będzie odpowiedzialna za cały proces ze szczególnym uwzględnieniem planowania, zarządzania i audytu. Jeśli projekt jest odpowiednio duży, można także wyznaczyć osobnego archiwistę ds. konfiguracji. Będzie to stanowisko administracyjne obsługujące sprawy formalne niezbędne w procesie śledzenia i raportowania. W zależności od wielkości projektu niezbędne może okazać się utworzenie specjalnej Rady ds. konfiguracji składającej się z menedżerów wyższego i średniego szczebla. Rada ta będzie wtedy zatwierdzała całościowy Plan konfiguracji, poszczególne elementy konfiguracji a nawet pewne duże zmiany wprowadzane zgodnie z procesem zarządzania konfiguracją. Oczywiście jeśli projekt (lub program) jest wystarczająco duży (np.: budowa samolotu), możliwe, że potrzebny będzie cały departament który będzie się tym zajmował, np. pod nadzorem Pionu zakupów/zaopatrzenia.
260 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.2 Zarządzanie zmianami / Techniki 5.2.P1 Proaktywne zarządzanie małymi zmianami. Wydaje się chyba oczywistym, że proces zmiany zakresu powinien być uruchamiany w celu przeprowadzenia dużych zmian w projekcie. Nie powinno także dziwić, że w przypadku małych zmian możne występować opór wykonawców lub klientów wobec sformalizowanego zarządzania zmianami zakresu. Mogą oni uważać to za zbędny narzut administracyjny. I mogą mieć rację. Są trzy alternatywne techniki, które można zastosować w przypadku niewielkich modyfikacji. Żadna z nich jednak nie powoduje, że nie zarządzasz lub nie kontrolujesz zmian zakresu. Są to po prostu techniki dodatkowe, które mogą być przydatne w zarządzaniu małymi zmianami zakresu. Jeśli żadna z nich nie okaże się właściwa, kierownik projektu powinien zastosować normalny proces zarządzania zmianami zakresu. 5.2.P2 Grupowanie wniosków o małe zmiany. Nie zawsze jest rzeczą praktyczną zwracanie się do sponsora z prośbą o zatwierdzenie małych zmian zakresu projektu, za każdym razem, kiedy pojawi się taka potrzeba. Zespół projektowy zazwyczaj nie ma codziennego kontaktu ze sponsorem. Trudno także byłoby wymagać od sponsora, żeby zajmował się niewielkimi w końcu modyfikacjami na każde wezwanie. Lepszym i bardziej praktycznym rozwiązaniem jest zebranie wielu małych zmian w zestaw. Polegać to może na tym, że małe zmiany zakresu będą identyfikowane, a ich wartość biznesowa i wpływ na projekt oceniane. Następnie, kiedy wartości te osiągną pewien założony próg, należy je łącznie przedstawić sponsorowi. Zamiast spotykać się z nim dziesięć razy, odbędzie się tylko jedno, może nieco dłuższe spotkanie. Często na spotkaniu takim niezbędna okaże się obecność przedstawiciela klienta. Dyskutuje się wtedy na temat wszystkich zmian lub tylko o tych najważniejszych w zestawie. Chociaż mówimy tu o małych zmianach, wszystkie one przeprowadzane są zgodnie z procesem zarządzania zmianami zakresu. W przeciwnym wypadku pojawiło by się bardzo groźne zjawisko – niekontrolowane choć niewielkie wyjścia poza zakres – tzw. pełzanie zakresu. Zaletą zatwierdzania małych zmian przez sponsora jest to, że jeśli już zostaną podjęte odpowiednie decyzje - powinien on jednocześnie przydzielić dodatkowy budżet i czas na wykonanie tych zadań. 5.2.P3 Swoboda menedżera projektu. Z praktycznego punktu widzenia rozsądnym może być pozostawienie pewnej swobody menedżerowi projektu i menedżerowi ds. klienta w sprawie zatwierdzania zmian zakresu w obrębie ustalonego progu pracochłonności i kosztów. Uprawnienia do takiego postępowania nie są jednak automatyczne - muszą zostać formalnie udzielone przez sponsora. Dodatkowe założenie, które czyni się w tym wypadku jest takie, że projekt nie jest opóźniony oraz że przeprowadzane zmiany nie spowodują przekroczenia wcześniej ustalonych kosztów lub czasu trwania projektu. Jeśli natomiast zachodzi jakiekolwiek niebezpieczeństwo, że nie będzie można wywiązać się ze zobowiązań określających koszty i długość trwania projektu - nie należy korzystać z tych specjalnych uprawnień – nawet w przypadku wniosku o zmianę jednej roboczogodziny. W takim przypadku należy zatwierdzać zmiany zakresu u sponsora 261 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
pojedynczo lub jako zestaw małych zmian. W przypadku zgody sponsora zwykle zostaną przydzielone także odpowiedni budżet i dodatkowy czas w harmonogramie. 5.2.P4 Budżet awaryjny na zmiany zakresu. W pewnych firmach dość powszechnym rozwiązaniem jest wyznaczanie budżetu awaryjnego na zmiany zakresu projektu, aby w ten sposób poradzić sobie z niewielkimi zmianami. Sponsor może uznać, że pewna ilość zmian zakresu jest nieunikniona i może przyznać kierownikowi projektu jakiś procent całego budżetu projektu na te zmiany np. w wysokości 5% dodane do ogólnego budżetu na zmiany zakresu. Jeśli ogólny budżet wynosił 500 tys. złotych, budżet awaryjny na zmiany zakresu wyniesie 25 tys. złotych. Takie podejścia ma jednak jeden ważny skutek. Będzie to jedyny budżet jaki jest przyznany na niewielkie zmiany zakresu. Klient musi więc tak zarządzać budżetem, żeby zapewnić sobie wprowadzenie wszystkich małych zmian zakresu. Jeśli wykorzysta ten budżet w całości zbyt szybko - nie pozostanie już nic na późniejsze zmiany. To zwykle sprawia, że klient staje się osobą ograniczającą ilość zmian tak, aby zapewnić środki na zatwierdzenie tych najważniejszych. Z budżetu awaryjnego korzysta się przy zmianach nie przekraczających pewnego progu roboczogodzin i kosztów. Wnioski o większe zmiany mogą być zgłaszane, ale będą one podlegać normalnemu procesowi zarządzania zmianami zakresu i będą zatwierdzane przez sponsora. 5.2.P5 Niedozwolone używanie rezerw szacunkowych. Jednym z kroków w procesie estymacji (faza definiowania projektu) jest dodanie dodatkowych roboczogodzin na nieprzewidziane wypadki w taki sposób, aby odzwierciedlały one poziom niepewności związany z estymacją. Wielkość taką nazywamy rezerwą szacunkową. Oto przykład: Jeśli pracochłonność projektu oszacowano na 5.000 rg, można dodać 500 godzin rezerwy szacunkowej wynikającej z faktu, że estymacje (5.000 rg) wykonano z 90% dokładnością – a więc istnieje 10%-wa niepewność (+/- 500 rg) co do faktycznej pracochłonności. Kiedy rezerwa taka zostanie zatwierdzona, mogą pojawić się naciski na kierownika projektu, żeby użył tej rezerwy na dodatkowe zmiany zakresu. Klient może zapytać: „Dlaczego musimy odwoływać się do procesu zarządzania zmianami zakresu na to zwiększenie długości zadania o 100 godzin? Mamy przecież w naszych kalkulacjach uwzględnione 500 godzin na nieprzewidziane sytuacje.” Kierownik projektu musi oprzeć się tej pokusie i presji. Celem rezerwy szacunkowej jest odzwierciedlanie niepewności w kalkulacjach. Będzie prawdopodobnie wiele okazji do skorzystania z niej, kiedy zaplanowane zadania zaczną zajmować więcej czasu, niż zaplanowano. A zatem nie należy korzystać z rezerwy szacunkowej na wykonywanie dodatkowych zadań (spoza zakresu!). Jeśli estymacje projektu okażą się dokładne, należy zwrócić klientowi nadwyżkę w postaci rezerwy szacunkowej lub uznać ją za dodatkowy zysk w przypadku klientów zewnętrznych. 5.2.P6 WSTRZYMANIE WNIOSKÓW O ZMIANY ZAKRESU W KOOCOWEJ FAZIE PROJEKTU.
Czy, jeśli tylko wnioski o zmiany zakresu obsługiwane są starannie, klient zawsze ma prawo do wnioskowania o zmiany w trakcie trwania projektu? Zwykle im bliżej końca, tym więcej czasu i nakładów pochłaniają takie zmiany. Może się jednak wydawać, że skoro sponsor zatwierdza zwiększony budżet i czas trwania projektu, klient powinien mieć prawo to zrobić.
262 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jest to prawdą tylko do pewnego momentu. Przychodzi w końcu taka chwila, w której nie ma już sensu wprowadzanie następnych zmian i przyjmowanie dodatkowych wniosków. Jest to pora do formalnego zamrożenia zmian. Nowe zmiany są nie tylko kosztowne do przeprowadzenia ale i niepotrzebnie rozpraszają zespół projektowy. W projektach IT zmiany zamraża się z reguły po otrzymaniu akceptacji testów od użytkownika (po fazie testów), i kiedy zespół jest już gotowy do implementacji rozwiązania (faza realizacji). W tym momencie projektu zespół jest już skupiony na wprowadzaniu w życie opracowanych rozwiązań. Zdarza się, że pracuje w nadgodzinach. Kierownik projektu może teraz zajmować się „mikrozarządzaniem” projektem. Ma to na celu dopracowanie wszystkich, nawet najmniejszych szczegółów w terminie. Na tym etapie projektu zmiany zakresu są nie tylko kosztowne, ale bardzo przeszkadzają. Zespół może stracić koncentrację i poczuć psychiczne wypalenie. Lepszym podejściem jest wstrzymanie tych zmian i zapisanie ich w specjalnym rejestrze - do realizacji na później (tzw. backlog). Można je wprowadzić jako rozszerzenie projektu, kiedy już pierwotne rozwiązania będą zrealizowane i stabilne. Dotyczy to oczywiście wniosków o zmiany zakresu a nie błędów. Jeśli użytkownicy konstruowanych przedmiotów dostaw wykryją pewne wady lub błędy w fazie testowania – z reguły zajdzie konieczność ich poprawy przed przystąpieniem do kolejnej fazy. Jeśli ustalono datę, od której zamraża się wszelkie zmiany, zespół może się skupić na wprowadzaniu wypracowanych rozwiązań. Oczywiście, jeśli zdarzy się absolutna potrzeba wprowadzenia jakiejś zmiany, trzeba będzie ją przeprowadzić. Mimo to w większości projektów ustalenie daty wstrzymania zmian, wyeliminuje potrzebę dodatkowych modyfikacji. 5.2.P7 Tylko sponsor zatwierdza zmiany. Typowym problemem w realizacji projektów jest nie zrozumienie roli sponsora, klienta i użytkowników końcowych w procesie zarządzania zmianami. Ogólnie rzecz ujmując, sponsor jest osobą finansującą projekt. W szczególnych przypadkach może też być jednocześnie klientem projektu. Sponsor jest zazwyczaj osobą umieszczoną wysoko w hierarchii firmy i niełatwo dostępną na co dzień. Zwykle wyznacza wtedy kogoś do podejmowania bieżących decyzji (tzw. sponsor wykonawczy). Często zdarza się, że ludzie, z którymi zespół projektowy najczęściej współpracuje to użytkownicy końcowi przedmiotów dostaw. To właśnie ci ludzie zgłaszają z reguły wnioski o zmiany, znając na bieżąco status wytwarzanych przedmiotów dostawy. Nie ma jednak znaczenia, czy i jak jakaś zmiana jest istotna dla odbiorcy końcowego. To nie oni podejmują decyzje o zmianach zakresu projektu, więc jednocześnie nie są władni uzgadniać czy zgadzać się na takie zmiany. We właściwym zarządzaniu zmianami zakresu tylko sponsor (lub wyznaczona przez niego osoba) może zatwierdzać zmiany. Użytkownicy końcowi mogą oczywiście o nie wnioskować ale nie mogą ich zatwierdzać. Nie mogą oni też przyznawać dodatkowych środków finansowych na wprowadzenie tych zmian i nie mogą stwierdzać czy wpływ tych zmian na projekt jest akceptowalny. Jeśli zmiana jest istotna dla sponsora, zatwierdzi ją razem z odpowiednimi modyfikacjami w budżecie i czasie trwania projektu. Jeśli zmiana nie jest dla niego wystarczająco ważna, nie zostanie zatwierdzona. Ale to sponsor podejmie decyzję, nie kierownik projektu, nie menedżer ze strony klienta, nie zespół projektowy i nie użytkownicy końcowi.
263 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.2.P8 Zgoda na zmianę a orientacja na klienta. Bywa, że kierownik projektu i zespół projektowy sądzą, że jest wyrazem orientacji na klienta samodzielne akceptowanie zmian zakresu projektu, jeśli tylko nie powodują one naruszenia oryginalnych ram projektu i ustaleń początkowych. Jeśli w takim przypadku okaże się, że projekt zaczyna mieć opóźnienia i wykraczać poza budżet, nie wystarczy usprawiedliwienie, że dodatkowe działania zostały włączone do projektu ze względu na klienta. Sponsor projektu i inni menedżerowie nie będą słuchali takich wyjaśnień. Zostanie to potraktowane jako niepowodzenie projektu z uwagi na przekroczenie uzgodnionego budżetu i czasu trwania projektu. Sponsor jest dla kierownika projektu głównym reprezentantem klienta. Orientacją na klienta jest zatem pozwolenie sponsorowi (lub osobie przez niego wyznaczonej) na podejmowanie decyzji w sprawie zamiany zakresu projektu. Jeśli zrobi to zespół projektowy lub kierownik projektu, z perspektywy sponsora nie będzie to oznaczało „nastawienia na dobro klienta”. 5.2.P9 Odroczone zyski jako koszty zmiany zakresu. Sponsor projektu nie powinien podjąć decyzji o zmianie zakresu bez uprzedniego zrozumienia wartości biznesowej zmiany i jej wpływu na projekt. Zazwyczaj kierownik projektu dostarcza mu informacji na ten temat w dziedzinie pracochłonności, koszów i czasu trwania projektu. Powszechną słabością w określaniu wpływu w ten sposób jest pomijanie faktu odroczonych zysków z projektu. Innymi słowy - projekt przyniesie firmie konkretne korzyści. Zyski pojawiają się zazwyczaj wkrótce po jego zakończeniu. Jeśli wniosek o zmianę zakresu oznacza opóźnienie projektu to koszty tej zmiany zakresu powinny obejmować nie tylko same koszty faktycznych zmian ale również koszty opóźnionych zysków. Oto przykład. Załóżmy, że koszt projektu to suma 100.000 złotych. Zysk finansowy po zakończeniu projektu to 5.000 złotych miesięcznie w postaci zwiększonych przychodów (lub zmniejszonych kosztów firmy). W trakcie pracy nad projektem klient występuje z wnioskiem o zmianę, która będzie kosztowała 5.000 złotych i wydłuży czas trwania projektu o jeden miesiąc. Zapłata klienta za tę zmianę będzie rozłożona na 5 miesięcznych rat po 1.000 złotych, po projekcie. Można udać się do sponsora z wnioskiem o zmianę stwierdzając, że jej koszt wynosi 5.000 złotych, ale zostanie zapłacona przez klienta w ciągu pięciu miesięcy. To, czego tu brakuje, to koszty związane z opóźnieniem w realizacji projektu o jeden miesiąc. W tym przypadku to miesięczne opóźnienie kosztuje firmę 5.000 złotych w odroczonych zyskach, co daje łączny koszt tej zmiany zakresu projektu równy 10.000 złotych. Sponsor może się zgodzić na tą zmianę lub nie. Dlatego przedstawiając mu wpływ zmiany na projekt kierownik projektu powinien pokazać także utratę lub odsunięcie w czasie korzyści związanych z opóźnieniem. 5.2.P10 Zajęty sponsor zazwyczaj mówi „nie‖. Dla kierownika projektu jedną z trudniejszych kwestii związaną z zachowaniem dyscypliny co do konieczności zatwierdzania zmian zakresu przez sponsora, jest przesądzenie, że sponsor, o ile zmiana nie jest wyjątkowo ważna, mówi „nie”. Sponsor to zazwyczaj osoba wysoko umocowana w hierarchii firmy i zazwyczaj niechętnie słuchająca o drobnych modyfikacjach. Sponsor często chce tylko, aby zrealizowano projekt zgodnie z pierwotnymi ustaleniami co do kosztów, pracochłonności i czasu jego 264 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
trwania. Kierownikowi projektu może być trudno czasem odmówić klientowi - sponsor natomiast nie będzie miał problemów z mówieniem ”nie”, szczególnie pracownikom własnej firmy. 5.2.P11 Każdy jest odpowiedzialny za proces zarządzania zakresem. Często procesy zarządzania zmianami działają dobrze na poziomie kierownika projektu ale problem z nimi pojawia się na poziomie członków zespołu. Jeśli kierownik projektu sumiennie dopilnowuje przestrzegania zasad zmiany zakresu bywa, że klient zwraca się bezpośrednio do zespołu w sprawie zmian. Oto przykład: Wysłano do klienta uzgodniony wcześniej raport. Niedługo potem klient żąda od członka zespołu drugiego raportu, który uściślałby pewne zagadnienia i dawał, z bieżącej perspektywy, lepszy obraz opisywanej sytuacji. Członek zespołu może wyrazić zgodę na takie działanie (wykazując, jak najbardziej, „nastawienie na potrzeby klienta”). Efektem jego pracy jest drugi raport zadowalający klienta. Kosztem całej operacji jest poświęcony czasu i pewne zasoby. Zarówno praca członka zespołu w czasie kiedy pisał raport jak i zasoby, których użył, mogłyby zostać wykorzystane do czynności bardziej priorytetowych z punktu widzenia projektu i nie być zaangażowane w czynności spoza ustalonego zakresu. Wniosek z tego jest taki, że wszyscy pracownicy projektu powinni być zobligowani do przestrzegania procesu zarządzania zmianą zakresu. Członkowie zespołu muszą znać ten proces i rozumieć jego znaczenie dla powodzenia projektu. To samo dotyczy także klienta. Mylnym jest pogląd, że te procedury te powinny być w sferze zainteresowania wyłącznie kierownika projektu i sponsora. Warto się więc upewnić czy zostały one zakomunikowane całemu zespołowi. Kiedy klienci żądają zmian zakresu bezpośrednio od członków zespołu należy zwróć na to uwagę menedżerowi ze strony klienta lub sponsorowi. Kiedy członkowie zespołu podejmują działania spoza zakresu projektu – trzeba się tym zająć niezwłocznie. Pierwszy taki przypadek może być uważany za szkoleniowy, następne będą traktowane jako problemy z wydajnością. 5.2.P12 Komitet Kontroli Zmian w dużych projektach. W przypadku bardzo dużych projektów sponsor projektu może nie czuć się komfortowo, podejmując samodzielnie wszystkie decyzje zmian zakresu. Zwłaszcza, jeśli ich efekt będzie miał wpływ także na inne jednostki organizacyjne. Podobnie może być w przypadku wielu firm współpracujących przy realizacji jednego projektu i partycypujących w kosztach. Firmy te mogą chcieć mieć coś do powiedzenia przy ocenianiu wniosków o zmiany zakresu projektu. W takim przypadku może być potrzebna grupa ludzi, która będzie zajmować się zatwierdzaniem zmian zakresu. Popularną nazwą takiej grupy jest Komitet Kontroli Zmian. Jeśli takie ciało istnieje, może to nieco komplikować pracę kierownika projektu. Jednak ogólny proces zarządzania zmianami zakresu nie musi się dramatycznie zmieniać. W dalszym ciągu istnieć będzie formularz zgłoszenia zmiany zakresu, zespół projektowy będzie określać wpływ zmian na projekt i koszty etc. Komitet musi rozważyć ten wpływ, jego wartość dla projektu, czas wprowadzania zmiany etc., a potem podjąć decyzję o zatwierdzeniu lub nie takich zmian. Procedury zmian zakresu muszą być w nieco bardziej szczegółowe i brać pod uwagę także pracę Komitetu. Trzeba sprecyzować kto będzie zasiadał w Komitecie, jak 265 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
często odbywać się będą spotkania, jak członkowie będą powiadamiani w sytuacjach kryzysowych, w jaki sposób będą oni podejmować decyzje (jednomyślnie, większością głosów, anonimowo etc.) i w jaki sposób będą wynagradzani za dodatkową pracę, etc. 5.2.P13 Rejestr nie wprowadzonych zmian. Sponsor może nie zatwierdzić pewnych wnioskowanych zmian zakresu w trakcie trwania projektu. Mogą one jednak być wykonane w późniejszym terminie. Tego rodzaju wnioski o zmiany powinny zostać odnotowywane w rejestrze zmian nie wprowadzonych (tzw. backlog). Po ukończeniu projektu możliwe jest przekazanie tych wniosków organizacji zarządzającej (lub wspierającej) przedmioty dostaw po projekcie. Może pojawić się także szansa na rozszerzenie pierwotnego projektu lub uruchomienie kolejnego. Ale nawet wtedy zmiany te mogą zostać zrealizowane tylko pod warunkiem, że zostaną formalnie zaakceptowane i że przydzielone zostaną fundusze na ich realizację.
266 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5.3 Zarządzanie zmianami / Podsumowanie 5.3.P1 Przedmioty dostawy Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Formularz wniosku o zmianę zakresu. Dziennik zmian zakresu. 5.3.P2 Harmonogram - czynności Rozmiar Niezbędne informacje Mały
W małych projektach nie jest konieczne planowanie działań związanych z zarządzaniem zmianami zakresu. W szczególnych przypadkach można stosować czynności przeznaczone dla większych projektów. czynność
Średni
pracochłonność uwagi
Sprawdzenie statusu zmian 1-2 godziny zakresu.
Co tydzień. Czynność przypisana zawsze do kierownika projektu. Służy sprawdzeniu, czy zmiany zakresu są obsługiwane właściwie oraz czy Dziennik zmian zakresu jest systematycznie uzupełniany.
Analiza wniosków o zmiany.
Należy dodać do harmonogramu zadanie dla każdej zmiany zakresu, która została przyporządkowana do przeanalizowania członkowi zespołu.
otwarte
Rozpatrywanie wniosków o otwarte zmiany. Czynność
Duży
Sprawdzenie statusu zmian zakresu.
Jeśli rozpatrywanie wniosków o zmiany wymaga wykonania dodatkowych zadań, powinny one zostać dodane do harmonogramu.
pracochłonność uwagi
1-2 godziny
Analiza wniosków o otwarte
Co tydzień. Czynność przypisana zawsze do kierownika projektu. Służy sprawdzeniu, czy zmiany zakresu są obsługiwane właściwie oraz czy Dziennik zmian zakresu jest systematycznie uzupełniany. Należy dodać do harmonogramu
267 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zadanie dla każdej zmiany zakresu, która została przyporządkowana do przeanalizowania członkowi zespołu.
zmiany.
Rozpatrywanie otwarte wniosków o zmiany.
Jeśli rozpatrywanie wniosków o zmiany wymaga wykonania dodatkowych zadań, powinny one zostać dodane do harmonogramu.
Uaktualnienie Definicji projektu.
Należy dodać zadanie do harmonogramu polegające na uaktualnieniu Definicji projektu po to, by odzwierciedlała wszystkie główne zatwierdzone zmiany zakresu lub jeśli kilka mniejszych zatwierdzonych zmian sprawia, że sekcja zakresu bieżącej Definicji projektu jest nieaktualna.
otwarte
268 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 6 Zarządzanie komunikacją
269 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.0 Zarządzanie komunikacją 6.0.P1 Właściwa komunikacja podczas projektu jest krytycznym czynnikiem wpływającym na jego końcowy sukces. Pozwala na systematyczne zarządzanie oczekiwaniami sponsora i interesariuszy. A jeśli osoby te są właściwie poinformowane co do postępów projektu, istnieje mniejsze prawdopodobieństwo pojawienia się problemów związanych z różnymi oczekiwaniami. W wielu przypadkach pojawiające się konflikty nie są związane z faktycznymi problemami, ale z faktem, że klient czy kierownik zostali zaskoczeni. Wszystkie projekty powinny informować o swoim statusie poprzez raporty zespołów projektowych do kierowników projektów oraz raporty kierowników do sponsorów i interesariuszy. Dwa typowe sposoby informowania o statusie to: spotkania statusowe oraz raporty stanu projektu. Duże projekty lub projekty związane ze zmianą kultury organizacyjnej muszą być zaawansowane pod względem sposobów i stylu komunikowania się z różnymi interesariuszami. To skomplikowane, wielopłaszczyznowe podejście zostało zawarte w Planie Komunikacji. 6.1 Zarządzenie komunikacją / Proces 6.2 Zarządzenie komunikacją / Techniki 6.3 Zarządzenie komunikacją / Podsumowanie
270 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1 Zarządzanie komunikacją / Proces 6.1.P1 W niniejszym rozdziale zostały opisane procesy używane do zarządzania komunikacją. Mogą one być odpowiednio modyfikowane do potrzeb konkretnego projektu, a następnie włączane do Planu Zarządzania Projektem (stworzonym w procesie 1.0 Definiowanie Projektu). Procesy używane do komunikacji różnią się w zależności od rozmiaru projektu. Małe projekty stosują zazwyczaj bardzo proste środki oraz drogi komunikacji. Średnie projekty, bardziej złożone, prawdopodobnie będą wykorzystywać Plan Komunikacji. Średnie projekty mogą również być na tyle duże, aby wykorzystywać niektóre dobre praktyki zarządzania dokumentami. Duże przedsięwzięcia wymagają kompletnego Planu komunikacji aby w pełni zapewnić proaktywne i wielopłaszczyznowe komunikowanie się. Dodatkowo, duże projekty potrzebują często złożonych technik zarządzania dokumentacją. 6.1.1 Zarządzanie komunikacją. Drobne projekty 6.1.2 Zarządzanie komunikacją. Średnie projekty
6.1.2.1 Zarządzanie dokumentacją. Podstawy
6.1.3 Duże projekty
6.1.3.1 Zarządzanie dokumentacją. Zaawansowane
271 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.1 Zarządzanie komunikacją / Małe projekty 6.1.1.P1 Małe projekty Małe projekty nie potrzebują zazwyczaj niczego innego jak tylko prostego raportu o swoim stanie. Jeśli kierownik projektu wykonuje jakieś bezpośrednie zadania w projekcie, będzie miał bardzo dobry ogląd sytuacji. Jednakże sponsorzy i inni interesariusze będą potrzebowali bieżących uaktualnień statusu. Jeśli kierownik projektu nie pracuje bezpośrednio przy projekcie (np. ma wiele projektów którymi zarządza), może uruchomić proces formalnego raportowania o stanie ze strony zespołu projektowego. Sam natomiast będzie musiał składać raporty interesariuszom projektu. Typowy proces opisano poniżej.
1
2
Rola
Raportowanie stanu (Małe projekty)
Członkowie zespołu.
Tworzenie raportu stanu dla kierownika projektu.
Kierownik projektu.
Tworzenie raportu stanu dla sponsora i interesariuszy.
Członkowie zespołu projektowego wysyłają co tydzień uaktualnienie stanu kierownikowi projektu.
Ważne jest, aby kierownik projektu używał raportu stanu i innych metod komunikacji do zarządzania oczekiwaniami. Więcej informacji na ten temat znajduje się w rozdziale 6.1.1.1. Kierownik projektu wysyła raport stanu do sponsora projektu i interesariuszy co dwa tygodnie lub co miesiąc. Jeśli projekt jest bardzo mały, sponsor może nie otrzymać żadnych raportów (lub tylko jeden) do czasu zakończenia projektu. Nie daje to sponsorowi czasu na żadną reakcję. W takich przypadkach kierownik projektu powinien raportować co dwa tygodnie lub co tydzień.
3
Kierownik projektu, członkowie zespołu, Klienci.
Plan operacyjny i udział w spotkaniach dotyczących stanu Cały zespół projektowy powinien uczestniczyć w zebraniach statusowych. Spotkania takie powinny koncentrować się wyłącznie na stanie projektu w odniesieniu do harmonogramu, identyfikować bieżące problemy krytyczne, wnioski o zmianę zakresu lub potencjalne ryzyka. Na spotkanie takie może zostać zaproszony klient. Częstotliwość spotkań statusowych zależy od czasu trwania projektu oraz potrzeb informacyjnych. Jeśli projekt trwa trzy tygodnie, zespół może spotykać się dwa razy w tygodniu. Jeśli projekt trwa osiem tygodni, cotygodniowe spotkania prawdopodobnie wystarczą.
272 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.1.1 Zarządzanie Komunikacją / Zarządzanie oczekiwaniami 6.1.1.1.P1 Zarządzanie oczekiwaniami klienta jest ważne we wszystkich projektach, w szczególności, gdy projekt jest duży, widoczny, krytyczny pod względem politycznym i/lub biznesowym. Sprawne zarządzanie oczekiwaniami powoduje, że wszystkie strony są zadowolone z wyników, nawet, jeśli w trakcie trwania projektu następują zmiany lub pojawiają się inne trudne wyzwania. Jeśli oczekiwania nie są właściwie zarządzane, może się zdarzyć, że mimo iż projekt zakończy się o czasie i nie przekroczy budżetu, z perspektywy klienta może się wydawać nieudany. Zarządzanie oczekiwaniami oznacza podejmowanie działań prowadzących do interakcji z klientem. Dzięki niej klient projektu dokładnie wie, co dzieje się w projekcie. Jest informowany o przebiegu projektu oraz wszelkich zmianach w pierwotnych ustaleniach. Życie pokazuje, że zaskoczony klient może mieć fatalny wpływ na przedsięwzięcie. Kierownik projektu powinien ciągle upewniać się, że przedstawiciel klienta jest angażowany, oraz że oczekiwania klienta i kierownika projektu są ciągle spójne. Kwestią zasadniczą staje się więc zapewnienie właściwej komunikacji między stronami. Należy pamiętać, żeby informować klienta o wszystkich ważnych sprawach (dobrych lub złych) zanim dowie się o nich z innego źródła. Opisany niżej proces wskazuje ogólne zasady zarządzania oczekiwaniami:
1
2
Role
Zarządzanie oczekiwaniami
Kierownik projektu, klient.
Ustanowienie porozumienia.
Kierownik projektu
Zarządzanie zmianami.
To najbardziej oczywista i najczęściej pomijana sprawa. Zarządzanie oczekiwaniami będzie trudne lub nawet niemożliwe, jeśli na samym początku nie osiągnięto porozumienia co do istoty tych oczekiwań. Metodyka wskazuje dwa miejsca, gdzie należy to bezwzględnie zrobić. Pierwszym z nich jest Definicja projektu. Jednym z celów jej wytworzenia jest zapewnienie, że obie strony jednakowego rozumieć będą zakres, przedmiot dostawy, założenia, ryzyka, budżet, czas, itp. Inny typowy obszar, w którym trzeba osiągnąć porozumienie to wymagania biznesowe. Sprawne dokumentowanie wymagań biznesowych i doprowadzenie do ich zatwierdzenia przez klienta to duży krok w uzyskiwaniu początkowego porozumienia.
Jeśli nie rozpocząłeś od uzyskania porozumienia, nie masz możliwości efektywnego zarządzania oczekiwaniami. Jednakże, jeśli porozumienie zostało osiągnięte, zmiany powinny być wprowadzane poprzez procedurę zarządzania zmianami. Zapewni to, że klient każdorazowo zatwierdzi proponowane rozwiązania. Pozwoli także na bieżące śledzenie oczekiwań.
273 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3
4
5
6
7
Kierownik projektu
Proaktywne komunikowanie.
Kierownik projektu,
Okresowe sprawdzanie wydajności,
Kierownik projektu,
Pracowanie zgodnie z oczekiwaniami,
Kierownik projektu.
Konieczna zmiana oczekiwań.
Kierownik projektu, Klient.
Wykonanie projektu zgodnie z oczekiwaniami.
Jeśli osiągnięto porozumienie, należy to proaktywnie komunikować z wykorzystaniem Raportów stanu lub zgodnie z szerszym Planem komunikacji (szczególnie, jeśli istnieją trudności w spełnianiu oczekiwań). Sprawi to, że klienta będzie na bieżąco z postępami prac, problemami krytycznymi, ryzykami, itp. Głównym celem tej komunikacji jest unikanie zaskoczenia klienta. Niedopuszczalne jest, aby dowiadywał się on o ważnych sprawach wcześniej, niż dotrze do niego oficjalna wiadomość od projektu.
Kierownik projektu powinien regularnie oceniać oczekiwania. Wykonuje to zazwyczaj w procesie 3.0 Zarządzanie harmonogramem i budżetem. W ten sposób dowiaduje się, czy oczekiwania co do projektu są spełniane. Jeśli nie są, należy podjąć natychmiastowe kroki, aby naprawić sytuację.
Ten punkt również może się wydawać oczywisty. Jeśli już osiągnięto porozumienie, projekt powinien być prowadzony zgodnie z oczekiwaniami. Zdarza się jednak, że ludzie nie wykonują uzgodnionych oczekiwań, nie komunikują się z klientem w celu informowania go o postępach i nie przyznają się do niewypełnienia oczekiwań.
Jeśli okaże się, że pierwotne uzgodnienia nie mogą być wykonane, należy je ponownie negocjować. Proces ten zawiera zebranie faktów związanych z niezdolnością do sprostania oczekiwaniom. Dodatkowo należy określić w jaki sposób wykonać zadanie w sposób jak najbardziej zbliżony do pierwotnych uzgodnień (tak, aby satysfakcjonowało to obie strony) i opisać niezbędne działania. Może to być związane ze zwiększeniem czasu trwania, budżetu lub dostarczaniem czegoś w mniejszych ilościach (lub o gorszych parametrach) niż klient początkowo chciał. Jeśli nowe porozumienie zostanie zatwierdzone przez obie strony – staje się ono jedynym obowiązującym i zastępuje poprzednie. Należy niezwłocznie uwzględnić to w dalszej pracy nad projektem.
Należy przejrzeć wykonaną pracę wraz z klientem pod względem jej zgodności z wcześniejszymi uzgodnieniami. Jeśli nie zostały one w pełni wypełnione, należy przedyskutować, co jeszcze należy zrobić, aby je wykonać.
274 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2 Zarządzanie komunikacją / Średnie projekty Rozpoczęcie projektu 6.1.2.P1 Planowanie komunikacji
1
2
Rola
Zarządzanie komunikacją (Średnie projekty)
Kierownik projektu.
Rozważenie stworzenia Planu komunikacji.
Kierownik projektu.
Rozważenie metod zarządzania dokumentami.
Gdy średnie projekty rozrastają się, może się pojawić konieczność stworzenia bardziej formalnego Planu komunikacji. Będzie to szczególnie ważne, jeśli projekt jest związany ze zmianą kultury organizacyjnej. Jeśli projekt wymaga Planu komunikacji, należy zastosować proces dla dużych projektów.
Gdy średni projekt rozrasta się, kierownik projektu powinien wziąć pod uwagę uruchomienie podstawowych technik zarządzania dokumentami, aby zorganizować i ustrukturyzować dokumentację projektu. Wczesne planowanie w tej dziedzinie może zaoszczędzić wiele problemów w późniejszej pracy nad projektem.
W czasie trwania projektu 6.1.2.P2 Raportowanie 3
4
Kierownik projektu, członkowie zespołu, klient.
Zaplanowanie i udział w spotkaniach statusowych projektu.
Kierownik projektu.
Tworzenie raportu stanu dla sponsora i interesariuszy
Zespół powinien brać udział w spotkaniach statusowych co jeden lub dwa tygodnie. W zależności od potrzeb kierownika projektu, mogą odbywać się osobne spotkania dla zespołu i osobne dla klienta. Powinna istnieć standardowa agenda takich spotkań i nie powinny one trwać dłużej niż jedną godzinę. Zazwyczaj celem takich spotkań jest informowanie o stanie projektu a nie rozwiązywanie jakichkolwiek problemów. (Typowa agenda spotkania jest zamieszczona w sekcji przedmiotów dostaw.)
Ważne jest, aby kierownik projektu używał Raportów stanu i innych metod komunikacji do zarządzania oczekiwaniami. (Więcej informacji o zarządzaniu oczekiwaniami patrz 6.1.1.1.) Kierownik projektu powinien wysyłać Raporty stanu wszystkim interesariuszom co dwa tygodnie lub co miesiąc. W zależności od cyklu raportowania finansowego, comiesięczny raport stanu
275 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
powinien również zawierać informacje finansowe. 5
Kierownik projektu.
Tworzenie raportów stanu dla kierownika projektu. Członkowie zespołu projektowego powinni wysłać kierownikowi projektu raporty statusowe co jeden tydzień lub dwa tygodnie. Raporty te pozwolą na uaktualnienie bieżącego harmonogramu informacjami o wykonywanych właśnie zadaniach. Raport jest formą pomocniczą do spotkania statusowego. Jeśli kierownik projektu zna status zadań każdego z członków zespołu, może go nie wymagać. Może to mieć miejsce, gdy kierownik projektu sam również pracuje, wśród członków zespołu, nad poszczególnymi przedmiotami dostawy. Typowy scenariusz raportowania: Zespół składa raport kierownikowi projektu w piątek po południu. Kierownik projektu uaktualnia harmonogram i budżet i w poniedziałek wysyła raport statusowy do sponsora i innych interesariuszy. We wtorek odbywa się spotkanie statusowe, na którym dyskutuje się bieżący stan projektu i przypisuje zadania członkom zespołu. W ten sposób kierownik projektu ma najnowsze informacje dotyczące wszystkich zadań w projekcie pod koniec tygodnia i jest przygotowany na spotkanie z zespołem i klientami na początku następnego tygodnia.
276 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2.1 Zarządzanie dokumentami / Podstawy 6.1.2.1.P1 Im większy jest projekt, tym trudniejsze staje się dzielenie informacjami pomiędzy członkami zespołu i interesariuszami. Jest to szczególnie widoczne, gdy nad dużym przedmiotem dostawy pracuje więcej niż jedna osoba. Jeśli kierownik projektu zawczasu nie pomyśli o procedurze zarządzania dokumentami, zespół projektowy może mieć problemy ze znalezieniem właściwej informacji. To powoduje zamieszanie i często konieczność podjęcia dodatkowej pracy przy ponownym wykonywaniu zakończonych zadań. Idea zarządzania dokumentami jest podobna do tego, co robi się zarządzając kodem źródłowym nowo tworzonego oprogramowania. Zarządzanie kodem źródłowym powinno być wykonywane przy pomocy narzędzia zarządzania zmianami w oprogramowaniu lub bazy danych, sprawdzającej prawa własności oraz pilnującej wersjonowania. Bez takich narzędzi, byłoby bardzo trudno rozwijać i wspierać duże projekty dotyczące oprogramowania. Podobnie zarządzane i kontrolowane powinny być także dokumenty, szczególnie w dużych projektach. Kilka poniższych przykładów pozwoli na wyjaśnienie tej koncepcji. Powiedzmy, że w wyniku projektu powstanie wiele dokumentów, które trzeba magazynować i współdzielić (np. Definicja projektu, Dziennik problemów krytycznych, Wymagania biznesowe, Plan testów, itp.). Po stworzeniu dokumentu, członek zespołu powinien wiedzieć, gdzie ma być on przechowywany. W zależności od stosowanego oprogramowania i stopnia jego złożoności, dokument może zostać przekazany do foldera udostępnionego w sieci, foldera plików na twardym dysku kierownika projektu, do pakietu oprogramowania zarządzającego dokumentami, itp. Po jego zapisaniu należałoby określić, kto może mieć dostęp do stworzonego dokumentu. Większość dokumentów może być dostępna dla całego zespołu. Jednak często chcemy, aby dokument mógł być tylko przeglądany a nie zmieniany. Powinno się zastosować ogólną konwencję nazywania dla oryginalnych dokumentów oraz ich kolejnych wersji. Na przykład, jeśli uaktualnia się Definicję projektu, to czy nowa, zmieniona wersja ma zastąpić wersję oryginalną? A może trzeba zachować oryginalny dokument, a nowy oznaczyć w specjalny sposób (np. wersja 2). Te właśnie zagadnienia będą regulowane procedurami zarządzania dokumentami. Sprawdźmy, jak działa raport statusowy. Po pierwsze, należy z góry określić konwencję nazywania takich raportów. Jeśli każdy członek zespołu wysyła raport do kierownika projektu, nie trzeba będzie długo czekać na zebranie się setek różnych raportów stanu. Jeśli w format nazwy dokumentu został ustalony na: „data/nazwisko/raport stanu“, raporty ułożą się w sposób chronologiczny. Jeśli nazwa dokumentu jest następująca „nazwisko/raport stanu/data“, raporty zostaną ułożone według osób. A może kierownik projektu powinien wykasowywać raporty po ich przeczytaniu? Wszystkie te pytania to składniki procesu zarządzania dokumentami. Zarządzanie dokumentami dla małych projektów jest zwykle trywialne. Dla większych projektów procesy te muszą być wcześniej ustalone. W innym razie doprowadzimy do zamieszania, niepewności oraz do pojawienia się dodatkowej pracy podczas trwania projektu.
277 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2.1.P2 Dane strukturalne i niestrukturalne Dane mogą być przechowywane w jednym lub dwóch stanów – strukturalnym i niestrukturalnym. Dane strukturalne to informacje zachowane w powtarzalny i zorganizowany sposób. Odnosi się to do plików, tabel, baz danych, składnic danych, itp. Ten rodzaj danych daje się łatwo przechowywać i jest łatwo dostępny przez programy komputerowe. Z drugiej jednak strony, dane niestrukturalne stanowią format łatwiejszy do zrozumienia dla ludzi, lecz trudniejszy do automatycznego zarządzania. Dane niestrukturalne to dokumenty, zdjęcia, grafiki, wideo, audio, itp. Dane niestrukturalne mogą być obrabiane przez komputer, lecz najlepsze zrozumienie ich treści jest ciągle w gestii ludzi. Pomimo że dokumenty stanowią główny obiekt zainteresowań zespołów projektowych, koncept zarządzania dokumentami może zostać rozszerzony na wszelkie inne dane. Innymi słowy, jeśli w wyniku projektu powstają pliki wideo lub audio, można wykorzystać te same techniki w odniesieniu do konwencji nazywania, indeksowania, magazynowania w repozytorium, itp. Przykłady danych strukturalnych i niestrukturalnych pokazane są w poniższej tabelce. Dane strukturalne
Dane niestrukturalne
Pola, rekordy, pliki, tabelki.
Dokumenty, rysunki, grafiki, tekst, wideo, chat.
Kody, modele, skrypty. Poleganie danych. Narzędzia źródłowym.
na
narzędziach, zarządzania
bazach kodem
Trudno znaleźć narzędzia, choć wiele takich istnieje. Narzędzia zarządzania dokumentami.
Trudne do zorganizowania bez narzędzi Możliwe do zorganizowania bez narzędzi. i struktur.
6.1.2.1.P2 Podstawy zarządzania dokumentami W poniższym rozdziale zostały opisane komponenty procesów zarządzania dokumentami. Procesy te mogą zostać zmodyfikowane według potrzeb danego projektu, a następnie zawarte w Planie zarządzania projektem stworzonym podczas procesu 1.0 Definiowanie projektu. Wiele z nich może się przydać w procesie zarządzania cyklem życia dokumentu (od momentu jego powstania do ostatecznej akceptacji) Por. 6.1.2.1.1 Cykl życia dokumentów. Proces zarządzania szkicami dokumentów opisany jest w rozdziale 6.1.2.1.2 Szkice dokumentów, Tak naprawdę zarządzanie dokumentami nie jest procesem rozumianym jako kolejno następujące po sobie czynności. To bardziej pewne specyficzne podejście i zestaw adekwatnych technik. Im większy jest projekt, tym większy rygor i tym większa struktura potrzebna jest do zarządzania dokumentami. Jeśli z góry nie ustali się dobrego planu zarządzania dokumentami, można pogubić się, starając się odnaleźć bądź zachować dokument. Poniższe kwestie powinny być zostać rozważone jako część ogólnego planu zarządzania dokumentami. Przykłady te nie odzwierciedlają procesu samego w sobie, gdyż mogą być rozważane i wdrażane w dowolnej kolejności.
278 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Miejsce
przechowywania dokumentów. Zespół projektowy powinien mieć wspólne miejsce lub repozytorium do umieszczania dokumentów. Może to być katalog plików, pakiet oprogramowania do zarządzania dokumentami, szafka na segregatory, itp. Kierownik projektu powinien upewnić się, że dokumenty nie są zachowywane w różnych miejscach (w oparciu o preferencje członków zespołu). Jeśli tak się stanie, zespół będzie miał trudności w znalezieniu potrzebnych dokumentów – szczególnie w przypadku wymiany członków zespołu.
Typy
dokumentów, którymi należy zarządzać. Zespół musi określić typy dokumentów, które będą dodawane do repozytorium. Biblioteka może zawierać każdy dokument na każdym etapie jego powstawania, włączając w to szkice i dokumenty robocze. Każdy członek zespołu może mieć swój wydzielony obszar pracy (wydzielony folder) dla własnych danych roboczych. Musi jednak istnieć wspólna dla wszystkich biblioteka do przechowywania ostatecznych, zatwierdzonych dokumentów.
Logiczna i fizyczna struktura organizacji dokumentów. Kiedy już znane jest miejsce przechowywania dokumentów, powinno się określić strukturę katalogów lub folderów. W ten sposób członkowie zespołu będą mieli wytyczne, co do miejsca zachowywania dokumentów. Pomoże również w ich odnajdywaniu. Pierwszy krok to określenie logicznego wyglądu tego, jak powinny być one zorganizowane. Można np. stworzyć prosty szkic struktury na papierze i przedyskutować pomysł z resztą zespołu. Kiedy już układ został uzgodniony, należy urzeczywistnić go w konkretnej strukturze katalogów lub specjalizowanym narzędziu. Struktura powinna być na tyle intuicyjna, aby łatwo znajdować właściwe informacje. Po stworzeniu kilku takich struktur dla kilku projektów, będzie można zaobserwować między nimi pewne podobieństwa. Może być to pomocne przy tworzeniu standardowej logicznej struktury dokumentów dla wszystkich projektów. Przykładowa struktura logiczna repozytorium dostępna jest w rozdziale 6.1.1.3 Zarządzanie dokumentami / Przedmioty dostaw.
Standardy nazewnictwa. Znajdowanie dokumentów może być trudne nawet w intuicyjnej strukturze. Jednolity standard nazywania dokumentów znacznie to ułatwi. Przykład został opisany wcześniej w konwencjach nazewnictwa raportów. Jeden sposób to np. „20061201 Joe Smith Status Report“. W tym przypadku wszystkie raporty z jednego okresu ułożą się obok siebie. W przypadku nazwy „Joe Smith 20061201 Status Report“ raporty posortują się według nazwisk osób. Kierownik projektu musi upewnić się, że wszyscy używają tego samego schematu. Pomimo że zadanie takie może wydawać się (szczególnie na początku) uciążliwe, posiadanie wspólnego standardu nazewnictwa dla powiązanych dokumentów będzie bardzo pomocne kiedy zespół projektowy zacznie tworzyć setki takich dokumentów.
Wersjonowanie.
Kierownik projektu określa, czy zapisywane będą wszystkie wersje dokumentów, czy tylko ostatnia, najnowsza wersja. Dla wielu dokumentów, takich jak Definicja projektu, zachowywane powinny być wszystkie wersje zatwierdzone. Dla nich, w konwencji nazewnictwa, powinien istnieć schemat określania wersji. Na przykład dokument wyjściowy może nazywać się „ABC Definicja Projektu v1“. Nazwa dokumentu zostanie zmieniona na „ABC Definicja Projektu v2“ jeśli został on później poprawiony. Z drugiej jednak strony, dokumenty takie jak Dziennik problemów krytycznych posiadają tylko bieżącą wersję, a informacje przeszłe zachowywane są wewnątrz dokumentu. Nowy,
279 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
uzupełniony Dziennik problemów krytycznych zawsze zastępuje poprzedni. Nie ma powodu by trzymać kolejne wersje.
Stan
akceptacji dokumentu. Kiedy dokumenty muszą być formalnie akceptowane - a w szczególności - gdy proces zatwierdzania jest długi, ważne jest oznaczanie stanu akceptacji dokumentu. Na przykład, ważne jest, aby wiedzieć, czy czytany dokument jest w ostateczną, zaakceptowaną wersją, czy to tylko szkic. Może w tym pomóc stworzenie osobnych bibliotek (folderów) dla dokumentów w trakcie procesu akceptacji. Typowe oznaczenia dokumentów to: “szkic” (draft), “praca w toku” (work in-progress) oraz „wersja ostateczna” (final). Kiedy dokument jest tworzony, znajduje się on w folderze: „szkic“. Kiedy dokument jest w obiegu do akceptacji, znajduje się w folderze: „praca w toku”. Kiedy dokument zostanie formalnie zaakceptowany, przesuwa się go do folderu „wersja ostateczna”.
Standardowe formaty dokumentów. W dłuższej perspektywie łatwiej jest czytać i tworzyć dokumenty, jeśli każdy stosuje standardowe wzorce i szablony. Dodatkowo zespół może stworzyć standardowe nagłówki lub stopki, stronę tytułową, spis treści, ustalić standardową czcionkę itp. W ten sposób nadamy wszystkim dokumentom standardowy wygląd.
Standardowe narzędzia obróbki dokumentów (opcjonalnie). Zespół powinien
posiadać standardowy zestaw narzędzi do przetwarzania dokumentów. Zazwyczaj nie jest to problem jeśli cały zespół pochodzi z jednej lokalizacji. Jednakże brak wspólnych narzędzi może stanowić problem, jeśli zespół projektowy składa się z osób z różnych organizacji, różnych państw czy różnych firm. Na przykład, coś tak prostego jak standardowe narzędzie do edycji tekstu zwykle nie stanowi problemu. Jednak, może się zdarzyć, że część zaproszonych do zespołu osób będzie używać MS Word w wersji 2003, część MS Word 2007 a część np. WordPerfect. Podobnie jest w przypadku arkuszy kalkulacyjnych. Kiedy już wybrane zostanie standardowe (referencyjne) oprogramowanie, trzeba upewnić się, że cały zespół ma te same lub kompatybilne wersje. Czasami nie będzie można współdzielić dokumentów, jeśli twórca i czytelnik używają innych wersji oprogramowania.
280 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2.2 Zarządzanie dokumentami / Cykl życia dokumentu 6.1.2.2.P1 Kierownik projektu powinien rozumieć etapy, jakie przejść musi dokument od momentu rozpoczęcia jego tworzenia do momentu zakończenia prac nad nim. Wiedza ta pozwoli mu zrozumieć ogólny status dokumentu w każdym momencie. Pomoże również zapewnić odpowiednią ilość czasu na jego stworzenie. Na przykład, kiedy członek zespołu mówi, że będzie w stanie zamknąć dokument w ciągu dwóch tygodni, ma na myśli, że dokument będzie gotów do pokazywania go innym i zbierania uwag na jego temat, czy też że będzie całkowicie zamknięty i formalnie zaakceptowany? Nie wszystkie dokumenty muszą przechodzić przez wszystkie etapy. Jednakże w zależności od dokumentu, wymagany będzie co najmniej jeden etap. Niektóre z poniższych etapów określonych poniżej mogą stanowić część procesu kontroli jakości dokumentów. Role
Cykl życia dokumentu
1
Planowanie dokumentu Autor dokumentu. Czasami można rozpocząć tworzenie dokumentu bez przygotowania. Innym razem niezbędne będzie odpowiednie przygotowanie i plan. Staje się to konieczne, gdy dokumenty są większe i bardziej złożone. W wielu przypadkach autor nie może rozpocząć pracy, ponieważ nie ustrukturalizował swoich przemyśleń. Przygotowanie i planowanie, nakreślenie zarysu treści i struktury rozdziałów, pomoże rozpocząć pracę.
2
Szkic dokumentu Autor dokumentu. Na tym etapie tworzy się szkic dokumentu. Jeśli nie są konieczne kolejne przeglądy, sprawdzenia i zatwierdzenia, etap ten kończy się stworzeniem końcowego przedmiotu dostawy. Ta część wymaga największej pracochłonności. Kolejne etapy mogą trwać dłużej - nie są natomiast tak pracochłonne.
3
Zebranie informacji zwrotnej i modyfikacje Autor dokumentu. Te dwa etapy związane są z cyrkulowaniem dokumentów w celu sprawdzenia ich i uzyskania informacji zwrotnej. Dokument jest następnie uaktualniany w oparciu o dopisane komentarze zwrotne. W zależności od dokumentu, może to etap ten może powtarzać się w kilku iteracjach. Dokument można także poddać wstępnemu sprawdzeniu wewnętrznemu, następnie oddać go do sprawdzenia przez interesariuszy i na końcu przez kierownictwo. Po każdym sprawdzeniu, dokument jest modyfikowany w oparciu o informacje zwrotne i przesyłany do następnego etapu.
281 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4
Zdobywanie akceptacji Autor dokumentu. Kiedy już otrzymano informacje zwrotne i uaktualniono dokument, jest on gotowy do końcowej akceptacji. Niektóre dokumenty wymagają akceptacji na piśmie. Inne uważa się za zakończone po naniesieniu ostatnich informacji zwrotnych.
Tak jak w przypadku wszystkich zakończonych przedmiotów dostaw, mogą one wymagać późniejszych uaktualnień lub rozszerzeń. Może to wymagać zdefiniowania dla nich specjalnego „małego cyklu życia dokumentu“ (mini-document life cycle).
282 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2.3 Szkice (wersje robocze) Szkice to dokumenty, które zostały już wstępnie zakończone przez autora ale nie można ich jeszcze uznać za całkowicie zakończone z perspektywy projektu. W większości przypadków dzieje się tak dlatego, że dokumenty te podlegają, w jakiejś formie, sprawdzeniu. Szkice dokumentów mogą być przechowywane w obszarze roboczym (np. folderze) autora. Jednakże w dużych projektach lub takich, które wymagają większego rygoru w zarządzaniu dokumentami, lepiej byłoby trzymać je w specjalnej bibliotece lub folderze z wersjami roboczymi. Proces uaktualniania szkiców jest następujący:
Role
Proces akceptacji dokumentu
1
Autor dokumentu.
Dokument jest tworzony i edytowany jest w obszarze roboczym autora.
2
Autor dokumentu.
Po ukończeniu pierwszej wersji szkicu, dokument jest przekazywany do biblioteki szkiców. Pozostaje tam, aż do chwili, gdy istnieje konieczność uaktualnienia go lub gdy może zostać przesunięty do repozytorium jako dokument zaakceptowany.
3
Autor dokumentu.
Kiedy dokument znajduje się w bibliotece szkiców, może cyrkulować i być sprawdzany i poprawiany.
4
Autor dokumentu.
Jeśli szkic musi zostać powtórnie uaktualniony, dokument jest kopiowany z powrotem do obszaru roboczego autora. W bibliotece szkiców zostaje kopia.
5
Autor Proces ten jest powtarzany aż do zakończenia pracy nad dokumentu, dokumentem. Wtedy jest on przekazywany z biblioteki szkiców do bibliotekarz. ostatecznego miejsca przeznaczenia w repozytorium dokumentów.
Wartością tego podejścia jest to, że zespół projektowy zawsze posiada jeden oficjalny szkic każdego dokumentu i jedną, ostatecznie zaakceptowaną, wersję końcową.
283 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.2.4 Przykładowa struktura katalogu 6.1.2.4.P1 Na najwyższym poziomie repozytorium dokumentów powinno składać się z trzech głównych obszarów – przedmioty dostawy projektu, przedmioty dostawy zarządzania projektem oraz pomoce projektowe. Można też zdefiniować obszar czwarty - obszar roboczy.
Przedmioty dostawy projektu: Katalog do magazynowania wszystkich przedmiotów dostaw projektu. Zwykle jest podzielony na podfoldery, które pomagają ustrukturalizować przechowywane dokumenty.
Przedmioty dostawy zarządzania projektem: Katalog do magazynowania wszystkich przedmiotów dostawy związanych z zarządzaniem projektem. Podzielony na podfoldery, które pomagają ustrukturalizować przechowywane dokumenty.
Pomoce projektowe: Katalog dla wszelkich dokumentów uznanych za wartościowe, które mogą stanowić „wsad“ do projektu. Są to np. definicje architektury, wykresy organizacji klientów, materiały szkoleniowe, grafiki, itp. Przedmioty dostawy powstałe podczas projektu nie są tutaj przechowywane.
Obszar roboczy (opcja): Katalogi członków zespołu. Używane do przechowywania wytwarzanych kopii roboczych dokumentów.
Poniżej znajduje się przykład typowej struktury katalogów projektu. \Nazwa projektu \Przedmioty dostawy projektu \Końcowe \Szkic \Praca w toku \Przedmioty dostawy zarządzania projektem \Definicja projektu \Komunikacja \Prezentacje \Informacje finansowe \Dzienniki \Różne \Harmonogramy \Status \Protokoły ze spotkań \Raporty \Pomoce projektowe \Tutoriale \Formularze \Inne materiały \Obszar roboczy \Członek zespołu 1 \Członek zespołu 2 \(itd..)
284 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.3 Zarządzanie komunikacją / Duże projekty 6.1.3.P1 Duże projekty W dużych projektach, komunikacja jest przeprowadzana w kontekście formalnego Planu komunikacji. Spotkania statusowe oraz raporty stanu, są wymagane, tak jak w przypadku średnich projektów. Dodatkowo istnieje wiele innych rodzajów proaktywnej komunikacji, które należy wziąć pod uwagę. Ta kreatywna i proaktywna komunikacja jest przedstawiona w Planie komunikacji, tworzonym w opisany poniżej sposób. Rozpoczęcie projektu 6.1.3.P1 Planowanie komunikacji
1
2
Role
Raportowanie stanu projektu (Duże projekty)
Kierownik projektu.
Określanie interesariuszy projektu.
Kierownik projektu.
Potrzeby komunikacyjne
Niezwykle istotne jest właściwe zidentyfikowanie wszystkich interesariuszy projektu. W niektórych przypadkach istnieją grupy interesariuszy o podobnych potrzebach komunikacyjnych (np. komitet sterujący). W innych przypadkach mogą to być pojedyncze osoby, np. sponsor.
Kierownik projektu określa potrzeby komunikacyjne każdego interesariusza. Może je podzielić na trzy kategorie:
Obowiązkowe.
Związane głównie z raportami stanu, wymogami prawnymi, raportami finansowymi, itp. Informacja jest doręczana odbiorcom („push“).
Informacyjne.
Informacje, które ludzie mogą chcieć poznać lub mogą potrzebować do swoich zadań. Informacje są udostępnianie odbiorcom (np. strona www w intranecie firmowym), ale to od osób czytających wymaga się, aby przejmowały inicjatywę komunikacyjną i sięgały po te informacje („pull“).
Marketing.
Komunikacja służąca tworzeniu poparcia i entuzjazmu dla projektu i jego przedmiotów dostaw. Informacja jest przekazywana odpowiednim osobom. Jeśli projekt wpływa na kulturę organizacyjną lub na nawyki w pracy warto go „obrandować“. (Patrz rozdział 6.1.3.3 Zarządzanie komunikacją / Branding projektu).
285 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
3
Kierownik projektu.
Odpowiedź na potrzeby komunikacyjne Dla każdego zidentyfikowanego interesariusza należy określić, jak można spełnić jego potrzeby komunikacyjne. Ważne jest, aby kierownik projektu używał Raportu stanu oraz innych metod komunikacji do zarządzania oczekiwaniami. Więcej informacji o zarządzaniu oczekiwaniami w rozdziale 6.1.1.1. Należy określić informacje, których potrzebują interesariusze, częstotliwość z jaką muszą być one uaktualniane oraz najlepszy sposób ich dostarczenia. Na tym etapie należy być kreatywnym w poszukiwaniu sposobów komunikowania się z interesariuszami projektu. Oto przykład: Wprawdzie wszyscy interesariusze potrzebują znać aktualny stan projektu, ale komitet sterujący może co miesiąc potrzebować spotkań na krótki briefing i przedstawienie kierunków strategicznych. Sponsor projektu może chcieć co miesiąc spotkania osobistego, a co kwartał może wychodzić biuletyn dla całej organizacji klienta w celach informacyjnych i marketingowych. Inne przykłady mechanizmów komunikacji – patrz rozdział 6.1.3.2 Zarządzanie Komunikacją / Przykłady planu komunikacji.
4
5
6
7
Kierownik projektu.
Określanie pracochłonności.
Kierownik projektu.
Szeregowanie opcji komunikacji.
Kierownik projektu.
Wdrażanie komunikacji obowiązkowej
Kierownik projektu.
Uzupełnienie harmonogramu
Należy oszacować pracochłonność wymaganą do stworzenia i wdrożenia każdej określonej opcji komunikacyjnej, opisanej w etapie 3. Należy również zidentyfikować potencjalne korzyści z komunikacji dla odbiorcy i zespołu projektowego.
Należy usunąć opcje komunikacji wymagające dużych nakładów przy jednoczesnych znikomych korzyściach końcowych. Należy również usunąć te, które dostarczają marginalnych korzyści, pomimo że mogą nie wymagać dużych nakładów ze strony zespołu projektowego. Należy wdrożyć opcje komunikacyjne dostarczające wysokiej wartości i wymagające niskich nakładów ze strony zespołu projektowego. Należy również rozważyć te, które mają dużą wartość i wymagają dużego nakładu ze strony zespołu. Wdrożenie niektórych z nich może mieć sens a innych nie.
Bez względu na priorytety należy wdrożyć opcje komunikacji, które są obowiązkowe dla projektu lub jego otoczenia. Będzie to dotyczyć Raportów stanu ale także raportów i dokumentów wymaganych przez prawo, itp.
Na koniec należy dodać czynności związane z planowaną komunikacją do harmonogramu. Także ich częstotliwość, daty
286 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
kluczowe, pracochłonność oraz osoby odpowiedzialne. Rozpoczynanie projektu 6.1.3.P2 Plan zarządzania dokumentami 8
Kierownik projektu.
Planowanie zarządzania dokumentacją. Duże projekty mogą tworzyć wiele dokumentów. Dokumentacja może też łatwo wymknąć się spod kontroli (informacje będą rozrzucone, trudne do znalezienia i zorganizowania). Proces zarządzania dokumentami jest znacznie prostszy, jeśli kierownik projektu zaplanuje, jak będą wyglądały dokumenty, gdzie będą przechowywane i w jaki sposób będą kontrolowane. Proces zarządzania dokumentami jest opisany w rozdziałach 6.1.2.1 Zarządzanie dokumentami – Podstawy i w 6.1.3.1 Zarządzanie dokumentami – Zaawansowane.
W czasie trwania projektu 6.1.3.P3 Dystrybucja informacji 9
Kierownik projektu.
Wykonywanie Planu komunikacji. Plan komunikacji wyszczególnia interesariuszy, informacje których potrzebują, częstotliwość z jaką powinni otrzymywać informacje, najlepszy format komunikacji, itp. Zadaniem kierownika projektu jest wprowadzenie tego planu w życie. Związane jest to również z odpowiadaniem na doraźne prośby o udzielenie informacji.
6.1.3.P4 Raporty o stanie projektu 10
11
Kierownik projektu, członkowie zespołu, klient.
Zaplanowanie i udział w spotkaniach statusowych projektu.
Kierownik projektu.
Tworzenie raportu stanu dla sponsora i interesariuszy.
Zespół powinien brać udział w spotkaniach statusowych co jeden lub dwa tygodnie. W zależności od potrzeb kierownika projektu, mogą odbywać się osobne spotkania dla zespołu i osobne dla klienta. Powinna istnieć standardowa agenda takich spotkań i nie powinny one trwać dłużej niż jedną godzinę. Zazwyczaj celem takich spotkań jest informowanie o stanie projektu a nie rozwiązywanie jakichkolwiek problemów. (Typowa agenda spotkania jest zamieszczona w sekcji przedmiotów dostaw.)
Kierownik projektu powinien wysyłać Raporty stanu wszystkim interesariuszom co dwa tygodnie lub co miesiąc. W zależności od cyklu raportowania finansowego, comiesięczny raport stanu powinien również zawierać informacje finansowe.
287 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
12
Członkowie Tworzenie raportów stanu dla kierownika projektu. zespołu. Członkowie zespołu projektowego powinni wysłać kierownikowi projektu raporty statusowe co jeden tydzień lub dwa tygodnie. Raporty te pozwolą na uaktualnienie bieżącego harmonogramu informacjami o wcześniej przydzielonych i wykonywanych właśnie zadaniach. Raport jest formą pomocniczą do spotkania statusowego. Jeśli kierownik projektu zna status zadań każdego z członków zespołu, może go nie wymagać. Może to mieć miejsce, gdy kierownik projektu sam również pracuje, wśród członków zespołu, nad poszczególnymi przedmiotami dostawy. Typowy scenariusz raportowania: Zespół składa raport kierownikowi projektu w piątek po południu. Kierownik projektu uaktualnia harmonogram i budżet i w poniedziałek wysyła raport statusowy do sponsora i innych interesariuszy. We wtorek odbywa się spotkanie statusowe, na którym dyskutuje się bieżący stan projektu i przypisuje zadania członkom zespołu. W ten sposób kierownik projektu ma najnowsze informacje dotyczące wszystkich zadań w projekcie pod koniec tygodnia i jest przygotowany na spotkanie z zespołem i klientami na początku następnego tygodnia.
6.1.3.P5 Zarządzanie interesariuszami 13
Kierownik projektu.
Monitorowanie Planu zarządzania interesariuszami. Wstępna analiza interesariuszy została wykonana podczas definiowania projektu w procesie 1.0 (patrz: 1.2.5 Analiza interesariuszy.) Analiza interesariuszy powinna być weryfikowana okresowo, tak, aby upewnić się, że interesariusze są właściwie zaangażowani. Związane jest to z także z oceną znaczenia grup interesariuszy dla projektu i odwrotnie. Jeśli interesariusze nie są dostatecznie zaangażowani, należy uaktualnić lub zmienić czynności adresowane do nich lub z nimi związane. Możliwe jest także odkrycie nowych interesariuszy w trakcie rozwoju projektu. W takim przypadku należałoby objąć ich także niniejszym procesem. 1. Dodatkowo należy wykonywać czynności związane z zarządzaniem interesariuszami z oryginalnego harmonogramu. Aspekty komunikacyjne analizy interesariuszy zostaną wykonane jako część Planu komunikacji. Jednakże mogą istnieć inne elementy analizy interesariuszy, które również trzeba będzie wykonać.
288 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.3.1 Zarządzanie dokumentami / zaawansowane 6.1.3.1.P1 Kierownik dużego projektu powinien najpierw przejrzeć procesy dla średnich projektów w poszukiwaniu wszystkich elementów, które można by zastosować. Opisane tam zasady dla struktury katalogów i konwencji nazewnictwa są nawet ważniejsze dla większych projektów. Oprócz kwestii opisanych już przy okazji średnich projektów, w dużych projektach powinny być brane pod uwagę następujące obszary:
Wyznaczenie
osoby zajmującej się dokumentami (bibliotekarza). Kiedy ustanowione zostanie repozytorium dla dużego projektu, należy wyznaczyć osobę odpowiedzialną za zarządzanie dokumentami. Nie jest to trudne zadanie w małym lub średnim projekcie. Jednak, gdy dany projekt generuje dużą ilość dokumentów, zarządzanie nimi może zajmować bardzo wiele czasu i wymagać pełnego etatu jednego z członków zespołu. Należy również określić jego zastępcę na wypadek, gdy bibliotekarza nie będzie. Zadania bibliotekarza mogą zostać przyporządkowane jednej lub wielu osobom w zespole. Z rolą tą związane jest także wiele czynności, które mogą być wykonywane przez pełnoetatowego pracownika biurowego związanego z projektem. Do obowiązków bibliotekarza należą następujące sprawy:
Koordynowanie czynności związanych z repozytorium.
Identyfikacja i rozwiązywanie problemów w repozytorium.
Określanie, utrzymywanie i wymuszanie standardów dokumentów oraz monitorowanie ich adekwatności.
przechowywania
Monitorowanie i kontrola dostępu do repozytorium, uaktualnienia biblioteki.
Określanie, kiedy magazynowanie starych dokumentów w bibliotece ma sens. Przeprowadzanie archiwizacji i czyszczenia katalogów. Nie należy obawiać się wyznaczania bibliotekarza w dużych projektach. Nie musi być to zadanie na pełen etat, może wymagać jedynie 10% czasu danej osoby. Jednak, jeśli projekt generuje dużo dokumentów, niezbędna jest i osoba i procesy, tak aby zapewnić zachowanie integralności dokumentacji.
Określanie
zasad dostępu. Zasady dostępu opisują, kto może przeglądać i sprawdzać dokumenty a kto je uaktualniać i zmieniać. Większość dokumentów powinna być dostępna dla całego zespołu „tylko do odczytu”. Niektóre dokumenty trzeba będzie zabezpieczyć w specjalny sposób. Musi być również wiadomo, które dokumenty członkowie zespołu mogą uaktualniać, a które nie. Zazwyczaj osoba (osoby), która stworzyła dany dokument jest jedyną osobą, która może go uaktualnić.
Jeśli
używane jest specjalizowane narzędzie zarządzania dokumentami, takie zasady można tam określić i wdrożyć. Ale nawet, jeśli używa się zwyczajnej struktury katalogów, można ustanowić klarowne reguły. Na przykład można przeznaczyć jeden folder na zakończone i zaakceptowane dokumenty, których nikt nie powinien zmieniać. Można również stworzyć foldery robocze dla każdego
289 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
członka zespołu. Będą tam mogli zachowywać swoje osobiste dokumenty jak również przedmioty dostaw w trakcie tworzenia.
Tworzenie
słów kluczowych i schematów indeksowania. W zależności od technologii repozytorium, powinno być możliwe wyszukiwanie dokumentów. Może ono być oparte na nazwie (co wymusza powszechne stosowanie standardów nazewnictwa) i/lub na słowie kluczowym. Słowa kluczowe to wyrazy lub frazy powiązane z danym dokumentem. Stanowią one metadane dokumentu. Struktura słów kluczowych powinna być określona już na początku projektu. Przykład prostego schematu indeksowania dokumentów to: nazwa dokumentu, temat, autor lub osoba kontaktowa, data złożenia do repozytorium oraz lista słów kluczowych. Można będzie wtedy odnaleźć każdy dokument w oparciu o wyszukiwanie według schematu słów kluczowych.
Określanie
procedur uzupełniania repozytorium. Z pewnością wszyscy członkowie zespołu potrzebują dostępu do każdego z ich własnych dokumentów będących w fazie roboczej. Jednakże zespół projektowy musi zdecydować, czy każdy może dokonywać poprawek i uzupełnień w dokumentach stworzonych przez inną osobę. Na przykład, może być konieczne, aby każdy mógł dodać dokumenty do części biblioteki zawierającej końcowe, zaakceptowane przedmioty dostaw. Z drugiej jednak strony można chcieć zastrzec dostęp do tego obszaru tylko dla bibliotekarza i tylko jemu umożliwić dokonywanie ostatecznych zmian. Jest to jedna z zasad, które zespół powinien przyjąć we wczesnej fazie projektu. Poniższa procedura wspiera opisane powyżej czynności: 1. Członkowie zespołu składają bibliotekarzowi dokumenty, kiedy zostaną one zaakceptowane lub w momencie końca danej fazy projektu i na końcu projektu. Członek zespołu uzupełnia formularz opisujący przedmiot dostawy, słowa kluczowe, datę akceptacji, folder, w którym przedmiot dostawy jest przechowywany, itp. 2. Bibliotekarz upewnia się, że dokumenty powinny trafić do repozytorium oraz, że dokument spełnia standardy przewidziane dla niego w projekcie. Jeśli dokument nie nadaje się z jakichś powodów do biblioteki, bibliotekarz może odmówić ich dodania. Jeśli dokument nie spełnia standardów, zwracany jest do członka zespołu w celu skorygowania. Jeśli bibliotekarz nie ma kompetencji, aby sprawdzić dokument, może przekazać go do innego członka zespołu. Członek zespołu sprawdza dokument i zwraca ze stosowną informacją. 3. Jeśli dokument jest odpowiedni i spełnia standardy, bibliotekarz umieszcza go w odpowiednim folderze repozytorium i dodaje inne wymagane informacje. Bibliotekarz korzysta z formularza składania dokumentów, aby dodać właściwe metadane do dokumentu (słowa kluczowe, datę akceptacji, opis, itp.)
Określanie
ram czasowych dla retencji i usuwania. Usuwanie starych, niepotrzebnych dokumentów zapewnia czytelność informacji w bibliotece. Na przykład, tygodniowe indywidualne Raporty stanu mogą nie być potrzebne po trzech miesiącach. Z drugiej jednak strony Definicja projektu potrzebna jest przez cały czas życia projektu, nawet jeśli ma on 12 miesięcy. Okresowo, podczas trwania projektu, bibliotekarz może archiwizować dokumenty, które nie są użyteczne i usuwać je z repozytorium.
Określanie
wymagań dla kopii zapasowych biblioteki i sposobu odzyskiwania. Jeśli repozytorium nie tworzy automatycznie kopii zapasowej,
290 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
kierownik projektu powinien nanieść na harmonogram czynności z tym związane. Jeśli istnieje już automatyczny proces tworzenia kopii zapasowych biblioteki, należy upewnić się, że częstotliwość zachowywania jest adekwatna, i że po awaryjnym odzyskaniu danych dokumenty będą akceptowalnie nieaktualne. Kierownik projektu powinien wiedzieć, gdzie przechowywana jest kopia zapasowa i przez jaki okres czasu. Przynajmniej jedna kopia zapasowa powinna być wysyłana poza bieżącą lokalizację na wypadek katastrofy.
Okresowe przeglądy repozytorium. Jeśli projekt jest bardzo duży a biblioteka skomplikowana, można dokonywać planowanego, okresowego przeglądu biblioteki oraz procesów zarządzania dokumentami. Bibliotekarz jest odpowiedzialny za koordynowanie takiego przeglądu. Można sprawdzać:
Czy biblioteka jest właściwie archiwizowana (kopie zapasowe) i czy przechodzi regularne cykle czyszczenia zbędnej zawartości?
Czy dokumentacja jest zachowywana we właściwym miejscu?
Czy dokumenty są właściwie oznaczone i skategoryzowane tak, aby był do nich łatwy dostęp? Dokumenty są dodawane na bieżąco lub przynajmniej pod koniec każdej ważnej fazy.
291 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.3.2 Zarządzanie komunikacją / Przykład Planu komunikacji 6.1.3.2.P1 Poniżej zamieszczono przykłady typów komunikacji, które można użyć jako część ogólnego Planu komunikacji: 6.1.3.2.P2. Obowiązkowe Ten typ komunikacji jest zwykle wymagany jest przez prawo korporacyjne, normy przemysłowe lub przez prawo państwowe. Informacja jest dostarczana (bezpośrednio) odbiorcom.
Raporty stanu projektu. Raporty stanu projektu
nagrywane na skrzynkę głosową (używanie skrzynek głosowych czy poczty głosowej jest w Ameryce bardzo popularne. W Polsce technologia ta, mimo, że istnieje, nie przyjęła się tak szeroko.)
Spotkania statusowe. Spotkania z komitetem sterującym. Regularne konferencje telefoniczne i wideokonferencje z interesariuszami. Wymagane raporty dla Wspólników lub Zarządu. Raporty i inne informacje wymagane przez przepisy prawa. Wymagane raporty finansowe, itp. 6.1.3.2.P3. Informacyjne
Informacje, które ludzie mogą potrzebować do swoich zadań lub po prostu chcą poznać. Informacje są udostępnianie, ale wymaga się, aby to osoby czytające przejmowały inicjatywę w komunikacji i sięgały po nie.
Sesje budowania świadomości – zachęca się ludzi do uczestniczenia w nich (nie mają to być szkolenia – mają tylko budować znajomość projektu).
Przedmioty
dostawy umieszczone we wspólnych bibliotekach, katalogach, stronach internetowych lub miejscach, do których ludzie mają dostęp.
Najczęściej zadawane pytania. 6.1.3.2.P4. Marketing
Komunikacja do tworzenia poparcia i entuzjazmu dla projektu i przedmiotów dostaw. Ten typ informacji jest przekazywany czytelnikom.
292 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Biuletyny dotyczące projektu – pozytywny marketing. Częste indywidualne spotkania z głównymi interesariuszami. Podróżowanie do różnych miejsc w organizacji w celu informowania o projekcie i korzyściach.
Referencje opisujące wartość biznesową przedmiotów dostaw danego projektu. Konkursy z drobnymi nagrodami – budowanie entuzjazmu. Akronimy i hasła dotyczące projektu, tworzące pozytywny obraz projektu. Odliczanie o daty rozpoczęcia projektu. Nieformalne (ale ważne) inicjowanie dyskusji o pozytywnych osiągnięciach projektu.
Świętowanie
w celu uwidocznienia zakończenia ważnych faz projektu czy osiągnięcia kamieni milowych.
Pamiątki i gadżety dotyczące projektu – promowanie nazwy i wizerunku projektu – takie jak: odznaki, ołówki, kubki, koszulki, itp.
Publikowanie osiągnięć.
Powyższe przykłady pokazują, że komunikacja projektu może przybierać różne kształty. Szczególnie przy większych projektach, zespoły projektowe powinny być kreatywne w określaniu: jak, co, komu, gdzie i z jaką częstotliwością trzeba coś przekazywać. Jeśli projekt jest kontrowersyjny, wymaga zmiany w kulturze lub ma charakter polityczny, krytyczne stają się pozytywne aspekty marketingu. W takich przypadkach można proaktywnie zastosować plan budowania pozytywnego wizerunku i marki projektu (patrz 6.1.3.3 Zarządzanie komunikacją / Kreowanie marki projektu).
293 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.1.3.3 Zarządzanie komunikacją / Kreowanie marki projektu 6.1.3.3.P1 Istnieją trzy główne kategorie komunikowania się w obrębie Planu komunikacji: obowiązkowa, informacyjna i marketingowa. Obowiązkowa komunikacja wystąpi w prawie każdym projekcie. Jeśli projekt jest wystarczająco duży, można chcieć dodać również komunikację informacyjną. Komunikacja marketingowa to miejsce, gdzie można i trzeba wykazać się kreatywnością. W wielu projektach nie ma potrzeby stosowania komunikacji marketingowej. Jeśli jednak projekt jest kontrowersyjny lub ingeruje w kulturę organizacyjną - należy wprowadzić komunikację marketingową. Kreowanie marki projektu jest bardziej złożoną formą komunikacji marketingowej. Celem kreowania marki projektu jest powiązanie z nim pewnych emocji i uczuć. To właśnie starają się zrobić ludzie od marketingu kreując markę. Na przykład Coca-Cola Company ma nadzieję, że ludzie pozytywnie odnoszą się do ich produktu i że wybiorą go z pełnych półek sklepowych. Wybiorą właśnie ten produkt, bo lubią powiązane z nim obrazy i emocje. Możliwe, że to działa. Jeśli ktoś wydaje przyjęcie i udostępnia lodówkę pełną Coli i Sprite‟a, prawdopodobnie dobrze czuje się z kreowanym wizerunkiem. Z drugiej jednak strony, gdy lodówka pełna jest napojów nieznanych lub Coli Joe‟go, gospodarz może czuć się trochę zażenowany. Jeśli tak jest, proces kreowania marki działa! Kreowanie marki projektu ma te same konotacje. Celem kreowania marki jest skojarzenie pozytywnego wizerunku i pozytywnych emocji z projektem. Większość projektów w ogóle się tym nie zajmuje. Warto sobie jednak zadać poniższe pytania w odniesieniu do wpływu projektu na organizację:
Czy wpływa na dużą liczbę osób, czy może na całą firmę? Czy będzie wymagał zmiany kulturowej lub zmiany sposobu, w jaki pracownicy wykonują swoje zadania?
Czy
projekt będzie denerwował ludzi? Na przykład, czy jego wynikiem będą usprawnienia zmniejszające ilość osób koniecznych do wykonania tych samych funkcji? Jeśli odpowiedź brzmi „tak” – to projekt będzie dobrym kandydatem do kreowania
marki. Rozważając oficjalną strategię kreowania wizerunku należy zadać sobie powyższe pytania. Jeśli ludzie usłyszą już o projekcie, to mają myśleć o korzyściach, które płyną z tego projektu, czy też mają myśleć, jak wielkim jest on niepowodzeniem? Czy powinni myśleć o firmie odpowiadającej na wyzwania konkurencji, czy też powinni zastanawiać się, czy dany projekt sprawi, że stracą pracę? Czy projekt ma nieść ze sobą pozytywne czy negatywne myśli? Wszystkie duże projekty niosą jakiś wizerunek z nimi powiązany. Kreowanie marki pozwala na proaktywne tworzenie wizerunku, który chce się przedstawić a nie na akceptowaniu czy walce z jakimś istniejącym. Oczywiście tworzenie wizerunku trwa, konieczny jest więc projekt trwający wystarczająco długo.
294 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Istnieją czynności, które, zawarte w projekcie, mogą pomóc w kreowaniu jego wizerunku. Jeśli to możliwe, należy rozważyć spotkanie z działem marketingu w celu zebrania większej ilości pomysłów, otrzymania pomocy przy kreowaniu wizerunku marki i jej udanego wdrożenia. Poniżej przykłady czynności:
Tworzenie
pozytywnej nazwy projektu. Na przykład projekt o nazwie MarketForce (Siła Rynku), będzie tworzył bardziej pozytywny wizerunek niż projekt zwany Marketing Process Improvement Initiative (Inicjatywa na rzecz Poprawy Procesu Marketingowego) Można również zbudować pozytywny wizerunek w oparciu o łatwy do zapamiętania skrót (akronim).
Tworzenie
wizerunku / logo. Projekt powinien posiadać związany z nim wizerunek lub logo. Wizerunek musi być pozytywny i powinien być dołączany do wszystkich komunikatów (informacji, dokumentów) pochodzących od zespołu.
Rozpowszechnianie markowych gadżetów. Należy umieścić nazwę lub logo projektu na odznakach, koszulkach, ołówkach, itp. Jeśli pracownicy czegoś dokonają, można ich nagradzać nagrodami, na których znajduje się logo projektu etc.
Bezpośrednie spotkania. Należy poświęcić czas na spotkanie jak największej
ilości osób w formie spotkań indywidualnych lub w małych grupach, w szczególności przy rozpoczynaniu projektu. Nikt nie lubi otrzymywać oficjalnych informacji o ważnym projekcie drogą elektroniczną. To dewaluuje wizerunek projektu.
Inne działania mogą być związane z „lunch & learns” („jedz i ucz się”), serią prostych słów związanych z logo projektu (może slogan), zbieraniem referencji od zadowolonych użytkowników oraz ciągłą komunikacją osobistą. Wszystkie te działania pozwalają na utrzymanie pozytywnego wizerunku i pozytywnego przekazu o projekcie do ludzi. Oczywiście wszystko to związane jest również z ciągłym przepływem informacji nieformalnych, co w połączeniu z pozytywnymi odczuciami, co do wizerunku projektu, pozwoli na jego udane zakończenie projektu. Powinno również pomóc przezwyciężyć negatywne postrzeganie projektu.
295 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.2 Zarządzanie komunikacją / Techniki 6.2.P1 Podstawowe zasady spotkań Wszystkie spotkania powinny posiadać agendę. Stworzenie jej wymaga oczywiście dodatkowego nakładu pracy, ale może to być coś tak prostego jak napisanie listu elektronicznego i wysłanie go do uczestników spotkania. Regularnie planowane spotkania statusowe nie wymagają cotygodniowo ustalonego planu, jeśli trzymają się zawsze tego samego formatu. Formalny, wcześniej ustalony program ma dużą wartość w momencie, kiedy zespół spotyka się po raz pierwszy. Jeśli później wszyscy zrozumieją cel spotkań statusowych, nie będzie problemu z ponownym używaniem standardowego planu. W zakresie spotkania mogą pojawić się również następujące sprawy:
Jeśli
w spotkaniu bierze udział duża grupa ludzi, powinno wyznaczyć się moderatora spotkania. Rola ta może być rotacyjna dla regularnych spotkań. Jest to zazwyczaj osoba, która poprosiła o spotkanie (chyba że podjęto inne ustalenia). Na spotkaniach statusowych moderatorem jest zazwyczaj kierownik projektu.
Należy się upewnić, że uczestnicy zostali z góry poinformowani o tym, co mają ze sobą zabrać na spotkanie lub jak się przygotować.
Należy
zapraszać tylko te osoby, które są konieczne. Inne osoby mogą zmniejszyć efektywność spotkania.
Spotkanie powinno się zacząć punktualnie. Należy jednak brać pod uwagę, że niektórzy uczestnicy mogą przychodzić wprost z innego spotkania.
Osoba,
która poprosiła o zebranie powinna wyjaśnić cel i oczekiwany wynik spotkania.
Moderator powinien korzystać z programu spotkania i sprawdzać czas. W ten sposób upewnia się, że wszystko zostało omówione.
Ktoś
powinien zająć się zapisywaniem przydziałów do zadań następujących podczas spotkania. Może to być moderator lub pomysłodawca, chyba że podjęto inne ustalenia. Czasami osoba taka nazywana jest „sekretarzem spotkania”.
Sekretarz powinien podsumować wszystkie nierozstrzygnięte kwestie i pod koniec spotkania (włączając w to: osoby odpowiedzialne, oczekiwania, terminy działań itp.).
Sekretarz
lub moderator powinien podsumować wszelkie podjęte decyzje i udokumentować je w liście elektronicznym (lub innym trybie komunikacji ustalonym dla danego projektu).
6.2.P2 Spotkania statusowe powinny być skoncentrowane Zazwyczaj istnieje pokusa, aby angażować się w rozwiązywanie konkretnych problemów, kiedy mamy zebranych w jednym czasie, na jednej sali, wszystkich ważnych ludzi. Jednak z reguły problem dotyczy tylko kilku osób. Pozostałe osoby na ogólnym 296 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
spotkaniu będą niezaangażowane i będą tracić czas. Jeśli na spotkaniu pojawili się wszyscy, należy poświęcić czas na omówienie ogólnego stanu problemów krytycznych, zakresu oraz ryzyk. Są to czynniki sukcesu projektu i powinny być w centrum zainteresowania wszystkich członków zespołu. Oczywiście można rozwiązywać problemy, jeśli znajdzie się czas w programie. Moderator powinien upewnić się jednak, że problemy te są w obszarze zainteresowań większości członków zespołu. Typowym problemem spotkań jest to, że trwają za długo. W niektórych projektach spotkania dotyczące bieżącego stanu trwają dwie lub więcej godzin. Jest to zazwyczaj spowodowane skupianiem się na rozwiązywaniu problemów, które nie są istotne dla wszystkich uczestników. Najlepszym sposobem ukierunkowania spotkań, które są za długie, jest zmniejszenie przeznaczonego na nie czasu. Na przykład, jeśli pracownicy spotykają się na dwie godziny w tygodniu i nie mogą zakończyć wszystkich punktów programu, należy zredukować ten czas do 90 lub 60 minut. Nie należy pozwalać na rozciąganie spotkań statusowych. Powinny one mieć raczej napięty program. Dzięki temu będą efektywne. Zbyt długie dyskusje należy przenieść poza spotkanie lub na osobne spotkanie (które skupi się na omawianych zadaniach i wezmą w nim udział najbardziej zainteresowane osoby). 6.2.P3 Standardowe raporty do informowania o bieżącym stanie Należy unikać tworzenia indywidualnych raportów dla każdej osoby potrzebującej informacji. Większość osób potrzebuje tylko standardowego zestawu informacji, które można przekazać w zwykłym raporcie statusowym. Jeśli istnieje potrzeba podania informacji wykraczających poza standardowy raport, należy stworzyć dodatkowy standardowy raport zawierający te informacje. Na przykład, można stworzyć szczegółowy raport stanu co tydzień, a podsumowujący raport stanu co miesiąc. To wystarczy. Jeden raport może nie spełniać potrzeb wszystkich interesariuszy. Jednak nawet jeśli mamy różnego rodzaju raporty muszą one być oparte o standardowe wzorce. Należy jak najbardziej minimalizować doraźne zapytania o raport o stanie. Wymaga to bowiem dodatkowego czasu i zazwyczaj ma marginalną wartość w porównaniu do dostępnych już, standardowych wzorców raportów. 6.2.P4 Raporty statusowe od zespołu ―wystarczająco często‖ Częstotliwość raportowania stanu jest oparta o długość projektu oraz prędkość reakcji. Na przykład, jeśli dany projekt trwa dwa miesiące, a kierownik projektu otrzymuje raporty o stanie co miesiąc, ma niewiele czasu na reakcję, jeśli zostanie poinformowany o problemach. Preferowane zasady są następujące:
Drobne projekty mogą nie wymagać formalnego raportowania stanu. Członkowie zespołów w średnich projektach powinni składać raporty co tydzień. Członkowie zespołów w dużych projektach powinni składać raporty co tydzień lub co dwa tygodnie. Ta częstotliwość mocno zależy jednak od sytuacji. Na przykład, jeśli pojawiają się czynności o charakterze krytycznym, raportowanie stanie może być potrzebne codziennie. Może to mieć miejsce w fazie wdrożenia, pod koniec projektu, kiedy wiele zadań od siebie zależy.
297 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.2.P5 Raport statusowy musi być wartościowy
Postęp projektu
Żądania zmian Synteza
Raport statusowy
Śledzenie problemów
Inne informacje
Spójrzmy prawdzie w oczy: raporty o stanie nie są zazwyczaj tak efektywne, jak być powinny. Odnosi się to zarówno do członków zespołu raportujących kierownikowi projektu, jak i do kierowników projektu składających raporty głównym interesariuszom. Jednym z głównych powodów jest to, że ludzie składający raporty podchodzą do nich jak do uciążliwego obowiązku a nie - środka do przekazania wartościowych informacji. Zdarzają się raporty stanu bardzo krótkie i o niczym nie mówiące, jak i zawierające absolutnie wszystkie, nieciekawe czynności wykonane przez daną osobę. Autor raportu powinien tworzyć go tak, aby czytelnik mógł wykorzystać informacje w procesie podejmowania decyzji. Informacje muszą być wartościowe. Tworzący je powinien zadać sobie pytanie: Czy informacja o raporcie o stanie rzeczywiście przekazuje coś wartościowego? Czy też jest po prostu wypełnieniem wolnej przestrzeni? Typowy Raport stanu powinien zawierać następujące kwestie:
To co osiągnięto w odniesieniu do tego co przyporządkowano do zrobienia w harmonogramie.
Uwagi dotyczące zadań, które należało wykonać, a które są już opóźnione. Napotkane problemy (problemy krytyczne), ich wpływ na projekt i to, co
jest
robione, żeby je rozwiązać.
Wnioski o zmianę zakresu. Nowo zidentyfikowane ryzyka. Obserwacje użyteczne dla czytelnika. Skupienie się w raporcie głównie na tych informacjach spowoduje, że będą one mogły stać się przyczynkiem do podejmowania właściwych decyzji zarządzaniu projektem. Stanowią również źródło informacji dla interesariuszy. Ludzie przestaną
298 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
natomiast zwracać uwagę na raporty, jeśli podawane im będą trywialne informacje. 6.2.P6 Używanie załączników do prezentowania szczegółów Istnieje wprawdzie potrzeba skupienia się tylko na ważnych informacjach w raporcie stanu, ale często jest tak, że dla jednych odbiorców ważne są informacje zagregowane a dla innych – bardziej szczegółowe. Czy oznacza to, że należy stworzyć dwa raporty stanu? Zdecydowanie nie. Jednym ze sposobów zadowolenia obu grup jest napisanie formalnego raportu stanu jako dokumentu opartego na sytuacjach wyjątkowych i dołączenie szczegółów w formie załącznika. Na przykład, większość czytelników chce poznać osiągnięcia z bieżącego okresu i te planowane na następny. Jednak menedżer może chcieć zobaczyć cały harmonogram. Aby usatysfakcjonować obie strony należy załączyć harmonogram jako aneks. Jeśli informacje wysyłane są drogą elektroniczną, bieżący harmonogram może zostać przesłany jako osobny dokument (niepołączony z podstawowym raportem o stanie). Podobnym przykładem może być sytuacja, kiedy informuje się o zakończeniu ważnego cyklu szkoleń. Klient może chcieć poznać nazwiska szkolonych osób. Nie należy podawać tak drobnych informacji w głównej części raportu. Należy je podać w aneksie. 6.2.P7 Raport wymaga mniejszej ilości szczegółów, jeśli odbiorca jest wyżej w organizacji Jeśli tworzy się Plan komunikacji dla projektu, potrzeby wszystkich użytkowników zostaną z pewnością formalnie przeanalizowane. Lecz nawet bez formalnego Planu komunikacji należy zawsze brać pod uwagę to, na jakim poziomie w organizacji znajdują się osoby, do których się pisze. Poziom w organizacji pomoże w określeniu poziomu szczegółów wymaganych w raporcie o stanie. Na przykład, członkowie zespołu potrzebują bardzo szczegółowych informacji, aby mogli wykonywać przydzielone zadania. Kierownik projektu potrzebuje informacji obejmujących cały projekt ale mniej szczegółowych. Kierownik kierownika projektu potrzebuje informacji sumarycznych. Następny wyższy kierownik potrzebuje jeszcze bardziej ogólnych informacji. Pomimo tego, że projekt jest bardzo ważny dla kierownika projektu, dla kierownictwa może on być tylko jednym z wielu, o których muszą być informowani. W niektórych organizacjach filtrowanie jest częścią systemu komunikowania. Oto przykład: Członek zespołu przekazuje raport statusowy kierownikowi projektu. Kierownik otrzymuje ten raport a także raporty od innych osób. Następnie podsumowuje i konsoliduje informacje, i przekazuje mniej szczegółowy raport swojemu kierownikowi. Ten z kolei robi to samo, aż ogólna informacja dotrze na sam szczyt. Dlatego też kierownictwo wyższego szczebla może otrzymać status projektu w postaci dosłownie jednej linijki. A jeśli nie dzieje się nic złego, projekt może nawet zostać pominięty na poziomie zarządu. W innych organizacjach informacja o stanie nie jest streszczana i nie jest przekazywana wyżej. To kierownik projektu jest jedynym, który komunikuje się z wyższymi poziomami kierownictwa. W takim przypadku należy pamiętać, że jeden „rozmiar” informacji nie pasuje wszędzie. Należy zmodyfikować treść komunikacji pod kątem poziomu kierownictwa. Na przykład można wysłać jednostronicowy raport do bezpośredniego kierownika oraz głównych klientów, ukazując stan projektu oraz sytuację 299 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
finansową. Informacje te można również zawrzeć na połowie strony, jeśli przekazuje się ją na następny poziom w organizacji, lub w jednym akapicie, jeśli przysyłamy ją jeszcze wyżej. 6.2.P8 Należy używać najlepszego środka komunikacji Wybierając różne typy komunikacji konieczne dla projektu, należy również określić najlepszy środek do przekazywania informacji. Na przykład:
Raport stanu. Nie musi być przekazywany na papierze. W zależności od osoby,
która wysyła i odbiera informacje, raport stanu może być przekazywany przy pomocy wiadomości na skrzynkę głosową, listu elektronicznego, wideokonferencji lub innych wspólnych narzędzi. Każda organizacja może mieć własne standardowe sposoby na przekazywanie informacji. Jeśli tak nie jest, należy wybrać sposób najbardziej odpowiadający czytelnikowi bez narażania na szwank wartości informacji.
E-mail.
Listy elektroniczne powinny być używane do przekazywania standardowych wiadomości, dzielenia się informacjami oraz komunikatami związanymi z marketingiem. Należy ustalić zakres ich wysyłania tak, aby nie zalewać informacjami tych samych osób w krótkim okresie czasu.
Wiadomości
głosowe. Skrzynek głosowych należy używać do pozostawiania krótkich wiadomości dla konkretnych osób lub całych działów. Skomplikowane długie wiadomości nie są odpowiednie dla tego typu medium.
6.2.P9 Nie strzela się do posłańców przynoszących złe wieści Prawdopodobnie wszyscy słyszeli to powiedzenie (lub jakieś podobne). Oznacza ono, że nie powinno się karać osoby (lub ludzi), która przyniosła złą wiadomość. Jeśli zadaje się pytanie o stan, należy akceptować dobre i złe informacje. Informacje raportuje się po to, aby można było podejmować lepsze decyzje. Jeśli ludzie opowiadali o problemach, należy przyjąć te wiadomości i pracować z zespołem nad przyczynami i rozwiązaniami (najlepiej gdyby członek zespołu informujący o problemie podał również rozwiązanie). Wszyscy kierownicy projektu muszą sobie wziąć to do serca. Jeśli szybko usłyszy się złą wiadomość, to będzie szansa na szybką reakcję. Na problemy krytyczne i ryzyka zidentyfikowane wcześnie można reagować w sposób bardziej elastyczny. Jest zdecydowanie mniej możliwości działania, jeśli usłyszymy o nich w ostatnim momencie. Jednak jeśli pracownicy przynoszą złe wiadomości, a kierownik projektu reaguje negatywnie (szczególnie w odniesieniu do tych osób), kolejnym „posłańcom” nie będzie się spieszyć ze złą wiadomością w przyszłości. 6.2.P10 Zielony/Żółty/Czerwony - ogólny stan projektu Jedną z dobrych technik przekazywania ogólnego stanu projektu jest zastosowanie kolorowych wskaźników (zielony/żółty/czerwony). Wskaźnik zielony oznaczać będzie, że projekt jest na właściwym torze. Nie oznacza to, że nie ma żadnych problemów. Oznacza jednak, że problemy są rozwiązywane, a projekt mieści się w zaplanowanych ramach czasowych i budżetowych.
300 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Wskaźnik żółty oznacza, że istnieje pewne ryzyko, że projekt przekroczy budżet i nie sprosta terminom. Oznaczanie projektu żółtym wskaźnikiem jest sposobem zarządzania oczekiwaniami i informowania, że projekt jest w pewnym sensie zagrożony. Jeśli projekt oznaczony jest na czerwono, oznacza to, że ma on poważne problemy i może narazić na szwank budżet, terminy i / lub jakość. Prawdziwa wartość wskaźników ukazuje się wtedy, kiedy raport o stanie jest przekazywany wyższemu kierownictwu. Jeśli zarząd ma jednostronicowe podsumowania wszystkich projektów oraz kolorowe wskaźniki, może z łatwością zobaczyć ogólny stan całego portfolio. Jeśli ludzie ci zarządzają tylko wyjątkami, błyskawicznie skupią się na tych projektach, które oznaczone są na czerwono i żółto. 6.2.P11 Proaktywne komunikowanie w celu zarządzania oczekiwaniami Jednym z celów zarządzania komunikacją projektu jest zarządzanie oczekiwaniami. Raporty o stanie na przykład są sposobem komunikowania się z interesariuszami. Umożliwiają przedstawianie im informacji o postępach projektu w odniesieniu do harmonogramu i budżetu. Można także dodać informacje dotyczące problemów krytycznych, zmian zakresu, ryzyka, itp. w celu zarządzania oczekiwaniami. Dodatkowe informacje o zarządzaniu oczekiwaniami omówione są szczegółowo w rozdziale 6.2.1. Zarządzanie komunikacją / Zarządzanie oczekiwaniami. 6.2.P12 Wydarzenia komunikacyjne w harmonogramie Kierownik projektu powinien traktować wydarzenia związane z komunikacją tak jak i inne przedmioty dostawy projektu. Należy dodać je do czynności w harmonogramie, przyporządkować osoby do ich wykonania, określić odpowiednie daty końcowe itp. W takim przypadku zespół z pewnością będzie wiedział, że oczekuje się takich wydarzeń komunikacyjnych, kto jest za nie odpowiedzialny i kto dostarczy informacji. Harmonogram powinien zawierać informacje o przyporządkowaniach osób oraz terminach zarówno dla raportów stanu przeznaczonych dla interesariuszy jak i tych składanych przez członków zespołu do kierownika. Także wszystkie czynności odnoszące się do wszystkich spotkań statusowych, spotkań ze sponsorami, spotkań komitetu sterującego oraz innych planowanych spotkań. Nawet, jeśli tworzy się kwartalny biuletyn, należy dodać czynności prowadzące do jego powstania oraz termin wydania do harmonogramu. Jeśli nie ma konkretnych oczekiwań co do terminów, komunikacja zaczyna się psuć. Na przykład, kwartalny biuletyn jest przekazywany sześć tygodni po czasie. Można wtedy podjąć jedynie decyzję o nietworzeniu kolejnego, gdyż terminy wydań są zbyt bliskie. 6.2.P13 Koncepcje brandingowe dla projektów związanych ze zmianą kulturową Większość projektów nie musi się zajmować kształtowaniem własnego wizerunku. Ich zakres jest ograniczony do małej grupy ludzi, a wpływ projektu na organizację jest umiarkowany. Jednakże niektóre projekty będą miały wpływ na całą organizację lub firmę. Ich wdrożenie może zająć lata. W tego typu projektach ma sens tworzenie pozytywnego wizerunku projektu i pozytywnych odczuć z nim związanych. Więcej informacji patrz rozdział 6.1.2 Zarządzanie komunikacją / Kreowanie marki projektu.
301 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.2.1 Zarządzanie dokumentami / Techniki 6.2.1.P1 Użycie Posiadanej Technologii Zarządzania dokumentami jako podstawy dla własnego procesu Duża część procesu zarządzania dokumentami zależy od używanej technologii, często wymuszonej przez specjalizowane narzędzia. Na przykład oprogramowanie do zarządzania dokumentacją będzie standardowo posiadało pewną strukturę logiczną, gotowa do uzupełnienia tylko właściwych nazw i uruchomienia. Może ono również narzucać oznaczenie wersji oraz funkcjonalności do kontrolowania uprawnień dostępu. Narzędzie może również opisywać metadane konieczne w przypadku stosowania słów kluczowych oraz indeksowania. 6.2.1.P2 Zachowywanie dokumentów projektu oraz zarządzania projektem w bibliotece W bibliotece dokumentów przechowywane są wszystkie przedmioty dostawy projektu – zarówno związane z projektem jak i z zarządzaniem nim. Na przykład, repozytorium będzie przechowywać Definicję projektu oraz harmonogram projektu (przedmioty dostawy zarządzania projektem) jak również schematy techniczne oraz plan testów (przedmioty dostawy projektu). Rozważając procesy zarządzania dokumentami, należy brać pod uwagę wszystkie te dokumenty, które powstają w wyniku projektu. 6.2.1.P3 Przekazywanie dokumentów do właściwego obszaru po projekcie Po zakończeniu projektu niektóre dokumenty mogą zostać zarchiwizowane, inne będą przechowywane przez nieokreślony z góry czas. Na przykład raport stanu projektu może zostać zarchiwizowany (lub usunięty) po zakończeniu projektu. Jest on związany z konkretną chwilą i ma niską wartość po zakończeniu projektu. Z drugiej strony, np. Podręcznik Użytkownika należy zachować. Dokumenty takie mogą być później jeszcze uaktualniane w bibliotece dokumentów, jeśli korzysta z niej cała organizacja. W innym przypadku te długotrwałe dokumenty mogą zostać przesunięte do biblioteki używanej przez zespół wsparcia technicznego lub innej. Niektóre firmy posiadają centralną bibliotekę przedmiotów dostaw dużych projektów. Przedmioty te mogą zostać ponownie użyte. Na przykład dokumenty związane z wymogami biznesowymi, które zostały stworzone dla danego projektu mogą zostać wykorzystane przez inny, związany z tym samym obszarem biznesowym. Strategia testowania określona w danym projekcie może zostać użyta przez inny projekt z takimi samymi potrzebami testowania. Po zakończeniu projektu, kierownik projektu oraz bibliotekarz powinni określić informacje, które można wykorzystać w przyszłych projektach i zachować je (jeśli organizacja ma bibliotekę, w której dokumenty mogą zostać zachowane). 6.2.1.P4 Obszary robocze członków zespołu Zazwyczaj repozytorium dokumentów nie przechowuje dokumentów, na których się pracuje (może to zależeć od używanego oprogramowania do zarządzania dokumentami). Każdy z członków zespołu powinien mieć własny obszar roboczy, gdzie może zachowywać wersje dokumentów bieżąco używanych, ale nie rozpowszechnionych. Może to być struktura katalogów lub folder, do którego każdy członek ma pełen dostęp. 302 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Członkowie zespołu mogą parametryzować swój obszar roboczy w dowolny, wygodny dla nich sposób. 6.2.1.P5 Ochrona integralności repozytorium Duże projekty mogą generować duże ilości dokumentów. W tego typu projektach zespół musi utworzyć bibliotekę dokumentów. Może być ona zarządzana przy pomocy specjalizowanego narzędzia. Można również stworzyć prosty folder/strukturę plików we wspólnym katalogu. Jeśli biblioteka zostanie utworzona, należy określić zasady i procedury ochrony integralności przechowywanych tam dokumentów. Na przykład, wszyscy członkowie zespołu potrzebują zazwyczaj pełnego dostępu do każdego ze swoich dokumentów, jednak należy zdecydować, czy każdy członek zespołu może uaktualniać (zmieniać) dokumenty stworzone przez innego członka zespołu. W niektórych projektach będzie to akceptowane, w innych jest to traktowane jako naruszenie bezpieczeństwa. Należy również zdecydować czy członek zespołu może dodawać dokumenty do biblioteki czy też proces uaktualniania będzie wykonywany przez osobę zajmującą stanowisko bibliotekarza? Czasami stanowisko centralnego bibliotekarza, kontrolującego uaktualnienia jest traktowane jako biurokratyczny narzut. Jednak stworzenie takiego stanowiska sprawdza się jeśli dokumentacja związana z projektem jest bardzo szeroka, jeśli ważne jest, aby dokumenty dodawane do biblioteki zawsze spełniały wymogi ustalonego standardu, i aby były wysokiej jakości. Ogólna jakość biblioteki może się obniżyć, jeśli każdy będzie mógł dodawać, usuwać lub modyfikować dowolny dokument. Zamiast tego bibliotekarz może kontrolować proces dodawania dokumentów. Bibliotekarz jest również odpowiedzialny za proces kasowania. Usuwanie starych dokumentów zapewni, że przechowywanie w bibliotece będą tylko właściwe informacje. Na przykład tygodniowy raport stanu może nie być potrzebny po trzech miesiącach. Z drugiej jednak strony, Definicja projektu jest ciągle niezbędna podczas projektu, nawet, jeśli ma już 12 miesięcy. Okresowo bibliotekarz może więc archiwizować dokumenty, które nie są już potrzebne i usuwać je z biblioteki.
303 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
6.3 Zarządzanie komunikacją / Podsumowanie 6.3.P1 Przedmioty dostawy: Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Wniosek o Zmianę Zakresu Dziennik Zmian Zakresu Indywidualny raport stanu Raport stanu projektu Raport stanu projektu II Raport stanu projektu III Raport podsumowujący kamienie milowe Plan komunikacji Dziennik dyskusji podczas spotkań Rozkład spotkań Podsumowanie dokumentacji Notatka projektowa Lista sprawdzająca dla dokumentacji projektu Strona śledzenia wersji 6.3.P2 Harmonogram Rozmiar Niezbędne informacje Czynność
Mały
pracochłonność Uwagi
Tworzenie indywidualnych 1 godzina Raportów stanu (opcja)
Co tydzień lub co dwa tygodnie. Członkowie zespołu przesyłają raport do kierownika projektu.
Tworzenie 1-2 godziny raportów stanu
Co dwa tygodnie lub co miesiąc. Kierownik projektu przesyła raport do interesariuszy.
Udział
w 1 godzina
Co tydzień lub co dwa tygodnie.
304 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
spotkaniach statusowych Czynność
pracochłonność Uwagi
Tworzenie indywidualnych Raportów stanu
1 godzina
Co tydzień lub co dwa tygodnie. Członkowie zespołu przesyłają raport do kierownika projektu.
Tworzenie raportów stanu
1-2 godziny
Co dwa tygodnie lub co miesiąc. Kierownik projektu przesyła raport do interesariuszy.
1 godzina
Co tydzień lub co dwa tygodnie.
Średni Udział spotkaniach statusowych
w
Udział w spotkaniach 1 godzina statusowych z klientem (opcja) Czynność
Pracochłonność
Uwagi
Tworzenie indywidualnych Raportów stanu
1 godzina
Co tydzień lub co dwa tygodnie. Członkowie zespołu przesyłają raport do kierownika projektu.
Tworzenie raportów stanu
1-2 godziny
Co dwa tygodnie lub co miesiąc. Kierownik projektu przesyła raport do interesariuszy.
1 godzina
Co tydzień lub co dwa tygodnie.
Udział spotkaniach statusowych Duży
Co tydzień lub co dwa tygodnie. Spotkanie to jest planowane jeśli klient nie bierze udziału w spotkaniach zespołu.
w
Udział w spotkaniach 1 godzina statusowych z klientem (opcja)
Co tydzień lub co dwa tygodnie. Spotkanie to jest planowane jeśli klient nie bierze udziału w spotkaniach zespołu.
Wykonywanie czynności Planu otwarte komunikacji
Dla każdego wydarzenia komunikacyjnego/przedmiotu dostawy komunikacji należy dodać właściwe czynności do planu operacyjnego projektu. Wiąże się z tym przyporządkowanie osób do zadań, określanie dat początkowych i końcowych, itp. Zapewnia to faktyczne wykonanie zadań z Planu komunikacji.
305 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Wykonywanie czynności zarządzania dokumentami
otwarte
Osoba wyznaczona na bibliotekarza powinna wykonywać co tydzień podejmować niezbędne czynności aby zapewnić porządek w bibliotece oraz to, że członkowie zespołu projektowego wykonują właściwe procesy zarządzania dokumentami.
306 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 7 Zarządzanie ryzykiem
307 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.0 Zarządzanie ryzykiem 7.0.P1 Ryzyko to przyszłe zdarzenie lub zjawisko, które jest poza kontrolą zespołu projektowego. Jego wystąpienie jest prawdopodobne, a w przypadku, gdy ryzyko stanie się już faktem będzie mieć negatywny wpływ na projekt. Podczas gdy problem krytyczny jest obecnym problemem, faktem z którym trzeba sobie poradzić, ryzyko jest potencjalnym zdarzeniem, które się jeszcze nie pojawiło. Reaktywny kierownik projektu próbuje rozwiązać problemy, dopiero kiedy się pojawią. Kierownik proaktywny zaś próbuje rozwikłać potencjalne problemy, czyli jeszcze przed ich pojawieniem się. I to jest sztuka zarządzania ryzykiem! Nie wszystkie zdarzenia mogą być wcześniej zidentyfikowane. Jednakże wiele problemów może zostać przewidzianych i powinny być one obsługiwane poprzez proaktywny proces zarządzania ryzykiem. Kierownik projektu powinien wraz z klientem i zespołem projektowym przeprowadzić identyfikację i szacowanie ryzyk. Określają oni w ten sposób, czy projekt jest wysoce, średnio czy mało ryzykowny. Jeśli masz szczęście, może okazać się, że ogólnie ryzyko projektu jest niskie. Ale nawet wtedy identyfikacja i ocena ryzyk uprzedzi klienta oraz zespół projektowy, że choć ryzyko istnieje to w TenStep jest sposób na jego obsługę. Jeśli więc wystąpią ryzyka o średnim i wysokim poziomie, klient będzie spokojniejszy, gdyż będzie wiedział, że jesteś na nie przygotowany. Analizowanie ryzyka Twojego projektu nie musi być czymś złym i krępującym Cię wobec Klienta czy Sponsora. Wszystkie projekty mają pewien stopień niepewności z powodu czynników wewnętrznych, które się do nich odnoszą, ale także otoczenia, w którym są realizowane. Projekt o większym poziomie ryzyka wymaga bardziej rygorystycznego zarządzania ryzykiem i większego skupienia zarządzających. Chociaż nie jest możliwe całkowite wyeliminowanie ryzyk, większość z nich może zostać przewidziana i w odpowiednim czasie można im zapobiegać lub przeciwdziałać. Celem zarządzania ryzykiem jest identyfikacja ryzyk, a następnie ustalenie Planu Zarządzania Ryzykiem, a dzięki temu pozbywanie się ryzykownych zdarzeń przed ich wystąpieniem lub zmniejszenie działania ryzyka w przypadku jego wystąpienia. W projektach prowadzonych zgodnie z TenStep, najpierw wykonujesz ocenę ryzyka, opisano to w rozdziale 1.0 Definiowanie Projektu. Dodatkowa identyfikacja ryzyk powinna odbywać się w trakcie całego projektu – zgodnie z ustalonym planem (najlepiej miesięcznie lub kwartalnie) lub po zatwierdzeniu kamieni milowych projektu. 7.1 Zarządzanie ryzykiem / Proces 7.2 Zarządzanie ryzykiem / Techniki 7.3 Zarządzanie ryzykiem / Krótka informacja
308 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1 Zarządzanie ryzykiem / Proces 7.1.P1 W tym rozdziale opisane zostały procesy zarządzania ryzykiem. W razie konieczności mogą być one modyfikowane dla potrzeb konkretnego projektu i następnie ujęte w Planie Zarządzania Projektem tworzonym podczas kroku 1.0. Definiowanie Projektu. Przed rozpoczęciem, wskazane byłoby znać precyzyjną definicję terminów "ryzyko" i "założenie" oraz znać różnicę między nimi. Patrz rozdział 7.1.3 Zarządzanie ryzykiem / Założenia i ryzyko. 7.1.P2 Małe projekty W małych projektach zwykle nie spotyka się znacznego ryzyka. Ponieważ niewielkie projekty zwykle nie trwają długo, nie ma więc wielu okazji do pojawiania się wielkich problemów. Jeśli kierownik projektu dokonuje oszacowania ryzyka i odkrywa pewne ryzyko projektu, mogą do jego obsługi być zastosowane takie procedury, jak w przypadku projektów średnich. 7.1.1 Średnie projekty 7.1.2 Duże projekty
309 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1.1 Zarządzanie ryzykiem / Średnie projekty 7.1.1.P1 Początek projektu W średnich projektach do obsługi ryzyk stosowany jest następujący proces:
1
Rola
Zarządzanie ryzykiem (Średnie projekty)
Kierownik projektu
Zidentyfikuj ryzyka. Kiedy definiujesz projekt (1.0 Definiowanie Projektu), wykonaj kompleksową identyfikację ryzyk. Dokonuje się jej w dwóch etapach: 1. identyfikacja ryzyk wrodzonych, 2. identyfikacja ryzyk specyficznych. Najpierw zwróć uwagę na ryzyka wrodzone. Są to ryzyka charakterystyczne dla projektu, nie z powodu tego czym się on konkretnie zajmuje, ale z powodu tego jak ma on być zorganizowany i realizowany. Na przykład projekt, który jest oszacowany na 10,000 godzin jest z natury bardziej ryzykowny niż skalkulowany na 1,000 godzin. Projekt, który angażuje 20 ludzi jest z natury bardziej ryzykowny niż realizowany przez 3 osoby. Projekt, który wprowadza nowe technologie jest bardziej ryzykowny od tego, w którym Twój zespół swobodnie używa znanej technologii. Zauważ, że w każdym z tych przykładów, nie potrzebujesz znać specyfiki projektu, jego celów, zakresu, etc. Wrodzone ryzyka bazują na cechach projektu – niezależnie od produkowanych przedmiotów dostawy. Istotny jest fakt, że raz zidentyfikowane ryzyka wrodzone mogą być pomocne przy identyfikacji ryzyk w następnych projektach o podobnych cechach. Mogą być one umieszczane na listach kontrolnych, tworzonych w organizacji. Po pomoc oraz przykłady określenia ryzyka wrodzonego patrz rozdział 7.2. Czynniki Ryzyka Wrodzonego. W drugim etapie identyfikacji ryzyk zwróć uwagę na ryzyka, specyficzne tylko dla Twojego projektu. To te ryzyka, które nie mogą wystąpić w innych projektach. Wynikają one bowiem ze specyfiki konkretnej sytuacji, w jakiej projekt jest realizowany, ludzi pracujących przy projekcie oraz z tego, jakie przedmioty dostawy projekt dostarcza. Na przykład do ryzyk specyficznych możesz zaliczyć: możliwość wycofania się z projektu Twojego kluczowego dostawcy, opóźnienia ważnych dla projektu dostaw, trudności ze pozyskaniem ludzi o konkretnych umiejętnościach etc. Istnieje kilka sposobów, aby zidentyfikować i ocenić ryzyka. Kierownik projektu może stworzyć wstępny szkic – listę ryzyk projektu opartą na jego wiedzy, następnie może puścić go w obieg w celu uzupełnienia, wprowadzania zmian i komentarzy. Inną techniką
310 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
jest zebranie wszystkich kluczowych interesariuszy i wspólne omówienie potencjalnych problemów. Jest to lepszy wariant. Gdy interesariusze rozmawiają o projekcie i jego ryzykach w tym samym czasie, bardziej prawdopodobne jest, że stworzą bardziej wyczerpującą listę ryzyk. Musisz być ostrożny, aby nie być zbyt optymistycznym w czasie oceny ryzyka. Pamiętaj także, że próbujesz zidentyfikować potencjalne problemy. Zalecane jest, aby na spotkania dotyczące ryzyk zapraszać organizacyjnych sceptyków i pesymistów. Oni zapewnią, że będą zidentyfikowane wszelkie możliwe ryzyka. 2
3
Kierownik projektu
Analizuj ryzyka używając technik jakościowych.
Kierownik projektu
Stwórz plan odpowiedzi do każdego ryzyka o wysokim poziomie.
W pierwszym kroku tego procesu zidentyfikowałeś wszelkie ryzyka. To prawdopodobnie o wiele za dużo, niż możesz obsłużyć. W rzeczywistości, nie ma zbyt wielkiego sensu skupianie się nad każdym ryzykiem. Wiele z nich ma niewielki wpływ na Twój projekt. Dlatego, zanim przebrniesz przez problem umieszczania ryzyka w planie, powinieneś określić jakie są ryzyka, na których chcesz się naprawdę skupić, a jakie ryzyka uznasz, za nie warte zainteresowania. Pierwszym krokiem analizy ryzyka jest analiza jakościowa. Aby uzyskać więcej danych o jakościowej analizie ryzyka udaj się do rozdziału 7.1.1.1.
Stwórz plan odpowiedzi do każdego rodzaju ryzyka, które zidentyfikowałeś, aby upewnić się, że ryzyko jest zarządzane w odpowiedni sposób. Ten plan powinien zawierać czynności zarządzania ryzykiem, określać ludzi i ich odpowiedzialność, daty i oraz sposoby monitorowania postępu. Istnieje pięć głównych odpowiedzi na ryzyko – zostawić je, monitorować, uniknąć, przesunąć na osoby trzecie lub złagodzić. Aby uzyskać więcej danych o tych alternatywach udaj się do rozdziału 7.2 Zarządzanie Ryzykiem / Techniki. 4
5
6
Kierownik projektu
Oceń ryzyka o średnim poziomie.
Kierownik projektu
Oceń ryzyka o niskim poziomie.
Kierownik
Umieść czynności związane z obsługą ryzyka w harmonogramie
Sprawdź wszystkie ryzyka o średnim poziomie. Jeśli ich wpływ jest wystarczająco duży - należy stworzyć plan odpowiedzi na dane ryzyko.
Sprawdź ryzyka o niskim poziomie. Zdecyduj, czy nie powinny być wpisane jako założenia. W ten sposób rozpoznajesz, że jest możliwość wystąpienia problemu, ale z powodu niskiego ryzyka, zakładasz, że on nie wystąpi. Więcej informacji w rozdziale 7.1.3.Zarządzanie ryzykiem / Założenia i ryzyko.
311 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektu
projektu. Umieść czynności związane z obsługą ryzyka w Harmonogramie projektu. Umieszczenie czynności w harmonogramie powoduje, że obsługa ryzyk jest w rzeczywistości planowana, realizowana i kontrolowana.
Procesy w toku 7.1.2.P1 Monitoring i kontrola ryzyka
7
8
Kierownik projektu
Monitoruj bieżące plany związane z obsługą ryzyka.
Kierownik projektu
Obserwuj nowe ryzyka.
Kierownik projektu musi kontrolować Plan Zarządzania Ryzykiem w celu upewnienia się, że ryzyka są skutecznie zarządzane. Nowe czynności do planu ryzyka powinny zostać dodane w przypadku, gdy istnieje podejrzenie, że ryzyko nie jest skutecznie obsługiwane.
Kierownik projektu musi okresowo ocenić ryzyko całego projektu opierając się na bieżących informacjach. W trakcie rozwoju projektu mogą pojawić się nowe ryzyka, a niektóre, które nie zostały zidentyfikowane od razu, mogą pojawić się później. Może również zaistnieć sytuacja, gdzie wcześniej zidentyfikowane ryzyko o niższym w poziomie w miarę upływu czasu zwiększy się do średniego lub wysokiego. Bieżąca ewaluacja ryzyka powinna być wykonywana regularnie lub po osiągnięciu (przy weryfikacji) kamieni milowych projektu.
.
312 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1.1.1 Zarządzanie ryzykiem / Jakościowa analiza ryzyka 7.1.1.1 P1 Jakościowa ocena ryzyka jest mniej dokładna, nie jest tak szczegółowa jak ocena ilościowa. Stosowanie jej daje jednak możliwość szybkiego sklasyfikowania poziomu ryzyka. Poziom ryzyka jest wyznaczony wg ogólnych kategorii: wysoki, średni lub niski. Zależy on od siły wpływu (np. szkód jakie dane zdarzenie, ryzyko może wywołać) i prawdopodobieństwa, możliwości pojawienia się zdarzenia. Jest wiele technik jakościowych analiz ryzyka. W tym rozdziale zostały zaprezentowane trzy przykłady. Istnieją także inne techniki, opisywane szeroko w literaturze dotyczącej analizy ryzyk. 7.1.1.1.P2 Tabela poziomu ryzyka Zacznij od następującej tabeli, jako punktu wyjścia. Pomaga ona ustalić poziom ryzyka i zakwalifikować go jako wysoki, średni lub niski, na poziomie prawdopodobieństwa oraz wpływu na projekt. Na przykład, zdarzenie wysoce prawdopodobne o silnym wpływie stanowi ryzyko wysokiego poziomu. Podobnie ryzyko, które ma niski wpływ na projekt i małe prawdopodobieństwo jest ryzykiem niskiego poziomu. Inne kombinacje mieszczą się gdzieś pomiędzy tymi dwiema skrajnościami. Każdy przypadek musi być oceniany indywidualnie. Jeśli wydarzenie nie jest bardzo prawdopodobne, ale jeśli jego wystąpienie może spowodować duże szkody (np. ktoś mógłby zginąć), możesz rozważyć je jako zdarzenie wysokiego poziomu ryzyka i umieścić je odpowiednio w Planie Zarządzania Ryzykiem. Dotkliwość wpływu wystąpienia ryzyka
ryzyka
/
Prawdopodobieństwo
Wysoce negatywny wpływ na prawdopodobieństwo wystąpienia
projekt
/
Wysokie
Wysoce negatywny wpływ na prawdopodobieństwo wystąpienia
projekt
/
Średnie
Wysoce negatywny wpływ prawdopodobieństwo wystąpienia
na
projekt
Średni negatywny wpływ na prawdopodobieństwo wystąpienia
projekt
Średni negatywny wpływ na prawdopodobieństwo wystąpienia
projekt
Średni negatywny wpływ na prawdopodobieństwo wystąpienia Niewielki negatywny wpływ na prawdopodobieństwo wystąpienia
/ /
Wysokie /
projekt projekt
Niskie
Średnie /
/
Niskie Wysokie
313 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Poziom ryzyka Wysoki Wysoki Średni / Niski Średni Średni / Niski Niski Niski
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Niewielki negatywny wpływ prawdopodobieństwo wystąpienia Niewielki negatywny wpływ prawdopodobieństwo wystąpienia
na
projekt
na
projekt
/
Średnie /
Niskie
Niski Niski
7.1.1.1.P3 Kolorowy diagram ryzyka: wysokiego, średniego, niskiego Możesz także przedstawiać te dziewięć prostych kombinacji ryzyka według następującej tabeli: Prawdopodobieństwo -> Niskie
Średnie
Wysokie
Ignoruj
Ignoruj
Ostrzeżenie
Ignoruj
Ostrzeżenie
Odpowiedź
Ostrzeżenie
Odpowiedź
Odpowiedź
Wpływ
Niski
Średni
Wysoki
Zielone kratki przedstawiają kombinację prawdopodobieństwa i wpływu, który możesz zignorować. Czerwone kratki przedstawiają kombinację, która powinna być obsłużona zarządzana. Żółte kratki prezentują kombinacje, które powinny zostać ocenione indywidualnie. 7.1.1.1.P4 Tabela prawdopodobieństwa ryzyka Możesz pozwolić sobie na więcej dokładności poprzez zwiększenie liczby opcji dostępnych w przypadku prawdopodobieństwa. Na przykład, możesz stworzyć pięciostopniową skalę traktującą o prawdopodobieństwie ryzyka.
Prawdopodobieństwo
Niski Wpływ
Średni Wpływ
Wysoki Wpływ
Bardzo mało Niskie prawdopodobne (<10%) Ryzyko
Niskie Ryzyko
Niskie Ryzyko
Mało prawdopodobne Niskie (<35%) Ryzyko
Niskie Ryzyko
Średnie ryzyko
314 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Może się zdarzyć lub nie Niskie (35% - 65%) Ryzyko
Średnie Ryzyko
Średnie/Wysokie Ryzyko
Prawdopodobne (>65%)
Niskie Ryzyko
Średnie/Wysokie Ryzyko
Wysokie ryzyko
Wysoce prawdopodobne Niskie (>90%) Ryzyko
Średnie/Wysokie Ryzyko
Wysokie ryzyko
Zamiast uproszczonej klasyfikacji wypływu - niski, średni, wysoki, możesz rozwinąć je analogicznie jak w poprzednim przykładzie dot. Prawdopodobieństwa. Na przykład, znowu możesz rozwinąć pięciostopniową skalę w następujący sposób (ta skala ma zastosowanie do każdego ryzyka): 1, nikły wpływ (lub brak wpływu) - jeśli chodzi o koszty i harmonogram od 2% 2, potencjalny wpływ 2%-4% -jeśli chodzi o koszt lub harmonogram 3, potencjalny wpływ 5%-7% na budżet lub harmonogram 4, potencjalny wpływ 8%-10% na budżet lub harmonogram 5, wysoki, potencjalny wpływ powyżej 10% na budżet lub harmonogram Po stworzeniu skali jak ta powyżej, powinieneś określić, co zrobisz z tak zaklasyfikowanymi ryzykami. Na przykład możesz ustalić, że poziom 1 do 2 może być ignorowany, poziom 4 do 5 powinien być zarządzany. Poziom trzeci prezentuje ryzyko, które powinno zostać ocenione indywidualnie.
315 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1.2 Zarządzanie ryzykiem / Duże projekty 7.1.2.P1 Proces zarządzania ryzykiem dla dużych projektów jest taki sam jak dla średnich z dwoma dodatkowymi elementami. Pierwszy, to wykorzystywanie technik analiz ryzyka ilościowego (dodatkowo do technik jakościowych). Drugi, to stworzenie planu wariantowego, aby ustalić przebieg projektu w przypadku, gdy Plan zarządzania ryzykiem nie powiedzie się a ryzyko wystąpi w rzeczywistości. Początek projektu. 7.1.2.P2 Planowanie zarządzania ryzykiem
1
Rola
Zarządzanie ryzykiem (Duże projekty)
Kierownik projektu
Stwórz Plan zarządzania ryzykiem Rozpocznij proces od zdefiniowania i wyboru ogólnego podejścia do zarządzania ryzykiem. Określ ogólnie proces zarządzania ryzykiem, kto będzie zaangażowany w zarządzania ryzykiem, jakie narzędzia zostaną użyte, jakie role będą wykonywane (kierownik projektu, specjalista ds. ryzyka, kierownik ryzyka itp.), ile czasu przeznaczysz na obsługę ryzyk itp.
7.1.2.P3 Identyfikacja ryzyka
2
Kierownik projektu
Zidentyfikuj ryzyka. Kiedy definiujesz projekt (1.0 Definiowanie Projektu), wykonaj kompleksową identyfikację ryzyk. Dokonuje się jej w dwóch etapach: 1. identyfikacja ryzyk wrodzonych, 2. identyfikacja ryzyk specyficznych. Najpierw zwróć uwagę na ryzyka wrodzone. Są to ryzyka charakterystyczne dla projektu, nie z powodu tego czym się on konkretnie zajmuje, ale z powodu tego jak ma on być zorganizowany i realizowany. Na przykład projekt, który jest oszacowany na 10,000 godzin jest z natury bardziej ryzykowny niż skalkulowany na 1,000 godzin. Projekt, który angażuje 20 ludzi jest z natury bardziej ryzykowny niż realizowany przez 3 osoby. Projekt, który wprowadza nowe technologie jest bardziej ryzykowny od tego, w którym Twój zespół swobodnie używa znanej technologii. Zauważ, że w każdym z tych przykładów, nie potrzebujesz znać specyfiki projektu, jego celów, zakresu, etc. Wrodzone ryzyka bazują na cechach projektu – niezależnie od produkowanych przedmiotów dostawy. Istotny jest fakt, że raz zidentyfikowane ryzyka wrodzone mogą być
316 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
pomocne przy identyfikacji ryzyk w następnych projektach o podobnych cechach. Mogą być one umieszczane na listach kontrolnych, tworzonych w organizacji. Po pomoc oraz przykłady określenia ryzyka wrodzonego patrz rozdział 7.2. Czynniki Ryzyka Wrodzonego. W drugim etapie identyfikacji ryzyk zwróć uwagę na ryzyka, specyficzne tylko dla Twojego projektu. To te ryzyka, które nie mogą wystąpić w innych projektach. Wynikają one bowiem ze specyfiki konkretnej sytuacji, w jakiej projekt jest realizowany, ludzi pracujących przy projekcie oraz z tego, jakie przedmioty dostawy projekt dostarcza. Na przykład do ryzyk specyficznych możesz zaliczyć: możliwość wycofania się z projektu Twojego kluczowego dostawcy, opóźnienia ważnych dla projektu dostaw, trudności ze pozyskaniem ludzi o konkretnych umiejętnościach etc. Istnieje kilka sposobów, aby zidentyfikować i ocenić ryzyka. Kierownik projektu może stworzyć wstępny szkic – listę ryzyk projektu opartą na jego wiedzy, następnie może puścić go w obieg w celu uzupełnienia, wprowadzania zmian i komentarzy. Inną techniką jest zebranie wszystkich kluczowych interesariuszy i wspólne omówienie potencjalnych problemów. Jest to lepszy wariant. Gdy interesariusze rozmawiają o projekcie i jego ryzykach w tym samym czasie, bardziej prawdopodobne jest, że stworzą bardziej wyczerpującą listę ryzyk. Musisz być ostrożny, aby nie być zbyt optymistycznym w czasie oceny ryzyka. Pamiętaj także, że próbujesz zidentyfikować potencjalne problemy. Zalecane jest, aby na spotkania dotyczące ryzyk zapraszać organizacyjnych sceptyków i pesymistów. Oni zapewnią, że będą zidentyfikowane wszelkie możliwe ryzyka.
7.1.2.P4 Analizy jakościowe ryzyka
3
Kierownik projektu
Analizuj ryzyka używając technik jakościowych. W pierwszym kroku tego procesu zidentyfikowałeś wszelkie ryzyka. To prawdopodobnie o wiele za dużo, niż możesz obsłużyć. W rzeczywistości, nie ma zbyt wielkiego sensu skupianie się nad każdym ryzykiem. Wiele z nich ma niewielki wpływ na Twój projekt. Dlatego, zanim przebrniesz przez problem umieszczania ryzyka w planie, powinieneś określić jakie są ryzyka, na których chcesz się naprawdę skupić, a jakie ryzyka uznasz, za nie warte zainteresowania. Pierwszym krokiem analizy ryzyka jest analiza jakościowa. Aby uzyskać więcej danych o jakościowej analizie ryzyka udaj się do rozdziału 7.1.1.1. problem umieszczania ryzyka, powinieneś określić, jakie są ryzyka, na których chcesz się naprawdę skupić. Pierwszym krokiem analizy ryzyka jest analiza jakościowa. Aby uzyskać więcej danych o jakościowej analizie ryzyka, udaj się do rozdziału 7.1.1.1.
317 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1.2.P5 Analizy ilościowe ryzyka
4
Kierownik projektu
(Opcjonalnie) Wykorzystaj analizy ilościowe dla ryzyka o wysokim poziomie. Analizę ilościową wykorzystaj do ryzyk, jakie zakwalifikowałeś na drodze analizy jakościowej, jako wysokiego poziomu. Termin „ilościowe” oznacza, że poziom ryzyka bazuje bardziej na analizach liczbowych niż na przybliżeniach, takich jak: niskie, średnie czy wysokie. Jest wiele modeli i algorytmów, które mogą być użyte w analizach ilościowych ryzyka. Większość projektów, nawet dużych, nie potrzebuje wykorzystywać technik ilościowych. Jednakże niektóre projekty wymagają tych technik. Na przykład, jeśli budujesz samolot, nie byłoby dobrze klasyfikować ryzyka jako ogólnie wysokie, średnie czy niskie, używając nieformalnych technik jakościowych. Potrzebujesz bardziej wyrafinowanego modelu i technik statystycznych analiz ryzyka, które są częścią analiz ilościowych ryzyka. Kilka przykładów analiz ilościowych zostało opisanych w rozdziale 7.2.2 Zarządzanie Ryzykiem / Oczekiwana Wartość Pieniężna oraz w 7.2.1.P7 Rachunkowość w Oszacowaniu Ryzyka – Modelowanie Monte Carlo.
7.1.2.P6 Planowanie odpowiedzi na ryzyko
5
6
Kierownik projektu
Stwórz plan odpowiedzi do każdego poziomu ryzyka
Kierownik projektu
Stwórz plany awaryjne dla ryzyka o wysokim poziomie.
Stwórz plan odpowiedzi do każdego rodzaju ryzyka, które zidentyfikowałeś, aby upewnić się, że ryzyko jest zarządzane w odpowiedni sposób. Ten plan powinien zawierać czynności zarządzania ryzykiem, określać ludzi i ich odpowiedzialność, daty i oraz sposoby monitorowania postępu. Istnieje pięć głównych odpowiedzi na ryzyko – zostawić je, monitorować, uniknąć, przesunąć na osoby trzecie lub złagodzić. Aby uzyskać więcej danych o tych alternatywach udaj się do rozdziału 7.2 Zarządzaj Ryzykiem / Techniki.
Stwórz plany wariantowe dla ryzyk o wysokim poziomie. Stwórz plan awaryjny, aby udokumentować z wyprzedzeniem przebieg projektu w przypadku gdy Plan zarządzania ryzykiem nie
318 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
powiedzie się i ryzyko wystąpi. Innymi słowy, zidentyfikuj, co się stanie w projekcie, jeśli ryzyko przekształci się w problem krytyczny. To pomaga kierownikowi projektu upewnić się, że wysiłek związany z realizacją Planu Zarządzania Ryzykiem jest adekwatny do konsekwencji wystąpienia ryzyka. Na przykład, gdy ryzyko stanie się faktem (kwestią krytyczną) projekt będzie musiał być zatrzymany. To powinno być wyraźną wskazówką, że Plan zarządzania ryzykiem musi być agresywny i wszechstronny, aby upewnić się, że ryzyko będzie skutecznie zarządzane. 7
8
9
Kierownik projektu
Oceń ryzyka o średnim poziomie.
Kierownik projektu
Oceń ryzyka o niskim poziomie.
Kierownik projektu
Umieść czynności związane z obsługą ryzyka w harmonogramie projektu.
Sprawdź wszystkie ryzyka o średnim poziomie. Jeśli ich wpływ jest wystarczająco duży - należy stworzyć plan odpowiedzi na dane ryzyko.
Sprawdź ryzyka o niskim poziomie. Zdecyduj, czy powinny być wpisane na jako założenia. W ten sposób rozpoznajesz, że jest możliwość wystąpienia problemu, ale z powodu niskiego ryzyka, zakładasz, że on nie wystąpi. Więcej informacji w rozdziale 7.1.3.Zarządzanie ryzykiem/Założenia i ryzyko.
Umieść czynności związane z obsługą ryzyka w Harmonogramie projektu. Umieszczenie czynności w harmonogramie powoduje, że obsługa ryzyk jest w rzeczywistości planowana, realizowana i kontrolowana.
Procesy w toku. 7.1.2.P7 Monitorowanie i kontrola ryzyka
10
11
Kierownik projektu
Monitoruj bieżące plany związane z obsługą ryzyka.
Kierownik projektu
Obserwuj nowe ryzyka.
Kierownik projektu musi kontrolować Plan Zarządzania Ryzykiem w celu upewnienia się, że ryzyka są skutecznie zarządzane. Nowe czynności do planu ryzyka powinny zostać dodane w przypadku, gdy istnieje podejrzenie, że ryzyko nie jest skutecznie obsługiwane.
Kierownik projektu musi okresowo ocenić ryzyko całego projektu opierając się na bieżących informacjach. W trakcie rozwoju projektu mogą pojawić się nowe ryzyka, a niektóre, które nie zostały zidentyfikowane od razu, mogą pojawić się później. Może również zaistnieć sytuacja, gdzie wcześniej zidentyfikowane ryzyko o niższym w poziomie w miarę upływu czasu zwiększy się do średniego lub wysokiego. Bieżąca ewaluacja ryzyka powinna być
319 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wykonywana regularnie lub po osiągnięciu (przy weryfikacji) kamieni milowych projektu.
320 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.1.3 Zarządzaj ryzykiem / Założenia i ryzyko 7.1.3.P1 Założenia są bardzo związane z ryzykiem. W rzeczywistości są po prostu ryzykami o niskim poziomie. Są przyszłymi wydarzeniami lub warunkami, które negatywnie wpłyną na projekt, są poza kontrolą zespołu projektowego. Drugim typem zjawisk i zdarzeń, jakie należą do założeń są to te, które musza się wydarzyć (mają pozytywny wpływ na projekt) aby projekt się powiódł. Np. zakłada się, że zarząd będzie akceptował fakt prowadzenia pracy przy projekcie, zakłada się, że każdy członek zespołu działa w dobrej wierze. W obu przypadkach ryzyk i założeń istnieje prawdopodobieństwo wystąpienia i wpływu na projekt. Różnica pomiędzy założeniem a ryzykiem jest taka, że jeśli zdarzenie zostanie zakwalifikowane jako założenie, nie będą podejmowane żadne czynności zabezpieczające. Jeśli dane zaś zdarzenie jest uznane za ryzyko, jest ono analizowane podczas monitoringu ryzyk, buduje się plan odpowiedzi na nie etc. Weźmy przykład powszechnego stwierdzenia, które jest zawarte w wielu Definicjach Projektu: “Zasoby potrzebne do celów projektu będą dostępne w razie potrzeby.” Jaki to jest rodzaj stwierdzenia? Wielu ludzi uznało by to za założenie. Ponieważ, kiedy rozpoczyna się projekt, zawsze zakładasz, że otrzymasz zasoby, których potrzebujesz. Czy to naprawdę jest założenie? Prawdopodobnie znasz przypadki lub możesz wyobrazić sobie rozpoczęcie projektu, w którym ludzie i sprzęt nie byli dostępni, np. ponieważ kończą inny projekt. Jest to nawet całkiem częste. Dlatego to stwierdzenie powinno być zdefiniowane jako ryzyko – a nie założenie. Kluczowe jest to, że samo stwierdzenie może być założeniem lub ryzykiem zależnie od okoliczności poszczególnego projektu. Różnica pomiędzy założeniem a ryzykiem jest wtedy, kiedy kombinacja prawdopodobieństwa i wpływu są dla Ciebie akceptowalne lub nie. Jeśli wydarzenie jest negatywne i kombinacja prawdopodobieństwa i wpływu nie są dla Ciebie akceptowalne (kombinacja jest zbyt wysoka), musi to być ryzykiem. Sposobem do identyfikowania istotnych założeń jest dokonanie oszacowania ryzyka (patrz: 7.2.1 Wrodzone Czynniki Ryzyka). Należy zdecydować, które z ryzyk o niskim poziomie nie są warte uwagi i mogą być uznane za założenia. Istnieją dwie cechy charakterystyczne ryzyk i założeń. Po pierwsze, musi być pewna niewiadoma zdarzenia. Jeśli występuje 100% szansa wystąpienia zdarzenia, jest to po prostu przyszły fakt. Jeśli szansa wystawienia jest zerowa, jest to fikcja. Żadne nie jest wtedy ryzykiem ani założeniem. Po drugie, założenia i ryzyka są poza całkowitą kontrolą zespołu projektowego. Jeśli zdarzenie jest pod kontrolą zespołu projektowego, nie jest to ani założenie, ani ryzyko. Powinno być po prostu zarządzane jako część harmonogramu. Przejrzyj następujące przykłady w celu uzyskania większej jasności odnośnie założeń i ryzyk.
321 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Stwierdzenie
Założenie, ryzyko czy inne?
Będziemy mieli silne wsparcie dla inicjatywy od naszego sponsora wykonawczego.
Nie można stwierdzić, czy jest to ryzyko, czy założenie. W zależności od projektu, może być to ryzyko – gdy istnieje szansa utraty wsparcia sponsora i trzeba zaplanować działania zapobiegawcze. W innym projekcie zaś prawdopodobieństwo utraty wsparcia będzie nikłe i zakłada się, że nie ma sensu poświęcać temu jakiejkolwiek uwagi.
Serwery testowe i produkcyjne zostaną zainstalowane zanim będziemy gotowi do testów integralności.
Nie można stwierdzić, czy to jest ryzyko, czy założenie. Zależnie od projektu - może występować wysoki stopień ryzyka w tym stwierdzeniu (ryzyko) lub bardzo niewielka szansa na tego rodzaju problemy (założenie).
Betonowe piętro ma 12 cali głębokości.
To stwierdzenie jest faktem lub wymaganiem i nie jest ryzykiem lub założeniem. Opisuje przedmiot dostawy.
Ukończymy definiowanie wymagań biznesowych przed początkiem prac projektowych.
To jest cześć podejścia realizacyjnego lub harmonogramu. Nie jest to ryzyko, ani założenie, ponieważ znajduje się w zakresie kontroli zespołu projektowego.
Nasi sprzedawcy będą gotowi spełnić wymagania do 1-go października.
Nie można stwierdzić, czy jest to ryzyko, czy założenie. Zależnie od projektu, może występować wysoki stopień ryzyka w tym stwierdzeniu (ryzyko) lub bardzo niewielki (założenie).
Musimy udać się na Pluton, aby otrzymać potrzebne fragmenty meteoru, którego wymaga projekt.
To nie jest ryzyko, ani założenie, ponieważ nie zawiera to sytuacji ryzykownych. Jest to fikcja (0% prawdopodobieństwa).
Pojazd musi być w stanie wytrzymać zderzenia przy 55 km/h.
To stwierdzenie jest wymaganiem biznesowym i nie jest ryzykiem, ani założeniem. Opisuje przedmiot dostawy.
Jest 90 km drogi od jednego zespołu projektowego do innego.
To nie jest ryzyko, ani założenie, ponieważ nie zawiera w sobie ryzyka. Jest to fakt (100% prawda). (Jeśli nie byłaby to prawda, byłaby to fikcja (0% prawdy), ale wciąż nie byłoby to założenie czy stwierdzenie ryzyka.)
322 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.2 Zarządzanie ryzykiem / Techniki 7.2.P1 Użyj jednej z pięciu strategii odpowiedzi na ryzyko W przypadku, gdy ryzyko zostało zidentyfikowane, istnieje wiele typów strategii, które kierownik projektu może podjąć przy opracowywaniu odpowiedzi względem ryzyka.
Ignorowanie ryzyka. W tym podejściu, kierownik projektu decyduje, aby nic nie robić. Tak może się zdarzyć dla jednego z trzech przypadków:
Kierownik projektu ocenia, że wpływ ryzyka na projekt jest na tyle niski lub nikły,
aby wymagane było opracowanie jakiejkolwiek odpowiedzi na ryzyko. Strategia stosuje się dla ryzyk o niskim i średnim poziomie.
Kierownik projektu uznaje, że wpływ ryzyka na projekt, jeśli wydarzyło by się, jest podobny do kosztów zabezpieczania się. W tym wypadku lepiej zgodzić się na koszt ryzyka – może nie wystąpić, niż ponosić pewne koszty przeciwdziałania.
Kierownik
projektu uznaje, że nie ma praktycznego sposobu, aby zarządzać ryzykiem, nawet jeśli ryzyko zostało zidentyfikowane jako wysokie. Na przykład, możliwe jest, że występuje ryzyko zmiany sponsora (odejście z organizacji) oraz że nowy nakaże wycofać się z projektu.
Monitorowanie
ryzyk. W tym podejściu, kierownik projektu nie zarządza proaktywnie ryzykiem, ale monitoruje, czy jest bardziej, czy mniej prawdopodobne w miarę upływu czasu. Jeśli wygląda na to, że ryzyko wystąpi, zespół musi sformułować różne plany obsługi ryzyka, ale w trakcie realizacji, nie podczas definiowania projektu. To podejście może sprawdzić się w ryzykach o wysokim wpływie na projekt i niskim prawdopodobieństwie. Kierownik projektu tworzy plan tylko jeśli prawdopodobieństwo zwiększyło się. Zaletą jest to, że rzadkie zasoby są wykorzystywane jedynie dla tych ryzyk, które prawdopodobnie naprawdę mogą się pojawić. Wadą jest to, że opóźnienie w oddziaływaniu na ryzyko może spowodować, że będzie ono słabiej zarządzanie w przyszłości. Dobrze jest zidentyfikować także ryzyko, które powinno być zarządzane ponieważ ma znaczący wpływ na projekt, ale które może mieć miejsce dalszej w przyszłości. Na przykład, jeśli zdarzenie ma prawdopodobieństwo wystąpienia za 9 miesięcy, nie ma sensu rezerwować zasobów w tym okresie na obsługę ryzyka. Lepszym podejściem może być miesięczne monitorowanie tego ryzyka. Jest możliwe, że z upływem czasu ryzyko zmaleje. Jeśli prawdopodobieństwo ryzyka nie zmniejszy się, zespół będzie musiał poradzić sobie z ryzykiem w następnych miesiącach.
Unikanie ryzyka. Strategia ta oznacza, że czynniki, które powodują problem, są
eliminowane. Na przykład, jeśli twój dostawca generuje ryzyko, strategia unikania ryzyka sugeruje aby go zmienić. Jest to bardzo efektywny sposób radzenia sobie z ryzykami, ale oczywiście może być stosowany tylko w pewnych okolicznościach. Strategię unikania ryzyka można zastosować do projektu polegającego na wprowadzaniu danego rozwiązania w wielu lokalizacjach. Kiedy ryzyko zostanie dostrzeżone, sponsor może zmienić zakres projektu i np. nakazać wprowadzania rozwiązań tylko w jednym miejscu. W ten sposób, ryzyko wprowadzenia w wielu lokalizacjach zostanie uniknięte.
323 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Przeniesienie
ryzyka. W pewnych przypadkach, odpowiedzialność za ryzyko może zostać usunięta z projektu poprzez przeniesienie go na stronę trzecią. Na przykład outsourcing - pozwala wyeliminować ryzyko, przesuwając go zespołu projektowego na podnajętego wykonawcę. Strona trzecia dysponuje szczególnymi zdolnościami, które pozwolą wykonywać pracę bez ryzyka. Nawet jeśli ryzyko nie zniknie przez to – odpowiada za nie strona trzecia.
Innym przypadkiem przesunięcia ryzyka jest kupno ubezpieczenia. Możesz mieć bardzo wartościowy, aczkolwiek delikatny sprzęt, który powinien być dostarczony do zespołu projektowego. Istnieje ryzyko, że zostanie on uszkodzony. Możesz przesunąć ryzyko finansowe poprzez ubezpieczenie ładunku. Jeśli ładunek byłby uszkodzony wprawdzie tracisz czas oczekując na części zamienne oraz naprawę, jednakże, nie ponosisz ryzyka finansowego. W zamian za to, że wcześniej zapłacono ubezpieczenie, ubezpieczyciel ponosi ryzyko finansowe.
Zapobieganie, łagodzenie ryzyka. Strategia ta jest stosowana w największej
ilości przypadków. Strategia ta oznacza, że umieszczasz w planie proaktywne (zapobiegawcze) kroki, aby dążyć do tego, że ryzyko nie wystąpi. Drugim celem tej strategii jest upewnienie się, że jeśli ryzyko wystąpi, jego negatywny wpływ będzie minimalizowany. (Ideą Procesów Zarządzania Projektem TenStep jest to, że Plan Zarządzania Ryzykiem powoływany jest aby zapobiegać ryzykom).
7.2.P2 Myśl o pozytywnym ryzyku jako o sposobie na osiągnięcie korzyści Ryzyko jest zwykle łączone z potencjalnymi zdarzeniami, które mają negatywny wpływ na projekt. Jednakże jest także koncepcja ryzyka jako okazji lub zdarzenia, potencjalnego lecz pozytywnego. W tych przypadkach, kierownik projektu lub zespół projektowy może wprowadzić takie ryzyko, aby spróbować uzyskać znacznie więcej profitów w późniejszym czasie. Na przykład, zespół może zdecydować się na wykorzystanie nowej technologii w projekcie, ponieważ uważa, że to może zmniejszyć wysiłek i oszczędzić koszty. Oczywiście, jest także możliwość, że nowa technologia nie sprawdzi się. Jednakże zespół wprowadzi takie ryzyko z powodu potencjalnych profitów. Jest to przykład inteligentnego podejmowania ryzyka lub ryzyka pozytywnego. (Proces Zarządzania Projektem TenStep zakłada, że ryzyka którymi zarządzasz są negatywne. Te ryzyka powinny być obsługiwane w taki sposób, aby grożące problemy nie pojawiły się.) 7.2.P3 Upewnij się czy twoje ryzyka mają pewien stopień niepewności Jeśli zdarzenie jest identyfikowane jako ryzyko, musi mieć pewien stopień niepewności, prawdopodobieństwa. Z drugiej strony, jeśli zdarzenie jest prawdopodobne na 100%, nie jest ryzykiem. (Czasem te 100% zdarzenia “ryzyka” są zwane także ograniczeniami. Ograniczenie jest zdarzeniem lub czynnikiem, które wpływa na projekt i musi być wzięte pod uwagę.) Ryzyko ma pewne prawdopodobieństwo wystąpienia pomiędzy 0% a 100%. Jeśli zdarzenie ma zerowe szanse wystąpienia, powinno zostać zignorowane. Jeśli posiada 100% szansę wystąpienia, jest faktem (i prawdopodobnie ograniczeniem). Kiedy zarządzasz ryzykiem, powinieneś skupić się na ryzykach - nie na faktach i fikcjach. 7.2.P4 Rozróżniaj ryzyka, przyczyny i skutki
324 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Dla każdego ryzyka o ile się wydarzy, istnieją przyczyna i skutek. Kiedy ryzyka są zidentyfikowane, upewnij się, że to ryzyko samo w sobie, a nie jego przyczyna lub skutek są odnotowane. Przyczyną jest istniejąca sytuacja, okoliczności, które tworzy warunki w jakich powstaje ryzyko, są to pewne na 100|% fakty. Skutkiem zaś są konsekwencje, szkody jakie ryzyko wyrządzi w projekcie. Spójrz na następujący przypadek. Powiedzmy, że pewne rozwiązanie techniczne powinno być wprowadzone w ramach projektu we wszystkich lokalizacjach międzynarodowej firmy, włączając w to kraje rozwijające się. Jeśli np. linie telekomunikacyjne nie będą na czas zmodernizowane, implementowanie rozwiązania na pewno nie będzie tam możliwe. Co jest ryzykiem w przykładzie?
fakt, że musisz wprowadzić rozwiązanie w krajach rozwijających się? Nie, to jest przyczyna. Jest to fakt lub wymaganie biznesowe, związane z przedmiotem dostawy tego projektu.
to,
że rozwiązanie nie będzie dostępne w pewnych krajach? Nie, jest to potencjalny skutek, który może się wydarzyć.
modernizacja
linii telekomunikacji nie jest wykonana w czasie? Tak, w tym właśnie pojawia się niepewność.
7.2.P5 UWZGLĘDNIJ W BUDŻECIE I HARMONOGRAMIE OBSŁUGĘ RYZYK NIEZNANYCH
Kierownik projektu może wnioskować o przyznanie budżetu na obsługę ryzyka zidentyfikowanego na początku projektu i oszacowanego na podstawie analiz jakościowych. Jednakże identyfikacja ryzyka nie jest czymś, co zdarza się tylko na początku projektu. Kierownik projektu powinien oceniać ryzyka w trakcie projektu. W średnich i dużych projektach jest sensownym zarezerwowanie środków w budżecie oraz czasu w harmonogramie na ocenę ryzyk nieznanych. Szczególnie jest to ważne dla projektów o znacznej ilości ryzyk wysokiego poziomu. Jeśli wykonujesz efektywnie okresowe oszacowanie ryzyk, możesz odkryć nowe ryzyka, które nie są zawarte w budżecie na obsługę ryzyk nieznanych. Z dotychczasowych doświadczeń wynika, że może być dodane 5% do budżetu awaryjnego, na obsługę ryzyk nieznanych, niezidentyfikowanych podczas definiowania projektu. (Pamiętaj, że czas na zapobieganie / zarządzanie rozpoznanymi ryzykami nieznanymi powinien być włączony także do oszacowań.) 7.2.P6 Włącz członków zespołu do identyfikacji ryzyk Jeśli członkowie zespołu zapoznali się z okolicznościami projektu, mogą odgrywać aktywną rolę w identyfikowaniu i ocenianiu ryzyk projektu. Uczestnictwo zespołu pomoże zidentyfikować ryzyka projektu, opracować efektywne działania do zarządzania ryzykiem i dać konsensus oraz wykonanie. 7.2.P7 Badaj koszty zarządzania ryzykiem w Planie zarządzania ryzykiem dla poziomów ryzyka Wszystkie projekty mają pewne ryzyko a czynności związane z zarządzaniem ryzykiem mają oczywiście koszty. Kierownik projektu oraz klienci powinni upewnić się, że wysiłek i koszt związany z zarządzaniem ryzykiem nie przekracza dozwolonego zagrożenia 325 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektu w przypadku pojawienia się ryzyka. W przypadku wysokich ryzyk, zwykle nie jest to przedmiotem dyskusji. Jednakże, jeśli zarządzasz średnimi ryzykami, upewnij się, że łączone koszty i korzyści odpowiadające ryzyku nadają sens projektowi. Jeśli koszt zarządzania ryzykiem jest większy niż wpływ ryzyka na projekt, nie ma sensu zarządzanie nim. Jest możliwe, że w przypadku, kiedy koszt zarządzania ryzykiem jest większy niż wpływ ryzyka, możesz po prostu zostawić i zignorować to ryzyko. 7.2.P8 Rozpoznaj poziom tolerancji ryzyka w swojej organizacji We wszystkich projektach występuje jakieś ryzyko a wszystkie ryzyka mają potencjalnie negatywny wpływ na projekt. Zarządzania ryzykiem używa się, aby określić ryzyka, które są wystarczająco ważne, aby nimi zarządzać. W trakcie procesu identyfikacji ryzyka, możesz napotkać wiele ryzyk, które mają pewne prawdopodobieństwo i marginalny wpływ. Należy zadać pytanie: Czy to ryzyko ma wystarczający wpływ na projekt, aby się nim martwić? (pojawia się to samo pytanie w ilościowych i jakościowych podejściach). Odpowiedź na to pytanie pokazuje poziom tolerancji na ryzyko. Na przykład, powiedzmy, że identyfikujesz ryzyko, które jest bardzo prawdopodobne, ale ma wpływ o wartości 100€ a trwa pół dnia. Możesz wybrać, nie przejmować się tym. Nie możesz jednak wpisać tego do listy założeń, ponieważ jest duża szansa pojawienia się tego ryzyka. Jednakże wpływ jest zbyt mały, aby wydawać na nie środki w razie jego wystąpienia. Dlatego mógłbyś wybrać strategie zarządzania ryzykiem polegającą na zignorowaniu go. Powiedzmy teraz, że ryzyko wynosi 100,000 € i trwa przez trzy miesiące? Oczywiście odpowiedzi nie są jednoznaczne – zależą od rozmiaru projektu. Jeśli projekt ma budżet 20,000 €, ryzyko ma wpływ 1,000 € - może być warte zarządzania. Jeśli budżet projektu wynosi jeden milion euro, to wpływ rzędu 1,000 € byłby marginalny. Kiedy dokonujesz identyfikacji ryzyka, musisz określić poziom tolerancji dla ryzyk. Ułatwi Ci to skupienie się na ryzykach, które są istotne i plasują się powyżej Twojego poziomu tolerancji. Ignorowanie ryzyka powoduje jego spadek poniżej poziomu tolerancji. Tolerancja na ryzyko jest cechą charakterystyczną kultury organizacji. Pewne firmy podejmują większe ryzyko i akceptują jego wysoki poziom w projekcie. Mogą one dopuścić wyższy poziom ryzyk w projektach. Z drugiej strony, pewne organizacje są bardziej przeciwne ryzyku. Skłaniają się one do akceptowania mniej ryzykownych projektów i będą miały niższy próg tolerancji na ryzyka. Powiedzmy, że masz podobny projekt w obu organizacjach. Kierownicy projektu w tej niechętnej ryzyku organizacji będą skłonni zarządzać ryzykami, które kierownik projektu w innych organizacjach mógłby pominąć. 7.2.P10 Użyj drzewek decyzji, aby dokonać wielorakiej analizy powiązanych ryzyk Jednym ze sposobów policzenia rezultatów finansowych współzależności ryzyka na projekt jest użycie drzewka decyzji. Drzewko decyzji jest techniką na określenie ogólnego wpływu powiązanych ze sobą ryzyk. Drzewka decyzji są dobrymi technikami, kiedy masz następujące cechy charakterystyczne:
Prawdopodobieństwo jednego ryzyka bazuje na skutkach wcześniejszego ryzyka. To znaczy, że ryzyka są powiązane.
Jest niewielka liczba możliwych skutków dla każdego punktu decyzyjnego – a nie duża. Jeśli istnieje duża liczba potencjalnych pojawień się, ta technika może być bardzo skomplikowana.
326 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Są implikacje kosztowe kalkulacji ryzyka.
Spójrz na następujący przykład drzewa decyzji.
To drzewko decyzji pokazuje dwa ryzyka. Ryzyko A ma dwa skutki. Rezultat 1 ma 20% prawdopodobieństwa i rezultat 2 ma 80% prawdopodobieństwa wystąpienia. Wartość kosztowa ryzyka A wynosi 10,000 $. Jeśli pojawi się rezultat A, wprowadzane jest Ryzyko B i możliwe są trzy rezultaty (25%, 70%, 5%), 1.1, 1.2 i 1.3. Wartość kosztowa ryzyka B wynosi 30,000 $. Używając drzewka decyzji, obserwujesz ryzyka finansowe różnych rezultatów według schematu: 1.1
9,500 $
(10,000 $* .2) + (30,000 $* .25)
1.2
23,000 $
(10,000 $* .2) + (30,000 $* .70)
1.3
3,500 $
(10,000 $* .2) + (30,000 $* .05).
2
8,000 $
(10,000 $* .8)
W tej sytuacji Twoim celem powinno być zapobiegać ryzyku A, aby nie pojawiło się. Jednakże, jeśli nie jesteś w stanie zapobiegać temu ryzyku, analizy pokazują, że powinieneś spróbować osiągnąć wynik 1.3. Ma on najmniejszy wpływ. Jeśli sądzisz, że nie jesteś w stanie osiągnąć rezultatu 1.3, powinieneś próbować osiągnąć rezultat 2. Nawet jeśli jego implikacje są większe niż implikacje ryzyka wyniku 1, istnieje drugie ryzyko połączone z wynikiem 1 i ryzyko B ma 95% prawdopodobieństwa, aby utrzymać całkowitą wartość wciąż wyższą.
327 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.2.1 Zarządzanie ryzykiem / Wrodzone czynniki ryzyka 7.2.1.P1 Ryzyka wrodzone (generyczne) to takie, które bazują na ogólnych cechach projektu. Są to ryzyka, które mogą pojawić się niezależnie od tego, co de facto dostarcza projekt, w jakiej dziedzinie jest realizowany. Żaden z czynników ryzyka wrodzonego nie oznacza, że projekt znajduje się w trudnej sytuacji. Wiele z tych nich będzie powiązane z ryzykami o niskim lub średnim poziomie. Poniższa Lista kontrolna pokazuje ponadto, że duże projekty mają większą podatność na ryzyko wrodzone niż małe. Pamiętaj także, że jeśli projekt mieści się w kategorii wysokiego ryzyka, nie oznacza to, że nie osiągnie powodzenia. Natomiast powinieneś bardziej intensywnie zarządzać ryzykiem. Tabela poniżej identyfikuje cechy charakterystyczne, które mogą rodzić ryzyka. Wskazuje też kryteria, które pozwalają dowiedzieć się, czy jest to ryzyko wysokie czy niskie. W zależności od tego, gdzie się mieszczą cechy charakterystyczne projektu, możesz ocenić, czy ryzyko może być wysokie, średnie czy niskie (średnie ryzyka mieszczą się pomiędzy ekstremami). Ten typ listy może być wyjątkowo wartościowy, jeśli Twoja organizacja przystosuje ją do swojej specyfiki i udostępni wszystkim menedżerom projektów. Na przykład, możesz uznać, że w Twojej organizacji projekt mający mniej niż 5,000 godzin jest uznawany za przedsięwzięcie o niskim ryzyku taki, który ma 20,000 godzin lub więcej, jest projektem wysokiego ryzyka. Jeśli po projektach organizuje się w Twojej organizacji spotkania podsumowujące, zespoły mogą przejrzeć dokumenty projektu, szczególnie dotyczące ryzyka, plan odpowiedzi na ryzyka i ich rezultaty. Wynik takiego przeglądu może być podstawą uaktualnienia List Kontrolnych dot. Ryzyka, zbiorów najlepszych praktyk czy wniosków z realizacji projektu. W tabeli poniżej, ryzyka o średnim poziomie znajdą się między ryzykami wysokiego i niskiego poziomu. Na przykład, jeśli wielkość twojego zespołu wynosi 15, będzie to czynnik ryzyka o średnim poziomie. Podobnie mogą wystąpić średnie ryzyka w projekcie gdzie zakres i przedmioty dostawy są lepsze niż „słabo-zdefiniowane” i gorsze niż „dobrze zdefiniowane”. Może być sytuacja, gdy pewne przedmioty dostawy były słabo określone inne lepiej. Poniższa Lista Kontrolna może być użyta do określania, czy w projekcie mogą wystąpić ryzyka wrodzone, których nie rozważyłeś.
Cechy charakterystyczne
Możliwe wysokie ryzyko
Całkowita pracochłonność
Duży projekt > 2500 godzin Mały projekt godzin
Czas trwania
Dłużej niż 12 miesięcy
Mniej niż 3 miesiące
Wielkość zespołu
Powyżej 25 członków
Mniej niż 5
328 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Możliwe niskie ryzyko <
250
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Ilość klientów
Więcej niż trzy
Zakres projektu / przedmioty Słabo określone dostawy Korzyść przedsięwzięcia
Jeden Dobrze określone
Nie jasna (nie powinno się Dobrze określona rozpoczynać projektu)
Zespół projektowy i wiedza o Ani zespół projektowy, ani I zespół projektu i klient przedsięwzięciu klienta klient nie mają solidnej mają solidną wiedzę o wiedzy o przedsięwzięciu przedsięwzięciu Bardzo skomplikowane, Łatwe do określenia dla ciężkie do określenia dla klienta klienta
Wymagania
Zależność od projektów lub zewnętrznych
innych Zależne od trzech lub Nie więcej niż jedna zespołów więcej projektów zależność na projekt zewnętrznych lub zespołów zewnętrzny lub zespół
Sponsor projektu
Nieznany (nie powinno się Zidentyfikowany zaczynać projektu) entuzjastyczny
Zaangażowanie klienta
Nieznane, pasywne
Zmiany wymagane w Duża ilość zmian istniejących procedurach, procesach i strategiach Struktury organizacji Doświadczenie projektu Lokalizacja zespołu Użycie metodyki
Duża ilość zmian
i
Porywcze Niewielkie zmiany
Niewielkie zmian
lub
brak
kierownika Niewielkie doświadczenie w Podobne doświadczenie podobnym projekcie w wielorakich projektach Zespół jest rozmieszczony Zespół jest pracuje w w kilku miejscach jednym miejscu
sformalizowanej Nie stosuje się Metody stosowane są sformalizowanych metod, standaryzowane metodyk i procesów
Technologia
Kluczowe komponenty i Nowa technologia składowe rozwiązania są jest wymagana oparte na nowej technologii
nie
Czas reakcji
Krytyczny. Projekt musi Akceptowalny zapewnić bardzo krótki czas zwykły czas reakcji reakcji zespołu.
jest
Jakość danych
Dane są niskiej jakości
Dane są dobrej jakości
Dostawca
Nowy.
Znany, mamy dobre relacje.
329 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
z
nim
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
7.2.2 Zarządzanie ryzykiem / Oczekiwana wartości pieniężna (EMV) 7.2.2.P1 Oczekiwana wartość pieniężna (EMV) jest techniką zarządzania ryzykiem, która może być użyta, aby pomóc określić ilość oraz porównać ryzyka wielu aspektów projektu. EMV to techniki ilościowych analiz. Polegają bardziej na określonych liczbach i wartościach kalkulowanych, niż na przybliżeniach typu: wysoki, średni i niski. EMV opiera się na trzech podstawowych parametrach ilościowych. P – prawdopodobieństwo, że ryzyko wystąpi I – wpływ na projekt jeśli ryzyko wystąpi, może być rozbity na: Ic - wpływ na koszty projektu Is – wpływ na harmonogram Ie – wpływ na pracochłonność projektu 7.2.2.P2 Rezerwa budżetowa na obsługę ryzyka Jeśli używasz tej techniki dla wszelkiego rodzaju ryzyk, możesz wnioskować o przyznanie budżetu awaryjnego na obsługę ryzyka, aby pokryć straty wywołane przez ryzyko, jeśli się wydarzy. Na przykład, powiedzmy, że zidentyfikowałeś sześć ryzyk w projekcie, są one następujące.
Budżet na obsługę na ryzyka
Ryzyko
P (Prawdopodobieńst wo ryzyka)
Ic (Wpływ koszty)
A
.8
10,000 $
8,000 $
B
.3
30,000 $
9,000 $
C
.5
8,000 $
4,000 $
330 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
D
.10
40,000 $
4,000 $
E
.3
20,000 $
6,000 $
F
.25
10,000 $
2,500 $
118,000 $
33,500 $
Razem
Bazując na identyfikacji tych sześciu ryzyk, potencjalny wpływ na koszt projektu wynosi 118,000 $. Jednakże nie możesz wnioskować o przyznanie budżetu na obsługę ryzyk w tej wysokości. Jedyna przesłanka dla przyznania całej tej sumy jest wysokie prawdopodobieństwo, graniczące z pewnością, że wszystkie te ryzyka wydarzą się. Pamiętaj, że celem zarządzania ryzykiem jest zapewnienie, że ryzyka nie zaistnieją. Dlatego od kierownika projektu oczekuje się, że większość ryzyk, jeśli nie wszystkie, nie wystąpią, dzięki skutecznemu zarządzaniu nimi. Budżet awaryjny powinien być adekwatny faktycznego poziomu wpływ ryzyka na projekt jak i do jego prawdopodobieństwa. W powyższej tabeli adekwatną wielość na obsługę ryzyk zamieszczono w ostatniej kolumnie. Zauważ, że całkowite zapotrzebowanie na budżet awaryjny ryzyk wynosi 33,500 $ i taka właśnie kwota może zostać dodana do budżetu. Jeśli obecnie wystąpiło ryzyko C i F, będziesz w stanie pokryć je z budżetu awaryjnego. Zauważ natomiast, że jeśli wystąpiło ryzyko D, budżet awaryjny może nie być wystarczający. Jednakże, ryzyko D ma tylko 10% szansy wystąpienia. Zespół projektowy powinien realnie skupić się więc tym na ryzyku i zarządzać nim skutecznie. Nawet, jeśli nie ma możliwości całkowicie poradzenia sobie z tym ryzykiem, jego wpływ na projekt zostanie minimalizowany przez proaktywne zarządzanie nim. 7.2.2.P3 Dywersyfikacja ryzyka Budżet awaryjny na obsługę ryzyk sprawdza się, kiedy obejmuje wiele istniejących ryzyk. Im więcej ryzyk zidentyfikuje zespół, tym bardziej narzut w budżecie i planie powinien być wystarczający ich obsługę. W sytuacji przedstawionej powyżej, fakt, że istnieje sześć ryzyk pomaga przydzielić wystarczający, skumulowany budżet awaryjny. Istnieje małe prawdopodobieństwo, że wszystkie 6 ryzyk wystąpi jednocześnie i przyznany budżet nie wystarczy. Inaczej się rzecz ma gdy na przykład, zidentyfikowałeś tylko jedno ryzyko podobne do ryzyka D i wnioskujesz o dodatkowe 4,000 $ na jego obsługę. Możesz okazać się, że jesteś w sytuacji bez wyjścia. Jeśli ryzyko nie występuje, nie potrzebujesz 4,000 $, ale jeśli ryzyko wystąpi - 4,000 $ nie będą wystarczające. Nie oznacza to, że narzut ten nie powinien zostać przyznany. Dodatkowe pieniądze rzadko przeszkadzają. Jednak budżety na obsługę ryzyk sprawdzają się lepiej, jeśli odnoszą się one do zidentyfikowanych licznych ryzyk. 7.2.2.P4 Wyasygnowanie funduszy na nieznane ryzyka Powyższa kalkulacja EMV jest adekwatna tylko sześciu ryzyk, które są znane na początku projektu. Jeśli zarządzasz dużym projektem, musisz kontynuować monitorowanie ryzyk na zmieniających się danych. Dlatego możesz także prosić o dodatkowy budżet na obsługę ryzyk, które prawdopodobnie zidentyfikujesz dopiero podczas realizacji projektu. Z doświadczeń wynika, że powinieneś poprosić o dodatkowe 331 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5% całkowitego budżetu na obsługę ryzyka na pokrycia nieznanych ryzyk, na które się natkniesz później. Jest to dodatkowa część budżetu dodawana do części na pokrycie znanych już ryzyk, które zostały zidentyfikowane.
7.3 Zarządzanie ryzykiem / Podsumowanie 7.3.P1 Przedmiot dostawy: Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Arkusz kalkulacyjny ryzyka Lista kontrolna czynników ryzyka Arkusz identyfikacji ryzyk Plan zarządzania ryzykiem Przegląd ryzyka Formatka zgłoszenia ryzyka Dziennik śledzenia ryzyka 7.3.P2 Harmonogram Te czynności są dodawane do harmonogramu w celu monitorowania i zarządzania ryzykiem. Zakłada się, że wstępne czynności identyfikowania ryzyka zostały ukończone na etapie Definiowania Projektu.
Rozmia r
Potrzebne dane
Małe
Nie istnieją dodatkowe czynności dla małych projektów.
Średnie Duże
Czynność
Czaso chłonn Komentarze ość
Identyfikuj i analizuj wszelkie ryzyka w projekcie. Stwórz Plan zarządzania ryzykiem dla każdego ryzyka o
Różna
To może być banalne ćwiczenie lub ogromna praca. Zależy to od projektu
332 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wysokim poziomie i pewnych ryzyk o średnim poziomie. Dodaj wszelkie czynności planu zarządzania Różna ryzykiem do harmonogramu projektu.
Po zdefiniowaniu projektu (1.0), dodaj czynności do harmonogramu, z datami początkowymi i końcowymi. Przypisz zasoby do wszystkich czynności.
Przejrzyj status 1-2 Planu zarządzania godzin ryzykiem. y
Tygodniowo lub dwutygodniowo. Zawsze jest to odpowiedzialność kierownika projektu. Przegląd ten ma upewnić Cię, że zachodzi postęp i wykonywane są z powodzeniem Plany zarządzania ryzykiem.
Oceń projekt pod 1 kątem nowego godzin ryzyka. a
Miesięcznie. Zrób krok wstecz i oceń pozostałą pracę w projekcie, aby określić, czy są nowe ryzyka, które powinny być zarządzane.
333 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 8 Zarządzanie Zasobami Ludzkimi
334 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.0 Zarządzanie Zasobami Ludzkimi
8.1 Zarządzanie Zasobami Ludzkimi / Proces [ wykreślono z edycji polskiej ]
8.2 Zarządzanie Zasobami Ludzkimi / Techniki Poniżej przedstawionych jest kilkanaście technik zarządzania zasobami ludzkimi / personelem. 8.2.2 Techniki Pozyskiwania Pracowników 8.2.3 Rozwój Grupy Projektowej 8.2.4 Zarządzanie Zespołem Projektowym
335 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.2.2 Techniki pozyskiwania pracowników 8.2.2.P1 Techniki szczególne dla grup rozproszonych W przeszłości zespół projektu rezydował zwykle w jednym miejscu. Powód tego był oczywisty: problemy z komunikacją i współpracą na odległość. W obecnych czasach ciągle powszechna jest współpraca na relatywnie niewielkie odległości. Jednakże coraz częściej członkowie zespołu znajdują się w wielu różnych lokalizacjach. Może to być spowodowane wykorzystaniem zasobów z innych oddziałów firmy lub zatrudnianie ludzi na zasadach telepracy. W ten sposób realizowana może być współpraca z firmą z zewnątrz - nawet w innym kraju. Umożliwia to rozwój nowych technologii i oprogramowania. Ludzie mogą mieć zdalny dostęp do firmowej sieci komputerowej z prawie taką samą szybkością jakby znajdowali się w biurze. Możliwe jest współdzielenie dokumentów i zdalne dokonywanie poprawek. Poprzez telekonferencje można kontaktować się z pozostałymi członkami grupy. To są te dobre wiadomości. Niestety ciągle łatwiej jest kierować pracą zespołu, gdy jego członkowie są ulokowani razem. Nie ma takiej technologii, która zastąpiłaby osobisty kontakt lub rozmowę twarzą w twarz. W przypadku, gdy zespół projektowy jest rozproszony, należy, przy definiowaniu projektu, określić to jako ryzyko. Nie jest to problem krytyczny, ponieważ nic złego jeszcze się nie wydarzyło. Należy stworzyć odpowiedni scenariusz odpowiedzi na ryzyko i dopisać go do Planu ryzyk. Warto rozważyć następujące kwestie:
Należy upewnić się o posiadaniu odpowiedniej technologii. Należy upewnić się, czy członkowie zdalnej grupy mają odpowiedni sprzęt komputerowy i oprogramowanie w celu wykonania pracy. Na przykład, jeśli część członków zespołu pracuje w domu, to modem 14.4 kb/s prawdopodobnie nie będzie odpowiedni.
Należy korzystać z technologii wspomagających pracę grupową. Jest wiele
produktów na rynku, które pozwalają na łatwiejszą współpracę ludzi znajdujących się w różnych miejscach. Większa część z nich opiera się na internecie. Np. dostępne jest oprogramowanie, dzięki któremu każdy ma możliwość brania udziału w wirtualnym spotkaniu, oraz przeglądania i zmieniania dokumentów.
Należy upewnić się, czy pracownicy mają odpowiednie podejście. Zarówno kierownik projektu jak i członkowie grupy projektu muszą zachować wyjątkową czujność w przypadku, gdy część grupy pracuje na odległość. Łatwo jest zdalnemu pracownikowi popaść w poczucie wyizolowania od reszty grupy. Pracownicy, którzy pracują na odległość powinni wykazywać inicjatywę w komunikacji, być niezależni w pracy i dotrzymywać terminów.
Trzeba
stworzyć procesy dobrej komunikacji. Kierownik projektu musi stworzyć proaktywny Plan komunikacji dla dobrej współpracy między rozproszonymi członkami zespołu. Np., jeśli to w ogóle możliwe, ustalić regularne spotkania, w których uczestniczyliby osobiście wszyscy. Jeśli członkowie grupy są z różnych miast lub krajów, należy określić odpowiednie godziny, w których możliwe jest przeprowadzenie wideo lub audio konferencji.
336 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Przekazywanie pracy.
Czasami zdarza się, że wielu pracowników w różnych miejscach pracuje nad tymi samymi lub powiązanymi przedmiotami dostawy. Kierownik może ustalić zasady przekazywania sobie wzajemnie pracy, szczególnie jeśli w grę wchodzą różne strefy czasowe. Musi on wtedy opisać proces płynnego przekazywania obowiązków od jednej osoby (lub grupy) do drugiej.
Jak wynika z powyższego, jeśli w projekcie pojawia się praca na odległość, powinna być ona traktowana jako ryzyko generyczne. Powiększa się ono wraz ze wzrostem odległości oraz ilością zaangażowanych stref czasowych. Jednak, nawet biorąc pod uwagę te trudności, proaktywny kierownik projektu może nadal sprawnie działać. Powinien mieć on całościowe spojrzenie na ludzi, procesy oraz używane technologie a odpowiednio uzupełniony Plan Ryzyk pomoże mu w przezwyciężeniu ewentualnych problemów. 8.2.2.P2 Zatrudnianie różnych ludzi bez osiągania kompromisu dotyczącego najlepszego kandydata Dla wielu osób kwestia dotycząca różnorodności jest delikatna, jest synonimem dostarczenia niższej jakości w celu dotrzymania pewnych zobowiązań. Jednak kwestia różnorodności jest bardziej skomplikowana. Na początek omówmy kwestię różnorodności w kategoriach wartości biznesowych, w przeciwnym wypadku zajmowanie się nią nie ma sensu. Są dwie przesłanki przemawiające za różnorodnością: pierwsza to bezstronność a druga to długoterminowa wartość związana z wszechstronną kadrą pracowniczą. Rozpocznijmy od kwestii bezstronności. Celem firmy w trakcie zatrudniania jest zawsze znalezienie najlepszego kandydata. Jest to jednak sprawa wysoce subiektywna. Bo co to znaczy: „być najlepszym” kandydatem? Różni kierownicy będą mieć różne opinie na ten temat. W niektórych przypadkach wybiorą takiego kandydata, który ma najlepsze kwalifikacje odpowiadające danemu stanowisku. W innych - osobę o podobnej do nich osobowości. Jest to tendencja naturalna, często nieuświadomiona. 1. Kierownik zatrudniający nową osobę ma tendencje do oceniania kandydatów porównując ich kompetencje do jego własnych. Ale, skoro on sam ma on już jakieś doświadczenie i jego kariera zatrzymała się na poziomie, na jakim jest obecnie, to czy jest sens, aby szukać takich samych cech u nowych kandydatów? Zazwyczaj jednak, decyzja taka jest podejmowana, często nieświadomie. Zostaje wybrany pracownik, który jest podobny do osoby rekrutującej. 2. Jeśli nie ma rzucającego się w oczy kandydata z odpowiednim doświadczeniem oraz umiejętnościami, osoba przeprowadzająca rozmowę kwalifikacyjną rozpoczyna szukanie różnic. Jeśli większość grupy pasuje do pewnego nurtu czy środowiska, następuje wtedy naturalna tendencja w myśleniu, że z ludźmi o podobnych cechach można dobrze się porozumiewać albo przynajmniej lepiej niż z ludźmi o odmiennych cechach. Jeśli grupy pozostawione są same sobie, to te dwie naturalne tendencje wpływają na wybór kandydata podobnego do grupy. Dzieje się to z powodu takiego, iż wybierają kogoś o podobnym do swojego doświadczeniu czy wyglądzie. Firmy, szczególnie te duże, próbują nadać formalny charakter oraz ustalić pewne standardy procesów 337 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
rekrutacji oraz zatrudniania w taki sposób, aby doprowadzić do tego, żeby każdy kandydat oceniany był według określonych kryteriów. Celem takiego procesu jest zazwyczaj unikanie zatrudniania niejednakowych pracowników. Celem jest także możliwie jak największe usunięcie podświadomych tendencji w celu uzyskania przekonania, że zatrudniany jest najbardziej wykwalifikowanym kandydatem. Kandydaci oceniani są przez różnych ludzi wg ustalonych kryteriów w nadziei na usuniecie subiektywności oraz dokonania obiektywnego wyboru. Wielu z kierowników dokonujących zatrudnienia sprzeciwia się ograniczeniom, jakie Dział HR nakłada na proces zatrudniania. W rzeczywistości nie ma wątpliwości, że niektóre organizacje rozwinęły uciążliwe i dysfunkcjonalne procesy zatrudniania. Jednak wiele z nich jest całkiem dobra. Nie są przeznaczone do tego, aby były prostą ścieżką zatrudniania kandydata. Są one przeznaczone do tego, aby zapewnić równe i sprawiedliwie traktowanie każdego kandydata oraz podjęcie decyzji dotyczącej zatrudnienia na podstawie faktów a nie subiektywnych odczuć, które ma każdy z nas. Tak więc wybór najlepszego kandydata w celu zatrudnienia nie powinien być trudny według jasnego procesu zatrudniania. W nawiązaniu do istniejącego argumentu dotyczącego bezstronności, różnorodność również wprowadza bezstronność i rzeczywistą wartość biznesową do firmy. Do takiego wniosku skłania fakt, że nie miało by to zastosowania, gdyby wszyscy byli tacy sami. Istotne jest to, że społeczeństwo jest zróżnicowane, firmy istnieją, sprzedają produkty na różnorodnym rynku
Korzystanie z rynku. Faktem jest, że skuteczne osiąganie sukcesów na różnych
rynkach bez różnorodnej kadry jest bardzo trudne lub wręcz niemożliwe. Jeśli próbujesz zdobyć klientów z Hiszpanii, sensowne jest posiadanie pracowników z Hiszpanii w celu rozwoju produktu, sprzedaży i marketingu. Nie oznacza to, że każda osoba musi być Hiszpanem, ale część naprawdę powinna być. To samo dotyczy afro-amerykanów etc. Jeśli rynek na którym operuje projekt jest wielonarodowy, potrzebni są ludzie z doświadczeniem i zrozumieniem spraw narodowościowych.
Podejmowanie
lepszych decyzji. Ludzie z tego samego środowiska mogą cechować się tendencją to podobnego postrzegania, a przez to podejmowania podobnych decyzji. Aby ustalać najlepsze cele, strategie oraz wykonywać zadania, kierownicy potrzebują różnorodnych opinii. Oczywiście są ludzie bardzo kreatywni, ale ciężko być kreatywnym w obszarach, w których nie ma się doświadczenia. Bardziej zróżnicowana struktura zarządzania firmą w zróżnicowanym świecie pomaga w podejmowaniu trafniejszych decyzji.
Zatrudnianie
lepszych pracowników. Bez względu na zatrudnianej osoby ważne jest, że w ogóle można ją zatrudnić.
338 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
doświadczenie
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.2.3 Rozwój Grupy Projektowej 8.2.3.P1 Staraj się stworzyć grupę o wysokiej wydajności Czy kiedykolwiek byłeś członkiem grupy projektowej, w której wszystko odbywało się bez zakłóceń? Wszyscy członkowie zespołu wpływają na rozwój projektu, mają wysokie kwalifikacje, wszyscy ciężko pracują na powodzenie projektu. Zdarza się, że dobry zespół formuje się samodzielnie. Jednak bardziej typowe jest to, że poprzez odpowiedni proces kierownik pomaga grupie stać się efektywną i wysoko wydajną. Niektórym kierownikom sprawia to jednak ogromną trudność. Pod kątem organizacyjnym, technicznym są sprawni ale niestety nie posiadają zdolności do kierowania oraz budowania efektywnego zespołu. Kierownik, który ma trudności w uzyskaniu od grupy wysokiej wydajności, najprawdopodobniej sam nie był członkiem takiej grupy. Osiąganie wysokiej wydajności jest w pewnego rodzaju wizją, a jeśli się nie posiada wizji popartej doświadczeniem, to trudno jest prowadzić grupę tak, aby uzyskała takie wyniki. Nie można oczekiwać od zespołu, że wkrótce po rozpoczęciu pracy stanie się od razu wysoko wydajnym. Jest wiele aspektów wymagających odpowiedniego czasu do osiągnięcia przez grupę wysokiej wydajności. Według modelu Tuckmana grupa, która wcześniej nie pracowała ze sobą, przechodzi przez cztery etapy rozwoju:
Formowanie.
Najpierw członkowie grupy poznają się. Nie mogą na sobie całkowicie polegać, bo nie są pewni swoich umiejętności, mocnych i słabych stron.
Docieranie. Członkowie grupy dążą do zdefiniowania swoich obowiązków, ról i
kompetencji. Zazwyczaj na tym etapie pojawiają się konflikty. Członkom grupy narzekanie wydaje się łatwe, ale nie zawsze są chętni czy zdecydowani do proponowania rozwiązań. Znają się na tyle, że mogą stwarzać sytuacje powodujące kłótnie. Na tym etapie członkowie grupy nie bardzo wiedzą, na czym polega ich rola. Niektóre niezbyt doświadczone grupy nigdy nie wychodzą z tego etapu.
Wytwarzanie
norm. Grupa zaczyna przyzwyczajać się do swoich mocnych i słabych stron. Z chaosu nagle zaczyna się wyłaniać zalążek porządku, zadania nabierają sensu. Członkowie zaczynają akceptować siebie i ludzi dookoła. Grupa realizuje się jako całość, jest silniejsza, pojawia się poczucie przynależności do zespołu.
Efektywna praca. To jest ostatnia faza, jaką przechodzi każdy zespół. Zespół skupia się na wykonaniu zadań, osiąganiu celów, polega na sobie. W razie problemów, kłopotów członkowie pomagają sobie, pytają o sposób rozwiązania problemów. Generalnie, członkowie grupy mogą pracować samodzielnie bez większego nadzoru czy kierownictwa. Całościowa wydajność jest szczególnie wysoka i tak samo jest postrzegana przez osoby z zewnątrz.
Członkowie takiej wydajnej grupy okazują wiarę i zaufanie wobec innych członków tej grupy. Nie mogą zbudować takiego poziomu zaufania w krótkim czasie, co jest następnym powodem, dla którego takie grupy potrzebują czasu, aby się uformować. Grup takich nie spotyka się często. A ich uczestnicy długo jeszcze pamiętają emocje jakie im towarzyszyły podczas pracy.
339 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jednakże, jak wspomniano wcześniej, takich zespołów nie tworzy się łatwo. Czasami zdarza się, że grupa utknie gdzieś pomiędzy poszczególnymi fazami. W rzeczywistości może się zdarzyć, że grupa może utknąć w którejś fazie już na stałe. Na szczęście, są pewne techniki, które pomagają w rozwoju grupy. 1. Ustalenie wspólnych celów. Ciężko będzie działać grupie na wysokim poziomie,
jeśli nie zostaną ustalone wspólne cele. Nawet jeśli członkowie zespołu wykonują różne czynności, należy ustalić cele obejmujące wszystkich członków. W miarę możliwości grupę należy nagradzać za osiągnięcia i osiąganie wspólnych celów. Spowoduje to, że członkowie zespołu będą mieli poczucie dążenia w jednym kierunku. 2. Zbudowanie dobrych, wewnętrznych procesów. Prawdą jest, że nie można
stale tworzyć dobrego produktu czy dostarczać dobrych usług przy słabych procesach. Wysoko efektywna grupa posiada zestaw wewnętrznych procesów wskazujący sposób, w jaki należy działać w określonych warunkach. Np., w razie problemu każdy jej członek wie, jak korzystać z odpowiednich technik zaradczych. Jeśli klient prosi o zmianę specyfikacji, zespół wie, co zrobić. Następny aspekt - to ciągłe dążenie do poprawy bieżących procesów. Jeśli proces działał perfekcyjnie rok temu, wcale nie musi być dalej tak dobry dzisiaj. Grupa bez przerwy monitoruje obecny stan i rekomenduje zmiany, które służą poprawie. 3. Etyczne warunki pracy. Zazwyczaj dzieje się to bez zapowiadania. Grupy
wysoko wydajne nie są tworzone w środowisku, w którym są ciągłe narzekania członków grupy na obciążenie pracą lub na panujące zwyczaje. Wyzwaniem dla grupy wysoko wydajnej jest ich praca. Członkowie takiej grupy ciężko pracują, aby wykonać zadania zgodnie z oczekiwaniami. Wysoko wydajna grupa pracuje skutecznie i sprytnie. Członkowie grupy wykonują więcej zadań w typowym dniu niż ich koledzy z zewnątrz. Z drugiej strony, grupa o wysokiej wydajności wyraża zrozumienie dla pracy po godzinach w celu osiągnięcia wspólnych celów. 4. Koncentracja. Grupa o wysokiej wydajności skupiona jest na celach i wie, jak je
osiągnąć. Grupa nie jest zainteresowana plotkami, pogłoskami ani polityką. Nie traci czasu na narzekanie. Członkowie grupy wiedzą, czego się oczekuje od zespołu i robią wszystko, aby spełniać te oczekiwania. 5. Utrzymanie
wysokiego poziomu motywacji. Grupa wysoce efektywna osiągnięcie celu traktuje jako wyzwanie. Wzbudza to automotywację poszczególnych członków grupy i wzmacnia całościową motywację zespołu.
6. Organizacja. Członkowie grupy znają swoją rolę w grupie oraz rolę jaką pełni
każdy z jej członków. Rozumieją procedury i procesy niezbędne do prowadzenia projektu tj. zarządzanie ryzykiem, zarządzanie jakością, problemami oraz raportowanie statusowe. W razie wystąpienia nieprzewidzianych zdarzeń, wiedzą, jaki proces uruchomić i jak go wzmocnić w razie konieczności. 7. Kluczowe
umiejętności. Grupa wysokiej wydajności posiada wszelkie umiejętności potrzebne do ukończenia zadania. Zarówno te techniczne jak i „miękkie”. Na przykład, trudno jest być grupą wysokiej wydajności, w której wszyscy chcą zostać liderami. Jeśli brakuje zestawu umiejętności w krótkim okresie czasu, wtedy są one w razie potrzeby sprowadzane z zewnątrz. Jeśli te umiejętności będą wymagane w długim okresie czasu, to członkowie grupy zostaną przeszkoleni. Członkowie w grupie o wysokiej wydajności są świadomi swoich słabości oraz mocnych stron, ale również są chętni do pracy na zewnątrz w razie potrzeby.
340 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8. Wzajemny szacunek. Typowe jest, że członkowie grupy o wysokiej wydajności
dobrze się porozumiewają miedzy sobą. Mają do siebie wzajemny szacunek i zaufanie, przekonanie, że inni pracują również tak ciężko - jak oni. Pomagają sobie w razie potrzeby i wiedzą, że pozostali członkowie grupy będą również pomocni w razie pomocy. Ogólnie rzecz biorąc, członkowie grupy nie są podatni na ekstazę oraz depresje. Szanują wzajemne możliwości oraz pomagają w pokonaniu słabości. W odpowiednich okolicznościach manager projektu może objąć przywództwo w celu doprowadzenia grupy do stanu o wysokiej wydajności. Proces ten wymaga czasu i w wielu przypadkach rezultaty nie są zachwycające. Gdyby było to takie łatwe, to każda grupa cechowałaby się wysoką wydajnością. Kiedy zespół ma tendencję do schodzenia z tej ścieżki, sugeruje się aby:
Usprawniać grupę. Grupy jaki i osoby indywidualne, rozwijają się, jeśli jest wolno
im podejmować coraz więcej decyzji, które ich dotyczą. Jeśli grupa jest pod ścisłą kontrolą kierownika, to ma mniej bodźców zachęcających, aby rozwinąć się w kierunku wysokiej wydajności. Jest możliwe, aby grupa wysoko wydajna wcale nie potrzebowała formalnego kierownika. Aby osiągnąć ten stan, kierownik musi pozwolić grupie na samodzielne podejmowanie decyzji. Wraz z rozwijaniem się grupy, zyskuje ona większą swobodę. W takiej grupie, kierownik działa bardziej jak trener, wskazując odpowiedni kierunek, udzielając rad, niż jak formalny kierownik, który mówi wszystkim, co mają robić.
Ustalanie procesów grupy. Grupa potrzebuje dobrych procesów aby za nimi podążać raportując, zarządzając ryzykami czy problemami krytycznymi. Członkowie grupy muszą rozumieć ścieżki akceptacji, jak identyfikować potencjalne ryzyka oraz jak powinny wyglądać cele. Niektóre z tych procesów już powinny istnieć, ale większość z nich może nie być jeszcze formalnie zdefiniowana. Jeśli to możliwe, procesy te powinny być jednolite w całej organizacji. Jeśli tak nie jest, zespół może je wypracować z chwilą rozpoczęcia projektu.
Inwestowanie
w szkolenia. W świecie idealnym, grupa oraz kierownik mają doświadczenie w zagadnieniach nad którymi pracują. Znają także i organizację i wewnętrzną politykę. Jednak w idealnym świecie kierownik i jego grupa rzadko posiadają wszystkie potrzebne umiejętności. Muszą rozumieć, czego nie wiedzą i próbować osiągnąć odpowiedni poziom wiedzy specjalistycznej tak szybko, jak to jest możliwe. To z kolei sugeruje kierownikowi projektu przykładanie dużej wagi do szkoleń – skoro już prowadzi zespół tą drogą. Obejmuje to zarówno dokształcanie techniczne, zawodowe, biznesowe jak i rozwój samej grupy. Może to znacznie skrócić czas wymagany do osiągnięcia wyższych poziomów działania zespołu.
Bycie
elastycznym. Ciężko jest wiedzieć i planować wszystko. Jedną z kluczowych cech dobrego kierownika jest swobodne poruszanie się w środowisku pracy, w którym występują ciągłe zmiany. Jeśli w takim środowisku kierownik działa efektywnie - ciągle dokonuje pewnych uaktualnień obowiązków i zadań do wykonania. Kierownik musi też stale podążać za dynamiką zmian w grupie.
Monitorowanie dynamiki i postępu grupy. Kiedy już grupa zostanie
przeszkolona i jest gotowa do działania - należy sprawdzać, czy wśród członków grupy następuje oczekiwana zmiana efektywności oraz wydajności. Kierownik
341 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
powinien na bieżąco utrwalać właściwe zachowania i radzić sobie z pojawiającymi się problemami.
342 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.2.4 Zarządzanie Zespołem Projektowym 8.2.4.P1 Proaktywne zarządzanie zasobami w organizacji macierzowej Frustrujące może być dla kierownika projektu zjawisko, kiedy nie jest formalnym przełożonym członków grupy. Z organizacyjnego punktu widzenia, jeśli pracownicy nie raportują do kierownika projektu jako do menedżera funkcyjnego, jest to wtedy najprawdopodobniej organizacja macierzowa. Ta struktura organizacyjna najefektywniej korzysta z zasobów pracowniczych, ale jest też rodzajem wyzwania dla kierowników projektu. Czy jest możliwe, aby grupa czuła się odpowiedzialna za dotrzymywanie terminów bez formalnego nadzoru? Z punktu widzenia pracowników, nawet jeśli nie podlegają oni kierownikowi bezpośrednio, to sposób ich pracy powinien wpływać na dokonywaną regularnie ocenę roczną. Warto im to uświadomić. Oczywiście, wcześniej należy to uzgodnić z menedżerami funkcyjnymi. Jeśli członkowie zespołu nie dotrzymują terminów, należy przede wszystkim zbadać przyczynę takiego zachowania. Jeśli na przykład, jest to spowodowane brakiem umiejętności, należy członka zespołu odpowiednio przeszkolić albo odwrotnie wymienić. Czasem powodem będzie niezrozumienie stawianych wymagań, co również wymaga odpowiedniej i szybkiej reakcji. Ze strony zarządzania procesami, istnieje wiele technik i procesów zarządzania projektem, które powinny być wcielone w życie. Jeśli byłoby to zagrożone z powodu małej dyspozycyjności lub wydajność zespołu - należy to jak najwcześniej zdefiniować jako ryzyko i sformułować odpowiedni plan zaradczy. Jeśli pracownicy nie dotrzymują terminów, to zagrożony jest harmonogram. Należy wtedy zastosować procedurę zarządzania problemami krytycznymi. W jej trakcie należy zmierzyć się z przyczyną problemu i spróbować go rozwiązać. Należy również upewnić się, czy członkowie zespołu komunikują się proaktywnie. W wielu przypadkach to nie sam fakt opóźnienia powoduje frustrację kierownika projektu lecz to, że nie został on odpowiednio wcześniej ostrzeżony. Idąc tym samym tokiem rozumowania również kierownik projektu powinien proaktywnie komunikować się z grupą i przedstawiać swoje terminy oraz oczekiwania. To samo dotyczy komunikacji z menedżerami funkcyjnymi. Zarządzanie w organizacji macierzowej wymaga spójnego i delikatnego balansowania pomiędzy kierownikami projektu oraz menedżerami liniowymi. Kierownik projektu ma zazwyczaj ograniczoną władzę w zarządzaniu ludźmi. Nawet wtedy możliwe jest jednak zakończenie projektów z sukcesem. Jest wiele procesów i technik zarządzania, które będą bardzo pomocne. Należy z nich korzystać w razie wystąpienia ryzyka czy problemów. Należy również korzystać z pomocy sponsora projektu, który ma wpływ na kierowników funkcjonalnych i może zapewnić odpowiednie zasoby potrzebne do odniesienia sukcesu. 8.2.4.P2 Przeprowadzenie sesji dotyczącej wydajności Normalnie rola kierownika projektu nie obejmuje formalnego podsumowywania sposobu pracy z członkami zespołu. Jest to w obowiązku każdego z menedżerów funkcyjnych. Nie ma jednak wątpliwości, że kierownik projektu musi przeprowadzić taką sesję z członkami grupy, aby powiadomić ich, jak pracują oraz czy spełniają jego oczekiwania. 343 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Obejmuje to rozpoznanie, czy członkowie grupy wykonują swoje zobowiązania oraz porozmawiania z nimi jeśli nie spełniali określonych oczekiwań. Łatwo jest powiedzieć pracownikom, że dobrze pracują. Gorzej jest, gdy trzeba powiedzieć członkowi grupy, że nie spełnia oczekiwań. Jeśli konieczna jest taka rozmowa, można wykorzystać następujące techniki:
Plan. Warto stworzyć
pewne zasady udzielania informacji zwrotnej. Kierownik powinien z wyprzedzeniem pomyśleć o zachowaniu pracownika, na które należy zwrócić uwagę i pomóc mu w poprawieniu tej kwestii.
Zapewnić
przykłady. Ogólnikowa krytyka wzmaga złość. Zaleca się, aby w trakcie sesji zwrócić uwagę na konkretne, namacalne przykłady. Nie trzeba przedstawiać ich zbyt wiele. Można zwrócić uwagę na istotę problemu popartą kilkoma obserwacjami.
Motywacja.
W dyskusji należy korzystać z technik motywowania. Pracownik może być zasmucony po sesji. Należy poszukać okazji do wzbudzenia morale u członków zespołu tak, aby byli wyrażali chęć poprawy.
Czas na sesję. Proces dawania informacji zwrotnej wymaga czasu. Musi to być
dialog pomiędzy kierownikiem projektu a członkiem grupy. Należy pozwolić na wyrażanie aprobaty, dezaprobaty oraz przedstawienie swoich punktów widzenia.
Ustalenie
terminu na działania korygujące. Kierownik projektu powinien udokumentować każdy omawiany aspekt, przesłać swoje uwagi do członków zespołu i dać czas na omówione działania korygujące.
8.2.4.P3 Dając informację zwrotną zawsze mów o faktach Świat jest pełen ludzi o licznych umiejętnościach i talentach. Często zdarza się, że talent prowadzi ludzi do pracy w obszarach, w których mogą się wyróżniać. W innych przypadkach, ich indywidualne talenty oraz praca nie pokrywają się. Wielu ludzi posiada i umiejętności i motywację do przezwyciężenia takich przeszkód. Gdyby każdy wyróżniał się w swojej pracy, byłoby o wiele mniejsze zapotrzebowanie na personel HR. Jednakże tak nie jest. Niektórzy ludzie nie są w stanie sprostać oczekiwaniom. A kierownicy nie powinni czuć się nieswojo próbując zaradzić ich problemom i poprawić wyniki pracy. Kierownicy nie powinni się obawiać zwracania uwagi pracownikom na zauważone problemy. Rozmowę należy przeprowadzić natychmiast, po ich zauważeniu. Praca, grupa i biznes nie mogą cierpieć z tego powodu. Wielu kierowników zadaje sobie pytanie, jak postępować, gdy pojawia się problem z wydajnością pracownika? Pomaganie mu pracy, tak aby zmieścił się w planie, nie jest, jak się wydaje, najlepszym rozwiązaniem. Czasem taki pracownik nie wie nawet, że nie wykonuje pracy należycie. Zanim więc przystąpi się do rozmowy, należy wykonać kilaka czynności wstępnych. Kierownik może rozważyć następujące kroki: 1. Pierwszy polega na zebraniu faktów – konkretnych przykładów niedotrzymania
terminów itp., które mogą być użyte podczas dyskusji. 2. Kiedy
obiektywne przykłady są już gotowe, to kolejnym przeprowadzenie dyskusji. Może ona mieć następujące cele:
344 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
krokiem jest
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Należy uświadomić pracownikowi, jak postrzegany jest problem; Otrzymać odpowiedź pracownika; Określić krótkoterminowy plan działania; jest do działanie krytycznie
ważne – od
niego zależy, czy przywrócona zostanie pierwotna wydajność
W wielu przypadkach kierownik dochodzi do wniosku, że problem związany jest z wydajnością. Jest jednak wiele różnych przyczyn, które pokazują, dlaczego wydajność pracownika nie spełnia oczekiwań. Kiedy kierownik pozna przyczynę, można wtedy stworzyć odpowiedni plan działania. Wstępna dyskusja pozwoli na określenie następnych kroków, które należy podjąć. Zawsze istnieje możliwość wspólnego rozwiązania problemu. Być może wystarczy tylko naświetlić problem pracownikowi i sytuacja sama zostanie rozstrzygnięta. Bez dyskusji nie jest możliwe stwierdzenie, gdzie występuje problem i jakie są dostępne rozwiązania. To pierwsze spotkanie nie powinno się zakończyć, zanim nie zostanie stworzony krótkoterminowy plan naprawczy. Często wymaga on pracy zarówno kierownika jak i pracownika. Plan powinien również zakładać czas, np.: 30 dni na ponowny powrót do pierwotnej wydajności. I oczywiście należy to później sprawdzić. Jeśli następuje poprawa, wtedy być może potrzebne będzie już tylko monitorowanie sytuacji. Jeśli wydajność dalej nie spełnia oczekiwań, wtedy drugie spotkanie powinno znowu rozpoznać przyczynę oraz zbadać, czy jest więcej działań, które można by podjąć. Jeśli są, należy je również wdrożyć. Jednakże, jeśli kierownik uważa, że pracownik nie może spełnić oczekiwań odpowiadających stanowisku, powinien zaangażować Dział Personalny i ewentualnie poszukać innych, dostępnych w danym momencie osób. 8.2.4.P4 Bądź staranny w zarządzaniu pracownikami Wielu kierowników projektu nie czuje się swobodnie kierując słabymi pracownikami. Sprawdza się to szczególnie, jeśli dany pracownik nie spełnia oczekiwań, ale jeszcze nie w takim stopniu, by go zwolnić. Trzeba jednakże podejmować takie wyzwania i tak zarządzać grupą aby ukończyć projekt z sukcesem. Poniżej przedstawiono kilka możliwych przyczyn słabej wydajności pracowników:
Czy pracownik posiada odpowiednie umiejętności i doświadczenie? Czasami zdarza się, że pracownicy z powodu braku odpowiednich umiejętności wymaganych na danym stanowisku nie spełniają danych oczekiwań. Jeśli ktoś zalicza się do tej kategorii, należy zadecydować, czy taka osoba może wykonać to zadanie po odpowiednim przeszkoleniu lub czy powinna zostać zastąpiona.
Czy pracownicy rozumieją oczekiwania kierownika projektu? Jeśli pracownicy posiadają odpowiednie kwalifikacje, należy ich
zapytać, czy naprawdę rozumieją przedstawione oczekiwania. Jeśli są jakieś nieścisłości dotyczące oczekiwań, można przekazywać je pisemnie wraz z zadaniami do wykonania oraz terminami.
Czy są jakieś okoliczności łagodzące?
345 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Czy występują jakieś biznesowe lub osobiste przyczyny, które mogą wpływać na
wydajność? Na przykład, członek zespołu może nie być zbyt zmotywowany do pracy, jeśli bliska mu osoba jest chora. Jeśli znajdzie się przyczynę, da to możliwość odpowiedniego zareagowania lub przynajmniej zapoznania się z faktami.
Jeśli pracownicy posiadają odpowiednie kwalifikacje oraz spełniają oczekiwania,
wtedy działania kierownika projektu są ograniczone. To jest właśnie obszar do zarządzania wydajnością. Jest też możliwe, że niektórzy członkowie grupy nie chcą być w stanie pracować tak, by spełnić oczekiwania. Może nie wykazują chęci do takiej pracy niezależnie od szkoleń i zapewnionego wsparcia. Można wtedy zaangażować odpowiedniego kierownika funkcyjnego i zazwyczaj także Dział Personalny, którzy mogą pomóc znaleźć środki naprawcze dostępne oraz akceptowane w Twojej firmie.
Jeśli pracownicy nie dotrzymują ważnej daty dostawy, projekt może znaleźć
się w obliczu ryzyka opóźnienia harmonogramu. Jeśli wynika to ze złego przydziału pracowników do zadań, to jest to problem krytyczny. Jeśli ludzie spóźniają się z dostawą, bo wykonują więcej zadań niż im przydzielono, należy uruchomić proces zarządzania zmianą zakresu. Jeśli pracownicy nie spełniają oczekiwań co do jakości, to należy wykorzystać proces zarządzanie jakością, aby ustalić metody korygujące.
Praca z pracownikami, z którymi współpraca nie jest możliwa, sprawia wiele
trudności i rodzi frustrację. Po określeniu problemu i znalezieniu przyczyny, należy zdecydować, czy działania naprawcze należą do kierownika projektu lub czy należy przedstawić je kierownikowi funkcyjnemu.
8.2.4.P5 Rola przywódcy w ważnych projektach Kierownicy projektu powinni być liderami. Przywództwo może być łatwe, jeśli wszystko idzie w dobrym kierunku a pracownicy stosują się do poleceń. Gdy tak nie jest, ciężko jest też być przywódcą; choć z drugiej strony bardziej energicznie niż kiedykolwiek. Poniżej przedstawiono kilka spraw, na które należy zwrócić uwagę, aby wyprowadzić grupę na prostą:
Szeroki ogląd sytuacji. Kiedy zaczynają się problemy, naturalnym odruchem jest że, każdy próbuje być na nich skoncentrowany. Rolą przywódcy jest skoncentrowanie się na wizji osiągania celów projektu.
Pozytywne
myślenie. Kiedy sytuacja ulega pogorszeniu, nawet najbardziej lojalni członkowie zaczynają się niepokoić, a bywa, że i kłócić. Zaczynają kwestionować swoje decyzje i znajdywać błędy w działaniu innych. Rolą przywódcy jest utrzymywanie wzajemnych pozytywnych stosunków, jak również racjonalne i obiektywne działanie.
Poświęcać się. Kiedy następuje kłopot z podziałem zadań, rolą lidera jest po
prostu kierowanie. Jeśli grupa musi pracować po godzinach, kierownik projektu również musi pracować po godzinach. Jeśli konieczna jest praca w niedzielę, kierownik projektu również musi pracować w niedzielę.
Spokój i opanowanie. Panika to normalny ludzki odruch i nikt nie jest na to odporny. Jednak przywódca musi na spokojne przemyśleć problem i pozostać
346 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
opanowanym. Pozwoli mu to na podjęcie prawidłowych decyzji dla całej grupy. Panika doprowadza tylko do katastrofy, podczas gdy opanowanie i spokój - do sukcesu i do zwycięstwa.
Motywacja. W ciężkich i wymagających sytuacjach ludzie zazwyczaj naturalnie
ulegają przygnębieniu. Mają tendencję do bycia pesymistami. Nie widzą, w jaki sposób znaleźć wyjście. Kierownik projektu powinien skoncentrować się na zmotywowaniu grupy np. poprzez pokazywanie bliskości końcowego sukcesu.
Tworzenie małych zwycięstw. Jednym ze sposobów motywowania jest metoda małych zwycięstw. Kiedy sprawy idą źle, grupa rozważa sposoby, jak odnieść sukces - nawet mały. Kierownik projektu powinien szukać sposobów na odniesienie zwycięstw. Z każdym małym zwycięstwem w grupie buduje się poczucie własnej wartości pozytywnego stosunku do pracy.
Poczucie
humoru. W życiu można się śmiać prawie ze wszystkiego. Będąc kierownikiem projektu należy poszukać okazji do wpajania radości, śmiania się nawet z siebie samego w różnych sytuacjach. Słaby kierownik projektu nie jest w stanie wyprowadzić grupy z kryzysu, ponieważ nie ma do tego odpowiednich predyspozycji. Kiedy kierownik projektu pokaże swoje przywództwo, grupa pójdzie za nim i, choć może nie natychmiast, to w efekcie tak się stanie.
8.2.4.P6 Atakuj morale grupy na wielu frontach Problemy z morale grupy nie następują z dnia na dzień, jak również nie da się ich rozwiązać w krótkim okresie czasu. Zazwyczaj przyczyny i środki zapobiegawcze są poza kontrolą kierownika. Niezależnie od tego, ile można zrobić, jeśli grupa widzi, jak dużo wysiłku kierownik wkłada w pracę i jak jest zdeterminowany do osiągnięcia celu, to również ona zmienia nastawienie na lepsze. Aby rozpoznać przyczynę problemu z morale, konieczna jest sesja z grupą. Dopiero, kiedy zostanie ona rozpoznana, znajdzie się wiele sposobów, aby rozwiązać problem.
Bądź dobrym słuchaczem. Można przekonać się, że sam fakt bycia dobrym
słuchaczem zwiększa morale grupy. Kierownik projektu powinien starać się nawiązać nić sympatii i starać się zrozumieć innych. Pokazuje to, że przynajmniej stara się on rozpoznać problem i jest nim zainteresowany.
Powiedz dziękuję. Podobnie jak bycie dobrym słuchaczem jest to bardzo istotna sprawa. Jeśli członkowie grupy czują, że kierownik projektu zauważa ich zaangażowanie, to wpływa to pozytywnie na atmosferę w pracy.
Przydzielanie bardziej ambitnych zadań. Jest to trudna kwestia, ponieważ w
większości przypadków, praca to praca i nie ma możliwości zmiany jej istoty. Jednakże, jest kilka spraw, które można zrobić, aby wprowadzić nowe wyzwania. Jeśli dwoje osób wykonuje te same czynności przez długi okres czasu, to dokonaj ich zamiany. Daje to możliwość opanowania nowych umiejętności. Można też przekazać pracownikom trochę więcej odpowiedzialności, Np.: pozwolić na opracowanie budżetu grupy, pozwolić na ponoszenie odpowiedzialności za współpracowników grupy itp.
347 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Szansa na poznanie nowych technologii. Można spróbować zapoznać ludzi z nowymi technologiami, zamienić obowiązki, aby pozwolić im na uczenie się nowych umiejętności, jak również podnieść ich szanse na nowe szkolenia.
Upewnij
się, że ludzie wiedzą, czego się od nich oczekuje. Należy się upewnić, że ludzie jasno wiedzą, na czym polegają ich obowiązki, jakie są ich bieżące czynności, oraz w jaki sposób ich udział pomoże całemu projektowi na odniesienie sukcesu.
Zaoferuj większą elastyczność. Pozwolenie ludziom na większą kontrolę ich pracy może pomóc w poprawieniu morale. Przykłady elastyczności pracy podano poniżej:
Zaoferuj opcje elastycznego czasu pracy tak, aby pozwolić ludziom pracować o
wcześniejszej lub późniejszej porze. Może to również objąć czterodniowy wymiar pracy w zależności od ich osobistych preferencji.
Zaproponuj formy telepracy. Można spróbować na grupie osób raz, dwa dni w tygodniu.
Sprzęt.
Upewnij się, że pracownicy posiadają odpowiedni sprzęt, oprogramowanie do pracy. Wykonywanie pracy na powolnym sprzęcie, komputerze sprzyja frustracji.
Poszukaj
okazji do zabawy. Poszukaj możliwości zorganizowania imprez pracowniczych jak urodziny, imieniny itp.
Zbieraj opinie i pomysły pracowników. Kierownik projektu powinien zachęcić członków grupy tak, aby byli zaangażowani. Jeśli poczują, że cenisz ich opinie i pomysły, lepiej się odnajdą w tej sytuacji.
Jest wiele przyczyn złego morale, ale jest też wiele sposobów na poprawę sytuacji. Rozwiązaniem jest rozpoznanie sytuacji i szybka, adekwatna reakcja. Tak więc, kierownicy projektu muszą bacznie obserwować, czy grupa nie działa pod wpływem złego morale i szukać sposobów na podniesienie morale wśród grupy. Niezależnie od innych ograniczeń, zawsze pozostają niezawodne sposoby jak np.: słuchanie czy powiedzenie „dziękuję”. 8.2.4.P7 Dysfunkcyjna Grupa Projektowa Wiele grup wśród swoich członków posiada osobowości konfliktowe. Czasem wzajemne niechęci powodują nawet niemożliwość współpracy. Kierownik projektu, który jest również członkiem grupy, w tym przypadku również może być częścią problemu i może mieć ograniczoną zdolność do zidentyfikowania i rozwiązania go. Gdy problem ten zostanie zidentyfikowany przez sponsora lub menedżera funkcyjnego, kierownik projektu może zostać zastąpiony (jest to zazwyczaj prostszy sposób niż wymiana całej grupy). Nowy kierownik projektu, który przejmuje dysfunkcyjną grupę, będzie musiał skupić się na wielu kwestiach. Pierwszą rzeczą, którą należy zrobić, jest ocena obecnego stanu projektu. Reakcja na problemy grupy projektowej będzie zależała od harmonogramu projektu. Na przykład, jeśli pozostało 30 dni do jego końca, wpływanie na dynamikę grupy może się nie udać. W tym przypadku najlepszym rozwiązaniem będzie próba zmotywowania grupy
348 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
i postępowania według planu. Z drugiej jednak strony, jeśli pozostaje wiele miesięcy do zakończenia projektu, to warto popracować nad grupą, aby poprawić relacje i naprawić ewentualne szkody, oraz skorygować harmonogram tak, aby był znów realistyczny. Rozwiązując problem warto rozważyć następujące kwestie:
Dobra
komunikacja. Jeśli kierownik projektu ma problemy ze sprawną komunikacją, to może to być przyczyną słabych wyników zespołu. Grupy o słabym morale mają tendencję do słabej komunikacji. Nie warto polegać na plotkach. Trzeba proaktywnie dzielić się z informacjami o projekcie.
Chwal i komplementuj. Kiedy członkowie zespołu dobrze sobie radzą, upewnij się, że o tym wiedzą. Ludzie nie oczekują ekstra pieniędzy, czy prezentów za codzienną dobrą pracę. Wystarczy przyjacielski uścisk dłoni i dobre słowo od kierownika. Zarówno oficjalnie jak i nieoficjalnie.
Jasne oczekiwania. Ludzie muszą rozumieć, czego się od nich oczekuje i znać
wyzwania jakie przed nimi stoją. Wskazówki, instrukcje, informacje o przydzielanych zadaniach powinny być przekazywane tak, aby ludzie rozumieli czego się od nich oczekuje.
Nie przecenianie grupy. Po tym jak morale grupy poprawiło się, nie należy jej
przeciążać. Zespół powinien skupić się wyłącznie na zadaniach pozostałych do wykonania w projekcie. Wszystko co jest niepotrzebne lub co może być zrobione po projekcie, nie powinno być wykonywane.
Zarządzanie zakresem. Zarządzanie zakresem powinno być bardzo restrykcyjne.
Warto starać się odkładać wszelkie zmiany na czas po projekcie, kiedy mogą być rozpatrzone jako nowy projekt.
Wygrywaj
małe bitwy. Słabe morale może być przyczyną niedotrzymywania terminów, co powoduje stres i dalsze pogorszenie morale. Z drugiej strony, jeśli grupa zacznie dotrzymywać bieżących terminów (a kierownik projektu komunikuje ten fakt proaktywnie i pochwala to), wtedy morale grupy powinno się poprawić.
Są to propozycje naprawy projektu. Podsumowując, jeśli nie ma dużo czasu do końca projektu, należy skupić się na jego wykonaniu w terminie. Jeśli natomiast jest, warto skoncentrować się na „naprawie” grupy projektowej, i oczywiście na ukończeniu projektu. 8.2.4.P8 Zarządzaj kwestiami politycznymi jak problemami Im projekt większy, tym częściej doświadczyć można problemów o naturze politycznej. Rozwiązanie ich wymaga osiągnięcia szczególnego konsensusu wśród ludzi, którzy mają odmienne opinie i często odmienne interesy. Ogólnie rzecz biorąc, polityka w projekcie to wzajemne oddziaływanie ludzi oraz wpływanie na nich tak, by podejmowali określone decyzje. W zależności od taktyki może to być działanie dobre, złe lub zupełnie neutralne. Rozważmy przykłady dobrych i złych sposobów wykorzystania politycznych umiejętności.
Kierownik projektu umie wprowadzić swoje pomysły w życie oraz skłaniać ludzi do współdziałania (dobry) ...poprzez szantażowanie kadry itp.(zły)
tłumienie
innych,
349 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
przeciwnych
opinii,
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Kierownik
projektu umie osiągać konsensus w skomplikowanych sprawach z licznymi interesariuszami (dobry) ...dzięki działaniom zakulisowym z ważnymi osobami, wchodzeniu w nieformalne umowy, eliminowaniu ludzi, którzy nie należą do grupy. (zły).
Kierownik projektu otrzymuje odpowiednie fundusze, dlatego że są one ważne dla
powodzenia projektu i dla organizacji (dobry) …przez rozmyślne wprowadzenie w błąd w sprawie kosztów oraz korzyści, obchodzenie istniejącego procesu finansowego. (zły).
Kierownik projektu tworzy swój wizerunek jako kogoś, kto wszystko potrafi dobrze
wykonać (dobrze) …używając legalnych i nielegalnych sposobów, idąc po trupach (źle).
Celem tych przykładów jest ukazanie, że wpływanie na ludzi i doprowadzanie rzeczy do końca, jest w biurokratycznym otoczeniu pozytywne, a wyrażenie „polityka biurowa” może mieć zarówno dobre jak i złe konotacje. Zajmowanie się polityką biurową nie jest procesem standardowym zarządzania projektem. Jednakże, kiedy polityka zacznie wpływać na projekt, taka sytuacja powinna być zidentyfikowana jako problem krytyczny, którego rozwiązanie leży poza obszarem uprawnień grupy projektowej. Nie można tu skorzystać z listy kontrolnej czy innych standardowych narzędzi. Problemy polityczne są powiązane z ludźmi oraz konkretną sytuacją. Co działa na jedną osobę w danej sytuacji, może nie działać na inną w tej samej sytuacji. Stosowanie procesu zarządzania problemami krytycznymi pomoże jasno ocenić sytuację i zaangażować odpowiednich ludzi. Generalnie, kierownicy projektu powinni sprawnie identyfikować i podejmować próby rozwiązywania spraw politycznych. Istnieją trzy obszary wymagające zainteresowania:
Warto
rozpoznać sytuacje, w których najprawdopodobniej zaangażowana zostanie polityka. Dotyczy to z reguły ważnych decyzji, budżetu, zasobów i ustalenia kierunku i priorytetów projektu.
Kierownik projektu powinien otwarcie i życzliwie komunikować swoje opinie. Kiedy
przedstawia opinię czy rekomendację, powinien pokazać jej za i przeciw aby słuchacze mieli szeroką perspektywę omawianych kwestii. Warto też oddzielać fakty od opinii, tak aby wszyscy zrozumieli różnicę. Proaktywna komunikacja z interesariuszami jest bardzo wskazana..
Jeśli kierownik projektu nie czuje się komfortowo z tym, o co został poproszony,
powinien zaangażować sponsora lub kierownika funkcyjnego. Mają oni z reguły lepsze wyczucie polityczne i niezbędny autorytet. Powinni być w stanie udzielić odpowiedniej rady.
Jeśli dobrze się czujesz z tym, co robisz i jak wpływasz na innych, to najprawdopodobniej prowadzisz politykę biurową w dobry sposób. Jeśli masz poczucie winy co do tego, jak traktujesz ludzi, lub masz wątpliwości wobec wykonanych zadań, to najprawdopodobniej prowadzisz politykę niejasną, może złą.
350 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.2.4.P9 Otwarcie określaj problemy, które powodujesz Nikt nie jest idealny. Kierownik projektu wykonuje zadania najlepiej, jak potrafi w miarę dostępnych informacji. Jednakże czasami pojawia się problem spowodowany błędem kierownika projektu. Może to być problem w komunikacji, błąd w ocenie, w zrozumieniu celów itp. Aby zaklasyfikować go jako formalny problem krytyczny, musiałby on być ogromny. Lecz i duże błędy są przecież popełniane. Zarządzanie problemem jest zazwyczaj logicznym procesem obejmującym identyfikację problemu oraz techniki rozwiązania problemu. Jednak, te specyficzne typy problemów mogą być szczególnie trudne do rozwiązania, gdy kierownik projektu przejawia bojaźliwość (lub zakłopotanie) i brak zdecydowania wskutek spowodowania problemu. Zdarza się, że fakt popełnienia błędu przez kierownika utrudnia jego otwartą identyfikację. W takiej sytuacji, aby działać efektywnie, należy podjąć następujące kroki: 1. Przyznanie się do problemu. Najpierw należy rozpoznać problem oraz przyznać się do jego spowodowania. Próby obwiniania innych, mogą spowodować, że rozwiązanie go będzie o wiele boleśniejsze. Jeśli kierownik projektu spowodował problem, lub choćby była to tylko częściowo jego wina, powinien wykazać się dojrzałością i uczciwością i się to tego przyznać. 2. Otwarte komunikowanie. Szybkie przyznanie się do błędu bardzo pomaga. Zaskakujące jest, jak taki fakt poprawia samopoczucie i winowajcy, i zespołu. Koniec z szukaniem winnych! Grupa szybko może przystąpić do rozwiązywania problemu. 3. Rozwiązuj problem spokojnie. W tym momencie najbardziej bolesna część dla kierownika projektu jest już za nim. Teraz trzeba szukać alternatyw i rozwiązywać problem za pomocą zwykłych technik zarządzania problemem. Koncentrowanie się na osobistym bólu, ucieczka czy pozorowanie działań, które mają na celu zachowanie twarzy nie mają teraz sensu. Zachowanie spokoju to najlepszy sposób na rozwiązanie problemu. 4. Wyciągnij nauczkę z pomyłek. Zazwyczaj każdy błąd, można zamienić w doświadczenie, z którego można się uczyć. Refleksja i wyciągnięcie wniosków może zaowocować zmianą procesów zarządczych w taki sposób, aby problem już więcej nie wystąpił. Powszechne dla kierowników jest stwierdzenie, że jedynym pozytywnym wyjściem ze złego doświadczenia, jest nauczka, aby więcej nie popełniać takiego błędu. Było by wspaniale, gdyby istniały lepsze momenty do nauki. Jednakże, jak już stwierdzono wcześniej, nikt z nas nie jest doskonały. Kiedy popełniasz większe błędy, przyznaj się do nich i właściwie to zakomunikuj. Następnie przemyśl, jak przezwyciężyć problem i wykonaj korektę w taki sposób, aby problem się więcej nie pojawił. Jeśli kierownik w ten sposób podejdzie do problemu, to okaże się, że ludzie będą akceptować to co mówi, a nawet będą podziwiać go za sposób, w jaki kieruje tymi osobistymi w końcu wyzwaniami. 8.2.4.P10 Przywództwo a wprowadzanie krytycznych zmian
351 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Zmiana z natury nie jest zła czy dobra. Jednakże, grupa może reagować na zmiany w sposób pozytywny lub negatywny, w zależności od stanu projektu. Typową reakcją większości grup projektowych jest iść dalej i dokonywać zmian. Ale jest też inna reakcja, która wydaje się bardziej problematyczna: grupa może nie chcieć dokonywać więcej żadnych zmian. Taka sytuacja może się wydarzać się w grupach, w których występują problemy, z różnych powodów.
Jeśli projekt jest długi, być może wymagający pracy po godzinach - ludzie po prostu chcą doprowadzić do jego zakończenia.
Proponowane zmiany wymagają wiele pracy, a terminy są ściśle przestrzegane. Znowu może wystąpić sytuacja, w której od pracowników wymaga się pracy w nadgodzinach.
Pomiędzy członkami grupy oraz klientem nie występują partnerskie relacje. Może okazać się, że grupa projektowa nie chce pomagać dalej klientowi.
Zmiany wymagają głównie przeróbek w projekcie, które z kolei wymagają zmian w konstrukcji i ponownym testowaniu całego rozwiązania.
Wszystkie te i inne sytuacje powodują, że grupa projektowa nie jest zmotywowana na tyle, aby poprzeć zakres zmian. To z kolei ustawia kierownika projektu w trudnym położeniu. Jest on zmuszony do przeprowadzenia kolejnych trudnych rozmów z pracownikami. Szczerze mówiąc, jest to ciężkie zadanie. Grupa jest zmęczona i brak jej motywacji. W rzeczywistości, morale może być bardzo słabe. Jednakże, to jest właśnie czas dla kierownika, aby zademonstrować cechy przywódcy. Ponieważ przyczyna problemu może być złożona, rozwiązania również mogą być złożone. Poniżej przedstawiono sytuacje, które kierownik powinien wziąć pod rozwagę:
Wytłumaczenie
faktów. Nie można zaczynać od razu od wielkiej przemowy. Najpierw należy spotkać się z grupą i wyjaśnić jej tło i okoliczności. Następnie dopiero przejść do zmian, wyjaśnić ich znaczenie i wartość biznesową.
Ujawnienie oporu. Kierownik projektu musi potwierdzić problemy. Powiadomić grupę, że rozumie, że mogą nie chcieć zmian i że ich morale może nie być najlepsze. Nie drąży tego tematu, ale jedynie go ujawnia.
Motywowanie. Teraz jest czas na motywowanie grupy. Warto odwołać się do ich poczucia wspólnoty, aby pokonać przeciwności losu. Uświadomić, jak bardzo są wartościowi dla firmy.
Rozmowy
indywidualne. W nawiązaniu do spotkania grupowego, można porozmawiać z każdym z osobna. Wysłuchać obaw i uzyskać tym osobiste zaangażowanie do pracy każdego z rozmówców.
Angażowanie kierownictwa i sponsora. Teraz jest też dobry czas, aby poprosić przełożonego i sponsora, aby porozmawiali z zespołem, podziękowali im za dotychczasową pracę i poprosili o dalszą pomoc w realizowaniu zmian.
Drobne
nagrody. Drobne nagrody pomogą grupie przejść przez kłopoty z brakiem motywacji oraz niskim morale. Czasem wystarczą bardzo proste. Np. z
352 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
rana zaoferować słodycze a wieczorem pizzę dla tych, którzy muszą pracować po godzinach.
Klienci. Kierownik projektu powinien upewnić się, że klienci są z nim. Zazwyczaj, jeśli grupa projektowa pracuje dłużej dodatkowo, klienci również w tym współuczestniczą. Jednak to kierownik projektu powinien się upewnić, że klienci też są zaangażowani.
Proaktywna
komunikacja. Kierownik nie może zapominać o komunikacji. Powinien stale informować wszystkich odnośnie stanu projektu, czasu oraz pracochłonności, jakie jeszcze pozostały do końca. Jeśli zatrzymuje to w tajemnicy, może wywołać wiele problemów z morale.
Świętuj sukces. Kierownik projektu nie musi czekać, aż do zakończenia projektu, aby poinformować o jego sukcesie. Warto poszukiwać nawet drobnych okazji do świętowania (osiągnięte kamienie milowe) oraz chwalić członków zespołu.
Kierownik projektu musi być obdarzony większymi umiejętnościami zarządzania i przywództwa, niż tylko mówienie: „dobra robota”. To spore wyzwanie, która wymaga dobrych umiejętności w zarządzaniu personelem. Nie ma gwarancji sukcesu, ale korzystanie z powyższych wskazówek może pomóc w wybrnięciu z trudnej sytuacji. 8.2.4.P11 Grupy samo-zorganizowane Praca grupowa przydaje się przy większości prac. Kiedy ludzie pracują w grupie, stają się bardziej zmotywowani i entuzjastycznie nastawieni. Rozwijają nowe pomysły, aby poprawić wydajność całej grupy i są gotowi na przyjmowanie większej odpowiedzialności. Zespół projektowy, który sam utrzymuje wysoki poziom wewnętrznej współpracy i zarządzania, nastawiony na osiąganie wysokiej wydajności własnej nazywamy zespołem samoorganizującym się. W takich grupach, wśród ich członków wzrasta poczucie zaufania, stają się oni zmotywowani i gotowi do zaakceptowania trudniejszych wyzwań. Koncentrują się na wydajności i na dobrych wewnętrznych relacjach. Grupy samozorganizowane potrzebują szkoleń przygotowujących do pracy w tym nowym trybie. Częstym błędem jest umieszczanie ludzi w takim samoregulującym się środowisku bez odpowiedniego przygotowania. Rezultatem tego jest chaos, frustracja i paraliż. Najlepszym momentem na szkolenie jest etap wstępnego formowania się grupy oraz chwile, gdy grupa doświadcza sytuacji, z którymi nie może sobie poradzić. Oczywiście, grupa nie może być szkolona w każdej możliwej wolnej chwili. Jednym z celów tworzenia grupy samozorganizowanej jest to, że ma ona wykazywać odpowiednią elastyczność i rozwiązywać nawet nieprzewidywalne problemy w momencie jak się pojawią. Żadna ilość treningów i planowania nie przyniesie w tym przypadku doskonałych rozwiązań. Nieprzewidziane problemy z pewnością nastąpią, a grupa musi być przygotowana, aby inwestować odpowiednie zasoby i energię do pracy w celu ich przezwyciężenia. 8.2.4.P12 Przezwyciężenie niechęci grupy do zarządzania projektem Jedną sprawą jest budowanie Definicji Projektu i harmonogramu - inną sprawne zarządzanie projektem. Jeśli dałoby się opracować plan oraz wyznaczyć działania tak,
353 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
by wszyscy zakończyli swoje zadania na czas, życie kierownika projektu byłoby proste. Jednakże, proces zarządzania zespołem i harmonogram komplikuje się z powodu zaangażowania elementu ludzkiego. Ludzie są nieprzewidywalni. Aby wiedzieć na czym polega praca projektu i upewnić się, że realizowana jest wg planu, konieczne są kontrole. Może kierownik projektu będzie musiał odpytywać ludzi, jak sobie radzą. Może będzie potrzebował danych i prosił o raporty i spotkania statusowe. Może wreszcie będzie tworzył statystyki dotyczące zakończonych prac, wykonywanych oraz nie rozpoczętych zadań. Niestety, członkowie grupy nie zawsze mu w tym pomogą. Nie zawsze przecież reagują pozytywnie na procesy zarządcze i kontrolne. Z różnych przyczyn:
Może
im się wydawać, że te procesy są niepraktyczne i odciągają ich od osiągania celów.
Może im się wydawać, że będą ukarani za dostarczanie złych wiadomości lub za niewłaściwe wykonywanie pracy.
Mogą uważać, że procesy zarządzania projektem nie są skuteczne. Mogą mieć zwykłą, ludzkie nastawienie przeciwko procesom, które uważają za dodatkową kontrolę.
Członkowie grupy mogli stosować te procesy, ale odkryli, że są niekompletne lub, że inni ich nie stosują.
Mogą uważać, że skoro kierownik nie stosuje się do procedur, to dlaczego oni mieliby się do nich stosować.
Mogą widzieć, że inni omijają te procedury bez negatywnych konsekwencji. Rozpoznanie tych normalnych ludzkich tendencji pozwoli na przeciwstawienie się im zawczasu. Zadaniem kierownika projektu jest również skuteczne komunikowanie tych procesów, włączając w to ich wartość dla projektu. Po ich przedstawieniu grupie, ważne jest, aby zacząć stosować je konsekwentnie i powszechnie. 8.2.4.P13-P17 [ wykreślono z edycji polskiej ]
354 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
8.3 Zarządzanie Zasobami Ludzkimi / Podsumowanie 8.3.P1 Dokumenty Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Formularz działań szkoleniowych Skarga na pracownika Samoocena pracownika Dziennik szkoleniowy pracownika Ostrzeżenie o problemie z wydajnością Opis stanowiska pracy Ogłoszenie wolnego stanowiska Dziennik zatrudnień Zapotrzebowanie na etat Plan rozwoju i działalności Podsumowanie wyników pracy Formularz urlopowy Raport z rocznego wykonania zadań i wiele innych 8.3.P2 Harmonogram dodatkowych działań Wielkość Niezbędne informacje Małe
Nie wymaga się żadnych działań Czynność
Średnie /duże
Pozyskanie zespołu
Zapewnienie rozwoju członkom
pracochłonność Uwagi Działanie to związane jest z określeniem typu zasobów, które potrzebne są do Nieokreślona projektu, wyszukanie ich i formalne pozyskanie. Nieokreślona
Działanie to związane jest z zapewnieniem odpowiednich kompetencji personalnych i technicznych w zespole poprzez coaching i szkolenia. Znajdą się
355 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zespołu
Zarządzanie zespołem projektowym
tu odpowiednie działania z tym związane. Mogą się one różnić się w różnych projektach.
nieokreślona
Praca ta jest związana z przydzielaniem pracy w projekcie i zapewnieniem, że będzie ona ukończona na czas. Obejmuje to proces 3.0. Zarządzanie budżetem i harmonogramem. Zadania te dotyczą również: dawania informacji zwrotnej o wynikach pracy; problemów dotyczących zarządzania pracownikami; zapewnienia, że grupa jest spójna i wysokowydajna.
356 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 9 Zarządzanie jakością
357 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.0. Zarządzanie jakością 9.0.P1 Jakość jest w zasadzie określana przez klienta i pokazuje, jak daleko projekt i przedmioty dostawy spełniają jego oczekiwania i wymagania. Stare powiedzenie mówiące, że jakość mierzona jest oczami obserwatora, jest prawdziwe – jakość jest mierzona przez Twojego klienta. Twoim celem jest zrozumienie jego wymagań i oczekiwań – a później sprostanie tym oczekiwaniom. To jest żelazna zasada dotycząca jakości. Czasami występuje tendencja w myśleniu, że wyznacznikiem jakości jest najlepszy materiał, najlepszy sprzęt i eliminacja absolutnie wszystkich defektów. Jednakże w większości przypadków klient nie oczekuje i nie może wymagać idealnego rozwiązania. Pomimo tego, że pojawi się kilka potknięć w projekcie lub jakieś defekty w dostarczonym rozwiązaniu, klient nadal może mówić o wysokim poziomie jakości. Z drugiej strony poziom jakości zaprojektowanego bez wad czy wolnego od defektów rozwiązania, które nie spełnia potrzeb klienta, nie jest postrzegany jako wysoki. Celem zarządzania jakością jest najpierw zrozumienie oczekiwań klienta w tym zakresie, a potem stworzenie proaktywnego planu, wychodzącego naprzeciw tym oczekiwaniom. Odkąd jakość jest definiowana przez klienta, może wydawać się, że jest subiektywna. Jednakże wiele można zrobić aby stała się obiektywna. Wymaga to najpierw dokonania podziału jakości na specyficzne aspekty, które są ważne dla klienta. Później należy spojrzeć na każdy z nich i określić jedną lub więcej miar, które mogą być zebrane w celu stworzenia ogólnej charakterystyki. Na przykład jedną z cech jakości może być minimalna ilość błędów. Taka charakterystyka może być mierzona przez liczenie błędów i defektów po powstaniu rozwiązania. W odniesieniu do definicji jakości postrzeganej przez klienta, ważne jest by rozpoznawać również oczekiwania innych interesariuszy. W zależności od roli, jaką oni pełnią, mogą mieć różne wymagania, które trzeba zaspokoić. Przykładowo:
Firma - rozwiązanie zaspokaja cele strategiczne. Kupujący - rozwiązanie wypełnia specyfikację. Końcowi użytkownicy - rozwiązanie pomaga im wykonywać pracę lepiej, szybciej i łatwiej. Dział Wsparcia IT - rozwiązanie jest stabilne, ma mało błędów, jest zrozumiałe i daje się łatwo modyfikować.
W dużych projektach zbieranie pomiarów jest niezbędne, by proces zarządzania jakością działał. Procesy 9.0 i 10.0 metodyki TenStep są ściśle ze sobą powiązane. Jeżeli chcesz dobrze zarządzać jakością, musisz być mierzyć! W przeciwnym wypadku ciężko będzie poprawiać procesy poprzez zarządzanie jakością.
358 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.0.1 Zrozumienie natury zarządzania jakością 9.0.1.P1 Znajdź błędy tak szybko jak to możliwe Koszt jakości Kierownik Hewlett-Packard kiedyś powiedział: „Jeśli weźmiesz dwu centowy opornik i nie umieścisz go w części składowej komputera a wyrzucisz go przed użyciem, to straciłeś dwa centy. Jeśli go nie znajdziesz, naprawa komputera może kosztować cię nawet 10 dolar ów”. Ten koszt może przekroczyć koszt produkcji. Jednym z celów zarządzania jakością jest odnajdywanie błędów i defektów w projekcie, tak wcześnie - jak to tylko możliwe. Dlatego dobry proces zarządzania jakością będzie czasochłonny i kosztowny. Jednakże w trakcie postępu projektu następuje duży zwrot z tej „inwestycji”. Przykładowo, o wiele łatwiej jest dostrzegać problemy przez pryzmat wymagań, jakie stawia biznes podczas fazy analizy projektu, niż powtarzać pracę z powodu wykrycia problemu podczas testowania. Również o wiele taniej jest odszukać problem w układzie elektronicznym w trakcie jego produkcji, niż wymieniać go, kiedy klient przyniesie gotowy komputer do serwisu. Innymi słowy zespół projektowy powinien próbować utrzymać wysoką jakość i jak najmniejszą ilość usterek podczas procesu tworzenia, niż mieć nadzieję na wyłapanie i rozwiązanie problemów podczas fazy testowania na koniec projektu (albo co gorsza, gdy klient znajdzie ten problem po tym, jak projekt zostanie ukończony). Kontrola na początku i koszty prewencji mogą wzrosnąć przy skutecznym zarządzaniu jakością. Jednak ten wzrost będzie znacznie mniejszy niż ogólny koszt związany ze złą jakością produktu w całym cyklu jego życia.
359 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Dobrym rozwiązaniem jest dokonywanie kontroli jakości i jej zapewnianie poprzez cały czas trwania projektu. Powinieneś zapobiegać tylu błędom, ile to tylko możliwe. Istotne jest także, aby robić to możliwie najszybciej, aby zminimalizować koszt ich poprawiania. 9.0.1.P2 Kontrola i zapewnianie jakości. Zanim zostaną zdefiniowane ogólne procesy jakości, przedstawione zostanie krótkie wyjaśnienie definicji kontroli jakości i zapewniania jakości.
Kontrola jakości odnosi się do czynności związanych z poziomem jakości przedmiotów dostawy. Używana jest, by zweryfikować, czy jakość przedmiotów dostawy jest do zaakceptowania i czy pokrywają się one z kryteriami kompletności i jakości ustalonymi w procesie planowania jakości. Kontrola jakości jest nieustannie przeprowadzana poprzez projekt i jest obowiązkiem członków zespołu i kierownika projektu. (W celu uzyskania dodatkowych informacji i przykładów zobacz rozdział: 9.2.2 Zarządzanie jakością / Kontrola jakości.) Zapewnianie jakości nie nawiązuje bezpośrednio do konkretnych przedmiotów dostawy, ale nawiązuje do procesów używanych w trakcie ich tworzenia. Czynności zapewnienia jakości skupiają się na procesach zarządzania i dostarczania rozwiązania. Mogą być one wykonywane przez kierownika, klienta lub osobę trzecią. Na przykład, niezależny audytor projektu może nie być w stanie określić, czy konkretny przedmiot dostawy jest do zaakceptowania. Powinien on umieć stwierdzić, czy przedmiot dostawy może być zaakceptowany na podstawie procesu jego tworzenia. Może on określić, czy były wykonywane przeglądy, czy były przeprowadzane odpowiednie testy, czy klient zatwierdził pracę itd. (Zobacz rozdział: 9.2.3 Zarządzanie jakością / Zapewnienie jakości.)
Zapewnianie jakości odbywa się na poziomie wyższym niż kontrola jakości. Na przykład możesz badać 100% produktów, które wytwarzasz. Taka fizyczna kontrola jest przykładem kontroli jakości. W czasie sprawdzania odkryjesz, że 3% produktów zawiera usterki i wyrzucisz je. Uważasz to za akceptowalny koszt, i powtarzasz takie działanie, ciągle wyrzucając 3% produktów. Jeśli jednak używasz technik zapewnienia jakości, znajdziesz powód wystąpienia 3% defektów. Gdy raz odkryjesz przyczynę tych błędów, zmienisz proces produkcji, tak by je wyeliminować. Ta praca nad procesami jest właśnie zapewnianiem jakości. 360 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Zaowocuje to mniejszą ilością błędów znalezionych podczas procesu badania (kontroli jakości).
361 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.1. Zarządzanie jakością / Proces W tym dziale opisane są procesy zarządzania jakością. Procesy te mogą być modyfikowane w zależności od Twojego projektu, a później wstawione do Planu zarządzania projektem, który powstaje podczas kroku 1.0 Definiowanie projektu. 9.1.1 Małe projekty Małe projekty nie są wystarczająco długie, by ulepszać procesy pracy wewnętrznej w celu zapewnienia jakości. Małe projekty powinny być jedynie rozpatrywane pod kątem poszczególnych kroków kontroli jakości. Każdy wyprodukowany przedmiot dostawy powinien być poddany kontroli i zatwierdzony. Ostateczny przegląd (być może jedyny) dokonywany jest z klientem. Skupia się on na ogólnej jakości przedmiotu dostawy. Jeśli przedmiot dostawy może być przetestowany, przegląd będzie również zawierał dyskusję na temat procesów testowania i aktualnych wyników testu. 9.1.2 Zarządzanie jakością średnich projektów 9.1.3 Zarządzanie jakością dużych projektów
362 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.1.2 Zarządzanie jakością / Średnie projekty Początek projektu 9.1.2.P1 Planowanie jakości
1
Rola
Zarządzanie jakością (średnie projekty).
Kierownik projektu
Określ oczekiwania klienta co do jakości. Współpracuj ze swoim klientem, by określić jego oczekiwania w zakresie jakości. Jest to szczegółowa charakterystyka ważna dla klienta. Ogólny poziom charakterystyk jakościowych może zostać zidentyfikowany podczas procesu definiowania projektu. Szczegółowe wymagania co do jakości powinny być zapisane, kiedy zgromadzisz wymagania biznesowe.
2
Kierownik projektu
Stwórz plan jakości. Stwórz plan jakości, by opisać kryteria kompletności i poprawności przedmiotów dostawy, czynności kontroli jakości i czynności zapewniające jakość. Plan jakości pozwoli ci zrozumieć, kiedy przedmioty dostawy są gotowe i jak rozpoznać, że są poprawne. Plan jakości również opisuje jak masz się upewnić, że wymagania klienta są spełnione. Jest to także miejsce na to by opisać procesy i czynności, które zostaną zebrane by upewnić się, że produkowane są przedmioty dostawy dobrej jakości. Plan jakości zawiera opis zapewnienia jakości i planów kontroli jakości. Czynności realizujące implementację tych procesów powinny zostać dopisane do harmonogramu.
W czasie trwania projektu 9.1.2.P2 Kontrola jakości i zapewnienie jakości
3
Kierownik projektu.
Przeprowadzanie czynności kontroli jakości. Upewnij się, że czynności związane z kontrolą jakości
363 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
dla każdego przedmiotu dostawy są wykonywane w toku projektu. (Jedną z powszechnych technik kontroli jakości jest przegląd przedmiotu dostawy który jest opisywany bardziej szczegółowo punkcie 9.1.3.1 Przegląd przedmiotów dostawy. 4
Kierownik projektu.
Przeprowadzanie czynności kontroli jakości. Podczas projektu, przeprowadź wszystkie czynności związane z zapewnianiem jakości, które są wyszczególnione w harmonogramie.
5
Kierownik projektu.
Uaktualniaj i monitoruj plan jakości. Przejrzyj i oceń plan jakości w co miesiąc lub po zrealizowaniu najważniejszych kamieni milowych. Przegląd powinien skupiać się na tym, czy plan jakości jest adekwatny do naszego przedmiotu dostawy i oczekiwań klienta. Jeśli tak nie jest, zaktualizuj plan jakości i harmonogram.
6
Kierownik projektu.
(opcjonalnie) Przeanalizuj kluczowe procesy na koniec projektu. Na koniec swojego projektu dostarcz informację zwrotną bazującą na wynikach procesu jakości i pokaż uzyskane miary. Ten krok może być pominięty, jeśli Twoja organizacja nie zbiera metryk standardowych projektów.
364 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.1.3 Zarządzanie jakością / Duże projekty Początek projektu 9.1.3.P1 Duże projekty
1
Rola
Zarządzanie jakością ( duże projekty )
Kierownik projektu.
Określ oczekiwania klienta co do jakości. Współpracuj ze swoim klientem, by określić jego oczekiwania w zakresie jakości. Jest to szczegółowa charakterystyka ważna dla klienta. Ogólny poziom charakterystyk jakościowych może zostać zidentyfikowany podczas procesu definiowania projektu. Szczegółowe wymagania co do jakości powinny być zapisane, kiedy zgromadzisz wymagania biznesowe.
9.1.3.P2 Planowanie jakości
2
Kierownik projektu
Stwórz plan jakości. Stwórz plan jakości, by opisać kryteria kompletności i poprawności przedmiotów dostawy, czynności kontroli jakości i czynności zapewniające jakość. Plan jakości pozwoli ci zrozumieć, kiedy przedmioty dostawy są gotowe i jak rozpoznać, że są poprawne. Plan jakości również opisuje jak masz się upewnić, że wymagania klienta są spełnione. Jest to także miejsce na to by opisać procesy i czynności, które zostaną zebrane by upewnić się, że produkowane są przedmioty dostawy dobrej jakości. Plan jakości zawiera opis zapewnienia jakości i planów kontroli jakości. Czynności realizujące implementację tych procesów powinny zostać dopisane do harmonogramu.
3
Kierownik projektu
Określ komplet miar, by móc stwierdzić, że spełnione są wymagania jakościowe. Zidentyfikuj komplet miar, które dadzą ci wgląd w postęp projektu oraz procesy używane do tworzenia przedmiotów
365 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
dostawy. Kierownik projektu powinien zbierać ogólne miary dotyczące aspektów czasowych i finansowych. Miary odnoszące się do jakości muszą być bardziej wyrafinowane. Są dwie płaszczyzny, na których zarządzasz jakością - pierwsza to procesy pracy w ramach Twojego projektu, a druga to rzeczywiste, budowane przez Ciebie, przedmioty dostawy. Powinieneś spróbować stworzyć takie miary, które będą opisywały oba aspekty. Przykładowe miary procesów zapewniających jakość zawierają:
Satysfakcję
klienta z komunikacji z zespołem
projektu.
Ilość
zidentyfikowanych ulepszeń wprowadzonych po przeprowadzeniu wstępnej analizy.
Ilość
czasu spędzonego na rozwiązywanie problemów krytycznych. Przykłady miar dla kontroli jakości przedmiotu dostawy lub produktu zawierają:
Liczbę najważniejszych błędów wykrytych podczas testowania.
Czas
reakcji budujesz.
programu
komputerowego,
który
Średni czas, w jakim produkt zawodzi. (Dodatkowe informacje o pomiarach znajdziesz w procesie 10.0 Zarządzanie pomiarem.)
W trakcie trwania projektu 9.1.3.P3 Zapewnienie jakości
4
Kierownik projektu
Wykonuj czynności zapewnienia jakości. W trakcie projektu wykonuj czynności zapewnienia jakości zgodnie z aktualnym harmonogramem.
9.1.3.P4 Kontrola jakości
5
Kierownik projektu
Wykonuj kontrolę jakości. Upewnij się, że czynności kontroli jakości dla każdego przedmiotu dostawy są wykonywane w czasie trwania
366 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektu. Jako niezbędne minimum powinieneś mieć formalny proces kontroli przedmiotów dostawy. Jest on opisany w bardziej szczegółowy sposób w punkcie 9.1.3.1 Przegląd przedmiotu dostawy.
9.1.3.P5 Aktualizacja i nadzór
6
Kierownik projektu
Uaktualniaj i monitoruj plan jakości. Przejrzyj i oceń plan jakości w co miesiąc lub po zrealizowaniu najważniejszych kamieni milowych. Przegląd powinien skupiać się na tym, czy plan jakości jest adekwatny do naszego przedmiotu dostawy i oczekiwań klienta. Jeśli tak nie jest, zaktualizuj plan jakości i harmonogram.
7
Kierownik projektu
Zbieraj miary, by być pewnym, że postępujesz cały czas zgodnie z założeniami jakości. Podczas projektu pamiętaj o miarach, z których większość powinna być zbierana co miesiąc. Niektóre, takie jak: ankiety satysfakcji klienta, mogą być zbierane co kwartał. Jeśli budujesz lub wytwarzasz coś materialnego, możesz codziennie zbierać miary w sposób zautomatyzowany.
8
Kierownik projektu
Analizuj miary w celu poprawy procesu. Analizuj wyniki pomiarów by określić, w jaki sposób możesz poprawić procesy Twojego projektu. Przykładowo, proces kontroli przedmiotu dostawy może być wykonany dwukrotnie, gdy przedmiot dostawy jest gotowy w 50% oraz gdy jest on kompletny. Wymagany czas na tego typu przegląd może zwrócić się w postaci dramatycznego skrócenia czasu na poprawki błędów wykrytych, kiedy produkt jest gotowy. W procesach wytarzania możesz potrzebować ulepszenia sprzętu, dodatkowych szkoleń dla operatorów lub inwestycji w lepsze materiały.
9
Kierownik projektu
Analizuj i rozwiązuj problemy dotyczące jakości. Kiedy pojawią się problemy związane z jakością, wprowadź proces, który pozwoli ci dociec przyczyn i wprowadzić poprawki w procesie (zobacz punkt 9.1.2 Zarządzanie jakością).
367 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10
Kierownik projektu
Wprowadź ulepszenia, które zostały zidentyfikowane. Może być więcej zgłoszonych pomysłów na ulepszenia, niż możesz wprowadzić w czasie jednego cyklu przeglądu. Wyznacz priorytety wśród sugestii i wprowadź te, które wydają się mieć największą wartość i wymagają najmniejszych nakładów pracy. Inne pomysły możesz wprowadzić w następnym cyklu przeglądu i analizy.
11
Kierownik projektu
Kontynuuj pomiary. Możesz potrzebować identyfikacji nowych lub ulepszonych pomiarów w celu wsparcia nowych albo ulepszonych procesów.
12
Kierownik projektu
(opcjonalnie) Przejrzyj czego się nauczyłeś na koniec projektu. Na koniec projektu zgromadź i przedstaw informacje, dotyczące rezultatów procesu jakości oraz wyniki końcowych pomiarów. Może to zostać użyte do poszerzania programu miar w całej organizacji i dostarczyć informacji o najlepszych rozwiązaniach przydatnych w późniejszych projektach. Ten krok może być pominięty, jeśli Twoja organizacja nie zbiera standardowych miar projektów.
9.1.3.1 Przegląd przedmiotów dostawy 9.1.3.1.P1 Przeglądy mogą dotyczyć wielu przedmiotów dostawy wytwarzanych przez projekt, np. harmonogramu czy listy wymagań biznesowych, badań, kampanii marketingowych, kodu programu komputerowego, itp. Nie można jednak w ten sam sposób przeglądać namacalnych, materialnych przedmiotów dostawy takich jak: pojazdy, odzież, nowy komputer, części do samolotów. Do tego służą inne techniki takie jak: inspekcje, które dopuszczają do użytku przedmioty dostawy tego typu. Poniższy proces może być stosowany do planowania i przeprowadzania formalnych przeglądów.
1
Rola
Formalny przegląd przedmiotów dostawy
Kierownik projektu
Wyznacz odpowiednich uczestników przeglądu. Angażuj tylko tych ludzi, którzy mogą wnieść znaczący wkład w przegląd. Im więcej ludzi bierze w nim udział, tym dłużej
368 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zazwyczaj taki przegląd trwa. Przeglądy przedmiotów dostawy są czynnościami kontroli jakości od momentu, w którym skupiają się na samym przedmiocie. Toteż spotykający się uczestnicy muszą być biegli w temacie przeglądanych przedmiotów dostawy. Uczestnikami są zazwyczaj współtworzący przedmiot dostawy. Może wystąpić potrzeba wielokrotnych przeglądów, by upewnić się, że duże przedmioty dostawy są tworzone prawidłowo. 2
Zespół do spraw kontroli
(opcjonalnie) Określ kryteria kompletności i poprawności. Zespół do spraw kontroli może ustalić tymczasowe kryteria odnośnie kompletności i poprawności przedmiotu dostawy. Takie tymczasowe kryteria są pomocne, gdyż zespół może wiedzieć wcześniej, że pełne kryteria nie będą spełnione, np. zanim przedmiot dostawy zastanie ukończony.
3
Wyślij materiały do przeglądu przed spotkaniem.
Dokonujący kontroli
Są sytuacje, kiedy nie jest to wykonalne. Jeśli jednak jest to możliwe, formalny przegląd będzie postępował szybciej, jeśli zespół będzie miał okazję by wcześniej zapoznać się z przedmiotem dostawy. 4
Dokonujący przeglądy zespół
Przeprowadź przegląd. i Twórca przedmiotu dostawy opowiada o pracy, którą wykonał w sposób logiczny i odpowiada na pytania uczestników. Podstawowe zasady przeglądu:
Przegląd nie może trwać dłużej niż godzinę. Jeśli przedmiot
dostawy jest za duży, by tego dokonać, rozważ rozłożenie przeglądu na mniejsze części, które już będą mogły być zrealizowane w godzinę.
Podczas
przeglądu uczestnicy powinni zadawać pytania, zgłaszać swoje spostrzeżenia i sugestie. Jeśli jakieś tematy wydadzą się zbyt skomplikowane, nie muszą być rozwiązywane w czasie obchodu. Powinny zostać odłożone na później. Tak samo, jak nie ma potrzeby osiągania kompromisu czy porozumienia. Jeśli jest to jednak niezbędne, to można to próbować zrobić po przeglądzie.
W wielu wypadkach zespół dokonujący przeglądu znajdzie
błędy w przedmiotach dostawy. W innych sprawach zespół przeglądający może wyrazić swoją opinię lub sugestię, która może, ale wcale nie musi być zastosowana. W momencie przekazania informacji zwrotnej powinno być
369 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
jasne, czy członek zespołu odkrył błąd, który powinien być naprawiony, czy wyraża tylko sugestię, do której można by się ewentualnie dostosować.
Nie pozwól by komentarze odnosiły się do osób. Oceniasz
produkt, a nie osobę, która go stworzyła. Zamiast mówić, że twórca popełnił błąd, lepiej omów problem, kierując swoją opinię do cech przedmiotu dostawy. Zamiast mówić, że to autor jest niedbały, można pokazać obszar przedmiotu, który według recenzenta jest niepoprawnie wykonany.
Jeśli
pojawią się problemy krytyczne związane z samym autorem przedmiotu dostawy lub procesami jego tworzenia, należy je przedyskutować na oddzielnym spotkaniu.
Stwórz listę czynności zleconych do wykonania w czasie przeglądu.
5
6
Zespół dokonujący kontroli
Sprawdź także procesy.
Zespół dokonujący kontroli
Zakończ przegląd.
Przegląd przedmiotu dostawy powinien skupiać się na jego kompletności i poprawności. Jednakże recenzenci powinni również wziąć pod uwagę procesy jego tworzenia , np.: czy były używane prawidłowe szablony, czy otrzymano odpowiednie zgody, czy był on tworzony zgodnie z wszelkimi zasadami. Tego typu pytania wiążą się z zapewnieniem jakości i są tak samo ważne w czasie przeglądu. Przegląd jest w stanie dostarczyć informacji, czy przedmiot dostawy oraz procesy biorące udział w jego tworzeniu są do zaakceptowania.
Określ, jak wypadła ocena przedmiotu dostawy według następujących ocen:
Pozytywnie.
Przedmiot dostawy spełnia wszystkie postawione mu kryteria i nie wymaga dalszego przeglądu. Mogą wystąpić jakieś drobne zmiany, ale ogólnie nie wymaga on już poprawek.
Potrzeba
więcej pracy. Przedmiot dostawy wymaga przeróbek, by spełnić kryteria postawione w czasie przeglądu. Wszelkie czynności z przebiegu przeglądu powinny być udokumentowane i przedstawione na najbliższym spotkaniu. Jeśli przedmiot dostawy nie przeszedł pozytywnie przeglądu, będzie on prawdopodobnie wymagał ponownej kontroli po wprowadzeniu poprawek według tych samych kryteriów.
7
Recenzent
Ogłoś wyniki kontroli. Upewnij się, że wszystkie zainteresowane strony otrzymały
370 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wyniki kontroli.
9.1.2. Zarządzanie jakością / Rozwiązywanie problemów z jakością 9.1.2.P1 Problemy związane z jakością mogą nie urastać do rangi problemów krytycznych, lecz nadal pozostają problemami i mogą być rozwiązywane za pomocą technik opisanych w procesie 4.0: Zarządzanie problemami krytycznymi. Zgadywanie przyczyn problemu nie daje dobrych wyników. O wiele lepiej działa ustrukturyzowane podejście do sprawy. Chcesz nie tylko rozwiązać dany problem, ale chcesz również zrozumieć ten problem na tyle, byś mógł zidentyfikować jego przyczynę i upewnić się, że nie wystąpi on już nigdy więcej. Ogólny opis procesu rozpoznawania i rozwiązywania problemów jakości.
1
2
3
4
Rola
Postępowanie z problemami jakości.
Kierownik projektu
Rozpoznaj problem lub symptom.
Kierownik projektu
Rozpoznaj główną przyczynę.
Kierownik projektu
Określ alternatywy i wpływy.
Kierownik projektu,
Wybierz najlepsza alternatywę.
Nie zakładaj, że wszyscy już o problemie wiedzą. Przeznacz trochę czasu na przedstawienie problemu w klarowny sposób tak, żeby każdy był w stanie go zrozumieć. Upewnij się, że wyjaśniłeś również wpływ, jaki wywiera on na cały projekt.
To jest najważniejszy krok. Powinieneś jasno określić główną przyczynę problemu i wyjaśnić, jak rzutuje ona na cały proces. Jeśli jednak nie możesz określić przyczyny dostrzeżonego problemu, to znaczy, że szukałeś zbyt powierzchownie. Istnieją techniki identyfikujące, które są opisane w procesie 4.0 Zarządzanie problemami krytycznymi. Tam znajduje się opis, w jaki sposób skupić się na głównej przyczynie problemu.
Kierownik projektu może zlecić określenie alternatyw decyzyjnych (scenariuszy rozwiązań) jednej lub wielu osobom. Do każdej z tych alternatyw powinni oni przypisać wpływ, jaki wywrze ona na projekt.
Zespół projektowy wraz z klientem mogą być zaangażowani
371 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
5
6
członek zespołu
w określanie najlepszej alternatywy. Zespół projektowy może także być w stanie rozwiązać problem samodzielnie, jeśli nie stanowi on formalnego problemu krytycznego. Tak naprawdę mógłby to być tymczasowy problem z dopracowaniem przedmiotu dostawy, który śmiało może być kontrolowany przez zespół.
Kierownik projektu
Rozwiąż problem.
Kierownik projektu
Sprawdź, czy problem został rozwiązany.
Stwórz mini-plan rozwiązania i przypisz zadania w nim zawarte odpowiednim osobom. Czynności te powinny być naniesione w harmonogramie.
Proces musi być jeszcze raz poddany weryfikacji, by upewnić się, czy jakość się poprawiła tak, jak tego oczekiwano. Jeśli tak właśnie jest lub wszystko idzie w tym kierunku, będziesz musiał jedynie prowadzić monitoring. Jeśli jednak jakość się nie poprawiła, jak zakładano, muszą zostać podjęte dalsze czynności korygujące.
372 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2 Zarządzanie jakością / Techniki 9.2.P1 Zrozum charakterystyki jakościowe Twojego projektu Ciężko jest zdefiniować jakość produktu czy usługi na wysokim poziomie, gdyż termin „jakość” może być niejasny i dla każdego znaczyć coś innego. Musisz poświęcić trochę czasu, by określić dokładne cechy jakości dla każdej usługi czy produktu. Jeśli chcesz być pewien, że usługa czy produkt spełnia oczekiwania klienta, musisz zapoznać się z poniższą tabelą. Poniższa tabela pokazuje przykłady charakterystyk jakościowych.
Jakość produktu – produkt jest:
Jakość usługi – ludzie są:
Niezawodny
Żywo reagujący
Łatwy w użyciu
Kompetentni
Łatwy w utrzymaniu
Dostępni
Dostępny w każdej chwili
Uprzejmi
Dostosowuje się do potrzeb
Komunikatywni
Warty zapłaconych pieniędzy
Wiarygodni
Intuicyjnie odsługiwany / łatwy w obsłudze
Znający klienta Niezawodni
Bezpieczny Dobrze udokumentowany Posiada minimalną ilość defektów (nie musi być idealny) Ma dobry czas reakcji Dostosowany do potrzeb klienta
9.2.P2 Przeprowadzaj czynności kontrolne by sprawdzić jakość swoich produktów Czynności kontrolne skupiają się na ogólnej jakości produkowanego przedmiotu dostawy. W zależności od rodzaju projektu, następujące czynności mogą być przykładowymi czynnościami kontrolnymi jakości:
Przeglądy przedmiotów dostawy / przeglądy techniczne / przeglądy kodu. (więcej informacji zobacz punkt: 9.1.3.1 Przeglądy przedmiotów dostawy.)
373 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Listy
kontrolne zapewniające, że przedmioty dostawy są spójne, kompletne i zawierają wszystkie niezbędne informacje. (Na przykład zobacz punkt: 9.2.2 Listy kontrolne.)
Ponowne użycie sprawdzonego oprogramowania. Standardy zapewniające spójność. Ustrukturyzowane metody zapewniające standard używanych procesów. Testowanie (jednostka, system, integracja, akceptacja). Testowanie
jest prawdopodobnie najczęściej stosowanym dzisiaj aspektem kontroli jakości, pomimo tego, że istnieje wiele innych technik budujących jakość. Pewność, którą masz co do ogólnej jakości, w większości płynie z testowania. Z tego powodu nie możesz pominąć testowania. Jest ono Twoją ostatnią szansą, by upewnić się, że rozwiązanie, które dostarczasz pokrywa się z oczekiwaniami klienta. Mówiąc ogólnie testowanie jest sposobem na to, by się przekonać, czy rozwiązanie jest w pełni satysfakcjonujące i wolne od defektów. Na niższym poziomie testowanie jest również sposobem na: Udowodnienie wiarygodności. Upewnienie się, czy rozwiązanie będzie działało w środowisku produkcyjnym. Upewnienie się, że rozwiązanie nie zawiedzie po pewnym czasie. Upewnienie się, że rezultaty nie obniżają się w czasie.
9.2.P3 Użyj czynności zapewnienia jakości, by usprawnić procesy używane w budowie przedmiotu dostawy Jako, że zapewnianie jakości związane jest z procesami tworzenia przedmiotu dostawy, najskuteczniejszą techniką jest tutaj formalny audyt procesu zapewnienia jakości. W przeglądzie jakości strona trzecia zadaje pytania dotyczące procesów powstawania przedmiotów dostawy, by upewnić się, że są właściwe. Sam przedmiot jako taki nie musi wcale podlegać sprawdzeniu. Audyt jakości powinien również udowodnić, że procesy zapewnienia jakości są przestrzegane. Przykładowo, jeśli zespół posiada formalny proces zarządzania problemami krytycznymi i zakresem, audyt dokona przeglądu problemów krytycznych i zmian w projekcie, by stwierdzić, czy procesy te były rzeczywiście przestrzegane. Będzie to dotyczyło kontroli Dziennika problemów krytycznych, Dziennika zmian zakresu, czynności w harmonogramie, Raportów stanu itp. To powinno wykazać, jak sprawnie zespół przestrzega reguł wspomnianych wyżej procesów. Kolejną czynnością zapewnienia jakości jest użycie listy kontrolnej, która sprawdza, czy procesy były przestrzegane. Na przykład taka lista może zawierać daty zakończenia produktów, daty przeglądów, sprawdzenie czy wszystkie czynności zostały wykonane, datę zatwierdzenia przez klienta itp. Jeśli tylko lista skupia się na procesie a nie na produkcie, jest przykładem narzędzia zapewniania jakości. (Zobacz punkt 9.2.3 Lista kontrolna.) 9.2.P4 Miej pewność co do kosztów i korzyści jakości Jedna z podstawowych zasad zarządzania jakością mówi, że ogólne korzyści z budowania jakości będą większe niż przewaga jakichkolwiek podnoszonych kosztów. 374 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
(Po wyjaśnienie kosztu jakości, korzyści jakości i kosztu złej jakości sięgnij do punktu: 9.2.1 Koszty i korzyści z jakości.) 9.2.P5 Nie „przedobrzaj‖ (nie dostarczaj więcej, niż klient sobie tego życzy) Powinieneś zawsze starać się sprostać postawionym przez klienta oczekiwaniom. Jeśli jednak nie jesteś pewien swoich możliwości, to zapamiętaj taką radę: „Lepiej nie obiecywać niż nad-obiecywać”. Dobrze jest, jeśli uda się osiągnąć wcześniejszą dostawę, czy niższą niż ustalona cenę. Nie jest jednak dobrze, gdy sam podnosisz poprzeczkę i tworzysz jakość wyższą niż klient tego wymagał. Używany powszechnie termin: „pozłacanie” oznacza dostarczenie przedmiotu dostawy o wyższym standardzie, niż klient tego wymaga. Choć wydawałoby się, że nic w tym złego – nie jest to dobre rozwiązanie, co najmniej z dwóch powodów. Pierwszy to taki, że powinieneś skupić się na tym, by dostarczyć to, czego chce klient – na czas i w ramach wyznaczonego budżetu. Poprzez dodawanie czegoś z własnej inicjatywy ryzykujesz, że nie dotrzymasz terminu lub przekroczysz budżet. Jeśli dojdzie z tego powodu do opóźnień, to Twoje tłumaczenie, że chciałeś „lepiej”, raczej nie spotka się z sympatią klienta. Po drugie, jeśli przedobrzysz i „pozłocisz”, bierzesz na siebie odpowiedzialność podjęcia biznesowej decyzji, co jest dla klienta największą wartością. Może istnieć wiele dobrych powodów, dla których dodatkowe cechy nie zostały zawarte w zakresie projektu. Mogą być one dla klienta marginalne. Może być dla klienta ważniejsze szybkie ukończenie przedmiotu dostawy i za mniejsze pieniądze. Najistotniejsze jest to, że to jest decyzja klienta i nie leży ona w uprawnieniach kierownika projektu. Nie mówiąc już o tym, że za pracę nad nieplanowanymi dodatkami zapłaci sponsor. Nieobiecywanie czy nad-obiecywanie powinno występować tylko wtedy, gdy wiąże się z możliwością wcześniejszej dostawy lub mniejszymi kosztami niż spodziewane. Nie dopuszcza się jednak dodawania czegoś, o co klient nie prosił. Może on oczywiście to uczynić i wtedy należy te nowe wymagania wdrożyć w trybie zmiany zakresu. Może być też tak, że klient będzie miał inne pomysły na zagospodarowanie zaoszczędzonych pieniędzy. Jeśli możesz ukończyć projekt szybciej lub pomniejszyć koszty, to zostaw decyzję klientowi, co zrobić z oszczędnościami. 9.2.P6 Upewnij się, że zarządzanie jakością skupia się na procesach a nie na ludziach Celem zarządzania jakością jest budowanie prawidłowych procesów, tak by cały zespół mógł produkować przedmioty dostawy zgodnie z oczekiwaniami klienta. Z tego też powodu, jeśli pojawia się problem z jakością, kierownik projektu i cała grupa powinni skoncentrować się na tym, jak poprawić procesy pracy, a nie dochodzić, kto jest winny. Większość problemów z jakością jest wynikiem słabych lub nieadekwatnych procesów realizacyjnych, nie z powodu złośliwego działania konkretnej osoby. Sądzi się, że co najmniej 80% problemów jakościowych może być rozwiązanych poprzez zmianę i umocnienie procesów biznesowych. Mniej niż 20% problemów jest pod kontrolą członka zespołu. Co więcej, procesy, które są wykorzystywane przez Twoją organizację są w dużym zakresie zależne od zarządzania. Więc, gdy pracownicy lub członkowie zespołu mają problemy z jakością, ważne jest by kierownicy odszukali słaby lub niedziałający proces i zmienili go. Jest to odpowiedzialność zarządzających, a nie załogi. Nie znaczy to, że nie każdy może być w to zaangażowany (zobacz poniższe techniki). Jednak ustanawianie i egzekwowanie procesów biznesowych jest jednym z głównych zadań zarządzającego. 375 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2.P7 Kładź nacisk na to, że jakość jest obowiązkiem każdego Na kierowniku projektu ciąży ogólna odpowiedzialność za procesy zarządzania jakością. Niektóre projekty nakładają również specyficzną rolę osobie, która tą jakość zapewnia lub testuje. Jeśli nawet masz konkretne osoby odpowiedzialne za jakość, to jakość projektu nie jest odpowiedzialnością jednego lub dwóch ludzi. Cały zespół, z klientem włącznie, ma obowiązek ciągłego sprawdzania, czy przedmioty dostawy są dobrej jakości. Każdy jest także odpowiedzialny za dostarczanie wskazówek mogących ulepszyć procesy tworzenia przedmiotu dostawy. Promuj takie zachowania. 9.2.P8 Upewnij się, że wysoka jakość jest szanowaną wartością, a nie tylko zwykłym elementem procesu W niektórych projektach jakość jest postrzegana jako konkretny krok w danym procesie lub też seria czynności na końcu procesu. Skutecznie działający zespół musi ciągle mieć na uwadze potrzebę zachowania jakości. Członkowie zespołu muszą poczuć się jak właściciele produkowanych przedmiotów dostawy i upewniać się, że jakość jest taka sama jak na początku produkcji. Nie mogą oni również wykazywać postawy wycofanej, podczas gdy ktoś inny dokonuje recenzji ich pracy. Muszą oni zdawać sobie sprawę z tego, że proces jakości pozwala całemu zespołowi projektowemu na produkowanie przedmiotów dobrej jakości, z minimalną ilością błędów i poprawek. Jakość projektu rozpoczyna się planowaniem, ale egzekwowanie jej musi być kontynuowane poprzez cały projekt. Wielowymiarowe podejście do zagadnienia jakości zawiera następujące aspekty:
Wczesne ustanowienie Planu jakości. Wbudowanie odpowiedzialności za jakość w zespół (na przykład poprzez trening, proaktywną komunikację)
Wbudowanie jakości w procesy realizacyjne Wbudowanie jakości produkty procesu zarządzania projektem. Wbudowanie jakości w produkty projektu. 9.2.P9 Odszukaj i zminimalizuj poprawki Mówiąc wprost, jeśli masz rygorystyczne procesy jakości, nie ma nawet powodu by dyskutować o poprawkach. Tak naprawdę poprawka jest wynikiem nieposiadania od samego początku wystarczająco rygorystycznych procesów jakości. Ale bądźmy również praktyczni. Żaden projekt nie może pozwolić sobie na to, by poświęcać czas i wysiłek, na tworzenie produktu od razu wprost idealnego. Nawet firma prosperująca na poziomie „Six Sigma” zakłada (chociażby minimalne) prawdopodobieństwo błędu. Więc załóżmy, że masz wspomniany Plan jakości. Nadal borykasz się z poprawkami. W niektórych metodykach zarządzania projektami, które dopuszczają produkcję przedmiotów dostawy pozbawionych wymogów czy początkowej jakości, poprawki mogą wynikać wręcz z natury projektu. Jest kilka rzeczy, o których musisz pamiętać, jeśli chodzi o poprawki:
376 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Poprawka nie jest tym samym, co normalny proces otrzymywania informacji zwrotnej
o produkcie. Jeśli stworzysz dokument i przed opublikowaniem puścisz go w obieg, by otrzymać opinię o nim, to po jej odebraniu nie będziesz niczego „poprawiał”. Ewentualne zmiany wprowadzone do dokumentu są Twoim sposobem na upewnienie się, że dobrze zaczniesz. Jeśli jednak opublikujesz gotowy dokument i potem znajdziesz w nim jakieś błędy, to będzie to niestety wymagało mniej lub bardziej kosztownych poprawek.
Choć możesz akceptować poprawki jako naturalną część projektu, nie znaczy to, że
kierownik projektu i jego zespół nie będą usiłowali tego wyeliminować. Twoim celem powinno być zawsze eliminowanie defektów i poprawek poprzez nieustanne poprawianie procesów.
Jeśli musi być naniesiona poprawka, znajdź ją w jak najwcześniejszej fazie życia
produktu. Pamiętaj, że błędy w analizie prowadzą do błędów w projektowaniu i konstruowaniu. Jeśli nie znajdziesz ich aż do fazy testowania, może zaistnieć potrzeba wprowadzenia poprawek wstecznie poprzez cały cykl życia produktu (fazę analizy, projektowania i konstrukcji). Z drugiej strony istnieje mniejsza szansa wystąpienia takiej sytuacji, jeśli przeznaczysz czas na szukanie błędów podczas fazy analizy i każdej kolejnej fazy projektu.
Możesz
śledzić poprawki, by określić, ile czasu przeznaczonego na projekt marnujesz pracując nad tym samym problemem dwukrotnie. Dla przykładu, w procesie testowania zwróć uwagę na liczbę naprawionych błędów. Kiedy są one poprawiane możesz spostrzec, że zmiana ta nie polega tylko na odpowiedniej naprawie występującego problemu. Możesz też odkryć, że wprowadzenie jednej zmiany może zepsuć coś innego. Ten drugi nieumyślny błąd również będzie wymagał poprawki. Możesz śledzić liczbę błędów naprawionych, jak również ogólną liczbę błędów wymagających poprawek. Jeśli zespół męczy się i długo pracuje, liczba poprawek wzrasta. Będziesz chciał na pewno ograniczyć ilość poprawek do zera, jeśli to możliwe.
Poprawka nie jest tym samym, co zmiana zakresu. Poprawka jest powodowana
przez problemy powstałe w procesie zarządzania jakością. Jest ona potrzebna, by podnieść poziom jakości przedmiotu dostawy do tego, który powinien być od samego początku. Zmiana zakresu nawiązuje do modyfikacji części przedmiotu dostawy, z powodu nowych wymagań. Włożona praca i koszty związane z poprawką muszą mieścić się w projekcie. Nie dotyczy to przypadku zmiany zakresu – tam za zmianę powinien zapłacić klient.
9.2.P10 Wykorzystuj solidne techniki rozwiązywania problemów z jakością Istnieje duża ilość technik, które mogą być stosowane, by identyfikować przyczyny problemów jakości oraz określać, których należy pozbyć się w pierwszej kolejności. Są to takie same techniki, jakie możesz stosować przy rozwiązywaniu problemów innego typu. Trzy popularne techniki opisane są w rozdziale 4.0 Zarządzanie problemami krytycznymi / Techniki. Więcej informacji na temat rozwiązywania problemów jakości znajdziesz w punkcie 9.1.3.2: Zarządzanie jakością / Rozwiązywanie problemów z jakością. 9.2.P11 Używaj technik kontroli statystycznej, by upewnić się, że proces jest pod kontrolą
377 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Gdy przyglądasz się przyczynom defektów przedmiotów dostawy, zauważasz, że należą one do dwóch kategorii. Dr. Edward Deming nazwał je „przyczyną specjalną” i „przyczyną powszechną”. Błędy z przyczyn specjalnych to takie, które użytkownicy produktu potrafią znaleźć i naprawić. Zalicza się do nich brak wprawy, nieodpowiednie użytkowanie sprzętu, wandalizm itp. Przyczyny powszechne mogą powodować duże różnice w jakości oraz zawierać częste problemy, których użytkownicy końcowi nie są świadomi. Przykładowo błędy z przyczyn powszechnych mogą polegać na drobnych niedoskonałościach sprzętu, słabym wyglądzie produktu, działających lecz niezoptymalizowanych procesach, itp. Są to właśnie problemy powszechne, ale trudne do wykrycia dla użytkownika. Techniki statystycznej kontroli procesów (Statistical Process Control, SPC) mogą być używane do monitorowania, zarządzania, analizowania i poprawiania wydajności procesów przez eliminację przyczyn specjalnych (tych problemów, które są łatwo wykrywalne). W celu uzyskania szczegółowych informacji na temat SPC przeczytaj punkt: 9.2.4 Zarządzanie jakością/Statystyczna Kontrola Procesu.)
378 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2.1 Zarządzanie jakością / Koszty i korzyści z jakości 9.2.1.P1 Koszt jakości Budowa jakości odzwierciedlona jest w harmonogramie. Wiąże się z określoną pracochłonnością i kosztami projektu. Te podwyższone koszty zostaną z nawiązką zbilansowane krótszymi terminami i zredukowanymi kosztami w cyklu życia przedmiotu dostawy. Oto przykładowe koszty jakości:
Przeglądy przedmiotów dostawy. Koszt związany z czasem ludzi uczestniczących w przeglądach (dotyczy on: przygotowania, rzeczywistego czasu kontroli dokonanej przez wszystkich uczestników oraz czasu pracy wykonanej według wskazówek pokontrolnych.)
Stworzenie Planu jakości. Czas wymagany do opracowania planu jakości poprzez projektowanie i rozwiązanie, włącznie z kryteriami kompletności i poprawności.
Zatwierdzenie
przez klienta. Czas i pracochłonność klienta przy przeglądzie przedmiotów dostawy (wstępnych i ostatecznych) oraz przy formalnym zatwierdzeniu ich poprawności i kompletności.
Testowanie.
To część cyklu życia projektu, jest wykonywane, by sprawdzić, czy przedmiot dostawy odpowiada wymaganiom i standardom jakości.
Standardy
kontroli jakości. Czas i koszty związane z określeniem odpowiednich standardów używanych poprzez projekt i / lub organizację.
Audyty. Audyty są sposobnością do zewnętrznego przeglądu procesów używanych
do tworzenia przedmiotów dostawy. Tacy audytorzy dostarczają świeżej perspektywy i obiektywnej opinii na temat procesów realizacyjnych i ich przestrzegania. W czasie audytu także kierownik projektu inne osoby poświęcają dodatkowy czas na część związaną z prowadzeniem przeglądu.
Listy kontrolne. Używana jest zwykle by sprawdzić czy wszystkie etapy procesu
zostały ukończone i czy wszystkie składniki produktu zostały wykonane. Istnieje koszt ich tworzenia i wypełniania.
Grupy kontroli
i zapewnienia jakości. Jeśli Twoja firma posiada oddzielne grupy specjalizujące się w kontroli i w zapewnianiu jakości, ich koszty są częścią ogólnych kosztów organizacyjnych.
Zbieranie miar. Pomiary stosuje się, by pokazać status procesu oraz by go poprawić
jeśli to niezbędne. Zbieranie miar zabiera trochę czasu i wiąże się z tym odpowiedni koszt.
9.2.1.P2 Korzyści wynikające z jakości Koszty jakości muszą być wyważone w stosunku do korzyści z dostarczania produktu wysokiej jakości. Podczas gdy wiele kosztów pojawia się w czasie trwania projektu, to wiele korzyści często dopiero po jego zakończeniu. Oto korzyści z jakości:
379 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Większa
satysfakcja klienta. Mniejsza ilość defektów oznacza, że klient będzie bardziej usatysfakcjonowany. Wyższa jakość usług powoduje, że doświadczenia klienta są o wiele przyjemniejsze. Może to spowodować zwiększenie ilości zamówień czy wystawienie pozytywnych rekomendacji.
Większa wydajność. Naprawianie błędów i poprawianie ukończonego przedmiotu dostawy stanowi potężne obciążenie pod względem wydajności. Tak naprawdę prowadzi to wręcz to wydajności negatywnej. Jeśli w produkcji występuje wyższa jakość i mniejsza ilość poprawek, to ogólna wydajność projektu wzrasta.
Niższe koszty / krótszy czas. Pomimo, że początkowy koszt procesów jakości jest
wyższy, to mniejsza ilość poprawek aż do końca projektu na pewno to zrekompensuje. Zaoszczędzisz zarówno czas jak i koszty.
Wyższe morale zespołu. Morale zespołu upadają, gdy wyjdzie na jaw wiele błędów.
Ludzie źle się z tym czują i są sfrustrowani, jeśli muszą ciągle naprawiać jakieś wady. Morale zespołu wzrasta (lub chociaż się stabilizuje), gdy przedmioty dostawy są od razu tworzone jedynie z nielicznymi błędami.
Mniej błędów / defektów. Wysoka jakość ujawnia się podczas cyklu życia gotowego
produktu poprzez mniejszą liczbę późniejszych błędów i defektów. Jeśli wytwarzasz produkt, by sprzedać go na rynku, to wyższa jakość oznacza mniej zwrotów, mniej napraw gwarancyjnych i napraw ogólnych. Jeśli tworzysz rozwiązanie długoterminowe, oznacza to mniej problemów z serwisem i konserwacją.
9.2.1.P3 Koszt złej jakości Budowa rozwiązań jakościowych wymaga pieniędzy i czasu. Możesz sądzić, że będzie taniej, gdy pozostawisz jakość na dotychczasowym poziomie, ale to rozwiązanie zazwyczaj się nie sprawdza. Ważne jest, by zrozumieć, że marna jakość również pociąga za sobą koszty. Koszty te mogą nie być widoczne, gdy projekt pracuje, ale powinny być obowiązkowo wzięte pod uwagę jako część pełnego cyklu życia dostarczanego przedmiotu. Koszty złej jakości:
Naprawy gwarancyjne. Są to prace wykonywane za darmo po obniżonej cenie, w ramach umowy gwarancyjnej. Rzeczywiste koszty takiej naprawy ponosi Twoja organizacja.
Naprawy / konserwacje. Są to prace wykonywane, by rozwiązać jakiś problem w momencie, gdy przedmiot dostawy już istnieje.
Niezadowolenie
klienta. Jeśli przedmiot dostawy jest słabej jakości, klient nie będzie zadowolony i może już nigdy więcej nic u Ciebie nie zamówić. Jeśli projekt ma charakter wewnętrzny, to klient może nie chcieć więcej zatrudniać kierownika projektu i jego zespołu do następnych projektów.
Help
Desk. Usługa zdalnej pomocy może pochłaniać duże koszty i sporą pracochłonność, gdy klient ma problemy z Twoim przedmiotem dostawy lub ma pytania dotyczące użytkowania go.
380 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Grupa wsparcia technicznego. Jej utrzymanie i praca także niesie za sobą spore koszty i znaczną pracochłonność. Wszystko to z tytułu konserwacji i wspierania przedmiotu dostawy z tytułu problemów, błędów, pytań itp.
Słabe morale. Nikt nie lubi pracować dla organizacji czy projektu, który ma słabe
procesy bądź produkuje wyroby słabej jakości. Koszty niskiego morale to: rosnąca nieobecność, większa rotacja załogi i niższa wydajność załogi.
381 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2.2 Zarządzanie jakością / Pytania kontroli jakości 9.2.2.P1 Kontrola jakości skupia się na ogólnej jakości produkowanego przedmiotu dostawy. Jest zazwyczaj obowiązkiem kierownika projektu i konkretnej osoby odpowiedzialnej za przedmiot dostawy. Poniższa lista zawiera pytania dotyczące kontroli jakości, które mogą być zastosowane do zarówno do przedmiotów dostawy głównego projektu jak i zarządzania nim.
Przedmiot dostawy Definicja projektu
Pytania kontroli jakości
Czy używana była standardowa formatka Definicji Projektu? Czy cele projektu są konkretne, realistyczne i znajdują się pod kontrolą grupy projektowej?
Czy przedmioty dostawy projektu są jasno zdefiniowane? Czy w sekcji zakres określono, co znajduje się w zakresie, a co poza nim?
Czy podejście realizacyjne projektu ma sens? Czy ogólne koszty, pracochłonność oraz czas trwania są jasno określony?
Czy organizacja projektu jest przejrzysta? Czy został określony sponsor projektu? Czy zostały określone wszystkie główne założenia i ryzyka? Czy istnieją plany zarządzania ryzykiem dla ryzyk wysokiego i średniego poziomu?
Czy
zostały wybrane odpowiednie osoby do zatwierdzenia projektu?
Czy
Definicja Projektu odpowiednich ludzi?
Harmonogram projektu
została
zaakceptowana
przez
Czy plan operacyjny wspiera podejście realizacyjne z Definicji projektu?
Czy w harmonogramie zawarte są plany zarządzania ryzykiem, plany komunikacyjne, plany kontroli i zapewnienia jakości?
382 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Czy została określona ścieżka krytyczna? Wymagania biznesowe
Czy
używana była standardowa formatka do zapisania wymagań biznesowych?
Czy wymagania biznesowe były określane z punktu widzenia użytkownika?
Czy
przedmiot dostawy spełnia kompletności i poprawności?
Czy
wymagania biznesowe odpowiednie osoby?
Plan testowania
były
wyznaczone zatwierdzone
kryteria przez
Czy
została zastosowana standardowa formatka do planu testowania?
Czy
zostały przeprowadzone testy, by upewnić się, że oprogramowanie działa tak, jak zostało zaprojektowane?
Czy
testy były przeprowadzane z dużą różnorodnością nieprawidłowych i nieoczekiwanych danych, by upewnić się, że oprogramowanie reaguje zgodnie z oczekiwaniami?
Czy
przedmiot dostawy przeszedł przez testy integracyjne, system testowania i test akceptacji użytkownika?
Czy przedmiot dostawy jest zgodny z kryteriami kompletności i poprawności?
Czy
klienci biznesowi zatwierdzili formalnie wyniki procesu testowania, podpisując, że przedmiot dostawy jest gotów do przejścia w fazę produkcji?
383 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2.3 Zarządzanie jakością / Pytania dotyczące zapewniania jakości 9.2.3.P1 Zapewnianie jakości polega na uwiarygodnieniu procesów użytych w tworzeniu przedmiotów dostawy. Jest to szczególnie pomocny proces dla kierowników i sponsorów. Kierownicy mogą nie mieć czasu czy biegłości potrzebnej do stwierdzenia, czy przedmioty dostawy są kompletne, poprawne i wysokiej jakości. Mogą oni w zamian przeglądać procesy używane w tworzeniu przedmiotu dostawy, by określić, czy wyglądają one wiarygodnie. Czy umiesz układać odpowiednie pytania dotyczące zapewnienia jakości? Spójrz na poniższe przykłady, czy takie pytania są właściwe?
Jak idzie? (nie) Czy zapowiada się, że skończysz na czas? (nie) Czy dzieje się coś niezwykłego? (nie) Czy wszystko jest na miejscu? (nie) Czy w takim razie wszystko idzie w porządku? (nie) Powiedz mi, czy masz jakieś problemy? (nie) Jeśli nie usłyszę od ciebie: „tak” - to zakładam, że wszystko jest w porządku. (nie) Muszę ci zaufać. Nie umiem ci powiedzieć, czy wszystko robisz prawidłowo. ( nie ) To nie są dobre pytania. Nie są one konkretne, a odpowiedzi, które otrzymasz, nie pomogą ci w określeniu ogólnego statusu projektu. Są to przykłady schematu „głupie pytanie - głupia odpowiedź”. Pytania odnoszące się do zapewnienia jakości muszą być o wiele bardziej szczegółowe i tak wycelowane, by określić bieżący status projektu. Dobre pytania odkryją stan procesów używanych do zarządzania projektem. W tym dziale napotkasz jeszcze na przykłady lepszych pytań. Jeśli chodzi o przyglądanie się bieżącym procesom, jedną z podstawowych rzeczy (poza przeglądem zapewniania jakości) jest odnalezienie tego, co idzie źle. Możesz zapytać, jak dokument był tworzony i zatwierdzany i możesz otrzymać ważną odpowiedź. Jednak osoba dokonująca kontroli musi także być w stanie określić, czy proces jest tak prawidłowy, jak być powinien. Pytania powinny być tak formułowane, by móc określić, które obszary działają źle oraz prowokować dyskusję, gdy coś idzie nie tak. Przegląd jakości powinien odkryć niedoskonałości procesu. Jednak należy pamiętać, że jest to obszar, gdzie wchodzi w grę indywidualna perspektywa. Audytor musi zrozumieć, że procesy używane w trakcie projektu mogą nie być idealne, lecz mogą być wystarczająco dobre. Żaden kierownik projektu (czy organizacja) nie może tracić czasu i siły na tworzenie procesu idealnego. Zawsze istnieje zagrożenie, że coś pójdzie nie tak z danym procesem. Jednakże powstały problem jest zazwyczaj niewystarczający, by wymóc poprawki w procesach. Jeśli konsekwencje są poważne to oczywiście będziesz możesz żądać nawet dodatkowych, redundantnych procesów. Jeśli 384 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
jednak konsekwencje nie są aż tak znaczące, wtedy proces spełniający zasadę 80/20 będzie wystarczający. Zapewnianie jakości powinno koncentrować się na ustanawianiu i przestrzeganiu dobrych procesów. Procesy te nie muszą być idealne. 9.2.3.P2 Audyt zapewniania jakości W wielu przypadkach sensowne jest zaproszenie zewnętrznego audytora w celu oceny procesów zarządzania projektem będących aktualnie w użyciu oraz upewnienia się, że realizowane są one zgodnie z oczekiwaniami. Kierownik projektu lub menadżer funkcyjny może zażądać audytu projektu jako części całego programu zarządzania jakością. Czasami mogą być zwoływane audyty stanowiące część kontraktu z klientem. W takim zewnętrznym audytorem może być dowolna wykwalifikowana osoba spoza kręgu kierownika projektu. W niektórych przypadkach Twoja organizacja może zaprosić do udziału specjalistę w dziedzinie audytów projektów. Możliwe, że dyrektor projektu lub jego sponsor również będą w nim uczestniczyli. Taki audytor może pochodzić spoza firmy. Może, ale nie musi. Osobą organizującą audyt może być menadżer funkcyjny, sponsor, specjalista do spraw audytu projektu, lub jakakolwiek osoba z wewnątrz lub z zewnątrz, która umie zadać odpowiednie pytania i potrafi zweryfikować, czy dana odpowiedź brzmi poprawnie, czy nie. Audyt skupia się na efektywnym procesie zarządzania projektem i sprawdza, czy projekt podąża odpowiednim torem. Audyt projektu ma na celu zapewnienie jakości poprzez zadawanie pytań na temat procesów użytych przy tworzeniu przedmiotów dostawy. Audyt może przebiegać według poniższych wskazówek:
1
2
Rola
Audyt zapewniania jakości
Audytor (przeprowadzający kontrolę )
Zawiadom członków.
Audytor
Przygotuj się na audyt.
Audytor zawiadamia kierownika projektu o zbliżającym się audycie i ustala dogodny czas i miejsce. Kluczowi interesariusze powinni być również powiadomieni.
Audytor może wymagać z wyprzedzeniem pewnych informacji. Może on także poprosić kierownika projektu, by był przygotowany na przedyskutowanie pewnych aspektów projektu. To pozwoli to na zagospodarowanie czasu spotkania w sposób efektywny. 3
Audytor, projektu
zespół
Wykonaj rozmowę przedwstępną. Podczas spotkania wstępnego audytor zadaje odpowiednie pytania, by upewnić się, że projekt jest na odpowiednich torach. Jeśli istnieją jakieś obszary, które nie idą tak jak trzeba, audytor je zanotuje.
385 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4
5
Audytor, projektu
zespół
Audytor
Wykonaj tyle rozmów, ile będzie potrzeba (opcjonalnie) W wielu projektach audyt może się skumulować w na jednym spotkaniu wstępnym. Jeśli projekt jest duży lub złożony, audytor może potrzebować wykonania uzupełniającej analizy. Będą to spotkania z innymi członkami zespołu oraz klientami, jak również przegląd dokumentacji. Udokumentuj swoje odkrycia. Audytor dokumentuje status i procesy użyte w projekcie w porównaniu do ja lepszych praktyk. Jeśli organizacja ma standardy i zasady zarządzania projektami, audytor sprawdza, czy wszystkie są przestrzegane w kontrolowanym projekcie. Audytor powinien także zarekomendować to co uważa, że może wpłynąć na bardziej efektywne i proaktywne zarządzanie projektem.
6
7
Audytor, kierownik projektu
Dokonaj przeglądu szkicu raportu z audytu.
Audytor
Raport ostateczny.
Audytor i kierownik projektu powinni spotkać się jeszcze raz, by przeanalizować wstępne wnioski. Audytor opisuje wszelkie niedoskonałości w zarządzaniu projektem i proponuje zmiany. Taki przegląd dostarcza również kierownikowi projektu okazji do odparcia pewnych zarzutów. W wielu przypadkach początkowe odkrycia audytora mogą być modyfikowane w oparciu o informację zwrotną od kierownika projektu.
Audytor sporządza ostateczny raport wszelkich wniosków i zaleceń. Kierownik projektu może również wystosować formalną odpowiedź na audyt. W takiej odpowiedzi może on zaakceptować niektóre punkty audytora i przedyskutować plany ich wdrożenia. Może on także wyrazić swój sprzeciw z niektórymi punktami kontroli oraz je uzasadnić. W takich przypadkach sponsor projektu i dyrektor projektu (menadżer kierownika projektu) będzie musiał zdecydować, czy kierownik projektu powinien zastosować się do zaleceń, czy nie.
9.2.3.P3 Pytania dotyczące zapewniania jakości Poniższe pytania mogą zostać użyte w dyskusji na temat zapewniania jakości, w zależności od fazy, w jakiej znajduje się projekt.
Kiedy?
Dyskusja na temat zapewniania jakości.
386 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Definicja projektu
Czy został zidentyfikowany sponsor i czy zatwierdził on formalnie projekt?
Czy
Definicja projektu została napisany i zatwierdzony przez odpowiednich kierowników i sponsorów?
Czy
kluczowi planowaniu?
interesariusze
uczestniczyli
w
Czy wymagania co do zasobów są adekwatne? Czy został stworzony prawidłowy harmonogram projektu?
Czy
zostały określone najważniejsze zadania do monitorowania zarządzania i zgłaszania jego postępów?
Czy
została sporządzona wycena dotycząca pracochłonności, kosztów i czasu trwania?
Jaki plan zarządzania projektem będzie używany w celach kontroli projektu?
Czy istnieją kryteria kompletności i poprawności do każdego głównego przedmiotu dostawy?
Pytania odnośnie zarządzania projektem, które powinny być zadane na końcu każdej ważniejszej fazy
Czy
kierownik projektu używa harmonogramu w zarządzaniu pracą zespołu?
Czy harmonogram dokładnie odzwierciedla pracę? Czy harmonogram dokładnie odzwierciedla szczegółowe czynności przewidziane na trzy kolejne miesiące (lub następny etap)?
Czy
kierownik projektu wyjaśnił, w jakim punkcie znajduje się teraz projekt - w porównaniu z tym, gdzie powinien być?
Czy wszystkie produkty wyszczególnione w Definicji projektu są dokończone?
Czy
używane są stałe procesy w zarządzaniu problemami, zakresem i ryzykami?
Czy Definicja projektu powinna być uaktualniona, by uwzględnić większe zmiany w projekcie?
Czy
kierownik projektu komunikuje się efektywnie poprzez spotkania i sprawozdania statusowe?
Czy
projekt znajduje się na właściwych torach w odniesieniu do kosztów, czasu trwania i jakości?
387 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Czy
klienci biznesowi są zadowoleni dotychczasowych postępów projektu?
z
Czy wymagania klienta są właściwie zarządzane? Na końcu po otrzymaniu wymagań biznesowych.
Czy
wymagania biznesowe udokumentowane i zatwierdzone odpowiednich klientów biznesowych?
zostały przez
Jakie inne produkty wytworzył projekt podczas tej fazy? Czy odpowiedni klienci biznesowi zatwierdzili je? Przykłady zawierają: projekt systemu pojęciowego strategię testowania strategię zmiany danych strategię treningu
Czy
projekt odpowiada standardom firmy, jej wytycznym i zasadom?
Na koniec projektowania, konstruowania testowania,
fazy oraz
Jakie
produkty wytwarza projekt podczas każdej fazy? Czy odpowiedni klienci biznesowi zatwierdzili je? Przykłady zwierają: projekt techniczny plan testowania plan treningu plan zmiany danych testowane rozwiązanie
jeśli
produkty nie są tworzone, przedyskutuj jak zostało dokonane testowanie, jak będzie wykonywany trening i jak będą zmieniane dane.
Czy projekt spełnia standardy, zasady i wytyczne firmy? Po tym jak rozwiązanie zostanie wprowadzone
Czy rozwiązanie zostało formalnie zatwierdzone i zaakceptowane przez sponsora projektu zanim trafiło do produkcji?
Czy
zespół produkcję?
projektu
początkowo
wspierał
Czy
początkowe problemy są rozwiązywane w szybki sposób?
Czy rozwiązanie prawidłowo przechodzi do grupy wspierającej?
388 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.2.4 Zarządzanie jakością / Statystyczna kontrola procesu (SPC) 9.2.4.P1 Techniki statystycznej kontroli procesu dostarczają opartego na danych, obiektywnego sposobu na określenie, czy projekt wytwarza przedmioty dostawy wewnątrz zaakceptowanych poziomów jakości. Techniki te polegają na testowaniu lub inspekcjach jakości przeprowadzanych na wytwarzanych przedmiotach dostawy. Jeśli Twój projekt wytwarza małą liczbę wysoce zróżnicowanych przedmiotów dostawy, techniki te mogą nie zadziałać. Jednak, jeśli Twój projekt produkuje wiele podobnych przedmiotów dostawy, techniki te mogą być dobrym sposobem, by określić, czy Twoje procesy są wystarczająco dobre do wytwarzania przedmiotów dostawy wysokiej jakości. Techniki statystycznej kontroli procesu pomagają również określić, czy Twoje procesy są pod kontrolą i czy produkcja odbywa się na odpowiednim poziomie. Kiedy proces zaczyna się chwiać i wytwarzać przedmioty dostawy nie odpowiadające standardom, procesy są określane jako: „poza kontrolą”. Techniki SPC powiedzą Ci bardzo szybko, kiedy Twoje procesy zaczynają wymykać się spod kontroli. Filozofia SPC polega na tym, że proces produkcji może być kontrolowany statystycznie poprzez metody inżynierii procesowej i odpowiednie zarządzanie. To podejście pomaga zespołowi projektowemu i organizacji w: odnalezieniu obszaru problemu krytycznego we wczesnej fazie procesu zredukowaniu zmienności przedmiotu dostawy określeniu zdolności procesu zoptymalizowaniu procesu określeniu niezawodności przedmiotu dostawy Pomimo że technika statystycznej kontroli procesu wydaje się prosta i bezpośrednia, to jej narzędzia mogą być skomplikowane. Wymaga ona konsekwentnego sposobu testowania przedmiotów dostawy, sposobu oceny wyników testów i sposobu ich interpretacji, by móc zrozumieć, co się dzieje. 9.2.4.P2 Wykresy kontrolne [ wykreślono z edycji polskiej ]
389 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
9.3 Zarządzanie jakością / Podsumowanie 9.3.P1 Produkty Poniższe wzorce dokumentów, wspierające opisywane w tym rozdziale procesy, dostępne są w bibliotekach formularzy TenStep (niektóre z formularzy mogą być dostępne tylko dla licencjonowanych użytkowników)
Plan jakości. Przegląd przedmiotów dostawy Kryteria kompletności i poprawności. Ocena projektu 1. Ocena projektu 2. Podsumowanie oceny projektu. Lista kontrolna zapewniania jakości. Lista kontrolna kontroli jakości. 9.3.P2 Harmonogram
Wielkość
Potrzebne informacje
projektu mały
Nie są wymagane żadne czynności
średni
Czynność
Pracochłonność
Uwagi
Ustal Plan jakości.
Nieokreślona
Wykonuje się to podczas definiowania projektu, jako część Planu zarządzania projektem.
Wykonaj czynności kontroli jakości.
Nieokreślona
Każdą z czynności kontroli jakości przenieś do planu operacyjnego.
Wykonaj czynności zapewnienia jakości.
Nieokreślona
Czynności zapewnienia umieść w
390 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
jakości planie
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
operacyjnym. duży
Czynności
Pracochłonność
Uwagi
Zacznij od tych samych czynności, co przy projekcie średnim i dodaj czynności bardziej wyrafinowane, by zbierać i analizować metryki. Zbierz pomiary.
Nieokreślona
Zbieraj pomiary co miesiąc, by wskazać jakość głównych przedmiotów dostawy i wewnętrznych procesów pracy.
Analizuj pomiary, by poprawić procesy.
1-2 godzin
Przeznacz trochę czasu na comiesięczną analizę zebranych miar, by zobaczyć czy procesy powinny zostać ulepszone. Kiedy procesy są zmieniane nadal, zbieraj miary, by wprowadzać więcej ulepszeń.
391 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Step 10 Zarządzanie pomiarami
392 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.0 Zarządzanie pomiarami 10.0.P1 Zbieranie pomiarów dla celów projektu jest najbardziej zaawansowanym procesem TenStep może być również procesem najtrudniejszym. Ponieważ trudno się dokonuje pomiarów, często aspekt ten jest pomijany. Wszystkie projekty powinny gromadzić i mierzyć podstawowe dane i informacje dotyczące kosztów, pracochłonności i czasu trwania. Krok 10.0 skupia się na dokonywaniu pomiarów umożliwiających sprawdzenie stopnia zadowolenia klienta z otrzymywanych przedmiotów dostawy. Po drugie, proces 10.0 umożliwia jak sprawdzanie na ile sprawnie działają procesy wewnętrzne w projekcie. W zależności od rezultatów mogą być podjęte działania korygujące lub udoskonalające te procesy, które wpłyną na poprawę ich skuteczności i efektwyności. Zarządzanie pomiarami i zarządzanie jakością są ze sobą związane. Bardzo trudno będzie podnosić jakość przedmiotów dostawy albo procesów, jeśli nie zgromadzisz pomiarów. Pomiary są wykorzystywane, aby pokazać początkowy poziomu jakości oraz umożliwić zbadanie czy jakość się podnosi, czy obniża. Zarządzanie pomiarami może być używane efektywnie w średnich i dużych projektach, ponieważ przy ich realizacji jest wystarczająco dużo czasu, by wykonywać pomiary, analizować ich wyniki i przeprowadzać odpowiednie zmiany. Zbieranie zaawansowanych pomiarów w mniejszych projektach nie ma z reguły sensu, chyba, że jest ono narzucone przez twoją organizację. Zespoły projektowe powinny wiedzieć, jak będą wykorzystywane wyniki pomiarów, kiedy zostaną już wykonane. Jeśli nie masz zamiaru wykorzystywać pomiarów dla poprawy zarządzania, być może nie masz potrzeby zbierania jakichkolwiek informacji, niż te dotyczące: kosztu, pracochłonności i czasu trwania (chyba, że jeszcze jakieś wielkości musisz mierzyć, gdyż takie są wymagania firmy). Pomiary projektu są ważne, ale najwyższa wartość w ich zbieraniu jest uzyskiwana, jeśli są one używane dla usprawnienia funkcjonowania firmy. Zebranie pomiarów ze wszystkich projektów może być wykorzystane do wdrażania w firmie procesów usprawniających. Ostatecznie informacje mogą być wykorzystane dla stworzenia zestawu najlepszych praktyk i standardów, które będą stosowane we wszystkich projektach. 10.1 Zarządzanie pomiarami / Proces 10.2 Zarządzanie pomiarami / Techniki 10.3 Zarządzanie pomiarami / Podsumowanie
393 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.1 Zarządzanie pomiarami / Proces 10.1.P1 Małe projekty W małych projektach kierownik projektu powinien zajmować się jedynie zbieraniem pomiarów, które są wymagane we wszystkich projektach, w całej organizacji, (jeśli takowe są). Składają się one zazwyczaj z podstawowych informacji- jaki jest postęp prac w relacji do ustalonego planu i budżetu. Na końcu projektu te liczby mogą być porównane z pierwotnymi oszacowaniami. Można dzięki temu wykazać, jak sprawnie projekt został zrealizowany. Na końcu projektu może zostać zbadana satysfakcja klienta. Wszystkie inne pomiary, które są wymagane (jeśli są) powinny być również wykonane i zaraportowane. Z reguły nie ma potrzeby zbierania bardziej zaawansowanych pomiarów związanych z wytwarzaniem przedmiotów dostawy lub działaniem wewnętrznych procesów, ponieważ nie ma zbyt dużo czasu na wprowadzanie ulepszeń czy podejmowanie działań opartych na rezultatach pomiarów. 10.1.P2 Średnie projekty W średnich projektów kierownik projektu powinien zebrać wszystkie dane, które są potrzebne całej organizacji – podobnie jak przy małych projektach. W zależności od organizacji może się zdarzyć, że będzie potrzebnych więcej informacji dla tej skali projektów. Kierownik, jeśli chce zdefiniować proces wykonywania pomiarów, powinien posłużyć się opisem procesu dla dużego projektu. Szczególnie w sytuacji, gdy średni projekt rozmiarami zbliża się do dużego projektu, zbieranie pomiarów jest coraz bardziej przydatne. Mogą one nie być tak zaawansowane, jak pomiary w większych projektach, ale mogą wnieść dodatkowe, wartościowe informacje. 10.1.P3 Duże projekty – rozpoczęcie projektu Duże projekty definitywnie powinny zbierać pomiary, które dają wiedzę o jakości przedmiotów dostawy i procesów wykorzystywanych do ich produkcji. Powyższy proces może być wykorzystany dla zdobycia właściwych pomiarów dla celów projektów. Ten proces będzie skutkował utworzeniem Karty Wyników Projektu.
1.
ROLA
Zarządzanie Pomiarami (duże projekty)
Kierownik Projektu
Ustal kryteria osiągnięcia sukcesu (Critical Succes Factor) Dokonaj przeglądu celów i przedmiotów dostawy w Definicji Projektu, podobnie jak wszystkich dokumentów ważnych dla realizacji projektu. W oparciu o tę dokumentację zdefiniuj informacje potrzebne, aby pokazać, że projekt okazał się sukcesem - będziemy je nazywać Kryteriami Osiągnięcia Sukcesu. Należy to zrobić z dwóch perspektyw: Wewnętrzna. Te charakterystyki, które wskazują, że projekt był zarządzany i wykonany efektywnie i skutecznie. Pomiary wykonywane w tej perspektywie mają pokazać, że przedmioty dostawy były zatwierdzane nie więcej w dwóch iteracjach, kamienie milowe były osiągane
394 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
z poślizgiem nie większym niż…, a średnia ilość błędów nie przekraczała liczby Y. Zewnętrzna. Te charakterystyki wskazują, że cele i przedmioty dostawy projektu zostały pomyślnie ukończone. Przykładami pomiarów tej perspektywy są: zakończenie projektu (nie wykraczające poza zatwierdzony budżet i ramy czasowe) zapewnienie (gwarancja), że wszystkie przedmioty dostawy są zgodne z zatwierdzonymi kryteriami jakości dostosowywanie przedmiotów dostawy tak, że są zgodne z oczekiwaniami klienta Jeśli twoja organizacja realizuje założenia modelu CMMI, powinienesś bezwzględnie jako kryterium osiągnięcia sukcesu projektu potraktowć i zmierzyć wartość biznesową jaką projekt dostarcza (lub nie) do organizacji. 2
Kierownik Projektu
Wyznacz potencjalne mierniki. Zidentyfikuj listę mierników dla każdego kryterium sukcesu. Mierniki powinny być tak skonstrułowane, aby nie tylko po zakończeniu prac, ale w trakcie projektu można było badać, czy projekt jest na drodze do sukcesu, czy gdzieś właśnie zboczył. Możesz zdefinować pomiary bezpośrednie albo pośrednie, Dla każdego miernika, krótko określ, jak będziesz zbierał dane, jaką pracochłonność oraz budżet należy na to przeznaczyć oraz jakie wartości wniesie określony miernik.
3
Kierownik Projektu
Zrównoważ mierniki. Lista potencjalnych mierników powinna być skatalogowana według kategorii dla uzyskania pewności, że dają one zbalansowany pogląd na projekt. Na przykład nie chcesz zakończyć jedynie z zestawem mierniików finansowych, chociaż mogą one być najłatwiejsze w uzyskaniu. Generalnie zdefiniuj pomiary, które dostarczą informacji w następujących obszarach:
koszt pracochłonność czas trwania produktywność jakość przedmiotów dostaw satysfakcja klientów z produktów praca zespołu wartość biznesowa
Zestaw przykładowych mierników w rozdziale 10.1.1 Przykłady
395 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
4
Kierownik Projektu
Ustal priorytety dla zbalansowanej listy mierników. W zależności od tego, ile mierników zidentyfikowałeś, ustal priorytety, aby włączyć tylko te, które wiążą się z poniesieniem najmniejszych kosztów i uzyskaniem największych korzyści. Oczywiście może być tyle zbieranych mierników, ile jest potrzebnych do projektu, ale nie powinno być więcej niż jedna lub dwie na kategorię. Wybierz te mierniki, które dają jak najwięcej informacji jak najmniejszym nakładem pracy. Po ustaleniu priorytetów i listy mierników, sprawdź ponownie, aby się upewnić, że pomiary są zbalansowane.
5
Kierownik Projektu
Ustal wartości pożądane Same pomiary mogą być przydatne, ale miarą sukcesu jest porównywanie tego, co masz, z tym co ustaliłeś jako wartość pożądaną. Wartość ta pozwala rozpoznać po wykonaniu pomiarów czy ich wyniki są dobre czy też złe i czy zmierzają w dobrym kierunku. Wartość pożądana może być konkretną liczbą, którą chcesz osiągnąć, lub też pewnym zakresem. Na przykład musisz ukończyć projekt w określonym dniu, ale Twój aktualny koszt może być 10 % wyższy lub niższy niż określony w budżecie.
6
Kierownik Projektu
Dodaj do harmonogramu odpowiednie zadania Dla każdego miernika, który zdefiniowałeś, określ konkretne działania konieczne dla zebrania i przeanalizowania danych. Te działania ujmij następnie w harmonogramie projektu. Informacje te to:
Jakie
konkretnie dane są potrzebne dla danego miernika?
Kto jest odpowiedzialny za zbieranie pomiarów? Kiedy informacje zostaną zebrane? Jak będą przedstawiane wyniki ( raporty, spotkania, raporty)
10.1.P4Duże projekty - realizacja projektu
7
Kierownik Projektu
Zbieraj dane, ulepszaj procesy Pomiary będą zbierane w oparciu o procesy w trakcie projektu. Pomiary powinny być analizowane i konfrontowane z wartościami pożądanymi. Zmiany w procesie powinny być przeprowadzane w oparciu o wyniki pomiarów. Przeprowadzaj analizę trendów. Na przykład możesz przekroczyć budżet w związku z realizacją jekiegoś zadania, jakkolwiek po jakimś czasie może się okazać, ze mieścisz się w budżecie w końcowym etapie
396 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
projektu. W takim przypadku nie są potrzebne żadne zabiegi korekcyjne. Możesz wyznaczyć pożądaną wartość dla satysfakcji klienta - 4 w pięciostopniowej skali. Twoja aktualna ocena może oscylować wokół 4.1. Jeśli poprzednie oceny oscylowały wokół 4.5, 4.3 i 4.2, trend zmierza w niewłaściwym kierunku i możesz mieć potrzebę dokonania zmian – nawet, jeśli aktualnie uzyskujesz więcej niż zaplanowałeś. 8
Kierownik Projektu
Analizuj Kartę realizacji.
Wyników
Projektu
podczas
jego
Oceniaj wyniki pomiarów w cyklach miesięcznych, aby się upewnić, że wciąż odzwierciedlają stan projektu a na ich podstwie pracownicy zachowują się w pożądany sposób. Jeśli nie, dokonaj właściwych zmian. 9
Kierownik Projektu
Analizuj końcowe rezultaty i wnioskuj o uznanie projektu za zakończony sukcesem Kiedy realizacja projektu została zakończona, zespół powinien stworzyć kartę wyników, która będzie odzwierciedlała końcowe rezultaty projektu. Zespół może przeanalizować końcowe pomiary i zarekomendować Sponsorowi czy należy uznać go za zakończony sukcesem, czy też porażką. Sponsor Projektu może zweryfikować wyniki i zdecydować, czy zaakceptować rekomendację albo wydać inną końcową ocenę sposobu realizacji projektu.
10
Kierownik Projektu
Prześlij końcowe wyniki do Biura Zarządzania Projektem (lub do innego ciała odpowiedzialnego za rozwój procesów w firmie) Wymagania biznesowe stają się coraz cięższe. Firmy stają w obliczu konkurencji. Poziom realizacji projektu, który był odpowiedni w tym roku, nie spełni oczekiwań w przyszłym roku. PMO i cały personel zarządzający ma obowiązek dbania o ciągłe podnoszenie poziomu realizacji projektu, a także poziomu usług. Zespół projektowy powinien zdać relacje z realizacji projektu PMO, co pozwoli na wykorzystanie sukcesu projektu w całej organizacji. PMO powinno użyć tych informacji jako wartościowego wkładu w ulepszanie procesów biznesowych w całej organizacji. (Jeśli Twoja organizacja nie posiada PMO, powinieneś wysłać informacje do jakiejkolwiek komórki organizacyjnej, która jest odpowiedzialna za ulepszenie procesów. Twoja organizacja powinna mieć program wdrażania pomysłów służących usprawnieniu procesów. Program powinien zawierać wskazówki dotyczące roli, jaką odgrywa ulepszenie procesów, mechanizm zbierania
397 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
pomysłów, aby mieć pewność, że każdy pomysł został przedyskutowany. Osoby, które przedstawiają swoje sugestie powinny otrzymać wynagrodzenie, niezależnie od tego, czy ich sugestie zostały wprowadzone w życie. Jeżeli sugestia nie zostanie uwzględniona, osoba ta powinna otrzymać informację, dlaczego jej idea nie została wprowadzona w życie.
398 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.1.1 Zarządzanie Pomiarami / przykładowe mierniki 10.1.1.P1 Poniższa lista przedstawia idee różnych rodzajów mierników, które powinny zostać zrelacjonowane. Lista ta nie jest w żadnej mierze wyczerpująca, ale może być pomocna w projekcie. Kategoria biznesowa
Miernik
Koszt
Rzeczywisty koszt / planowany budżet
projektu, określonej
fazy, etapu, etc.
Całkowite
koszty wspierania zakończeniu projektu
Całkowite
przez
x
miesięcy
po
koszty pracy oraz inne koszty (rozbieżność z
budżetem)
Koszty związane z ponownym użyciem komponenetów Całkowity koszt transakcji Wdrożone pomysły na obniżenie kosztów / obniżki kosztów wdrożone w życie
Pracochłonność
Rzeczywista pracochłonność / planowana (rozbieżność) Pracochłonność zarządzania projektem / pracochłonność projektu
Czas trwania
Rzeczywisty czas trwania / planowany (rozbieżność)
Produkcyjność
pracochłoność zadanie / punkt funkcyjny jednostki pracy/ punkty funkcyjne na godzinę godziny pracy zredukowane w stosunku do standardowego procesu
godziny
pracy zredukowane z powodu ponownego użycia poprzednich produktów, modeli, komponentów, etc.
Liczba wprowadzonych w życie pomysłów w celu ulepszenia procesów
Liczba
godzin/dolarów wprowadzenia ulepszeń.
zaoszczędzonych
399 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
w
wyniku
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Jakość przedmiotów dostawy
procent
przedmiotów dostawy, które przechodzą kontrolę
jakości
procent przedmiotów dostawy, które
zyskały akceptację za
pierwszym razem
ilość defektów wykrytych po wstępnej akceptacji procent przedmiotów dostawy, które w 100 % są zgodne ze standardami organizacji
procent
przedmiotów dostawy, które są standardami architektonicznymi organizacji
zgodne
ze
ilość zmian żądań klientów (duża ilość i zakres zmian może implikować mierne wymagania procesu gromadzenia)
ilość godzin przeróbek w przedmiotach dostawy ilość najlepszych praktyk rozpoznanych i zaaplikowanych w trakcie realizacji projektu
ryzyko, które zostało złagodzone Satysfakcja Klienta z przedmiotu dostawy
Satysfakcja
Klienta przedmiotu dostawy)
z
przedmiotu
dostawy
(przegląd
niezawodność defekty użyteczność czas rekacji łatwość użycia dostępność elastyczność intuicyjność bezpieczeństwo wychodzenie naprzeciw oczekiwaniom klientów łatwość rozumienia wiadomości użycie dokumentacji czas odpowiedzi aplikacji (skalkulowany przez system) Ilość zaaprobowanych biznesowych wymagań spełnionych w realizacji projektu
400 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Satysfakcja Klienta z pracy z zespołem projektowym
Satysfakcja klienta z zespołu projektowgo (przegląd) odpowiedzialność kompetencja dostępność nienaganne maniery komunikacja wiarygodność znajomość biznesu niezawodność / w trakcie realizacji profesjonalizm szkolenie całkowita satysfakcja klienta czas potrzebny, aby odpowiedzieć na pytania i problemy klienta
średni czas potrzebny do rozwiązania zagadnień
401 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.2 Zarządzanie Pomiarami / Techniki 10.2.P1 Upewnij się, że Twoje mierniki i pomiary dodają wartości Zbieranie, analiza i użycie wyników pomiarów powinny wnieść wartość do projektu. Wartość ta może zostać ujęta ilościowo w następujących obszarach:
poprawa produktywności w wykonaniu projektu i w procesie budowy przedmiotów dostawy
poprawione i sprawdzone estymacje dla przyszłych projektów potwierdzenie ważności czasu trwania, kosztu, pracochłoności
i jakości zadań w
realizacji projektu
identyfikacja i komunikacja najlepszych praktyk poprawa satysfakcji klienta Generalnie pomiary dostarczają bardziej rzeczowych i ilościowych podstaw dla zrozumienia, jak sobie radzisz i które rzeczy mogą być zrobione lepiej. Bez co najmniej jakichś podstawowych pomiarów, wszystkie dyskusje na temat działania oraz udoskonalania są oparte na opiniach i domysłach. Jeżeli chcesz, aby Twój sukces albo niepowodzenie w realizacji projektu oparty był na prawdziwych danych, musisz ustalić kryteria sukcesu z pewnym wyprzedzeniem, musisz także określić, jak oceniać te kryteria. Następnie należy zebrać pomiary, nawet jeśli są one niedoskonałe i nieprecyzyjne. Mimo wszystko wciąż dostarczą one lepszych informacji, niż sposób polegający na postrzeganiu, przypominaniu sobie i domysłach. 10.2.P2 Używaj zebranych przez siebie pomiarów Nie potrzebujesz wykonywać pomiarów jedynie dla samej sztuki. To nie ma sensu z punktu widzenia realizacji projektu i perspektyw zarządzania nim, wydaje się być stratą czasu. Jeśli pewne pomiary są wymagane przez Twoją organizację zbierz je. Dodatkowo powinieneś dokonać pomiarów, które są potrzebne dla realizacji danego projektu. Jeżeli nie masz celu przeznaczenia tych pomiarów albo jeżeli Twój projekt nie jest wystarczająco długi, aby móc coś korygować, to pomiary te nie są warte przeprowadzenia w Twoim projekcie. 10.2.P3 Porównaj koszt zbierania pomiarów i zysk wynikający z ich wykonania Ponieważ istnieją koszty związane z większością działań związanych z zarządzaniem projektu, istnieje również koszt dokonania i przetwarzania pomiarów. W przypadku zarządzania zakresem albo zarządzania problemami krytycznymi, jest to koszt zarządzania projektem. Pracochłonność związana z zarządzaniem pomiarami, jest zależny od kultury pracy całej organizacji. W wielu przypadkach, koszt zebrania i wykorzystania pewnego typu pomiarów jest wogóle niepożądany. Pomiary te nie powinny być gromadzone. Inne pomiary są interesujące, lecz nie dostarczają informacji, które mogą być wykorzystane w doskonaleniu. Sednem sprawy jest to, że koszt wykonania każdego pomiaru powinien być rozważony w kontekście potencjalnego zysku, jaki jest możliwy do osiągnięcia. Zacznij od zbierania pomiarów, które są wymagane 402 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
przez organizację. Następnie zgromadź pomiary, których koszt pracochłonność są najniższe w relacji najwyższego potencjalnego zysku.
zebrania
i
10.2.P4 Łącz wydajność jednostki i zespołu Ta stara reguła: „Co zostanie zmierzone - zostanie zrobione” sprawdza się w trakcie realizacji projektu. Jeśli komunikacja jest ważna dla Twojego projektu, zbuduj pomiary wokół komunikacji. Na przykład możesz dokonywać pomiarów klientów i interesariuszy, aby dowiedzieć się, jakie jest ich zdanie na temat efektywności działania komunikacji. Jeśli zachęcasz Twój zespół do ponownego użycia istniejących komponentów, znajdź przykłady ponownego użycia; oszczędności czasu i kosztów. Jakkolwiek możesz wciąż nie uzyskać zachowań, których pożądasz, jeżeli rezultaty pomiarów nie mają bezpośredniego wpływu na członków zespołu. Podstawą jest zebranie pomiarów, które dają ilościowo wskaźnik całej grupy i pojedynczego członka zespołu. Przykładem, jest projekt uzuany za porażkę, gdzie wszyscy członkowie zostają wysoko ocenieni w trakcie oceny pracy. Upewnij się, że sukces grupy znajduje właściwe odzwierciedlenie w ocenie indywidualnego działania. Jeśli projekt okazał się sukcesem, członkowie grupy powinni zostać wynagrodzeni. Jeśli projekt okazał się porażką, ocena członków zespołu powinna być również odpowiednia. 10.2.P5 Uważaj na niepożądane konsekwencje pomiarów Zbieranie pomiarów spowoduje określone zachowania. Zatem istnieje założenie, że zbieranie pomiarów spowoduje właściwe zachowania i wykluczy niepożądane. Przeanalizuj poniższy przykład: Zespól projektowy był oceniany na podstawie czasu trwania rozwiązywania problemów, które się pojawiły we wstępnych testach. Członkowie zespołu zdali sobie sprawę, że muszą rozwiązać kłopoty natychmiast, ponieważ będą źle ocenieni. Członkowie zespołu zdali sobie sprawę, że jeśli nie będą potrafili określić przyczyny odpowiednio szybko, powinni po prostu zgadnąć i rozwiązać zgłoszony problem jakkolwiek. Jeśli ich pomysł nie rozwiązał problemu, pojawił się nowy problem i zostawał ponownie szybko rozwiązywany. Rezultatem było powtarzanie się błędów i strata większej ilości czasu, niż jest wymagana. W przykładzie jednym z problemów były pomiary. Ten zespół wyglądał dobrze na papierze, dopóki problemy były rozwiązywane szybko. Jednak w rzeczywistości zespół funkcjonował słabo, generując dodatkową pracę i będąc źródłem braku satysfakcji klienta. Kiedy rozważasz miernik dla Twojego projektu, pomyśl o tym, jakie uboczne konsekwencje mogą powstać w trakcie dokonywania pomiarów. Bądź pewien, że rozpocząłeś proces w sposób, który kreuje właściwe i pożądane zachowania. 10.2.P6 Ustal wartość bazową, jeśli nie znasz wartości pożądanej pomiaru Zbiór pomiarów sam w sobie ma ograniczoną wartość. Największa wartość pojawia się w sytuacji porównaniapomiarów z jakimś standardem albo celem. Dla wielu pomiarów istnieje jakaś wartośc pożądana, nawet jeśli nie zawsze określisz go w sposób szczegółowy. Na przykład - rzeczywista pracochłonność, czas trwania i koszt wykorzystywane są dla porównań tych wielkości z planowanymi. 403 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Dla wielu jednak mierników nie ma nawet domniemanego stanu pożądanego. Na przykład, jeśli badasz satysfakcję klienta, mogą cię ocenić na 3,8 w pięciostopniowej skali, to dobra, czy też zła ocena? Jeśli nie masz materiału porównawczego, jest to trudne do stwierdzenia. Sposobem zebrania większej wartości z pomiarów jest przeprowadzenie oceny na samym początku, aby uzyskać informację, na jakim etapie znajdujesz się obecnie. W przykładowym przeglądzie możesz rozważyć pierwsze wyniki, jako bazę porównawczą, a następnie starać się polepszać wyniki. Na przykład po uzyskaniu wyniku na poziomie 3,8 na 5.0 możliwych punktów, możesz wybrać cel aby osiągnąć 4.2 na 5.0, przed zakończeniem projektu. Inną opcją jest dążenie do 10 % poprawy w stosunku do bazowego wyniku, kiedy początkowe metryki zostały zgromadzone. 10.2.P7 Bądź kreatywny w poszukiwaniu sposobów oceny wartości biznesowej Jedną ze świętych zasad dotyczących pomiarów, jest właściwe uchwycenie wartości biznesowej. W niektórych przypadkach wartość jest oczywista. Sprzedaż powinna wzrastać. Zapasy magazynowe powinny się zmniejszać. Mniej ludzi może być zaangażowanych w proces. Jednak w wielu projektach może okazać się trudne lub wręcz niemożliwe, aby dokładnie określić to ilościowo. Obejmuje to następujące sytuacje:
Projekt
przynosi niemierzalne korzyści, takie jak wzrost zadowolenia klienta albo jakości produktu.
Projekt
wymaga infrastruktury, która jest używana przez wielkie grupy ludzi. Na przykład jak dalece wzrośnie wydajność pracowników, jeśli zwiększymy dwukrotnie pamięć ich komputerów? Jaka jest policzalna wartość nowej wewnętrznej linii telefonicznej?
Projekt skutkuje zwiększoną ilością informacji, do której dostęp mają ludzie. Trudno jest określić dokładnie, jaki wpływ mają te informacje na podejmowane decyzje
Postęp jest możliwy dzięki wielu projektom w jakimś okresie czasu, ale trudno jest określić, jaką wartość przynosi realizacja każdego projektu.
Rezultatami są udoskonalenia na niskim poziomie operacyjnym, które nie skutkująw
speklakularny i wyraźny sposób, na przykład: eliminowanie poszczególnych etapów w procesie - proces zajmuje mniej czasu, ale czas jest wykorzystywany do innej działalności
Najlepszym sposobem zdefiniowania biznesowej wartości projektu jest analiza dokumentacji, którą wypełniono zgłaszając pomysł biznesowy, na podstawie którego realizowany jest projekt. Spójrz, jak zyski zostały tam określone, aby się przekonać, czy rzeczywiście uzyskałeś zbliżone wartości na zakończeniu realizacji projektu. Jeśli pojawiły się spore zyski, pomiar winien ukazać, jak wiele wartości zostało dodanych. Jeśli zyski były skromne, będziesz musiał prawdopodobnie przeprowadzić przegląd za pomocą dowodzenia nie wprost, jak wartość została dostarczona. 10.2.P8 Zbiraj opinie klienta oraz jego ankiety
404 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Zbieranie pomiarów jest bardzo użyteczne i pozwala Ci stwierdzić, jak wyglądają Twoje działania w relacji do oczekiwań Twoich klientów. W świecie doskonałym wszystkie pomiary byłyby wiarygodne i pokazujące stan rzeczywisty. Jednak w wielu przypadkach zebranie odpowiedniej liczby pomiarów będzie niepraktyczne lub zbyt kosztowne. Jedynym sposobem uzupełnienia danych jest analiza danych dotyczących zadowolenia klientów. Więcej informacji znajdziesz w dziale: 10.2.1. 10.2.P9 Zbieranie Pomiarów i danych demograficznych projektu może pomóc w realizacji przyszłych projektów Zbieranie i relacjonowanie zgodnego zestawu pomiarów w etapie końcowym realizacji projektu może pomóc Twojej organizacji w ustaleniu trendów projektów w jakiejś perspektywie czasowej. Pomiary powinny wskazać, w jaki sposób członkowie projektu spełniają stawiane im żądania w relacji do pożądanej jakości, kosztów i czasu trwania. W sytuacji, gdy coraz większa ilość projektów zbiera pomiary, podstawa powinna być ustalona na takim poziomie, który pozwoli Twojej organizacji zorientować się, jak wyglądają procesy udoskonalania Jeśli gromadzisz pomiary dla całej organizacji, powinieneś zebrać dodatkowe informacje demograficzne. Dane demograficzne dotyczące projektu są to charakterystyki, które dostarczają opisu każdego poszczególnego projektu. Jeśli zbierzesz pomiary i dane demograficzne w pliku lub bazie danych, mogą one zostać przeanalizowane dla wykazania trendów w bardziej dyskretnej formie. 10.2.P10 Upewnij się, że Twoje pomiary dają pogląd na całą kwestię Problem z pomiarami polega na tym, ze są one relacjonowane w sposób, który nie pokazuje całego zagadnienia. Kierownik projektu i zespół mogą wiedzieć, co im dają wykonane pomiary, ale postronni obserwatorzy już nie. Sposobem, który może pomóc, jest raportowanie wyników pomiarów wraz z ich opisem. Na przykład jeśli relacjonujesz swoje obecne wydatki, włącz w to również planowane wydatki w danej fazie projektu. Jeśli relacjonujesz, że dla celów projektu wydano do tej pory 100.000 $, a Twój całkowity budżet wynosi 150.000 $, czytelnik wciąż nie zna kontekstu. Nie może stwierdzić, czy to dobra czy zła sytuacja. Wie, że mieścisz się w budżecie, ale zdaje sobie sprawę, że praca się jeszcze nie skończyła. Lepszym sposobem zrelacjonowania tych informacji jest poinformowanie, że wydałeś do obecnej chwili 100.000 $, a według planu miałeś wydać 110.000 $ w danej fazie projektu. Jeśli trend się utrzymuje, określasz, że finalny koszt projektu wyniesie 135.000 $ w ramach 150.000 $ budżetu. Jeśli relacjonujesz pomiary w tym kontekście Twoi czytelnicy zrozumieją, co dane liczby mówią. 10.2.P11 Informuj i zachęcaj zespół do korzystania z pomiarów Jeśli wpajasz zespołowi konieczność polepszania jakości projektu, członkowie zespołu zwykle rozumieją, o czym mówisz. Jakość to termin, którego konotacja jest znana każdemu. Generalna definicja „pomiarów”, “mierników” etc., nie jest taka jasna. Menedżer może stworzyć program pomiarów dla dużego projektu, podczas gdy członkowie zespołu nie znają zależności pomiędzy wykonywaniem pomiarów i uzyskaną wartością biznesową. To może również dotyczyć klienta. Oni nie muszą intuicyjnie wyczuwać potrzeby używania pomiarów dla określenia, czy przedmioty dostawy spełniają stawiane im wymagania. Mogą również nie widzieć związku pomiędzy zbieraniem pomiarów i zdolnością udoskonalania procesu.
405 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Kierownik projektu powinien wytłumaczyć, dlaczego pomiary są potrzebne i jak zebrane informacje pomogą wdrożyć udoskonalenia. Zespół powinien rozumieć, jak szukać pomiarów, które dostarczą wskaźnika, co do stanu procesu lub przedmiotu dostawy. Edukacja zespołu oraz klienta pomoże uzyskać lepsze pomiary z mniejszym nakładem pracy. Jeśli Twoja organizacja jest ogólnie nastawiona na podnoszenie jakości, ta edukacja powinna być przeprowadzona dla całego personelu. 10.2.P12 Używaj CSF i KPI do informowania klientów o pomiarach Terminy: Critical Success Factor (CSF) i Key Perfomance Indicator (KPI) są wykorzystywane do wskazania celów. Wiele organizacji używa tych dwóch terminów mówiąc o jednej rzeczy, ale jest mała różnica. Zazwyczaj KPI ogniskują się na procesie. Na przykład, jeden z Twoich KPIs może spowodować redukcję czasu, który jest potrzebny do wysłania towaru do klienta. To jest pomiar związany z sukcesem procesu, dlatego jest to pomiar zapewniający jakość. CSF z drugiej strony mają zazwyczaj do czynienia z charakterystyką przedmiotu dostawy. Na przykład możesz mieć CSF związane z obniżeniem liczby wad w jednym z Twoich projektów. To jest pomiar dotyczący kontroli jakości. 10.2.P13 Postrzegaj przedmioty dostawy jako dowody sukcesu Kiedy definiujesz projekt, ustalasz zestaw celów. Jeśli Twój projekt uzyska te cele, powinieneś uznać go za udany. Jeśli zdefiniowałeś zestaw przedmiotów dostawy, muszą one zaspokoić cele projektu. To określa związek pomiędzy Twoimi przedmiotami dostawy i sukcesem Twojego projektu. Kiedy stworzysz swoją Kartę Oceny Projektu, pierwszą rzeczą, którą potrzebujesz zrozumieć są kryteria Twojego sukcesu. Część kryteriów Twojego sukcesu powinno oznaczać dostarczenie przedmiotów dostawy. Jeśli skompletujesz udanie przedmioty dostawy o odpowiedniej jakości, będziesz miał co najmniej jeden komponent kryteriów ogólnego sukcesu na Twojej karcie wyników.
406 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.2.1 Zarządzanie Pomiarami / Zbieranie danych przy pomocy ankiet 10.2.P1 Jednym ze sposobów uzupełnienia określonych liczbowo pomiarów jest ankieta zadowolenia klienta. Na przykład, zamiast starać się zmierzyć dokładny czas odpowiedzi, możesz po prostu zadać pytania użytkownikom, jaki był stopień ich satysfakcji z czasu odpowiedzi na pytanie. W ten sam sposób, możesz dokonać pomiarów, które wskażą czas potrzebny do rozwiązania problemów klienta. To może wiązać się ze sprawdzeniem, kiedy padnie początkowe pytanie, kiedy pierwszy raz odpowiesz klientowi i kiedy problem zostanie rozwiązany. Z drugiej strony mógłbyś po prostu wysłać ankiety, w których zadasz pytania, czy Twoi klienci byli zadowoleni z okresu potrzebnego do rozwiązania problemu. Ankiety są ze swojej natury ilościowe, tzn. odzwierciedlają one opinię danej osoby w liczbach. Dlatego nie musisz koniecznie pytać w ankiecie o ocenę całego projektu. Niektóre informacje można uzyskać łatwiej za pomocą określeń liczbowych. Na przykład, nie ma zazwyczaj powodu wysyłać ankiety do departamentu finansów, żeby zapytać, jak jest realizowany budżet. Powinieneś mieć dostęp do faktów, Jednak dla wielu innych rodzajów pomiarów pytania przez ankiety mogą być wykorzystywane jako substytut dla pomiarów innych typów. Ankiety mogą się składać z pytań i mjesc na odpowiedzi dla respondenta. Wiele ankiet jest kombinacją pytań z odpowiedziami w formie skla liczbowych i rankingów. Dobrze przygotowane ankiety mogą przynieść wiele korzyści: Kiedy starasz się określić, jak ludzie oddziałują wzajemnie na siebie, albo jak proces oddziałuje na ludzi, być może najlepszym sposobem zebrania informacji zwrotnej będzie zapytanie ludzi. Jest to pomocne, ale nie pozwala w sposób ilościowy określić informacji. Ankiety dają ci elastyczność – wkład od ludzi, których dotyczyły. Są one stosunkowo niedrogim sposobem zebrania informacji od wielu interesariuszy. Na przykład dostawca może próbować zebrać informacje zwrotne od setek lub tysięcy klientów. Ankieta może być efektywnym sposobem na poznanie opinii wielu osób. Oczywiście istnieją również słabe strony ankiet. Oto one:
Dopóki
zdecydowanie i precyzyjnie nie określisz pytań w ankiecie, nie otrzymasz z powrotem wypełnionych ankiet. Tak naprawdę powinieneś być zadowolony, jeśli otrzymasz 50 % ankiet, a wyniki w okolicy 25 % i mniej nie są wcale rzadkie. Jeśli dostaniesz za mało odpowiedzi na ankiety, możesz nie uzyskać pewności, czy rezultaty są reprezentatywne dla całej grupy.
Wiele, (być może większość) ankiet nie jest zbyt dobra i dlatego uzyskane informacje są podejrzane. Problemy mogą dotyczyć:
Trudności w wypełnianiu ankiet, być może z powodu braku wystarczającej ilości miejsca
Warianty odpowiedzi (do wyboru) nie są spójne i logiczne 407 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
zadawania sugerujących pytań, które wiodą w określonym kierunku Zadawania pytań dotyczących jednego zagadnienia, kiedy zdanie
zawiera
dwa lub więcej pytania.
Kiedy tworzysz ankietę, wspólnym pytaniem jest: czy ankieta ma być anonimowa czy też nie. Pytanie o tożsamość może ułatwić zadanie kolejnych pytań i spowodować większą klarowność odpowiedzi. Jednak może to spowodować, że niektórzy respondenci w ogóle nie odpowiedzą na pytania. 10.2.1.P2 Uważaj na pytania: „TAK – NIE‖ Wielu niedoświadczonych ankieterów zaczyna zadawanie pytań, na które można odpowiedzieć: tak lub nie. W ten sposób odpowiedzi są krótkie i proste do interpretacji. Jeśli zadajesz pytania „TAK – NIE”, możesz z łatwością ujmować w tabele rezultaty, by określić ogólne preferencje. Problem z takimi pytaniami polega na tym, że odpowiedź nie uznaje odcieni szarości (biały albo czarny, wszystko albo nic). Często respondent ma bardziej kompleksowe spojrzenie. Czasami może być zadowolony z jednej pozycji a niezadowolony z innej. Respondenci mogą sobie nie życzyć takiej klasyfikacji. Lepszą metodą jest zadawanie pytań, które pozwolą respondentom na dawanie zróżnicowanych odpowiedzi. Na przykład możesz zapytać sponsora: „Jakie są Twoje ogólne odczucia związane z projektem” i pozwolić mu na określenie jego oceny w pięciostopniowej skali (albo w 10 punktowej). W takiej sytuacji sponsor ma pewną swobodę. Jeśli jest całkowicie zadowolony może dać projektowi 5. Jeśli sponsor był zadowolony z większości rzeczy i niezadowolony z niektórych, może dać zespołowi 4 w pięciostopniowej skali lub 7 na 10. Jeszcze raz, pojawiające się wyniki określają przeciętną ocenę poziomu wykonania projektu. 10.2.1.P3 Wysyłaj ankiety odpowiednio wcześnie i często, aby mieć czas na udoskonalenie Ankieta do klienta może być wysłana na końcu każdego projektu – małego, średniego lub dużego. Dostarczy ona końcowych informacji zwrotnych od klienta i określi, czy przedmioty dostawy spełniają potrzeby i czy projekt został wykonany dobrze. Jednak zespól nie ma szans na poprawę, jeśli jedyna ankieta sporządzana jest na końcu projektu. Dla większych projektów zespół projektowy powinien dokonywać przeglądu poiarów co jakiś czas, na przykład: w połowie realizacji projektu i na jego końcu. Jeśli Twój projekt jest wystarczająco duży, powinieneś zrobić ankietę na zwieńczenie głównej fazy projektu albo punktu przełomowego. Jeśli robisz zbyt dużo ankiet, może to spowodować ryzyko ignorowania ich, ponieważ zbyt dużo się nie zmieniło od ostatniej ankiety. Jednak, jeśli nie robisz ankiet zbyt często, ocena Twojego aktualnego działania może być trudna (z perspektywy klienta) i może nie pozwalać na czynienie postępów opartych na informacjach zwrotnych.
408 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
10.3 Zarządzanie pomiarami / Podsumowanie 10.3.P1 Przedmioty dostawy Poniższe przedmioty dostawy są dostępne w Bibliotece Ten Step
Projekt Karty Wyników Mierniki dotyczące zamykania projektu Ankiety dotyczące poziomu zadowolenia 10.3.P2 Dodatkowe działania
wielkość
Potrzebna informacja Działanie
Pracochłonność
Małe Zbierz i analizuj
1godzina/1tydzień
pomiary
Działanie
Wysiłek
Stwórz projekt Karty Średnie: 2-4 godziny Wyników Projektu Duże: 8 godzin
Średnie i duże
Zbierz i przeanalizuj różnie pomiary
409 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Uwagi
W małych projektach możesz zbierać i analizować dane raz na tydzień. Niektóre pomiary mogą zostać podsumowane na końcu projektu Komentarz Ta praca może być wykonana jako część definiowania projektu, albo jako jedna z pierwszych czynności zaraz po rozpoczęciu jego realizacji. Patrz na proces opisany w punkcie: 10.1. Większość pracy może być ukończona w trakcie spotkania kluczowych członków zespołu i interesariuszy. Miesięcznie. Zbierz i przeanalizuj pomiary, jak opisano w Twojej karcie
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
wyników.
Procesy udoskonalania działań
Oceniaj wyników
kartę
różnie
Miesięcznie. Ujmij w swoim harmonogramie czas potrzebny do analizy pomiarów. Zastosuj działania w trakcie realizacji wdrażania w życie udoskonalenia opartych na analizie danych dotychczas zebranych
różnie
Miesięcznie. Oceń pomiary, które zbierasz w okresie miesięcznym, aby upewnić się, czy w dalszym ciągu odpowiednio odzwierciedlają cele projektu i wciąż wdrażają pożądane działania.
410 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
Licencja: PL1025/2/2010/CR TenStep PM Process v6.00.03 wydana dla: Operator Gazociągów Przesyłowych GAZ-SYSTEM S.A., 02-337 Warszawa, ID:527-243-20-41
Informacje dodatkowe Inne materiały na temat metodyki TenStep dostępne są na stronach internetowych: http://www.tenstep.pl http://www.theicpm.com http://www.tenstep.com http://www.pmostep.com http://www.portfoliostep.com http://www.lifecyclestep.com Produkty TenStep oraz usługi wdrożeniowe i szkoleniowe dostępne są w TenStep Polska Sp. z o.o. ul. J i J. Rostafińskich 4 02-593 Warszawa
411 Prawa autorskie zastrzeżone © TenStep Polska Sp. z o.o. 2007-2010 www.tenstep.pl
