1

Dlaczego projekty informatyczne kończą się prawie zawsze fiaskiem?


Czemu tak jest i jak temu zapobiec? Ile projektów informatycznych według statystyk upada oraz ile przechodzi pełną przemianę?

W tym artykule postaram się przybliżyć Was do odpowiedzi na powyższe pytania.

Na początek trochę danych wyciągniętych z najbardziej znanego raportu dotyczącego projektów IT, mianowicie raport The Standish Group zatytułowany “Chaos

2

Według raportu Standish Group w 2015 roku tylko 29% projektów informatycznych zostało zakończonych sukcesem, czyli zgodnie z harmonogramem, budżetem oraz zadowalającym wynikiem. Ciekawe, że aż 52% odniosło częściowy sukces, ponieważ nie spełniły jednego lub kilku następujących warunków: przekroczony harmonogram, przekroczony budżet, zmieniony zakres. Zastanawiający jest jednak fakt, że 19% projektów IT zostało utopionych.

Dane trochę szokujące, jednak kiedy popatrzymy na to z innej perspektywy, to dochodzimy do wniosku, że tak naprawdę to, czy dany projekt odniesie sukces, czy też nie, jest zależne od wielu czynników.

Trendem jest to, że mniejsze projekty mają o wiele większe prawdopodobieństwo powodzenia niż większe, jak pokazano w poniższej tabeli.

3

Dzięki zastosowaniu metod zwinnych w projektach IT w ostatnich latach, możliwe było porównanie wyników projektów pomiędzy zwinnymi i tradycyjnymi projektami. W zależności od wielkości projektów podejście zwinne zaowocowało bardziej udanymi projektami i mniejszymi niepowodzeniami.

4

Złożone, długie i kosztowne projekty IT są bardziej narażone na przekroczenie budżetu lub czasu, niż mniejsze przedsięwzięcia. Zaś w przypadku efektywności funkcjonalnej (spełnieniu wszystkich wymagań Klienta) ryzyko porażki szacowane jest wzrostem aż 10-krotnie!

W tym miejscu można nawiązać do zasady „Two-Pizzas Team” stosowanej przez Jeffa Bezosa założyciela Amazona, o której wspominałem w poprzednim artykule. Według niego zespoły projektowe nie powinny przekraczać 6-8 osób, czyli tylu, ilu można wyżywić dwiema pizzami. Bezos zauważył, że w większych zespołach wzrasta chaos komunikacyjny i rozmycie odpowiedzialności.

Dlaczego więc projekty IT upadają?

W większości największy wpływ na taki stan rzeczy ma zarząd firmy. Jeżeli zarząd stwierdził, że nie robimy czegoś, bo to nam się nie opłaca, albo to porzucamy i idziemy pracować przy czymś innym. W zasadzie reszcie pracowników pozostaje się tylko dostosować.

Tak samo sytuacja wygląda z zaangażowaniem klienta, jeśli klient myśli, że spotka się z kierownikiem projektu i powie czego oczekuje, a potem za kilka miesięcy przyjdzie odebrać gotowy produkt, to mamy raczej pewność, że nie otrzyma tego, co sobie wymarzył. Na dalszy plan schodzą tutaj takie aspekty, jak doświadczenie kierownika projektu, jasno zdefiniowane cele, zakres prac, odpowiednio dobrany harmonogram oraz kamienie milowe. Oczywiście na sukces bądź porażkę wszystkie te czynniki mają istotny wpływ.

Dlaczego tak się dzieje?

W ciągłym pędzie nie analizujemy minionych projektów, w których kryje się odpowiedź na pytanie o przyczyny niepowodzeń lub czynniki decydujące o sukcesie. Nie staramy się wyciągać wniosków z porażek, ale również nie analizujemy sukcesu.

Zatem pamiętajmy, iż podstawową przyczyną niepowodzeń projektów IT są głównie czynniki poza informatyczne, wynikające z:

  • nieumiejętnego zarządzania projektem,
  • braku umiejętności czytelnego zdefiniowania celów podjęcia realizacji projektu,
  • problemów w zapewnieniu właściwej komunikacji między stronami zaangażowanymi w projekt.

Przyczyny informatyczne nie są tutaj kluczowe. Pamiętajcie o tym zwłaszcza, kiedy jesteście przed rozpoczęciem  realizacji projektu informatycznego.

 

Źródła:
https://www.infoq.com/articles/standish-chaos-2015