Year: 2011

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?