STROKOVNI PRISPEVKI
B Analiza vodenja projekta izgradnje programske rešitve v državni upravi
Mojca Žlak Abanka Vipa, d. d. mojca.zlak@abanka.si
Izvleček
Prispevek obravnava problematiko vodenja projektov izgradnje programskih rešitev v državni upravi, ki jih navadno izvajajo zunanji izvajalci po sprejeti metodologiji za vodenje tovrstnih projektov. V prispevku je predstavljena analiza projekta, ki ga je izvedel zunanji izvajalec, pri čemer je poudarek na kritični presoji izvedbe projekta, poznavanju metodoloških podlag udeležencev projekta in na metodologiji sami. Kot naročnik bi morala državna uprava pred oddajo projektov v izvedbo zunanjim izvajalcem poskrbeti, da ti dobro poznajo uveljavljena metodološka izhodišča in da se jih smiselno držijo. Tudi metodologija zaradi spreminjajočih se potreb in novih dognanj na področju informacijske tehnologije in projektnega menedž-menta nujno potrebuje posodobitev. Skladno s teoretičnimi osnovami s področja projektnega menedžmenta pri razvoju programskih rešitev in z vodenjem projektov ter s pridobljenimi praktičnimi izkušnjami so na podlagi analize obravnavanega primera v članku prikazani tudi glavni dejavniki uspešnosti organiziranja in vodenja projektov razvoja programske rešitve v državnem organu; podani so predlogi za izboljšave. Ključne besede: projektni, menedžment, informacijska tehnologija, državna uprava, programska rešitev, metodologija vodenja projektov v državni upravi.
Abstract
THE ANALYSIS OF MANAGING A PROJECT ON DEVELOPING A PROGRAMME SOLUTION IN THE STATE ADMINISTRATION
The article discusses the issue of managing projects on developing a programme solution in the state administration. Such projects are generally implemented by external contractors according to the adopted methodology for the management of such projects in the state administration. The article conducts an analysis of a concrete project implemented by an external contractor, particularly emphasising critical assessment of the project implementation, the knowledge about methodological bases held by project participants and the methodology itself. As a contracting authority, the state administration should ensure that external contractors have a good understanding of the established methodological grounds and observe them as appropriate prior to awarding projects to them. At the same time, it is crucial to update the methodology due to changing needs and new findings in the world of information technology and project management. In accordance with theoretical bases from the field of project management regarding programme solution development and practical experience gained in project management, the article also presents the main factors of efficient project organisation and management in developing programme solutions in state bodies and proposes improvements based on the analysis of the example discussed.
Keywords: project management, information technology, state administration, programme solution, methodology of project management in state administration.
1 UVOD	2 PROJEKTNI MENEDŽMENT NA PODROČJU
Ne glede na siceršnjo organizacijo je projektni pristop tudi INFORMACIJSKE TEHNOLOGIJE V DRŽAVNI v državni upravi najprimernejša oblilia za doseganje ciljev UPRAVI
na več področjili. Eno izmed bolj izpostavljenih je gotovo po- Posebnosti projektov informacijske tehnologije (IT) v dročje informatizacije.	državni upravi glede na projekte v gospodarstvu iz-
Finančna sredstva zagotavlja državna uprava iz virajo predvsem iz lastnosti projektnega okolja, ki ga proračvma, ustrezne kadre pa delno sama, v večji meri ustvarja delovanje državne uprave. Ena temeljnih popa z najemanjem zunanjih izvajalcev. Glede na obseg sebnosti izhaja iz dejstva, da so cilji delovanja državne ztmanjega izvajanja je seveda povsem jasno, da so zu- uprave teže določljivi in merljivi, kar otežuje merjenje nanji izvajalci pomemben dejavnik, ki vpliva na uspeš- učinkovitosti in uspešnosti delovanja javnih ustanov, nost projektov. Takšen odnos zahteva vzpostavitev Uspešen zaključek projektov zahteva skrbno pri-ustreznih metodologij in postopkov na strani državne pravo in načrtovanje ter precejšnje usmerjanje napo-uprave kot naročnika in na strani zimanjih izvajalcev. rov vodstva projekta in drugih udeležencev v celovi-
tO obvladovanje projekta med njegovim izvajanjem. Kompleksnost projektnega okolja glede na udeležence projekta ponazarja slika 1.
Ostal i javne
Javna uprava
•.. Nosilna institucija Projekt ■■••-.
, -^Vodstvo — Projektni ' škgpina
^^^yn^ izvajalci"
Gospodarstvo
Uporabniki Državljani
Slika 1: Udeleženci IT-projektow v državni upravi
2.1 Sodelovanje z zunanjimi izvajalci IT-projektov
Državna uprava sodeluje predvsem s ponudniki storitev na ključ, ki ponujajo razvoj paketov integrirane strojne opreme in programske rešitve za točno določeno situacijo aU problem, ki vsebuje tudi svetovanje, načrtovanje in implementacijo rešitve.
Vloga državne uprave pa se ne konča z izbiro zunanjega izvajalca, temveč mora biti tudi v fazi izvajalčevega dela aktivna pri vodenju projekta, za kar potrebuje vodje projektov, ki so sposobni obvladovati zunanje izvajalce in jih voditi v smeri uresničevanja interesov naročnika. Z izbiro zunanjega izvajalca se začne proces, katerega učinkovitost in uspešnost izvajanja je z vidika naročnika postavljena že v razpisni dokumentaciji.
Evropska unija določa, da mora biti za menedž-ment projektov informacijske tehnologije v državni upravi uporabljena standardna metoda projektnega menedžmenta na področju informatike. Krovrü dokument na tem področju so smernice EU za IT-siste-me državne uprave (dokument EU VI/661 /97).
Pred desetimi leti se je nekaj slovenskih državnih organov s pomočjo svetovalcev iz Velike Britanije povezalo v projektu priprave metodologije, ustrezne projektnemu delu v organih državne uprave. Rezultat projekta je predstavljala Metodologija vodenja projektov v državni upravi (MVPDU). Njen temelj so bile izkušnje na področju vodenja projektov informacijske tehnologije in metodologija PRINCE (Pro-
ject ESI Controled Environment). Leta 1997 je bila v Vladi Republike Slovenije sprejeta kot splošno veljavna metodologija v državni upravi (Wohinz, 2006, str. 23). Obsega Priročnik za splošni del (MVPDU) in Priročnik za vodenje^ projektov s področja IT (MVPDU-IT). Zadnja različica priročnika je bila potrjena maja 2001.
3 RAZVOJ PROGRAMSKIH REŠITEV V DRŽAVNI UPRAVI
Za projekte razvoja informacijskih sistemov (v nadaljevanju IS) in projekte izdelave strateških načrtov IS, kot najzahtevnejše in najbolj zapletene vrste projektov informacijske tehnologije pogosto ne zadošča samo uporaba splošne projektne metodologije. Me-nedžerji projektov razvoja programske rešitve si zato pomagajo z metodologijo razvoja IS, ki jih vodi od začetka do končnega cilja, tj. do uporabne programske rešitve.
Uporaba pravilno izbrane metodologije razvoja IS je zelo pomembna, saj daje celotnemu projektu neke vrste smer. V državni upravi je bila razvita enotna metodologija razvoja informacijskih sistemov (EMRIS). Skupaj z MVPDU-IT predstavlja podlago za obvladovanje projektov izdelave strateških načrtov IS in projektov razvoja IS. EMRIS je nastala na podlagi najbolj uveljavljenih metodologij razvoja IS v svetu ter izkušenj avtorjev pri uporabi metodologij v organizacijskih sistemih državne uprave in poslovnih sistemih v slovenskem okolju. Predstavlja standard za uporabo v državni upravi in je tako vodilo kot tudi jezik sporazumevanja pri razvoju IS za razvijalce, uporabnike in tudi za naročnike. Namenjena je tako notranjim izvajalcem v organizacijskih sistemih kakor tudi zunanjim, ki jo morajo sprejeti kot pogoj za sodelovanje z naročniki (Krisper et al., 2003, str. 9).
Poleg metodoloških opisov EMRIS vsebuje tudi podrobno opisan proces razvoja. Ta po fazah, aktivnostih in opravilih .podrobno predstavlja nabor izdelkov, ki morajo nastati v okviru razvoja IS, s čimer opozarja na vse elemente, za katere je treba poskrbeti. Oblikovana je kot metametodologija in nudi celovito podporo za celoten življenjski cikel IS, od posameznega projekta pa je odvisno, kakšen pristop, postopki in opravila bodo uporabljeni ter kako podrobno. Predvideva torej prilagajanje zahtevam
^ v okviru MVPDU-IT se za menedzrnent projekta uporablja termin »vodenje«, vodenje v smislu uveljavljanja projekta pa je opredeljeno kot »spremljanje«.
in potrebam vsakega posameznega projekta, tako da se izvajajo oziroma uporabljajo le tista opravila v ustreznem obsegu, ki dejansko prispevajo h končnemu rezultatu.
4 ANALIZA VODENJA PROJEKTA IN PREDLOGI IZDOUŠAV
Pričujoča analiza vodenja projekta izgradnje programske rešitve temelji na primerjavi zahtev in priporočil metodologije ter dejanske izvedbe pri obravnavanem projektu, upoštevane pa so tudi teoretične * podlage projektnega menedžmenta nasploh. Vključena je ocena uspešnosti projekta ter predstavljeno mnenje glede pomanjkljivosti metodoloških izhodišč. Na podlagi ugotovitev analize so predstavljeni predlogi za izboljšave na področju vodenja prihodnjih projektov ter spremljajočih dejavnosti.
4.1 Podpora vodstva državnega organa projektnemu delu po MVPDU-IT
Brez trdne podpore vodstva in sprejemanja projektnega načina dela pri zaposlenih je uspešna implementacija projektnega dela in metodologije projektnega menedžmenta v institucijo težko izvedljiva.
Sistem projektno organiziranega razvoja IS po MVPDU-IT se je na državnem organu začel vzpostavljati kmalu po njegovi ustanovitvi. Temeljni namen je bil zadostiti zahtevam metodologije in hkrati vzpostaviti učinkovit sistem, ki bo ustrezno povezal vse tri ključne udeležence, ki sodelujejo pri razvoju: zunanje izvajalce, uporabnike in vodstvo.
Državni organ za sistem vodenja projektov ne uporablja MVPDU-IT neposredno, ampak je metodologijo prilagodil svojim posebnostim in zahteve formalno dokumentiral. Notranji organizacijski predpisi, ki definirajo ta sistem dela, obsegajo manj kot 50 strani. V svojem bistvu se do danes niso spreminjali, čeprav so bili pripravljeni po prvi različici MVPDU-IT, ki je bila medtem že spremenjena in dopolnjena. Notranje predpise je treba sproti prilagajati. Ob izdaji nove različice MVPDU-IT sta pregled novosti in vključitev ustreznih novosti obvezna. Notranji predpisi bi morali natančno upoštevati minimalne zahteve metodologije, dodatne zahteve pa so problem posameznega državnega organa.
Do danes se je večina zaposleiuh v državnem organu že srečala s projektnim načinom dela. Večjo težavo predstavlja slabo poznavanje metodologije. V primeru predstavljenega projekta del projektne skupine, ki je
zastopal uporabnike tistih področij, ki so svoje delo do takrat opravljali ročno, ni imel nobenih izkušenj s projektnim delom, zahtev metodologije pa niso poznali niti tisti člani skupine, ki so že sodelovali pri projektih.
Kaj je vzrok za takšno stanje? Glede na to, da se tako rekoč vsak zaposleni prej ali slej sreča s projektnim načinom dela, v državni upravi pa se zahteva delo po MVPDU-IT oz. po notranjih predpisih, ki so nastali na podlagi te metodologije, bi bilo treba redno izvajati izobraževanja in usposabljanja, na katerih bi zaposleni pridobivali metodološka znanja, podkrepljena s primeri iz prakse. Projektni menedžment in poznavanje metodologije ne bi smela biti pozidonirana kot manj pomemben nabor znanj in tehrük, saj je s tem ogrožena uspešnost projektov, manjša pa je tudi učinkovitost izvajanja projektov, kar se kaže v vei^ih stroških.
4.2 Podpora vodstva državnega organa izvajanju projektov
Vodstvo državnega organa je na projektu predstavljal projektni svet, ki je imenoval vodjo projekta naročnika in vodjo projekta izvajalca. S tem sta dobila mandat, da v skladu z opredelitvami v vzpostavitvenem dokumentu projekta (VDP) v načrtovanem času, virih in z odobrenimi finančnimi sredstvi pripeljeta projekt do uspešnega zaključka. Da pa bi to lahko tudi dejansko uresničila, sta potrebovala avtoritativno podporo in pomoč projektnega sveta. Z avtoriteto vodje projekta izvajalca v projektni skupini zaradi medsebojnega poznavanja in prejšnjega sodelovanja ni bilo težav.
Večji problem je predstavljalo pomanjkanje avtoritete vodje projekta naročnika. Projektni svet kot vrhovni organ projekta ga s svojo avtoriteto ni podpiral. V skladu z MVPDU-IT (točka 3. A. 6) in VDP je imel vodja projekta naročnika naloge in pristojnosti, med katere sta sodila tudi koordinacija in delegiranje izvajanja nalog oz. dejavnosti na projektu. Ker je imel vodja v funkcijski organiziranosti nižjo ali enako funkcijo kakor sodelavci na projektu, ki jim je delegiral naloge, ga ti niso sprejemali kot sebi nadrejenega. Člani projektne skupine tudi niso bili razbremenjeni svojih običajnih nalog. Ker so se zanje čutili odgovorni, za naloge, delegirane v okviru projekta pa ne, za delo na projektu niso bili motivirani.
Prišlo je torej do konfliktov glede pristojnosti vodje projekta in funkcijskih vodij nad sodelavci oigana, ki so bili vključeni v projektno skupino, saj so ti imeli dva nadrejena. Funkcijski vodje niso bili ustrezno informirarü o projektu, zato se jim ni zdelo potrebno organizirati
dela v svojih oddelkih tako, da bi podprli delo na projektu s strani članov skupine v svojem oddelku. Brez podpore nadrejenih pa sodelavci, čeprav so bih člani skupine, niso čutili odgovornosti za izvedbo nalog.
Navedene težave bi lahko rešili z naslednjimi ukrepi:
■	projektni svet bi moral obvestiti vse področne vodje, torej vse, ki so bili nadrejeni sodelavcem v projektni skupini, o pomembnosti projekta,
■	predstojnik projektnega sveta bi se moral udeležiti prvega sestanka projektne skupine, na kratko predstaviti cilje projekta ter predati mandat za vodenje projekta določenemu vodji pred vsemi navzočimi,
■	za vodjo projekta bi moral določiti sodelavca s tako visokim položajem v državnem organu, da že zaradi svojega položaja ne bi imel težav z avtoriteto,
■	projektni svet bi se moral redno sestajati, kot je predvideno v metodologiji in potrjenem VDP, ter tako nadzirati potek projekta,
■	v primeru potrebe po vključitvi dodatnih sodelavcev v projekt bi moral biti o tem vodja projekta seznanjen, določena in dokumentirana pa bi morala biti tudi njihova vloga.
Ob ustrezni podpori in zavzetosti vodstva projekta bi se projekt z manjšimi napori uspešno zaključil.
4.3 Ocena uspešnosti projekta
Za ugotovitev uspešnosti projekta metodologija predvideva primerjavo osnovnih načrtov projekta, ki so bili zapisani v VDP z dejansko izvedbo. Če bi uspešnost ocenili s temi merili, bi bile ugotovitve naslednje:
■	stroški projekta - projekt je bil izveden v okviru predvidenega obsega finančnih sredstev;
■	poraba virov - viri so bili uporabljeni v predvidenih okvirih;
■	izdelki - pripravljeni so bili vsi glavni izdelki projekta;
■	časovni potek - projekt je bil izveden v predvidenem času;
■	kakovost - vsi glavni izdelki projekta so ob potrditvi ustrezali standardom kakovosti.
Na podlagi zgornjih ugotovitev bi lahko ocenili, da je bil projekt uspešen. Vendar pa podrobnejša analiza pokaže, da bi lahko bil še veliko bolj.
4.3.1 Stroški projekta
Zahteve za programsko rešitev so bile med načrtovanjem, organiziranjem in v začetnem delu izvajanja
projekta tako nejasne, da je bilo nemogoče predvideti potreben obseg sredstev. Krivce za to situacijo bi lahko iskali v Bruslju, kjer je sedež Evropske komisije, saj od odgovornih ni bilo mogoče pravočasno pridobiti podrobnih definicij.
Dinamiki načrtovanja in izvajanja projekta sta bih prilagojeni prilivom finančnih sredstev, ki so v državni upravi odvisni od letnega proračuna in v drugi polovici niso bili zagotovljeni, zato je imel zunanji izvajalec večjo pogajalsko moč pri zahtevah za dodatna sredstva v drugem delu. Vzrok nastale situacije je bil v tem primeru zimanji, vodstvo državnega organa pa nanj ni imelo neposrednega vpliva. Ker sta bila opisana dinamika in način financiranja predvidena v VDP, projekt ni presegel predvidenih stroškov.
Opozoriti žehm še na dejstvo, da so bih v načrt stroškov vključeni le stroški naročnika v zvezi z najemom zunanjega izvajalca. Za popoln vpogled v stroške projekta bi bilo treba vključiti tudi porabo časa zaposlenih v državnem organu. Vrednostno spremljanje porabe časa sodelavcev državnega organa bi pripomoglo k boljši preglednosti dela zaposlenih in posledično k povečanju učinkovitosti.
4.3.2	Poraba virou
Kot viri na projektu so bili v VDP opredeljeni le kadrovski viri, ti pa kot »notranji in zunanji«. Zaradi nenatančne opredelitve načrta kadrovskih virov lahko sklepamo, da viri niso bUi preseženi. Priporočam, da se uvede načrtovanje notranjih in zunanjih kadrovskih virov ter materialnih virov, če so potrebni, kot ga predvideva metodologija v točki 3. B., torej da se vire natančno opredeli in dodeli dejavnostim, ki so predvidene v terminskem načrtu. V načrtu notranjih kadrovskih virov naj bo opredeljen seznam potrebnih notranjih kadrov, za vsako osebo pa predviden obseg dela ter dinamika dela v življenjskem ciklu projekta, v načrtu zunanjih virov naj bo opredeljen obseg storitev skozi življenjski cikel projekta za posameznega izvajalca, v načrtu materialnih virov pa naj bo opredeljena vrsta in količina potrebne opreme. Na podlagi tako opredeljenih načrtov virov bo mogoče ustrezno spremljati in končno tudi ocenjevati porabo virov.
4.3.3	Izdelki
Pri izdelkih ni pomembno le to, da se pripravijo v okviru projekta. Pomembne so vsebina, kakovost in skladnost.
Prvi in najpomembnejši izdelek v fazi načrtovanja je VDP. Menim, da ni dopustno, da je bila priprava dokumenta, ki je definiral cilj, vsebino, obseg, omejitve, predpostavke, tveganja, načrte itd. projekta prepuščena vodji projekta zunanjega izvajalca, saj je imel tako rekoč proste roke pri vključitvi vseh mogočih elementov, ki so ga varovali pred odgovornostjo v primeru, da izvajanje projekta ne bi potekalo po načrtu.
Naslednja skupina izdelkov so specifikacije zahtev za programsko rešitev. Te specifikacije mora pripraviti projektna skupina naročnika. V primeru obravnavanega projekta je zaradi kratkega roka, neizkušenosti in obremenjenosti članov projektne skupine naročnika pri pripravi sodeloval izvajalec in v tem primeru je ta vključitev v veliki meri pripomogla k pravočasni izvedbi projekta, vendar pa v splošnem neposredno vključevanje izvajalca v pripravo specifikacij zahtev ni dobrodošlo, saj to predstavlja konflikt interesov.
Na podlagi specifikacij je bila pripravljena sistemska analiza. Vključevala je definicijo vhodnih in izhodnih podatkov ter poročil, postopkov obdelave podatkov in ročnega vnosa, slike in opise predvidenih ekranskih mask, diagrame in opise procesov ter funkcijski in entitetno relacijski diagram. Analiza je bila sprejeta brez večjih pripomb in po manjših popravkih so jo uporabniki in vodstvo potrdili. Nato je bil natančno po analizi pripravljen prototip (le kot faza v razvoju sistema, namenjen nadaljnji uporabi pri izgradnji), ki je bil za boljšo predstavitev procesa in predvidenega izgleda ekranskih mask predstavljen projektni skupini. Projektna skupina ga je sprejela z odobravanjem in takoj potrdila, težava pa je nastala ob uvajanju sistema. Ob predstavitvi sistema se je izkazalo, da ta ne pokriva vseh potreb po podatkih teh oddelkov, zato je bilo potrebno dodatno delo oz. dodaten razvoj.
4.3.4 Časovni potek
Projekt se zaradi težav pri definicijah zahtev v začetnem delu ni izvajal v skladu z načrtom, vendar je bila zamuda kasneje nadoknadena, tako da je bil zaključen v predvidenem roku. Pri prihodnjih projektih, predvsem tistih, pri katerih je na voljo kratek čas za izvedbo, priporočam, da terminski načrt pripravi izkušena oseba ali tim pri naročniku, saj bo tako časovni potek projekta sledil dinamiki dela naročnika. V primeru, da načrt pripravlja izvajalec, ga seveda pri-
lagodi po lastnih željah in tako lahko predvidi kratek čas za izvedbo dejavnosti naročnika ter relativno daljši čas za izvedbo njegovih dejavnosti.
4.3.5 Kakovost
Standardi kakovosti so bili predpisani s smernicami in pravilniki sektorja za informacijsko upravljanje in tehnologijo. Težava pri tem je bila, da sodelavcem zunanjega izvajalca ti dokumenti niso bili predloženi. Projekt je bil voden na podlagi pridobljenih izkušenj na preteklih projektih in »po izročilu«, prav tako pa se je tudi zadostilo zahtevam kakovosti.
Kakovost je bila preizkušena predvsem v okviru pregledovanja in potrjevanja pripravljene sistemske analize in testiranja programske opreme, vendar le kot preverjanje praktične uporabnosti, skladnosti s potrjeno sistemsko analizo in pravilnosti delovanja. Dobrodošla bi bila izvedba presoje, kot je predvidena v MVPDU-IT, v točki 3. D. 4, ki bi preverila skladnost s standardi kakovosti, vgrajene varovalke, optimiziranost programske kode, varnost sistema in prijaznost do uporabnikov, s čimer bi dosegli večjo skladnost različnih programskih rešitev, ki tvorijo IS državnega organa in enotne standarde.
IS je po zaključku izgradnje brez težav prestal akreditacijski pregled, ki ga je najprej izvedla pooblaščena revizijska hiša v Sloveniji, nato pa še Evropska komisija, zato ugotavljam, da je zadostil standardom kakovosti.
4.4 Analiza vodenja projekta glede na zahteve metodologije
Pri projektu so sodelovali zunanji izvajalci, pri katerih se ni zahtevalo predznanje s področja poznavanja metodologije vodenja. Dokumentov metodologije ni bilo na vpogled. V točki 3. A. 10 je sicer opredeljeno, da od izvajalcev ni obvezno zahtevati uporabo metodologije, vendar kakovostno sodelovanje ni mogoče, če se vsi projektni udeleženci ne držijo iste metodologije. Dokumenti morajo biti izvajalcu predloženi, poleg tega pa tudi dejansko v uporabi v državnem organu. Preverjati je treba skladnost izvajanja projekta z zahtevami.
4.4.1 Organiziranje
Metodologija se večinoma posveča organiziranju in načrtovanju projekta, saj je uspešna izvedba v veliki meri odvisna od kakovostnega načrta in organizacije. V metodologiji je zbrana najboljša praksa, zato
bi bilo treba upoštevati priporočila in posvetiti večjo pozornost tema dvema fazama projekta.
Organizacija projekta je bila opredeljena že v predlogi VDP, tako da se konkretnemu projektu ni posebej prilagodila. V VDP tudi niso bili poimensko navedeni posamezni člani projektne skupine naročnika, kot to zahteva metodologija v točki 2. B. 5. 2. Formalno imenovanje članov v VDP je potrebno med drugim tudi zaradi psihološkega učinka. Ljudje, ki vidijo svoje ime zapisano v VDP, ob njem pa opredeljene pristojnosti in odgovornosti, čutijo večjo pripadnost in odgovornost za potek projekta. Vzpostavljena organizacija se je razlikovala od priporočene predvsem v naslednjih točkah:
■	projektni svet je bil imenovan, a se ni sestajal,
■	v projektni svet je bil vključen zunanji izvajalec,
■	vrhovni nadzor nad projektom je izvajala oseba, ki na projektu formalno ni imela določene vloge,
■	vodja zunanjega izvajalca je bil po hierarhiji na isti ravni kot vodja projekta naročnika,
■	predstojruk projektnega sveta in vodja projekta zaradi velike razlike v položaju nista bila v primernem medosebnem odnosu,
■	vodja projekta naročnika je bil na najnižji ravni v hierarhiji in ni imel ustrezne avtoritete,
■	vlogo vsebinskega koordinatorja je deloma prevzel vodja projekta naročnika, čeprav za to ni bil usposobljen, deloma pa se naloge niso koordinirale,
■	vodja kakovosti in skupina za presojo kakovosti nista bila imenovana,
■	pri izbiri članov projektne skupine pri naročniku vodja projekta ni imel vpliva,
■	državni organ ni izbral predstavnikov izvajalca,
■	člani projektne skupine naročnika so imeli znanja s svojega delovnega področja, ne pa s področja zahtev EU,
■	člani projektne skupine niso bili razrešeni svojih rednih nalog.
4.4.2 Načrtouanje
Kakovosten projektni načrt je podlaga za kasnejšo uspešno izvedbo projekta. V primeru opustitve ali slabega načrtovanja je pot do uspešne izvedbe težka, največkrat celo nemogoča.
V nasprotju s priporočili metodologije so se v procesu načrtovanja izvajale oz. se niso izvajale naslednje dejavnosti:
■	VDP in vse načrte (načrt izdelkov, načrt virov, stroškov, kakovosti in terminski načrt), ki so bili vključeni v VDP, je pripravil izvajalec,
■	analiza in ocena tveganja ter strukturni in mrežni diagram izdelkov niso bili pripravljeni,
■	terminski načrt ni bil obrazložen tudi opisno,
■	načrti materialnih in človeških virov ter stroškov naročnika niso bili pripravljeni,
■	naročnikovi viri niso bili razporejeni na dejavnosti in opravila,
■	načrt kakovosti ni bil pripravljen,
■	predloga VDP je bila enaka kot pri vseh drugih projektih državnega organa ne glede na njihovo velikost; spremenjeni so bili le cilji, terminski načrt, obseg finančniih sredstev in glavni izdelki, drugo pa je bilo namenjeno le zadostitvi zahtevam metodologije,
■	zahteve sistema je v večji meri pripravil izvajalec,
■	celotni stroški projekta niso bili ocenjeni pred ustrezno pripravo projektnega načrta,
■	uporabniške zahteve niso bile primerno definirane, zato ni bilo mogoče natančno opredeliti rezultatov projekta,
■	v načrtu ni bila predvidena izvedba presoje kakovosti,
■	prehod v fazo izvajanja je bil izveden brez predhodne potrditve VDP, ki ga je sicer pregledal vodja projekta, projektni svet pa ga ni ne potrdil ne zavrnil več tednov; zaradi velike časovne stiske na potrditev ni bilo mogoče čakati, saj bi bila ogrožena pravočasna izvedba projekta,
■	izbira metodologije razvoja programske rešitve je büa prepuščena izvajalcu, tako je razvoj potekal po metodologiji Oracle CDM oziroma notranjih postopkih izvajalca namesto po EMRIS.
Za pripravo načrtov je bil odgovoren vodja projekta, zato bi moral biti seznanjen s sprejetimi cilji, usmeritvanu in načrti naročnika, da bi tako bolje in laže vodil projekt v skladu s temi cilji. Ena izmed možnosti ukrepanj za izboljšanje načrtovanja bi bila določitev vodje projekta v zgodnejši fazi priprave projekta ter njegova vključitev v predprodajne dejavnosti oziroma v začetne faze projekta. S tem bi se vodja projekta seznanil s strategijami in cilji državnega organa ter deloval v skladu z njegovimi interesi.
Ugotavljam, da je bila glavna napaka pri pripravi načrtov in VDP v tem, da je ta dokimientacija nosila vlogo definiranja odnosa med naročnikom in izvajalcem, namesto da bi bila namenjena načrtovanju pro-
jekta, kot to predvideva metodologija, in pri čemer je izvajalec vključen bolj ali manj le pri opredelitvi virov in stroškov. Tako vlogo je VDP verjetno dobil zato, ker v pogodbi med naročnikom in izvajalcem niso bili ustrezno opredeljeni njun odnos, obseg dela, cilji in načrti.
Jasno defiiurane zahteve naročnika so podlaga, na kateri zunanji ponudnik pripravi ponudbo, izvajalec izvede zahtevana dela, naročnik pa jih spremlja. Definiranje podrobnih zahtev pa nikakor ni preprosto in zahteva čas ter ustrezna znanja. Zaradi pomanjkanja obeh prvin so bile zahteve premalo natančne in usklajene, zato jih je büo treba naknadno podrobneje opredeliti.
Rešitev opisanih problemov bi bila izvedba analize pred začetkom postopka javnega naročila, katere rezultati bi bili podlaga zahtev za javno naročilo. Analizo bi lahko izvedel naročnik sam ali bi glede na to, da ni imel ustreznih znanj za izvedbo analize, najel zunanjega izvajalca.
MVPDU-IT predvideva razvoj IS po EMRIS, vendar je naročnik prepustil izvajalcu izbiro metodologije razvoja. Izvajalec je izbral metodologijo Oracle CDM, pri kateri gre za zelo podoben pristop, saj obe metodologiji predvidevata razvoj po življenjskem ciklu. Oracle CDM je ena izmed metodologij, na podlagi katerih je bila razvita EMRIS. Postopek razvoja programske rešitve je bil sicer ustrezen, vendar bi moral državni organ kljub temu od izvajalca zahtevati razvoj po EMRIS, saj je ta uveljavljena v državni upravi.
4.4.3 Spremljanje projekta, zagotauljanje kakovosti in obvladovanje tveganj
Za spremljanje projekta sta bila odgovorna projektni svet in vodja projekta naročnika, za spremljanje razvoja sistema pa tudi vodja projekta izvajalca, saj je moral poročati naročniku. Vodja projekta naročnika je spremljal projekt na rednih tedenskih sestarJcih projektne skupine. Tako je bila dosežena ustrezna obveščenost vseh odgovornih, vendar so ti prevzemali premalo aktivno vlogo.
V nasprotju s priporočili se projektni svet ni nikoli sestal, niti na nadzornih točkah in pri vodenju ni podpiral vodje projekta. Navedeno je vplivalo na slabšo kakovost vodenja projekta in povzročalo tveganje nepravočasne ter manj kakovostne izvedbe, čemur bi se bilo mogoče izogniti z imenovanjem vsebinskega koordinatorja, izbiro izkušenih in rednih
nalog razbremenjenih članov projektne skupine ter imenovanjem skupine za presojo kakovosti.
Ob zaključku projekta metodologija zahteva dokumentiranje pridobljenih izkušenj, naročnik pa tega ni zahteval in izvedel, prav tako pa ni bil sklican zaključni sestanek projekta. Projekt se ne more in ne sme zaključiti, dokler ni potrjeno kakovostno pripravljeno zaključno poročilo projekta in dokler niso izkušnje, pridobljene na projektu, ustrezno dokumentirane. Zbiranje pridobljenih izkušenj je zagotovo zelo dobrodošlo, saj predstavlja dragocene informacije za druge vodje projektov, pa tudi za novince, ki se šele uvajajo v vodenje. Le tako lahko znanje o projektnem vodenju in pridobljene izkušnje pripomorejo k učinkoviti pripravi, vzpostavljanju in izvedbi prihodnjih projektov.
Neprimerna je tudi opustitev izvedbe zaključnega sestanka, saj je za vse projektne udeležence, ki se več mesecev trudijo za uspeh projekta, zelo pomembno, da se projekt primemo zaključi.
4.4.4	Spremljanje razvoja izdelkov in projektna dokumentacija
Spremljanje razvoja izdelkov in vodenje projektne dokumentacije je bilo primerno, kljub temu pa bi bilo treba uporabljati poimenovanje statusov ter številčenje različic, kakor sta zahtevana v metodologiji.
4.4.5	Projektna pisarna
Pri naročniku bi bila glede na precejšnje število projektov, ki so se izvajali sočasno, smiselna tudi vzpostavitev projektne pisarne, kot jo priporoča in opredeljuje metodologija v točki 3. A. 11. Pri takšnem obsegu je bilo treba veliko načrtovati, izdelati različna poročila, sprenüjati razvoj izdelkov in izmenjavati izkušnje. Vzpostavitev projektne pisarne bi bila dobrodošla, saj bi projektna pisarna lahko nudila pomoč vodji projekta v obliki svetovanja, lahko pa bi tudi opravljala določene naloge namesto nosilcev vlog na projektu.
4.5 Pomanjkljivosti metodoloških izhodišč
Včasih samozadostno načelo učinkovitosti »delati stvari prav« je zgolj eden od pogojev za doseganje uspešnosti, torej delati prave stvari. Treba je biti iispe-šen in učinkovit hkrati, treba je delati prave stvari prav. Ugotavljam, da se je pomanjkljivost metodologije pokazala predvsem na dveh področjih. Prva pomanjkljivost izhaja iz dejstva, da metodologija le v manjši meri opredeljuje razmerje med naročnikom in izvajalcem ter
postopke javnega naročanja, kot drugo pomanjkljivost pa bi izpostavila pomanjkanje opredelitev »mehkih« dejavnikov vodenja, predvsem veščin komuniciranja, motiviranja in vodenja v ožjem smislu.
Projekte se v gospodarstvu izvaja s timskim načinom dela, saj se pri njih srečuje z zapletenimi dejavnostmi, ki posegajo na razhčna strokovna področja (Rozman, Kovač, Koletnik, 1993, str. 2). Prepričana sem, da je tudi v tem, da se dela skupinsko namesto timsko, torej da delo članov ni vedno usmerjeno k istemu cilju in da člani med seboj neposredno ne sodelujejo, da bi ta cilj dosegli, vzrok slabše učinkovitosti državne uprave v primerjavi z učinkovitostjo gospodarstva.
Metodologija v točki 3. A. 9. 3 opredeljuje, da so lahko uporabniške zahteve izvajalcu posredovane v pisni ali verbalni obliki. Dobro bi bilo razmisliti o izključitvi možnosti verbalnega posredovanja zahtev, saj brez dokumentiranja posredovanja zahtev kasneje ni mogoče dokazati.
4.6	Uporaba programske podpore za vodenje projektov
Naročnik vodenja projekta ni podprl s programsko podporo. Izvajanje projekta se je nadziralo po termin-skem načrtu, ki je bil vključen v VDP. Smiselno bi bilo, da bi naročnik zahteval predložitev terminskega načrta v elektronski obliki. Spremljanje izvajanja dejavnosti z ustreznim orodjem je preglednejše in lažje kot ročno, smiselno pa bi bilo tudi vključiti načrt virov in stroškov ter spremljanje izvajanja obeh .načrtov.
Za podporo projektnemu vodenju je bila za vse državne organe razvita programska rešitev Projektna pisarna, ki podpira celoten življenjski cikel projekta. Za njen razvoj in skrbništvo je zadolžen Center vlade za informatiko, državnim organom pa je na voljo brezplačno. Smiselno bi bilo zahtevati izključno uporabo te programske rešitve, ki je razvita po meri državnih organov. Z njeno ustrezno uporabo bi bolje načrtovali obseg dela sodelavcev na projektih in jih ustrezno razbremenili na drugih nalogah, povečali učinkovitost dela na projektih, zagotavljali spremljanje izvajanja projektov in podobno. S tem bi se vzpostavila preglednost dela sodelavcev, h kateri bi vodstva državnih organov morala stremeti.
4.7	Vodenje projektne skupine
Voditi je treba tudi projektno skupino, ne le projekt. Naloga vodje projekta je izbiranje, vpHvanje, spod-
bujanje in usmerjanje članov projektne skupine. Z njimi mora komunicirati in jih motivirati k doseganju ciljev projekta.
4.7.1	Kadrouanje uodje projekta in članov projektne skupine
Kakovostno kadrovanje je izredno pomembno zlasti pri izbiri vodje projekta in sestavljanju timov, saj so tu poleg strokovnega znanja pomembne tudi osebnostne lastnosti in etika. Pri zagotavljanju uspešnih projektov so po številnih raziskavah eden od najpomembnejših dejavnikov tudi ustrezno usposobljeni kadri, pri čemer so še posebno izpostavljeni projektni vodje.
V nasprotju s priporočili metodologije je bila pri naročniku za projektnega vodjo izbrana oseba z neprimerno nizkim položajem glede na druge člane. Zmanjšane pristojnosti bi moral biti vodja projekta sposoben nadomestiti z znanjem in načinom delovanja, ki bi izhajala tudi iz njegovih lastnosti, vendar je bil po osebnosti preblag za izvajanje veščin vodenja. Pri izbiranju projektnega vodje se je posvečalo premalo pozornosti njegovim lastnostim.
Vodja projekta bi moral dobiti vsa pooblastila, da sam na podlagi strokovnosti, izkušenj in osebnostnih lastnosti predlaga člane projektne skupine. Člani bi se morali na podlagi pričakovanih in jasnih pravic in dolžnosti, ki jih bodo imeli kot člani projektne skupine na projektu, prostovoljno odločiti, ali želijo v skupini sodelovati.
Za projektne udeležence naročnika in izvajalca je zelo pomembno tudi poznavanje timskega dela, uporabe MVPDU in MVPDU-IT pri izvajanju projektov, programske podpore za načrtovanje in spremljanje projektov, za projektne vodje pa tudi poznavanje osnov projektnega vodenja, zato priporočam, da se vsaj navedena znanja vključi v nabor znanj, ki jih morajo imeti osebe, če želijo sodelovati na projektu oziroma voditi projekt.
4.7.2	Uodenje v ožjem smislu
Vodenje projekta v ožjem smislu je predstavljalo zapleten proces, saj sta pri vodenju sodelovala vodji projekta naročnika in izvajalca, vsak izmed njiju pa je bil nadrejen svojemu delu projektne skupine oz. tima. Člani projektnega tima izvajalca so se med seboj dobro poznali, v nasprotju z njimi pa se naročnikovi člani projektne skupine med seboj večinoma niso poznali, zato je bil velik del časa, ki je bil namenjen pro-
jektu, porabljen za spoznavanje, formalne pogovore na sestankih ipd. Tim, v pravem pomenu besede, se na strani naročnika ni nikoli razvil. Ugotavljam, da je bila za to kriva med drugim tudi togost in formalizi-ranost odnosov, ki je značilna za državno upravo.
4.7.3	Komuniciranje v projektu
Formalno komuniciranje je v MVPOU-IT zelo podrobno opredeljeno. Pri projektu je pogosto prihajalo do potrebe po povezovanju z neformalnimi komuiuka-cijskimi kanali in neformalnem sodelovanju, vendar so tovrstno komuniciranje v večji meri uporabljali le člani projektnega tima izvajalca ter vodji projekta naročnika in izvajalca med seboj. Projektni vodja naročnika je zgolj po formalnih komunikacijskih kanalih usmerjal projekt in skliceval sestanke.
Z željo in usmerjenim delovanjem projektnega vodje naročnika, ki bi ga podpiral projektni svet, bi bilo mogoče pridobiti tudi zaupanje, doseči enakost in vzajemnost med člani projektne skupine, s čimer bi se povečala tako raven timskega vzdušja kot ustvarjalnost članov. Tako bi vzpostavili odprto in spontano komuniciranje, na katero različen položaj članov v hierarhični strukturi državnega organa in meje organizacijskih enot ne bi imeli vpliva.
4.7.4	Motiviranje projektne skupine
Motiviranje članov projektne skupine je pomembna sestavina vodenja tudi v okolju državne uprave. Projektni vodja mora biti sposoben prepričati ljudi, da hočejo in ne da morajo storiti tisto, kar je potrebno za doseganje ciljev projekta.
Za sodelovanje na projektu bi bilo mogoče vodjo projekta in člane projektne skupine motivirati s tem, da bi jim predstavUi dodelitev nove naloge kot priznanje za dobro predhodno opravljanje dela, kot izziv zaradi svoje enkratnosti in pričakovanih rezultatov ter kot novo stopničko pri napredovanju v karieri v primeru uspešne izvedbe.
Z jasnimi merili uspešnosti projekta bi lahko določili tudi merila za povečanje oziroma zmanjšanje nagrad. Vsi dogovori bi morah biti javni, jasru, med projektom nespremenljivi ter vnaprej znani vsakemu vodji projekta in članu projektne skupine, preden prevzame projekt oz. sodeluje pri njem.
5 SKLEP
Uspešno vodenje projektov razvoja programskih rešitev zahteva visoko učinkovitost, ki jo dosežemo z
natančno pripravljenimi načrti, primerno organizacijo, optimalno izrabo ustrezno izobraženih kadrov, aktivnim spremljanjem, nadziranjem izvajanja in nadziranjem projekta ter vodenjem projektnega tima v realnem času.
S projektnim načinom dela se predvsem na področju informatizacije srečuje tudi naša državna uprava, ki predstavlja specifično projektno okolje. Po meri državne uprave je bila pripravljena in vanjo uvedena metodologija vodenja projektov v državni upravi, posebej za vodenje IT-projektov pa je bil uveden tudi poseben priročnik.
Z uporabo MVPDU-IT se je državni upravi izredno povečala kakovost menedžmenta IT-projek-tov, saj so projekti preglednejši tako z vidika organizacije, v katero se vključujejo zunanji izvajalci, kot z vidika trajanja in stroškov. Na drugi strani pa je opaziti tudi težave, ki jih kljub uvedbi MVPDU-IT državna uprava ni uspela rešiti. S trenutnim stanjem se ni smiselno kar zadovoljiti, zato se je treba ozreti nazaj, podrobno proučiti vsak izvedeni korak, opredeliti pomanjkljivosti pri izvajanju vodenja in nastale težave, poiskati vzroke zanje ter predlagati ukrepe za izboljšave v prihodnje, da pri naslednjih projektih ne bo prihajalo do pri obravnavanem projektu nastahh težav.
Glede na teoretične osnove s področja projektnega menedžmenta pri razvoju programskih rešitev in pri vodenju projektov pridobljenih praktičnih izkušenj so v članku izpostavljeni glavni dejavniki uspešnosti organiziranja in vodenja projektov razvoja programske rešitve v državnem organu na podlagi analize obravnavanega primera, ki jih v nadaljevanju le povzemam:
■	podpora vodstva državnega organa in projektnega sveta izvajanju projekta, izbira in formalno imenovanje ustrezno usposobljenih in izkušenih kadrov (menedžerja projekta s primerno avtoriteto), v času dela na projektu pa razrešitev z drugih nalog,
■	poznavanje metodologije, upoštevanje bistvenih zahtev metodologije in prilagajanje notranjih predpisov najnujnejšim zahtevam metodologije,
■	zahteva uporabe MVPDU-IT in EMRIS pri zunanjem izvajalcu, saj je uporaba teh dveh metodologij predvidena tudi za izvajalce,
■	opredelitev medsebojnega odnosa, obsega dela, ciljev in načrtov za njihov doseg v pogodbi med naročnikom in izvajalcem.
podrobna preučitev in opredelitev uporabniških zahtev za programsko rešitev, kar izvajajo člani projektnega tirna naročnika, naročnikova priprava kakovostnega načrta izdelkov, stroškov, virov (notranjih in zunanjih kadrovskih ter materialnih), analize in ocene tveganja, strukturnega in mrežnega diagrama izdelkov ter VDP; prilagoditev vseh bistvenih postavk VDP konkretnemu projektu,
uporaba programske podpore vodenju projektov, podrobno preverjanje vseh elementov sistemske analize in prototipa, če se izvaja prototipni razvoj,
uvedba timskega načina dela in aktivnega vodenja projektnega tima; ki vključuje komuniciranje ter motiviranje tima, uvedba projektne pisarne, uvedba načrtovanja kakovosti, skupine za presojo kakovosti, najbolje v okviru projektne pisarne, in izvajanja presoj,
izvedba zaključnega sestarüca projekta in priprava baze znanja na podlagi zaključnih poročil, ki morajo vsebovati popis izkušenj, pridobljenih na projektu.
To delo predstavlja kritično analizo izvedbe vodenja projekta razvoja programske rešitve v državnem organu. Pripravljeno je v konstruktivnem duhu, zato naj bo tako tudi sprejeto, predlogi za izboljšave pa preučeni in upoštevani. S še podrobnejšo in bolj razširjeno analizo projektnega menedžmenta v državni upravi bi bilo mogoče opredeUti še dodatne probleme in predstaviti predloge za izboljšave, smiselno pa bi bilo primerjati domačo prakso tudi s prakso drugih držav EU na področju vodenja projektov v državru upravi.
6
[1]
[2]
[3]
[4]
[5]
[6]
LITERATURA IN VIRI
Kolšek Vasja, Černe Meta: Problemi obvladovanja projektov Informacijske tetinologije v javni upravi. Ljubljana: Inštitut za projektni management In Informacijsko tehnologijo, 2005. 4 str.
Krisper Marjan et al.: Enotna metodologija razvoja infonnaclj-sklh sistemov. [Zv. 1], Uvod. Ljubljana: Vlada Republike Slovenije, Center Vlade RS za informatiko, 2003.149 str. Paying Agencies' IT Systems: Computer Security Guidelines No. VI/661/97, rev. 2. Brussels: European Commission Directorate - General VI Agriculture, 1998.10 str. Rozman Rudi, Kovač Jure, Koletnik Franc: Management. Ljubljana: Gospodarski vestnik, 1993. 312 str Vlada Republike Slovenije: Metodologija vodenja projektov v državni upravi: Priročnik: Verzija 1.0. Ljubljana: Ministrstvo za notranje zadeve Republike Slovenije, 1999. 291 str. Wohinz Barbara: Od PRINCE do e-uprave. Poslovna asistenca, Ljubljana, 2 (2006), str. 23-24.
Mojca Žlak je leta 2004 končala dodiplomski univerzitetni študij in se isto leto vpisala na podiplomski študij na Ekonomski fakulteti Univerze v Ljubljani, smer poslovna informatika, kjer je leta 2007 zagovarjala magistrsko delo. Od leta 2003 vodi projekte informatizacije v državni upravi, bankah in drugih finančnih ustanovah. Kot strokovna svetovalka je od leta 2008 zaposlena v Abanki Vipa, d. d.