Mit 4 - Większość projektów IT skazana jest na porażkę.

Rzeczywistość: Zależy jak zdefiniujemy "porażkę".

Na dowód, że niepowodzenie jest wpisane w naturę projektów informatycznych najłatwiej odwołać się do statystyk, które masowo publikują handlowcy firm oferujących usługi informatyczne. Czynią to zawsze z zastrzeżeniem - "z nami ci się uda".

Statystykom można wierzyć albo nie, ale kluczowe dla rozprawienia się z tym mitem jest określenie, co w kontekście wdrożenia systemu informatycznego należy uznać za porażkę. Czy będzie nią nieznaczne przekroczenie budżetu czy dopiero sparaliżowanie któregoś z kluczowych procesów biznesowych? "Jeśli uruchomienie systemu opóźni się o trzy miesiące albo budżet zostanie przekroczony o 5%, to można mówić co najwyżej o rozczarowaniu, ale w żadnym razie o porażce" - mówi Jim Shepherd, wiceprezes AMR

Reasearch, która znana jest w USA z opracowań na temat rynku systemów ERP.

W monitorowaniu przebiegu dużych projektów IT na rynku amerykańskim specjalizuje się inna firma - The Standish Group. Na potrzeby opracowania pt. Chaos Report sklasyfikowano aż 13 tys. projektów. Jak wynika z podsumowania, przedsięwzięcia zakończone sukcesem to ok. 34%. Takich, które bezsprzecznie zakończyły się porażką - zarzucono ich kontynuowanie w trakcie wdrożenia - było 15%. Cała reszta, czyli 51% została przez Standish zaliczona do grupy "projekty-wyzwania". Wyzwanie oznacza, że projekty albo kosztowały więcej niż początkowo zakładano, albo trwały zbyt długo, albo wreszcie efekt finalny odbiegał od oczekiwań.

Zaangażowanie przyszłych użytkowników, wsparcie ze strony kierownictwa firmy, doświadczenie kierownika projektu - w tej kolejności The Standish Group wymienia składowe sukcesu. Konsultant z Sapient dorzuca jeszcze jedną - umiejętność znalezienia przyczyny błędu zanim ten ściągnie niepowodzenie na cały projekt.

Mit 5 - Nieskalowalność.

Rzeczywistość: Prawie z każdą technologią można osiągnąć zakładany cel. To kwestia doboru składników i implementacji.

Najbardziej dyskredytujący z zarzutów, jakim można skwitować dowolny produkt informatyczny, brzmi: "nieskalowalność". Taki wyrok prędzej czy później zawiśnie nad każdą technologią, bo każda kiedyś okaże się w danych okolicznościach zawodna.

Skalowalność - podobnie jak "porażka projektu" - jest terminem nieostrym. Przykładowo, od aplikacji możemy oczekiwać, że będzie zarówno "skalowalna w górę", tzn. będzie pracować na największych serwerach działających w trybie przetwarzania równoległego, jak i w "dół", czyli zniży się do poziomu palmtopa lub telefonu komórkowego. Ale rozmiar to tylko jedna z kategorii skalowalności. Inne to m.in. przepustowość, dostępność, wydajność. O tym, jak niesprawiedliwie zarzucamy brak skalowalności jednym technologiom faworyzując inne, niech świadczy poniższy przykład.

Twórcy popularnego w USA serwisu Friendster kojarzącego ludzi o pokrewnych zainteresowaniach porzucili wykorzystywaną dotąd technologię Java (J2EE). Dzięki wdrożeniu w pewnym sensie alternatywnej technologii PHP serwis znacznie lepiej radzi sobie z obsługą komunikacji rosnącej w siłę społeczności Friendstera. Adwokaci PHP triumfują nad adwersarzami, którzy zaciekle utrzymywali, że języki skryptowe "nie skalują się". Wreszcie mogą odpłacić się orędownikom Javy. Tyle, że dokładnie z tych samych powodów, dla których Friendster cieszy się z dobrodziejstw PHP - bez wnikania w szczegóły techniczne - wychwalają Javę informatycy potentata internetowego eBay. Odkąd eBay przeszedł na technologię J2EE stał się żywym słupem reklamowym Suna.

Na podstawie InfoWorld oprac. kfryd