Sybena Consulting

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

Strona główna	Wiedza	Kontakt
Projekty publiczne	Wprowadzenie. 1 BS 6079. 1 CMMI^SM.. 3 ICB. 4 ISO 10006. 5 P2M... 7 PMBOK® Guide. 8 Prince 2®. 9 Podsumowanie. 11 Literatura.. 12 Tematyka przedstawiona w niniejszym artykule jest streszczeniem jednego z rozdziałów większego opracowania poświęconego zarządzaniu wiedzą o projektach (Gasik, 2010). Wprowadzenie Zarządzanie projektami od kilkudziesięciu lat przeżywa fazę coraz bardziej intensywnego rozwoju, co jest połączone z rozwojem wiedzy o tym sposobie zarządzania. Istnieją czasopisma o globalnym lub lokalnym zasięgu poświęcone zarządzaniu projektami. Pisane są książki zawierające coraz bardziej wyspecjalizowaną wiedzę – także w języku polskim powstało ich co najmniej kilkadziesiąt. Szczególnym rodzajem publikacji są te, które starają się zawrzeć – a raczej uporządkować – wiedzę potrzebną do zarządzania projektami. Publikacje takie formułują swoje główne cele na różne sposoby. Niektóre z nich, jak PMBoK® Guide, przedstawiają całość struktury wiedzy o zarządzaniu projektami. Inne starają się opisać metodykę zarządzania pojedynczym projektem – tu przykładem może być Prince 2® albo japoński, uznawany dość powszechnie za najbardziej zaawansowany, standard P2M. Jeszcze inne patrzą na zarządzanie projektem jako na zestaw umiejętności, które powinien mieć ich kierownik – wtedy mamy do czynienia ze standardem kompetencji, przykładem może być publikacja ICB IPMA. Są wydawnictwa, które jawnie definiują się jako standardy, czyli dokumenty będące podstawą do oceniania czy coś jest wykonywane dobrze czy źle – do tej klasy należy norma ISO 10006. Omówimy także brytyjską normę BS 6079. Kolejna kategoria to dokumenty, które opisują projekty z punktu widzenia procesów realizowanych w organizacji i sposobów ich doskonalenia – są to modele dojrzałości projektowej, przykładem jest tu CMMI^SM. Do wszystkich tych wydawnictw – proszę purystów metodycznych, żeby nie mieli mi tego za złe – będę stosował nazwę „standard”. BS 6079 Krótka historia BS 6079 jest standardem zarządzania projektami. British Standard Institution najdłużej spośród wszystkich organizacji prowadzi prace standaryzacyjne w obszarze zarządzania projektami. W 1968 BSI opublikował standard opisujący podstawowe pojęcia dotyczące analizy budowy harmonogramu projektu (tzw. „technik sieciowych”) oznaczony jako BS 4335. Po rozlicznych modyfikacjach, zmianach nazw i ulepszeniach aktualnie standard nazywa się BS 6079, składająca się z czterech tomów, z których najważniejszy jest pierwszy – przewodnik po zarządzaniu projektami, którym się zajmiemy. Inne tomy to glosariusz pojęć, opis procesu zarządzania ryzykiem oraz opis zarządzania projektami w sektorze budowlanym. Co dokument zawiera? BS 6079 najpierw opisuje różne sposoby organizacji przedsiębiorstwa: organizację funkcjonalną, macierzową i nastawioną na projekty. Ze względu na to, że projekty są narzędziem wdrażania zmian w organizacjach, w części tej opisywane są także sposoby realizacji projektów z punktu widzenia wprowadzanych w przedsiębiorstwie zmian (np. psychologia i polityka zmiany). Część poświęcona procesowi zarządzania projektem opisuje proces planowania, jego główny produkt – plan projektu oraz proces nadzorowania projektu. Głównymi częściami procesu planowania są budowa Struktury Podziału Pracy (SPP) oraz tworzenie harmonogramu razem z podejmowaniem ustaleń dotyczących zasobów koniecznych do jego realizacji. Poza procesami głównymi istnieją procesy wspomagające – zapewnienie jakości (odnoszące się m. in. do zagadnień zdrowia i bezpieczeństwa), zarządzanie konfiguracją, zarządzanie ryzykiem, zarządzanie zaopatrzeniem, zarządzanie finansami, mierzenie wartości wypracowanej (EVA). Wyróżnionym procesem, mającym szczególne znaczenie dla realizacji projektu, jest rozwój personelu projektu. Głównymi zadaniami wykonywanymi w trakcie realizacji projektu są raportowanie, monitorowanie postępu, nadzorowanie, motywowanie właścicieli zadań oraz negocjacje. Czym ten dokument różni się od innych? BS 6079 wyróżnia się spośród innych standardów sposobem szerokiego określenia cyklu życia projektu. Projekt rozpoczyna się od fazy pomysłu, kiedy zainteresowane osoby szukają sposobów na usprawnienie działania organizacji. Następnie wykonywane są fazy spotykane w innych standardach, z których ważniejsze to analiza wykonalności, zatwierdzenie projektu, realizacja prac. Ale integralnymi częściami cyklu są także przekazanie produktu projektu do wykorzystania, faza działania produktu oraz faza zakończenia projektu, rozumiana jako wycofanie produktu z użytku. Przy tak zdefiniowanej strukturze cyklu życia łatwiej jest, w fazie oceny wykonalności, ocenić planowany efekt finansowy projektu. Zwykle od osób proponujących projekty wymaga się przedstawienia szacunków jego pełnego efektu finansowego, a nie tylko prac powodujących wykonanie produktu. Ale perspektywa taka jest charakterystyczna dla projektów inwestycyjnych. Dla projektów komercyjnych, realizowanych na potrzeby firm zewnętrznych, projekty kończą się, gdy klient odbierze produkty projektu i ureguluje związane z tym płatności. Chociaż, zgodnie z BS 6079, dla niektórych projektów komercyjnych można uwzględnić także fazę utrzymania produktu, kiedy wykonawca świadczy klientom odpłatne usługi utrzymaniowe. BS 6079 zawiera także rozważania dotyczące wprowadzania zmian w organizacjach. Zalecenia te, dotyczące m. in. polityki i psychologii, są formułowane w odniesieniu do zmian struktur organizacyjnych. Wydaje się, że zalecenia te mogą także być stosowane do innych rodzajów zmian, na przykład zmian procesów pracy. Spośród bardziej szczegółowych zagadnień w BS 6079 wyróżnia się podejście do relacji pomiędzy kierownikiem projektu a osobami odpowiedzialnymi za zadania. Relacje te mają charakter kontraktów. Takie podejście jest bardziej właściwe dla projektów realizowanych zewnętrznymi zasobami. Stosowanie takiego podejścia dla zadań wykonywanych przez członków pochodzących z organizacji odpowiedzialnej za całość projektu może sprzyjać dezintegracji zespołu projektu – „jestem odpowiedzialny tylko za swoje prace, żadnych innych zobowiązań nie podpisywałem”. BS 6069 jest jednym z nielicznych standardów, które poświęcają uwagę zagadnieniom związanym ze zdrowiem i bezpieczeństwem w środowisku projektów. CMMI^SM Krótka historia CMMI^SM jest modelem dojrzałości organizacji w zakresie zarządzania projektami. W późnych latach 80 XX. wieku Departament Obrony Stanów Zjednoczonych poszukiwał sposobu oceny firm zgłaszających się do realizacji projektów informatycznych w ramach kontraktów rządowych. W roku 1991 zespół pracujący w Software Engineering Institute Carnegie Mellon University opracował pierwszą wersję Capability Maturity Model (CMM®), służącego ocenie potencjalnych kontraktorów Departamentu Obrony. Następnikiem CMM® jest Capability Maturity Model® Integrated (CMMI^SM) opracowany także w Software Engineering Institute Carnegie Mellon University. Do publikacji w roku 2002 przeznaczono wersję 1.1. Aktualny model CMMI^SM, ma oznaczenie wersji 1.3 i dotyczy projektów wytwarzających produkty niezależnie od sektora zastosowania. Co dokument zawiera? CMM® używa pięciostopniowej skali do oceny dojrzałości organizacji. Poziomy te to: Początkowy (ad hoc, chaotyczny, Powtarzalny (w projektach świadomie powtarza się takie same działania), Zdefiniowany (firma ma zdefiniowany, obowiązujący sposób realizacji projektów), Zarządzany ilościowo (pozwalający przewidzieć parametry wyjściowe projektów, na przykład czas, na podstawie parametrów wejściowych, na przykład liczba punktów funkcyjnych), Optymalizujący (firma w sposób świadomy ciągle poprawia miary swoich procesów). Oceniane mogą być także osobno możliwości firmy w zakresie realizacji poszczególnych procesów – tu taj stosowana jest skala czteropoziomowa: Poziom Niekompletny to taki, w którym proces nie jest wykonywany, poziom Wykonywany to taki, w którym jesteśmy pewni, że proces jest w całości wykonywany, poziom Zarządzany to ten, w którym proces jest planowany i wykonywany zgodnie z planem, zaś poziom Zdefiniowany to ten, w którym firma ma określony dany proces a jego wykonywanie może się przyczynić do usprawnień. CMMI^SM opisuje cztery grupy procesów: Zarządzanie projektami, Zarządzanie procesami, Inżynieria oraz Wsparcie. Zarządzanie projektami, są to te obszary, które są bezpośrednio związane z zarządzaniem projektami – Planowanie projektu, Monitorowanie i sterowanie projektem, Zarządzanie uzgodnieniami z dostawcami, Zintegrowane zarządzanie projektami, Zarządzanie ryzykiem oraz Ilościowe zarządzanie projektem. Zarządzanie procesami są to obszary zawierające procesy realizowane w organizacji, konieczne do właściwej realizacji projektów. Obszarami tymi są: Definiowanie procesów firmy, Nastawienie firmy na procesy (czyli ich usprawnianie definiowane jakościowo), Szkolenia firmowe, Wydajność procesów (czyli ich usprawnienia definiowane z wykorzystaniem kryteriów ilościowych) oraz Zarządzanie efektywnością organizacji (monitorowanie efektywności i wprowadzanie do procesów nowych rozwiązań). Inżynieria – uogólnione (abstrakcyjne) obszary procesów związanych z wytwarzaniem produktów. Obszarami tymi są Opracowanie wymagań (koncentruje się na sposobie zdefiniowania wymagania), Zarządzanie wymaganiami (kontrolujący zmienność wymagań), Rozwiązania techniczne (tworzenie składowych produktu), Integracja produktu, Weryfikacja (sprawdzanie, czy wytworzono produkt zgodny ze specyfikacjami) oraz Walidacja (sprawdzenie, czy wytworzono produkt przydatny do wykorzystania w docelowym środowisku). Wsparcie jest to kategoria obszarów wspomagających realizowanie procesów z wszystkich trzech wcześniej wymienionych kategorii obszarów. Do tej kategorii obszarów zaliczane są Zarządzanie konfiguracją, Zapewnienie jakości produktu i procesu, Pomiary i ich analiza, Analiza (problemów) i podejmowanie decyzji, Analiza przyczyn (problemów) i usprawnianie (procesów). Czym ten dokument różni się od innych? Różnice pomiędzy CMMI^SM a innymi opisywanymi tu standardami wynikają w dużej części z głównego celu opracowania modelu: ocena i ulepszanie procesów zarządzania projektami w organizacji. 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ą. 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. Charakterystyczną cechą CMMI^SM jest też wspólna własność projektu przez wszystkich interesariuszy. Źródłem wymagań dla projektu może być każdy udziałowiec projektu. Użytkownik nie zawsze jest w stanie sformułować wymagania. Zauważmy, że istnieją projekty, w których głównym autorem wymagań nie są ani klienci ani wykonawcy – w projektach realizowanych ze względu na konieczność dostosowania organizacji do uregulowań prawnych źródłem wymagań (przynajmniej wysokopoziomowych) zwykle jest zewnętrzny względem projektu ustawodawca. 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. Trzeci obszar to wytwarzanie produktów. 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. Uzasadnia to dodanie do nazwy modelu literki „I” wskazującej na wysoki poziom zintegrowania modelu. ICB Krótka historia ICB jest standardem kompetencji kierowników projektów – jego głównym celem jest dostarczenie wytycznych koniecznych do oceny kompetencji kierowników projektów. W 1986 roku w Association of Project Managers (APM) w Wielkiej Brytanii powstała Grupy Standardów Zawodowych (Professional Standard Group, PSG). Prace tego zespołu doprowadziły do opublikowania zarysu kompendium wiedzy o zarządzaniu projektami w 1992 roku. Na podstawie tego kompendium tej strukturze wzorowana była pierwsza wersja opisu podstawowych kompetencji kierowników projektów wydana przez IPMA (do której należało APM) w 1998 roku. Aktualnie obowiązuje wersja trzecia ICB wydana w roku 2006. Co dokument zawiera? IPMA ICB jest standardem kompetencji kierowników projektów (także kierowników programów i portfeli). W związku z tym duża część dokumentu poświęcona jest wymaganiom dotyczącym certyfikowanych osób oraz procesowi certyfikacji. Sposób zarządzania projektami zalecany przez IPMA ICB wynika z opisu wymaganych kompetencji. Kompetencje kierowników projektów w IPMA ICB są dzielone na trzy grupy: kontekstowe, behawioralne i techniczne. Wiedza o zarządzaniu projektami zawiera się głównie w ogólnym opisie elementów kompetencji oraz opisie procesów związanych z tymi elementami kompetencji. Opis każdego obszaru kompetencji składa się z opisu ogólnego oraz możliwych kroków procesu, realizujących zadania danego obszaru. Ponadto, ponieważ ICB stanowi podstawę do czteropoziomowej oceny kompetencji, w każdym obszarze określono kompetencje dla każdego z czterech poziomów zaawansowania kierowników projektów. Kompetencje techniczne dotyczą podstawowych działań w zakresie zarządzania projektami. ICB wyróżnia 20 obszarów kompetencji technicznych. Niektóre z nich dotyczą poszczególnych faz – np. Rozpoczęcie projektu i Zamknięcie projektu. Definiując projekt należy uwzględnić obszary takie jak Sukces projektu, Interesariusze oraz Wymagania. Standardowymi, często spotykanymi w innych dokumentach, obszarami są Zakres i produkty, Zarządzanie kosztami i finansami (dodano obszar finansowania projektu), Zarządzanie ryzykiem i okazjami, Jakość, Czas i fazy projektu, Zaopatrzenie i kontrakty. ICB każe także zarządzać Zasobami, Informacjami i dokumentacją oraz Komunikacją. Do różnych poziomów organizowania projektów odnoszą się obszary Struktury projektowe, Organizacja oraz Praca grupowa. Postęp prac powinien być Raportowany i kontrolowany, w projektach zdarzają się Problemy, z których mogą wynikać Zmiany. Kompetencje behawioralne dotyczą kształtujących się w czasie realizacji projektu relacji między ludźmi. W obszarze tym wyróżnia się 15 obszarów składowych, na przykład Przywództwo, Zaangażowanie i motywacja, Samokontrola i Asertywność, umiejętność Redukcji napięcia. Kierownik projektu powinien się także cechować Otwartością, Kreatywnością, Nastawieniem na wynik oraz Skutecznością, żeby wymienić niektóre tylko jego cechy wymagane przez ICB. Kompetencje kontekstowe dotyczą sposobu oddziaływania zespołu projektu i środowiska organizacyjnego. W tej grupie istnieje 11 obszarów. Kierownik projektu powinien współpracować z organizacją realizującą projekt, kierownictwem programu i portfela (jeśli są realizowane). Powinien być kompetentny w zakresie wytwarzania produktu projektu. Powinien mieć także wiedzę o zagadnieniach związanych ze zdrowiem i bezpieczeństwem oraz regulacjami prawnymi, żeby wymienić tylko niektóre kompetencje kontekstowe wymagane przez ICB. Czym ten dokument różni się od innych? IPMA, inaczej niż inne organizacje (np. PMI), przyjęło podejście, w którym wiedza o zarządzaniu projektami jest opisana w tym samym dokumencie, w którym opisany jest także proces certyfikacji. IPMA ICB pokrywa zapewne największy zestaw tematów związanych z zarządzaniem projektami – jest ich 46. Liczba tematów jest równoważona przez ich dość ogólny opis, zwykle nieprzekraczający dwóch stron tekstu. Niektóre funkcje uważane zwykle za osobne obszary (np. zarządzanie konfiguracją) zostały zredukowane do pojedynczych akapitów; inne, na przykład „Zmiany” zostały wyodrębnione jako osobne elementy wiedzy – obydwie te funkcje często uważa się za składowe jednego obszaru, zarządzania integralnością projektu. W większości obszarów o wiedzy można mówić, że jest sygnalizowana, a nie opisywana. W ten sposób traktowana jest przede wszystkim wiedza procesualna, opisująca możliwe procesy realizacji projektów. Wynika to z roli dokumentu – kompetencja kierownika projektu może być realizowana poprzez różne sposoby wykonywania określonych funkcji; IPMA ICB nie narzuca określonych technik. IPMA ICB bardzo dużo uwagi poświęca zagadnieniom związanym z cechami osobowościowymi koniecznymi do kierowania projektami. Średni zespół z doskonałym kierownikiem prawdopodobnie będzie miał większą szansę na odniesienie sukcesu niż dobry zespół ze słabym kierownikiem. Elementami kontekstu projektu, którym inne omawiane standardy nie poświęcają zbyt wiele (lub wcale) uwagi są zagadnienia związane z ze zdrowiem, bezpieczeństwem i ochroną środowiska. Zagadnienia te w niektórych projektach mają znaczny wpływ na sposób realizacji projektu – przykładem mogą być projekty budowlane czy wojskowe. Innym elementem, nieopisywanym jawnie w żadnym innym standardzie, a wyodrębnionym jako osobne zagadnienie w IPMA ICB, są zagadnienia prawne – prawo i inne obowiązujące regulacje wywierają znaczny wpływ na projekty. Wielu kierowników spędza dużo czasu walcząc z regulacjami prawnymi – na przykład uruchamianie projektów unijnych wymaga takiej znajomości uregulowań, że w Polsce wyodrębniła się osobna grupa doradców świadczących usługi dokładnie w tym zakresie. ISO 10006 Krótka historia ISO 10006 jest standardem zarządzania jakością w projektach. Standard ISO 10006 Systemy zarządzania jakością – Wytyczne do zarządzania jakością w projektach został opublikowany po raz pierwszy przez ISO w 1997 roku w postaci zbliżonej do aktualnej. Następne wydanie zostało opublikowane w roku 2003 i zawierało zmiany o charakterze technicznym. Krajowe organizacje normalizacyjne publikują przetłumaczone wydania tego standardu. W Polsce dostępny jest standard PN-ISO 10006, wydany w 2005 roku. Aktualnie ISO planuje utworzenie światowego standardu zarządzania projektami ISO 21500, który zastąpi standard ISO 10006. Według aktualnego (ale nie pierwszego) planu jego publikacja jest przewidywana na drugą połowę 2012 roku. Porównanie pierwszej opublikowanej wersji roboczej ISO 21500 i PMBoK® Guide (Gasik, 2011) pokazuje, że standard ISO 21500 jest oparty na PMBoK® Guide. Co dokument zawiera? Norma ISO 10006 zawiera ogólne wytyczne dotyczące jakości w projektach i prezentuje podejście typu TQM: wszystkie procesy realizacji projektu wpływają na jakość projektu i jego produktów. Z takiego podejścia wynika, że wszystkie procesy realizacji projektu są przedmiotem tej normy. Dokument opisuje ogólne właściwości systemu zarządzania jakością w przedsięwzięciach, odpowiedzialność kierownictwa, zarządzanie zasobami, realizację wyrobu oraz pomiary, analizę i doskonalenie. Podstawą jakości jest właściwa organizacja, zaangażowanie kierownictwa, a przede wszystkim procesy, zorganizowane w sprawnie działający system – standard większą część swego niewielkiego rozmiaru poświęca właśnie procesom zarządzania projektami. Poza procesami składnikami systemu są orientacja na klienta, przywództwo, zaangażowanie ludzi, ciągłe doskonalenie, podejmowanie decyzji oraz wzajemnie korzystne powiązania z dostawcami. Aby kontrolować postęp w osiąganiu celów należy organizować przeglądy projektu. Zorganizowane powinno być zarządzanie zasobami, czyli personelem, wyposażeniem, finansami, urządzeniami czy informacjami. Norma zwraca uwagę na procesy dotyczące personelu, związane ze strukturą organizacyjną oraz tworzeniem i utrzymaniem właściwej atmosfery współpracy. To, co w innych standardach nazywa się zarządzaniem integralnością procesów, w normie ISO 10006 jest nazywane zarządzaniem interakcjami (pomiędzy procesami). Procesy te obejmują także rozpoczynanie i kończenie projektów oraz zarządzanie zmianą. Procesy dotyczące zakresu obejmują opisanie wyrobu, jego właściwości oraz sposoby ich pomiaru i oceny, a także definiowanie i nadzorowanie działań koniecznych do wykonania wyrobu. Norma zawiera procesy z obszarów zarządzania czasem, zarządzania kosztami, zarządzania ryzykiem, zarządzania zakupami. Osobna sekcja opisuje procesy dotyczące doskonalenia – pomiary i analizy oraz działania korygujące, zapobiegawcze i zapobiegające stratom. Czym ten dokument różni się od innych? Normę ISO 10006 można uznać za bardzo wysokopoziomowy dokument systematyzujący procesy zarządzania projektami. Zakres normy ISO 10006 można uznać za kanoniczny zakres zarządzania projektami. Jeśli ktoś chce poznać samo jądro dziedziny zarządzania projektami, to można mu polecić właśnie tę normę. Pewnym dodatkiem do podstawowego zestawu procesów są opisywane w normie procesy związane z pomiarami, analizą i doskonaleniem procesów zarządzania projektami. Norma nakazuje także ustanowienie w projekcie roli odpowiedzialnej za jakość i jej ciągłą poprawę. Ciekawe jest także wskazanie, że sukces projektu jest uwarunkowany nie tylko spełnieniem celów jego bezpośredniego klienta, ale i innych zainteresowanych podmiotów (chociaż wymagania klienta mają pierwszeństwo przed wymaganiami innych stron). Norma ISO 10006 jako jeden z pierwszych standardów uwzględnia czynniki społecznościowe w zarządzaniu projektami: zaleca się uwzględnianie powiązań interpersonalnych przy kompletowaniu zespołu projektu. Norma mocno akcentuje konieczność systemowego zarządzania projektami – czyli takiego podejścia, w którym wszystkie procesy ze sobą współpracują i są wspólnie nadzorowane i sterowane. Głównym narzędziem służącym kontrolowaniu zgodności z planem postępu prac są przeglądy projektów, w ramach których między innymi ocenia się skuteczność realizowanych procesów. Oryginalnym zaleceniem normy jest zalecenie wewnątrzprojektowej funkcjonalnej lub macierzowej struktury organizacyjnej – zwykle uważa się, że cechy te dotyczą organizacji wykonującej projekt, a nie samego projektu. P2M Krótka historia P2M jest metodyką zarządzania projektami. Japoński Przewodnik po zarządzaniu projektami i programami innowacji przedsiębiorstw (P2M) został opracowany na zlecenie japońskiego Ministerstwa Gospodarki, Handlu i Przemysłu. Prace były wykonywane przez Japońskie Forum Zarządzania Projektami (Japan Project Management Forum), będące częścią Stowarzyszenia Rozwoju Inżynierii (Engineering Advancement Association of Japan, ENAA). Aktualnie dokument jest własnością Stowarzyszenia Zarządzania Projektami Japonii (Project Management Association of Japan). Pierwszy tom standardu, zawierający ogólne informacje o projektach oraz programach, ukazał się po raz pierwszy w roku 2001. Następne wersje, zawierające niewielkie zmiany, ukazywały się do roku 2005. Co dokument zawiera? P2M składa się z czterech głównych części: Wprowadzenia, Zarządzania projektami, Zarządzania programami (pozostająca poza zakresem naszych rozważań) oraz Szczegółowych wzorców zarządzania, czyli opisu procesów zarządzania projektami z poszczególnych obszarów wiedzy. Projekt według P2M jest to „biznes tworzący wartość”. Najważniejszymi składowymi zarządzania projektem są podejście systemowe, cykl życia projektu, platforma współpracy projektu (tzw. „ba”), interesariusze projektu oraz wykorzystanie umiejętności zarządczych. Zarządzanie strategią projektu, pierwszy szczegółowy proces metodyki to włączanie projektu w tworzenie wartości korporacji. Zarządzanie finansami projektu ma na celu utworzenie struktury dostarczającej fundusze na potrzeby realizacji projektu. Systemowe zarządzanie projektem jest to podejście do rozwiązywania problemów oparte na pojęciu systemu, obejmującego całość zagadnienia, uwzględniające obiekty i cele jako jeden system mający wewnętrzne, strukturalne powiązania. Zarządzanie organizacją projektu jest to zarządzanie wspólnym udziałem w projekcie wielu osób, zespołów, działów organizacji, korporacji, grup itp. mających na celu wspólny cel – sukces projektu. Następny proces szczegółowy to Zarządzanie celami projektu. Proces ten obejmuje szczegółowe procesy zarządcze, w innych standardach uważane za samodzielne procesy: zarządzanie cyklem życia projektu, zarządzanie zakresem, zarządzanie czasem, zarządzanie kosztami, zarządzanie jakością, zarządzanie wartością wypracowaną, zarządzanie raportowaniem i zmianami, zarządzanie wytwarzaniem produktu. Osobnym procesem szczegółowym jest Zarządzanie zasobami projektu, czyli materiałami, usługami dostarczanymi spoza projektu, ludźmi, wiedzą, informacją oraz finansami. Szczegółowy proces Zarządzania ryzykiem przebiega w sposób zbliżony do nakazywanego przez inne standardy. P2M wyróżnia osobny proces Zarządzania technologiami informacyjnymi projektu, bez których nie jest możliwa realizacja prawie żadnego współcześnie realizowanego projektu. Z procesów Zarządzania technologiami informacyjnymi korzysta obszar Zarządzania komunikacją projektu, którego celami są przekazywanie idei istniejących w projekcie oraz rozumienie sytuacji i problemów z uwzględnianiem różnic pomiędzy pomysłami członków zespołu oraz różnic międzykulturowych pomiędzy nimi. Kolejny proces to Zarządzanie relacjami projektu z interesariuszami. Proces Zarządzania wartością projektu obejmuje obieg wartości w projekcie, w których zasoby takie jak doświadczenie i wiedza (najważniejszy zasób każdego projektu) są przekształcane w wartości oczekiwane przez klienta. Czym ten dokument różni się od innych? Metodyka P2M w oryginalny sposób patrzy na zarządzanie projektami. Dla mnie najważniejszą zmianą jest przedefiniowanie roli kierownika projektu: jego rola nie jest statyczna, czyli trzymanie się zapisów planu projektu. Kierownik projektu ma określony cel, jego zadaniem jest zrobienie w każdym momencie wszystkiego, żeby ten cel osiągnięć. Jaka jest więc rola planu projektu? Jest on przede wszystkim świadectwem dokładnego przemyślenia projektu i jego środowiska. To, co dotychczas było uważane za główne obszary wiedzy: zarządzanie harmonogramem, jakością czy raportowaniem jest uznawane przez P2M tylko za środek prowadzący do osiągnięcia celu projektu. P2M zwraca uwagę na decydujące znaczenie posiadania wiedzy, aby można było zarządzać projektem: dostarczanie wartości jest to właśnie przekształcanie wiedzy. Wyodrębnienie zarządzania technologiami informacyjnymi sankcjonuje fakt, że współcześnie nie ma projektów realizowanych bez wsparcia IT, a w każdym razie nie można zalecać omijania tych technologii – na pewno dotyczy to tak zaawansowanego technologicznie społeczeństwa, jak Japonia. Akcentowanie znaczenia platformy współpracy projektu jest zapewne uwarunkowane kulturowo: społeczeństwa wschodnie są bardziej nastawione na działania wspólne, zespołowe niż indywidualistyczne społeczeństwa cywilizacji zachodniej. We współczesnym świecie coraz więcej projektów jest realizowanych przez ludzi należących do różnych kultur, co także powinno być uwzględnione w projekcie, głównie w procesach komunikowania się. PMBOK® Guide Krótka historia PMBOK® Guide jest to kompendium wiedzy o zarządzaniu projektami – jego głównym celem jest przedstawienie (struktury) wiedzy o zarządzaniu projektami. Zarząd PMI zatwierdził w 1981 roku projekt mający na celu opracowanie dokumentu wspomagającego kierowników projektów w ich pracy. Wyniki projektu opublikowane w Project Management Journal w 1983 roku są znane pod nazwą Raportu ESA (Komitetu ds. Etyki, Standardów i Akredytacji). Pierwsza wersja książkowa standardu PMI, została opublikowana w 1987 roku pod nazwą Project Management Body of Knowledge. W wersji opublikowanej przez PMI w roku 1996 do tytułu dodano słowo „guide” (przewodnik), żeby uzmysłowić odbiorcom, że dokument nie zawiera pełnej wiedzy, a tylko przewodnik po niej. W 1999 roku Project Management Institute został akredytowany przez American National Standard Institute jako organizacja ustanawiająca standardy, zaś PMBOK® Guide został przyjęty jako standard w obszarze zarządzania projektami. Kolejne wersje PMBOK® Guide były publikowane w latach 2000, 2004 i 2008. Autor niniejszego opracowania był członkiem zespołu opracowującego trzecią wersję PMBoK® Guide z 2004 roku. Co dokument zawiera? Główną składową PMBOK® Guide jest opis wiedzy o zarządzaniu projektami przedstawionej w postaci procesów zarządczych. Procesy zarządzania projektami są podzielone na pięć grup oraz dziewięć obszarów. Grup procesów to procesy inicjujące, procesy planowania, procesy wykonania, procesy monitorowania i sterowania oraz procesy kończące projekt. Obszar Zarządzania zakresem koncentruje się na szczegółowym określeniu produktów projektu, prac koniecznych do ich wykonania oraz wykonywaniu tych prac. Zarządzanie czasem to działania związane z harmonogramem prac. Obszar Zarządzania kosztami zajmuje się planowaniem i nadzorem nad realizacją budżetu, rozumianego jako lista kosztów. Zarządzanie jakością opisuje dwie podstawowe składowe: zapewnienie jakości (procesy powodujące, że produkty i procesy projektu mają właściwą jakość) oraz kontrolę jakości (weryfikację zgodności produktów z wymaganiami). Zarządzanie personelem to nabór i szkolenie personelu oraz organizacja i kierowanie zespołem. Zarządzanie komunikacją dotyczy tworzenia i utrzymywania repozytoriów projektu oraz przekazywania informacji pomiędzy członkami zespołu projektu, a także pomiędzy projektem a jego otoczeniem. Zarządzanie ryzykiem dotyczy określania i reagowania na prawdopodobne zdarzenia, które mogą wpłynąć zarówno pozytywnie jak i negatywnie na realizację projektu. Zarządzanie zaopatrzeniem (kontraktami) to procesy związane z nabywaniem produktów i usług spoza organizacji realizującej projekt. Obszar Zarządzania integralnością projektu są to procesy powodujące spójną, zintegrowaną realizację procesów z wszystkich innych obszarów. Czym ten dokument różni się od innych? Dla PMBoK® Guide sekcję tę najłatwiej byłoby mi pominąć, ponieważ standard ten jest najbardziej popularnym i kanonicznym spośród wszystkich innych. Standard ten ma takie znaczenie i pozycję w obszarze zarządzania projektami, że właściwie należałoby wszystkie inne standardy porównywać właśnie do niego. PMBoK® Guide jest uznawany za pierwszy rzeczywiście globalny standard zarządzania projektami – pozycję te uzyskał nie przez decyzję żadnego ciała standaryzującego, ale poprzez opowiedzenie się za nim rzesz kierowników projektów (ponad 3 000 000 egzemplarzy w obiegu na całym świecie). Ale skoro przyjąłem pewną strukturę pisania o standardach, to postaram się zastosować ją również do PMBoK® Guide. PMBoK® Guide jest rzeczywiście solidnym przewodnikiem po głównych obszarach wiedzy o zarządzaniu projektami. Kompendium powstało z inicjatywy samych kierowników projektów, a nie innych ciał, które na inne sposoby są zainteresowane projektami (na przykład Prince 2® powstał z inicjatywy klientów projektów, rządowych agencji brytyjskich). Autorzy PMBoK® Guide wychodzą z założenia: jeżeli dostarczymy kierownikom projektów wiedzę, to oni sami będą potrafili ją dostosować i wykorzystać w swoich projektach. W związku z tym drugim, oprócz samego PMBoK® Guide, najważniejszym produktem Project Management Institute jest certyfikat PMP®, potwierdzający, że ludzie rzeczywiście potrafią zarządzać projektami. Jest to zapewne najbardziej prestiżowy i jednocześnie najbardziej popularny na świecie certyfikat z tego obszaru. Za świadectwo zaawansowania organizacji w zakresie zarządzania projektami, przynajmniej w Polsce, uznawana jest duża liczba osób z certyfikatami PMP®. Ludzie ci w dodatku są zobowiązani do ciągłego doskonalenia się pod groźbą utraty certyfikatu. Od ludzi znających PMBoK® Guide jednego można się spodziewać na pewno: że będą potrafili ze sobą rozmawiać wspólnym językiem – a problemy komunikacyjne stanowią większość problemów w zarządzaniu projektami (podobnie jak i w innych dziedzinach działania). PMBoK® Guide jest dość elastycznie zdefiniowaną metodyką zarządzania projektami. Na bazie PMBoK® Guide, dysponując wykształconymi profesjonalistami, firmy mogą budować swoje metodyki zarządzania projektami – wdrażać aplikacje wspomagające zarządzanie procesami, budować procesy, definiować potrzebne formularze – dokładnie takie, jakie są firmie potrzebne. PMBoK® Guide wskazuje wiele technik koniecznych do zarządzania projektami (a niektóre z nich opisuje dokładniej, na przykład budowę harmonogramu, analizę wartości wypracowanej czy sposoby szacowania kosztów). Prince 2® Krótka historia Prince 2® jest metodyką zarządzania projektami. Nazwa Prince 2® jest skrótem od „PRojects IN Controlled Environment”. Źródłem Prince 2 ® była metodyka PROMPT II (Project Resource Organisation Management and Planning Techniques) opracowana przez brytyjską firmę Simpact Systems Ltd. w 1975 roku. PROMPT II został przyjęty jako standard budowy systemów informatycznych w Wielkiej Brytanii w 1979 roku przez rządową agencję CCTA (Central Computer and Telecommunication Agency). Po dziesięciu latach, w roku 1989, PROPMT II został zastąpiony przez metodykę Prince, w dalszym ciągu nastawioną wyłącznie na projekty informatyczne. W 1996 roku opracowano nową wersję – Prince 2® nastawioną na projekty wszystkich rodzajów, nie tylko informatyczne. Kolejne wersje, zachowujące nazwę Prince 2®, były publikowane przez CCTA, a następnie OGC (Office for Government Commerce), które przejęło funkcje CCTA, w latach 1998, 2002, 2005 oraz 2009. Co dokument zawiera? Rozbudowana struktura Prince 2® odbiega od struktur innych standardów. Najważniejsze są zasady. Sterowanie projektem przez uzasadnienie biznesowe (projekt albo musi mieć takie uzasadnienie, albo nie powinien być realizowany), zarządzanie wypracowaną wiedzą (zarówno poprzez nakaz jej tworzenia, jak i wykorzystywania), jednoznaczna organizacja (w zakresie ról i procesów), rozbicie projektu na etapy, tolerancja dla procesów zarządzania (określanie przez wyższe poziomy zarządcze przedziałów czasu, kosztu i innych parametrów, w ramach których niższe poziomy mogą samodzielnie działać), nastawienie na produkty i elastyczność metodyki, czyli jej dostosowanie do specyfiki projektu. Ważne dla projektów zagadnienia zostały zgrupowane w „tematy”. Uzasadnienie biznesowe jest to zestaw informacji koniecznych do podejmowania decyzji o realizacji i kontynuowaniu projektu. Organizacja wyróżnia cztery poziomy zarządzania: od poziomu organizacji poprzez poziom Komitetu Sterujące, kierownika projektu aż po poziom zespołu wykonawczego. Jakość oraz ryzyko to tematy, które są obecne także w innych standardach. Prince 2® dużo miejsca poświęca planom, a w szczególności planowaniu nastawionemu na produkty. Temat zmian zawiera także zarządzanie konfiguracją. Temat postęp prac odnosi się do nadzoru nad zaawansowaniem i przewidywanym dalszym sposobem realizacji projektu. Realizacja zasad w obszarach wyodrębnionych tematów odbywa się poprzez dobrze zdefiniowane procesy dotyczące projektu jako całości. Przygotowanie projektu jest to postępowanie prowadzące do decyzji o uruchomieniu projektu. Strategiczne zarządzanie jest to podejmowanie przez Sponsora najważniejszych decyzji i kontrola nad projektem, mające na celu zapewnienie sukcesu projektu Proces Inicjowania ma na celu przemyślenie sposobu realizacji projektu i zapewnienie wspólnego zrozumienia sposobu jego realizacji przez zaangażowane osoby. Proces Zamykania projektu wskazuje moment, od którego projekt, ze względu na osiągnięcie jego celów (lub stwierdzenie niemożliwości ich osiągnięcia), jest uznawany za zakończony. Prince 2® określa także procesy dotyczące dobrze wyodrębnionych fragmentów projektu. Sterowanie etapem to zarządzanie tym, co się dzieje na bieżąco w projekcie: wykonywanie zadań, raportowanie, podejmowanie działań korygujących itp. Zarządzanie końcem etapu wskazuje moment w projekcie, kiedy przechodzi on między fazami. Należy wtedy przejrzeć uzasadnienie biznesowe, osiągnięcia, ryzyka i perspektywy projektu, żeby podjąć decyzję, że projekt będzie kontynuowany oraz opracować szczegółowy plan następnego etapu. Zarządzanie dostarczaniem produktów to przyjmowanie przez kierowników zespołów roboczych pakietów prac do wykonania, ich wykonywanie i oddawanie wyników prac. Dokumentacja Prince 2 ® zawiera także wytyczne dotyczące dostosowywania metodyki do różnych rodzajów projektów, na przykład do projektów komercyjnych, czyli realizowanych przez wykonawcę za wynagrodzeniem na potrzeby innych firm. Czym ten dokument różni się od innych? Prince 2 ® jest to pełny opis procesów zarządczych wykonywanych w trakcie realizacji projektu. 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. Stosując 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. Prince 2 ® jest metodyką prezentującą konsekwentnie punkt widzenia klienta projektu. 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 Komitetu Sterującego, ale bardzo wyraźnie mówi się, że zasadnicze decyzje podejmuje przedstawiciel klienta, pozostałe osoby mają w Komitecie Sterującym tylko głos doradczy. O nastawieniu na klienta, a nie na wykonawcę świadczy też pominięcie zagadnień interpersonalnych i tzw. miękkich technik zarządzania zespołem – praca z ludźmi, przez wielu praktyków i metodyków uznawana za najważniejszy element zarządzania projektem odbywa się przecież w całości po stronie wykonawcy. Prince 2 ® nie uznaje zarządzania projektem za proces społeczny, co wydaje się być istotnym niedopatrzeniem tej metodyki. Metodyka 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. Prince 2 ® stosuje specyficzne rozwiązania czysto zarządcze. Za sukces projektu odpowiada nie kierownik projektu (odpowiedzialny za bieżące zarządzanie projektem) ale Komitet Sterujący, czyli praktycznie sponsor. Drugim pojęciem specyficznym dla Prince 2® są tolerancje. Podwładni powinni zawsze mieć określone parametrów, wewnątrz których mają działać samodzielnie – czyli właśnie tolerancje. Z tolerancjami związane jest pojęcie zarządzania przez wyjątki: wyżsi przełożeni, na przykład sponsor, nie muszą być niepokojeni, jeśli projekt idzie zgodnie z planem. Natomiast, jeśli w projekcie zdarzy się coś szczególnego, czyli właśnie sytuacja wyjątkowa, to konieczne jest powiadamianie wyższych przełożonych. Podsumowanie W jaki sposób wybrać standard zarządzania projektami dla własnej organizacji? Jakiego standardu należy się uczyć wchodząc na ścieżkę kariery kierownika projektu? Według jakiego standardu zarządzać konkretnym projektem? Który z tych standardów jest najlepszy? To są pytania, na które próbuje sobie odpowiedzieć wiele osób. Kryteria wyboru mogą być nie tylko merytoryczne, ale także społeczne, organizacyjne czy biznesowe. Kryteria merytoryczne to te, które dotyczą zestawu procesów, ich postaci, stosowanych technik i wytwarzanych produktów. Do kryteriów społecznych zaliczyłbym prestiż standardu w środowisku zarządzania projektami. Kryteria organizacyjne to na przykład narzucanie organizacji metodyki przez organizację nadrzędną, na przykład korporację czy właściciela biznesowego. Kryteria biznesowe to na przykład wymagania przez klienta projektu stosowania określonej metodyki – coraz częściej w przetargach wymaga się realizacji projektów przez osoby mające certyfikat PMP® czy też zgodnie z metodyką Prince 2 ®. Przy dokonywaniu wyboru standardu należy także uwzględnić jej podstawowy cel. Jeśli chcemy podnieść kwalifikacje personelu, to dobrym rozwiązaniem są standardy typu kompendium wiedzy (PMBoK® Guide) lub standardy kompetencji – ja skrótowo omówiłem IPMA ICB. Jeśli koncentrujemy się na wdrożeniu sprawnego, dobrze zdefiniowanego procesu zarządzania projektami i nie chcemy zbyt dużo pracy wkładać w dopracowywanie rozwiązania – to zalecać należałoby którąś z gotowych metodyk (np. Prince 2 ®). A jeśli zarządzanie projektami już u nas na pewnym poziomie funkcjonuje, to można pomyśleć o jego usprawnianiu – do tego z kolei służą modele dojrzałości projektowej, na przykład CMMI^SM. Ale trzeba też pamiętać, że niektóre z omawianych tu dokumentów pełnią więcej niż jedną rolę. Na przykład PMBoK® Guide, chociaż zawiera przewodnik po kompendium wiedzy, to stosowany jest także jako standard zarządzania projektami – Stany Zjednoczone przyjęły ten dokument jako obowiązujący standard, co w zasadzie zamyka dyskusję, czy PMBoK® Guide jest czy nie jest metodyką – gdyby nie był metodyką, to nie można by wymagać od organizacji działania zgodnie z nim. A może można jednocześnie wdrażać więcej niż jeden standard? Są specjaliści, którzy nie sprzeciwiają się takiemu rozwiązaniu. W końcu żaden z omawianych tu globalnych standardów nie pokrywa całości obszaru zarządzania projektami. Na przykład opis procesów można pobrać z PMBoK® Guide czy Prince 2 ®, zaś za podstawę do kształtowania miękkich umiejętności kierowników projektów przyjąć można IPMA ICB. Takie rozwiązania są możliwe i gdzieniegdzie stosowane, jednak wymagają one sporo pracy mającej na celu dostosowanie i uzgodnienie wybranych elementów zawartości standardów. Ale, z drugiej strony, żaden ze standardów nie jest nigdy wdrażany w postaci dokładnie takiej, jaka jest opisana w publikacji. Jeśli wdraża się pojedynczy standard, to także należy go dostosować do specyfiki organizacji. Jedna z autorek CMMI^SM, Susan Garcia, opisuje pytania, które organizacja powinna sobie postawić wybierając standard zarządzania projektami: · Czy firma powinna wybrać standard ze względu na warunki rynkowe? · Czy w organizacji występują problemy, które standard rozwiązuje? · Czy organizacja chce i jest gotowa inwestować we wdrożenie standardu? · Czy standard jest zgodny ze strategią, praktykami i klimatem organizacji? Dopiero dokładna analiza warunków organizacji pozwala na podjęcie właściwej decyzji dotyczącej wdrażania standardu. Natomiast na pewno można stwierdzić, że – na poziomie pojedynczego kierownika projektów – większa ilość wiedzy zawartej w standardach zwiększa szerokość spojrzenia na zarządzanie projektami, przygotowuje na różne sytuacje, które mogą wystąpić w trakcie ich realizacji i w ten sposób może się przyczynić do zwiększenia skuteczności w tej pracy. Literatura 1. BSI. (2000). Project management. Part 2: Vocabulary. London:BSI 2. BSI. (2000a). Project management. Part 3: Guide to the management of business related project risk. London:BSI 3. BSI. (2002). Project management. Part 1: Guide to project management. London:BSI 4. BSI. (2006). Project management. Part 4: Guide to project management in the construction industry. London:BSI 5. Gasik, S. (2010). Model zarządzania wiedzą o projektach. Rozprawa doktorska. Uniwersytet Warszawski, Wydział Zarządzania. 6. Gasik, S. (2011). Comments on ISO 21500 Draft Version. Dostępne z http://www.sybena.pl/wiedza_ang.htm. 7. IPMA. (2006). ICB – IPMA Competence Baseline Version 3.0. Nijkerk, The Nederlands: International Project Management Association. 8. ISO. (2003). ISO 10006: 2003: Quality management: Guidelines to quality in project management. Geneva: International Organization for Standardization. Polskie wydanie: PKN (2005). 9. MTDC (2009). A guide to the project management body of knowledge (PMBOK®Guide) Fourth Edition. Wydanie polskie. MTDC. 10. OGC. (2009). PRINCE2^TM – Skuteczne zarządzanie projektami. London: The Stationery Office. 11. PKN. (2005). Systemy zarządzania jakością. Wytyczne dotyczące zarządzania jakością w przedsięwzięciach. PN-ISO 10006. Warszawa: Polski Komitet Normalizacyjny. 12. PMAJ. (2005). A Guidebook of Project & Program Management for Enterprise Innovation. Volume I. Revision 3. Japan: Project Management Association of Japan. 13. PMAJ. (2005a). A Guidebook of Project & Program Management for Enterprise Innovation. Volume II. Revision 1. Japan: Project Management Association of Japan. 14. PMI. (2008). A Guide to Project Management Body of Knowledge (PMBOK®Guide) – Fourth Edition. Newton Square: Project Management Institute. 15. SEI. (2010). CMMI^SM for Development, Version 1.3. CMU/SEI-2010-TR-033 ESC-TR-2010-033. Pittsburgh, Pa. Software Engineering Institute, Carnegie Mellon University. 16. SPMP. (2009). NCB Polskie wytyczne kompetencji IPMA® Wersja 3.0. Gdańsk:SPMP. Pobierz artykuł o siedmiu standardach zarządzania projektami w formacie PDF
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