RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się sukcesami? Jak charakter projektu (development, wdrożenie ) wpływa na jego powodzenie? Czy udaje się mieścić w czasie i budżecie? Które podejścia są najpopularniejsze, czy faktycznie Agile zdominował świat? Co organizacja i kierownik projektu mogą zrobić, aby efektywnie zarządzać ryzykiem? Jaka część PM posiada certyfikaty? Wrocław 2011
O RAPORCIE I BADANIU Pierwsze badanie polskich projektów informatycznych PMresearch.pl zostało przeprowadzone między 10.04.2010, a 15.06.2010. Badanie objęte zostało patronatem Instytutu Informatyki Politechniki Wrocławskiej, Stowarzyszenia Project Management Polska, Project Management Institute Wrocław Branch, Polskiego Towarzystwa Informatycznego Oddział Dolnośląski. Zebrano dane od ponad 300 respondentów z całego kraju, po rygorystycznej weryfikacji jakości odpowiedzi do badania zakwalifikowano 80 projektów. Zespół badawczy: mgr inż. Albert Dabiński, mgr inż. Marcin Grzesiek. Nadzór merytoryczny: dr inż. Kazimierz Frączkowski. Raport z Polskiego badania projektów IT 2010 strona 2
POLSKIE PROJEKTY IT SUKCES I PORAŻKA PROJEKTÓW Sukces; 21% Porażka; 33% Częściowy sukces; 46% CZYM JEST SUKCES A CZYM PORAŻKA? Na potrzeby badania utworzona została syntetyczna miara sukcesu projektu nazwana współczynnikiem sukcesu. Miarę tę buduje pięć czynników: zgodność rzeczywistego budżetu projektu z planowanym, zgodność rzeczywistego czasu trwania z planowanym, zgodność zrealizowanego zakresu z planowanym, ocena projektu dokonana przez kierownika projektu, ocena satysfakcji klienta dokonana przez kierownika projektu. Na podstawie wartości współczynnika sukcesu każdy z projektów został zaliczony do jednej z grup: zakończonych sukcesem, częściowym sukcesem, porażką. Raport z Polskiego badania projektów IT 2010 strona 3
SEKTOR PUBLICZNY VS PRYWATNY Badanie pokazuje znaczące dysproporcje między projektami w sektorze publicznym i prywatnym. Niestety na niekorzyść projektów publicznych, które dwukrotnie rzadziej kończą się sukcesem. Na uwagę zasługuje jednak fakt, że projekty publiczne występują stosunkowo często stanowiły one aż 14% wszystkich badanych projektów. Publiczny; 14% Prywatny; 86% Procent projektów 10 9 8 7 6 4 3 2 1 35% 49% 16% Prywatny 18% 27% 55% Publiczny Sukces Częściowy sukces Porażka Sektor gospodarki Raport z Polskiego badania projektów IT 2010 strona 4
SUKCES A CHARAKTER PROJEKTU Jedynie 28% projektów skoncentrowanych było na rozwoju nowego systemu. Nie pozwala to co prawda wnioskować o trendach, pokazuje jednak wysokie nasycenie gotowymi rozwiązaniami, które są wdrażane, integrowane i rozwijane w kolejnych projektach. Nie bez powodu z rozwojem nowych systemów związane jest największe ryzyko, co odzwierciedlają ich wyniki. Wdrożenie rozwiązania IT; 36% Rozwój nowego systemu; 28% Rozwój istniejącego systemu; 36% Procent projektów 10 9 8 7 6 4 3 2 1 18% 34% 32% 28% Rozwój nowego systemu 38% 38% Rozwój istniejącego systemu Charakter projektu 55% 7% Wdrożenie rozwiązania IT Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 5
JAK WIELKOŚĆ PROJEKTU WPŁYWA NA JEGO POWODZENIE? Badane projekty zostały skategoryzowane pod kątem wielkości na podstawie budżetu i czasu trwania. Wbrew obiegowej opinii trudno jest wskazać jednoznaczną zależność między wielkością projektu a jego sukcesem. Wielki; 5% Mikro; 14% Duży; 21% Mały; 31% Średni; 29% Procent projektów 10 9 8 7 6 4 3 2 1 36% 36% 26% 41% 36% 52% 48% 41% 27% 26% 12% 18% Mikro Mały Średni Duży Wielki Wielkość projektu Porażka Częściowy sukces Sukces W grupie projektów sklasyfikowanych jako wielki znalazło się zaledwie kilka projektów, stąd do miar sukcesu dla tej grupy należy podchodzić ze szczególnym dystansem. Raport z Polskiego badania projektów IT 2010 strona 6
PRZEKROCZONE OGRANICZENIA CZAS, BUDŻET PLANOWANY BUDŻET A RZECZYWISTY KOSZT REALIZACJI Połowa badanych projektów przekroczyła budżet, średnio o 32%. Niewykorzysta ny; 3 Przekroczony; 49% Wykorzystany; 21% CZAS REALIZACJI PLANOWANY A RZECZYWISTY Ograniczenie terminu było łamane znacznie częściej niż ograniczenia budżetowe. 61% badanych projektów przekroczyło termin, średnio o 58% - to prawie dwukrotnie więcej niż średnie przekroczenie budżetu! Przywiązywanie większej wagi do budżetu niż do terminu to specyfika typowo polska. W Europie zachodniej oraz USA jest dokładnie odwrotnie (bardziej liczy się termin niż budżet), co pokazują analogiczne badania prowadzone na tym obszarze. Przed terminem; 6% Zgodnie z terminem; 33% Po terminie; 61% Raport z Polskiego badania projektów IT 2010 strona 7
STOPIEŃ REALIZACJI ZAKRESU Spośród trzech głównych ograniczeń projektowych najczęściej zachowywanym był zakres projektu. Ponad połowa projektów została zrealizowana w niemal 10 zakresie. 8 i mniej; 6% Ponad 8; 16% W przybliżeniu 10; 56% Ponad 9; 21% Raport z Polskiego badania projektów IT 2010 strona 8
METODYKI PROJEKTOWE POPULARNOŚĆ PODEJŚĆ Mimo dużej popularności metodyk zwinnych jedynie 11% projektów było prowadzona w myśli podejścia zwinnego. Zaskoczeniem może również być fakt, iż nie ma jedna trzecia projektów nie była prowadzona wg żadnej zdefiniowanej metodyki a jedynie w oparciu o wiedzę i doświadczenie kierownika projektu. Jak widać rezultaty takiego podejścia mówią same za siebie. Nieformalne - wiedza i doświadczenie ; 29% Agile; 11% Formalne oparte o metodykę lub procedury organizacji; 6 Procent projektów 10 9 8 7 6 4 3 2 1 33,3% 54,2% 66,7% 22,2% 12,5% 11,1% Formalne oparte o metodykę lub procedury organizacji Agile Metodyki projektowe 17,4% 39,1% 43,5% Nieformalne - wiedza i doświadczenie Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 9
PODEJŚCIE DO ZARZĄDZANIA PROJEKTEM A WIELKOŚĆ PROJEKTU Wraz ze wzrostem rozmiaru projektu rośnie formalizacja metod zarządzania i rola metodyk formalnych definiujących procesy zarządcze. Udział metodyki zarządzania 10 9 8 7 6 4 3 2 1 36% 32% 3 24% 16% 9% 27% 10 76% 52% 61% 36% Mikro Mały Średni Duży Wielki Wielkość projektu Nieformalne - wiedza i doświadczenie Agile Formalne oparte o metodykę lub procedury organizacji Raport z Polskiego badania projektów IT 2010 strona 10
ZARZĄDZANIE RYZYKIEM OCENA RYZYKA PRZED ROZPOCZĘCIEM PROJEKTU Ocena ryzyka przed rozpoczęciem projektu nie miała miejsca w blisko jednej trzeciej projektów. A szkoda, takie projekty dwukrotnie częściej kończyły się porażką. Nie; 30, Tak; 70, Procent projektów 10 9 8 7 6 4 3 2 1 29,2% 33,9% 37,5% 50, 33,3% 16,1% Nie Tak Ocena ryzyka przed rozpoczęciem projektu Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 11
SYSTEMATYCZNOŚĆ OCENY RYZYKA Czy warto systematycznie identyfikować i oceniać ryzyko? Zdecydowanie tak! Projekty, w których oceniano ryzyko systematycznie pięciokrotnie rzadziej kończyły się porażką. Tylko przed rozpoczęciem; 23% Systematycznie; 77% 10 Procent projektów 9 8 7 6 4 3 2 1 25, 48,1% 37,5% 44,4% 37,5% 7,4% Tylko przed rozpoczęciem Systematycznie Systematyczność oceny ryzyka Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 12
UDZIAŁ ZESPOŁU W ZARZĄDZANIU RYZYKIEM Kierownictwo projektu często nie jest w stanie samodzielnie zidentyfikować i prawidłowo ocenić wszystkich ryzyk. Włączanie w ten proces kolejnych członków zespołu pozwala ograniczyć ryzyko porażki (nawet ponad dwukrotnie). Tak, cały zespół; 21% Nie, nie widzę takiej potrzeby; 9% Tak, niektórzy jego członkowie; 7 UDZIAŁ ZESPOŁU W ZARZĄDZANIU RYZYKIEM - ROZKŁAD ODPOWIEDZI. Procent projektów 10 9 8 7 6 4 3 2 1 28,6% 26,4% 42,9% 28,6% Nie, nie widzę takiej potrzeby 52,8% 20,8% Tak, niektórzy jego członkowie 56,3% 31,3% 12,5% Tak, cały zespół Udział zespołu w zarządzaniu ryzykiem Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 13
PROCEDURY ZARZĄDZANIA RYZYKIEM W ORGANIZACJI Jedynie jedna trzecia badanych organizacji posiadała procedury zarządzania ryzykiem. Wyniki prowadzonych w nich projektów pokazują, że pozwala to ograniczyć zagrożenia dla projektu i zwiększyć jego szanse na sukces. Istotniejszym wnioskiem wydaje się jednak fakt, że.. niewiedza szkodzi. Najsłabsze wyniki osiągnęły bowiem projekty, których kierownicy nie byli świadomi procedur funkcjonujących (bądź nie) w ich organizacji. Nie wiem; 13% Tak, występują; 33% Nie, brak takich procedur; 53% Procent projektów 10 9 8 7 6 4 3 2 1 44, 36, 60, 20, 15, 25, 30, 30, 40, Tak Nie Nie wiem Posiadanie procedur zarządzania ryzykiem organizacyjnym Porażka Częściowy sukces Sukces Raport z Polskiego badania projektów IT 2010 strona 14
CERTYFIKACJA PROJECT MANAGERÓW POSIADANIE DOWOLNEGO CERTYFIKATU Z ZARZĄDZANIA PROJEKTAMI Jedna trzecia badanych kierowników projektu posiada certyfikat z zarządzania projektami. Tak; 31% Nie; 69% POSIADANIE CERTYFIKATU Z ZARZĄDZANIA RYZYKIEM Mimo powszechnego przekonania o istotności zarządzania ryzykiem w projekcie jedynie 7% kierowników projektu posiada specjalistyczny certyfikat z tego zakresu. Tak; 7% Nie; 93% Raport z Polskiego badania projektów IT 2010 strona 15
PODSUMOWANIE Wyniki badania jednoznacznie pokazują, że skuteczność realizacji projektów IT w Polsce jest niezadowalająca sponsorzy projektów informatycznych muszą liczyć się z ryzykiem, że szanse na sukces projektu to statystycznie tylko 21%. Frederick P. Brooks w słynnym artykule No Silver Bullet stwierdził, że nie ma takiego jednostkowego osiągnięcia czy to w technice, czy w zarządzaniu które, samo z siebie, doprowadziłoby do poprawy efektywności o jeden rząd wielkości. Poprawa efektywności realizacji projektów IT nie jest możliwa przez pojedyncze działania, konieczny jest cały zbiór praktyk projektowych. Wyniki badania pokazują, że zbiór ten powinien obejmować: unikanie podejścia nieformalnego na rzecz stosowania metodyk projektowych, przeprowadzenie oceny ryzyka projektu przed jego rozpoczęciem, systematyczne ocenianie ryzyka w trakcie projektu, zaangażowanie (przynajmniej częściowe) zespołu w zarządzanie ryzykiem, zbudowanie wiedzy kierowników projektu o procedurach organizacyjnych zasadach funkcjonowania organizacji. Wdrożenie tych prostych praktyk do projektów pozwala istotnie ograniczyć ryzyko oraz zwiększyć szanse przedsięwzięcia na sukces. Raport z Polskiego badania projektów IT 2010 strona 16