Publikowane przez Państwa dane mówiące o odsetku zrealizowanych z powodzeniem projektów informatycznych były pesymistyczne w tym sensie, że pokazywały, jak mało z nich kończy się pełnym sukcesem, ale jednocześnie optymistyczne, bowiem wraz z upływem czasu odsetek sukcesu stale rósł. Tymczasem widać, że w ciągu ostatnich kilku lat ten pozytywny trend się załamał.

Myślę, że wynika to głównie z agresywnego podejścia do realizacji projektów w obecnej dekadzie. Firmy decydują się na większe ryzyko, chcą osiągnąć więcej niż dawniej za pomocą wdrożeń czy realizacji systemów IT.

Co stanowi główne przyczyny porażek?

Jim Johnson

Przede wszystkim chodzi o pięć podstawowych czynników - ambicję, arogancję, ignorancję, niegospodarność i nieobecność, czyli faktyczne niezaangażowanie w realizację projektu. Bardzo ważna jest zdolność do szybkiego podejmowania decyzji. To czasem ma znaczenie decydujące. Znam przypadek wdrożenia systemu CRM w dwu prawie identycznych firmach, działających na tym samym rynku. Pierwsza z nich była w na tyle złej sytuacji finansowej, że miała przed sobą wszystkiego może jeszcze cztery miesiące, a dalej bez sprawnego systemu wsparcia obsługi sprzedaży i klienta już by nie przetrwała. Druga z tych firm nie miała już noża na gardle i mogła wdrożenie realizować znacznie spokojniej. Co się okazało? Że w pierwszej z nich system ruszył nawet przed terminem i pozwolił na dalszy rozwój, w drugiej zaś wdrożenie trwało ponad dwa lata i właściwie się nie udało.

Można by się zatem zastanawiać, czy projekty IT to nie są aby zjawiska chaotyczne, odnośnie do których wiadomo przecież, że niewielka zmiana czynników początkowych prowadzi do daleko idącej zmiany rezultatów.

zobacz też Jakość jest wartością Dla dobra wspólnego

Pewnie tak jest, z tym iż można te przyczyny w tym przypadku wyśledzić. Innym moim ulubionym przykładem jest wdrożenie jednego z systemów z zakresu ubezpieczeń społecznych w poszczególnych stanach USA. Wszystkie miały wdrożyć system o identycznej funkcjonalności. Na Florydzie wdrożenie zaczęło się w 1990 r., miało skończyć się po trzech latach i pochłonąć 32 mln USD. Okazało się jednak, że pracowało przy nim ponad 100 ludzi, w tym wielu zewnętrznych konsultantów, system ma zostać uruchomiony dopiero w tym roku, a wydano ponad 230 mln USD. Rzecz udałoby się jeszcze może obronić, gdyby nie to, że w Minnesocie, stanie bardzo podobnym pod względem zaludnienia i potencjału gospodarczego, system o - powtarzam - identycznych zadaniach, zbudowano przed czasem w ciągu niecałego roku pracą ośmiu ludzi i kosztem niewiele przekraczającym 1 mln USD...

To skąd taka różnica?!

W tym, że - po pierwsze - zastosowano możliwie standardowe środowisko pracy i infrastrukturę, po drugie zaś, starano się w możliwie dużym stopniu na samym początku ograniczyć wymagania funkcjonalne - system miał realizować tylko to, co było zasadniczym celem jego budowy, i absolutnie nic więcej. Z naszych obserwacji widać, jak generalnie mała część pierwotnej funkcjonalności w realizowanych projektach IT jest potem faktycznie użytkowana - jest to nawet na poziomie kilkunastu procent. Po cóż więc implementować zbyt wiele?

Czy w prowadzonych badaniach zbieracie także dane dotyczące różnic w realizacji projektów pomiędzy biznesem a instytucjami państwowymi?

Tak, oczywiście, różnice są znaczące i to na niekorzyść administracji, tam znacznie więcej projektów się nie udaje. Jedną z podstawowych zasad, które cały czas powtarzam i polecam, to stwierdzenie, że przystępując do realizacji projektu nie należy pytać się, czy mam wszystko, co będzie potrzebne, tylko lepiej się zastanowić, czy rzeczywiście potrzebuję wszystkiego co mam. Nadmiar zasobów bywa źródłem wielu problemów. W przypadku administracji publicznej spotkać można świetnie zorganizowane biura projektów, wdrożenia norm i dopracowane praktyki stosowanych metod, a mimo tego realizowane tam projekty tak często nie kończą się sukcesem właśnie z uwagi na niegospodarność w dysponowaniu dostępnymi zasobami.

W jakim zatem stopniu w realizacji projektów pomaga wybór określonych narzędzi, metodyk czy zasad?

Gromadzimy również takie dane, ale nie chciałbym tutaj podawać konkretnych wartości. Z grubsza mogę powiedzieć, że dobrze stosować elastyczne podejście do prowadzenia projektu. Prawdopodobieństwo sukcesu trochę podnosi stosowanie narzędzi wspomagających zarządzanie projektem, natomiast narzędzia służące do modelowania nie mają tutaj większego znaczenia. Natomiast radykalna poprawa wynika ze stosowania narzędzi wspomagających zarządzanie i kontrolę wymagań. W przypadku systemów zintegrowanych im więcej modyfikacji chcemy do nich wprowadzić, tym bardziej prawdopodobne, że wdrożenie skończy się klapą.

Podkreśla Pan korzyści płynące ze stosowania elastycznego podejścia i technik miękkich (agile), w szczególności na poziomie realizacji projektów. Tymczasem wielu specjalistów z dużą dozą sceptycyzmu traktuje te nowe wynalazki...

Trudno dyskutować z liczbami. Nasze statystki jasno pokazują, że elastyczne i iteracyjne podejście do realizacji systemów IT pozytywnie wpływa na prawdopodobieństwo sukcesu. Problem z takimi krytykami polega na tym, że nie rozumieją oni, że te miękkie metodyki wcale nie oznaczają odejścia od formalizmów, zasad, które trzeba przestrzegać. Jest wręcz odwrotnie. Techniki miękkie wymagają konsekwencji i jasnych reguł. Są tylko nieco inne. Wydaje się, że są odpowiedzią na inne niż dawniej wymagania biznesu, a przede wszystkim potrzebę szybszego niż dawniej realizowania systemów w znacznie bardziej dynamicznym i zmiennym środowisku, w którym w oczywisty sposób w trakcie wdrożenia zmieniają się wymagania i założenia projektowe. Tu nie ma odwrotu.

The Standish Group jest małą amerykańską firmą, jednak dobrze znaną w branży IT na całym świecie jako jedno z najbardziej wiarygodnych źródeł danych statystycznych dotyczących realizacji projektów informatycznych. Standish Group posiada bazę dotyczącą realizacji ponad 50 tys. projektów z całego świata (dane zbierane są od odbiorców, nigdy zaś od dostawców systemów). Na podstawie danych z bazy publikowane są raporty Chaos Chronicles. Firma świadczy również usługi doradcze w zakresie oceny ryzyka i kosztów realizowanych projektów IT.

10 podstawowych zasad sukcesu projektu IT wg Jima Johnsona 1. Rzeczywiste zaangażowanie użytkowników; 2. Wsparcie ze strony zarządu; 3. Jasno określone cele biznesowe; 4. Odpowiednio dobrany zakres i wymagania; 5. Doświadczony menedżer projektu; 6. Iteracyjny i elastyczny proces realizacji; 7. Zapewniony mechanizm finansowania; 8. Wyedukowany personel; 9. Formalna metodyka; 10. Standardowe narzędzia i standardowa infrastruktura.