Porażki w projektach IT – część III
W trzeciej części cyklu na temat porażek w projektach IT przytoczę wyniki badań opublikowanych w listopadowym numerze Communications of The ACM, są to badania przeprowadzone przez naukowców z Oxfordu, a ich uczestnikami byli brytyjscy kierownicy projektów. Badania miały przynieść odpowiedź na pytania: jak to faktycznie jest z porażkami w projektach IT i jakie są główne czynniki powodujące, że projekty IT stają się bardziej ryzykowne.
Z badań przeprowadzonych wśród 412 doświadczonych kierowników projektów (średnia 9 lat jako kierownicy projektów) wynika, że:
Średnie przekraczano budżet o 13%, harmonogram opóźniał się o 20%, a zakres projektu był realizowany w 93%.
Wśród badanych projektów, wydzielono następujące grupy:
Z wyników widać, że w przypadku 67% projektów ich wyniki można uznać za zadowalające, w przypadku 23 % przekroczono znacznie budżet (o 127%), albo harmonogram (82%), jeden projekt na jedenaście, nigdy nie został zakończony. W porównaniu do wyników z „Chaos Report” można uznać te wyniki za pozytywne, warto jednak zwrócić uwagę, że są to badania przeprowadzone wśród doświadczonych kierowników projektów, więc średnia na rynku może być rzeczywiście znacznie gorsza.
Badania pokazały również ścisłą zależność pomiędzy pracochłonnością projektów, a prawdopodobieństwem tego, że odniosą porażkę, widać wyraźną zależność.
Natomiast w przypadku wielkości zespołu projektowego i czasu trwania zależność ta nie była już tak oczywista. O ile potwierdza się, że dłuższe projekty są bardziej ryzykowne, badania pokazują, że graniczną wartością czasu trwania projektu jest jeden rok, po tym okresie prawdopodobieństwo porażki rośnie. Jeszcze ciekawiej wyglądają wyniki w zależności od wielkości teamu projektowego, praktycznie dla teamów do 20 osób prawdopodobieństwo porażki jest stałe i wynosi ok. 30%, powyżej 20 osób we zespole rośnie ono gwałtownie do 50%.
Innowacyjnością w tych badaniach wydaje się również próba odpowiedzi na pytanie, w jaki sposób zmiany w projekcie wpływają na prawdopodobieństwo porażki. Okazało się, że są 2 główne rodzaj zmian, które szczególnie niekorzystnie mogą wpłynąć na projekt: zmiana w nadzorze (kierownik projektu, sponsor), zmiana celu projektu (zakresu), na poniższym wykresie zilustrowano wpływ tych zmian na projekt.
Wyniki tych badań dają kolejne argumenty kierownikowi projektu, który chce chronić projekt przed zbyt dużą liczbą zmian i „koncertem życzeń” ze strony interesariuszy projektu. Każą się również zastanowić, czy warto zmieniać kierownika projektu, w momencie, gdy coś pójdzie nie tak (podnosimy przecież automatycznie ryzyko porażki). Wyniki również pozwalają w prosty sposób kierownikowi projektu pokazać, ile potencjalnie może kosztować jego zmiana.
W kolejnej, czwartej już części przedstawię wyniki badań jednej z dużych światowych firm tworzącej oprogramowanie. W piątej części przyjdzie czas na podsumowanie i wyciągnięcie praktycznych wniosków.
Related posts:
- Porażki w projektach IT – część II W tej części zajmę się wynikami badań firmy Tata...
- Porażki w projektach – część IV W kolejnej, przedostatniej (ostatnia i podsumowująca, już w przyszłym...
- Porażki w projektach IT – część I Porażki w projektach IT. Do napisania tego artykułu...
- Kierownik projektów w 15 minut ? Wyobraź sobie sytuację, jest piątek i dostajesz e-mail’a, że...
- Jak wybrać właściwy (dla siebie) certyfikat kierownika projektu – część 3 This post is also available in English. Dziękuję za...
