Jak uniknąć porażek przy wdrażaniu technologii i usług informatycznych? Być może każdy z Was ma własny ranking przyczyn, dlaczego projekty się nie udają. Od tygodnia jednak zastanawiam się, czy jest przyczyna nadrzędna, uniwersalna?
Chcąc odpowiedzieć na to pytanie, warto na początku sięgnąć do badań The Standnish Grup, która od blisko 20 lat analizuje sukcesy i porażki projektów „informatycznych”.
Ile projektów IT kończy się sukcesem?
Zacznijmy od definicji sukcesu projektu wg. Standish Group. Jest nim dostarczenie założonej funkcjonalności (zakresu) w uzgodnionym czasie oraz w granicach budżetu.
Jak widać, jest to klasyczny „żelazny trójkąt” projektu, który nie obejmuje takiego parametru sukcesu, jak korzyść z eksploatacji dostarczonego produktu. Jest to perspektywa bliższa Dostawcy, który rozlicza projekt wraz z wykonaniem i przekazaniem produktu (np. systemu informatycznego), niż Klientowi, który oceni zasadność projektu w momencie zmaterializowania korzyści biznesowych wynikających z eksploatacji produktu (co może potrwać kilka lat).
Wyniki badań projektów, przy założeniu następujących definicji :
wyglądają następująco:
Widać niewielki, ale stale rosnący, odsetek sukcesów. Czynników mających na to wpływ jest wiele, ale najbardziej znamiennym jest spadająca liczba dużych projektów, realizowanych metodą kaskadową, które były najbardziej narażone na ryzyko porażki. Wzrasta natomiast udział małych przedsięwzięć zarządzanych zwinnie, które częściej kończą się sukcesem.
Gdzie najczęściej projekty napotykają na problemy?
Jeśli chodzi o ostatni parametr, badania Standish Group wykazały, że po oddaniu produktu do eksploatacji (np.systemu informatycznego) tylko 20% jego funkcjonalności jest regularnie wykorzystywana przez użytkowników. Połowa okazuje się niepotrzebna, a pozostałe 30% użytkownicy wykorzystują od czasu do czasu. Ciekawe, że to dokładnie odpowiada zasadzie Patero.
Jaki główny wniosek płynie z badań Standish Group?
Złożone, długie i kosztowne projekty IT są dwukrotnie bardziej narażone na przekroczenie parametru kosztu i czasu niż mniejsze przedsięwzięcia. Zaś w przypadku efektywności funkcjonalnej ryzyko porażki wzrasta 10-krotnie! W tym miejscu można nawiązać do zasady „Two-Pizzas Team” stosowanej przez Jeffa Bezosa (założyciela Amazona). 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.
Porównanie efektywności małych i dużych projektów (Chaos Manifesto 2013 – The Standish Group):
Jakie są główne czynniki sukcesu małego projektu?
Wyniki badań na podstawie raportu Chaos Manifesto 2013 (The Standish Group) wyglądają następująco:
Reasumując
Krytycznymi czynnikami, zwiększającymi szanse powodzenia projektu, są:
Więcej w załączonym raporcie Chaos Manifesto 2013 – The Standish Group.
Załączniki
