W standardzie PMI ryzyko jest to niepewne wydarzenie, które, jeśli zajdzie, może mieć negatywny albo pozytywny wpływ na projekt. Z tej definicji wynika podstawowy podział ryzyk na zagrożenia i okazje. Ponadto ryzyka są dzielone na:

· Techniczne, związane z tworzeniem produktu projektu, jego możliwościami technicznymi, jakością, efektywnością itp.

· Zarządcze, odnoszące się do wszystkich czynności związanych z procesem zarządzania, a więc planowaniem, monitorowaniem planów, mechanizmami zlecania i rozliczania prac itp.

· Organizacyjne, związane np. z brakiem właściwego finansowania, nieokreślonymi zależnościami pomiędzy projektami w realizujących je organizacjach czy konfliktami wykorzystania zasobów w tych organizacjach

· Zewnętrzne, odnoszące się do zmian w środowisku, w którym działa projekt lub mają być wykorzystywane jego produkty. Najczęściej spotykanym przykładem ryzyka zewnętrznego jest zmiana potrzeb klienta, ale można tu także zaliczyć problemy z zatrudnieniem czy zmianą warunków rynkowych. Ryzyka zewnętrzne trudno poddają się minimalizacji.

Intuicyjne pojęcie ryzyka odnosi się do możliwości wystąpienia zjawisk negatywnych. Próba rozszerzenia przez PMI tego pojęcia o zjawiska pozytywne nie jest konsekwentnie realizowana. Już przy definicji kategorii ryzyk PMI podaje przykłady odnoszące się wyłącznie do zagrożeń. Także przy opisie reakcji na ryzyko PMI wymienia wyłącznie unikanie, przeniesienie, zmniejszenie oraz akceptację, której aktywną techniką są plany awaryjne. Gdyby reakcja miała się odnosić do okazji, to na potrzeby prowadzonego przez mnie projektu zapewne wymyśliłbym na miejsce tych czterech technik odpowiednio prowokowanie, przyciąganie, zwiększanie i akceptację, ale raczej z planami okazyjnymi jako podstawową techniką. Trzeba więc uznać, że poza kilkoma zabiegami typu redakcyjnego w rzeczywistości zarządzanie ryzykiem w PMI odnosi się wyłącznie do zagrożeń, czyli zjawisk negatywnych.

Według PRINCE ryzyko jest to narażenie projektu na negatywne konsekwencje przyszłych wydarzeń. Wyróżniane są dwa ogólne rodzaje ryzyk:

· Biznesowe

Ryzyka biznesowe są to zagrożenia związane z niedostarczeniem przez projekt produktów, które umożliwiałyby osiągnięcie korzyści biznesowych. ryzyka projektowe. Są powiązane z takimi obszarami jak zmiany uwarunkowań zewnętrznych (np. prawo), zmiany w wymaganiach klienta czy znaczenie dla biznesu firmy realizującej projekt.

Projektowe

Zagrożenia związane z zarządzaniem projektem; najczęściej odnoszące się do osiągnięcia celów projektu zgodnie z zaplanowanym kosztem i harmonogramem. Ryzyka projektowe są dalej klasyfikowane jako:

Problemy związane z dostawcami
Czynniki organizacyjne, np. związane z personelem i strukturą organizacyjną projektu
Zagadnienia techniczne, związane np. z jakością wymagań, integracją, testowaniem i wdrażaniem produktu projektu.

W modelu CMMI nie jest podawana definicja ryzyka, ale przy identyfikowaniu ryzyka mówi się, że należy wyszukiwać potencjalne problemy, niebezpieczeństwa, zagrożenia lub słabości, które mogą negatywnie wpłynąć na plan lub wynik projektu. Określenie kategorii ryzyk w projekcie jest elementem określenia strategii zarządzania ryzykiem. Jako przykładowe kategorie, które powinny być rozważane CMMI podaje:

· Fazy życia produktu (odpowiada ryzykom technicznym PMI i projektowym ryzykom technicznym PRINCE)

· Typy procesów (np. inżynierskie, wsparcia)

· Typy wykorzystywanych produktów (np. wytwarzane w projekcie, pozyskiwane z zewnątrz; odwołuje się częściowo do ryzyk określonych w PRINCE jako ryzyka związane z dostawcami)

· Zarządzanie projektami (odpowiada ryzykom związanym z czynnikami organizacyjnymi PRINCE oraz ryzykom organizacyjnym i projektowym PMI)

Wszystkie trzy standardy nakazują wykonanie analizy ryzyka, która powinna wykryć grupy ryzyk specyficznych dla każdego projektu. Podane klasyfikacje są tylko wstępnymi próbami zwrócenia uwagi na zagrożone obszary. Proponowany przez PRINCE podział na ryzyka biznesowe i projektowe ma konsekwencje w odpowiedzialności za obsługę ryzyka. Za obsługę ryzyk biznesowych odpowiada Rada Projektu, natomiast za pozostałe – zespół zarządzający projektem. Ten aspekt istotnie odróżnia podejście PRINCE do klasyfikacji ryzyka od podejścia PMI i CMMI.

Struktura procesów zarządzania ryzykiem

W procesach związanych z zarządzaniem ryzykiem można wyróżnić cztery główne grupy:

· Określenie strategii

· Analiza ryzyka

· Planowanie reakcji na ryzyko

· Sterowanie ryzykiem

Określenie strategii to zestaw czynności, których wynikiem jest wypracowanie właściwego dla danego projektu sposobu zarządzania ryzykiem. Ogólna metoda, przedstawiana w ramach standardu, jest dostosowywana i ewentualnie modyfikowana.

W ramach analizy ryzyka są kolekcjonowane, oceniane, grupowane i porządkowane według poziomu zagrażania projektowi. Wskazywane są te, dla których konieczne jest podjęcie akcji zmniejszających je.

Planowanie reakcji na ryzyko to opracowanie strategii zmniejszania ryzyka oraz zestawów akcji realizujących te ryzyka. Częścią planowania reakcji na ryzyko może być modyfikacja wcześniej opracowanych planów projektu.

Sterowanie ryzykiem to jego monitorowanie ryzyk oraz uruchamianie wcześniej zaplanowanych działań a także reagowanie na nie przewidziane wcześniej zaburzenia w realizacji projektu.

Poza określeniem strategii procesy z pozostałych grup są wykonywane wielokrotnie w trakcie realizacji projektu.

Rysunek 1 pokazuje ogólną strukturę procesów zarządzania ryzykiem.

Rysunek 1. Struktura procesów zarządzania ryzykiem

W PMI zarządzanie ryzykiem jest dobrze wyodrębnionym obszarem procesów. Odwołania do ryzyka w innych obszarach procesów są dość rzadkie i występują w obszarach Zarządzania Czasem, Zarządzania Kosztem, Zarządzania Zaopatrzeniem, Zarządzanie Komunikacją i Zarządzania Integralnością.

PRINCE w obszarze zarządzania ryzykiem koncentruje się na procesach, w których należy wykonywać obsługę ryzyka, zależnościach organizacyjnych oraz sposobie dokumentowania ryzyk.

W CMMI obsługa ryzyka jest składową innych obszarów. Od występujących ryzyk uzależnione są procesy Innowacje i Wdrożenia Organizacyjne (składowa Zarządzania Procesami), Planowanie Projektów, Monitorowanie Projektów oraz Ilościowe Zarządzanie Projektami (składowe obszaru Zarządzanie Projektami), Opracowywanie Wymagań, Rozwiązania Techniczne (z obszaru Inżynieria) oraz Analiza i Podejmowanie Decyzji z obszaru Wsparcie.

Określenie strategii

Specyficzny cel CMMI:Przygotowanie do Zarządzania Ryzykiem nakazuje określić kategorie możliwych ryzyk, określić ich sposób oceny oraz przygotować strategię zarządzania ryzykiem.

Pierwszą praktyką jest CMMI:Określenie Źródeł i Kategorii Ryzyka. Należy najpierw wyszukać możliwe źródła ryzyka, na przykład brak podstaw do szacowania (w nowatorskich projektach), niedojrzałość technologii, brak kwalifikacji personelu, niedostateczny budżet, opóźnienia w dostawach. Następnie należy przygotować kategorie, do których ryzyka będą przydzielane. CMMI sugeruje poszukiwanie kategorii w fazach życia produktu (kategoria ryzyk związanych z wymaganiami, z projektowaniem, z wykonaniem, wdrożeniem....). Drugą podstawą do wyszukiwania kategorii ryzyk mogą być typy procesów - np. ryzyka związane z procesami inżynierskimi, związane z procesami zarządzania projektami czy z procesami wsparcia. Trzecie przykładowe źródło podziału to typy wykorzystywanych produktów – ryzyka związane z produktami wytwarzanymi w projekcie, związane z produktami pozyskiwanymi z zewnątrz czy też związane z własnymi produktami dostosowanymi do potrzeb projektu. Ostatnim podawanym źródłem podziału na kategorie jest zarządzanie projektami – na przykład ryzyka związane z kontraktem, związane z kosztem, z zasobami, z personelem. Kategorie ryzyk powinny być wykorzystywane do wspólnego opracowywania reakcji na ich wystąpienie.

Po określeniu potencjalnych źródeł i kategorii ryzyk należy wykonać praktykę CMMI:Określenie Parametrów Ryzyk. Bardzo ważnym problemem jest ustalenie sposobów mierzenia ryzyk, żeby zagwarantować porównywalność ryzyk mających różną naturę. Podstawowymi miarami wymienianymi przez CMMI są prawdopodobieństwo jego wystąpienia oraz miara wpływu ryzyka na cele projektu. Prawdopodobieństwo i wpływ najczęściej określa się za pomocą kilku wyróżnionych wartości. Dla obydwu tych wielkości można np. przyjąć zestaw wartości na skali pomiędzy bardzo niskim a bardzo wysokim, ale decyzja o przyjęciu określonej skali musi być podjęta w trakcie opracowywania podejścia do zarządzania ryzykiem. Także graniczne wartości prawdopodobieństwa oraz wpływu, które będą powodowały dalsze akcje, muszą być ustalone w tej praktyce. Na przykład należy ustalić poziom przekroczenia kosztu (harmonogramu, efektywności), który spowoduje że do obsługi ryzyka zostanie włączone wyższe kierownictwo projektu. Innym rodzajem parametrów ryzyk jest określenie, kiedy ryzyka w ogóle mają podlegać zarządzaniu, kiedy mają podlegać analizie jakościowej, a kiedy także analizie ilościowej.

Określenie źródeł, kategorii i parametrów ryzyk ma na celu przygotowanie wykonania praktyki CMMI:Ustanowienie Strategii Zarządzania Ryzykiem. Strategia ta powinna odnosić się do wizji sukcesu projektu. Czynnikami wizji sukcesu, wpływającymi na strategię zarządzania ryzykiem, może być np. ogólny koszt projektu (faworyzuje tanie metody zarządzania ryzykiem i każe zwrócić szczególną uwagę na zagadnienia związane z kosztem) czy też wysoka jakość produktu projektu. Zgromadzona w wyniku wcześniej opisanych praktyk wiedza powinna pozwolić określić metody i narzędzia, które będą wykorzystywane w trakcie zarządzania ryzykiem. W dokumencie określającym strategię zarządzania ryzykiem należy umieścić również wyniki procesów CMMI:Określenie Źródeł i Kategorii Ryzyka oraz CMMI:Określenie Parametrów Ryzyk. Konieczne jest także wskazanie metod zmniejszania ryzyka. CMMI nakazuje dość szczegółowe określenie tych metod, podając jako przykłady prototypowanie, symulację czy ewolucyjny rozwój. Należy także podać środki monitorowania statusu ryzyka oraz odstępy czasu, w których będzie się odbywało monitorowanie oraz ponowna ocena ryzyka. Strategia musi być przejrzana z zainteresowanymi udziałowcami aby uzyskać ich zrozumienie i przekonanie.

Podobne znaczenie do osiągnięcia celu CMMI:Przygotowanie do Zarządzania Ryzykiem ma proces PMI:Planowanie Zarządzania Ryzykiem. Jego wynikiem jest ogólny plan postępowania z ryzykiem w projekcie. Zasadniczą składową tego planu jest opis podejścia do zarządzania ryzykiem. Plan ten powstaje na podstawie standardowego zestawu procesów zarządzania ryzykiem PMI, dostosowanych do potrzeb i możliwości projektu. Możliwe jest podjęcie decyzji o pominięciu niektórych elementów zarządzania ryzykiem (np. nie wykonywanie analizy ilościowej) lub ich połączeniu (np. połączenie procesów analizy jakościowej i analizy ilościowej).

Wadą proponowanego przez PMI podejścia jest nie poprzedzanie procesu planowania wstępnym rozpoznaniem ryzyk, które jest wykonywane w praktykach CMMI:Określenie Źródeł i Kategorii Ryzyka oraz CMMI:Określenie Parametrów Ryzyk. Pewną namiastką tych praktyk jest w PMI sugestia wykorzystania wypracowanych wcześniej w firmie realizującej projekt standardów, metod oraz doświadczeń związanych z zarządzaniem ryzykiem. Nb. jest to jedno z niewielu w standardzie PMI odwołań do elementów zarządzania procesowego w organizacji.

PMI dopuszcza możliwość obsługi ryzyka przez zespół spoza projektu, którego jedynym celem będzie zarządzanie ryzykiem.

Plan powinien opisywać sposoby poszukiwania ryzyka – np. sposób wykorzystania źródeł zewnętrznych (listy ryzyk), osoby zaangażowane w wywiady mające na celu identyfikację i analizę ryzyka. Ważną, nieobecną w CMMI częścią procesu PMI:Planowanie Zarządzania Ryzykiem, jest ustalenie budżetu przeznaczonego na zarządzanie ryzykiem. Wszystkie procesy i czynności związane z ryzykiem muszą pochłaniać pewne zasoby, a więc są źródłami kosztów. Należy się domyślać że chodzi tu o budżet przeznaczony na analizę, opracowywanie planów awaryjnych i tp., a nie na realizację wbudowanych w plan projektu technik zapobiegania ryzyku.

PMI poza sposobami dokumentowania, raportowania nakazuje także audytowanie procesów związanych z zarządzaniem ryzykiem.

W PRINCE nie przewidziano procesu, którego wynikiem byłoby wypracowanie strategii zarządzania ryzykiem w projekcie. Oznacza to, że każde ryzyko musi być obsługiwane osobno. Może to utrudnić porównywanie między sobą istniejących ryzyk i podejmowanie właściwych akcji na poziomie projektu lub wyższym. Ponieważ nie jest przewidziany osobny budżet na zarządzanie ryzykiem, nie istnieje możliwość wydzielenia zarządzania ryzykiem do kompetencji zewnętrznego zespołu.

Analiza ryzyka

Celem procesu PMI:Identyfikacja Ryzyka jest wskazanie i udokumentowanie ryzyk mających wpływ na realizację projektu. W procesie tym nie określa się prawdopodobieństwa ani wpływu ryzyka.

Istnieją dwie kategorii informacji wejściowych do procesu PMI:Identyfikacja Ryzyka. Są to wcześniej wypracowane elementy planu projektu oraz wiedza o ryzykach, na które projekt może być narażony. Wykorzystanie jako wejścia elementów planu projektu implikuje (nie jest to jednoznacznie powiedziane) późne rozpoczynanie identyfikacji ryzyka, gdy gotowy jest dokument otwarcia projektu, opis produktu, założenia i ograniczenia projektu oraz co najmniej wstępne wersje WBS, planu zarządzania zaopatrzeniem, planu zarządzania personelem, szacunków kosztu i harmonogramu oraz innych wyników planowań. Poszukiwanie ryzyk powinno się rozpocząć od analizy tych właśnie materiałów. Ponieważ wyszukiwanie ryzyk jest rodzajem weryfikacji prac planistycznych, można się spodziewać, że lepsze wyniki zostaną osiągnięte, gdy to zajęcie nie zostanie powierzone autorom planów. Wynikiem wyszukiwania ryzyk może być żądanie uściślenia planów tak, aby można było się jednoznacznie wypowiedzieć o ich realności.

Wiedza o potencjalnych ryzykach może płynąć z kilku źródeł. Dwa podstawowe to doświadczenie organizacji realizującej projekt oraz ogólnodostępne (sprzedawane lub publikowane) bazy danych ryzyk, najczęściej dla określonych obszarów zastosowań projektów. Dla znanej mi bliżej dziedziny projektów informatycznych listę ryzyk opublikował Software Engineering Institute w publikacji R. C. Williams, G. J. Pandelios, S. G. Behrens, Software Risk Evaluation Method Description (Version 2.0), TR CMU/SEI-99-TR-029, XII.1999. PMI zwraca uwagę, że opieranie się na istniejących listach ryzyk może zawęzić zakres wyszukiwania do wcześniej występujących ryzyk.

Wynikiem procesu PMI:Identyfikacja Ryzyka powinna być lista ryzyk wraz z ich wyzwalaczami, czyli sytuacjami wskazującymi, że ryzyko się zdarzyło lub w najbliższym czasie się wydarzy. Na przykład dla ryzyka zmiany wymagań w projekcie informatycznym, realizowanym dla agendy rządowej, są to informacje o rozpoczęciu prac nad ustawą modyfikującą obszar działalności tej agendy.

Technikami grupowymi występującymi w procesie PMI:Identyfikacja Ryzyka są: burza mózgów, techniki delfickie wykorzystujące wiedzę ekspertów, wywiady oraz analiza SWOT. Techniki delfickie polegają na iteracyjnym, anonimowym ustalaniu opinii ekspertów – w tym przypadku w zakresie ryzyk projektu. PMI sugeruje także wspomaganie wyszukiwania ryzyk technikami graficznymi – np. poprzez wykorzystanie diagramów Ishikawy, schematów blokowych czy diagramów pokazujących zależności przyczynowo – skutkowe pomiędzy elementami projektu.

W CMMI identyfikacji ryzyka służą dwie praktyki: CMMI:Identyfikacja Ryzyk Projektu (z obszaru CMMI:Planowanie Projektu) oraz CMMI:Identyfikacja Ryzyka (obszar CMMI:Zarządzanie Ryzykiem). Druga z tych praktyk może być wykorzystywana także do obsługi procesów w organizacji, a nie tylko projektów. Łącznie praktyki te niewiele różnią się od opisanych wyżej elementów procesu PMI:Identyfikacja Ryzyka. W przeciwieństwie do PMI do obszaru ryzyk w CMMI zalicza się także działanie siły wyższej – zdarzeniom takim, z definicji, nie można zapobiegać, ale możliwe jest wykorzystanie technik zarządzania ryzykiem do zmniejszania skutków ich działania. Gdyby przyjąć spojrzenie PMI, to, stojąca do chwili obecnej w mojej bibliotece wydana przez dostojną oficynę Wiley & Sons książka S. H. Goldberga, S. C. Davisa i A. M. Pengalisa, zatytułowana Y2000 Risk Management nie miała by prawa zostać nigdy napisana (co, skądinąd, być może przyczyniłoby się do rozsądniejszego zagospodarowania potężnych pieniędzy :-)). W procesie identyfikacji ryzyka CMMI nacisk kładzie się na ryzyka związane z kosztem, harmonogramem oraz charakterystykami wytwarzanego produktu. Pierwotna identyfikacja ryzyka powinna być przeprowadzona po określeniu kosztu i harmonogramu projektu, natomiast w trakcie realizacji projektu należy praktykę ponowić, gdy zmienia się status ryzyk albo gdy znacząco zmieniają się warunki projektu – czyli gdy modyfikowany jest jego plan. Technikami wskazywanymi przez CMMI są m. in. strukturalne wywiady, burze mózgów, analizy sieciowe, listy kontrolne.

Opis procesu PRINCE:Identyfikacja Ryzyka ogranicza się do nakazania określenia ryzyk, które mogą zagrażać projektowi. Identyfikacja ryzyka jest wykonywana w sposób ciągły przez cały projekt. Dodatkowo PRINCE wymienia procesy, w których identyfikacja ta musi być wykonana. Pierwsze wyszukiwanie ryzyk biznesowych powinno odbyć się w trakcie realizacji procesu PRINCE:Opracowanie Konspektu Projektu. Podproces PRINCE:Ponowna Ocena Uzasadnienia Biznesowego i Ryzyk, będący składową procesu PRINCE:Inicjacja Projektu, jest przeznaczony m. in. do wyszukania nowych, możliwych do zidentyfikowania ryzyk biznesowych. Zidentyfikowane ryzyka mogą w skrajnym przypadku spowodować zmianę celów biznesowych projektu. W każdym procesie PRINCE:Planowanie należy przed opracowaniem ostatecznej wersji wykonać identyfikację ryzyka. W podprocesie PRINCE:Zlecanie Pakietu Prac kierownik projektu powinien przeprowadzić identyfikację ryzyka związanego z pracą. Osoba przyjmująca pracę w procesie PRINCE:Akceptacja Pakietu Prac także powinna wykonać identyfikację ryzyk. Ryzyka mogą zostać zidentyfikowane w podprocesie PRINCE:Rozpatrywanie Zagadnień Projektu. W podprocesie PRINCE:Przegląd Statusu Fazy ryzyka mogą być zidentyfikowane w trakcie ogólnej oceny stanu zaawansowania fazy projektu. Ryzyka zidentyfikowane w podprocesie PRINCE:Identyfikacja Akcji Następujących odnoszą się do zagrożeń związanych z wykorzystaniem produktu projektu. Wszystkie ryzyka powinny być opisywane w Rejestrze Ryzyk, zawierającym pełną informację o ich naturze, ocenie, statusie i zaplanowanych i wykonanych akcjach.

Także według dwóch pozostałych metod identyfikacja ryzyka powinna być wykonywana wielokrotnie. PMI precyzuje, że pierwotna identyfikacja ryzyka powinna najpierw być wykonana w gronie personelu zespołu projektowego. Wyniki tej wstępnej analizy mogą być następnie modyfikowane w szerszym gronie, w skład którego wchodzą przedstawiciele klienta, eksperci dziedziny, w której projekt jest realizowany czy też eksperci zarządzania ryzykiem.

Zadaniem procesu PMI:Jakościowa Analiza Ryzyka jest ocena prawdopodobieństwa, wpływu oraz narażenia na ryzyko i wyselekcjonowanie najważniejszych ryzyk – do dalszej analizy ilościowej lub bezpośrednio do procesu opracowania reakcji na ryzyko. Podstawowymi technikami są ocena prawdopodobieństwa wystąpienia ryzyka, ocena wpływu ryzyka na osiąganie celów projektu oraz macierz oceny ryzyka.

Ocena prawdopodobieństwa powinna wykorzystywać skalę pięciostopniową. Dla ryzyk ocenionych na skali pięciostopniowej przypisuje się wartości liczbowe, np. 0.1, 0.3, 0.5, 0.7, 09. Analogiczne wartości może przyjmować skala wpływu. Macierz oceny ryzyka jest to graficzne przedstawienie wartości iloczynu prawdopodobieństwa i wpływu. Przykład macierzy oceny ryzyka pokazuje Tabela 1.

Tabela 1. Standard PMI - tabela oceny ryzyka

Wartości graniczne: < 0,1 brak dalszej obsługi; < 0,4 do dalszej analizy; > 0,4 do przeciwdziałania

P-stwo	Ocena ryzyka = P * W
0.1	0.01	0.03	0.05	0.07	0.09
0.3	0.03	0.09	0.12	0.21	0.27
0.5	0.05	0.15	0.25	0.35	0.45
0.7	0.07	0.21	0.35	0.49	0.63
0.9	0.09	0.27	0.45	0.63	0.81
	0.1	0.3	0.5	0.7	0.9	Wpływ na cele projektu

Dla tabeli oceny ryzyka – czyli dla iloczynu prawdopodobieństwa i wpływu, zwanego narażeniem na ryzyko – określa się wartości progowe. Zwykle przyjmuje się górną granicę narażenia na ryzyko, powodującą wykluczenie z dalszego zarządzania ryzykiem (czyli granicę lekceważenia ryzyka). Określa się także minimalną wartość narażenia na ryzyko, powodującą obowiązkowe przeznaczenie ryzyka do procesu przeciwdziałania mu. Decyzja w sprawie dalszej obsłudze ryzyka pomiędzy tymi granicami należy do zespołu zarządzającego projektem.

Standard PMI każe zwrócić uwagę na precyzję danych wykorzystywanych przy analizie ryzyka. Cechami decydującymi o precyzji danych są zrozumienie problemu przez osoby analizujące, zestaw i jakość danych dostępnych przy analizie ryzyka.

W wyniku analizy jakościowej ryzyka są porządkowane. Podstawowym kryterium porządkowania jest wartość narażenia na ryzyko, ale możliwe są także inne kryteria, np. spodziewany czas wystąpienia (wcześniej spodziewane muszą być szybciej obsłużone) czy miejsce w WBS.

Wynikiem analizy jakościowej jest także ogólna ocena ryzyka projektu. PMI nie mówi, w jaki sposób ocenę tę należy wyliczyć. Najprostszą, dość obiektywną miarą, która może być zastosowana jest liczba dużych ryzyk (Tabela 1: ryzyka o narażeniu większym niż 0,4). Ogólna ocena ryzyka projektu może być wykorzystana w organizacji realizującej projekt np. do decyzji w kwestii przydziału zasobów do projektu lub decyzji o zatrzymaniu projektu.

W wyniku powtarzania analizy ryzyka mogą się ujawnić trendy, które będą powodowały konieczność intensyfikacji (lub osłabienia) działań związanych z zarządzaniem ryzykiem.

PMI:Ilościowa Ocena Ryzyka to proces, którego zadaniem jest wykorzystanie metod matematycznych do oceny ryzyka, jego wpływu na cele projektu oraz do oceny prawdopodobieństwa osiągnięcia założonych celów. Jednym z produktów ilościowej oceny ryzyka może być wyznaczenie rezerw kosztu i czasu projektu.

Podobnie jak w ocenie jakościowej, jedną z wykorzystywanych technik są wywiady. Cel wywiadów jest tutaj jednak inny. Dla analizowanych zmiennych – np. czas czy koszt – należy przyjąć określony rozkład (np. normalny czy trójkątny). Osoby uczestniczące w wywiadach proszone są o podanie parametrów rozkładu, np. dla rozkładu normalnego - wartości średniej i odchylenia standardowego. Na podstawie uzyskanych odpowiedzi wyznacza się rozkład analizowanej zmiennej. Uzyskany rozkład ma swoje parametry – np. wartość średnią, poziomy ufności itd.

Inną metodą analizy ilościowej jest analiza drzew decyzyjnych, zawierających rodzaje decyzji, ich prawdopodobieństwa i konsekwencje dla projektu.

Ostatnia sugerowaną przez PMI metodą analizy ilościowej są symulacje. Podstawą modelu symulacyjnego jest WBS (dla symulowania kosztu) oraz diagramy sieciowe, opisujące zależności pomiędzy sekwencjami wykonywanych czynności (dla symulacji czasu). Symulacje są wykonywane metodą Monte Carlo, polegającą na wielokrotnym wyliczaniu wartości analizowanej zmiennej przy losowych (zgodnych z przyjętym rozkładem) wartościach elementarnych (kosztach lub czasach wykonania elementarnych czynności).

PMI zaleca także stosowanie analizy czułości, która pozwala oszacować wpływ poszczególnych czynników na określone ryzyko (lub łączną ocenę ryzyka projektu). W tym celu przy ustalonym modelu określonego ryzyka przyjmuje się, że wszystkie elementy modelu ryzyka poza jednym są ustalone. Następnie bada się, jaka jest wartość analizowanego ryzyka przy zmianach wybranego elementu. Na przykład przy ustalonym modelu czasu trwania projektu, składającego się, jak to zwykle z wielu czynności, można zbadać wpływ przedłużania lub skracania czasu trwania wybranej, zasadniczej czynności na łączny czas. Analiza taka może być ciekawa, szczególnie wtedy, gdy czynności są ze sobą powiązane w skomplikowany, nieliniowy sposób.

Wyniki analizy ilościowej powinny służyć do wskazania najbardziej znaczących ryzyk projektu. Ubocznymi skutkami są ogólna probabilistyczna ocena projektu oraz trendy w wynikach analizy ilościowej (jeśli analiza jest powtarzana). Wyniki stosowania technik probabilistycznych oraz symulacyjnych mogą być także wykorzystywane do oszacowania prawdopodobieństwa osiągnięcia celów projektu.

Praktyka CMMI:Ocena, Kategoryzacja i Priorytetyzacja Ryzyk opisuje tylko bardzo ogólne zasady wykonywania analizy ryzyka. Można powiedzieć, że wszystkie wymagania stawiane praktyce są wymienione w jej nazwie. Wspomina się, że na podstawie prawdopodobieństwa i wpływu może być wyliczony poziom narażenia na ryzyko – na tym parametrze nie były wykonywane działania praktyki CMMI:Określenie Parametrów Ryzyk, co wydaje się dziwne, ponieważ zwykle w analizach ryzykach, wartości tego właśnie parametru decydują o akcjach wykonywanych na ryzyku. Pewnym uzupełnieniem procesu analizy z PMI jest wprowadzenie kategorii grup ryzyk, dla których można opracowywać wspólne sposoby reakcji.

W PRINCE mówi się, że należy wykonać szacowanie i ocenę ryzyka. Opis tych czynności wspomina tylko o konieczności określenia prawdopodobieństwa i wpływu ryzyka oraz wskazaniu ryzyk podlegających dalszym działaniom. Elementem oceny ryzyka jest określenie możliwych akcji zmniejszających ryzyko. Szacowanie i ocena ryzyka powinny być wykonywane zawsze bezpośrednio po wykonaniu identyfikacji ryzyka.

Planowanie reakcji na ryzyko

Celem procesu PMI:Planowanie Reakcji na Ryzyko jest określenie, w jaki sposób będą obsługiwane ryzyka, które wcześniej zostały określone jako ważne dla przebiegu projektu. Według PMI istnieją cztery podstawowe strategie reakcji na ryzyko:

· Zmniejszanie

Próba zmniejszenia prawdopodobieństwa i/lub wpływu do wymaganego progu.

Np. testowanie oprogramowania w projekcie „Rok 2000”, stosowanie sprawdzonego oprogramowania, zwiększenie obsady zespołu testów, zatrudnienie bardziej wykwalifikowanego personelu. Zmniejszenie wpływu ryzyka to np. redundantne dublowanie wdrażanego systemu.

Unikanie

Szczególny rodzaj zmniejszania, prowadzący do osiągnięcia zerowego poziomu prawdopodobieństwa lub wpływu na projekt. Eliminacja ryzyka lub ochrona celów projektu przed jego wpływem.

Np. zwiększenie płac zespołu, dodawanie zasobów lub czasu, unikanie nieznanego podwykonawcy.

Przeniesienie.

Przeniesienie konsekwencji ryzyka razem z reakcją na to ryzyko na inny podmiot.

Najczęściej stosowane do przeniesienia ryzyka finansowego. Np. ubezpieczenia.

· Akceptacja

Nie zmienianie planu projektu w celu przeciwdziałania ryzyku lub brak możliwości stworzenia takiego planu.

Akceptacja czynna jest to opracowanie planów awaryjnych. Plany awaryjne są uruchamiane przez wyzwalacze (symptomy ryzyka). Plany mogą być uruchamiane gdy pojawią się wczesne sygnały ostrzegawcze – wtedy ich celem jest zapobieżenie ostatecznej materializacji ryzyka, albo gdy ryzyko wystąpi – wtedy ich celem jest przywrócenie projektu do normalnego procesu realizacji. Ten drugi rodzaj planów awaryjnych jest opracowywany jeśli ryzyko ma duży wpływ lub jeśli wybrana strategia może nie być w pełni skuteczna.

Akceptacja bierna: jest to nie robienie niczego, czekanie aż ryzyko się wydarzy.

Według PMI dla każdego ryzyka należy wybrać (co najmniej jedną) strategię oraz szczegółowo zaplanować sposób jej realizacji. Dla każdego ryzyka należy wskazać osobę odpowiedzialną za jego monitorowanie oraz podejmowanie decyzji (analogiczne wymaganie znajduje się w CMMI oraz PRINCE). Osoba taka musi mieć zgodne z przyjętą strategią ustalone szczegółowe sposoby działania. Musi mieć także przyznany budżet oraz uprawnienia konieczne do wykonania działań.

PMI zaleca oszacowanie ryzyk pozostających po realizacji strategii zapobiegania ryzyku oraz ryzyk wtórnych, związanych z realizacją tej strategii. Wynikiem planowania reakcji na ryzyko powinno być także ustalenie rezerw kosztu i czasu projektu. Wszystkie te wyniki planowania mogą wpłynąć na wcześniej przyjęte ustalenia dotyczące kosztu, harmonogramu, personelu i innych obszarów zarządzania procesem. W związku z tym po przyjęciu planu reakcji na ryzyko (zawierającego opisane tu wyniki procesu Planowania Reakcji na Ryzyko) konieczne może być ponowne przepracowanie planu projektu, a być może także kontraktu, na podstawie którego projekt jest realizowany.

CMMI wyróżnia pięć opcji (odpowiednik PMI strategii) obsługi ryzyka:

· Unikanie

Sterowanie
Przeniesienie
Akceptacja

Opcje te odpowiadają odpowiednim strategiom PMI. Do opcji obsługi ryzyka CMMI zalicza także:

Monitorowanie

Obserwowanie i okresowa ponowna ocena ryzyka i jego parametrów.

Klasyfikacja akcji związanych z ryzykiem w, umieszczona w opisie czynności PRINCE:Ocena Ryzyka zawiera:

· Zapobieganie

Redukcję (wg. nazewnictwa PMI – zmniejszanie)
Przeniesienie
Plany awaryjne
Akceptację

CMMI dopiero do procesu opracowywania planu zmniejszania ryzyka włącza określenie wartości parametrów nakazujących podejmowanie określonych akcji – w PMI wynikiem identyfikacji ryzyka jest zestaw ich wyzwalaczy, zaś progi nakazujące podejmowanie akcji są ustalane w procesie analizy ryzyka. W CMMI w tym momencie pojawiają się także zagadnienia związane z budżetem – należy wykonać analizę kosztów / zysków dla każdego ryzyka. Wyniki tej analizy są podstawą do wyboru najwłaściwszych rozwiązań. Wszystkie plany obsługi ryzyka łącznie tworzą ogólny plan zmniejszania ryzyka, dzięki któremu poszczególne plany są koordynowane. Poza tym planem pozostają plany awaryjne, które są przygotowywane na wypadem zajścia zdarzenia ryzykownego.

PRINCE rozbija planowanie reakcji na ryzyko na dwie czynności: PRINCE:Planowanie i PRINCE:Przydział Zasobów. Głównymi wynikami planowania jest określenie zasobów, opracowanie i włączenie do planu szczegółowego zestawu akcji oraz uzyskanie zatwierdzenia planu przez odpowiednie kierownictwo. Plan ten jest włączany do planu realizacji fazy. Zasadniczą częścią drugiej z tych czynności jest uzyskanie funduszy na realizację akcji obsługi ryzyka (w PRINCE, inaczej niż np. w PMI nie istnieje ogólny budżet zarządzania ryzykiem). Planowanie akcji związanych z obsługą ryzyka powinno się odbywać po wykonaniu oszacowania ryzyka.

Sterowanie ryzykiem

Proces PMI:Monitorowanie i Śledzenie Ryzyk trwa przez cały projekt. Składają się na niego śledzenie zidentyfikowanych ryzyk – w szczególności monitorowanie spodziewanych symptomów, monitorowanie ryzyk pozostających, identyfikowanie nowych ryzyk, zapewnienie wykonania planów ryzyk oraz ocena ich efektywności w redukowaniu ryzyk. Zmiana statusu ryzyka lub wykrycie nowego ryzyka może spowodować konieczność ponownego planowania elementów lub całości projektu. Konieczna jest komunikacja z odpowiednimi udziałowcami żeby oceniać akceptowalność poziomów ryzyka. Jeśli przyjęto kilka alternatywnych wariantów zmniejszania ryzyka, jego właściciel musi podejmować decyzje. Realizowane czynności muszą być dokumentowane.

Konieczne jest wykonywanie okresowych przeglądów ryzyk, których głównym celem jest wykonanie statusu zidentyfikowanych ryzyk. Całość procesu monitorowania i śledzenia ryzyka powinna być audytowana, aby zweryfikować efektywność przyjętych metod zarządzania ryzykiem i sposobów ich realizacji. Konkretnymi źródłami nowych ryzyk może być analiza wartości uzyskanej i wykonywane prace techniczne (mające na celu wytworzenie produktów projektu). Wystąpienie nieprzewidywanych zdarzeń może spowodować konieczność planowania i wykonywania dodatkowych prac na bieżąco. Zgodnie z przyjętymi dla projektu procedurami może to spowodować konieczność przygotowania dokumentu żądania zmiany.

Na potrzeby następnych projektów PMI nakazuje tworzenie bazy ryzyk. Występujące zaburzenia w realizacji projektu powinny stanowić podstawę do modyfikacji kontrolnych list ryzyk (patrz podrozdz. Analiza ryzyka).

W CMMI praktyki związane ze sterowaniem ryzykiem znajdują się w dwóch obszarach. Elementem obszaru CMMI:Zarządzanie Projektami jest praktyka CMMI:Monitorowanie Ryzyk Projektu. Do obszaru CMMI:Zarządzanie Ryzykiem należy praktyka CMMI:Wdrożenie Planu Zmniejszania Ryzyka, podobna do PMI:Monitorowanie i Śledzenie Ryzyk. Status ryzyk ma być okresowo monitorowany, ich dokumentacja powinna być modyfikowana a znaczące zmiany w ryzykach powinny być komunikowane osobom zainteresowanym. Należy uruchamiać akcje związane z zarządzaniem ryzykiem, gdy ryzyko przekracza ustalone wcześniej wartości graniczne. W porównaniu z PMI jest to włączenie jednego więcej kroku pośredniego: sytuacja w projekcie, czyli symptomy ryzyka, muszą wcześniej być przetworzone na wartość parametru ryzyka, żeby możliwe było podjęcie akcji. Takie podejście wydaje się niepotrzebnie spowalniać akcje związane z ryzykiem. Realizowane akcje powinny być śledzone - należy wykonywać okresowe przeglądy akcji związanych z obsługą ryzyka, m. in w momencie osiągania kamieni milowych projektu (praktyka CMMI:Prowadzenie Przeglądów Kamieni Milowych). Należy w sposób ciągły zapewniać dostępność zasobów koniecznych do realizacji akcji. I w końcu miary związane z ryzykiem powinny być kolekcjonowane na potrzeby realizowanego i następnych projektów.

Czynność PRINCE:Monitorowanie Ryzyka zawiera sprawdzanie czy wystąpiły sygnały ostrzegawcze, sprawdzanie ich wykonania i efektywności oraz raportowanie. W PRINCE ciągle wyszukiwanie nowych ryzyk nie jest częścią monitorowania ryzyka, ale częścią wykonywanej w sposób ciągły czynności Identyfikacja Ryzyka. PRINCE:Sterowanie Akcjami Związanymi z Ryzykiem jest to powodowanie wykonania zaplanowanych akcji.

Inne obszary

Poza obszarem PMI:Zarządzanie Ryzykiem zagadnienia związane z ryzykiem znajdują się w obszarze PMI:Zarządzanie Zakresem – założenia przyjęte w procesie PMI:Inicjacja są jednym z głównych źródeł ryzyk. W obszarach PMI:Zarządzanie Kosztem i PMI:Zarządzanie Czasem zwraca się uwagę na obciążenie ryzykiem szacunków kosztu i czasu i na konieczność przewidzenia rezerw. Tak jak wszystkie obszary, PMI:Zarządzanie Ryzykiem jest wymieniane jako obiekt integracji w procesie PMI:Zarządzanie Integralnością.

CMMI sporo uwagi poświęca także ryzyku w innych niż CMMI:Zarządzanie Ryzykiem obszarach. Starannie powinny być obsługiwane ryzyka związane z dostarczycielami dóbr dla projektu oraz z włączaniem produktów kupionych „z półki”. Analizę ryzyka należy wykonać także przy projektowaniu ulepszeń w procesach organizacji (a więc poza projektami; proces CMMI:Innowacje i Wdrożenia Organizacyjne) – należy określić wszystkie możliwe ryzyka, na które narażone są proponowane ulepszenia. Poziom ryzyka jest jednym z podstaw decyzji w kwestii wdrożenia ulepszeń. Ryzyko jest także ważnym czynnikiem w obszarze CMMI:Ilościowe Zarządzanie Projektami – należy je uwzględniać przy tworzeniu zintegrowanego procesu projektu. W obszarze CMMI:Opracowywanie Wymagań zidentyfikowane ryzyka mogą być podstawą do opracowania nowych wymagań, mniej obciążonych ryzykiem. Głównym celem praktyk CMMI:Analiza Wymagań żeby Uzyskać Równowagę i CMMI:Walidacja Wymagań jest wykrycie i zmniejszenie ryzyka nieprzydatności produktu dla przyszłego użytkownika. Także w obszarze CMMI:Rozwiązania Techniczne przy wyborze optymalnego rozwiązania należy uwzględnić ryzyka. W obszarze CMMI:Analiza i Podejmowanie Decyzji należącym do obszaru CMMI:Wsparcie ryzyko związane z alternatywnymi rozwiązaniami jest jednym z podstawowych kryteriów podejmowania decyzji.

Porównanie zarządzania zakresem

Ogólne podejście

Celem każdego projektu jest wyprodukowanie produktu: towaru albo usługi. Żeby wyprodukować produkt, należy wykonać zestaw prac.

Według PMI zakres projektu jest to zestaw prac wykonywanych w ramach projektu. PMI wyróżnia dwa rodzaje prac wykonywanych w projekcie, połączone w następujące grupy procesów:

Procesy zorientowane na produkt (np. określenie wymagań, opracowanie produktu, wdrożenie...)
Procesy zarządzania projektem (np. zarządzanie ryzykiem, jakością, personelem....)

PRINCE dzieli prace na trzy następujące rodzaje:

Prace specjalistyczne, powodujące wytworzenie produktu
Prace zarządcze, związane z obsługą kontraktów, planów, raportów etc.,
Prace związane z zarządzaniem jakością.

Podział ten jest do pewnego stopnia wtórny, gdyż w PRINCE prace są widziane poprzez charakterystyki tworzonych produktów.

Przy definiowaniu planu CMMI mówi, że w projektach należy uwzględnić następujące rodzaje prac:

Tworzenie produktów projektu
Zmniejszanie ryzyka
Opracowywanie planów wspomagających (np. zarządzanie konfiguracją, zarządzaniem jakością)
Uzyskiwanie wiedzy i umiejętności (przez zespół projektowy)
Włączanie i zarządzanie produktami wytworzonymi poza projektem.

Ogólny podział, znajdujący odzwierciedlenie we wszystkich trzech standardach, to wyodrębnienie prac nastawionych na produkt oraz pozostałych – związanych z zarządzaniem. Podane definicje różnią się sposobem podziału prac zarządczych. PRINCE kładzie nacisk na zarządzanie jakością. Najnowszy ze standardów, CMMI, dużą wagę przykłada do zarządzania półproduktami wyprodukowanymi poza projektem. Wiąże się to z popularnością i przewidywanym rozwojem technik projektowania opartych na ponownym wykorzystaniu gotowych komponentów („component based design”). A PMI wszystkie obszary zarządcze traktuje sprawiedliwie czyli równo.

Struktura procesów zarządzania zakresem projektu

Wejściem do procesu zarządzania zakresem projektu jest zakres produktu, który pochodzi z obszaru Produkt / Technologia. Mówiąc inaczej, żeby zaplanować prace, trzeba wiedzieć, co ma być wyprodukowane.

W procesach związanych z zarządzaniem zakresem projektu można wyróżnić cztery główne grupy:

· Określenie podejścia do zarządzania zakresem

· Planowanie zakresu

· Wykonywanie prac

· Sterowanie zakresem

Określenie podejścia do zarządzania zakresem są to czynności związane z ustanowieniem standardów dotyczących zarządzania zakresem. Należy ustalić m. in. jakie techniki będą prowadziły do określenia zestawu prac, w jaki sposób zestaw prac będzie dokumentowany, jakie narzędzia będą wykorzystywane do zarządzania zakresem oraz jakie procedury będą stosowane do sterowania zakresem po jego zatwierdzeniu.

Planowanie zakresu jest to określenie zestawu prac projektu.

Wykonywanie prac obejmuje ich zlecanie, realizację oraz odbiór.

Sterowanie zakresem to powodowanie realizacji zaplanowanego zakresu oraz sposób wprowadzania zmian zakresu.

Rysunek 2 pokazuje ogólną strukturę procesów zarządzania zakresem projektu.

Rysunek 2. Struktura procesów zarządzania zakresem projektu

Do zarządzania zakresem – inaczej niż PMI – nie zaliczam procesu Inicjacja, który w przyjętej przeze mnie klasyfikacji znajduje się w obszarze Biznes.

W większości procesów PRINCE, w których występują zagadnienia związane z zarządzaniem zakresem, występują czynności należące do innych obszarów zarządzania projektami (np. zarządzanie czasem, zarządzanie kosztem).

Podobnie jak w PRINCE, wiele z praktyk powiązanych z zarządzaniem zakresem odnosi się także do innych obszarów zarządzania projektami.

Określenie podejścia

W procesie PRINCE:Ustanowienie Sposobów Sterowania Projektem należy wskazać uprawnienia decyzyjne oraz procedury służące do podejmowania decyzji. Należy się domyślać (nie jest to jasno powiedziane), że te uprawnienia i procedury dotyczą także zakresu projektu (rozumianego jako zestaw prac).

Proces PMI:Planowanie Zakresu w dużej części odnosi się do opisania produktów i biznesowych uwarunkowań projektu. Jego elementem, który dotyczy zarządzania zakresem projektu, jest określenie planu zarządzania zakresem. W dokumencie tym powinno być sprecyzowane, kto, kiedy i w ramach jakiej procedury ma prawo zmienić wcześniej ustalony zakres projektu.

W CMMI jest kilka elementów, które mogą być zaliczone do obszaru określenia podejścia do zarządzania zakresem. Podstawowe procesy z obszaru zarządzania projektami dość ogólnie odnoszą się do określenia strategii zarządzania projektem. W praktyce CMMI:Ustanowienie Budżetu i Harmonogramu należy ustanowić kryteria działań korygujących, które w trakcie realizacji projektu mogą być wykorzystane m. in. do modyfikacji zakresu projektu. W praktyce CMMI:Ustanowienie Planu Projektu określane są wszystkie czynności zarządcze, które mogą służyć m. in. do zarządzania zakresem. W praktyce CMMI:Plan Zaangażowania Udziałowców wskazuje się odpowiedzialności osób zaangażowanych w sterowanie projektem, a więc także odpowiedzialności za zarządzanie zakresem projektu.

Określaniu podejścia do zarządzania zakresem projektu mogą służyć niektóre praktyki wchodzące w skład zaawansowanych procesów zarządzania projektem. Praktyka CMMI:Ustanowienie Zdefiniowanego Procesu Projektu nakazuje m. in. wybranie i dostosowanie do potrzeb realizowanego projektu standardowych procesów obowiązujących w macierzystej organizacji. Jednym z takich procesów powinno być monitorowanie i sterowanie procesem, które powinno zawierać proces zarządzania zakresem projektu.

Za element zarządzania zakresem projektu można uznać obszar procesów CMMI:Ilościowe Zarządzanie Projektami. W obszarze tym na podstawie uzyskiwanych miar mogą być definiowane zmiany w zestawie czynności służących do realizacji projektu. A więc określenie sposobu ilościowego zarządzania projektami jest elementem określenia podejścia do zarządzania zakresem w przyjętej przeze mnie klasyfikacji. Pierwszą składową określenia podejścia jest praktyka CMMI:Ustalenie Celów Projektu. Jej wynikiem jest zestaw celów dotyczących np. funkcjonalności, niezawodności, pielęgnowalności, których miary będą wykorzystywane w ilościowym zarządzaniu. Następnie należy wskazać podprocesy, które mogą podlegać zarządzaniu statystycznemu – dzieje się to w praktyce CMMI:Skomponowanie Zdefiniowanego Procesu. Ostateczny wybór tych podprocesów odbywa się w praktyce CMMI:Wybór Podprocesów Do Zarządzania Statystycznego. Po wybraniu procesów określane są miary, które będą stosowane – praktyka CMMI:Wybór Miar i Technik Analitycznych. Dla tych miar i procesów w praktyce CMMI:Zastosowanie Metod Statystycznych do Zrozumienia Odchyleń określane są dopuszczalne granice tolerancji. Określenie tych granic jest elementem definiowania podejścia do zarządzania zakresem, gdyż w wyniku ich przekroczenia mogą być wykonywane prace planistyczne, które w szczególności mogą zmienić zakres projektu.

Najwięcej uwagi problemowi określenia podejścia do zarządzania zakresem projektu poświęca CMMI – model nakazuje zaplanowanie kryteriów i miar podejmowania wszelakich akcji korygujących. Podstawą do zmiany zakresu prac mogą być ściśle określone parametry realizacji procesów. PMI ogólnie nakazuje istnienie procedury zarządzania zakresem. PRINCE podchodzi do problemu podobnie jak PMI – nakazuje realizację procesu, w wyniku którego zostaną przydzielone uprawnienia do zarządzania projektem – a więc domyślnie także do wprowadzania zmian w zakresie projektu. Z faktu, że PRINCE jest gotową metodą zapewne wynika, że rzadko w tym standardzie uwzględniane są procesy służące do jego modyfikacji.

Planowanie zakresu

W PMI w procesie PMI:Definiowanie Zakresu, gdy określone są produkty projektu, na ich podstawie należy zdefiniować WBS (ang. Work Breakdown Structure; czasami używany jest polski skrót: SPP – Struktura Podziału Pracy). WBS na tym poziomie opracowywania opisuje prace konieczne do wykonania poszczególnych produktów i półproduktów. WBS ma zawsze strukturę hierarchiczną. Pierwszy poziom WBS to technologiczne fazy projektu, wynikające zwykle ze standardowego cyklu produkcji produktu, oraz wyróżniane jako jeden blok prac, prace zarządcze. Poziom szczegółowości planowania na tym etapie jest wyznaczany przez zestaw koniecznych do wytworzenia produktów i półproduktów. Na przykład dla fazy analizy w projekcie, który jest podzielony na obszary jednostkami planowania prac mogą być model funkcji, model danych, model wymagań – dla poszczególnych obszarów. Planowanie prac zwykle odbywa się z wykorzystaniem narzędzi programistycznych, z których najpopularniejszym jest zapewne MS Project. Dla wielu typów projektów, np. dla deweloperskich projektów informatycznych, istnieją standardowe cykle produkcji (cykle życia systemu), z których najbardziej znane to model kaskadowy, model spiralny czy model kontrolowanych iteracji.

Podstawowym elementem WBS potrzebnym kierownikowi projektu pakiet prac – zestaw prac, które są jednocześnie zlecane i odbierane. Planowanie zakresu w procesie PMI:Definiowanie Zakresu odbywa się właśnie na poziomie pakietu prac. Na przykład, przy opracowywaniu wymagań w projekcie informatycznym, pakietem prac może być wykonanie modelu procesów analizowanej dziedziny. Pracami wykonywanymi w ramach takiego pakietu prac są spotkania z przyszłymi użytkownikami systemu, wprowadzenie uzyskanych informacji do narzędzia modelującego, przygotowanie dokumentu zawierającego model procesów. Planowanie na poziomie prac jest potrzebne kierownikom zespołów technicznych.

Ten niższy poziom planowania prac odbywa się w procesie PMI:Definiowanie Czynności. Zwykle zejście do tego poziomu szczegółowości jest możliwe tylko dla najbliższej fazy.

Ostatecznym wynikiem planowania zakresu prac jest WBS doprowadzony do poziomu czynności. Możliwe jest uzupełnianie WBS o dodatkowe informacje uzupełniające specyfikację planowanych prac.

Proces określania zestawu przewidywanych do wykonania prac w PRINCE jest bardzo rozbudowany. Planowanie zakresu jest mocno powiązane z planowaniem czasu i kosztu. Określenie tych atrybutów pakietów prac lub prac odbywa się bezpośrednio po zaplanowaniu pracy. W procesie PRINCE:Przygotowanie Konspektu Projektu określa się najbardziej ogólne wytyczne dotyczące zestawu przewidywanych prac – na poziomie potrzebnym do określenia stwierdzenia, czy projekt jest wykonalny. W procesie PRINCE:Definiowanie Podejścia do Projektu określane są opcje przebiegu prac i wybierana jest spośród nich optymalna. Jednocześnie w procesie PRINCE:Planowanie Fazy Inicjacji opracowywany jest zestaw prac, które mają być wykonane w pierwszej fazie – inicjacji projektu. Opisy prac (ogólny dla całego projektu i dokładny dla fazy inicjacji) są rozpatrywane i ewentualnie zatwierdzane przez Radę Projektu w procesie PRINCE:Zatwierdzenie Projektu jako elementy większych dokumentów – Konspektu Projektu i Planu Fazy Inicjacji. Akceptacja planów prac w tym momencie objawia się zezwoleniem przez Radę Projektu na wykonanie inicjacji projektu.

Zgodnie z przyjętą dla PRINCE kategoryzacją prac, konieczne jest zaplanowanie prac trzech rodzajów. Prace związane z zarządzaniem jakością i prace związane z wykonaniem produktu są planowane w procesie PRINCE:Planowanie Projektu. Należy zwrócić uwagę, że w procesie PRINCE:Planowanie Jakości nie odbywa się określenie zestawu prac, a tylko opisanie wymagań na system jakości. Planowanie czynności związanych z zarządzaniem projektem (np. monitorowanie) odbywa się w procesie PRINCE:Ustanowienie Sposobów Sterowania Projektem, który jest wykonywany po procesie PRINCE:Planowanie Projektu. Ostateczna wersja planu prac jest wynikiem wykonania procesu PRINCE:Ponowna Ocena Uzasadnienia Biznesowego i Ryzyk – stwierdzenie zbyt dużego poziomu ryzyka może spowodować zmiany w podejściu do realizacji projektu.

Ostatecznie ustalony na poziomie Kierownika Projektu Plan Projektu, zawierający opis prac jest przekazywany do procesu PRINCE:Zatwierdzenie Projektu, gdzie Rada Projektu podejmuje decyzję w kwestii zatwierdzenia projektu (w tym proponowanych decyzji dotyczących zestawu wykonywanych prac).

Równolegle z procesami inicjacji projektu w procesie PRINCE:Planowanie Fazy Kierownik Projektu wykonuje prace mające na celu opracowanie szczegółowego zestawu prac pierwszej fazy projektu. Proces ten jest wykonywany zawsze przed przejściem do następnej fazy. Kierownik przekazuje ten plan Radzie Projektu do procesu PRINCE:Zatwierdzenie Planu Fazy lub Wyjątków. Rada ma uprawnienia do akceptacji tego planu.

W modelu CMMI praktyki związane z planowaniem zakresu zgrupowane są w trzech procesach CMMI:Planowanie Projektu, CMMI:Zintegrowane Zarządzanie Projektami i CMMI:Ilościowe Zarządzanie Projektami.

Praktyka CMMI:Szacowanie Zakresu Projektu pobiera na wejściu architekturę produktu i produkuje WBS, zawierający wszystkie rodzaje prac. Niezależnie od tego, że wg. CMMI WBS ewoluuje, już w pierwszym procesie związanym z zarządzaniem zakresem zestaw prac należy określić na poziomie dostatecznym do oszacowania harmonogramu. Na podstawie WBS w praktyce CMMI:Określenie Cyklu Życia Projektu określany jest podział projektu na fazy. Praktyka ta nie wprowadza nowych prac do wykonania, ale strukturyzuje WBS na najwyższym poziomie koniecznym do podejmowania zasadniczych decyzji o przebiegu projektu.

Po utworzeniu planu projektu w procesie CMMI:Ponowne Rozważenie Zaangażowanej Pracy i Zasobów możliwe jest wykonanie modyfikacji zaplanowanego zestawu prac – na przykład ze względu na brak środków finansowych może się okazać, że konieczne będzie zmniejszenie zakresu wykonywanych prac.

W zaawansowanych organizacjach plan projektu może być ustalany na podstawie wcześniej przyjętych i obowiązujących standardów. W praktyce CMMI:Ustanowienie Zdefiniowanego Procesu Projektu najpierw, spośród dostępnych w firmowej bibliotece, wybierany jest model cyklu życia najbardziej odpowiedni dla realizowanego projektu. Następnie wybierane są procesy, które mogą służyć do realizacji tego cyklu życia. Zwykle procesy te nie do końca opowiadają szczegółowym wymaganiom projektu, więc – zgodnie z ogólnymi zasadami modyfikowania procesów – należy zmodyfikować lub uzupełnić wybrane procesy. Zwróćmy uwagę, że jeśli organizacja nie ma przyjętych standardów, najpierw ustalane są czynności, a później grupowane są one w fazy. Jeśli istnieją w firmie standardowe modele cyklu życia, praca jest łatwiejsza – najpierw wybierany jest ogólny wzorzec (model cyklu życia), a następnie wykonywane są niezbędne modyfikacje szczegółowe.

W organizacjach, które projektami zarządzają na podstawie danych ilościowych, wybór podprocesów przeznaczonych do włączenia do procesu projektu odbywa się w praktyce CMMI:Skomponowanie Zdefiniowanego Procesu. Kryteria decydujące o włączeniu podprocesów są sformułowane w sposób mierzalny, na podstawie przyjętych celów projektu, wymagań klienta, dostępności danych i tp. Ważnym kryterium jest wcześniejsza stabilność procesów, która powinna zagwarantować ich mierzalną przewidywalność. Kryteria te są stosowane do zbudowania pełnego procesu realizacji projektu.

We wszystkich trzech standardach występują pojęcia faza, pakiet prac, praca. Poza PRINCE obydwa standardy opierają zakres projektu na pojęciu WBS. Wydaje się, że PRINCE za wszelką cenę chcę uniknąć wprowadzenia pojęcia dekompozycji prac (zastępując to pojęcie dekompozycją produktu). Nawet w podawanych przykładach PRINCE podaje tylko jednopoziomowe zestawy prac. Można przyjąć, że każda praca jest jednoznacznie identyfikowalna przez jej produkt (i na odwrót), czyli istnieje równoważność pracy i produktu, ale jest to nienaturalne podejście. O ile w pracach technicznych rzeczywiście intuicyjnie ważniejszy jest produkt, to w dziedzinie zarządzania i jakości wydaje się, że ważniejsze są same prace (chociaż muszą one zawsze dać jakieś wyniki). Kolejna różnica pomiędzy podejściem PMI i CMMI a podejściem PRINCE to oparcie planowania zakresu projektu w tych dwóch pierwszych standardach na wcześniejszych doświadczeniach organizacji realizującej projekt. W PRINCE, który opiera się na produktach, byłoby to mniej możliwe. W szczególności takie podejście jest bardzo mocno akcentowane w CMMI – w standardzie tym podstawą określenia podejścia do zarządzania projektami jest ciągłe doskonalenie realizowanych procesów, a więc oparcie się na wcześniejszych pracach organizacji. W zamian za to PRINCE bardzo dokładnie precyzuje, w których procesach powinny być podejmowane akcje związane z planowaniem zakresu projektu.

Wykonywanie prac

W PMI do zarządzania wykonywaniem prac służą dwa procesy. PMI:Wykonanie Planu Projektu jest elementem obszaru zarządzania integralnością, zaś PMI:Weryfikacja Zakresu należy do obszaru zarządzania zakresem.

Częścią składową procesu PMI:Wykonanie Planu Projektu jest system zlecania prac. W każdym projekcie musi być jednoznacznie określone, kto komu i w jaki sposób ma prawo zlecić prace do wykonania. Uzyskane wyniki prac są przekazywane do procesu PMI:Weryfikacja Zakresu w celu podjęcia decyzji w kwestii ich akceptacji. W procesie tym realizowane są czynności mające na celu ustalenie, czy wyniki są zgodne ze stawianymi im wymaganiami (np. pomiary, przeglądy, audity). Wynikiem tych czynności jest decyzja w sprawie akceptacji produktu. Decyzja taka może być warunkowa.

W PRINCE wykonywanie prac jest opisywane z dwóch perspektyw: Kierownika Projektu, zlecającego pakiet prac oraz Kierownika Zespołu odpowiedzialnego za realizację tych prac.

Kierownik Projektu realizując proces PRINCE:Zlecanie Pakietu Prac musi zagwarantować właściwe warunki wykonania prac. Po jego stronie leży w szczególności zapewnienie potrzebnych zasobów, sprawdzenie opisu prac i uzyskanie przekonania, że osoba przyjmująca zadanie zna cele i warunki wykonania prac. Osoba przyjmująca pracę do wykonania (Kierownik Zespołu) reprezentuje podlegające jej osoby i jest odpowiedzialna za wykonanie procesu PRINCE:Akceptacja Pakietu Prac. W procesie tym, w imieniu wykonawców negocjowane są szczegółowe warunki wykonania i dostarczenia produktu. Określane są sposoby raportowania postępu prac. Kierownik Zespołu musi rozumieć, kto i w jaki sposób będzie odbierał prace projektu. Musi także przygotować szczegółowy plan sposobu realizacji pakietu prac.

Po zaakceptowaniu pakiet prac pod kierunkiem Kierownika Zespołu jest realizowany w procesie PRINCE:Wykonanie Pakietu Prac. Głównymi zadaniami Kierownika Zespołu są monitorowanie statusu prac i raportowanie ich w ustalony sposób Kierownikowi Projektu, ewidencjonowanie wykorzystanych zasobów i szacowanie zasobów niezbędnych do ich zakończenia oraz zapewnienie jakości prac. Końcowym elementem zarządzania dostarczaniem produktu jest wykonanie procesu PRINCE:Dostarczenie Pakietu Prac. Konieczne jest uzyskanie zatwierdzenia prac przez wszystkie przewidywane kontrole jakości i przekazanie wyników prac, które w procesie PRINCE:Przyjmowanie Ukończonego Pakietu Pracy muszą być przyjęte przez Kierownika Projektu. Kierownik projektu jest odpowiedzialny za sprawdzenie zgodności produktu z przyjętymi wymaganiami i standardami. Produkt jest włączany do kontrolowanego przez system zarządzania konfiguracją zbioru gotowych prac.

W modelu CMMI niezbyt wiele uwagi poświęca się standardowej, bezproblemowej realizacji planu projektu. Praktyka CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu nakazuje wykorzystywanie umieszczonych w zintegrowanym planie kryteriów do rozpoczynania i kończenia zadań. Praktyka ta jest elementem zaawansowanego procesu CMMI:Zintegrowane Zarządzanie Procesami. Na poziomie podstawowym nie udało mi się znaleźć żadnej praktyki odnoszącej się do zlecania i wykonywania pakietów prac.

Minus dla CMMI. Standard prawie nic nie mówi (poza jednym zdaniem) o standardowym sposobie realizacji zaplanowanych prac. Według PMI prace powinny być wykonane i zatwierdzone. Ważny proces zlecania, przyjmowania, wykonywania i odbierania prac najdokładniej jest opisany w standardzie PRINCE.

Sterowanie zakresem

Do sterowania zakresem służy proces PMI:Sterowanie Zmianami Zakresu. Zasadniczą częścią tego procesu są narzędzia zarządzania zakresem, czyli procedury podejmowania odpowiednich decyzji. Główną podstawą zmian zakresu są raporty postępu prac. Żądania zmian mogą pojawiać się także z innych powodów, na przykład zmian uregulowań prawnych czy błędów popełnionych w planowaniu zakresu projektu. Wynikiem analizy postępów projektu czy żądania zmiany nie musi być zmiana zakresu – alternatywnie podejmowane mogą być decyzje o wykonaniu działań korygujących mających na celu realizację projektu zgodnie z wcześniej przyjętym zakresem. PMI zwraca – na dość ogólnym poziomie – uwagę, że z zaburzeń w realizacji planu należy wyciągać wnioski na przyszłość. Zarządzanie zmianami zakresu musi być zintegrowane z innymi obszarami zarządzania – przede wszystkim z zarządzaniem czasem i kosztem: modyfikacja przyjętego zakresu zwykle ma efekty w harmonogramie i / lub budżecie realizowane projektu.

PRINCE ma bardziej rozbudowany niż PMI sposób zarządzania zmianami zakresu. Najbardziej codziennym procesem, którego wynikiem może być zmiana zakresu projektu jest PRINCE:Przegląd Statusu Fazy. Zasadniczym celem tego procesu jest sprawdzenie postępu prac. Wstępna ocena napotkanych problemów, razem z proponowanym zestawem ewentualnych akcji przeciwdziałających musi być wykonana w procesie przed przeglądem statusu fazy w procesie PRINCE:Badanie Zagadnień Projektu. Jeśli Kierownik Projektu przewiduje, że w wyniku jego działań faza i projekt pozostaną w granicach tolerancji, może sam podjąć decyzję o wykonaniu procesu PRINCE:Podjęcie Akcji Korygujących. Jeśli granice tolerancji wyznaczone dla fazy są zagrożone, konieczna jest wykonanie procesu PRINCE:Eskalowanie Zagadnień Projektu, żeby poinformować o zagrożeniu Radę Projektu i uzyskać jej opinię dotyczącą dalszego przebiegu prac. PRINCE:Podjęcie Akcji Korygujących polega na przeanalizowaniu przyczyn zaburzeń, ustaleniu możliwych akcji korygujących, wyborze najlepszej z nich (być może z pomocą Rady Projektu), włączeniu akcji do Planu Fazy i uruchomieniu wykonywania akcji. Również w trakcie procesu PRINCE:Eskalowanie Zagadnień Projektu Kierownik Projektu musi przeanalizować sytuację i zaproponować rozwiązania w postaci Planu Wyjątków – doprowadzającego projekt do zaplanowanych ram (wtedy ze strony Rady Projektu wystarczy wykonanie procesu PRINCE:Bieżące Zalecenia) lub określający nowy sposób działania. Tworzenie Planu Wyjątków odbywa się w procesie PRINCE:Tworzenie Planu Wyjątków. Plan Wyjątków musi być zaakceptowany przez Radę Projektu w procesie PRINCE:Zatwierdzenie Planu Fazy lub Wyjątków[1]. Po utworzeniu Plan Wyjątków musi być, poprzez proces PRINCE:Modyfikowanie Planu Projektu włączony do Planu Projektu. Ten sam proces jest wykorzystywany do włączania do Planu Projektu uszczegółowionego planu następnej fazy (w czasie kończenia fazy poprzedniej).

Sterowanie zakresem projektu w CMMI na poziomie podstawowym odbywa się w procesie CMMI: Monitorowanie i Zarządzanie Projektem. Wejściem do praktyk zarządzania zakresem projektu są wyniki monitorowania różnych aspektów projektu (kosztu, czasu, ustaleń, ryzyk....) przeglądy postępu projektu oraz przeglądy osiągania kamieni milowych.

W wyniku wykonania praktyki CMMI:Analiza Problemów wskazywane są te problemy, które wymagają podjęcia akcji korygujących. Pojęcie akcji korygującej ma w CMMI szersze znaczenie niż w PMI i PRINCE – są to wszystkie działania podejmowane w celu usunięcia problemów, także te, które wymagają znaczących zmian planów. Dla wytypowanych problemów w praktyce CMMI: Podejmowanie Akcji Korygujących ustalany jest dalszy przebieg działań, który może dotyczyć np. zmiany określenia pracy, zmiany wymagań czy zmiany procesów. Konieczne może być ponowne wykonanie procesu PRINCE:Planowanie Projektu. Akcje korygujące muszą być uzgodnione z odpowiednimi udziałowcami. Realizacja akcji korygujących jest specjalnie śledzona aż do ich pełnego wykonania (poprzez praktykę CMMI:Zarządzanie Akcjami Korygującymi).

Na zestaw realizowanych prac wpływ mogą mieć także wyniki procesu CMMI:Zarządzanie Wymaganiami. W praktyce CMMI:Identyfikacja Niespójności pomiędzy Pracą Projektu a Wymaganiami odbywa się przegląd planowanych prac projektu i zestawu wymagań. W przypadku wykrycia niespójności należy ustalić ich przyczyny i zmienić wymagania lub zaproponować akcje korygujące. Akcje muszą być włączone do planu projektu.

Zaawansowane procesy, w których występują elementy zarządzania zakresem projektu to CMMI: Zintegrowane Zarządzanie Projektami i CMMI:Ilościowe Zarządzanie Projektami. Celem należącej do pierwszego z nich procesu CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu jest monitorowanie przebiegu procesu projektu i ewentualne modyfikowanie planów (w tym planu prac czyli WBS). Modyfikacje takie powinny być wykonywane, gdy mierzone parametry przebiegu projektu wykazują znaczące odchylenia od przyjętych założeń.

W procesie CMMI:Ilościowe Zarządzanie Projektami występują trzy praktyki, których wynikiem może być modyfikacja zakresu prac. Praktyka CMMI:Zarządzanie Efektywnością Projektu jest częścią statystycznego zarządzania procesem projektu. Praktyka ta jest podobna do praktyki CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu, ale podstawą do planowania akcji korygujących są odchylenia od ustalonych parametrów realizacji podprocesów. Praktyka odnosi się do całości realizowanego procesu. Wynikiem tej praktyki może być zmiana zaplanowanego procesu. Następne dwie praktyki odnoszą się do tych podprocesów, które w praktyce CMMI:Wybór Podprocesów Do Zarządzania Statystycznego zostały wybrane do zarządzania statystycznego. Praktyka CMMI:Zastosowanie Metod Statystycznych do Zrozumienia Odchyleń nakazuje przeanalizowanie i zrozumienie powodów odchyleń. W jej wyniku powinny być zaplanowane akcje korygujące, które nie zmieniają ogólnej struktury realizowanego procesu. Poważniejsze skutki może mieć praktyka CMMI:Monitorowanie Efektywności Wybranych Podprocesów. Jej celem jest zrozumienie całości możliwości procesów złożonych ze składowych (a nie tylko poszczególnych składowych). Wynikiem tej praktyki może być zmiana struktury złożonego procesu, a więc włączenie do planu projektu nowych podprocesów – a nie tylko doprowadzenie podprocesów do właściwego działania.

Rozbudowane techniki zarządzania zakresem to zaleta podejścia CMMI. Procedury zarządzania zakres najpełniej opisane są w PRINCE. PMI mówi ogólnie, że powinna być realizowana procedura zarządzania zakresem projektu.

Porównanie zarządzania jakością

Ogólne podejście

Każda czynność wykonywana w projekcie może wpłynąć na jakość jego produktów. Dlatego przy opisywaniu podejścia do zarządzania jakością należy tak sprecyzować opisywany zakres, żeby zarządzanie jakością nie było równoważne całej dziedzinie zarządzania projektami. Należy określić zestaw działań poświęconych specyficznym czynnościom związanym z osiąganiem przez produkt projektu cech powodujących spełnianie przezeń stawianych mu wymagań. Do działań takich zalicza się zwykle przeglądy, testy, audity, weryfikacje, walidacje, czynności związane z ich planowaniem oraz czynności usprawniające realizację procesów. Za część składową obszaru zarządzania jakością zwykle uważa się zarządzanie konfiguracją, wykonywanie pomiarów i analiz oraz zarządzanie zmianami. W moim podejściu zarządzanie konfiguracją, podobnie jak wykonywanie pomiarów i analiz jest dobrze wyodrębnionym osobnym obszarem zarządzania jakością. Obszary te są omawiane w osobnych rozdziałach. Natomiast zarządzanie zmianami jest zawsze powiązane z obszarem, którego zmiany dotyczą.

PMI stosuje definicję jakości zapożyczoną z normy 8402, według której jakość jest to ogół charakterystyk produktu lub usługi odnoszących się do jego możliwości spełniania jawnie określonych lub domyślnych potrzeb. Zasadniczym problemem jest przekształcenie domyślnych potrzeb w wymagania, co odbywa się w obszarze zarządzania zakresem.

PRINCE wykorzystuje tę samą definicję jakości i także zwraca uwagę na wymagania domyślne, które według tej metody nie powinny być uwzględniane, gdyż mogą prowadzić do niejednoznaczności. Ponadto uściśla się dwa pojęcia:

Jakość produktu – jego przydatność do celów, dla których jest przeznaczony
Jakość procesu – jego możliwość dostarczania produktów w sposób wolny od problemów

CMMI podaje definicję, zbliżoną do zawartej w normie ISO 9000:2000, według której jakość jest to możliwość spełniania wymagań klienta przez zasadnicze charakterystyki produktu, składowej produktu lub procesu. Wymagania klienta są definiowane na podstawie potrzeb wszystkich udziałowców projektu. Potrzeby, oczekiwania, ograniczenia, interfejsy, pomysły operacyjne są analizowane, równoważone, wypracowywane i dokumentowane w celu utworzenia wymagań klienta, które muszą być udokumentowane.

Podstawowym celem procesu CMMI:Zapewnienie Jakości Procesu i Produktu jest dostarczenie personelowi i kierownictwu projektu obiektywnego wglądu w procesy i produkty. Jest to bardzo konkretny, zoperacjonalizowany cel zapewnienia jakości. W innych procesach, w których występują czynności związane z zarządzaniem jakością, oczywiście zachowany jest także „tradycyjny” cel – uzyskanie pożądanej jakości procesów i produktów.

Wszystkie trzy definicje opierają definicję jakości na wymaganiach. Problemem przy definiowaniu jakości są wymagania niejawne. PRINCE wyklucza wymagania niejawne z prac projektowych. PMI nakazuje przekształcić te wymagania w wymagania udokumentowane, czyli jawne. CMMI w ogóle nie zajmuje się wymaganiami niejawnymi. Różnica w podejściach PRINCE i PMI a CMMI występuje także w kwestii źródła wymagań. Według tych dwóch pierwszych standardów źródłem wymagań jest klient. Natomiast według CMMI źródłami wymagań są wszyscy udziałowcy projektu. Jeśli wykonawca (lub inny udziałowiec projektu, np. autor regulacji prawnych, w celu realizacji których projekt jest realizowany) nie zgodzi się na realizację wymagań, to bezsensowne jest włączanie ich do zestawu wymagań projektu. Dodatkową cechą odróżniająca podejście CMMI od dwóch pozostałych i wzbogacającą spojrzenie na problemy zarządzania jakością jest wskazanie dostarczenia wglądu zainteresowanym osobom w przebieg procesów i produkty jako celu zapewnienia jakości. Cel ten należy rozumieć jako pośrednie, ale bardzo ważne, wpływanie na jakość – kierownictwo powinno wykorzystać uzyskane informacje do właściwego sterowanie przebiegiem projektu.

Struktura procesów zarządzania jakością

W procesach związanych z zarządzaniem jakością można wyróżnić cztery główne grupy:

· Planowanie jakości

· Zapewnienie jakości

· Kontrola jakości

· Ulepszanie, którego wyróżnioną podgrupą jest

o Naprawianie

Planowanie jakości obejmuje projektowanie sposobu wykonania czynności z trzech pozostałych grup.

Zapewnienie jakości są to czynności mające na cele realizację procesów projektu w sposób gwarantujący uzyskanie akceptowalnych produktów.

Kontrola jakości są to sprawdzenia – na różnych poziomach organizacyjnych – czy uzyskane produkty spełniają stawiane przed nimi wymagania.

Ulepszanie są to czynności mające na celu poprawę parametrów jakościowych. Ulepszanie może się odnosić zarówno do procesów jak i do produktów pracy. Ulepszanie procesów z założenia odnosi się do procesów powtarzalnych. W trakcie realizacji projektów powtarzają się czynności zarządcze (np. sprawozdawczość, ocena ryzyka, przeglądy), rzadziej zaś procesy techniczne – realizacja procesu wytwórczego w projekcie składa się zwykle z ciągu niepowtarzalnych czynności. Ulepszanie może ale nie musi być skutkiem wykonania procesów zapewnienia lub kontroli jakości.

Szczególnym rodzajem ulepszania jest naprawianie (często nazywane podejmowaniem akcji korygujących), czyli czynności wykonywane na obiektach nie spełniających kryteriów jakości, mające na celu uzyskanie akceptowalnych wartości parametrów jakościowych. Naprawianie zawsze jest wynikiem kontroli jakości.

Rysunek 2 pokazuje ogólną strukturę procesów zarządzania jakością.

Rysunek 3. Struktura procesów zarządzania jakością

PMI w zakresie zarządzania jakością powołuje się na standardy ISO. Do zarządzania jakością zaliczane są procesy potrzebne do zapewnienia że projekt spełni potrzeby dla których został podjęty. Procesy te, zgodnie z definicją z normy ISO 8402, zawierają wszystkie ogólne funkcje zarządcze, które wyznaczają politykę jakości, cele i odpowiedzialności i implementują je przez środki takie jak planowanie jakości, zapewnienie jakości, kontrola jakości i poprawa jakości w ramach systemu jakości.

W PRINCE zarządzanie jakością można podzielić na dwa podobszary. Pierwszy z nich to zarządzanie jakością w procesach i technikach zarządczych zdefiniowanych przez samą metodę. Problemy związane z jakością w tym podobszarze są w moim opracowaniu opisywane pośrednio lub bezpośrednio w obszarach, do których te procesy i produkty należą. Drugi podobszar – omawiany w niniejszym rozdziale – to zarządzanie jakością związane z procesami tworzonymi w ramach metody (głownie prace związane z wytworzeniem produktu, ale także inne procesy utworzone na potrzeby danego projektu).

Wyodrębnioną, osobno opisywaną, właściwie jedyną, techniką związaną z zarządzaniem jakością jest w PRINCE Przegląd Jakości.

Techniki zarządzania jakością występują w modelu CMMI w trzech grupach:

· Procesy, których głównym lub jedynym celem jest zarządzanie jakością, np. proces weryfikacji

· Czynności związane z zarządzaniem jakością w pozostałych procesach i praktykach, np. określenie celów jakościowych w procesie planowania projektu,

· Kryteria jakości procesu i jego produktów umieszczone w opisie każdego procesu.

Dwie pierwsze grupy są omawiane w niniejszym rozdziale, trzecia grupa jest omawiana pośrednio lub bezpośrednio przy opisywaniu procesów, do których odnoszą się te kryteria.

Osiem spośród dwudziestu dwóch procesów składających się na model CMMI należy do pierwszej z tych grup – ich główny cel należy do obszaru zarządzania jakością. Procesy te z punktu widzenia obszaru zastosowania można podzielić na dwie grupy:

· Procesy nastawione na ulepszanie sposobów realizacji projektów na poziomie organizacji

· Procesy będące składowymi zarządzania poszczególnymi projektami

Do pierwszej z tych grup, omawianej w obszarze Procesy w Organizacji, należą:

1. Nastawienie na Proces Organizacyjny

2. Efektywność Procesu Organizacji

3. Innowacje i Wdrożenia Organizacyjne

Elementem zarządzania projektami są:

4. Ilościowe Zarządzanie Projektem

5. Weryfikacja

6. Walidacja

7. Zapewnienie Jakości Procesu i Produktu

Procesem należącym do obydwu tych grup jest:

8. Analiza Przyczyn i Usprawnianie

Poza procesami mającymi poprawę jakości jako swój główny cel, działania związane z jakością występują w wielu – można powiedzieć, że w większości – innych procesów.

Wszystkie trzy standardy zwracają należytą uwagę na problemy związane z jakością. Najbardziej przesycony czynnościami związanymi z zarządzaniem jakością, a w szczególności pracami mającymi na celu ulepszanie sposobu realizacji procesów, jest model CMMI. Znaczącą wagę problemom zarządzania jakością poświęca PRINCE – należy przede wszystkim zwrócić uwagę na kryteria jakości określone dla wszystkich procesów zarządczych i produktów. W PMI zarządzanie jakością jest osobnym obszarem, słabo zintegrowanym z pozostałymi obszarami zarządzania projektami.

Planowanie jakości

Według definicji podanej w procesie PMI:Planowanie Jakości jest to określenie standardów jakości obowiązujących w projekcie oraz sposobów osiągania tych standardów. Podstawą do planowania jakości jest ogólna polityka jakości firmy, czyli ogólne nastawienie firmy do problemów związanych z jakością, wyrażone przez najwyższe kierownictwo firmy. Polityka ta zawsze musi być przystosowana do konkretnego projektu. Czynnikami, które wpływają na dostosowanie polityki jakości do projektu są zakres projektu, opis produktu oraz standardy i regulacje adekwatne do zakresu projektu. Regulacje są to „twarde” normy prawne organizacyjne i tp. Standardy są to wytyczne dotyczące sposobu pracy oraz własności produktu. Przy planowaniu jakości należy uwzględnić wyniki innych planowań, np. planowania zaopatrzenia (firma dostarczająca podprodukty do naszego projektu może mieć własny system jakości).

Poza systemami jakości – własnym i zaangażowanych firm – źródłem danych do planowania jakości są inne analogiczne projekty, które mogą dostarczyć wzorów działań prowadzących do uzyskania pożądanej jakości. PMI sugeruje stosowanie technik graficznych do planowania jakości, np. diagramy Ishikawy czy schematy blokowe mogą dostarczyć wglądu w naturę procesu projektu i mogą pomóc w wypracowaniu właściwego podejścia. Takie techniki mogą być użyteczne we wszystkich obszarach zarządzania. Można sobie wyobrazić uzyskanie wglądu w proces bez prezentacji graficznej. Do planowania jakości mogą być wykorzystane „eksperymenty”. W rozumieniu PMI za eksperyment może być uznane rozważenie procesu prowadzący do podjęcia decyzji personalnych mających na celu podniesienie jakości (wybór bardziej wykwalifikowanego personelu). Tak rozumiane eksperymenty mogą być stosowane w każdym obszarze zarządzania (np. komunikacja, koszt....). Przy planowaniu jakości należy zawsze uwzględnić koszty. PMI dzieli koszty związane z jakością na trzy grupy: koszty zapobiegania, koszty oceny i koszty błędów – te ostatnie są dzielone na zewnętrzne i wewnętrzne. Zyski muszą przewyższać nakłady poniesione na zarządzanie jakością.

Wynikiem planowania jakości powinien być plan zarządzania jakością. PMI nie podaje opisu jego zawartości – mówi tylko, że musi on opisywać struktury organizacyjne, odpowiedzialności, procedury, procesy i zasoby konieczne do wdrożenia zarządzania jakością. Jakość musi być zoperacjonalizowana – dla każdej cechy jakościowej należy podać jej metrykę, umożliwiającą jednoznaczne zmierzenie, czy wymagana wartość została w projekcie uzyskana. Do oceny procesów służą listy kontrolne – zestawy pytań dotyczących wykonania elementów procesu lub spełniania przez proces określonych warunków. Wyniki planowania mają skutki w innych obszarach zarządzania, np. w zarządzaniu personelem (konieczność zatrudnienia osób do zarządzania jakością), zarządzaniu zaopatrzeniem (określenie kryteriów jakości dla nabywanych produktów lub usług) czy zarządzaniu kosztem.

Jakość musi być mierzalna. Dla każdego projektu należy przygotować zestaw miar, które będą wyliczane w trakcie jego realizacji. Najprostszymi miarami jakości produktu deweloperskiego projektu informatycznego jest liczba błędów stwierdzonych w czasie eksploatacji systemu i czas pomiędzy wystąpieniem błędów.

W PRINCE planowanie jakości zaczyna się już w czasie wstępnego planowania projektu w procesie PRINCE:Opracowanie Konspektu Projektu. Dyrektor projektu powinien uwzględnić oczekiwania klienta odnoszące się do jakości. Może to być na przykład określenie czasu nieprzerwanej bezawaryjnej pracy czy charakterystyka innego typu odnosząca się do produktu projektu. W następnym procesie PRINCE:Określenie Podejścia do Projektu określane są ograniczenia nakładane na jakość. Ograniczeniem takim może być na przykład możliwość uzyskania przez produkt określonego czasu bezawaryjnej pracy nie krótszego niż jeden tydzień.

Zasadnicza praca związana z planowaniem jakości odbywa się w procesie PRINCE:Planowanie Jakości, który jest częścią złożonego procesu PRINCE:Inicjacja Projektu. Żeby projekt toczył się w sposób gwarantujący spełnienie standardów jakości, należy ustalić kompromis pomiędzy systemem zapewnienia jakości obowiązującym w firmie realizującej projekt i systemem zapewnienia jakości u klienta projektu. Na tej podstawie definiowane są potrzeby dotyczące zapewnienia jakości obowiązujące w projekcie.

Planowane są także kryteria odbioru produktu oraz kryteria sukcesu projektu. O ile kryteria odbioru produktu powinny się odnosić do jego cech, które mogą być sprawdzone w trakcie względnie niedługiego procesu PRINCE:Skończenie Projektu, to kryteria sukcesu projektu często mogą się odnosić do eksploatacji produktu projektu po jego odbiorze. Na przykład sukces projektu produkcji gotowego wyrobu na półkę może być oceniony dopiero po pewnym okresie działań handlowych związanych z tym produktem. Działania handlowe mogą być realizowane dopiero po odbiorze produktu projektu.

Określane są procedury i metody stosowane do kontroli jakości oraz wytyczne dotyczące ich stosowania.

Dla każdej planowanej czynności, zarówno dotyczącej zapewnienia jakości jak i kontroli jakości, określane są odpowiedzialności.

Wynikiem planowania jakości jest Plan Jakości, który może wejść w skład Planu Projektu. Dodatkowo tworzony jest Rejestr Jakości przeznaczony do opisu przebiegu czynności związanych ze sprawdzaniem jakości.

Elementy planowania jakości znajdują się w procesie PRINCE:Ustanowienie Sposobów Sterowania Projektem. Elementami sterowania według PRINCE mogą być progi tolerancji jakości oraz Przeglądy Jakości. Przekroczenie progów tolerancji jakości (np. zbyt duża liczba błędów wykrytych w czasie testowania oprogramowania) może być podstawą do rozważania zmiany przebiegu fazy lub projektu. Wynik Przeglądu Jakości jest elementem sterowania, ponieważ jego wynikiem może być np. konieczność ponownego wykonania niektórych prac. Sposób wykorzystania tych dwóch elementów sterowania musi być włączony do Dokumentu Otwarcia projektu.

Plan Jakości wraz z pozostałymi elementami planu projektu musi być zatwierdzony w procesie PRINCE:Zatwierdzenie Projektu przez Radę Projektu. Zasadnicze kryterium zatwierdzenia to jego zgodność z wcześniej przyjętym Konspektem Projektu oraz właściwy przydział funkcji związanych z zarządzaniem jakością.

Plan jakości projektu musi być realizowany w poszczególnych fazach. W procesie PRINCE:Planowanie Fazy (lub w procesie PRINCE:Tworzenie Planu Wyjątków) do planu fazy włączane są wszystkie czynności dotyczące tej fazy a wynikające z przyjętego Planu Jakości; w szczególności zaplanowany musi być zestaw Przeglądów Jakości, przewidywanych w ramach fazy. Przydzielone muszą być także zasoby konieczne do zrealizowania tych czynności. Czynności te muszą być zaakceptowane przez Radę Projektu w procesie PRINCE:Zatwierdzenie Planu Fazy lub Planu Wyjątków. Jeśli w wyniku planowania fazy (lub wyjątku) zmienia się podejście do zarządzania jakością, to w procesie PRINCE:Modyfikowanie Planu Projektu należy także odpowiednio zmodyfikować Plan Jakości.

Najbardziej szczegółowe planowanie czynności związanych z kontrolą jakości odbywa się w trakcie realizacji procesu kierownika projektu PRINCE:Zatwierdzanie Pakietu Prac oraz odpowiadającego mu po stronie kierownika zespołu technicznego procesu PRINCE:Akceptacja Pakietu Prac. W trakcie tej interakcji ustalone mogą być szczegóły dotyczące sposobu wykonania prac związanych ze sprawdzeniami jakości (główna postać – Przegląd Jakości).

Wedlug CMMI podstawowe, ogólne czynności związane z zarządzaniem jakością muszą być włączone do planu projektu w praktyce CMMI:Szacowanie Zakresu Projektu. W procesie CMMI:Zapewnienie Jakości Procesu i Produktu znajdują się praktyki CMMI:Obiektywna Ocena Procesów i CMMI: Obiektywna Ocena Produktów Pracy i Usług. Częścią tych praktyk jest określenie (i późniejsze utrzymywanie) kryteriów potrzebnych do oceny jakości procesów. Kryteria muszą być określone w sposób mierzalny, muszą być podane opisy procedur mierzenia a także odpowiedzialności i harmonogram sprawdzeń.

Bardziej zaawansowane organizacje powinny opierać realizację projektów na swoich wcześniejszych doświadczeniach. Do procesu realizacji projektu, w wyniku realizacji praktyki CMMI:Ustanowienie Zdefiniowanego Procesu Projektu, powinny wejść sprawdzone czynności związane z zarządzaniem jakością, a w szczególności czynności odnoszące się do weryfikacji i walidacji. W bibliotece zasobów organizacji może się znajdować wzorcowy plan zapewnienia jakości. Praktyka PMI:Integracja Planów umożliwia korzystanie z takiego wzoru planu (standard CMMI nie opisuje jego postaci).

Najbardziej sprawne organizacje, realizujące proces CMMI:Ilościowe Zarządzanie Projektem w bibliotece zasobów służących do realizacji projektów powinny przechowywać także dane o miarach związanych z jakością, uzyskanych w trakcie realizacji poprzednich procesów. Dane te mogą być wykorzystane do planowania efektów jakościowych aktualnie realizowanego projektu. Do zaplanowania zarządzania jakością służy kilka praktyk tego procesu. Pierwszą z nich jest CMMI:Ustanowienie Celów Projektu, w której powinny być określone cele związane z jakością, np. liczba błędów wykrytych w trakcie testowania elementu oprogramowania. Następnie w praktyce CMMI:Skomponowanie Zdefiniowanego Procesu należy wybrać te spośród stosowanych w firmie podprocesów, które najlepiej nadają się do realizacji przyjętych celów. Zdefiniowany proces składa się z wielu czynności, być może nie jest ekonomiczne ani wykonalne mierzenie cech jakościowych wszystkich z nich. Praktyka CMMI:Wybór Podprocesów Do Zarządzania Statystycznego nakazuje wybrać te, które będą podlegać zarządzaniu statystycznemu (w celu osiągnięcia przyjętych wcześniej celów). Dla wybranych czynności w praktyce CMMI:Wybór Miar i Technik Analitycznych określane są sposoby i procedury wyliczania miar.

Czynności związane z zarządzaniem jakością znajdują się także w obszarze inżynierskim. W praktyce CMMI:Opracowanie Wymagań Klienta należy określić wymagania (procedury, ograniczenia, założenia) związane ze sposobem wykonywania weryfikacji i walidacji. Przy projektowaniu produktu lub jego składowej (praktyka CMMI:Projektowanie Produktu lub Składowej Produktu) należy określić kryteria, według których produkt będzie oceniany (np. niezawodność, weryfikowalność, dokładność, prostota). Następnie w praktyce CMMI:Ustanowienie Pakietu Danych Technicznych (najbardziej szczegółowy poziom planowania) należy określić kryteria weryfikacji spełnienia przyjętych wymagań. W praktyce CMMI:Określenie Kolejności Integracji należy zdefiniować kryteria weryfikacji zintegrowanego produktu. Kryteria te powinny być zaimplementowane w praktyce CMMI:Ustanowienie Procedur i Kryteriów Integracji Produktu.

Również w procesie zarządzania umowami z dostarczycielami znajdują się elementy planowania zarządzania jakością. Praktyka CMMI:Ustanowienie Umowy z Dostarczycielem nakazuje określenie standardów jakie mają być spełniane przez dostarczany produkt. Wskazane muszą być także typy przeglądów wykonywanych ze względu na realizacje umowy. Jeśli nabywany ma być produkt „z półki”, to praktyka CMMI:Przegląd Produktów „z Półki” nakazuje określenie dla niego wymagań jakościowych.

Systematyczne podejście do planowania procesu weryfikacji jest opisane w praktykach mających na celu realizację celu CMMI:Przygotowanie do Weryfikacji. Wybór produktów pracy przeznaczonych do weryfikacji odbywa się w praktyce CMMI:Wybór Produktów Pracy do Weryfikacji. Kryteriami decydującymi o wyborze mogą być np. ryzyko związane z produktem lub wpływ na realizację celów projektu. Konieczne jest podanie wymagań, które będą weryfikowane. Ponieważ pojęcie weryfikacji jest rozumiane w CMMI dość szeroko – zawiera wszystkie techniki prowadzące do sprawdzenia czy proces daje właściwe efekty – należy określić techniki wykonywania weryfikacji. Plany weryfikacji powinny być włączone do planu projektu. Żeby możliwe było wykonanie weryfikacji, konieczne jest przygotowanie środowiska dla niej – praktyka CMMI:Ustanowienie Środowiska Weryfikacji. Praktyka ta nakazuje opracowanie szczegółowych planów zasobów potrzebnych do wykonania weryfikacji. Szczegółowe procedury wykonania weryfikacji (np. scenariusze testowe) są planowane w praktyce CMMI:Ustanowienie Procedur i Kryteriów Weryfikacji. Konkretną techniką, której CMMI poświęca dużo uwagi, są równe przeglądy. Planowanie równych przeglądów (Praktyka CMMI:Przygotowanie Równego Przeglądu) wymaga przede wszystkim określenia problemów (np. zasady projektowania, poprawność, spójność), które będą analizowane oraz sposobu wykonania przeglądu. Należy określić także zestaw uczestników oraz harmonogram przeglądu.

Wybór produktów do walidacji odbywa się w praktyce CMMI:Wybór Produktów do Walidacji. Praktyka ta także nakazuje określić główne zasady przeprowadzenia walidacji. Następna praktyka CMMI:Ustanowienie Środowiska Walidacji nakazuje określić zasoby potrzebne do jej przeprowadzenia. Szczegółowe plany (scenariusze) walidacji są opracowywane w praktyce CMMI:Określenie Procedur i Kryteriów Walidacji.

Standard PMI podaje zestaw konkretnych technik, które należy uwzględnić przy planowaniu jakości. Oryginalną, nieobecną w pozostałych standardach metodą planowania jakości są eksperymenty. Standardy jakości powinny odnosić się do efektów jakościowych innych projektów. Planowanie jakości musi dojść do poziomu operacyjnego. Standard PMI mówi, że proces planowania jakości powinien się odbywać jednocześnie z innymi pracami planistycznymi, nie są podane powiązania z innymi czynnościami realizacji projektu.

Metoda PRINCE nakazuje obowiązkowe stosowanie jednej, bardzo skutecznej techniki kontroli jakości – Przeglądów Jakości oraz jednej techniki zapewnienia jakości – auditów jakości. PRINCE wskazuje konkretne procesy, w których powinien odbywać się coraz dokładniejsze planowanie jakości. Planowanie jakości rozpoczyna się już przy określaniu wstępnych zarysów projektu w trakcie przygotowywania jego konspektu, zaś najbardziej szczegółowe czynności związane z planowaniem jakości odbywają się na poziomie zespołu technicznego w trakcie opracowywania sposobu wykonania produktów. Takie podejście sprzyja precyzyjnemu zaplanowaniu wszystkich czynności związanych z zarządzaniem jakością.

Znaczącą cechą odróżniającą podejście modelu CMMI do planowania jakości od pozostałych standardów jest oparcie planowania na wcześniejszych doświadczeniach firmy. W ramach planowania jakości zalecany jest wybór najlepszych spośród dostępnych w firmie sposobów realizacji projektu. Podobnie jak w PRINCE planowanie jakości odbywa się stopniowo, zaczynając od ogólnego szacowania projektu aż do zlecania do wykonania elementarnych pakietów prac. Ostatecznym efektem planowania jakości powinny być zawsze scenariusze potrzebne do realizacji czynności związanych z zapewnieniem czy kontrolą jakości. Tak precyzyjny sposób opisu wyniku planowania jakości nie znajduje się w pozostałych omawianych tu standardach.

Zapewnienie jakości

Proces PMI:Zapewnienie Jakości jest opisany dość skąpo. Są to czynności mające na celu osiągnięcie przez projekt wszystkich dotyczących go standardów jakości. Zapewnienie jakości jest w projektach zwykle wykonywane przez zewnętrzny względem projektu, niezależny dział zapewnienia jakości, ale może także być wykonywane przez wyróżniony zespół wewnątrz projektu lub przez klienta, dla którego projekt jest realizowany. Podstawową techniką są tu audity jakości, czyli systematyczne przeglądy innych czynności związanych z zarządzaniem jakością, mające na celu wyszukanie ewentualnych niezgodności z przyjętymi standardami. PMI mówi także, że do zapewnienia jakości mogą być zastosowane techniki wykorzystywane w planowaniu jakości. Porównanie z innymi projektami może służyć do sprawdzenia, czy techniki związane z zapewnieniem jakości są stosowane w sposób analogiczny do innych projektów. Diagramy Ishikawy i schematy blokowe mogą pokazać, jakie konkretne problemy spowodowały określony negatywny efekt[2]. Eksperymentem prowadzącym do poprawy jakości, zgodnie z podaną definicją, jest proces wyboru jednego z kilku zaproponowanych rozwiązań dotyczących sposobu realizacji fragmentu projektu.

Wynikiem procesu zapewnienia jakości jest poprawa jakości, czyli zwiększenie efektywności i skuteczności projektu w zaspokajaniu potrzeb udziałowców.

Za zapewnienie jakości w metodzie PRINCE odpowiada Rada Projektu. Do realizacji zadań związanych z zapewnieniem jakości mogą być delegowane osoby z zespołu Zapewnienia Projektu. Osoby te są odpowiedzialne za stosowanie standardów technicznych i standardów dotyczących jakości. W szczególności odpowiadają one za realizację określonych w Planie Jakości Projektu procesów kontroli jakości i auditów niezależnych od Kierownika Projektu. Jednak należy zauważyć, że w PRINCE nie ma procesu, którego celem byłoby wykonanie tych czynności. Można więc domniemywać, że są one wykonywane w dowolnym momencie na życzenie Rady Projektu. Wydaje się, że w procesie Kierowanie Projektem powinien znajdować się podproces, którego celem byłoby wykonywanie funkcji zapewnienia projektu, w tym procesu zapewnienia jakości.

W PRINCE nie są wymagane procesy zapewnienia jakości uruchamiane w wyniku polecenia Kierownika Projektu. Zaplanowanie takich prac – jako standardowych prac wykonywanych w trybie przyjmowania, realizowania i odbioru – wymagałoby utworzenia specjalistycznego zespołu zapewnienia jakości podlegającego Kierownikowi Projektu.

Podstawowym procesem nastawionym na zapewnienie jakości w modelu CMMI jest CMMI:Zapewnienie Jakości Procesu i Produktu. W praktyce CMMI:Obiektywna Ocena Procesów należy zastosować definicje wcześniej ustalonych procedur, standardów i procesów do oceny sposobu wykonywania rzeczywiście realizowanych procesów. Podobny cel ma praktyka CMMI:Obiektywna Ocena Produktów Pracy i Usług. Różnica polega na tym, że o ile w drugiej z nich ocenia się procesy z punktu widzenia wytworzonych produktów, to w pierwszej bada się proces jako taki. Przy ocenie produktu – która może się odbywać np. w trakcie oceny kamieni milowych – należy stwierdzić, czy standardy, procedury i procesy zastosowane do produkcji tego produktu zostały w sposób właściwy wykonane. Ocena produktu powinna ułatwić późniejszą jego weryfikację. Jeśli sprawdzany jest proces, to zakres czynności nie jest zawężany przez perspektywę jednego produktu.

Jeśli organizacja wdrożyła zintegrowane zarządzanie projektami, to praktyka CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu nakazuje kontrolować sposób realizacji projektu. Czynności, które mają wpływ na zasadnicze parametry projektu (np. parametry jakościowe – liczba zidentyfikowanych błędów) muszą być monitorowane. Jeśli parametry przekraczają przyjęte progi, to należy przeprowadzić badania, mające na celu ustalenie ich przyczyn.

Zapewnienie jakości w projektach zarządzanych ilościowo ma strukturę podobną do zapewnienia jakości w projektach zarządzanych w sposób zintegrowany. Różnica polega na tym, że oczekiwane wartości parametrów podprocesu są ustalane na podstawie ich działania w innych, wcześniej zrealizowanych projektach. Zapewnienie jakości projektu odbywa się na dwóch poziomach. Praktyka CMMI:Zarządzanie Efektywnością Projektu służy do monitorowania postępu projektu jako całości. Żeby ten sposób zapewnienia jakości był możliwy, konieczne jest istnienie modelu efektywności procesu, który służy do badania postępów w realizacji celów projektu, gdy nie jest on ukończony. Praktyki CMMI:Monitorowanie Efektywności Wybranych Podprocesów i CMMI:Zastosowanie Metod Statystycznych do Zrozumienia Odchyleń koncentrują się na poszczególnych podprocesach wybranych do statystycznego zarządzania. Pierwsza z nich dotyczy przebiegu procesu i stara się wyłapać zaburzenia w realizacji przed jego zakończeniem. Druga jest stosowana do oceny podprocesu po jego zakończeniu. Wszystkie te praktyki mogą spowodować wprowadzenie zmian usprawniających realizację projektu.

We wszystkich trzech standardach występują działania, które można uznać za audit – w PMI i PRINCE występują one explicite, natomiast w CMMI za audity można uznać realizację praktyk Obiektywna Ocena Procesów i Obiektywna Ocena Produktów Pracy i Usług. W PMI dodatkowymi technikami zapewnienia jakości są techniki graficzne. PMI przewiduje możliwość wykonania auditów na kilku poziomach organizacyjnych, także na poziomie kierownika projektu – nie jest to przewidziane w PRINCE. Znaczącym rozszerzeniem technik zapewnienia jakości w CMMI, w porównaniu z pozostałymi standardami, jest wykorzystywanie konkretnych technik ilościowych, opartych na doświadczeniach organizacji realizującej projekt lub na wynikach wcześniej zrealizowanych czynności projektu.

Kontrola jakości

W PMI zgodnością technicznych produktów i półproduktów oraz wyników prac zarządczych z przyjętymi standardami zajmuje się proces PMI:Kontrola Jakości. Za miary jakości prac zarządczych można przyjąć m. in. poziom wykorzystania budżetu czy zgodność z przyjętym harmonogramem. Podstawową techniką kontroli jakości jest inspekcja, czyli sprawdzanie, przeglądanie lub testowanie produktów w celu stwierdzenia czy obiekt spełnia stawiane przed nim wymagania. Sprawdzane mogą być wszystkie wyniki prac lub statystycznie wyznaczone podzbiory wyników. Wyniki inspekcji mogą być prezentowane na różne sposoby, np. mogą być grupowane wg. przyczyn (diagramy Pareto), czy też prezentowane w zależności od czasu. Uzyskane wyniki mogą być podstawą do analizy trendów, służącej do przewidywania przyszłych zachowań analizowanych zmiennych.

W wyniku kontroli jakości podejmowane są decyzje w kwestii akceptacji produktu. Produkt może być zaakceptowany albo odrzucony, możliwe jest także jego przepracowania aby dostosować go do przyjętych standardów.

Techniką kontroli jakości w PRINCE jest Przegląd Jakości. Podstawowym celem Przeglądu Jakości jest zapewnienie, że produkt spełnia wszystkie stawiane przed nim wymagania i jest możliwy do wykorzystania jako ostateczny produkt lub jako wejście do innych prac. W przypadku półproduktów ważne jest wczesne wykrywanie błędów, których efekty mogłyby wpłynąć na dalsze prace. Wczesne wykrywanie i usuwanie błędów jest zawsze znacznie mniej kosztowne niż poprawianie następnych produktów, w których efekt błędu i koszt jego usunięcia może być spotęgowany. W Przeglądzie Jakości powinny brać wszystkie osoby, które mają wiedzę o sposobie jego produkcji oraz osoby, które będą wykorzystywały produkt. Za wykonanie przeglądu odpowiada kierownik zespołu technicznego, w którym produkt został opracowany.

Przegląd jakości składa się z trzech etapów:

Przygotowanie
Spotkanie
Akcje następujące

W ramach przygotowania wytypowane osoby otrzymują produkt, który podlega przeglądowi. Przed spotkaniem powinny one ocenić produkt, czego efektem jest lista wykrytych błędów. Lista ta powinna zostać dostarczona producentowi, żeby przed spotkaniem mógł się przygotować do dyskusji.

W trakcie spotkania należy przeprowadzić dyskusję mającą na celu omówienie i wyjaśnienie wszystkich błędów. Udział w spotkaniu powinien odbywać się na zasadach partnerskich. Producent wyjaśnia wszystkie wątpliwości związane z produktem. Przegląd powinien służyć wyszukiwaniu błędów, a nie określaniu odpowiedzialności personalnej spowodowanie tych błędów. Dla każdego błędu ustalane i dokumentowane są sposoby jego usunięcia. Ubocznym efektem przeglądu jakości może być weryfikacja standardów (wymagań) na podstawie których produkt był opracowywany.

Na podstawie przebiegu spotkania podejmowana jest decyzja w sprawie przydatności produktu. Możliwe (ale niestety rzadko zdarzające się w praktyce) jest zaakceptowanie produktu bez uwag. Najczęstszym wynikiem jest akceptacja warunkowa, czyli przyjęcie produktu z listą odnoszących się do niego, koniecznych do naprawy, usterek – w tym przypadku nie jest konieczne ponowne poddawanie produktu przeglądowi jakości. Jeśli produkt zdecydowanie odbiega od założonych standardów, konieczne jest jego poprawienie i ponowne poddanie przeglądowi jakości.

Po przeglądzie należy poinformować Kierownika Projektu o wynikach spotkania a w szczególności o decyzjach dotyczących sposobu usuwania błędów.

W CMMI procesami, których głównym celem jest kontrola jakości są CMMI:Weryfikacja i CMMI:Walidacja. Sposobami wykonania weryfikacji mogą być np. audity, prezentacje wyników pracy czy analizy. Praktyka CMMI:Wykonanie Weryfikacji nakazuje wykonanie zaplanowanej weryfikacji w celu wyszukania niezgodności z przyjętymi kryteriami. Uzyskane wyniki są analizowane jako wyniki praktyki CMMI:Analiza Wyników Weryfikacji i Określenie Akcji Korygujących. Praktyka ta powinna także określić w jaki sposób zidentyfikowane usterki mają być usunięte.

Techniką, której CMMI poświęca szczególnie wiele uwagi są równe przeglądy, czyli systematyczne sprawdzenie produktów pracy przez równouprawnionych członków zespołu producenckiego w celu zidentyfikowania i usunięcia błędów. Postaciami równych przeglądów mogą być np. aktywny przegląd lub strukturalne przejście. Po wykonania równego przeglądu (CMMI:Wykonanie Równego Przeglądu) powinna nastąpić analiza uzyskanych wyników (praktyka CMMI:Analiza Danych z Równych Przeglądów).

Wynikiem walidacji jest zwykle modyfikacja zestawu obowiązujących wymagań. Celem walidacji jest wykazanie, że produkt lub jego składowa będzie się nadawała do zamierzonego użycia. Walidacja powinna się odbywać progresywnie. Możliwie wcześnie, w wyniku wykonania praktyki CMMI:Walidacja Wymagań, należy sprawdzić, że udokumentowane wymagania opisują rzeczywiste potrzeby klienta. W tym celu należy przeanalizować wymagania pod kątem ryzyka niewłaściwego działania specyfikowanego produktu w środowisku docelowym, wynikającego z istniejących wymagań. Analogicznie do walidacji powinny być wybierane następne, kolejno wypracowywane wyniki prac (projekt, składowe produktu, zintegrowany produkt). Ostateczna walidacja produktu powinna odbywać się w środowisku, w którym produkt ma docelowo działać. Niezależnie od obiektu, walidacja składa się, podobnie jak weryfikacja, z dwóch części. Pierwsza z nich to CMMI:Wykonanie Walidacji. Uzyskane wyniki powinny być przeanalizowane w trakcie realizacji praktyki CMMI:Analiza Wyników Walidacji, w której porównuje się wyniki uzyskane z zamierzonymi. W wyniku walidacji mogą być zmodyfikowane wymagania na produkt.

Proces zarządzania projektem i jego wyniki podlegają kontroli jakości (weryfikacji) w wielu miejscach. Praktyka CMMI:Przegląd Planów Wpływających na Projekt nakazuje sprawdzić zgodność ogólnego planu projektu z planami wspomagającymi (np. plan jakości, plan zarządzania ryzykiem). Ustalenia z udziałowcami, podjęte w celu realizacji projektu, muszą być z nimi przejrzane w ramach praktyki CMMI:Uzyskanie Ustaleń dla Planu. Należy wykonywać przeglądy wszystkich elementów, które mają się stać wspólnymi zasobami organizacji (praktyki CMMI:Ustanowienie Standardowych Procesów, CMMI:Ustanowienie Opisu Modelu Cyklu Życia, CMMI:Ustanowienie Kryteriów i Wytycznych Dotyczących Dopasowywania oraz CMMI:Ustanowienie w Organizacji Repozytorium Miar). Jeśli realizacja projektu będzie się odbywać zgodnie ze zdefiniowanym procesem, to opis tego procesu musi być poddany przeglądowi w trakcie realizacji praktyki CMMI:Ustanowienie Zdefiniowanego Procesu Projektu. W trakcie realizacji zdefiniowanego procesu należy w praktyce CMMI:Zarządzanie Projektem z Wykorzystaniem Zdefiniowanego Planu oceniać przydatność środowiska do realizacji projektu oraz sprawdzać zgodność wyników projektu z jego planami. Główną częścią praktyki CMMI:Zarządzanie Zaangażowaniem Udziałowców jest sprawdzanie, czy wyniki prac realizowanych przez udziałowców są właściwe. Prace udziałowców muszą być skoordynowane – częścią praktyki CMMI:Zarządzanie Zależnościami jest przegląd zależności pomiędzy udziałowcami.

Czynności mające charakter kontroli jakości występują także jako składowe innych procesów, a przede wszystkim procesu inżynierskiego oraz procesu współpracy z dostawcami.

W procesie zarządzania wymaganiami w praktyce CMMI:Identyfikacja Niespójności pomiędzy Pracą Projektu a Wymaganiami w trakcie przeglądu należy wyszukać niespójności, które mogły wyniknąć z wprowadzenia zmian w wymaganiach. Przed walidacją wymagań w praktyce CMMI:Ustanowienie Koncepcji Operacyjnych i Scenariuszy należy w trakcie przeglądu stwierdzić, że zasadnicze założenia określające sposób działania produktu są zgodne z przyjętymi wymaganiami. W ramach praktyki CMMI:Implementacja Projektu wykonywany jest przegląd wybranych składowych oraz testowanie wyników prac. Praktyka CMMI:Opracowanie Dokumentacji Wspomagającej Produkt nakazuje wykonanie przeglądu dokumentacji wszystkich rodzajów (instalacyjnej, eksploatacyjnej i pielęgnacyjnej). Ta sama technika jest wykorzystywana do sprawdzenia poprawności i kompletności interfejsów między składowymi produktu (CMMI:Przegląd Kompletności Opisu Interfejsów). Sprawdzone muszą być składowe wchodzące do integracji (CMMI:Potwierdzenie Gotowości Składowych Produktu do Integracji), zintegrowane składowe (CMMI:Ocena Złożonych Składowych Produktu). Ważnym, ostatecznym elementem kontroli jakości w procesie inżynierskim jest sprawdzenie gotowych do dostarczenia, zapakowanych produktów projektu (CMMI:Zapakowanie i Dostarczenie Produktu lub Składowej).

Wypełniony technikami związanymi z kontrolą jakości jest także proces zakupu towarów lub usług od zewnętrznych dostarczycieli. Wybór podproduktów do zakupu z zewnątrz w praktyce CMMI:Przegląd Produktów „z Półki” odbywa się w wyniku działań, które można określić jako inspekcję dostępnych towarów. Praktyka CMMI:Wykonanie Umowy z Dostarczycielem nakazuje poprzez przeglądy kontrolować właściwie wszystkie aspekty pracy podwykonawcy (techniczne wyniki i procesy zarządzania). Żeby w praktyce CMMI:Odbiór Nabywanego Produktu zaakceptować produkt, należy najpierw wykonać jego przegląd.

Wszystkie trzy standardy opierają kontrolę jakości na przeglądach. Tak jak we wszystkich innych obszarach związanych z zarządzaniem jakością, PMI wyróżnia się tutaj również większym zestawem technik zapewnienia jakości. Podejście CMMI jest najbardziej rozbudowane. Kontrola jakości została podzielona z punktu widzenia celów wykonania (weryfikacja, walidacja). Pojęcie walidacji nie występuje w PMI ani w PRINCE. CMMI szczegółowo wskazuje, w których miejscach poszczególnych procesów powinny być wykonane kontrole jakości. W modelu tym techniki związane z zarządzaniem jakością są obecne w wielu procesach, ale brakuje ich w początkowych fazach tworzenia rozwiązania technicznego, kiedy weryfikacja produktu jest bardzo ważna. Uwaga taka nie może być sformułowana w odniesieniu do PMI ani PRINCE, gdyż standardy te pozostawiają wybór momentów, w których należy wykonać kontrolę jakości, zespołowi kierującemu projektem.

Ulepszanie

PMI nie przywiązuje zbyt dużo uwagi do procesu ulepszania. Plan jakości powinien uwzględniać ulepszanie procesów projektu. Podstawą do ulepszania mogą być wyniki zapewnienia jakości lub kontroli jakości. Ulepszanie może wymagać zastosowania procedury zarządzania zmianami.

PRINCE nie odnosi się jawnie do ulepszania ani naprawiania procesów projektu chociaż naturalną konsekwencją auditu jakości, jeśli jego wynik nie jest pozytywny, powinno być podjęcie czynności zmierzających do doprowadzenia procesu do postaci wymaganej przez przyjęty standard.

Poprawianie produktów projektu jest wynikiem Przeglądu Jakości. Za prace te odpowiedzialny jest kierownik zespołu technicznego tworzącego produkt. Zakończenie akcji ustalonych w czasie przeglądu musi być stwierdzone odpowiednim podpisem. Jeśli produkt miał być poddany ponownemu Przeglądowi Jakości, to przegląd taki należy przeprowadzić.

W modelu CMMI ulepszanie sposobu realizacji projektów odbywa się przede wszystkim na poziomie organizacji realizujących projekty. Projekty dostarczają rozwiązań organizacyjnych oraz wiedzy uzyskanej w trakcie ich realizacji. Do ulepszania sposobu realizacji konkretnych projektów służy proces CMMI:Analiza Przyczyn i Usprawnianie. Proces ten składa się z dwóch części: określenie przyczyn błędów i odniesienie się do tych przyczyn. Wejściem do praktyki CMMI:Wybór Do Analizy Danych Odnoszących się do Błędów są informacje uzyskane w trakcie weryfikacji produktów pracy albo dane z procesu ilościowego zarządzania projektem. Wybierane powinny być często pojawiające się błędy mające największy wpływ na realizację projektu. Rozważyć należy także możliwość i koszt wykonania analizy. Do wykonania analizy służy praktyka CMMI:Analiza Przyczyn. Analizę tę powinny wykonywać osoby najlepiej znające realizowane procesy. Przyczyny błędów powinny być grupowane w celu sprawniejszej ich obsługi. Podstawowym wynikiem analizy powinno być wskazanie działań zapobiegających ponownemu pojawieniu się usterek, np. szkolenia personelu, zmiana sposobu realizacji czynności, zmiana kolejności czynności w procesie czy dostarczenie nowych zasobów do jego realizacji. Praktyka CMMI:Wdrożenie Propozycji Działań nakazuje określić priorytety akcji naprawczych. Najważniejsze z nich powinny być szczegółowo zaplanowane – przydzielona musi być odpowiedzialność, zaplanowana musi być koordynacja działań, określone muszą być sposoby oceny skuteczności proponowanych poprawek. Po wdrożeniu zmiany należy ją ocenić realizując praktykę CMMI:Ocena Efektywności Zmiany. Dane z procesu usprawniania powinny być w ramach praktyki CMMI:Zapisanie Danych zapisane na potrzeby innych procesów realizowanych w danej organizacji.

Według modelu CMMI proces Analiza Przyczyn i Usprawnianie jest wymagany tylko od najlepiej zorganizowanych organizacji. W mniej zaawansowanych firmach ulepszanie może mieć mniej kompleksowy charakter. Praktyka CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu sugeruje dodawanie nowych narzędzi, wyposażenia czy szkolenia, jeśli zostaną napotkane problemy z poprawną realizacją planu projektu. Elementem ilościowego zarządzania projektami są praktyki CMMI: Zastosowanie Metod Statystycznych do Zrozumienia Odchyleń i CMMI:Monitorowanie Efektywności Wybranych Podprocesów. Obydwie one, podobnie jak CMMI:Zarządzanie Projektem z Wykorzystaniem Zintegrowanego Planu, nakazują zrozumienie przyczyny błędu oraz określenie i wdrożenie sposobu przeciwdziałania ich pojawianiu się. Różnica polega na sposobie wskazywania procesów będących kandydatami do ulepszania – techniki ilościowe polegają na mierzeniu i porównywaniu wyników procesu z ustalonymi statystycznie dopuszczalnymi wartościami parametrów.

Jedynie model CMMI przedstawia spójne, konsekwentne podejście do problemu ulepszania oraz naprawiania. Pozostałe standardy wspominają o tych zagadnieniach, ale nie poświęcają im uwagi odpowiadającej znaczeniu ich znaczeniu dla osiągnięcia sprawnej realizacji projektów.

Porównanie zarządzania biznesem

Ogólne podejście

Zarządzanie biznesem w projekcie jest to zestaw działań mających na celu zapewnienie, że projekt osiągnie te cele, dla których został powołany.

Klient zamawia realizację projektów żeby zmienić sposób swojego działania, mówiąc inaczej – żeby coś zrobić z produktami projektu. Zadaniem produktów projektu jest ulepszenie środowiska, dla którego są przeznaczone. Powinny one umożliwić inny, lepszy, bardziej sprawny sposób realizacji celów funkcjonowania użytkownika produktów projektu. Produkty projektu są narzędziem wprowadzania pozytywnych zmian. Ważnym ubocznym efektem realizacji projektu z punktu widzenia użytkownika jest zmniejszenie jego zasobów o wszelakie koszty przeznaczone na realizację projektu. Kosztami takimi są środki finansowe przeznaczone na wynagrodzenie wytwórcy, ale należy do nich także zaliczyć inne obciążenia związane z realizacją projektu – np. koszty zapewnienia wyposażenia koniecznego do realizacji projektu czy efekty oddelegowania własnego personelu do zadań związanych z realizacją projektu. Zmniejszenie zasobów jest jednym z czynników wyznaczających sposób działania użytkownika w wynikowej sytuacji.

Warto jednak zauważyć, że istnieją projekty, których celem nie jest zmiana sposobu funkcjonowania użytkownika. Pod ten schemat trudno byłoby podciągnąć większość projektów z obszaru sztuki – na przykład wybudowanie pomnika czy produkcja filmu. Projekty takie stanowią jednak zdecydowaną mniejszość.

Rysunek 4. Kontekst projektu – spojrzenie użytkownika

Z kolei dla wykonawcy projektu głównym celem realizacji projektu jest uzyskanie korzyści z jego realizacji. Ewentualna zmiana sposobów funkcjonowania wykonawcy w wyniku realizacji projektu, czyli uzyskanie doświadczenia, jest pożądanym, ale ubocznym efektem prac projektowych.

Rysunek 5. Kontekst projektu – spojrzenie wykonawcy

Trzecim głównym rodzajem podmiotu, jaki może być zaangażowany w realizację projektu, jest klient. Klient jest to podmiot zlecający realizację projektu. Klient nie musi być użytkownikiem produktu projektu, chociaż w większości realizowanych projektów role te pokrywają się. Przykładami projektów, w których klient nie jest tożsamy z użytkownikiem produktu, są tzw. projekty pomocowe. Klientem projektu jest tu organizacja, której statutowym celem jest usprawnienie funkcjonowania innych podmiotów. Innym przykładem tej sytuacji są projekty handlowe, w których klient projektu zleca produkcję określonego towaru, aby później na własną odpowiedzialność produkty te sprzedawać końcowym użytkownikom. Biznesowe spojrzenie klienta na projekt jest zbliżone do spojrzenia użytkownika, jednak większą wagę niż użytkownik przywiązuje on do wykorzystania zasobów koniecznych do realizacji projektu. W projekcie nieobecny może być użytkownik jego produktu (chociaż sytuacja taka nie jest pożądana) natomiast nie może istnieć projekt bez klienta.

Standard PMI określa zbiór przyczyn biznesowych, dla których wykonawca może rozpocząć realizację projektu. Przyczynami takimi mogą być np. sytuacja rynkowa, wymagania biznesowe, żądanie klienta, możliwość uzyskania przewagi technologicznej, wymaganie prawne czy potrzeba społeczne.

Metoda PRINCE nie precyzuje jawnie rodzajów przyczyn (a więc i celów) biznesowych, jakie mogą spowodować rozpoczęcie projektu.

W metodzie PRINCE podstawowym pojęciem dotyczącym efektów biznesowych jest Uzasadnienie Biznesowe czyli opis powodów realizacji projektu i ocena podjęcia projektu, oparta na szacunkach kosztów, ryzyk i korzyści biznesowych. Wyróżniane są dwa Uzasadnienia Biznesowe – klienta i wykonawcy. Jednak poza podaniem informacji, że dla projektu istnieje także Uzasadnienie Biznesowe wykonawcy, w PRINCE nie uwzględnia się potrzeb biznesowych wykonawcy – jest to metoda nastawiona wyłącznie na klienta projektu.

Model CMMI, podobnie jak PMI, koncentruje się na celach biznesowych organizacji wykonującej projekty. Celami takimi mogą być np. dochodowość czy udział w rynku. Cele te są ustalane przez najwyższe kierownictwo organizacji.

Standard PMI oraz model CMMI prezentują biznesowe spojrzenie wykonawcy na realizację projektu. PRINCE prezentuje spojrzenie klienta.

Struktura procesów zarządzania biznesem w projekcie

W procesach związanych z zarządzaniem biznesem można wyróżnić trzy główne grupy:

· Wypracowanie celów biznesowych

· Sterowanie celami biznesowymi

· Ocena biznesowego efektu

Celem wypracowania celów biznesowych jest zidentyfikowanie, uzgodnienie i opisanie celów, dla których projekt jest realizowany.

Sterowanie celami biznesowymi obejmuje czynności wykonywane w trakcie realizacji projektu, mające na celu zapewnienie uzyskania przewidywanych celów lub modyfikację tych celów. Szczególną akcją z tej grupy może być przedwczesne zakończenie realizacji projektu – gdy nie jest możliwe osiągnięcie obowiązujących celów biznesowych ani satysfakcjonująca uczestników projektu ich modyfikacja.

Ocena biznesowego efektu projektu są to czynności mające na celu stwierdzenie, czy zaplanowane cele biznesowe zostały osiągnięte. Ocena ta może rozciągać się na czas poza odbiorem produktów projektu.

Rysunek 6 pokazuje ogólną strukturę procesów zarządzania biznesem w projekcie.

Rysunek 6. Struktura procesów zarządzania biznesem w projekcie

Standard PMI w procesie PMI:Inicjacja nakazuje określenie powodu, dla którego projekt jest podejmowany, natomiast w trakcie realizacji projektu nie występują odniesienia do problemów biznesowych.

W metodzie PRINCE Uzasadnienie Biznesowe jest wypracowywane w fazach wstępnych projektu a następnie cały projekt na bieżąco odnosi się do ustanowionych celów. Metoda nakazuje także zaplanowanie czynności, które po zakończeniu projektu sprawdzą, czy zaplanowane efekty wykonania projektu rzeczywiście są osiągane.

W modelu CMMI cele biznesowe nie mogą być zmieniane w trakcie realizacji projektów (są wyznaczane przez najwyższe kierownictwo firmy). Realizacja projektów może w mniejszym lub większym stopniu wpływać na osiąganie celów biznesowych, na przykład poprzez redukcję czasu realizacji projektu, szybkie wykrywanie błędów, zmniejszenie liczby błędów zgłaszanych przez użytkownika.

Sposób realizacji celów biznesowych jest określany poprzez ustanowienie parametrów jakościowych i efektywnościowych dotyczących stosowanych w organizacji procesów i podprocesów. Z kolei te parametry wyznaczają wartości, jakie mają być osiągane w poszczególnych projektach. Parametry dotyczące celów projektu powinny uwzględniać także wymagania klienta i innych udziałowców projektu, jednak w CMMI nie mówi się o celach biznesowych udziałowców innych niż wykonawca.

Tylko w metodzie PRINCE cele biznesowe są osią realizacji projektu i mogą być modyfikowane w trakcie jego trwania. Standard PMI nie odnosi się do celów biznesowych poza momentem ich określenia. Model CMMI stara się doprowadzić do takiej realizacji projektu, żeby spełniał on cele biznesowe organizacji realizującej projekt.

Wypracowanie celów biznesowych

W standardzie PMI, który opisuje projekty z punktu widzenia ich wykonawców, biznesowe cele projektu są definiowane w procesie PMI:Inicjacja. Każdy projekt zaczyna się od podjęcia decyzji o jego rozpoczęciu. Przesłanki do podjęcia tej decyzji pochodzą z szeroko rozumianej dziedziny biznesowej. Przesłanki uruchomienia projektu muszą być zgodne z planem strategicznym realizującej go firmy: organizacja zajmująca się hodowlą kurczaków nie powinna tworzyć systemów informatycznych. Firma powinna mieć informacje historyczne mówiące czy istnieje szansa poprawnego zrealizowania konkretnego projektu. Decyzję o uruchomieniu projektu powinien zawsze podejmować ktoś zewnętrzny względem projektu (np. członek zarządu firmy). W wyniku realizacji procesu PMI:Inicjacja powstaje m. in. dokument otwarcia projektu. W dokumencie otwarcia powinien być określony między innymi cel, dla którego projekt jest realizowany. W momencie rozpoczęcia projektu jego zawartość staje się częścią planu projektu.

W metodzie PRINCE Uzasadnienie Biznesowe powstaje stopniowo. Podstawowe wyznaczniki dla zawartości tego dokumentu powinny znajdować się już w Mandacie Projektu, czyli zewnętrznym bodźcu powodującym rozpoczęcie rozważania uruchomienia projektu. Mandat Projektu jest podstawą do opracowania w procesie PRINCE:Przygotowywanie Konspektu Projektu głównych elementów Uzasadnienia Biznesowego. Na tym etapie powinno być wiadome, w jaki sposób projekt wpisuje się w cele podmiotu zlecającego realizację projektu, czyli dlaczego jest on potrzebny. Elementy Uzasadnienia Biznesowego stanowiące część Konspektu Projektu podlegają ocenie przez Radę Projektu w trakcie procesu PRINCE:Zatwierdzenie Inicjacji. Głębsze spojrzenie na cele biznesowe uzyskiwane jest w trakcie realizacji procesu PRINCE:Projektowanie Podejścia do Projektu – w tym momencie określa się znaczenie produktów projektu dla sposobu realizacji biznesu użytkownika. Ostateczne dopracowanie Uzasadnienia Biznesowego odbywa się po utworzeniu planu projektu – w procesie PRINCE:Ponowna Ocena Uzasadnienia Biznesowego i Ryzyk. Należy sprawdzić, czy sposób realizacji projektu gwarantuje osiągnięcie wcześniej naszkicowanych celów biznesowych. Może się zdarzyć, że w czasie od opracowania Konspektu Projektu pojawiły się nowe okazje biznesowe lub że okazje takie stwarza planowany sposób realizacji projektu. Nowozidentyfikowane możliwe korzyści powinny być włączone do Uzasadnienia Biznesowego. Analogicznie należy postąpić w stosunku do ewentualnych strat, które mogą być wynikiem realizacji projektu. Na przykład ogólnie korzystny projekt wdrożenia nowej technologii informatycznej może spowodować konieczność porzucenia eksploatacji starszych wersji oprogramowania. Dla wszystkich spodziewanych korzyści powinny być określone sposoby ich pomiaru oraz oczekiwane wartości. Konieczne jest także ocena kosztów inwestycji, która powinna być jednym z elementów analizy kosztów i zysków. Akceptacja Uzasadnienia Biznesowego jest podstawowym elementem procesu PRINCE:Zatwierdzanie Projektu, wykonywanego przez Radę Projektu. Klient musi zatwierdzić spodziewane korzyści. Informacja o kosztach projektu powinna być dostarczona przez kierownika projektu. Ocena tych informacji oraz ogólnej możliwości realizacji projektu jest podstawą do podjęcia decyzji o zatwierdzeniu projektu.

W modelu CMMI projekty nie są nastawione bezpośrednio na realizację celów biznesowych. Cele te są widziane przez pryzmat celów dotyczących jakości i efektywności procesu projektu. Cele takie dotyczące poszczególnych procesów są określane w ogólnej (czyli stosowalnej do każdego procesu) praktyce poziomu 4 CMMI:Określenie Celów Ilościowych dla Procesu. Najbardziej zaawansowane organizacje powinny dla procesów określać cele związane z ulepszaniem sposobu realizacji procesów. Wymaga tego ogólna praktyka CMMI:Zapewnienie Ciągłego Ulepszania Procesów.

Globalne określenie celów związanych z jakością i efektywnością projektu odbywa się w procesie zarządczym CMMI:Ilościowe Zarządzanie Projektem. Jego praktyka składowa CMMI:Ustanowienie Celu Projektu nakazuje uwzględnić cele biznesowe wykonawcy oraz oczekiwania dotyczące jakości i efektywności projektu pochodzące od innych udziałowców.

W PMI i PRINCE cele biznesowe związane z realizacją projektu są widoczne bezpośrednio. W CMMI projekt ma do czynienia z cechami wpływającymi na realizację celów biznesowych; same cele biznesowe nie przekładają się bezpośrednio na proces realizacji projektów.

PRINCE prezentuje biznesowy punkt widzenia klienta projektu. PMI – wykonawcy, zaś CMMI przede wszystkim punkt widzenia wykonawcy, ale ten punkt widzenia powinien uwzględniać także potrzeby innych zaangażowanych udziałowców.

Sterowanie celami biznesowymi

PMI nie przewiduje osobnych procesów poświęconych zarządzaniu celami biznesowymi projektu. Dwa procesy mają za jeden ze swoich celów sterowanie celami biznesowymi.

Proces PMI:Inicjacja, gdy jest wykonywany dla całego projektu, nakazuje określić cele biznesowe. Proces ten powinien być także wykonywany przed rozpoczęciem każdej fazy – jest to moment, żeby ocenić, czy postawione cele są w dalszym ciągu realne. Możliwa jest zmiana celów biznesowych albo, w skrajnym przypadku, zakończenie projektu.

Jednym z dokumentów, które mogą podlegać zmianie w wyniku realizacji procesu PMI:Zintegrowane Zarządzanie Zmianami jest plan projektu, do którego włączony jest także dokument otwarcia. PMI nie opisuje metod, które byłyby poświęcone modyfikacji tej właśnie części planu projektu.

W metodzie PRINCE Uzasadnienie Biznesowe żyje. W kilku procesach nakazywane jest wykonywanie oceny wpływu zdarzeń na Uzasadnienie Biznesowe. W procesie PRINCE:Badanie Zagadnień Projektu należy wstępnie ocenić, jaki wpływ rozważane zagadnienie ma na przewidywane korzyści uzyskiwane z projektu. Tak przygotowana ocena jest rozpatrywana w procesie PRINCE:Przegląd Statusu Fazy. W procesie tym należy rozpatrzyć wszystkie czynniki – nie tylko zagadnienia, ale np. stan prac – które mogą mieć wpływ na Uzasadnienie Biznesowe. Wynikiem przeglądu (albo bieżących zaleceń płynących ze strony Rady Projektu) może być wykonanie procesu PRINCE:Podejmowanie Akcji Korygujących. Działania tego typu z założenia mieszczą się w dopuszczalnych granicach tolerancji, jednak także w tym przypadku należy sprawdzić, czy nie mają one wpływu na Uzasadnienie Biznesowe. Metoda nie mówi jasno, co należy zrobić, jeśli w tych procesach wpływ na Uzasadnienie Biznesowe zostanie stwierdzony. Możliwą akcją może być w tym przypadku wykonanie procesu PRINCE:Eskalowanie Zagadnień Projektu. Tutaj też należy rozważyć wpływ zagadnienia na Uzasadnienie Biznesowe. Wynikiem eskalacji zagadnień projektu może być PRINCE:Tworzenie Planu Wyjątków, po którym może nastąpić proces PRINCE:Modyfikowanie Planu Projektu. Modyfikowanie planu projektu jest także standardowym wynikiem realizacji procesu PRINCE:Planowanie Fazy. Jeśli zmiany w planie projektu są poważne, należy wykonać proces PRINCE:Modyfikowanie Uzasadnienia Biznesowego. Proces ten może być także wykonywany w innych okolicznościach, na przykład gdy zmienia się biznesowe środowisko realizacji projektu, gdy zmieniają się warunki dostępności zasobów, gdy zmienia się sytuacja podwykonawców, gdy konieczna jest zmiana terminu zakończenia projektu. W takich sytuacjach Rada Projektu musi rozważyć wszystkie konsekwencje opisywanych zdarzeń dla Uzasadnienia Biznesowego i odpowiednio je zmodyfikować. Do wprowadzenia takich zmian konieczne może być uzyskanie akceptacji wyższych poziomów organizacyjnych, np. kierownictwa firmy. Po sporządzeniu wszystkich planów związanych z realizacją nowej fazy albo zmianą sposobu realizacji projektu, konieczne jest podjęcie decyzji w kwestii kontynuacji realizacji projektu. Temu celowi służy proces PRINCE:Zatwierdzanie Planu Fazy lub Planu Wyjątków. Uzasadnienie Biznesowe musi być porównane z jego początkową wersją, żeby stwierdzić, czy projekt wart jest kontynuowania. Możliwe jest podjęcie decyzji o rozpoczęciu następnej fazy albo o zakończeniu projektu.

W modelu CMMI istnieją dwie praktyki związane ze sterowaniem celami biznesowymi. Praktyka CMMI:Ustanowienie Celu Projektu poza pierwotnym ich ustaleniem nakazuje cele te modyfikować zgodnie z potrzebami. Model nie precyzuje, w jaki sposób potrzeby takie mogą się przejawiać. Jedną z akcji podejmowanych w wyniku realizacji praktyki CMMI:Zarządzanie Efektywnością Projektu, jeśli cele jakościowe i związane z efektywnością projektu nie mogą być osiągnięte, może być zmiana tych celów. Analogiczna akcja może być wykonana w odniesieniu do zarządzanego statystycznie podprocesu, jeśli sposób jego realizacji nie spełnia oczekiwań – zezwala na to praktyka CMMI:Monitorowanie Efektywności Wybranych Podprocesów.

W metodzie PRINCE Rada Projektu na bieżąco kontroluje sytuację biznesową i modyfikuje Uzasadnienie Biznesowe. Model CMMI umożliwia w trakcie realizacji projektu wprowadzanie zmian w parametrach procesów wpływających na cele biznesowe firmy. W standardzie PMI pośrednio mówi się o możliwości wprowadzenia zmian w uzasadnieniu biznesowym.

Ocena efektu biznesowego

Tak jak to było powiedziane w podrozdziale Ogólne podejście na początku niniejszego rozdziału, efekt biznesowy projektu nie zawsze i nie z każdego punktu widzenia może być oceniany w momencie kończenia projektu. Ocena efektu biznesowego nie musi być utożsamiana z odbiorem prac projektu. Łatwiej jest ocenić efekt biznesowy projektu w momencie jego kończenia z punktu widzenia wykonawcy niż z punktu widzenia użytkownika produktów projektu.

W standardzie PMI projekt jest kończony poprzez wykonanie procesu PMI:Administracyjne Zamknięcie. Proces ten – ani żaden inny – nie odnosi się do problemu osiągnięcia celów biznesowych przez żadną z zaangażowanych stron.

PRINCE jako jedyny ze standardów w procesie Identyfikacja Akcji Następujących odnosi się do problemu weryfikacji uzyskania celów biznesowych. Jednym z dwóch celów tego procesu (obok ustalenia sposobu załatwienia problemów wykrytych a nie załatwionych w czasie realizacji projektu) jest planowanie akcji oceniających spełnienie stawianych przed projektem celów biznesowych. Należy wskazać te z celów biznesowych opisanych w Uzasadnieniu Biznesowym, które będą mierzone po formalnym zakończeniu projektu. Dla każdego celu należy precyzyjnie określić sposób mierzenia. Najlepiej żeby miary takie mogły być porównywane do hipotetycznej sytuacji, w której produkty projektu nie są użytkowane. Powinny być ustalone daty przeprowadzenia przeglądów biznesowych celów projektu oraz ich plany. Celem projektu nie jest przeprowadzenie tych przeglądów – proces PRINCE:Identyfikacja Akcji Następujących jest jednym z elementów kończenia procesu.

W modelu CMMI nie ma procesów ani praktyk związanych z zakończeniem projektu. W modelu nie ma więc miejsca na stwierdzenie, czy dzięki realizacji projektu zwiększyły się dochody firmy, zwiększył się udział firmy w rynku czy osiągnięto inny cel biznesowy. Natomiast model poświęca dużo uwagi pośredniemu przyczynianiu się projektów do osiągania celów biznesowych – usprawnianiu procesów realizacji projektów.

Ocena efektów biznesowych tego typu może odbywać się – podobnie jak wypracowanie celów biznesowych – na dwa sposoby. Dobrze zorganizowana firma po wykonaniu każdego wykonanego procesu realizując ogólną praktykę CMMI:Wybór Informacji Ulepszających powinna rozważyć, czy sposób jego wykonania może wzbogacić firmowe repozytorium dobrych praktyk. Najbardziej zaawansowane ogólne praktyki mające na celu usprawnienie sposobów realizacji procesów wchodzą w skład 5 poziomu dojrzałości. Efektem wykonania procesu powinno tu być usunięcie przyczyn problemów – dzieje się to w wyniku realizacji praktyki CMMI:Naprawianie Podstawowych Przyczyn Problemów.

Zbliżony cel, ale odnoszący się do całości projektu, ma praktyka CMMI:Dodawanie do Zasobów Procesu Organizacyjnego. W wyniku jej wykonania sposoby realizacji procesów w firmie powinny być wzbogacone o doświadczenia uzyskane w trakcie realizacji projektu. Ulepszenia takie mogą się odnosić do procesów, sposobów ich realizacji czy miar stosowanych do kontroli procesu. Wynikiem tej praktyki może być także pojawienie się nowych procesów w firmowym repozytorium.

PRINCE jest konsekwentnie nastawiony na obserwowanie celu biznesowego – od rozpoczęcia projektu aż po jego zakończenie i dalej, do czasu eksploatacji produktu projektu. PMI w ogóle nie odnosi się do problemów związanych z uzyskaniem i oceną efektu biznesowego. Zgodnie z przyjętym podejściem, w którym środkiem służącym do uzyskania celów biznesowych firmy jest sprawna realizacja projektów, model CMMI nakazuje włączenie do zasobów firmy najlepszych praktyk wypracowanych w trakcie realizacji projektu.

Porównanie zarządzania strukturami organizacyjnymi

Ogólne podejście

Organizacja projektu jest to zbiór ról występujących ze względu na realizację projektu oraz relacje występujące pomiędzy tymi rolami. Role są przypisywane osobom zaangażowanym w realizację projektu. W trakcie realizacji projektu osoby pełniące role mogą być zmieniane, chociaż zmian takich w miarę możliwości należy unikać. Podstawowe relacje zachodzącą pomiędzy rolami to:

Podporządkowanie
Współdziałanie
Ustalenia

Najważniejsza relacja to relacja podporządkowania, czasami nazywana relacją raportowania, wyznacza upoważnienia do wydawania poleceń. Polecenia te odnoszą się do konkretnych obszarów zarządzania – przede wszystkim do obszaru tworzenia produktu projektu ale także do innych obszarów: np. do zarządzania kosztami, ryzykiem, jakością czy personelem. Relacja podporządkowania pośrednio wyznacza drugą relację – tworzenia zespołów. Niniejszy rozdział zajmuje się relacją podporządkowania i konsekwencjom decyzji dotyczących jej określenia.

Współdziałanie jest to relacja, które zwykle polega na przekazywaniu wyników prac pomiędzy zespołami albo rolami. Sposoby współdziałania zwykle są opisane w planie projektu.

Trzecią relacją wiążącą role występujące w projekcie są ustalenia, czyli zobowiązania zawierane pomiędzy dwoma lub więcej podmiotami, mające na celu uzyskanie określonego efektu. Ustalenia mają charakter tymczasowy – powstają w wyniku zidentyfikowania potrzeby podjęcia ustalenia i kończą się w momencie uzyskania pożądanego efektu. Wypracowywanie i koordynacja ustaleń jest jednym z podstawowych zajęć kierownika projektu (ale mogą one być także zawierane na innych poziomach organizacyjnych). Można powiedzieć, że ustalenia są to „mini-projekty” realizowane w ramach projektu.

Relacja podporządkowania wyznacza statyczną strukturę organizacyjną. Dwie role wchodzą do tego samego zespołu, jeśli są podporządkowane tej samej roli nadrzędnej. Do zespołu należy zawsze także jego kierownik. Zespoły mogą być złożone albo elementarne. Zespół projektu to wszystkie role pośrednio lub bezpośrednio podporządkowane kierownikowi projektu. Kierownik projektu jest to rola, której główną odpowiedzialnością jest osiągnięcie przez projekt stawianych przed nim celów, czyli zapewnienie sukcesu projektu. Zespół elementarny to taki, w którym żadnej jego roli – oprócz kierownika – nie jest podporządkowana żadna inna rola. Przykładem zespołów elementarnych są zespoły techniczne, których celem jest produkcja określonych produktów lub półproduktów. Zespołem elementarnym może być też na przykład biuro projektu albo zespół zapewnienia jakości. W ramach organizacji projektu wyróżniamy organizację wewnętrzną i zewnętrzną. Wewnętrzna organizacja projektu jest to organizacja zespołu projektu. Zewnętrzna organizacja jest to zbiór ról nie podlegających (pośrednio ani bezpośrednio) kierownikowi projektu. Główną rolą zewnętrzną jest właściciel projektu (często nazywany sponsorem). Właściciel projektu uruchamia projekt oraz podejmuje decyzję o jego – planowym lub przedwczesnym – zakończeniu. Do organizacji zewnętrznej należą także relacje z zewnętrznymi rolami koniecznymi do realizacji projektu, na przykład relacje z poddostawcami czy relacje z przyszłymi użytkownikami produktu projektu.

W każdym projekcie występują działania zarządcze oraz działania nastawione na realizację produktów projektu – działania takie nazywane są pracami technicznymi lub pracami specjalistycznymi. Poziom zarządzania związany z bezpośrednią odpowiedzialnością za realizację prac technicznych jest to poziom techniczny a zespoły występujące na tym poziomie to zespoły techniczne.

Rysunek 7. Elementy organizacji projektu

PRINCE wyróżnia cztery poziomy zarządzania:

1. Zarządzanie firmą lub programem

2. Kierowanie projektem

Częścią kierowania projektem jest

− Zapewnienie, że projekt przebiega właściwie (zapewnienie projektu)

3. Codzienne zarządzanie projektem

Częścią codziennego zarządzanie projektem jest

− Wykonywanie prac wspomagających (wspomaganie projektu)

4. Zarządzanie zespołami

Rysunek 8. Struktura organizacyjna wg. metody PRINCE 2

Najwyższy poziom – zarządzanie firmą lub programem – zajmuje się najważniejszymi dla projektu zagadnieniami. Zaangażowanie tego poziomu zarządczego jest większe, jeśli projekt jest częścią większego przedsięwzięcia – zbioru projektów, czyli programu – zaś mniejsze, jeśli projekt nie musi być koordynowany bezpośrednio z innymi projektami.

Odpowiedzialnością Komitetu Sterującego jest ogólne kierowanie projektem. Komitet Sterujący odpowiada za sukces projektu. Komitet Sterujący działa w ramach uprawnień przyznanych mu przez kierownictwo firmy lub programu. Komitet Sterujący w szczególności odpowiada za osiągnięcie celów określonych w uzasadnieniu biznesowym projektu.

W skład Komitetu Sterującego powinny wchodzić co najmniej trzy osoby:

Sponsor, kierujący pracami Komitetu
Przedstawiciel użytkownika
Przedstawiciel wykonawcy

Rozmiar Komitetu Sterującego, nawet w przypadku dużych projektów, nie powinien przekraczać sześciu osób.

Zapewnienie projektu polega na weryfikacji – w imieniu Komitetu Sterującego – czy projekt jest realizowany we właściwy sposób.

Codzienne zarządzanie projektem jest podstawową funkcją Kierownika Projektu. Kierownik Projektu ma uprawnienia określone przez Komitet Sterujący i w ramach tych uprawnień odpowiada za wyprodukowanie pożądanych produktów o właściwej jakości w zaplanowanym czasie i budżecie.

Część czynności koniecznych do codziennego kierowania zespołem Kierownik Projektu może powierzyć innym, wspomagającym go osobom. Czynności takie to np. opracowywanie szczegółowych harmonogramów, zapewnienie właściwego obiegu informacji w projekcie.

Zarządzanie zespołami polega na zapewnieniu wyprodukowania w ramach projektu określonych przez Kierownika Projektu produktów mających wymaganą jakość.

Standard PMI wyróżnia następujące podstawowe role związane z organizacją projektu;

Sponsor
Kierownik Projektu
Zespół Zarządzający Projektem
Organizacja wykonująca projekt
Klient
Użytkownik
Członkowie zespołu projektu

Opis powyższych ról jest przedstawiony w standardzie dość ogólnikowo. Sponsor jest to osoba odpowiedzialna za dostarczenie zasobów potrzebnych do realizacji projektu. Kierownik Projektu odpowiada za zarządzanie projektem. Zespół Zarządzający Projektem są to osoby bezpośrednio zaangażowane w zarządzanie projektem. Organizacja wykonująca to ta, która zatrudnia członków zespołu projektu. Klient jest to podmiot – osoba lub organizacja – kupujący produkt projektu. Użytkownik jest to podmiot, który będzie bezpośrednio wykorzystywać produkty projektu. W wielu projektach klient i użytkownik są to te same podmioty. Członkowie zespołu projektu to osoby podporządkowane kierownikowi projektu, które biorą udział w wytworzeniu produktu projektu.

W modelu CMMI wymienia się następujące role organizacyjne:

Kierownik Projektu
Kierownik
Zintegrowany Zespół
Klient

Kierownik Projektu jest to osoba odpowiedzialna za planowanie, kierowanie, kontrolowanie, strukturyzację i motywowanie projektu. Kierownik Projektu jest także odpowiedzialny za usatysfakcjonowanie klienta.

Kierownik jest to osoba odpowiedzialna za techniczne i administracyjne kierowanie i zarządzanie zgodnie z powierzonymi uprawnieniami.

Zintegrowany zespół jest to grupa ludzi z uzupełniającymi się umiejętnościami i doświadczeniem, którzy są zaangażowani i wspólnie odpowiedzialni za dostarczenie określonego produktu.

Klient jest to strona odpowiedzialna za zaakceptowanie produktu i zatwierdzenie płatności. Klientem może być projekt wyższego poziomu.

Organizacja projektu najdokładniej przedstawiona jest w metodzie PRINCE 2. Metoda ta – w przeciwieństwie do pozostałych – podaje gotową do zastosowania strukturę organizacyjną projektu. Elementami tej struktury, nie występującymi w pozostałych standardach, są Komitet Sterujący, Zapewnienie Projektu oraz Wspomaganie Projektu.

Standard PMI oraz model CMMI w opisie realizowanych procesów koncentrują się wyłącznie na realizowanych czynnościach i nie wskazują odpowiedzialności za wykonywanie tych czynności. Rozwiązania organizacyjne – poza ogólnym zarysem – nie są podawane w tych opracowaniach.

Szczególnie mało uwagi zagadnieniom organizacyjnym poświęca model CMMI, który ogranicza się do podania słownika pojęć z tego zakresu.

W każdym standardzie występuje rola Kierownika Projektu. W metodzie PRINCE 2 osoba ta działa pod nadzorem Sponsora, do którego należy podejmowanie zasadniczych decyzji związanych z projektem. Sponsor jest najważniejszą osobą zaangażowaną w realizację projektu. Rola Sponsora w standardzie PMI jest inna niż w metodzie PRINCE 2 i polega na zapewnieniu środków do realizacji projektu. Rola ta odpowiada roli przedstawiciela wykonawcy w metodzie PRINCE 2. Takie określenie roli Sponsora w standardzie PMI wynika z ogólnego podejścia do projektu – w PMI projekt jest rozpatrywany z punktu widzenia wykonawcy.

Model CMMI wprowadza nie występujące w pozostałych standardach pojęcie zintegrowanego zespołu. Wynikiem wprowadzenia zintegrowanych zespołów jest przeniesienie oddziaływań, które przy innych rozwiązaniach występują pomiędzy zespołami, do wnętrza zespołu. Rozwiązanie takie zmniejsza liczbę koniecznych do zarządzania zewnętrznych interakcji zespołów.

Struktura procesów organizacyjnych

W procesach dotyczących organizacji projektu można wyróżnić dwie główne grupy:

· Określenie struktur organizacyjnych

· Modyfikację struktur organizacyjnych

Rysunek 9 pokazuje strukturę procesów zarządzania organizacją projektu.

W wykazie grup obszaru organizacji nie uwzględniono grupy odpowiedzialnej za funkcjonowanie struktur organizacyjnych. Funkcjonowanie tych struktur jest równoważne całości realizacji projektów we wszystkich obszarach zarządzania – jak powiedzieliśmy wcześniej, relacja podporządkowania może dotyczyć wszystkich obszarów zarządzania projektami. W związku z tym opis takiej grupy procesów musiałby powtarzać wszystkie inne informacje związane z zarządzaniem projektami zawarte w niniejszym opracowaniu.

Rysunek 9. Struktura procesów zarządzania organizacją projektu

Celem procesów określenia struktur organizacyjnych jest określenie ról w projekcie, wskazanie obowiązujących relacji oraz dokładne zdefiniowanie tych relacji dla wszystkich łączonych nią ról.

Funkcjonowanie struktur organizacyjnych jest to realizacja relacji organizacyjnych w codziennym życiu projektu. Głównymi czynnościami w ramach tej grupy funkcji są wydawanie poleceń związanych z realizacją projektu i rozliczanie z wykonywania tych poleceń.

Określenie struktur organizacyjnych

Określenie struktur organizacyjnych w standardzie PMI odbywa się w procesie PMI:Planowanie Organizacji. Podstawą do określenia tych struktur są interfejsy projektu, które określają sposoby raportowania (podporządkowania) pomiędzy jednostkami organizacyjnymi oraz osobami zaangażowanymi w projekt. Interfejsy techniczne wpływają na określenie relacji współdziałania pomiędzy podmiotami zaangażowanymi w realizację projektu. Projekty są realizowane w firmach mających określoną strukturę i doświadczenia – czynniki te także wpływają na określenie struktur organizacyjnych projektu. Struktura firmy może wpłynąć na zakres odpowiedzialności kierownika projektu. Inaczej określana jest jego odpowiedzialność w firmach mających strukturę projektową, a inaczej w firmach mających strukturę funkcjonalną. Przy strukturze funkcjonalnej część odpowiedzialności za jakość prac technicznych spoczywa na kierownikach zespołów funkcjonalnych, podczas gdy w firmach o strukturze projektowej kierownik projektu zawsze odpowiada za całość prac, w tym także za ich jakość techniczną. Kierownicy projektów mają skłonność do powtarzania rozwiązań organizacyjnych, które w przeszłości gwarantowały sukcesy prowadzonych przez nich projektów. Standard PMI zwraca także uwagę na rolę teorii organizacyjnych w planowaniu struktur projektu, ale nie jest wskazywana żadna konkretna teoria.

Wynikiem planowania organizacyjnego jest przypisanie ról i odpowiedzialności do udziałowców. Dla każdej fazy należy określić zestaw odpowiedzialności każdego zaangażowanego udziałowca. Relacja podporządkowania powinna być przedstawiona w postaci graficznej. Szczególnym rodzajem prezentacji graficznej jest OBS (Organizational Breakdown Structure; Struktura Podziału Organizacji), która wskazuje, które prace powinny być wykonywane przez poszczególne elementy struktury organizacyjnej. OBS przypisuje elementy WBS do struktury organizacyjnej. Dla każdego elementu struktury organizacyjnej należy podać jego pełny opis, zawierający w szczególności zakres odpowiedzialności.

W metodzie PRINCE 2 planowanie struktur organizacyjnych odbywa się stopniowo. Ogólny zarys struktur organizacyjnych projektu (Komitet Sterujący, Kierownik Projektu....) jest wyznaczony przez metodę. W trakcie startowania projektu w procesie PRINCE:Wyznaczenie Komitetu Sterującego i Kierownika Projektu, Kierownik Projektu i Sponsor doprecyzowują pomiędzy sobą podział ról. Następnie, także na podstawie predefiniowanych dla PRINCE zasad, w procesie PRINCE:Projektowanie Zespołu Zarządzającego Projektem odbywa się ostateczne ustalenie struktury tego zespołu. Za proces ten wspólnie odpowiadają Sponsor i Kierownik Projektu. Uszczegółowiane są obowiązki członków zespołu. Zespół powinien być zaprojektowany tak, żeby uwzględniał interesy wykonawcy, klienta i użytkownika produktów projektu. Wynikiem realizacji procesu jest struktura zespołu zarządzającego projektem. Zespoły w strukturze organizacyjnej są reprezentowane przez ich kierowników. Opis struktury organizacyjnej zespołu zarządzającego projektem jest włączany do Dokumentu Otwarcia w procesie PRINCE:Kompletowanie Dokumentu Otwarcia. Struktura organizacyjna jest ostatecznie zatwierdzana przez Komitet Sterujący w procesie PRINCE:Zatwierdzenie Projektu.

W modelu CMMI praktyką związaną z planowaniem organizacji jest CMMI:Planowanie Zaangażowania Udziałowców. Zidentyfikowani powinni być wszyscy udziałowcy biorący udział w projekcie oraz wszystkie wiążące ich relacje.

Metoda PRINCE 2 dostarcza gotowe ramy organizacyjne dla wszystkich projektów. Wskazywane są procesy, w których stopniowo należy zaplanować i zatwierdzić strukturę organizacyjną projektu. Standard PMI uwzględnia wpływ struktur organizacyjnych firmy realizującej projekt na organizację tego projektu. Model CMMI praktycznie właściwie wcale nie odnosi się do zagadnień organizacyjnych.

Modyfikowanie struktur organizacyjnych

Standard PMI nakazuje oceniać przydatność istniejącej struktury organizacyjnej do realizacji projektu. W przypadku nieefektywności struktury organizacyjnej należy zaplanować i wprowadzić zmiany usprawniające strukturę. Standard ten nie wskazuje technik, które byłyby stosowalne do modyfikacji struktur organizacyjnych – w tym celu powinny być wykorzystywane te same techniki co w przypadku planowania organizacji.

Struktura organizacyjna projektu musi być zweryfikowana przed rozpoczęciem każdej fazy. Ewentualna modyfikacja tej struktury odbywa się w procesie PRINCE:Planowanie Fazy. Zatwierdzenie zmienionej struktury zespołu zarządzającego projektem jest wykonywane przez Komitet Sterujący w procesie PRINCE:Zatwierdzanie Planu Fazy Lub Planu Wyjątków. Należy zwrócić uwagę, że przy planowaniu obsługi sytuacji wyjątkowych nie przewiduje się zmiany struktury organizacyjnej projektu.

W modelu CMMI dopuszcza się zmiany zestawu udziałowców w trakcie realizacji projektów. Możliwe są więc także zmiany relacji pomiędzy udziałowcami.

Wszystkie trzy analizowane standardy odnoszą się do problemu modyfikacji struktury organizacyjnej. We wszystkich standardach problem ten jest potraktowany dość ogólnie. Najwięcej uwagi poświęca mu metoda PRINCE 2, wskazując w których procesach modyfikacje struktury organizacyjnej powinny być proponowane i zatwierdzane.

Model zarządzania wiedzą o projektach

Wiedza o projektach

Zarządzanie projektami nastawione na wiedzę

Agregaty projektów

Rodziny projektów

Agregaty projektów

Jednolity model zarządzania portfelami

Podstawy zarządzania portfelami

Modele dojrzałości

Dojrzałość systemów zarządzania projektami

Dojrzałość metodyk zarządzania projektami

Meta-dojrzałość zarządzania projektami

Standardy i metodyki

Analiza ISO 21500 i porównanie z PMBoK® Guide

Siedem głównych standardów zarządzania projektami

Ogólne porównanie PMBoK, Prince 2 i CMMI

Szczegółowe porównanie PMBoK, Prince 2 i CMMI

Standardy PMI – spojrzenie krytyczne

Narzędzia Primavera a PMBoK

Zarządzanie jakością

Jakość w projektach informatycznych

Jakość dokumentów

Analiza

Analiza strategiczna

Analiza

Tworzenie tekstów analitycznych

Tematy ogólne i inne

Zarządzanie projektami

Projekty – punkt widzenia wykonawcy

Ryzyko w projektach informatycznych

Analiza zysków – kosztów

[1] Należy zauważyć liczne niespójności w opisie metody. Na przykład w opisie procesu PRINCE:Tworzenie Planu Wyjątków nie mówi się o konieczności przekazania proponowanego Planu Wyjątków do procesu PRINCE:Zatwierdzenie Planu Fazy lub Wyjątków, ale w opisie tego ostatniego jest informacja o przyjmowaniu przez proces Planu Wyjątków.

[2] Wydaje się, że diagram Ishikawy za podstawę bierze wynik prac i ewentualnie znaleziony tam problem, jego zastosowanie do zapewnienia jakości jest wtórne.