Rejowskie "Ksiądz pana wini, pan księdza..." można wprost odnieść do relacji biznes - informatyka i to niezależnie od tego, czy mówi się o przypadkach sprzed lat trzydziestu, czy o czasach współczesnych.

Jedyna różnica między sytuacją sprzed trzydziestu lat a obecną jest taka, że dawniej strona określana "biznesem" była jeszcze skłonna słuchać, a teraz zrobiła się arogancka i, a priori odrzucając wszelką argumentację, chce tylko żądać i rozkazywać. To ostatnie to - oczywiście - stronnicza opinia kogoś, kto uprawia informatykę. Bo gdyby zapytać strony przeciwnej, to dowiemy się, że nie kto inny, tylko właśnie informatyka chciałaby narzucać już nie tylko swoją wolę, ale również swój sposób postrzegania biznesu, którego dzisiejszej złożoności przecież nie rozumie i o którym w ogóle nie ma pojęcia.

Wszystko przez zmiany

Sprawa wydaje się trudna do pojęcia, gdy założyć, że wszystko, czego biznes oczekuje od informatyki, to rejestrowanie, przechowywanie i dostarczanie informacji. Okazuje się, że te z pozoru proste zadania potrafią - w oczekiwaniach biznesu - osiągnąć taki stopień złożoności, że sprostanie im często ociera się o granice możliwości informatyki. Szczególnie, gdy uwzględnić wysokość przeznaczanych na to środków i czas, w jakim zadanie ma być wykonane.

Wszystko to zaś jest wynikiem zmian, jakie strona biznesowa albo musi, albo chce wprowadzać do zasad swego działania. Musi - bo do tego zmusza ją konieczność reagowania na posunięcia konkurentów lub bo żąda tego prawo. Jeżeli zaś chce, to jest to własna inicjatywa, mająca z założenia konkurentów wyprzedzić albo uprzedzić, a bywa, że jednocześnie jest innowacyjna w charakterze.

Każda zaś taka zmiana (bądź wiele zmian z tego samego obszaru lub o podobnym charakterze) przyjmuje - w celu zastosowania - formę przedsięwzięcia projektowego, mającego stworzyć warunki do jej wprowadzenia w sposób kontrolowany i zharmonizowany z innymi podobnymi zamiarami, mającymi miejsce w tym samym czasie. W efekcie równolegle realizuje się wiele takich działań, które konkurują o zasoby.

Każde niepowodzenie takiego przedsięwzięcia projektowego nakręca spiralę wzajemnych oskarżeń o jego przyczyny. Gdy projekt jest duży i jego budżet liczy się w milionach, które pochodzą z podatków, sprawa staje się przedmiotem zainteresowania publicznego, często podsycanego jeszcze przez media. Te zaś albo poszukują sensacji, a wielkie pieniądze zawsze przyciągają uwagę, albo działają na zamówienie polityczne. Chłodną i rzetelną analizę można co najwyżej znaleźć w prasie fachowej, która, z oczywistych względów, nie dociera do tzw. masowego czytelnika.

Statystyka niepowodzeń

Szczególnym powodzeniem cieszy się opracowanie autorstwa organizacji Standish Group zatytułowane "Chaos Report", publikujące szczegółowe dane o niepowodzeniach przedsięwzięć projektowych, oparte na systematycznie prowadzonych badaniach. Paradoksem jest, że kolejne edycje tego opracowania wskazują na istotną poprawę sytuacji i coraz mniejszą liczbę spektakularnych wpadek dużych projektów, a obiegowo najczęściej cytuje się najbardziej znaną pierwszą wersję raportu z 1995 r., której wymowę trudno uznać za optymistyczną.

Zastanawiając się nad przyczynami niepowodzeń projektów informatycznych, trzeba jednak zauważyć, że istota niemal każdego takiego przedsięwzięcia jest obecnie biznesowa, a i samo pojęcie niepowodzenia nie jest już tak jednoznaczne, jak niegdyś.

Znane i szeroko stosowane metodyki prowadzenia przedsięwzięć projektowych są dość ortodoksyjne, jeżeli chodzi o kryteria ich powodzenia. Koszty projektu mają się mieścić w przewidzianym budżecie, całość ma być wykonana na czas i w ustalonym zakresie. Granica tolerancji jest niewielka i nie przekracza 5-10%.

Coraz to większą popularność zyskuje jednak podejście odwrotne, według którego ani zakresu, ani czasu, ani nawet budżetu projektu nie można traktować sztywno, a kurczowe trzymanie się tych trzech kryteriów częściej bywa błędem niż zasługą. Jest tak dlatego, że ustalając na początku budżet i terminy, działa się na podstawie przesłanek bardziej niż faktów, a - co więcej - w trakcie trwania przedsięwzięcia projektowego mogą się pojawić nowe, wcześniej nieistniejące albo niedostrzegane możliwości np. dalszego, wykraczającego poza pierwotny zakres projektu, rozwoju biznesu. Ich realizacja musi kosztować i musi trwać, ale poważnym błędem kierownictwa projektu byłoby niesięgnięcie po takie możliwości i kurczowe trzymanie się pierwotnych założeń.

Dobrym tego przykładem praktycznym są realizowane obecnie w bankach projekty, których celem jest przystosowanie się do postanowień tzw. Nowej Umowy Kapitałowej. Jedne banki przyjęły tu postawę minimalistyczną i starają się spełnić tylko najbardziej elementarne wymogi, inne zaś dostrzegły dodatkowe możliwości i, kosztem nieco większego wysiłku, podejmują przy okazji próbę również biznesowego wykorzystania możliwości, które w związku z tymi działaniami się pojawiły.

Góra czy dół?

Prowadzenie projektu we wspomniany sposób wymaga nowych umiejętności od jego kierownictwa i - co może wydawać się sprzeczne - jednocześnie dyscypliny i elastyczności podejścia od wszystkich zaangażowanych w jego realizację. Nie oznacza to jednak przyzwolenia na dowolność i swobodę, tylko dlatego że dotychczasowe ograniczenia już nie obowiązują. Trudnym zadaniem dla kierownictwa takiego projektu jest wyznaczenie granic nakreślających jego nowy zakres, budżet i czas realizacji, przy zapewnieniu płynności realizacji i uniknięciu marnowania efektów już osiągniętych.

Zmiana taka jednak z pewnością zwiększa ryzyko niepowodzenia całości przedsięwzięcia, czyli niewykonania obu zakresów - pierwotnego i poszerzonego, bo ten ostatni zdominuje projekt, sprowadzając go na jakieś manowce, doprowadzając do wyczerpania budżetu, bądź do takiego przekroczenia terminów, że wątpliwy stanie się sam sens kończenia realizacji całości. To zaś przybliża te rozważania do próby przypisania sprawstwa tytułowej wpadki.

Obiegowe opinie na ten temat wcale nie są jednoznaczne, a do wspomnianego już tu obwiniania się na linii biznes - informatyka dochodzi jeszcze poszukiwanie przyczyn niepowodzenia w układzie góra - dół. Według jednych opinii sprawa jest oczywista: w poszukiwaniu winnych nie należy spoglądać w dół czy na boki, tylko od razu kierować wzrok w górę. Bo źródło wszelkiego projektowego zła jest właśnie tam, w kierownictwie i komitetach sterujących. Pozostali wykonawcy to tylko trybiki w wielkim mechanizmie.

Jest jednak również spojrzenie, które mówi, że nawet najbardziej wprawne kierowanie projektem musi polec, jeżeli napotka opór na dole. Postawie takiej sprzyja szczególnie część informatyczna przedsięwzięcia projektowego, jako że kierownictwu trudniej tu wniknąć w specjalistyczne zawiłości. Opór taki może być tym większy, im bardziej nierealistyczne wydawać się będą cele i zakres przedsięwzięcia.

Grzechy główne

Pośród przyczyn niepowodzenia przedsięwzięcia projektowego można znaleźć takie, które bez wątpliwości można przypisać stronie biznesowej (np. skrajnie zła ocena oczekiwań klientów), jak i takie, które - również poza wszelką wątpliwością - mają swe źródło po stronie informatycznej. Jest jednak również pewien obszar ziemi niczyjej, którą każda ze stron chętnie zawłaszczy w przypadku sukcesu i którą odrzuci, gdy go zabraknie.

W pierwszej wersji głośnego kiedyś opracowania "The Software Paradigm" prof. Brian Warboys z Uniwersytetu w Manchesterze wymieniał trzy, jego zdaniem historycznie największe, wpadki informatyczne. Jego dobór sprawiedliwie rozdzielał winę między tworzenie oprogramowania (nadmierne dawki promieniowania aplikowane pacjentom przez urządzenie do radioterapii Therac 25), projektowanie (awaria systemu sterowania pracą pogotowia ratunkowego w Londynie) i eksploatację (błędna wersja oprogramowania rakiety Ariane).

W przypadku jednak londyńskiego pogotowia są również opinie, że winę za awarię ponosi strona, nazwijmy to, biznesowa, bo nie zadbała o przestrzeganie ustalonych procedur (a może o same procedury?). Przyczyna tej awarii była w istocie prozaiczna, gdyż system, który przestał działać w kilka dni po uruchomieniu, nie sprostał sytuacji, w której bywało, że do wezwań wyjeżdżały ekipy inne niż przez ten system wskazane.

Można epatować się wynikami kolejnego badania niepowodzeń przedsięwzięć projektowych publikowanego przez Standish Group, więcej jednak mówi pochodząca z tej samej organizacji lista "pięciu grzechów głównych" popełnianych przez kierujących takimi przedsięwzięciami, stanowiąca sumę obserwacji z wszystkich tych badań. Na liście znajdują się: przerost ambicji, arogancja, ignorancja, abstynencja i mijanie się z prawdą. Aby było jasne - dwie ostatnie cechy oznaczają powstrzymywanie się od udziału i informowanie niekoniecznie zgodnie z rzeczywistością, ale za to zawsze na swoją korzyść.

Przerost ambicji kierownictwa projektu przejawia się dążeniem do spełnienia za wszelką cenę kryteriów zakresu, czasu i budżetu, co przejawia się manipulacją zakresem właśnie, gdyż polega zazwyczaj na ograniczaniu ostatniego przed wdrożeniem etapu, którym jest testowanie. Prowadzi to wprost do licznych perturbacji w początkowym okresie działania systemu, co jednak idzie już na karb chorób wieku dziecięcego, jakie każdy nowy system przejść przecież musi.

Wracając raz jeszcze do typowo biznesowych przyczyn niepowodzeń, trzeba wskazać na jakże częsty brak, po stronie biznesu właśnie, świadomości ograniczonych przecież możliwości informatyki, a nawet - wiarę w jej swoistą omnipotencję. Dobrym tego przykładem był przypadek jednego z brytyjskich banków internetowych. Na miesiąc przed jego uruchomieniem, kiedy przygotowania były już de facto zakończone, strona biznesowa, chcąc jeszcze wzmocnić zainteresowanie premierą zapowiedziała, że iluś tam pierwszych klientów nowego banku w nagrodę otrzyma roczny limit kredytowy bez żadnego oprocentowania. Inicjatywy tej nie uzgodniono ze stroną informatyczną. Liczba klientów chętnych do znalezienia się w uprzywilejowanej grupie była tak duża, że system nie sprostał obciążeniu i trzeba było go wyłączyć już w pierwszych godzinach działania. Ponowne uruchomienie nastąpiło dopiero po miesiącu czy dwóch.

W opracowaniach fachowych można znaleźć setki rad i wskazań, jak prowadzić projekty, aby uniknąć niepowodzeń, rozczarowań i strat. Do bardziej oryginalnych należy wspominana już Standish Group, która uważa, że podstawowym warunkiem powodzenia jest podział dużych przedsięwzięć na wiele mniejszych, tak aby jeden projekt można było zamknąć w budżecie nie większym niż 750 tys. USD, zrealizować go szybciej niż 6 miesięcy, angażując do tego nie więcej niż 6 osób. Brak jednak recepty na to, jak udanie skoordynować wiele takich mniejszych projektów, aby zapewnić sukces większego przedsięwzięcia, na które one się składają.

W innym kierunku idzie British Computer Society. Organizacja ta, zaniepokojona wieloma niepowodzeniami dużych projektów realizowanych w obrębie brytyjskiej sfery publicznej, proponuje, by wzorem innych dziedzin, takich jak budownictwo, wprowadzić obowiązek kierowania dużymi przedsięwzięciami i kluczowymi w nich funkcjami przez osoby o potwierdzonej wiedzy, umiejętnościach i praktyce, czego wyrazem byłyby formalnie nadane uprawnienia. Wymowę tego stanowiska osłabia jednak fakt, że właśnie to Stowarzyszenie zajmuje się w Wlk. Brytanii nadawaniem takich uprawnień.

Czyja wina? Bez znaczenia

Wracając do głównego tematu niniejszych rozważań, pewne wydaje się jedno: klęska przedsięwzięcia projektowego, bez względu na przyczyny szczegółowe, jest zawsze klęską całej organizacji, która je podjęła. Tak to postrzega jej otoczenie i tak to widać w jej wnętrzu. Strona biznesowa i informatyczna mogą, a nawet powinny dzielić się wątpliwościami, ale podział na uprawniony do ciągłego stawiania coraz to nowych wymogów biznes i informatykę, która nigdy nie potrafi do końca ich spełnić, jest anachroniczny, o ile był zasadny kiedykolwiek. Informatyka nie jest w stanie rozwiązać problemu biznesowego, z którym nie umie poradzić sobie sam biznes. Tak się złożyło, że obecnie jedna z tych stron bez drugiej istnieć nie może i są one skazane na współpracę. Informatyka może oferować tylko półprodukty, które rangę pełnego produktu zyskują dopiero po dodaniu do nich otoczki biznesowej.

Na nieco niższym poziomie sprawa powodzenia przedsięwzięć projektowych bądź jego braku sprowadza się do ogólnej roli, jaką odgrywa w nich kierownictwo. Tu źródłem sukcesu nie są płynące z góry, bardzo szczegółowe polecenia i drobiazgowa kontrola ich wykonania, lecz inicjatywy oddolne, dla których kierownictwo pełni jedynie rolę katalizatora.

Tak się złożyło, że na krótko przed powstaniem tego tekstu w Kanadzie miała miejsce katastrofa budowlana, a więc taka właśnie, która zdarzyła się w stawianej informatyce za wzór dziedzinie o liczącej tysiące lat tradycji. Cały segment wiaduktu górnej z dwóch krzyżujących się autostrad spadł tam nagle na tę przebiegającą w dole. Dla ofiar tego tragicznego w skutkach wypadku nie ma żadnego znaczenia, czy przyczyną był błąd popełniony na etapie projektu, czy w trakcie jego realizacji.