O sukcesie informatyzacji urzędu - ale i innych organizacji również - w dziewięćdziesięciu procentach przesądzają pierwsze kroki poczynione przez zespół realizujący projekt.

Projekty w środowisku administracji publicznej bardziej niż gdzie indziej narażone są na niepowodzenie, ponieważ poddane są podwójnej ocenie ze strony zleceniodawców. Z jednej strony zespół projektowy musi postępować racjonalnie i logicznie, aby osiągać założone cele projektu, z drugiej - respektować reguły gry politycznej i obyczaje klienta, czyli kasty urzędniczej, która skupia się na zdobyciu lub utrzymaniu władzy. Sukces projektu może - ale nie musi - iść w sukurs interesom zleceniodawcy. Jeśli nie jest on żywotnie zainteresowany losami projektu, czyli nie postrzega go jako elementu swojej strategii politycznej, to nie dość, że lekceważy projekt - więc nie posuwa się on do przodu - to jeszcze złości się na zespół, a zwłaszcza jego kierownika, ponieważ ten zabiera mu czas i środki, a ponadto stanowi tzw. słabe ogniwo, które zawsze może być wykorzystane przez oponentów politycznych czy biurowych. Wszak oficjalnie projekty w administracji zawsze są inicjowane po to, aby służyć dobru społecznemu. Czy projekt źle idzie, czy dobrze, to zawsze można to zinterpretować w kategoriach politycznych. Menedżerowi projektu grozi więc, że jego zwierzchnik w ramach samoobrony uczyni go kozłem ofiarnym. Grozi to zresztą każdemu kierownikowi projektu w administracji publicznej, bowiem trendy polityczne zmieniają się szybciej niż trwają projekty. Z powodu tego szczególnego usytuowania projektu w administracji ma on szansę tylko pod pięcioma wstępnymi warunkami:

- zleceniodawca postrzega projekt jako zgodny ze swoimi interesami

- szef projektu faktycznie zdejmuje z głowy zleceniodawcy problemy decyzyjne, choć formalnie respektuje władzę swojego zwierzchnika

- jeszcze przed podjęciem projektu ujawniono możliwe rozbieżności interesów wśród wszystkich uczestniczących w projekcie

- finansujący projekt sprawnie balansuje między racjonalnością finansową wydawania swoich pieniędzy a racjonalnością konieczną do osiągnięcia merytorycznego celu projektu

- upublicznianie, czyli szukanie zewnętrznych sojuszników projektu, ale też demonstrowanie swojej wartości przez zespół - tuż przed tym, jak uzyska on masę krytyczną, tzn. będzie nie do zatrzymania bez ogromnych strat.

Oprócz tych wstępnych warunków, istnieje jeszcze kilkanaście innych czynników wpływających na powodzenie projektu, np. jego poprawność, predyspozycje menedżera przedsięwzięcia, kwalifikacje i zgranie zespołu, koncepcja postępowania z partnerami i dostawcami rozwiązań, oprogramowania, sprzętu itd.

Przypadek ALSO

Podstawowym celem projektu ALSO jest wsparcie technologią informatyczną zdolności Ministerstwa Pracy i Polityki Socjalnej do wywiązywania się ze swoich obowiązków wobec społeczeństwa. Projekt ten składa się z trzech podprojektów:

- Systemu polityki socjalnej

- Systemu urzędów pracy

- Systemu wspomagania ministerstwa.

Projekt w przeważającej części finansowany jest z pożyczki Banku Światowego, w mniejszym zakresie przez program Phare, a także przez budżet państwa. Dyrektorem projektu jest Gustaw Pietrzyk, szef biura informatyki w MPiPS, a głównym projektantem Andrzej Gogolewski. Dyrektor projektu podlega wiceministrom, odpowiedzialnym za sprawy pomocy społecznej i zatrudnienia. Są oni klientami zespołu projektowego. W momencie przejęcia projektu ALSO przez Gogolewskiego i Pietrzyka ich pierwszym krokiem było właśnie sprecyzowanie klienta projektu, czyli tych osób w administracji, dla których przedsięwzięcie jest realizowane, które muszą podejmować decyzje i zapewnić środki umożliwiające pracę zespołu. Było to ważne z tego powodu, że administracja ma budowę hierarchiczną i każdy poziom tej hierarchii ma inne, a czasem nawet sprzeczne potrzeby, cele, interesy. Bez ustalenia dla kogo właściwie systemy są budowane, projekt zostałby rozsadzony przez różne oczekiwania i żądania zainteresowanych. "Ustaliliśmy, że głównym użytkownikiem tworzonych systemów jest najwyższy poziom tej hierarchii. Naszymi głównymi klientami są wiceministrowie odpowiednich obszarów" - mówi Gustaw Pietrzyk.

Drugim, niezwykle ważnym krokiem, było ustalenie wymagań wobec systemów, a następnie opracowanie ich mierników. "Wymagań, których nie można zmierzyć, nie sposób spełnić" - twierdzi szef projektu. Odbyło się kilka sesji z użytkownikami, podczas których został najpierw udowodniony sens istnienia i działania klientów, następnie sprecyzowane ich cele, a dopiero potem opisany produkt, który ma powstać w wyniku projektu i wspomagać realizację celów klientów. "Było to niewdzięczne i niezwykle trudne zadanie. Odpowiedni urzędnicy musieli przecież udowodnić swoją użyteczność, pokazać, że wnoszą dodatkową wartość do instytucji, w której pracują, i jak to zrobią. Ponadto to nie my sugerowaliśmy im, że system informatyczny im w czymś ważnym pomoże, lecz zmusiliśmy ich, aby to oni nas przekonali, że konieczne jest wsparcie informatyczne i pokazali w czym. W ten sposób ucięliśmy ewentualne późniejsze dywagacje nad sensem projektu i ponowne ustalanie komu na nim naprawdę zależy. Nie obeszło się bez zmian personalnych" - opowiada Gustaw Pietrzyk. Nie ma wątpliwości, że te wstępne sesje - które przysporzyły mu zarówno wrogów, jak i sojuszników - zwielokrotniły szansę powodzenia przedsięwzięcia.