Realizacja celu miarą sukcesu

Cele projektu muszą wynikać z określenia problemu do rozwiązania. W projektach IT dla administracji publicznej w naszym kraju cele mylone są często z produktami.

WIĘCEJ W RAPORCIE COMPUTERWORLD TOP200

Wyjątkową kategorią projektów zasługujących na szczególną uwagę są projekty informatyczne dla administracji publicznej. Ich wyjątkowość wynika z równoczesnego występowania kilku czynników: rozległość i wielopoziomowość instytucji objętych projektami, (najczęściej) długi czas realizacji i jednocześnie wysoki koszt, niezwykle istotny wpływ czynników politycznych i społecznych, zmienność otoczenia prawnego, mnogość interesariuszy, którzy mogą preferować rozwiązania, co prawda zgodne z celami projektu, to jednak zasadniczo odmienne produktowo.

Drażniąca pomyłka

Szczególną przeszkodą na każdym etapie realizacji wszystkich projektów jest rozbieżne rozumienie pojęć takich jak: cel projektu, produkt - usługa, miernik stopnia realizacji i wskaźnik poziomu realizacji, trwałość projektu. Pojęcia te są wyraźnie opisane w dokumentach projektów współfinansowanych ze środków europejskich i mocno dyscyplinują poszczególnych interesariuszy, jednocześnie bezlitośnie obnażając ich wszelkie uchybienia. Mimo tego, wciąż są kłopoty z jednoznacznym pojmowaniem najważniejszych pojęć i działaniem zgodnym z obowiązującymi definicjami.

Cel projektu koniecznie musi wynikać ze zidentyfikowanych problemów. W sektorze publicznym cele formułowane są niekiedy na podstawie manifestów i programów politycznych. Jest to może zrozumiałe z punktu widzenia polityków, ale absolutnie błędne z metodologicznego punktu widzenia. Jeszcze większy kłopot sprawia projekt, którego cel został sformułowany wprost z poziomu inżynierskiego i tylko w związku z nowymi możliwościami technologii. Wówczas, zupełnie słusznie, użytkownicy zazwyczaj nie dostrzegają aspektów praktycznych projektu i tym bardziej krytycznie, a nawet wręcz negatywnie, odnoszą się do nowych rozwiązań.

W sposób wyjątkowy drażni mylenie celów projektu i produktów, które mają w jego ramach powstać. Ten błąd zresztą jest solidarnie popełniany zarówno przez zamawiających, jak i tzw. konsultantów zewnętrznych. Jeżeli produkt zastępuje w rozważaniach cele projektu, to dość szybko pojawią się następujące zagrożenia:

- produkt (w dłuższej perspektywie czasowej) staje się przestarzały, nieatrakcyjny, czyli osiągnięcie celu przestaje satysfakcjonować;

- kadry zarządzające projektem w kolejnych kadencjach - a te praktycznie nie przekraczają nawet dwuletnich okresów - będą dość skutecznie i chętnie modyfikować produkty, podważając w istocie dorobek swoich poprzedników, oddalając tym samym osiągnięcie celów;

- ocena realizacji celów sprowadza się do oceny realizacji produktów, które mogą w gruncie rzeczy służyć czemukolwiek, bo przecież nie są to cele.

Właściwa hierarchia

O sukcesie projektu decyduje w znacznym stopniu etap związany z pracami przygotowawczymi, polegającymi na "definiowaniu celu głównego projektu i tzw. celów szczegółowych", zwanych też inaczej pomocniczymi lub operacyjnymi. Podstawowym warunkiem poprawności zdefiniowania celu głównego i celów szczegółowych jest, jak wskazano wcześniej, poprawna analiza problemów, do których odnosi się projekt. Na to zagadnienie trzeba jednak spojrzeć szerzej: jak zidentyfikować problemy? To zadanie należy do sponsora projektu. To on powinien opisać, jakie widzi bariery w rozwoju społecznym czy gospodarczym lub w komunikacji z klientami czy instytucjami i określić, które jego zdaniem winny być przedmiotem dalszych prac.

Za punkt odniesienia do rozważań na ten temat mogą posłużyć działania podejmowane z wykorzystaniem funduszy europejskich w bieżącym okresie finansowania (2007-2013). Narodowa Strategia Spójności (NSS) wyznacza ramy dla poszczególnych programów operacyjnych i szczegółowych opisów priorytetów. Dokument ten, zaakceptowany przez Komisję Europejską, zawiera "najważniejsze wyzwania dla kraju w perspektywie kolejnych lat" i "określa kierunki wsparcia ze środków finansowych dostępnych z budżetu UE". W skali makro zatem to preferencje sponsora - a ostatecznym sponsorem dla wsparcia finansowego w okresie 2007-2013 jest Komisja Europejska, która zaakceptowała elementy NSS - stały się najważniejsze dla wydatkowania środków unijnych i mogą być przedmiotem dalszego uszczegółowienia.

To, czego brakuje projektom informatycznym w administracji publicznej naszego kraju, to rozsądnie i realnie zakreślone ramy realizacji znajdujące odzwierciedlenie w dobrze zidentyfikowanych problemach i wynikających z podstawowych celów do osiągnięcia. Nie widać związku między podejmowanymi przedsięwzięciami informatycznymi a choćby "Strategią rozwoju społeczeństwa informacyjnego", opracowaną w roku 2008 na okres do roku 2013. Trudno zauważyć jakiekolwiek znaczenie Planu Informatyzacji Państwa, choćby dla zmian w samej administracji publicznej. To, co się dzieje w instytucjach publicznych jest przypadkowym wynikiem nieskoordynowanych (między innymi) przedsięwzięć informatycznych.

Mając to na uwadze, można postawić bardzo prawdopodobną hipotezę, że zarówno plan informatyzacji, jak też strategia informatyzacji, są zbędne. Dokumentem, który może dać szansę na koordynację wysiłków w różnych obszarach administracji publicznej, powinien być dokument podobny w swojej konstrukcji do wspomnianej Narodowej Strategii Spójności. Czy na bazie tego dokumentu (albo innego podobnego) będzie podejmowana próba wyprowadzenia, na przykład według metodyki TOGAF lub innej, modelu infrastruktury teleinformatycznej dla państwa, jest sprawą do ustalenia w następnej kolejności. Tylko właściwa hierarchia dokumentów - od ogólnej strategii poczynając, przez dokumenty programowe, do dokumentów szczegółowo opisujących poszczególne osie działań i ich priorytety z niezbędną infrastrukturą instytucjonalną - jest warunkiem koniecznym, ale nie wystarczającym, do odniesienia sukcesów w pojedynczych projektach z zakresu informatyzacji państwa.

Precyzyjne zasady

Sukces projektu możemy odnotować wówczas, gdy skutecznie zostały zrealizowane cele. Zdefiniowanie celów projektu oznacza wykonanie poprawnej analizy problemów i ustalenie, które z nich stają się właściwe dla projektu. Rekomendacje w tym zakresie są znane, choćby w metodyce "Project Cycle Management", a jednak tutaj właśnie popełnia się najwięcej elementarnych błędów.

Poprawne zdefiniowanie celów projektu wciąż jest w praktyce zadaniem nadspodziewanie trudnym. Najczęściej dostrzegane uchybienia to:

- brak kompletnej analizy problemów w rozważanym obszarze;

- brak związku problemów właściwych dla projektu z treściami dokumentów programowych;

- źle dobrane mierniki i wskaźniki projektu;

- mylenie celów projektu z zadaniami czy produktami;

- poziom wydatkowania środków jako jedyne kryterium postępów;

- statyczne traktowanie projektu i pomijanie zmian otoczenia.

Dla projektów IT w administracji należy dołożyć jeszcze szereg specyficznych, ale istotnych utrudnień. Większość tzw. projektów strategicznych wymaga bowiem integracji obszarów, dla których zarządzanie jest rozlokowane w odrębnych, autonomicznych instytucjach.

Szanse eliminacji wskazanych powyżej uchybień daje stosowanie się do następujących zasad:

- analiza problemów identyfikowanych dla projektu musi wpisywać się w "ogólne drzewo problemów" zidentyfikowanych w dokumentach programowych; takie podejście, przyjęte jako zasada, daje sponsorowi przynajmniej minimalną gwarancję, że jego środki będą sprzyjać realizacji strategii ogólnej;

- cele projektu muszą "zero-jedynkowo" wiązać się z określonymi problemami (tak jak w metodyce PCM); projekt może zakładać dodatkowe cele szczegółowe, ale nie może mieć miejsca sytuacja, że mamy wyłącznie "zawieszone w powietrzu", niewynikające ze zidentyfikowanych problemów, dodatkowe cele szczegółowe;

- mierniki i wskaźniki właściwe dla projektu winny mieć związek z celami projektu. Występujący czasami brak rozróżnienia między pojęciami "miernik" i "wskaźnik" ma swoje częściowe wyjaśnienie w języku potocznym, gdzie pojęcia te stosowane są zamiennie. Natomiast w projekcie zasadniczą odpowiedzialność za poprawność metodologiczną w tym względzie ponoszą solidarnie: instytucje kontrolne, nadzorujące, audytowe, ale i doradcze, a nade wszystko beneficjenci. To właśnie te podmioty na wczesnym etapie zatwierdzają/weryfikują projekt (instytucje nadzorujące), badają poprawność jego przebiegu w trakcie realizacji (audytowe i kontrolne) i ostatecznie akceptują rozliczenie projektu (certyfikujące).

Przyjęcie racjonalnego podziału ról i wzajemne uznanie kompetencji poszczególnych podmiotów zaangażowanych w realizację projektu oznacza, że sposób realizacji celów, definiowanie zadań i produktów pozostaje prawie wyłącznie w domenie zamawiającego i wykonawców. To, czy na przykład usprawnienie usług nastąpi w wyniku dostarczenia rozwiązań w modelu rozproszonym, czy w modelu serwisu centralnego, powinno podlegać wyborom instytucji realizujących projekt. Niestety, często następuje pomieszanie pojęć i funkcji, w wyniku czego instytucje nadzorujące i kontrolne za przesłankę do oceny projektu przyjmują wytworzenie produktu, a nie realizację celu. Zauważmy przy tym, że:

- przyjęcie poziomu wydatkowania jako głównego (a nawet jedynego) kryterium postępów projektu, stanowi element o najwyższej szkodliwości społecznej. Niski koszt jest fałszywie przyjmowany za synonim pewnej przebiegłości instytucji realizujących projekt (zamawiającego) i wyraz dbałości o finanse projektu, gdy tymczasem niejednokrotnie stanowi przeszkodę formalną dla osiągnięcia odpowiedniej jakości i konkurencyjności, a czasem jest wręcz sprzeczny z zasadami jakości;

- zmienność otoczenia prawnego (zmiany aktów prawa), finansowego (np. zmiany kursów walut, eliminacja niektórych projektów), instytucjonalnego (zmiany kadrowe i organizacyjne) jest na tyle duża, że projekty, dla których cykl realizacji trwa 4-5 lat, nie mają praktycznie szansy (nawet sensu) realizacji, jeśli są oceniane przez perspektywę produktową.

Najwyższy stopień trudności w definiowaniu celów projektu występuje w projektach zintegrowanych, które muszą ingerować w autonomiczne obszary przynależne wielu instytucjom. Wydaje się, że o skuteczną receptę na sukces jest w tym przypadku niezwykle trudno. Pewną szansę na przezwyciężenie utrudnień daje trzymanie się sformalizowanych zasad postępowania i "twardych" deklaracji zawierających precyzyjny podział ról, w tym: wskazanie zasobów (przynależnych, udostępnionych, przydzielonych w imieniu sponsora), postawione cele z właściwymi miernikami i wskaźnikami oraz sposób komunikacji. Warto o tym pamiętać przystępując do realizacji złożonych projektów IT w administracji publicznej.

Dr Zbigniew Olejniczak - dyrektor Centrum Projektów Informatycznych od lipca 2010 do marca 2012; w latach 2007-2010 zatrudniony w Centrum Rozwoju Zasobów Ludzkich w Warszawie, m.in. jako koordynator Pionu Realizacji Projektów; w latach 2005-2007 członek i przewodniczący Rady Informatyzacji; od roku 1995 do 1998 uczestniczył w projekcie ALSO, m.in. w zakresie wdrożenia SI PULS; od sierpnia 2002 do października 2006 dyrektor Departamentu Informatyki MPiPS.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200