Słynny, choć stary już raport The Standish Group zatytułowany “Chaos” (1995) pokazuje, że:
- 31,1% projektów zostanie wstrzymanych, zanim zostaną dokończone
- 52,7% projektów kosztuje 189% swoich pierwotnych szacunków
- 222% wynosi średnie przekroczenie wstępnie estymowanego czasu realizacji
- Tylko 16,2% projektów jest realizowanych na czas i w budżecie
- 61% funkcji jest realizowanych zgodnie z wymaganiami
Bardzo często spotykam odniesienia do tego raportu – wyciągnięte z niego liczby, które mają zaskakiwać, jednak pozbawione są szerszego kontekstu i przede wszystkim genezy oraz wniosków z badania, które są bardzo ciekawe.
The Chaos Report
Wstęp do raportu mówi:
W 1986 roku Alfred Spector, prezes Transarc Corporation, współtworzył dokument porównujący budowę mostu do rozwoju oprogramowania. Przyjął następujące założenia: mosty budowane są zwykle na czas, w budżecie i nie spadają, natomiast oprogramowanie nigdy nie jest realizowane na czas lub w budżecie, ponadto zawsze się psuje. (Oczywiście w rzeczywistości budowa mostów nie zawsze kończyła się sukcesem. Wiele projektów przekroczyło szacunki, ramy czasowe, a niektóre nawet spadły.) Takie założenia przyjęto jednak na potrzeby raportu (przyp. autora).
Jednym z najważniejszych powodów, dla których mosty realizowane są na czas, w budżecie i nie spadają, jest ogromna szczegółowość projektu. Projekt jest „zamrożony” i wykonawca ma niewielką elastyczność wprowadzania zmian do specyfikacji. Jednak w dzisiejszym, szybko zmieniającym się środowisku biznesowym, zamrożony projekt oprogramowania nie uwzględniałby zmian biznesowych, dlatego należy stosować bardziej elastyczny model, który będzie umożliwiał wprowadzanie ich. To rodzi uzasadnienie dla porażki rozwoju oprogramowania.
Jest jeszcze jedna różnica między niepowodzeniami we wdrażaniu oprogramowania i niepowodzeniami w budowaniu mostów – około 3000 lat doświadczenia. Kiedy most spada, przyczyny katastrofy są badane, powstaje raport z przyczyn niepowodzenia. Nie dzieje się tak w branży komputerowej, gdzie awarie są maskowane, ignorowane i / lub racjonalizowane. Jako rezultat powtarzamy te same błędy w kółko.
I na tym ostatnim zdaniu chciałabym skupić Twoją uwagę. To zdanie stanowi środek ciężkości całego wpisu. To punkt wyjścia do moich rozważań, o których będziesz mógł już wkrótce przeczytać. Niby oczywiste, a jednak odkrywcze, przy tym głębokie jak studnia. Wróćmy teraz jednak do raportu, nie gubiąc powyższej myśli.
Badane projekty podzielone zostały na 3 grupy:
- Sukces projektu: projekt zakończony w terminie i w budżecie, zawierający wszystkie
cechy i funkcje, jakie określono w pierwotnych wymaganiach- 16,2% - Projekt-wyzwanie: projekt zrealizowany do końca, funkcjonujący, ale z przekroczonym budżetem i terminem, oferuje mniej funkcji i możliwości, niż pierwotnie określone – 52,7%
- Projekt przerwany: projekt jest anulowany w pewnym momencie w trakcie cyklu rozwoju – 31,1%
Respondentami byli wykonawczy menedżerowie IT. Próba obejmowała duże, średnie i małe firmy z różnych segmentów rynku: bankowość, papiery wartościowe, produkcja, sprzedaż detaliczna, sprzedaż hurtowa, opieka zdrowotna, ubezpieczenia, usługi oraz lokalne, stanowe i federalne organizacje. Całkowita wielkość próby wynosiła 365 respondentów i 8 380 aplikacji. Ponadto Standish Group przeprowadziła wywiad w czterech grupach fokusowych oraz liczne, indywidualne wywiady, aby zapewnić jak najlepszy, jakościowy kontekst dla wyników badań.
Badanie miało odpowiedzieć na pytanie dlaczego projekty informatyczne kończą się porażką. Aby to ustalić Standish Group zadała menedżerom IT pytanie o to, jakie czynniki decydują o sukcesie projektu. Oto 3 najważniejsze zdaniem ankietowanych kryteria sukcesu:
- Zaangażowanie użytkowników – 15,9%
- Wsparcie kadry zarządzającej – 13,9%
- Jasno sprecyzowane i klarowne wymagania – 13%
Oczywiście są też inne czynniki, jednak Standish Group w swoim badaniu wskazuje te 3 jako znacząco wpływające na powodzenie projektu. Bez nich szanse na sukces drastycznie maleją. I w tych czynnikach, a właściwie w ich braku można upatrywać się przyczyny porażek projektów, choć raport wprost ich nie wskazuje. Stanowi jednak (a przynajmniej powinien) impuls do dyskusji: dlaczego tak się dzieje? Dlaczego tak często projekty kończą się źle?
20 lat minęło…
Od czasu powstania raportu minęło 20 lat. Sporo, kiedy myślę o sobie – to 2/3 mojego życia, jednak czy to rzeczywiście dużo dla ewolucji projektów?
W tym czasie ścieżkę krytyczną zastąpiliśmy łańcuchem krytycznym, nauczyliśmy się obsługi MS Project’a, poznaliśmy Scrum’a. Wkroczyliśmy w erę wszechobecnego Internetu, a nawet w erę mobile. Zrozumieliśmy, że sprzedaż powinna być oparta na potrzebach klienta (np. Customer Centric Selling). Dowiedzieliśmy się jak trafiać do użytkownika końcowego (User-centered design). Nauczyliśmy się zbierać, zapisywać, projektować i modelować wymagania (przypadki użycia, diagramy BMPN, modelowanie UML). Mamy dostęp do szybszego, bardziej niezawodnego sprzętu, ogromny postęp w dziedzinie programowania, doskonalimy się także w obszarze zapewnienia jakości oprogramowania, w wyniku czego opracowane zostały standardy testowania oprogramowania (IEEE 829-1998, 829 Standard for Software Test Documentation).
Rynek nasycił się project managerami, pojawiły się nowe metody i metodyki, a co za tym idzie – certyfikaty. Firmy zaczęły dostrzegać znaczenie roli kierownika projektu jako niezależnego stanowiska, rozdrobniły się specjalizacje, co zaowocowało dziesiątkami ekspertów z różnych dziedzin. Zaczęliśmy doceniać znaczenie kompetencji miękkich, a w szczególności menedżerskich – nauczyliśmy się odróżniać szefa od lidera. Zaczynamy stawać się liderami.
Czy jednak to wszystko pomogło nam uporządkować panujący w projektach chaos, utrudniający realizację projektów w budżecie, terminie oraz zgodnie z wymaganiami? Nie.
Dlaczego tak się dzieje?
W nieustającym pędzie nie oglądamy się za siebie, a to właśnie w minionych projektach kryje się odpowiedź na pytanie o przyczyny niepowodzeń lub czynniki decydujące o sukcesie. Nie wyciągamy wniosków, nie przyznajemy się do porażki, nie analizujemy sukcesu. To mnie frapuje na tyle, że temu zagadnieniu na blogu poświęcę serię wpisów, tymczasem dziś inicjuję wątek porażki jako naturalnego kroku na drodze do sukcesu.
Pobierz:
