Sybena Consulting

Porównanie standardów zarządzania projektami

Strona główna	Wiedza	Kontakt
Projekty publiczne	Przedstawione porównanie dotyczy wersji standardów obowiązujących w 2003 roku. Na stronie znajduje się już tekst porównujący siedem głównych, podstawowych globalnych standardów zarządzania projektami (kliknij tu, żeby uzyskać): · PMBOK (wersja 2008), · Prince 2 (wersja 2009), · CMMI (wersja 1.3, 2010), · ISO 10006, · BS 6079, · IPMA Competence Baseline (wersja 3.0), · Japoński standard zarządzania projektami P2M. Wprowadzenie.. 2 Sposób porównania.. 2 Zawartość standardów... 2 Główne cechy standardów... 2 PMBOK ® PMI. 2 Techniki 2 Prostota, spójność, zwięzłość. 2 PRINCE 2 ®.. 2 Gotowa metoda. 2 Punkt widzenia klienta. 2 Wyniki prac. 2 CMMI ^SM.. 2 Jakość i ulepszanie. 2 Wspólna własność projektu. 2 Integracja firmy, projektu i wytwarzania produktu. 2 Wybrać czy połączyć?. 2 Wprowadzenie Niniejszy materiał opisuje próbę porównania standardów prowadzenia projektów. Wydaje się, że dwa aktualnie najbardziej popularne standardy to standard prowadzenia projektów amerykańskiej organizacji Project Management Institute - PMBoK ® PMI, metoda prowadzenia projektów PRINCE 2 ® opracowana przez brytyjską Central Computer and Telecommuniocation Agency. Do porównania dołączyłem opublikowany w 2002 roku model CMMI ^SM (Capability Maturity Model Integration) opracowany w projekcie sponsorowanym przez Departament Obrony Stanów Zjednoczonych. Główną organizacją zaangażowaną w realizację tego projektu jest Software Engineering Institute działający w ramach Carnegie Mellon University. Czwartym porównywanym produktem są Polskie Wytyczne Kompetencji IPMA, opracowane przez Stowarzyszenie Project Management Polska na podstawie IPMA (International Project Management Association) Competence Baseline. Słowo „standard” na oznaczenie tych produktów zostało wybrane dla uproszczenia opisu. Równie dobrze można byłoby używać słowa „sposób”, „metoda” czy „model”. Porównanie składa się z dwóch głównych części: porównania ogólnego i zestawu porównań szczegółowych. Porównanie ogólne z kolei zawiera część „obiektywną” i „subiektywną”. Zestaw porównań szczegółowych składa się z tylu części, ile wyróżniłem obszarów zarządzania projektami. Do porównań szczegółowych nie włączyłem wytycznych IPMA, ponieważ materiał ten opisuje tylko zakres wiedzy, jaką powinien mieć kierownik projektu, nie podając konkretnych rozwiązań wypełniających ten zakres. Sposób porównania Pierwsza część porównania opiera się na przyjętej przeze mnie systematyce obszarów zarządzania projektami. Wyróżniłem kilkanaście obszarów, pogrupowałem je w pewną hierarchię, a następnie za pomocą prostej skali oceniłem, czy standard zawiera opis każdego z tych obszarów. Druga część oceny ma charakter bardziej subiektywny. Zadaniem, które sobie postawiłem było wskazanie najważniejszych cech poszczególnych standardów. Żeby cechy te dobrze oddawały rzeczywiście najważniejsze właściwości rozważanych standardów, przyjąłem, że liczba takich cech dla każdego standardu nie powinna być większa niż dwa. Zawartość standardów Poniższy rysunek zawiera ogólny schemat, który określiłem na potrzeby porównania. W schemacie znajdują się hierarchicznie powiązane obszary odnoszące się do prowadzenia projektów. Dla każdego obszaru przyjąłem trzy poziomy uwzględnienia w standardzie. Pełny opis oznacza wyczerpujący, dogłębny działań koniecznych do zarządzania danym obszarem. Częściowy opis oznacza, że w standardzie znajdują się informacje dotyczące obszaru, ale nie stanowią one pełnej recepty na zarządzanie danym obszarem. Brak oznacza, że standard nie odnosi się do danego obszaru. Obiekty pomocnicze w hierarchii służą grupowaniu obszarów w logiczne całości. Struktura opisu standardów Projekty prowadzone są w Przedsiębiorstwach. Każda przedsiębiorstwo musi być zorganizowane w sposób lepiej lub gorzej wspomagający realizację projektów. Tego aspektu dotyczy obszar Struktura Organizacyjna Przedsiębiorstwa. W organizacji powinny być realizowane procesy wspomagające realizację projektów, np. prowadzenie repozytorium procesów, standardów czy też szkolenie personelu na potrzeby projektów. Obszar Procesy w Organizacji zawiera realizację procesów działających w organizacji na potrzeby prowadzonych przez tę organizację projektów. Złożony obszar Projekty zawiera cztery obszary. Podstawowe, specyficzne dla prowadzenia projektów obszary elementarne, zostały połączone w Obszary Zarządzania. Obszar, który nazwałem Biznes zawiera procesy i czynności związane z określeniem, monitorowaniem i realizacją celów biznesowych stawianych przed projektem. Obszar Struktura Organizacyjna to zasady i procesy związane z określeniem organizacji projektu. Produkt / Technologia to obszar zawierający procesy technologiczne związane z wytworzeniem produktów – od zdefiniowania wymagań na produkt do przekazania, wdrożenia, eksploatacji i wycofania z użytkowania. Wyróżnienie obszarów Biznes, Struktura Organizacyjna oraz Produkt / Technologia ma na celu zwrócenie uwagi na specyficzną naturę tych obszarów. Obszar Biznes jest w dużym stopniu sterowany wytycznymi spoza projektu, zwykle zarządzanie tymi celami leży poza kompetencjami kierownika projektu. Obszar Struktura Organizacyjna jest obszarem statycznym. Zasadnicze struktury organizacyjne są rzadko modyfikowane w trakcie realizacji projektu. Zwykle nie wyodrębnia się – inaczej niż w pozostałych elementarnych obszarach – procesów związanych z zarządzaniem organizacją projektu. Powodem wyróżnienia tego obszaru jest także jego decydujące znaczenie dla realizacji całego projektu. Przyjmuje się, że obszar Produkt / Technologia nie jest dziedziną zarządzania projektami. Umiejętności w tym obszarze są specyficzne dla poszczególnych dziedzin aplikacji. Jednakże umiejętności technologiczne stanowią jeden z zasadniczych czynników sukcesu projektu. Dodatkowym powodem uwzględnienia tego obszaru w obszarach związanych z zarządzaniem projektami jest dostarczenie przez standard CMMI ^SM niezależnego od dziedziny zastosowań modelu czynności związanych z opracowaniem i utrzymaniem produktów projektów. Zaproponowane wyodrębnienie tych trzech obszarów nie ma zasadniczego znaczenia dla meritum oceny standardów. Ale wydaje się, że struktura opisu obszarów dzięki temu zabiegowi zyskuje na przejrzystości. Obszary zarządzania składają się z trzech złożonych grup oraz z trzech obszarów samodzielnych. Do poszczególnych grup złożonych zostały włączone te obszary, pomiędzy którymi interakcje występują szczególnie często. Grupa, którą nazwałem Praca, zawiera obszary najbardziej bezpośrednio powiązane z zarządzaniem wykonywaniem prac w projekcie. Grupa Ludzie to obszary odnoszące się do czynności zarządczych związanych z ludźmi występującymi w projekcie. Grupa Obszar Jakości to obszary, które według przyjętych klasyfikacji odnoszą się do zagadnień związanych z uzyskiwaniem właściwej jakości przez procesy i produkty. Elementarny obszar Zakres (dla uproszczenia zapisu używam tu, jak i w opisach innych obszarów, nazwy Zakres a nie Zarządzanie Zakresem) to procesy związane z określeniem zestawu prac wykonywanych w projekcie. Zasadniczym pojęciem w tym obszarze jest zwykle WBS, czyli hierarchiczne rozbicie prac realizowanych w projekcie. Koszt jest to obszar zawierający procesy dotyczące określenia i realizacji budżetu projektu. Celem realizacji obszaru jest doprowadzenie do realizacji projektu w przyjętym budżecie. Celem realizacji procesów z obszaru Czas jest doprowadzenie do realizacji projektu w określonym czasie. Podstawowym pojęciem w tym obszarze jest harmonogram projektu. Obszar Jakość obejmuje wszystko co jest związane z możliwościami zaspokajania przez produkty projektu jawnych i ukrytych wymagań stawianych przed tymi produktami. Zasadniczymi pojęciami związanymi z jakością są funkcjonalność, niezawodność czy efektywność. Zarządzanie Konfiguracją to procesy mające na celu zapewnienie spójności wszystkich produktów pracy realizowanych procesów. Pomiary i Analiza to obszar grupujący procesy związane z wszelakimi pomiarami i analizą produktów i realizowanych procesów. Wyniki pomiarów i analiz są konieczne do podejmowania decyzji dotyczących realizacji innych procesów. Obszar Komunikacja to procesy związane z przetwarzaniem informacji w projekcie. Obejmuje zbieranie, magazynowanie, rozpowszechnianie, udostępnianie, archiwizowanie i usuwanie informacji. Obszar Personel jest odpowiedzialny za przyjmowanie, wykorzystanie oraz zwalnianie z projektu osób realizujących projekt. Obszar Społeczny obejmuje zagadnienia związane z relacjami interpersonalnymi w projekcie: przewodzenie, rozwiązywanie konfliktów, negocjacje itp. Obszar ten jest mocno powiązany z obszarami Komunikacja i Personel a został wyróżniony ze względu na zasadnicze znaczenie tego typu umiejętności dla powodzenia projektu. Integralność to specjalny obszar, którego celem jest zapewnienie spójności realizacji wszystkich pozostałych procesów. Obejmuje także spójność realizacji projektu z funkcjonowaniem organizacji realizującej projekty oraz z szerszym środowiskiem realizacji projektu. Zaopatrzenie to określenie dóbr, które na potrzeby projektu są realizowane poza nim, wybór dostawców tych dóbr oraz realizacja umów, na podstawie których dobra te są dostarczane do projektu. Zarządzanie Ryzykiem to procesy związane z identyfikowaniem, analizą, przeciwdziałaniem i reakcją na potencjalne problemy, które mogą wystąpić w projekcie. Zawartość standardu PMBOK ® PMI PMBoK ® PMI jest opracowywany przez praktyków, czyli przez ludzi, którzy na co dzień zajmują się zarządzaniem projektami. W PMBoK ® właściwie zupełnie nie ma zaleceń dotyczących procesów, które powinny być wykonywane w firmach realizujących projekty. Zarządzanie biznesem jest potraktowane dość skąpo: mówi się o uzasadnieniu biznesowym realizacji projektów, natomiast metodyka ta nic nie wspomina o zarządzaniu celami biznesowymi (modyfikacja celów w trakcie realizacji projektu, ocena biznesowych efektów projektu). PMBoK ® niewiele mówi o strukturze organizacyjnej projektów – wspomina się o kilku podstawowych rolach oraz o konieczności określenia tych struktur. Także bardzo niedużo jest powiedziane o tworzonym produkcie: w procesie planowania zakresu nakazuje się zdefiniować produkty projektu. Metodyka nie odnosi się do dalszych fazy cyklu życia produktu. Opis obszaru społecznego zawiera wyłącznie omówienie charakterystyk osobowościowych kierownika projektu, pomijając inne osoby uczestniczące w projektach. Zarządzanie konfiguracją jest wspomniane jako jedno z narzędzi (sztucznego) obszaru zarządzania integralnością. PMBoK ® w ogóle pomija zagadnienie wykonywania pomiarów w trakcie realizacji projektu. Obszarem (złożonym), który w PMBoK ® jest szczególnie dobrze opracowany jest zarządzanie pracą, czyli zarządzanie zakresem, kosztem i czasem. W tym zakresie PMBoK ® przedstawia pełny zestaw sprawdzonych, uznanych technik. PMBoK, w przeciwieństwie do innych opisywanych tu obszarów, sporo miejsca poświęca opisowi różnych sposobów organizacji przedsiębiorstwa realizującego projekty. Zawartość metody PRINCE 2 ® Podobnie jak PMBoK ®, PRINCE 2 ® w ogóle nie zajmuje się procesami zarządczymi realizowanymi w organizacjach wykonujących projekty. Elementem zarządzania produktem w tej metodyce jest planowanie zorientowane na produkt. Metodyka ta nie zawiera żadnego opisu cyklu życia produktu – jego zdefiniowanie jest zadaniem zespołu projektu. PRINCE 2 ® nie jest zainteresowany zarządzaniem zaopatrzeniem (dostawcami), twierdzi, że zadania zlecane zewnętrznym wykonawcom to takie same zadania jak zadania zlecane własnym członkom zespołu. PRINCE 2 ® zupełnie nie jest zainteresowany problemami społecznymi (międzyludzkimi), występującymi w trakcie realizacji projektu. Zarządzanie personelem jest widziane jako część zarządzania zasobami, bez uwzględnienia aspektów specyficznie ludzkich (np. szkolenie). PRINCE 2 ® nie zajmuje się procesem wykonywania pomiarów i analiz – chociaż wartości mierzalne, w szczególności np. progi tolerancji – zgodnie z tą metodą powinny być wyznaczane bardzo często. Zdecydowanie w porównaniu z innymi standardami PRINCE 2 ® najpełniej i najbardziej systematycznie zajmuje się obszarem zarządzania biznesem. Przeprowadzenie projektu polega na zdefiniowaniu uzasadnienia biznesowego, ciągłym jego monitorowaniu oraz zadbaniu, żeby przyszły użytkownik projektu osiągnął maksymalne korzyści. Zawartość modelu CMMI ^SM W CMMI ^SM biznes jest rozumiany dość wąsko, wyłącznie z punktu widzenia realizatora projektu. Podawanymi przykładami celów biznesowych są zwiększenie udziału w rynku, skrócenie cyklu wytwarzania produktu. Na temat struktur organizacyjnych CMMI ^SM mówi, że muszą one zostać określone; dość często występują odwołania do „odpowiednich udziałowców”. Obszar społeczny: zagadnienia związane z oddziaływaniami międzyludzkimi są zupełnie obce modelowi CMMI ^SM. CMMI ^SM, podobnie jak PRINCE 2 ®, traktuje ludzi tak jak każde inne zasoby, bez uwzględnienia ich specyfiki. W zakresie zarządzania komunikacją nie jest wymagane utworzenie planu zarządzania komunikacją (mówi się o planie zarządzania danymi, wydaje się że autorzy mają na myśli dane związane z produktem). Najciekawszym i najlepiej opisanym obszarem w CMMI ^SM jest zarządzanie (definiowanie, ulepszanie) procesami w organizacji realizującej projekty. CMMI ^SM jako całość może być scharakteryzowany właśnie jako opis tych procesów. Zawartość wytycznych IPMA Wytyczne IPMA – zgodnie z ich celem – zawierają opisy obszarów koniecznych do zarządzania projektami; nie są to pełne przepisy działania w tych obszarach i dlatego o żadnym obszarze nie można powiedzieć, że jego opis w wytycznych IPMA jest pełny, gotowy do wykorzystania w trakcie kierowania projektem. Główne cechy standardów PMBOK ® PMI Techniki W porównaniu z pozostałymi standardami, standard PMBOK ® PMI jest najmocniej ukierunkowany na usystematyzowany zestaw konkretnych, sprawdzonych technik i narzędzi zarządczych. Podstawą opisu każdego procesu jest zestaw technik, które mogą być wykorzystane do jego realizacji. Większość technik jest opisywana, niektóre tylko wskazywane – na przykład poprzez odniesienie do literatury. Techniki w standardzie PMBOK ® PMI są rozumiane szeroko. Pierwsza grupa to techniki mające postać technik i modeli formalnych. Przykładami mogą tu być Analiza Wartości Uzyskanej wykorzystywana jako metoda oceny postępu prac, analiza wrażliwości czy symulacje stosowane w trakcie ilościowej oceny ryzyka. W obszarze zarządzania jakością wskazywane są techniki oparte na graficznej analizie lub prezentacji danych – np. diagramy Ishikawy i diagramy Pareto. Następna grupa to opisy czynności, które muszą być wykonane, aby procesy były zrealizowane Na przykład jako technika wyszukiwania dostawców wskazywane są konferencje i ogłoszenia. Jako technika zarządzania personelem wskazywane są czynności budujące zespół (krótkie spotkania, imprezy wyjazdowe). Inna grupa to narzędzia „proceduralne”, czyli np. system zarządzania zmianami czy sposób odbioru prac projektu. PMBOK ® PMI często odwołuje się do narzędzi komputerowych. Do narzędzi zaliczane są też oceny ekspertów. Można odnieść wrażenie, że ta ostatnia kategoria została dodana głównie po to, żeby zestaw narzędzi był pełny: jeżeli zupełnie nie można podać konkretnej techniki, to należy spytać się mądrego, doświadczonego człowieka, który po prostu wie o co chodzi. Dwa pozostałe standardy również podają techniki realizacji funkcji i procesów, ale w sposób najbardziej systematyczny i pełny zestaw ten jest podany w standardzie PMBOK ® PMI. To się rzuca w oczy od pierwszego spojrzenia. Prostota, spójność, zwięzłość Standard PMBOK ® PMI jest najbardziej zwarty spośród trzech ocenianych. Jego opis zajmuje mniej więcej połowę tego miejsca, jakie zajmuje opis metody PRINCE 2 ® i jedną trzecią miejsca zajmowanego przez model CMMI ^SM. Percepcję standardu dodatkowo ułatwia przyjęty i konsekwentnie stosowany sposób prezentacji wiedzy. Wiedza dotycząca zarządzania projektami jest podzielona na dziewięć spójnych obszarów. Każdy obszar składa się z procesów, każdy proces ma dobrze określone wejście, techniki i wyjście. Istnieją diagramy powiązań procesów oraz opis produktów (wejść i wyjść) przekazywanych pomiędzy procesami. W porównaniu ze standardem PMBOK ® PMI, CMMI ^SM jest o wiele mniej systematyczny, szczególnie jeśli chodzi o opis wejść i wyjść z procesów. W PRINCE 2 ® powiązane wiedza jest porozrzucana po całym dokumencie, struktura dokumentu jest niejednorodna: zasadnicze jego części to procesy, składowe, techniki, opis produktów i dodatkowo jeszcze obszerny zestaw załączników. Taki sposób zredagowania dokumentu utrudnia – co najmniej pierwszy – kontakt z prezentowaną metodą. Standard PMBOK ® PMI jest to najbardziej uporządkowane kompendium wiedzy o zarządzaniu projektami. PRINCE 2 ® Gotowa metoda PRINCE 2 ® jest to pełny opis procesów zarządczych wykonywanych w trakcie realizacji projektu. Główną częścią książki opisującej tę metodę jest opis procesów, które trzeba wykonać od momentu podjęcia decyzji o rozpoczęciu prac nad projektem aż po jego zakończenia (a nawet dalej – do czynności, które należy wykonać po zakończeniu projektu, żeby ocenić przydatność produktów projektu dla użytkowników). Wszystkie procesy mają określoną kolejność ich wykonywania, wyniki realizacji procesów są przekazywane do ściśle określonych innych procesów. Zależności pomiędzy produktami i procesami oraz pomiędzy procesami są przedstawiane w przejrzystej postaci graficznej. W PRINCE 2 ® dokładnie wiadomo, co trzeba zrobić, żeby rozpocząć projekt, w jaki sposób projekt można przedwcześnie przerwać i jakie muszą być do tego podstawy. Podawane są opisy struktury produktów zarządczych. Opisane są role występujące w trakcie realizacji projektu. PRINCE 2 ® jest to gotowa do stosowania, dostosowana do określonych warunków organizacyjnych, metoda prowadzenia projektów. Punkt widzenia klienta „Klient nasz pan”? Zdecydowanie tak. Spośród trzech rozważanych standardów PRINCE 2 ® jest jedynym prezentującym konsekwentnie punkt widzenia klienta projektu. Podstawowym pojęciem związanym z biznesem jest w tym standardzie uzasadnienie biznesowe. Każdy projekt musi być uzasadniony biznesowo – zarówno z punktu widzenia klienta jak i wytwórcy. Ale PRINCE 2 ® prawie wcale nie poświęca uwagi uzasadnieniu biznesowemu działania wykonawcy. Prawdziwym dowódcą projektu jest przedstawiciel klienta, on podejmuje wszystkie zasadnicze decyzje związane z realizacją projektu. Główny przedstawiciel wykonawcy musi wchodzić w skład Rady Projektu, ale bardzo wyraźnie mówi się, że zasadnicze decyzje podejmuje przedstawiciel klienta, pozostałe osoby mają w Radzie Projektu tylko głos doradczy. Cele biznesowe klienta są widziane przez pryzmat celów klienta. Wydaje się że takie podejście jest nie do końca realistyczne: jeśli z rozważań (uwzględniających, oczywiście, także reakcję klienta, utratę reputacji wykonawcy i wszystkie inne możliwe negatywne czynniki) wykonawca uzyska przekonanie, że kontynuowanie projektu jest dla niego ostatecznie niekorzystne, to może on zadecydować o zakończeniu projektu – podobnie jak może to zrobić główny przedstawiciel klienta. W końcu realizacja projektu na podstawie kontraktu jest interakcją dwóch równych wobec tego kontraktu stron. Nasuwa się porównanie: tak jak nie można zmusić do urodzenia dziecka kobiety, która nie chce donosić ciąży (chociaż prawo aktualnie twierdzi co innego) – ojciec też niewiele ma tu do powiedzenia; tak nie można zmusić nikogo, żeby kontynuował projekt (nawet jeśli kontrakt nie przewiduje jego zerwania) – klient i prawo są dla wykonawcy tylko jednym z czynników warunkujących podjęcie decyzji. Wyniki prac Metoda PRINCE 2 ® jest nastawiona na uzyskiwane wyniki. Planowanie jest zorientowane na produkt. Wykonywane prace są widziane przez pryzmat tworzonych produktów. Takie podejście sprzyja uzyskiwaniu rzeczywistych efektów realizacji produktu. Konsekwencją techniczną takiego punktu widzenia jest na przykład występowanie Struktury Podziału Produktu zamiast Struktury Podziału Pracy. Takie podejście zdecydowanie promuje efektywność, a przede wszystkim skuteczność prac w projekcie. Żadna praca nie może być rozliczona, jeśli jej wynikiem nie jest konkretny efekt. Tak jak w szkole rzadko przyjmowane jest tłumaczenie ucznia zagrożonego dwójką: „Proszę Pani, ale ja się przecież uczyłem”, tak w PRINCE 2 ® praca jest na tyle istotna, na ile akceptowalne są jej produkty. Wydaje się, że w nastawieniu na produkt autorzy PRINCE 2 ® posunęli się zbyt daleko. Przykładem może być porównanie podejścia do jakości produktu i podejścia do jakości procesu. Podstawowa technika nastawiona na jakość produktu – przegląd jakości – jest bardzo dokładnie w osobnym rozdziale opisana. Zaleca się jej (częste) stosowanie w procesie wykonywania produktów, wiadomo co zrobić z wynikami przeglądu. Ale w wielu innych podejściach (np. normy serii ISO 9000) uważa się, że głównym sposobem uzyskiwania jakości jest poprawne wykonywanie procesów pracy – a nie weryfikowanie ich wyników po zakończeniu. W PRINCE 2 ®, co prawda, mówi się ogólnie, że należy wykonywać audity mające na celu sprawdzenie zachowywania standardów w trakcie realizacji procesów i że zlecanie auditów powinno się odbywać na poziomie Rady Projektu, ale żaden spośród procesów zarządczych nie jest odpowiedzialny za realizację tych auditów. CMMI ^SM Jakość i ulepszanie Jakość, a w szczególności ulepszanie sposobu realizacji projektów, jest celem i wszechobecnym tematem modelu CMMI ^SM. Spośród dwudziestu dwóch procesów co najmniej siedem – a więc prawie jedna trzecia – może być zaliczona do obszaru zarządzania jakością. Procesami tymi są Zapewnienie Jakości Procesu i Produktu, Analiza Przyczyn [błędów] i Usprawnianie, Innowacje i Wdrożenia Organizacyjne, Weryfikacja, Walidacja, Nastawienie na Proces Organizacyjny, Efektywność Procesu Organizacji, Ilościowe Zarządzanie Projektem. Ponadto dla każdego procesu podane są kryteria weryfikacji jego przebiegu oraz kryteria oceny produktów i półproduktów. Takie wysycenie zagadnieniami związanymi z jakością pozwala stwierdzić, że uzyskanie jakości procesu i produktu projektu jest jednym z głównych celów modelu CMMI ^SM i wyróżnia go spośród trzech rozważanych standardów. Wspólna własność projektu „Klient nasz pan”? Nie. Po podpisaniu kontraktu klient i wykonawca to dwie równe strony realizujące kontrakt. CMMI ^SM – inaczej niż np. PRINCE 2 ® – bardzo mocno podkreśla rolę wytwórcy w procesie realizacji projektu. To podejście jest dobrze widoczne przy określaniu pojęcia jakości w projekcie. Otóż wg. CMMI ^SM jakość jest to możliwość spełniania wymagań – jak na razie nic nowego. Ale ważne jest, skąd się biorą wymagania. Ich źródłem może być każdy udziałowiec projektu. Takie podejście na pierwszy rzut oka wydaje się dziwne. Przecież klient płaci, wymaga i td. Jednak po pewnym zastanowieniu się, takie podejście okazuje się wcale nie być takie dziwne. Po pierwsze: użytkownik nie zawsze jest w stanie sformułować wymagania. W mojej praktyce analityka prawie codzienną regułą jest podpowiadanie klientowi czy użytkownikowi wymagań. Powiem więcej: samą idea zawodu analityka jest wydobywanie wymagań od użytkowników. A zły byłby to analityk, który działałby tylko jak magnetofon. Po drugie: bezsensowne jest opieranie przebiegu projektu na wymaganiach, których wykonawca nie akceptuje. Powodem braku akceptacji może być na przykład brak możliwości realizacji wymagań. Prawdę mówiąc źródła wymagań jest jeszcze bardziej złożona. W największym w Polsce projekcie informatycznym (KSI ZUS) prawdziwym źródłem wymagań nie był ani wykonawca (Prokom) ani klient (ZUS), ale trzecia storna: prawodawca czyli Sejm. Być może świadomość rzeczywistych procesów rządzących definiowaniem wymagań mogłaby zmienić sposób realizacji tego projektu – wykonawca nie mógłby obarczać klienta pełną odpowiedzialnością za zdefiniowanie wymagań. Model CMMI ^SM obejmuje także sytuację, która wystąpiła w trakcie realizacji KSI ZUS. Dowolny udziałowiec projektu może być źródłem wymagań. Integracja firmy, projektu i wytwarzania produktu W kontekście prowadzenia projektów występują trzy obszary działania. Pierwszy z nich to funkcjonowanie firmy realizującej projekt. Organizacja ta nadzoruje czy też steruje realizacja projektu. Drugi obszar to samo zarządzanie projektem – do tej części zalicza się zwykle zarządzanie jakością, budżetem, czasem itp. Celem czynności zarządczych jest umożliwienie wytworzenia produktu. Środowisko realizacji projektu Standardowe spojrzenie na zarządzanie projektami koncentruje się wyłącznie na środkowym obszarze, czyli na „właściwym zarządzaniu projektami”. Jednakże trzy te obszary są ze sobą nierozerwalnie powiązane. Model CMMI ^SM stara się objąć swoim zasięgiem także funkcjonowanie firmy – w części dotyczącej środowiska realizacji projektów – oraz techniczny proces wytwarzania produktu. Według CMMI ^SM zadaniem firmy jest wypracowanie zasobów („środków trwałych”) koniecznych do realizacji projektów. Zasoby te to przede wszystkim sam sposób realizacji projektu oraz wszystkie techniki, wzorce, procedury czy sposoby wspomagające realizację projektów. Firma powinna najpierw ustanowić początkowe zasoby a potem ciągle je doskonalić. Doskonalenie odbywa się przede wszystkim na podstawie doświadczeń zebranych w trakcie realizacji projektów. Z zarządzaniem projektem musi także być zintegrowane wytwarzanie produktu. Integracji takiej sprzyja opis uogólnionego procesu wytwórczego, czyli czynności prowadzących od sformułowania wymagań do przekazania produktu użytkownikowi. CMMI ^SM dostarcza taki model. Model ten jest całkowicie zintegrowany z modelem zarządzania projektem. Wybrać czy połączyć? Wybór standardu zarządzania projektami powinien zależeć od dwóch czynników. Pierwszy z nich to rola organizacji w procesie realizacji projektów. Wybór powinien być uzależniony od tego, czy firma jest wykonawcą czy klientem projektu. Ponieważ PRINCE 2 ® bardzo mocny nacisk kładzie na efekty biznesowe projektu, metoda ta powinna być zalecana firmom będącym klientami projektów. Ponieważ PMBoK ® PMI został opracowany przez profesjonalistów zaangażowanych bezpośrednio w realizację projektów, standard ten powinien być zalecany firmom wykonującym projekty. A kiedy wybrać CMMI ^SM? Model ten opisuje w jaki sposób ulepszać procesy realizacji projektów. A więc, po pierwsze jest to narzędzie dla wykonawców projektów. Po drugie ulepszanie musi się odnosić do pewnego stanu początkowego – np. takiego, w którym wdrożono PMBoK ® PMI lub PRINCE 2 ®. Można więc uznać, że CMMI ^SM jest zaawansowanym standardem zarządzania projektami. A jeżeli, czytelniku, nie jesteś firmą realizującą projekty, ale zawodowcem, na przykład w dziedzinie produkcji oprogramowania, i chciałbyś rozpocząć trudną drogę zarządzania projektami, od czego powinieneś zacząć lekturę? Moja zdecydowana propozycja – zacznij od PMBoK ® PMI. Dostaniesz dużo podstawowej (czyli zasadniczej) uporządkowanej wiedzy. Kolejność stosowania standardów Opisywane standardy raczej nie są sprzeczne ze sobą. Można spróbować połączyć je ze sobą (prawdę mówiąc, cały tekst na tej stronie jest poświęcony próbie wzięcia z każdego z nich tego, co w nim jest najlepsze). W świetle tego, co napisałem wyżej, najlepiej jest wziąć proces realizacji projektu z PRINCE 2 ®, techniki pobrać z PMBoK ® PMI. A jak już ten sposób realizacji projektów ustabilizuje się, to do jego ulepszania można zastosować model CMMI ^SM . Sposób łączenia standardów
Co zrobić z ustawą Prawo Zamówień Publicznych? Co zrobić z Urzędem Zamówień Publicznych? Kto ma wygrywać publiczne przetargi? Czy najniższa cena oferty gwarantuje najniższy koszt? Program rozwoju sportu
Wiedza o projektach
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