Author: Aljaž Page 7 of 9

Sedaj je že čas, da podrobneje opredelim dokument, ki predstavlja končni proizvod snovanja projekta in naznanja prehod projekta iz snovanja v pripravo. Omenil sem že, da bi ga lahko poimenovali »listina projekta« (angl. project charter), odločba za pripravo ali naročilo projekta.

Spet moram poudariti, da dokument ni različno poimenovan le v slovenskih združbah, ampak sem poleg pojma »project charter«, ki ga navaja večina avtorjev (med njimi tudi Kerzner ter PMBOK), naletel tudi na »project brief« (PRINCE2, Young), »POS – Project overview statement« (Wysocki), »Business Plan« (Brandon) ter »Project mandate« (Andersen).

Poleg tega sem pri tujih avtorjih ugotovil, da eni pod »charter« dejansko razumejo zaključni dokument faze snovanja, spet drugi (Burke, Verzuh, Thomsett) pa ga predstavljajo kot elaborat projekta, torej kot končni dokument priprave projekta s podrobnim planom in organizacijo. Kar neizkušenega projektnega managerja lahko še bolj zmede, je to, da nekateri avtorji dokument poimenujejo z dvema nazivoma, ki jih sicer drugi uporabljajo za dva različna dokumenta – Thomsett: »charter or business case«; Snedaker: »statement of work or project charter«. Da bo zmeda popolna, Verzuh pod vsebino »charterja« predstavi elaborat, sicer pa navaja še »proposal«, ki pa je po vsebini identičen »charterju« drugih avtorjev.

Sicer pa je najbolj pogosta definicija naslednja: »Project charter« je uradni »lansirni« dokument, ki naznanja obstoj projekta, in ki zagotavlja jasno sliko oziroma enako videnje projekta s strani vrhnjega managementa, skrbnika projekta in projektnega tima. Managerju projekta zagotovi potrebne pristojnosti ter mu da »uradno pravico«, da svoj delovni čas lahko posveti projektu, ter da lahko začne s pridobivanjem internih kadrov za izvedbo projekta (Prince2 celo navaja, da s podpisom skrbnik in manager skleneta pogodbo o izvedbi projekta). Poleg tega je vhodni dokument v fazo priprave projekta in prikaže pričakovanja ter omejitve, kot vodilo projektnemu timu pri planiranju projekta.

Primer: Listina oz. odločba za pripravo projekta

Vir: Wysocki, 2009

Nekateri avtorji prikazujejo »charter« kot enostranski obrazec, kjer so prikazane bistvene informacije, v prilogi pa se nahajajo ostali dokumenti faze snovanja (idejna rešitev in študija izvedljivosti). Spet drugi pa predlagajo obširnejši dokument, z vsemi vsebinami. Mislim, da je najbolje, če je to skupen dokument, ki ima na prvi strani standarden obrazec s povzetkom najpomembnejših informacij.

Sicer pa avtorji najpogosteje navajajo naslednjo vsebino dokumenta:

• Osnovne informacije: številka in naziv projekta, skrbnik, manager, (stranka)
• Ozadje projekta – problem / priložnost
• Idejna rešitev, obseg proizvodov in zahteve (specifikacije)
• Študija izvedljivosti
• Analiza deležnikov
• Omejitve projekta in predpostavke
• Proračun in okvirni terminski plan (mejniki in končni rok)
• Kadrovske zahteve oz. ključni kadri

Našel sem tudi naslednjo opredelitev vsebine: skrbnik opredeli zakaj, kaj, kdo, kdaj, kje, kako in za koliko naj bi se izpeljal projekt – za doseganje strateških ciljev združbe! (Burke, 2010).

In kdo pripravi dokument? Večina avtorjev navaja, da je za pripravo odgovoren skrbnik (sponzor) projekta, torej “vplivnejši predstavnik” tistih, ki bodo koristili rezultate projekta. Naletel sem tudi na navedbo, da v praksi dokument pripravi (bodoči) manager projekta, vendar se na koncu pod njega podpiše skrbnik. Vsekakor naj bi veljalo, da odgovornost za pripravo sloni na skrbniku, pri pripravi pa mu lahko pomagajo pobudnik projekta, predvideni manager projekta ter drugi strokovnjaki, ki imajo določena znanja in informacije, potrebne za dobro pripravljeno končno naročilo oziroma odločbo za pripravo / izvedbo projekta.

Naslednji korak procesa snovanja projekta je podrobna opredelitev končnega proizvoda (izdelka, rezultata, storitve, dogodka ali sestavine) – »kaj naj bi nastalo« ob zaključku oziroma do zaključka projekta in »kako bo izgledalo«? Vhodni dokument za opredelitev proizvodov je predlagana rešitev, ki pa jo je potrebno natančneje opredeliti na podlagi potreb uporabnikov. Napisal sem »proizvodov«, saj običajno projekt ne ustvari le enega – projekt razvoja novega izdelka ima npr. naslednje »proizvode«: nov izdelek, dokumentacijo (navodila za uporabo, promocijski brošuro, ipd.), zagotovljene proizvodne zmogljivosti s priučenimi delavci, pridobljene tipske odobritve na ciljnih trgih, ipd.

Celoten nabor predvidenih proizvodov projekta stroka vključuje v »obseg«, ki sem ga časom že na kratko predstavil. Po navedbah avtorjev obstajata dva »tipa« obsega – obseg dela (angl. scope of work ali project scope) in obseg proizvodov (angl. product scope, PMBOK 2004). V fazi snovanja projekta govorimo seveda o slednjem (to, kar sem opisal v prejšnjem odstavku), medtem ko se obseg dela običajno izdela v fazi priprave projekta (taktika izvedbe in planiranje aktivnosti), kar pa je že naloga projektnega tima.

Če smo torej z obsegom opredelili, kaj bo potrebno ustvariti, morajo snovalci v naslednjem koraku te proizvode natančno opredeliti (oblika, karakteristike, funkcionalnost…), dokument pa se običajno imenuje specifikacije (proizvodov), v Sloveniji poimenovan tudi »tehnični zahtevnik« ali pa »projektna naloga«. Pri več avtorjih sem našel delitev specifikacij na »funkcionalne« in »tehnične«. Frame (2003) navaja, da funkcionalne zahteve opisujejo karakteristike proizvodov v običajnem, »netehničnem« jeziku, saj morajo biti razumljive uporabnikom. Tehnične zahteve pa opisujejo karakteristike proizvodov s »tehničnim« jezikom (parametri, strokovni izrazi, pogoji delovanja, ipd.).

Priprava specifikacij – proces in primer

*

Na podlagi obsega in specifikacij projektni tim točno ve, kaj se od njega pričakuje, predstavlja osnovo za pripravo plana izvedbe, ob zaključku projekta, ob predaji proizvodov, pa na podlagi specifikacij naročnik (stranka) preveri ustreznost oziroma usklajenost proizvodov s specifikacijami.

Poleg obsega proizvodov so vhod v pripravo specifikacij predvsem zahteve (angl. requirements) uporabnikov, zato je naloga pobudnika in snovalcev projekta, da čim bolj analizirajo želje in potrebe uporabnikov. Če se bo projekt izvedel za lastne potrebe (npr. razvoj IT podpore procesu), potem se analiza izpelje neposredno s pogovori z uporabniki, v primeru razvoja novega izdelka za trg, pa se zahteve opredelijo s pomočjo tržne analize.

V primeru, da je podjetje v vlogi (pod)izvajalca in naj bi izvedlo projekt proti plačilu za zunanjega naročnika, pa pričakuje, da bo večino zgoraj omenjene dokumentacije pripravil naročnik. Pri tem je seveda vprašljiva strokovnost snovalcev in uporabnikov pri naročniku (sicer bi mogoče projekt izvedli kar sami), zato je smiselno, da obe združbi specifikacije izdelata skupaj. Kdaj se podpiše pogodba in ali vključuje tudi storitev priprave specifikacij, bomo govorili kdaj drugič.

V povezavi s zahtevami in specifikacijami pa moram omeniti še »konfiguracije« in management konfiguracij (angl. configuration management), ki sem ga tudi že omenil. Burke (2010) navaja, da je konfiguracija (skupaj s študijo izvedljivosti in taktiko izvedbe) vhod v opredelitev obsega del, vendar je še bolj pomembno to, kar navaja Cleland (1999) – da management konfiguracije vključuje obvladovanje funkcionalnih in fizičnih karakteristik proizvodov skozi celoten projekt. Predvsem se to nanaša na morebitne spremembe proizvodov – glavna naloga managementa konfiguracij po potrjenih specifikacijah proizvodov je, da poskrbi za formalno obravnavo predlaganih sprememb specifikacij (vključno z oceno posledic spremembe), ter da s spremljanjem nastajanja proizvodov zgodaj odkrije morebitne poskuse nekontroliranega spreminjanja.

Nekateri avtorji vključujejo pripravo obsega in specifikacij med naloge projektnega managerja, vendar bi se osebno tukaj raje držal drugih priporočil – manager projekta mora predvsem zagotoviti, da so zahteve (obseg, specifikacije) pred začetkom planiranja projekta čim bolj podrobne in nedvoumne, da bo plan realnejši, da ne bo kasnejših konfliktov in sprememb. Poleg tega pa, kot pravi Thomsett (2002), naj manager projekta ne bi bil pobudnik projekta, zaradi česar ne bo »čustveno vezan« na pričakovane proizvode in bo lažje zastopal načelo »povejte mi, kaj naj naredimo, in to bomo storili«. Seveda tako on, kot člani tima lahko sodelujejo pri snovanju (oziroma je celo priporočljivo), a le kot svetovalci – poznajo zmožnosti tehnologije, predlagajo tehnične rešitve, alternative … a na koncu se odločajo uporabniki ali skrbnik projekta! Včasih specifikacije lahko nastanejo šele v sklopu priprave projekta, ko je ožji projektni tim že sestavljen, a še vedno imajo glavno besedo uporabniki…

Združbe seveda ne »zgrabijo« vsake ideje in pobude, zato se takoj ne lotijo projekta, ampak se preudarno odločijo, če in kateri projekt bi bilo smiselno (smotrno) izvesti. Da ugotovimo »ali se splača« izvesti projekt, si pomagamo s primerjavo stroškov izvedbe s pričakovanimi koristmi. Ker je idej lahko veliko, je dostikrat  potrebno izbrati najboljše – načeloma izberemo tiste projekte, ki bodo čim prej prinesli največ koristi. A obstaja še kar nekaj dejavnikov, katerih vplive stroka vključuje v študijo izvedljivosti.

Čeprav sem v praksi izdelal kar nekaj študij, moram priznati, da sem v preteklosti študijo izvedljivosti jemal »dobesedno« kot oceno zmožnosti izvedbe. No, podrobnejši pregled literature mi je razkril, da vključuje tudi vrsto drugih analiz in preverb – vse z namenom, da je odločitev o izvedbi projekta kar najbolj optimalna.

Čeprav naj bi pobuda projekta vsebovala okvirno oceno koristi projekta, je potrebno preveriti, če pobudnik mogoče ni bil preveč optimističen ali pa je mogoče je zanemaril določene dejavnike. Razmisliti je tudi potrebno, ali predlagan projekt dejansko najbolj optimalno rešuje poslovni problem (oz. izkorišča priložnost). Ali mogoče obstajajo druge alternative in kakšne koristi prinašajo? Koristi se seveda finančno ovrednotijo, pri čemer se morajo upoštevati »operativni« stroški npr. proizvodnje izdelka, vzdrževanja linije, ipd.

Študija izvedljivosti

Prirejeno po: Brandon 2006, Heldman&Heldman 2007, Kerzner 2001, Lock 2007, Newell 2002, Thomset 2002, Turner 2009

Drugi del vsebuje oceno zmožnosti izvedbe projekta. Tudi tu je potrebno razmisliti o več alternativah – ali naj se celoten projekt izvede v združbi ali s pomočjo zunanjih izvajalcev? Naj rešitev kar kupimo? Pri tem je seveda potrebno upoštevati zmožnosti zaposlenih (znanje, izkušnje, razpoložljivost), razmisliti je potrebno o potrebnih delovnih sredstvih. Je res, da so zaposleni cenejši od zunanjih, glede na trajanje aktivnosti in kakovost izvedbe? V kakšnem času smo sploh sposobni izvesti projekt? Z vidika pričakovanih koristi je smiselno »finančno ovrednotiti« čas izvajanja (npr. koliko več koristi prinese mesec dni krajši projekt).

Sledi okvirna ocena stroškov izvedbe, pri kateri združbe večinoma uporabijo metodo »top-down«, pri kateri se projekt stroškovno oceni na podlagi dejanskih stroškov preteklih primerljivih projektov. Lahko si pomagajo z oceno svetovalcev, ki so v preteklosti delali na podobnih projektih, ne gre pa zanemariti poklicnih kolegov iz drugih (nekonkurenčnih) združb, sošolcev… ter drugih znancev z izkušnjami s primerljivih projektov. V veliko pomoč snovalcem projekta je pri tem lahko projektna pisarna, ki sistematično analizira zaključene projekte in gradi bazo znanja, lahko pa se vključi tudi predvideni manager projekta.

Po oceni koristi  in stroškov se »analiza stroškov in koristi« (Cost Benefit Analysis) zaključi s primerjavo obeh. Najbolj enostavna ocena smotrnosti izvedbe je seveda razmerje med koristmi in stroški, ki naj bi bilo večje od 1 (donosnost projekta), zanima pa nas tudi, k kolikšnem času bodo prihodki (ali prihranki) povrnili porabljena sredstva (doba vračanja). Za daljše projekte je za realnejšo oceno potrebno upoštevati tudi diskontno stopnjo (NSV – neto sedanja vrednost, razlika med diskontiranim tokom vseh koristi in vseh stroškov investicije / projekta), zelo uveljavljena pa je metoda izračuna interne stopnje donosnosti (IRR, diskontna stopnja, pri kateri je NSV enaka nič).

Pred dokončnim izborom najustreznejše alternative oziroma pred potrditvijo projekta je smiselno tudi preveriti, ali obstaja kakšna možnost, da vračanje vloženih sredstev ne po potekalo pričakovanjih. Mogoče se izdelek ne bo tako dobro prodajal, stanovanj v novem bloku ne bomo mogli tako hitro prodati, prireditev bo obiskalo manjše število ljudi, ali pa nova programska oprema ne bo zmanjšala stroškov procesa za toliko, kot smo se nadejali. Ta vprašanja lahko vključimo v področje ocene »poslovnih tveganj«, upoštevajo pa se pri pesimističnih ocenah pričakovanih koristi, ki se tudi upoštevajo pri izračunu prej navedenih kazalnikov projekta.

Mogoče še to – študija izvedljivosti ne služi le vodstvu, ki se odloča, ali se bo projekt izvedel, podobne študije zahtevajo tudi banke, pri katerih se združbe dogovarjajo za najem kredita za izvedbo projekta!

Na žalost v sklopu preučevanja literature nisem našel priporočila, koliko časa in stroškov je smiselno porabiti za izdelavo študije izvedljivosti. Vsekakor je to odvisno od trajanja in vrednosti projekta, a bi težko navedel priporočljiv odstotek, sploh ker je to odvisno tudi od vrste projekta. Pa pustimo to dilemo za debatni večer…

Na spodnjih povezavah pa najdete še več informacij o obravnavani problematiki:
Uredba o enotni metodologiji za pripravo in obravnavo investicijske dokumentacije na področju javnih financ (Uradni list)
Pravilnik o metodologiji izdelave in vsebini študije izvedljivosti alternativnih sistemov za oskrbo stavb z energijo (Uradni list)
Priročnik za izdelavo analize stroškov in koristi investicijskih projektov (Računovodja.com)
Investicijski elaborat (Računovodja.com)

Pri preučevanju faze snovanja (inicializacije oz. koncipiranja) v literaturi sem naletel na različne opredelitve procesa z različno poimenovanimi dokumenti. V enem zgodnejših prispevkov sem na kratko že predstavil charter in business case, poleg podrobnejše opredelitve omenjenih dveh dokumentov pa bom v naslednjih nekaj prispevkih prikazal še študijo izvedljivosti, »cost/benefit« analizo, specifikacije, SOW, POS, itd.

Najprej naj opozorim, da je faza snovanja sicer del projekta, a vendar aktivnosti te faze niso del managementa projekta. Sodelovanje projektnega managerja pri snovanju projekta je sicer priporočljivo (kot sem omenil zadnjič), vendar pa je ta faza v domeni pobudnika, končnih uporabnikov in/ali bodočega skrbnika projekta (običajno predstavnika končnih uporabnikov). Poleg tega je značilna le za »interne projekte«, katerih rezultati (nov objekt ali oprema, reorganizacija, IT podpora procesu, nov način dela, nov izdelek…) naj bi združbi pobudnika prinesli dolgoročnejše koristi. Združbe, ki projekt izvedejo proti plačilu za znanega zunanjega naročnika, se s snovanjem projekta ne ukvarjajo, razen če pomagajo (svetujejo) bodočemu naročniku pri oceni izvedljivosti še preden slednji sploh objavi povpraševanje.

Vsaka »projektna« pobuda se nedvomno porodi na podlagi lastnih problemov pri delu, ob kritičnem opazovanju delovanja oziroma analizi poslovanja združbe, spremljanju konkurence ali nasploh zaradi sprememb v okolju. Pobudnik projekta mora v začetku predstaviti ozadje problematike (dogajanja na trgu, v združbi), izpostaviti probleme, ki naj bi jih projekt rešil, oziroma priložnosti, ki bi jih bilo smiselno izkoristiti (primere sem prikazal na sliki). V velikih primerih, sploh če projekti izhajajo strateških planov združbe, probleme in priložnosti najdemo v SWOT analizi.

Primeri vsebine predlogov projektov

*

Strokovnjaki navajajo, da ima prvi dokument projekta, imenovan »business case«, katerega pripravi pobudnik projekta, naslednje vsebine:

• ozadje in poslovni problem oz. priložnost
• tržni vidik
• predlagano rešitev (oz. več alternativ s projekcijami učinkov)
• prikaz usklajenosti s strategijo združbe
• poslovne in organizacijske koristi (če je možno, prikazane finančno)
• način merjenja učinkov projekta (prihodkov, prihrankov)

Dokumentu bi lahko rekli tudi »poslovna utemeljitev projekta«, saj naj bi jasno opredelil razloge za izvedbo projekta. Idejna rešitev naj bi bila kasnejši končni proizvod projekta, iz koristi pa izhaja namen projekta. Na podlagi jasno opredeljene pobude se vodstvo združbe prvič odloča o projektu. V primeru pozitivnega mnenja, se snovanje projekta nadaljuje s poglobljeno oceno smotrnosti izvedbe in opredelitvijo obsega projekta.

Omenil sem že, da nekateri slovenski avtorji »business case« prevajajo kot »poslovna študija«, sam pa sem v že omenjenem prispevku navedel, da bi bil primernejši izraz  »idejna rešitev« (opredelitev organizacije, kot naj bi izgledala ob zaključku projekta). Zdaj, ko sem podrobneje pregledal opredelitve več kot dvajset tujih avtorjev, pa bi se mogoče bolj strinjal s »poslovno študijo«, saj, kot sem prikazal v prejšnjem odstavku, vsebuje več, kot le prikaz končne rešitve. Lahko pa bi ga enostavno poimenovali »predlog projekta«? Kaj pa v dokument vključujete vi in kako ga imenujete?