Blog, debatni večeri, raziskave, knjiga…

Category: Snovanje projekta

Obvladovanje vplivnežev projekta

Eno od večjih tveganj je, da bodo izvedbo projekta ovirali ali jo celo želeli preprečiti posamezniki ali skupine, ki imajo za svoje nasprotovanje lahko pozitivne ali negativne razloge (varovanje narave, prikriti finančni interesi, ipd). Imenujemo jih vplivneži (PMBOK: influencers), delno pa sem jih predstavil že v prispevku, kjer sem opredelil udeležence projekta, njihove interese in vloge. Že tam sem tudi navedel, da jih običajno delimo na notranje (zaposlene v združbi) in zunanje (družbeno – politične ali interesne organizacije), obstajajo pa tudi druge delitve (slika).

Rezultati projekta lahko vplivajo na veliko število posameznikov in združb, česar posledica je veliko število potencialnih vplivnežev. McElroy & Mills (Turner & Simister, 2000) navajata ugotovitve raziskav, da se zaradi vplivnih skupin, ki nasprotujejo kakemu projektu, stroški projekta v povprečju dvignejo za 15%. Zaradi tega zagovarjata proaktivni pristop k obvladovanju vplivnežev, pomembno pa je izkoristiti podporo »projektu naklonjenih« vplivnežev, ki managerju projekta lahko pomagajo s poznanstvi, informacijami in s svojimi izkušnjami.

Vplivneži projekta

Potencialni nasprotniki / vplivneži projektaVir: Cleland, 1999

Omenjena avtorja sta postavila naslednjo definicijo: ravnanje z vplivneži dejansko pomeni neprestan razvoj odnosov z njimi. Analizo vplivnežev je potrebno izdelati v začetnih fazah projekta, saj se na podlagi analize preveri glavne cilje projekta z vidika zadovoljevanja pričakovanj različnih vplivnežev. Priporočljivo je celo nekoliko spremeniti cilje, da bi zagotovili višjo podporo projektu. Burke (2003) poudarja, da je spremembe bolje narediti takoj, kot pa zanemariti nasprotovanja in se z njimi spopasti šele v fazi izvedbe projekta, saj so spremembe občutno dražje v kasnejših fazah projekta.

Young (2000) predlaga, naj si projektni tim že v fazi planiranja projekta postavi naslednja vprašanja:

  • Kdo želi, da projekt uspe, in kdo bi morda želel, da propade?
  • Kdo bo podprl projekt in kdo ga bo oviral ali mu nasprotoval?
  • Kdo bo imel koristi od projekta in kdo kaj izgubil?
  • Čigav uspeh se poveča s projektom in na čigav uspeh vpliva negativno?

Sledi pridobivanje informacij o vplivnežih:

  • Kakšen je dejansko njihov interes in zakaj jih zanima projekt?
  • Kaj pričakujejo od projekta in kakšne so njihove potrebe?
  • Ali jih lahko vključimo v organizacijo (zaradi znanj, izkušenj, posebnih veščin)?
  • Kakšen je njihov položaj in vpliv?
  • Kaj lahko izgubijo s projektom in kako lahko ovirajo izvedbo?

Obstajajo trije glavni pristopi obvladovanja vplivnežev – ignoriranje, informiranje in sodelovanje. Izbira taktike obvladovanja posameznega vplivneža je seveda odvisna od tega, kako močno nasprotuje projektu in kakšen je njegov vpliv. Manj pomembne vplivneže lahko ignoriramo, druge lahko »obvladujemo« s stalnim informiranjem o poteku in koristih projekta, organiziranjem sestankov in posvetovanj, kjer poskušamo prepričati nasprotnike, seveda pa je smiselno določene pripombe  tudi upoštevati. Tretji pristop predlaga vključitev vplivneža med uradne udeležence projekta, kar mu omogoči udeležbo na določenih sestankih ter sodelovanje pri sprejemanju odločitev, ki so povezani z njegovim nasprotovanjem. Lahko celo sodeluje pri izvedbi določenih aktivnosti.

Omenimo še interne vplivneže, med katere štejemo predvsem managerje na različnih nivojih v združbi, kjer se izvaja (interni) projekt. Po mnenju Golda (2002) je predvsem pomembno, da manager projekta doseže visoko podporo ključnih oseb v združbi, kar zahteva visok nivo sodelovanja (»mreženje«) in sposobnosti dobre promocije projekta. Potrebno je razumeti interese in politiko delovanja managerjev, pri promociji projekta pa je potrebno predstaviti predvsem koristi, ki jih bo prinesel projekt.

Potrjevanje, izbira in prioriteta projekta

Mogoče se zdi naslov današnjega prispevka malce nerazumljiv, a ga bom takoj obrazložil. Ob koncu snovanja projekta pristojni v združbi (običajno vrhnji management, za manjše projekta pa tudi linijski managerji) sprejmejo odločitev, da se bo projekt izvedel (= potrjevanje), s potrditvijo pa preide v fazo priprave (planiranja). Večkrat se zgodi, da smo zasnovali več projektov, glede na omejene vire (ljudje, denar) pa v danem trenutku lahko izpeljemo le tretjino predlaganih projektov. Katere? (= izbira). Pri tem bodo eni projekti hitreje povrnili vložena sredstva in bodo predvidoma donosnejši ali pa so kako drugače pomembnejši za združbo, zato si zaslužijo “posebno obravnavo” (= večjo prioriteto). Skupno vsem trem pojmom je, da se za odločanje uporabljajo ista orodja oziroma kazalniki, ki jih bom predstavil v tem prispevku.

Zanimivo je, da za opredelitev kriterijev ocenjevanja projektov kar nekaj bolj znanih strokovnjakov v svojih najnovejših knjigah še vedno upošteva priporočila Sounder-ja iz 1973 (Kerzner, 2009; Pinto, 2010; Meredith & Mantel, 2009). Sounder poudarja, da naj bi model za oceno in izbiro projektov zagotavljal smiselnost in realnost ocen, omogočal oceno kompleksnih projektov, a bil vseeno enostaven za uporabo, omogočal vključevanje novih kriterijev ali spremembo obstoječih, pri čemer ocenjevanje ne bi zahtevalo veliko finančnih sredstev. Pinto dodaja še šesti kriterij učinkovitega modela – primerljivost različnih alternativ projekta, Meredith & Mantel pa kot šestega dodajata možnost računalniške podpore.

Večina avtorjev za oceno projektov uporablja le finančno poslovne kriterije, ki smo jih navedli kot del študije izvedljivosti – analizo stroškov in koristi, neto sedanjo vrednost (NSV), dobo vračanja vloženih sredstev ter interno stopnjo donosnosti (IRR). V redkih novejših delih pa sem našel tudi širše nabore kriterijev – poleg omenjenih so dodani tudi poslovni kriteriji, ki jih je težje finančno oceniti, dodani pa so tudi tehnični kriteriji.

Ocena projekta – enostaven odločitveni model

Kriteriji / model ocene projektaPrirejeno po: Heldman (2002), Kerzner (2009), Pinto (2010)

Kerzner (2009) na primeru novega izdelka (po Souderju) oceno projekta prikaže s 25 kriteriji v petih kategorijah (povzemam nekaj tipičnih kriterijev):

  • vrhnji management – ROI, doba vračanja, velikost investicije, vpliv na rast delnic,
  • inženiring – potrebna oprema, znanje, razpoložljivost ljudi,
  • raziskave – možnost patentiranja, znanje, stroški projekta, razpoložljivost ljudi,
  • trženje – življenjska doba izdelka, velikost trga, število konkurentov,
  • proizvodnja – proizvodljivost, razpoložljivost opreme.

Meredith in Mantel (2009) 44 kriterijev razporedita malce drugače kot Kerzner. Navajata proizvodne kriterije (14), tržne (8), finančne (7), kriterije osebja (7) ter poslovne in administrativne (8).

Kerzner predlaga, da se vsak kriterij oceni od -2 (nesprejemljivo) do +2 (odlično), vmesne stopnje pa so slabo, sprejemljivo in dobro (ocene bi bile lahko tudi od 1 do 5). Če želimo poenostaviti izračun, lahko dodelimo skupno oceno skupini kriterijev ali pa izberemo najpomembnejše kriterije, npr. dobičkonosnost, poslovna tveganja in proizvodljivost. Posameznim kriterijem lahko s ponderji določimo višjo pomembnost, kar pomeni, da je npr. ocena dobičkonosnosti “več vredna” od ocene proizvodljivosti (glej sliko). Projekte tako primerjamo med seboj glede na končni seštevek vseh upoštevanih kriterijev.

Kaj pa prioritete? Projekt z višjo vsoto ocen kriterijev naj bi imel višjo prioriteto! Pinto v zvezi s tem poudarja povezanost projektov s strateškimi usmeritvami združbe – visoka pomembnost strategije, iz katere izhaja projekt (strateški cilj = namen projekta), lahko neposredno pomeni tudi visoko prioriteto projekta. Ali pa je to le en od vplivnejših kriterijev.

In kaj prioriteta pomeni za projekt? Pomembnejši projekt naj bi imel vplivnejšega skrbnika z več pristojnostmi, izkušenejšega managerja, prednost pri izbiri članov tima in koriščenju opreme, prednost pri reševanju kriz in problemov… Vseeno pa prioriteta projekta nima “enake teže” skozi celoten projekt oziroma ne velja v vseh primerih. Nesmiselno bi bilo na primer dati prednost neki manj pomembni aktivnosti (ki ni na kritični poti) projekta z visoko prioriteto pred reševanjem zaostanka projekta z manjšo prioriteto, sploh če je slednji bliža zaključku in bo morebitni prepozni zaključek povzročil poslovno škodo združbi!

Listina, odločba oz. naročilo projekta (project charter)

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

Predlog oz. listina projektaVir: 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.

Obseg, zahteve, specifikacije, konfiguracija proizvodov

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

Opredelitev specifikacij projekta*

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…

Študija izvedljivosti, analiza stroškov in koristi, poslovna tveganja

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

Študija izvedljivosti projektaPrirejeno 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)

Ozadje projekta, problem in idejna rešitev (business case)

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

Predlog projekta / business case*

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?

Snovanje projekta

V tuji literaturi najdemo dva tipična naziva uvodnih faz projekta – conception in initiation. Kot sem navedel v prispevku, kjer sem opredelil faze življenjskega cikla projekta, Oxfordov slovar conception opredeljuje kot proces snovanja ideje ali plana (angl. the process of forming an idea or a plan), slovar tujk pa koncept kot okvirni načrt, koncipiranje pa kot zamišljanje nečesa. Initiation po Oxfordovem slovarju bolj opredeljuje trenutek, kot proces (angl. the act of starting something), a glede na preučene opredelitve obeh pojmov v literaturi, načeloma vsebujeta dokaj podobne aktivnosti. Glede na prevod »koncipiranja« sem se odločil, da bom uvodno fazo poimenoval snovanje projekta.

Frame (2003) navaja, da se projekt začne s potrebo in z željo, da se to potrebo zadovolji. Drugi avtorji »potrebo« prikažejo kot (poslovni) problem (npr. premajhna zmogljivost proizvodnje) ali priložnost (npr. izkoriščanje tržne niše). V večini primerov ima avtor ideje pripravljen tudi že predlog rešitve (nova proizvodna linija, nov izdelek / storitev). Ker pa imajo združbe omejene vire za uresničevanje vseh idej, ideje pa včasih tudi niso tako »genialne«, kot si jih predstavljajo predlagatelji, je potrebno »idejni predlog projekta« še podrobneje oceniti z vidika pričakovanih koristi in zmožnosti izvedbe.

Idejo se zato predloži vodstvu združbe, ki običajno najprej preveri skladnost s poslanstvom in strateškimi usmeritvami združbe, nadalje pa se na podlagi subjektivne ocene smotrnosti ideje odloči, ali bi bila izvedba projekta smiselna. S potrditvijo ideje in določitvijo “snovalnega” tima se začne faza snovanja projekta. Pri tem je potrebno poudariti, da tim, ki zasnuje projekt, načeloma ni isti, kot tim, ki projekt izvede. Vsekakor je bodoči manager projekta lahko član tega tima, ni pa nujno.

Proces in vsebina snovanja projekta

Faza snovanja projekta

Poglejmo še nekaj definicij faze snovanja:

  • Snovanje je prva faza projekta, v kateri se preuči potrebo, ocenijo alternative, ter določijo cilji in skrbnik (sponsor) projekta. Wideman, spletni pojmovnik
  • Snovanje je faza, ki vključuje študijo izvedljivosti projekta, s katero raziščemo zmožnost izvedbe in pričakovane koristi, opredelijo se proizvodi projekta in okvirni plan izvedbe. Charvat (2002)
  • Prva faza projektnega cikla, ki vsebuje obravnavo ideje, odobritev in začetek projekta. Opredelijo se namen in proizvodi projekta. Heldman (2002)
  • Prva faza, kjer se na podlagi zamisli o projektu  ter ocene tehnološke in ekonomske izvedljivosti izdelata okvirna predhodna ocena stroškov ter grobi plan projekta. Kliem & Ludin (1998)
  • Začetna faza, v kateri se opredelijo usmeritve in omejitve projekta. Martin & Tate (2001)
  • Začetna faza projekta, kjer se opredelijo poslovne potrebe, opredli proizvod projekta ter določi managerja projekta. Philips (2004)


V fazi snovanja, ki je običajno v domeni naročnika projekta (uporabnikov), se torej na podlagi idejnega predloga projekta, ki vključuje poslovni problem oz. priložnost ter možne rešitve, oceni smotrnost projekta (kot primerjava zmožnosti in okvirnih stroškov izvedbe ter pričakovanih koristi projekta). Izbere se najboljša rešitev in opredeli obseg projekta. Pri tržno usmerjenih projektih je za večjo zanesljivost potrebno preveriti trg in delovanje konkurence ter oceniti poslovna tveganja. Predvsem v primeru internih projektov, so (bodoči) manager projekta in nekateri člani projektnega tima tudi lahko že člani »snovalnega« tima, kjer sodelujejo kot strokovna pomoč pri opredelitvi zmožnosti izvedbe ter specifikaciji proizvodov projekta.

Podrobneje bomo posamezna področja in dokumente opredelili v kasnejših prispevkih.  Za konec pa še ena dilema. V prispevku, kjer sem opredelil najpomembnejše dokumente projekta, sem navedel, da na koncu faze snovanja nastane »predlog projekta«. Sedaj, po proučevanju »snovanja« pa nisem več prepričan.. Mogoče bi dokument poimenovali kar »Odločba za pripravo projekta«? Kaj menite? Očitno bo to tema za naslednji debatni večer!

V tuji literaturi najdemo dva tipična naziva uvodnih faz projekta – conception in initiation. Kot sem navedel v prispevku, kjer sem opredelil faze življenskega cikla projekta, Oxfordov slovar conception opredeljuje kot proces snovanja ideje ali plana (angl. the process of forming an idea or a plan), slovar tujk pa koncept kot okvirni načrt, koncipiranje pa kot zamišljanje nečesa. Initiation po Oxfordovem slovarju bolj opredeljuje trenutek, kot proces (angl. the act of starting something), a glede na preučene opredelitve obeh pojmov v literaturi, načeloma vsebujeta dokaj podobne aktivnosti. Glede na prevod »koncipiranja« sem se odločil, da bom uvodno fazo poimenoval snovanje projekta.

 

Frame (2003) navaja, da se projekt začne s potrebo in z željo, da se to potrebo zadovolji. Drugi avtorji »potrebo« prikažejo kot (poslovni) problem (npr. premajhna zmogljivost proizvodnje) ali priložnost (npr. izkoriščanje tržne niše). V večini primerov ima avtor ideje pripravljen tudi že predlog rešitve (nova proizvodna linija, nov izdelek / storitev). Ker pa imajo združbe omejene vire za uresničevanje vseh idej, ideje pa včasih tudi niso tako »genialne«, kot si jih predstavljajo predlagatelji, je potrebno »idejni predlog projekta« še podrobneje oceniti z vidika pričakovanih koristi in zmožnosti izvedbe.

 

Idejo se zato predloži vodstvu združbe, ki običajno najprej preveri skladnost s poslanstvom in strateškimi usmeritvami združbe, nadalje pa se na podlagi subjektivne ocene smotrnosti ideje odloči, ali se ideja še podrobneje opredeli. S potrditvijo ideje in določitvijo odgovornega tima se začne faza snovanja projekta. Pri tem je potrebno poudariti, da tim, ki zasnuje projekt, načeloma ni isti, kot tim, ki projekt izvede. Vsekakor je bodoči manager projekta lahko član tega tima, ni pa nujno.

 

Poglejmo še nekaj definicij faze snovanja:

· Wideman, ki ima na spletu zelo obsežen pojmovnik projektnega managementa, navaja, da je snovanje prva faza projekta, v kateri se preuči potrebo, ocenijo alternative, ter določijo cilji in skrbnik (sponsor) projekta.

· Snovanje je faza, ki vključuje študijo izvedljivosti projekta, s katero raziščemo zmožnost izvedbe in pričakovane koristi, opredelijo se proizvodi projekta in okvirni plan izvedbe. Charvat (2002)

· Prva faza projektnega cikla, ki vsebuje obravnavo ideje, odobritev in začetek projekta. Opredelijo se namen in proizvodi projekta. Heldman (2002)

· Prva faza, kjer se na podlagi zamisli o projektu  ter ocene tehnološke in ekonomske izvedljivosti izdelata okvirna predhodna ocena stroškov ter grobi plan projekta. Kliem & Ludin (1998)

· Začetna faza, v kateri se opredelijo usmeritve in omejitve projekta. Martin & Tate (2001)

· Začetna faza projekta, kjer se opredelijo poslovne potrebe, opredli proizvod projekta ter določi managerja projekta. Philips (2004)

V fazi snovanja, ki je običajno v domeni naročnika projekta (uporabnikov), se torej na podlagi idejnega predloga projekta, ki vključuje poslovni problem oz. priložnost ter možne rešitve, oceni smotrnost projekta (kot primerjava zmožnosti in okvirnih stroškov izvedbe ter pričakovanih koristi projekta). Izbere se najboljša rešitev in opredeli obseg projekta. Pri tržno usmerjenih projektih je za večjo zanesljivost potrebno preveriti trg in delovanje konkurence ter oceniti poslovna tveganja. Predvsem v primeru internih projektov, so (bodoči) manager projekta in nekateri člani projektnega tima tudi lahko že člani »snovalnega« tima, kjer sodelujejo kot strokovna pomoč pri opredelitvi zmožnosti izvedbe ter specifikaciji proizvodov projekta.

Podrobneje bomo posamezna področja in dokumente opredelili v kasnejših prispevkih.

Za konec pa še ena dilema. V prispevku, kjer sem opredelil najpomembnejše dokumente projekta, sem navedel, da na koncu faze snovanja nastane »predlog projekta«. Sedaj, po proučevanju »snovanja« pa nisem več prepričan, da je bi »project charter« prevedel v predlog projekta. Mogoče bi dokument poimenovali kar »Odločba za pripravo projekta«? Kaj menite? Očitno bo to tema za naslednji debatni večer…

Izbira managerja projekta

O nalogah, veščinah in osebnostnih lastnostih managerja projekta sem že pisal, tokrat pa bi napisal še nekaj o tem, kdaj, kdo in na podlagi česa izbere managerja (bodočega) projekta. V »projektno« razvitih« združbah je to utečen postopek, še posebej če pri tem sodeluje projektna pisarna, ki sistematično spremlja projekte in ocenjuje delo managerjev projektov.

Pri odločitvi »kdaj?« moramo opozoriti na razliko med internimi in zunanjimi projekti. Pri slednjih se projekt izvede na podlagi pogodbe, ki se sklene na podlagi razpisa / povpraševanja oziroma pripravljene ponudbe. Dokler ni podpisane pogodbe, ni smiselno vlagati preveč truda v projekt, res pa je, da je potrebno pripraviti kakovostno ponudbo, z realnimi roki in ceno, ki bo pokrila stroške izvedbe. Mnogi managerji v inženiring podjetjih se pritožujejo, da tržniki vsevprek pošiljajo ponudbe, ter pridobivajo posle z nemogočimi roki. Mogoče sem prav zato naletel na podjetja, kjer se vodilni pritožujejo, da vse manj ljudi želi prevzeti projekte… Potencialni projektni manager bi moral zato sodelovati tudi že pri pripravi ponudbe, kar mu niti ne bi vzelo preveč časa, sploh če lahko za osnovo uporabi kakšen plan podobnega, že zaključenega projekta.

Pri internih projektih je priporočljivo vključiti predvidenega managerja projekta v snovanje projekta, kjer s svojimi izkušnjami poskrbi za realna pričakovanja (internega) naročnika in vodstva združbe. Kot pa sem že omenil v enem od predhodnih prispevkov, ni priporočljivo, da je manager projekta nosilec snovanja projekta in s tem tisti, ki poskuša prepričati nadrejene, da je projekt potrebno izvesti. Oziroma, kot navaja Thomsett (2002) – skrivnost odličnosti managementa projekta je, da manager projekta ni pobudnik projekta, ter da ima projekt skrbnika, ki res želi, da se projekt izpelje.

Izbira managerja (bodočega) projekta

Izbira managerja / vodje projekta*

Kdo izbere managerja projekta? Na to vprašanje bi težko odgovoril z nekim pravilom, saj je to odvisno od projektne kulture, vloge linijskih managerjev pri izvedbi projektov, vrste projekta, ipd. Nekateri priporočajo, da managerja izbere skrbnik projekta, v manjših združbah je to direktor, lahko je to usmerjevalno – nadzorna skupina (Svet projekta). Pristojnosti za izbiro ima lahko tudi projektna pisarna, sploh če je manager le-te hkrati direktor portfelja projektov. Pravila izbire imajo združbe zapisana v organizacijskem predpisu.

Ko že omenjam projektno pisarno (PMO), lahko o njeni vlogi napišem kaj več. PMO lahko po eni strani skrbi za usposabljanje projektnih managerjev, hkrati pa beleži njihove projektne (ne)uspehe. V interni bazi potencialnih managerjev projektov so zavedena njihova pretekla usposabljanja (z morebitnimi certifikati) ter zaključeni projekti, kjer je sodeloval kot manager ali član ožjega tima. Za vsak projekt se lahko nadalje zabeleži vrsta, kompleksnost, vrednost, trajanje, velikost tima…, kazalniki učinkovite izvedbe (roki, stroški), lahko pa dodamo tudi oceno s strani skrbnika in članov tima. Na podlagi teh informacij bo izbira pravega managerja prihajajočega projekta lažja in zaneslivejša.

Dejavniki izbire večinoma izhajajo iz prioritet in zahtevnosti projekta – organizacijski zahtevnejši in za združbo pomembnejši projekti se seveda zaupajo najbolj (pre)izkušenim projektnim managerjem, podobno kot to velja tudi za določitev članov ožjega projektnega tima. Dejavnike izbire sem prikazal na priloženi sliki.

Charvat (2002) v svoji knjigi navaja, da je »za večino projektov malo verjetno, da bo za managerja projekta izbran nekdo, ki dela v podjetju«. Na žalost nadalje ne opiše razlogov za to, niti ne navaja virov, na podlagi katerih je to napisal. Vseeno pa je smiselno omeniti tudi možnost »najetja zunanjega managerja«, čeprav v Sloveniji ne poznam prav veliko primerov. Mislim, da to še ni »praksa« s našem prostoru, vrhnji management še bolj zaupa lastnim kadrom, katere ima »neposredno pod kontrolo«, predvsem pa je vprašljiva odgovornost zunanjih managerjev, povezana z njihovimi pristojnostmi v združbi, kjer »gostuje«. Namreč – če projekt ne teče po planu, se lahko manager projekta izgovarja na to, da je kriva projektna kultura v združbi (ali npr. razpoložljivost kadrov), po drugi strani pa so »domači« lahko zelo nezaupljivi do zunanjih začasnih managerjev. Da ne omenjam nevoščljivosti… Sicer pa v Sloveniji tudi nisem zasledil izkušenih projektnih managerjev, ki bi ponujali te vrste storitev. Je delo pretežko ali odgovornost prevelika? Ima kdo od vas, ki spremljate blog, kakšne izkušnje s tem? Dodajte komentar…

Vzroki za neuspeh projekta – snovanje in priprava projekta

V prejšnjem prispevku (Uspeh in učinkovita izvedba projekta) sem med drugim zapisal, da se uspešnost projekta ocenjuje z razmerjem koristi, ki jih prinese proizvod projekta, in porabljenih sredstev za izvedbo projekta. Vendar pa večina tujih avtorjev, ki govori o vzrokih za neuspeh projekta, (ne)uspeh enači z (ne)učinkovito izvedbo – z doseganjem rezultatov znotraj dogovorjenih časovnih omejitev, v okviru finančnih omejitev (predračuna stroškov) ter ob ustrezni kakovosti proizvodov. Poglejmo torej najbolj tipične vzroke za neučinkovito izvedbo projekta. Povzel sem jih po več tujih avtorjih (Andersen, Young, Wysocki, White) in seveda po lastnih izkušnjah, predvsem pa se nanašajo na neustrezno delovanje različnih udeležencev projekta.

Snovanje projekta

Prvi problem, ki je osnova za mnogo kasnejših, je neustrezna obravnava ideje oziroma predloga projekta. Kot smo zapisali v opisu faze snovanja (Faze projekta) naj bi se na začetku preverila na podlagi jasnega proizvoda projekta ocenile koristi in izvedljivost projekta.

Vzroki za neučinkovito izvedbo projekta

Management vodenje projekta - vzroki za neuspeh 1*

Predvsem pri organizacijskih projektih se dostikrat zgodi, da je projekt formalno odobren, a ga večina (predvsem linijskih managerjev) podpira »s figo v žepu«. Zaradi manjše podpore ima projekt manjšo prioriteto, manager pa težje dobi ustrezne in razpoložljive kadre. Le-ti mogoče tudi ne podpirajo projekta, kar seveda vpliva na njihovo motivacijo. Pri obravnavanju poročil o projektu se vedno znova sprašujejo o smiselnosti projekta, projektni tim pa je deležen manjše pomoči pri reševanju morebitnih problemov. Zato je pomembno, da je projekt v veliki meri skladen s strateškimi usmeritvami združbe, da so v fazi snovanja jasno opredeljene koristi projekta (za celotno združbo), vodstvo združbe pa mora pred odobritvijo zahtevati od vseh, da izrazijo in utemeljijo kakršnekoli pomisleke glede projekta.

Problemi v kasnejših fazah pa izhajajo tudi iz neusklajene taktike izvedbe – čeprav je način izvedbe ožje gledano stvar projektnega tima, naj bi bil le-ta usklajen tudi z naročnikom in s tistimi linijskimi managerji, katerih zaposleni so člani tima. V nasprotnem primeru bo pri izvajanju prihajalo do nesporazumov, neusklajenega delovanja, odpora, konfliktov, ipd.

Opozorim pa naj še na problem neustrezno definiranega proizvoda, do katerega lahko pride zaradi premalo strokovnega znanja naročnika, neusklajenosti ali zaradi premalo vključevanja končnih uporabnikov (npr. uporabnikov IT rešitve). Nedefinirane zahteve povzročijo neustrezno oceno koristi projekta, sploh pa ogromno sprememb v fazi izvedbe projekta, zato jih je priporočljivo jasno opredeliti že v fazi snovanja oziroma najkasneje v fazi priprave pred začetkom planiranja.

Priprava projekta

Neustrezno planiranje ima za posledico pomanjkljiv terminski in stroškovni plan, projektni tim pa tudi ni pripravljen na kakršnekoli ovire pri izvedbi (kaj šele, da bi te ovire »odstranil« vnaprej). Govorim seveda o površnem planu obvladovanja tveganj.

Prvi vzrok za slab plan je lahko samostojno planiranje managerja projekta, brez sodelovanja nosilcev aktivnosti oziroma nosilnih strokovnjakov za posamezna področja. »Več glav več ve!« Ta rek še kako velja za planiranje projektov. Zelo redki so (če sploh obstajajo) managerji projektov, ki poznajo vsa strokovna področja projekta do potankosti, kar je pogoj za realen plan. Sodelovanje pri planiranju tudi dvigne motiviranost izvajalcev, da bi dosegli dogovorjene (obljubljene) roke.

Plani so nerealni tudi zaradi dveh drugih razlogov – ali so člani tima pri planiranju preveč optimistični (kar se spet dogaja mlajšim in manj izkušenim) ali pa pri planiranju podležejo željam naročnika (kar velja predvsem za interne projekte), brez upoštevanja dejstva, da se projekti redko izvedejo natanko po planu. Pri tem igra dodatno vlogo projektna kultura v podjetju, kjer vodstvo velikokrat od timov zahtevajo nemogoče, le ti pa podležejo pritiskom z željo, da se izkažejo. Spet drugje pa se vsi skupaj sprijaznijo s površnim in nerealnim planom ter že na začetku projekta tudi s kasnejšo zamudo projektov, kar tudi kaže na nizko projektno kulturo. Površen plan seveda pomeni, da je premalo podroben, da so izpuščene posamezne aktivnosti ali je neustrezna ocena potrebnega dela, da ni upoštevana različna usposobljenost izvajalcev, da se zanemarijo morebitni problemi…

Na to opozarjam tudi zato, ker mnogi manj izkušeni managerji pač naredijo samo toliko plana, kot je potrebno za zadovoljitev potreb nadrejenih (nekaj rokov, okvirne stroške in glavne izvajalce), zaradi česar kasneje, med izvedbo, ne obvladujejo časa in običajno zamudijo postavljene roke. Projektni manager mora zase (in ne za nadrejene) izdelati podroben plan, ki mu bo omogočil obvladovano izvajanje aktivnosti!

Powered by WordPress & Theme by Anders Norén