I znowu wszystkiemu winny czynnik ludzki

Tezę dotyczącą wspomnianego powyżej sceptycyzmu potwierdza tzw.

paradoks Cobba10: "Wiemy, dlaczego projekty upadają, wiemy j a k zapobiec tym upadkom - więc dlaczego one ciągle upadają?" [18]. Wobec zaprezentowanych powyżej faktów autorka tego opracowania stawia niniejszym dodatkowe pytanie: / dlaczego projekty SI nadal będą - w tak dużej przypuszczalnie skali - upadać?

Prezentując dane Standish Group dotyczące ostatniej dekady pokazano, że rzeczywiste docenienie znaczenia czynników niepowodzenia informatycznych przedsięwzięć projektowych nie pozostaje bez wpływu na zmniejszenie skali chaosu w ich realizacji. Toteż problem nie tkwi w tym, że nie potrafim y w praktyce skutecznie zapobiegać przyczynom upadków, że istnieją tzw. czynniki obiektywne, na które nie mamy wpływu, bo to nie z ich winy większość przedsięwzięć kończy się niepowodzeniem, a w tym, że nie wykorzystujemy do tego celu wszystkich

10 Martin Cobb to pracownik Kanadyjskiej Rady Skarbu Państwa, a swój paradoks sformułował on na konferencji CHAOS University w listopadzie 1995 r. w Chatham.

możliwości. Dlaczego? Innymi słowy, jakie są praprzyczyny upadków projektów SI?

Bardzo dosadnie rzecz ujmuje Edward Yourdon, twierdząc, że „(...) Wszystkie kłopoty wynikają ze stosowania niewłaściwych metod (albo z pracowania w ogóle bez metod), złych narządzi lub też nieodpowiednich technik zarządzania projektem. Innymi słowy, przyczyną marszy ku klęsce je s t nasza głupota albo nieudolność." [20], W tym twierdzeniu jest oczywiście sporo przesady - opiera się ono zapewne na założeniu, że „cel uświęca środki” - trudno jednak zaprzeczyć, że ów niekwestionowany autorytet w praktycznym tropieniu powodów „marszy ku klęsce” wytacza właściwy kierunek poszukiwań. Dopatruje się on bowiem przyczyn chaosu nie w specyfice produktu, nie w błędach technologicznych, nie w braku odpowiednich źródeł wiedzy czy właściwych doświadczeń, nie w niezwykle dynamicznej zmienności IT i otoczenia biznesowego, nie w braku podobieństw między inżynierią oprogramowania a inżynierią lądow ą (jak to czynią niektórzy, np. w [12], [7]), ale w przyczynach zależnych od uczestników informatycznych przedsięwzięć projektowych, a przede wszystkim od osób odpowiedzialnych za zarządzanie projektami SI.

I ten sposób rozumowania pokrywa się z ogólnym wnioskiem płynącym z badań Standish Group:. "W 1906 roku na wschodnim wybrzeżu miało miejsce 177 katastrof statków morskich. Owe katastrofy spowodowane były wypadkami, złym zarządzaniem, zaniedbaniami, błędami w ocenie sytuacji i błędami osób pilotujących statki - wszystkie te przyczyny przypisuje się błędom ludzkim (w przeciwieństwie do błędów technologicznych). To samo wynika również z raportu Standish Group dotyczącego błędów w tworzeniu projektów inform atycznych."

[13].

Praprzyczyny niepowodzenia projektów SI leżą zatem w omylnej naturze ludzkiej - czy jednak tylko po stronie osób zarządzających nimi? Okazuje się, iż po wielu latach analiz J. Johnson uzupełnia ogólny, powyżej zaprezentowany wniosek płynący z badań SG, zauważając, iż nierzadko kierownicy projektów SI są zmuszeni zmierzyć się z takimi postawami użytkowników, które nawet najbardziej kompetentnym zarządzającym odbierają szansę na zakończenie wspólnego wszak przedsięwzięcia sukcesem. Ów bowiem skutecznie udaremniają spotykane czasami postawy odbiorców SI, które charakteryzują się przesadną ambicją, arogancją, ignorancją, niegospodarnością (zauważalną zwłaszcza w administracji publicznej), świadomym brakiem aktywności i chęci do współpracy, co skutkuje brakiem rzeczywistego zaangażowania użytkownika w realizację projektu, oraz niechęcią do szybkiego podejm owania decyzji ([18], [3]). W opinii Johnsona one także stanowią źródłowe powody upadków projektów SI [18].

Chaos w projektowaniu SI spowodowany jest zatem czynnikami zależnymi od uczestników tego procesu: z jednej strony zarządzający informatycznymi przedsięwzięciami projektowymi popełniają błędy wynikające głównie z niewystarczającego doceniania w praktyce możliwości skutecznego zapobiegania upadkom projektów SI, z drugiej strony - m ogą oni napotkać na bariery wynikające z niewłaściwych postaw występujących czasami po stronie odbiorców SI. Trudno zaś oczekiwać nie tylko tego, żeby winna tym praprzyczynom

niepowodzeń natura ludzka uległa zmianom, ale nawet tego, aby owe praprzyczyny - owszem, kontrowersyjne i niepopularne - zostały w najbliższym czasie właściwie odebrane i docenione przez większość uczestników informatycznych przedsięwzięć projektowych. Tymczasem przekonanie o ich znaczeniu odbiorców SI, np. o racjonalności ich rzeczywistego zaangażowania w projekt, leży w interesie i gestii osób zarządzających procesem projektowania, jednak - jak się wydaje - oni sami są z reguły nastawieni do tych praprzyczyn upadków zbyt sceptycznie. Być może wynika to z powszechnego w środowisku IT przywiązania do poglądu, że sukces projektu SI zależy od jasnych, algorytmizowalnych reguł i formalizmów - a ich gwarancji na próżno szukać w nieprzewidywalnej naturze ludzkiej, zwłaszcza w zespole ludzi. Na zmniejszenie tego, skądinąd również naturalnego, sceptycyzmu wobec owych źródłowych przyczyn trzeba zapewne jeszcze trochę poczekać - dopiero ja k zostaną one docenione pojawi się realna szansa na znaczny i trwały spadek skali chaosu w projektowaniu SI. Dlatego projekty SI, przynajmniej w najbliższym czasie, nadal będą - w tak dużej przypuszczalnie skali - upadać. A więc znów sceptycyzm...? Raczej świadomość, że w obszarze skuteczności realizacji informatycznych przedsięwzięć projektowych jest jeszcze wiele do zrobienia.

Literatura:

1. Babcock D. L., Morse L. C., Managing Engineering and Technology: An Introduction to Management fo r Engineers, Third Edition, Prentice Hall, Upper Saddle River, New Jersey 2002.

2. Czamacka-Chrobot B., Pomiar rozmiaru funkcjonalnego systemu

informatycznego - sposób na "chaospermanens"?, w: Współczesne kierunki rozwoju informatyki, praca zbiorowa pod red. P. W. Fuglewicza, B.

Jackowskiego, E. Mizerskiej, A. Ostaszewskiej, M ateriały XX Jesiennych Spotkań PTI, Polskie Towarzystwo Informatyczne, Katowice-Mrągowo, listopad 2004.

3. Gamdzyk P., Koszt i ryzyko, Computerworld nr 27/2005, 4.07.05.

4. Hall P., Avoiding Project Failure, SM /ASM 2002 Conference, StickyMinds.com, por.

http://www.stickyminds.com/sitewide.asp?ObjectId=3365&Function=DETAIL BROW S E&ObjectT ype=ART (5.10.05).

5. Hayes F., Chaos is back, Computerworld, November 8, 2004, por.

http://wvAv.computerworld.eom/printthis/2004/0,4814,97283,00.html (27.10.05).

6. Johnson J., Standish Group Study, The XP 2002 Conference, Sardinia, May 2002.

7. Jones C., Software Project Management in 21st Century, American Programmer, Vol. XI, No. 2; February 1998.

8. Karten N., Ten Ways to Guarantee Project Failure, StickyMinds.com, 4.07.03, por.

http://www.stickyminds.com/sitewide.asp?ObjectId=6370&Function=DETAIL BROW SE&ObjectType=COL (4.10.05).

9. Kerzner H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Eight Edition, Wiley, John & Sons, New York 2003.

10. Meredith J. R., M antel S.J., Jr., Project Management, A Managerial Approach, Sixth Edition, W iley, John & Sons, New York 2005.

11. Parker W., The Eight Keys to Project Management Failure, The Workstar Library, 2003 r., por. http://workstar.net/library/pml.htm (5.10.05).

12. The CHAOS Report, The Standish Group International, Inc., West Yarmouth, Massachusetts 1995.

13. Unfinished Voyages, The Standish Group International, Inc., West Yarmouth, Massachusetts 1996.

14. CHAOS: A Recipe f o r Success, The Standish Group International, Inc., West Yarmouth, Massachusetts, 1999.

15. The CHAOS Chronicles II, The Standish Group International, Inc., West Yarmouth, M assachusetts, 2001.

16. The CHAOS Chronicles III, The Standish Group International, Inc., West Yarmouth, M assachusetts, January 2003.

17. Standish: Project Success Rates Improved Over 10 Years, Software Mag.COM, The IT Software Journal, por.

http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish (27.10.05).

18. Johnson J., CHAOS Rising, The Standish Group International, Inc., Materiały konferencyjne z Il-giej Krajowej Konferencji Jakości Systemów

Informatycznych, Computerworld, czerwiec 2005.

19. Stokalski B., Grać aby 'wygrać. Ryzyko i zarządzanie projektami, InfoVide, 1998.

20. Yourdon E., M arsz ku klęsce. Poradnik dla projektanta systemów, WNT, Warszawa 2000.

ROZDZIAŁ VI

JAKOŚĆ JAKO PODSTAWA EFEKTYWNEGO WDROŻENIA