Blog, debatni večeri, raziskave, knjiga…

Author: Aljaž Page 6 of 9

Ukrepi zniževanja projektnih tveganj

Ko se identificira in ovrednoti tveganja, se začne iskanje načine za znižanje stopnje tveganosti projekta. Najprimernejši ukrepi so tisti, s katerimi poskušamo znižati ali celo odpraviti možnost uresničitve posameznih tveganj, dokaj razširjeno in učinkovito pa je tudi znižanje posledic v primeru, da se tveganje uresniči.

Tveganju se lahko popolnoma izognemo tako, da odstranimo ali obidemo dejavnik tveganja. Slednje je možno s spremembo plana projekta, pri čemer spremenimo celoten projekt ali posamezno fazo, trajanje aktivnosti, taktiko izvedbe, dobavitelja ali izvajalca. Nov plan, s katerim poskušamo zaobiti tveganje, lahko opredelimo kot alternativno metodo doseganja ključnih dogodkov in lahko predstavlja večji strošek izvedbe ali pa tudi ne. Drugi način odprave tveganja je npr. odprava določenih težko dosegljivih zahtev naročnika, kar zahteva pogajanja z naročnikom, pri odločanju pa se običajno primerja velikost tveganja s pričakovanim donosom uresničitve zahteve naročnika.

Znižanje verjetnosti uresničitve tveganj je pristop, podoben predhodnemu, pri čemer se tveganje ne odstrani ampak se poskuša le znižati verjetnost uresničitve. Le-to se največkrat doseže z dodatnimi preventivnimi / kontrolnimi aktivnostmi (in posledično z dodatnimi stroški), možni pa so tudi naslednji ukrepi: boljša (dražja) oprema, drugačna (boljša, dražja) tehnologija izvedbe, pomoč zunanjih strokovnjakov, simulacije in uporaba preizkušenih postopkov.

Seznam tveganj in ukrepov

Ukrepi zniževnja projektnih tveganjVir: prirejeno po Carter et al., 1994

Posledice tveganja lahko ublažimo z aktivnostmi, ki jih izvedemo le v primeru uresničitve tveganja (pristop imenujemo aktivno sprejetje), z zavarovanjem, ter s prenosom tveganja na drugo osebo ali združbo. Zavarovanje je primerno v primeru velikih tveganj, katerih verjetnost dogodka je nizka, a imajo za projekt lahko katastrofalne posledice. V takih primerih se združbe običajno obrnejo na zavarovalnice. Prenos tveganja pomeni prenos kritja dodatnih stroškov, kot posledice morebitne uresničitve tveganja, na drugo osebo ali združbo – na naročnika, zunanjega izvajalca ali dobavitelja, in je opredeljen s pogodbo. Pomembno je, da tveganje prevzame stranka, ki ga laže obvladuje in je za to tudi bolj motivirana.

Ko smo opredelili ukrepe za zmanjšanje tveganj, jih je potrebno vključiti v plan projekta (dodatne kontrolne / preventivne aktivnosti). Korektivnih ukrepov se v terminski plan ne vključi, saj naj bi se izvedli le v primeru uresničitve tveganja. Za primere uresničitve tveganj in izvedbe omenjenih ukrepov se v terminski plan vključijo časovne rezerve. Te se koristijo tudi za pasivno sprejetje identificiranih tveganj ter za vsa tveganja, ki jih projektni tim ni identificiral. Poleg dodatnega časa se predvidi tudi denarna rezerva, ki se uporabi v primeru dodatnih stroškov.

Za celovit pregled najpomembnejših tveganj in še posebno za potrebe kontroliranja tveganj se izdela seznam tveganj s pripravljenimi ukrepi (tabela). Na podlagi seznama projektni manager na kontrolnih sestankih preverja uresničevanje tveganj in udejanjanje ukrepov. O morebitnih pojavih simptomov prihajajočega tveganja poročajo lastniki tveganj, zato seznam tveganj vsebuje tudi simptom in lastnika, torej tistega, ki je zadolžen za kontroliranje posameznega tveganja. Običajno je to član tima, ki sodeluje na aktivnosti, kjer se tveganje lahko uresniči, in ki ima ustrezna znanja, izkušnje in zadosti visok nivo odgovornosti.

Zaključna poročila projektov naj bi vsebovala tudi analizo tveganj projekta – primerjavo problemov in tveganj, na katere se je projektni tim pripravil in tistih, do katerih je v resnici prišlo, poleg tega se izpostavijo ukrepi, s katerimi se je projektni tim izognil večjim tveganjem v času izvedbe projekta. V poročilu ne smejo izostati niti tveganja, katerih tim pri planiranju projekta ni predvidel, ter tistih, katerih ukrepi za omilitev oz. izogib so se izkazali za neustrezne. Na podlagi teh informacij se izdela in dopolnjuje “baza tveganj”, ki se koristi pri obvladovanju tveganj bodočih projektov.

Management projektnih tveganj – identifikacija in vrednotenje

»Murphy obišče vsak projekt!« sem prebral v neki knjigi. Še tako idealen plan žal ne more preprečiti vseh nezaželenih dogodkov, ki v času izvedbe projekta lahko povzročijo vsaj nekaj nepredvidenega dodatnega dela, lahko pa tudi večje zamude in stroške. Da zadovoljijo različne interese udeležencev projekta, so cilji projektov zelo kompleksni, kar zahteva veliko število aktivnosti, v katere je vključenih večje število ljudi z različnimi veščinami, odgovornostmi in pristojnostmi. Iz kompleksnosti izhaja veliko priložnosti, da aktivnosti ne bi potekale, kot je bilo načrtovano.

Večino avtorjev deli tveganja na poslovna (investiranje v napačen projekt), tehnična (nezmožnost uresničitve ciljev) in operativna (neustrezno sodelovanje naročnika s projektnim timom). Pri tem velja, da se s poslovnimi tveganji ukvarja naročnik projekta (vplivajo pa na uspeh projekta), s tehničnimi in operativnimi (ki vplivajo na učinkovito izvedbo) pa projektni tim. Pri tem slednja dva tipa skupaj običajno poimenujejo tudi »projektna tveganja«, ki lahko izhajajo iz okolja projekta ali pa neposredno iz projekta (slika).

Vrste, viri in dejavniki projektnih tveganj

Projektna tveganja*

Tipični koraki procesa managementa tveganj so:

  • identifikacija in vrednotenje tveganj,
  • planiranje ukrepov za znižanje tveganosti,
  • kontroliranje tveganj in ukrepanje.

Proces identifikacije tveganj obsega razpravo o potencialnih tveganjih in izdelavo seznama tveganj. Osnova za identifikacijo tveganj je seznam in opis aktivnosti projekta (WBS), vhodne informacije pa so tudi obseg in specifikacije proizvodov, informacije o okolju združbe ter pričakovane koristi. Da bi lahko identificirali tveganja in kasneje poiskali ustrezne ukrepe z njihovo zmanjšanje, je potrebno za posamezne aktivnostih poiskati razloge za pojave, ki lahko negativno vplivajo na uspeh projekta:

  • zakaj bi izvedba aktivnosti in projekta lahko zamujale in/ali zakaj bi bili končni stroški večji od planiranih?
  • kje bi bil lahko vzrok, da rezultat projekta ni v skladu z zahtevami naročnika?
  • kaj bi nas oviralo, da ne bi dosegli ustrezne kakovosti proizvoda in/ali izvedbe?
  • katera tveganja so vezana na pridobitev virov in ali jih lahko pravočasno pridobimo?

Pri tem si lahko pomagamo z izkušnjami projektnega tima in sodelavcev, v podporo nam je poznavanje strokovnih področij, opremo se tudi na intuicijo. V kolikor združba izvaja sistematične analize končnih poročil zaključenih projektov, so nam v veliko pomoč tudi zabeleženi podatki o tveganjih preteklih projektov.

Z vidika vpliva na projekt so tveganja lahko zelo različna – nekateri dogodki povzročijo le nekajurno “reševalno” akcijo, drugi pa kar večmesečno zamudo. Slednji seveda zahtevajo večjo pozornost, poskušamo jih preprečiti ali vsaj zmanjšati verjetnost uresničitve. Zato z ocenjevanjem poskušamo oceniti velikost tveganj, nakar le za petino (po Paretovem načelu) kasneje poiščemo tudi ukrepe za zmanjšanje tveganosti. Tveganja se ovrednotijo tako, da se ocenita verjetnost uresničitve ter obsežnost posledic uresničitve. Zmnožek obeh dejavnikov pa nam prikaže velikost tveganja.

Velikost tveganja = verjetnost * posledice

Različni avtorji predlagajo različne enote ocenjevanja:

  • oba faktorja od 1 do 3 (Burke, 2003)
  • posledice od 1 do 3, verjetnost od 1 do 5 (Gibbs) oz. od 1 do 9 (Young, 2000)
  • verjetnost v %, posledice od 1 do 100 (Newell, 2002)
  • verjetnost v %, posledice v mesecih zamude ali v denarnih enotah (Chapman & Ward, 1997)

Ocena posledic v denarju nam omogoči lažjo primerjavo posledic in stroškov morebitnih ukrepov za zmanjšanje ali odpravo tveganja, saj se za ukrep ne odločimo, kadar je dražji od velikosti tveganja. Druga prednost ocenjevanja posledic v denarju je tudi možnost večjega razpona med najnižjimi in najvišjimi stroški uresničitve tveganj, v primerjavi z razponom 1 – 3.

Planiranje stroškov projekta

O ocenjevanju stroškov projekta sem pisal že v sklopu snovanja projekta, natančneje pri izdelavi študije izvedljivosti. Takrat sem navedel, da se stroški ocenijo po načelu (metodi) »top-down«. V fazi planiranja pa se po načelu »od spodaj navzgor« (bottom-up) čim bolj natančno predvidijo stroški vseh virov, ki jih bomo potrebovali za izvedbo projekta. Stroka ta pristop imenuje »inženirski«, poleg omenjenih dveh metod pa omenja še tretjo – analogno, kjer se stroški ocenijo na podlagi normativov za določeno enoto – meter (npr. 1 m izgradnje kanalizacije = 1725 €), m2 (asfalta) ali m3 (betona).

Razlike med metodami po Kerznerju (2009)

Ocenjevalni model Generičen tip Povezava z WBS Natančnost Čas priprave
Parametrično ROM Top down -25% – +75% Dnevi
Analogno Proračun Top down -10% – +25% Tedni
Inženirsko Definitivno Bottom up -5% – +10% Meseci

(ROM – groba ocena po velikost stroškov, angl. rough order of magnitude)

Normativi so seveda plod izkušenj oz. statističnih analiz dejanskih stroškov preteklih projektov. Predvsem bolj projektno usmerjene združbe imajo v ta namen zaposlene analitike projektov, ki pomagajo projektnim timom čim bolj realno oceniti stroške. Obstaja celo svetovno združenje teh strokovnjakov, imenovanih »stroškovni inženirji« (ICEC). Sicer pa so ocene plod izkušenj članov tima in drugih strokovnjakov iz združbe ali izven nje. Osnove dobrega ocenjevanja pa so tudi izdelani referenčni modeli projektov, razpoložljivi ažurirani podatki o cenah opreme in materialov, ter baza internih stroškov ljudi (plačilni razredi po delovnih mestih).

Vhodni podatki za ocenjevanje stroškov so seznam aktivnosti (WBS), potrebe po virih ter stroški teh virov. Stroški so lahko variabilni, preko ur dela vezani na trajanje aktivnosti (običajno se upoštevajo kot strošek dela na uro) ali fiksni (nespremenljiv strošek vira na eni aktivnosti – pogodbeni znesek, material, ipd.). Novejša računalniško podprta orodja omogočajo neposredno planiranje stroškov v kombinaciji s terminskim planom, lahko pa se izdela kar tabela vrst stroškov po aktivnostih (slika).

Enostavna matrika stroškov projekta

Plan / matrika stroškov projekta*

Ko združimo terminski plan in stroške virov, dobimo vhodne podatke za izdelavo plana financiranja – potrebe po višini finančnih sredstev v posameznih obdobjih projekta. Na podlagi predvidenih izdatkov se tako izdela plan financiranja. Običajno pa to ni naloga projektnega tima, ampak skrbnika projekta ali managerja portfelja projektov, čeprav obstaja kar nekaj izjem (iskanje pokroviteljev za izvedbo prireditve, projekti v društvih, ali pa projekti, financirani s strani države ali EU). V omenjenih projektih pa morajo člani tima sami poskrbeti za pridobitev finančnih sredstev.

Ocena stroškov po inženirski metodi se lahko zelo razlikuje od prvotne ocene naročnika. Če predpostavimo, da je projektni tim pripravil realen plan stroškov, prvotni predračun pa je nižji od končne ocene, potem ostaneta le dve alternativi – projekt se ne izvede ali pa se poveča proračun projekta. Slednje se izvede, v kolikor popravljeni finančni kazalniki projekta (donosnost, doba vračanja) še vedno zadovoljijo naročnika. Zato on tudi sprejme to odločitev. Malce drugače je seveda pri pripravi ponudb, a o tem kdaj drugič.

Kadrovanje članov tima

Manager projekta in člani ožjega tima se običajno določijo pred začetkom priprave projekta, saj je njihova prva naloga izdelava plana projekta. Ko splanirajo aktivnosti in ocenijo potrebe po izvajalcih (usposobljenost, ure dela), v sodelovanju z linijskimi managerju izberejo tudi ostale izvajalce (člane širšega tima).

V določenih primerih pa se izvajalci ne določijo v fazi priprave projekta, ampak šele kasneje. Se pa določi delovno mesto z predvidenimi urami dela, da se preverijo zmožnosti glede razpoložljivosti izvajalcev ter ocenijo stroški izvedbe projekta. Lahko rečemo, da obstajajo trije termini kadrovanja:

  • takojšnje izbira / določitev konkretnih izvajalcev se običajno izvede v primeru RR in internih projektov sprememb delovanja (IT, reorganizacija);
  • določitev po pridobljenem poslu (projekti za zunanjega naročnika) – v prvi fazi priprave projekta (priprava ponudbe) se planirajo le potrebni kadri, konkretna imena pa se določijo šele takrat, ko naročnik potrdi ponudbo;
  • kadrovanje tik pred izvedbo aktivnosti – projekti, kjer v določenem času potrebujemo več enako usposobljenih izvajalcev; primer: za montažo linije v osmem mesecu projekta potrebujemo 5 monterjev, katere njihov vodja določi šele pred montažo.

Preverjanje obremenitve ljudi

Izravnava (leveling) virov*

V redkih primerih (visoka prioriteta projekta) manager projekta lahko zahteva konkretne ljudi,  običajno pa jih določi linijski manager, ki bolje pozna zmožnosti svojih ljudi (strokovnost, hitrost dela, kreativnost, natančnost…). Manager projekta linijskim managerjem predstavi potrebe po kadrih, oni pa potem določijo ustrezne ljudi. Pri tem izhajajo iz strokovne zahtevnosti aktivnosti ter sposobnosti in razpoložljivosti svojih ljudi, ki sicer lahko že delajo na drugih projektih (slika!) in imajo tudi redne zadolžitve sklopu svojega oddelka.

Ko govorimo o razpoložljivosti in obremenitvah ljudi, moramo omeniti tudi izravnavanje obremenitve (angl. leveling), ki se najprej izvede na nivoju projekta, ki ga planiramo, nato pa lahko tudi na nivoju vseh projektov v združbi. Najprej poiščemo morebitne planirane preobremenitve posameznikov – ali smo za koga katerikoli dan planirali več kot 8 ur dela (na dveh ali več vzporednih aktivnostih), ki jih nato rešujemo z zamikanjem nekritičnih aktivnosti, premeščanjem ali dodajanjem ljudi, ipd. Postopek nato ponovimo na celotnem naboru projektov (slika – »gantogram« nalog posameznika). Če projekta z razpoložljivimi kadri ne moremo izvesti do želenega roka, se to rešuje z najetimi zunanjimi izvajalci ali pa se zamakne končni rok. Lahko pa se podaljša kateri od že izvajanih projektov z nižjo prioriteto.

Računalniško podprta orodja so planiranje ljudi dokaj poenostavila, vendar moramo paziti, da ne »podležemo« funkcionalnosti teh orodij. Prva stvar je natančnost ocenjevanja obremenitev – če se pogajamo o 9% preobremenitvi in poskušamo izravnavati obremenitve, ki imajo manj kot 20% presežka, lahko porabimo več časa za usklajevanje, kot nam to prinese koristi. Sploh, ko se določene aktivnosti na enem od projektov zamaknejo zaradi problemov in zamud… Druga funkcija, ki je »navidezno uporabna« pa je samodejno izravnavanje obremenitev. Če je delno uporabna na enem projektu (preverjanje različnih alternativ izvedbe), nam lahko v multiprojektnem okolju povzroči veliko zmedo in nejevoljo ljudi!

Planiranje virov projekta

Terminski plan po razporeditvi in oceni trajanja aktivnosti še ni dokončen. Razloga sta dva – prvi je omejenost virov, drugi pa »predvidevanje problemov«. Slednje se seveda nanaša na ukrepe v pričakovanju morebitnih težav pri izvedi, zaradi česar kakšno aktivnost prestavimo na zgodnejši termin, v plan dodamo “kontrolne” aktivnosti ali nekatere aktivnosti za vsak slučaj podaljšamo. O tem bom več pisal v sklopu managementa tveganj, danes pa bom opisal planiranje virov.

Čeprav sem v enem od zgodnejših prispevkov napisal, da viri niso omejitev projekta, ampak je omejitev denar (če imamo denar, nimamo pa zadosti ustreznih ljudi, jih pač najamemo), največkrat najprej preverimo, ali smo v predvidenem času zmožni projekt izvesti z lastnimi ljudmi. Trajanje projekta se zato lahko spreminja z dodajanjem (ali odvzemanjem) izvajalcev posameznih aktivnosti.

V zvezi s tem avtorji omenjajo dva pristopa. Pri prvem imamo omejeno število ljudi in temu priredimo razpored in trajanje aktivnosti (določene aktivnosti, ki bi sicer lahko tekle vzporedno, moramo izvesti zaporedno, ker jih izvaja isti človek). Ta pristop se npr. uporablja za interne projekte izboljšav poslovanja. Drugi pristop ima fiksiran končni rok (npr. datum prireditve), zagotoviti pa si moramo zadostno število izvajalcev (v združbi ali izven nje), da ta rok (čim ceneje) dosežemo.

Plan virov v gantogramu

Plan virov projekta*

Pri tem naj povem, da najetje zunanjih izvajalcev (posameznikov, podjetij) ni vedno dražje od lastnih kadrov, saj ljudje pozabljajo na to, da bi zaposleni, ki mora izvesti aktivnost na projektu, v tem času lahko delal kaj drugega (npr. tržil produkte). Tržnik npr. tedensko ustvari 800€ dobička, strošek njegovega dela pa je 500€. Čeprav bi nas najetje zunanjega izvajalca za izvajanje aktivnosti na projektu stalo 1.000€, bi se nam to še vedno splačalo, saj bi imeli 300€ plusa (če bi tržnik delal na projektu, ne bi ustvaril običajnega dobička!). Dodatne prednosti zunanjih izvajalcev pa sta lahko tudi v kakovost in hitrost izvedbe.

Čeprav večina avtorjev tujih knjig piše le o planiranju ljudi, moramo poudariti, da obstajajo tudi drugi viri za izvedbo projekta. Ljudje brez opreme, materiala in energije seveda ne morejo narediti nič, vir pa je tudi denar, ki ga potrebujemo za plačevanje ostalih virov. Da bi lahko dokaj natančno ocenili stroške projekta, lahko uporabimo WBS in za vsako aktivnosti opredelimo potrebne vire (pri čemer moramo za izvajalce predvideti znanja in veščine). Vendar pa moramo tudi predvideti, kdaj bomo potrebovali kakšne vire, zato jih planiramo kar v gantogram (slika). Ne samo ljudi, tudi opremo je velikokrat treba rezervirati vnaprej, potrebno je vedeti, kdaj kupiti določen material, in seveda, kdaj potrebujemo določena denarna sredstva za nabavo opreme oz. plačilo podizvajalca.

Na sliki so prikazani potrebni viri za izvedbo posamezne aktivnosti, opazite pa lahko tudi odstotke pri nekaj izvajalcih. S tem v zvezi moram opozoriti, da moramo razlikovati med trajanjem aktivnosti (angl. duration) in potrebnim delom. Tega je lahko več (več ljudi) ali manj (manjša obremenitev človeka). Obremenitev – število ur dela posameznika na eni aktivnosti – planiramo iz dveh razlogov, da bi ljudi ne preobremenili oz. da poznamo njihovo obremenitev na enem ali vseh projektih, ter da bo ocena stroškov dela realna. Odstotki, ki so navedeni na sliki, pomenijo koliko % od celotnega trajanja aktivnosti bo navedeni izvajalec delal v času izvedbe aktivnosti. Primer: trajanje Akt3 = 15 dni, kar naj bi bilo 120 delovnih ur (toliko bo delala Barbara); Vinko pa bo v tem času projektu posvetil polovico svojega delovnega časa oz. 60 ur.

Sledi ugotavljanje in izravnavanje obremenitve posameznikov (angl. leveling) – najprej na enem projektu (seštevek ur na vzporednih aktivnostih), potem pa še na drugih projektih (multiprojektno okolje). O tem pa naslednjič…

Terminski plan projekta – gantogram

Kdor ne ve, kaj je gantogram, nas bo težko prepričal, da je kdaj (resno) vodil projekt! Eno najpomembnejših orodij, tako rekoč osnovno delovno sredstvo managerja projekta, ki služi časovnemu planiranju in kontroliranju izvedbe, se v originalu imenuje »Gantt chart«, po Ganttu, ki naj bi ga »izumil« že davnega leta 1917. Gantogram grafično prikazuje časovni razpored in trajanje izvedbe posameznih aktivnosti, ki so nanizane ena pod drugo. Za vsako aktivnost se tako hitro in jasno razbere, kdaj naj bi se začela in kdaj zaključila.

S tem, ko so prikazani konkretni datumi začetkov in koncev aktivnosti, so prikazani tudi dnevi, ko naj bi izvajalci aktivnosti posvetili svoj čas projektu. V gantogramu so lepo vidni zaključeni sklopi / faze projekta z mejniki (zaključki faz), pa tudi časovne rezerve nekritičnih aktivnosti, ki se lahko izkoristijo za uravnavanje obremenitev ljudi (o tem več naslednjič). Čeprav je imel gantogram prvotno eno veliko slabost v primerjavi s kasneje razvitim mrežnim planiranjem – ni vključeval povezav med aktivnostmi, so sodobna računalniška orodja to omogočila, zaradi česar se klasično mrežno planiranje vse bolj opušča.

Primer gantograma s prikazano kritično potjo

Gantogram - terminski plan projekta* Mimogrede, ko sem preverjal, kako »domača« je beseda »gantogram«, mi je »stric Google« ponudil kar 90.700 slik s primeri gantogramov. Preverite še sami…

Verzuh (2008) o gantogramu pravi: »Slika pove več kot 1000 besed!«, Pinto (2009) pa izpostavlja naslednje prednosti: je nazoren in razumljiv, zelo enostavno poveže mrežni plan in naročnikove želene roke, uporaben je za kontrolo in enostaven za posodabljanje, služi pa tudi ugotavljanju potreb po virih. Omogoča tudi hiter in enostaven izračun oziroma preverjanje več možnih scenarijev izvedbe oziroma simulacij ukrepov in posledic v procesu managementa tveganj. S pomočjo gantograma usklajujemo aktivnosti članov tima z aktivnostmi, ki jih mora v sklopu projekta izvesti naročnik, ter s tistimi, ki jih bomo zaupali pogodbenim izvajalcem.

Če sem pri mrežnem planiranju navedel, da je možno projekt skrajšati s krajšanjem kritičnih aktivnosti, nam gantogram omogoča tudi krajšanje s prekrivanjem aktivnosti. Če je potrebno »pohitriti« izvedbo (tudi že v fazi planiranja, velikokrat pa pri reševanju zamud v fazi izvedbe), lahko npr. aktivnost, ki naj bi se sicer začela takoj po zaključku predhodne, začnemo izvajati nekaj časa prej in tako obe povezani aktivnosti krajši čas potekata vzporedno. Seveda se aktivnosti in s tem projekt krajšajo tudi tako, da na neko aktivnost razporedimo več ljudi (čeprav trajanja ne moremo kar deliti s številom ljudi, kot to meni Dilbertov šef) ali pa aktivnost zaupamo pogodbenim izvajalcem.

Pri mrežnem planiranju sem napisal le, da aktivnostim pripišemo predvideno trajanje. Čeprav je zelo enostavno napisati številko (dneve ali tedne trajanja), je to ena najbolj kritičnih aktivnosti planiranja projekta. Avtorji poudarjajo, da se trajanje aktivnosti oceni na podlagi izkušenj planerjev (managerja, ožjega tima, predvidenih izvajalcev). K realnejši oceni pomagajo plani in poročila o izvedbi podobnih predhodnih projektov, plani tipskih projektov, sodelujejo lahko sodelavci iz projektne pisarne (s statističnimi »normativi«, ugotovljenimi z analizami zaključenih projektov). Pomagamo si tudi s ponudbami podizvajalcev, ali z izkušnjami s podobnih projektov v drugih združbah (sošolci,  znanci, strokovna združenja). Kerzner (2009) pa predlaga, da naj trajanje ocenijo kar linijski managerji, ki naj bi imeli najbolj bogate izkušnje.

Mrežno planiranje in kritična pot – CPM

Aktivnosti, ki jih je potrebno izvesti, da bi dosegli cilje projekta, bi načeloma lahko izvajali eno za drugo, kot smo jih zapisali v WBS, vendar pa bi bilo to zelo neracionalno, saj je možno določene aktivnosti izvajati vzporedno, s čimer se projekt lahko veliko hitreje izvede. Pristopu, s katerim zagotavljamo racionalno izvedbo za vidika časa, rečemo mrežno planiranje. Moram povedati, da projektni managerji s pojavom modernih računalniških orodij, s katerimi pripravljamo terminske plane (gantograme, ki jih bom predstavil naslednjič), mrežnih planov skoraj ne uporabljamo več, a filozofijo planiranja projekta je nekako najlažje obrazložiti prav z mrežnim planiranjem.

Obstajata dva grafična prikaza mrežnega plana. Pri enem uporabljamo »puščice in krogce«, pri drugem z linijami povezujemo pravokotnike (primer na sliki). Pri prvem, imenovanem puščični (angl. arrow diagram, poznan tudi kot TOA, task-on-the-narrow), s puščicami prikažemo aktivnosti, krogci pa označujejo »dogodke« – začetke in konce aktivnosti oz. povezavo več aktivnosti (kadar mora biti zaključenih več aktivnosti, da začnemo z naslednjo ali z več naslednjimi). Pri drugem, »aktivnostnem« mrežnem diagramu (Lock ga imenuje precedence logic diagram, Kerzner precedence network, Wysocki pa govori o PDM metodi – precedence diagramic method), pa pravokotniki predstavljajo aktivnosti, linije med njimi pa povezavo. Pri tem linije vedno tečejo iz desne stranice pravokotnika predhodne aktivnosti v levo stranico naslednje aktivnosti.

Primer enostavnega mrežnega plana s prikazano kritično potjo

CPM mrežni plan*

Glavna slabost puščičnega plana je, da moramo uporabljati »navidezne aktivnosti«, pri aktivnostnem pa je lahko nejasna »večstranska« povezava več aktivnosti. V oba tipa diagramov lahko vnašamo tudi različne (najzgodnejše ali najkasnejše) začetke in konce aktivnosti, s katerim prikažemo časovno rezervo »plavajočih« aktivnosti, ipd. Da ne grem preveč v podrobnosti – podrobneje bom metodi obrazložil v knjigi.

Kot sem že omenil, vhod v mrežno planiranje je WBS. Postopek izdelave pa gre nekako takole: vnesemo prvo aktivnost, pri naslednji pa se vprašamo: »Ali mora biti prva aktivnost zaključena, da lahko začnemo izvajati to, ki jo želimo vrisati?« Če je odgovor NE, potem jo narišemo vzporedno, če pa je DA, jo narišemo za njo (desno) in ju povežemo. Pogoj za zaporednost je običajno »tehnološki« (npr. dovoljenja za gradnjo ne moremo zaprositi, če nimamo izdelanih načrtov). Z morebitnim pomanjkanjem kadrov, zaradi katerih dveh aktivnosti ne bi mogli izvajati vzporedno, se tu še ne ukvarjamo. Podobno nadaljujemo z vsemi ostalimi aktivnostmi do konca seznama, pri čemer se pri vsaki vprašamo “Katera aktivnost mora biti nujno zaključena, da začnemo s to, ki jo vnašamo v plan…?” Pa še to: pri risanju mrežnega plana ni pomembno, kako so aktivnosti strukturirane v WBS.

Ko zaključimo z risanjem, vsaki aktivnosti pripišemo predvideno trajanje (slika: 6w = šest tednov) in poiščemo kritično pot. To so tiste medsebojno povezane aktivnosti, katerih seštevek trajanj je najdaljši (slika: rdeče aktivnosti). Njihov seštevek je tudi pričakovano trajanje projekta – prej kot v tem času projekta ne bo možno izvesti. Govorimo o metodi kritične poti (CPM, critical path method). Kritične aktivnosti moramo poznati, da vemo, katere aktivnosti krajšati, da bi skrajšali projekt, ter da damo večji poudarek tveganjem na kritični poti. Poleg tega pa je v fazi izvedbe pomembno vedeti, da zamujanje kritične aktivnosti pomeni neposredno tudi zamujanje projekta.

Za konec pa še nekaj: kadar izvajamo veliko podobnih projektov, s skoraj identičnimi aktivnostmi, potem nima smisla tratiti časa s pripravo WBS-a in mrežnega plana, ampak raje uporabimo terminski plan enega od predhodnih projektov. Z nekaj dopolnitvami in prilagoditvami nato dokaj hitro pripravimo zelo kakovosten plan novega projekta.

Členitev projekta in izdelava seznama aktivnosti – WBS

Kratica WBS v originalu pomeni work breakdown structure, kar Hauc prevaja kot »retrogradna členitev projekta«, Rozman »struktura projekta«, Semolič »strukturirana členitev projekta«, Nemec Pečjak pa kot »strukturirana členitev dela«. Ker govorimo o planiranju aktivnosti, mi je zadnji prevod še nekako najbližji. Mogoče pa bi metodo lahko poslovenili kot »členitev projekta«, rezultat pa poimenovali »struktura del«? Cilj oziroma bistvo členitve pa je, da se izdela seznam vseh aktivnosti, s katerimi bomo učinkovito izvedli projekt.

Členitev projekta in izdelava seznama aktivnosti je načeloma prvi korak (podrobnega) planiranja projekta, čeprav je res, da se okvirni plan z mejniki izdela že v fazi snovanja. Nekateri avtorji pa tudi predlagajo, naj tim pred podrobnim planom aktivnosti skupaj z naročnikom najprej doreče okvirni način (taktiko) izvedbe (nekaj o tem sem napisal v zadnjem odstavku). Vseeno pa, tudi če taktika ni posebej (pisno) opredeljena, se tim o njej pogovarja, ko členi projekt. Vhodni podatki za pripravo strukture del so obseg in specifikacije proizvodov projekta, včasih pa si timi pomagajo tudi z zahtevanimi mejniki projekta, ki delno nakazujejo tudi že taktiko izvedbe, kot jo vidi naročnik.

Primer Strukture del projekta

WBS členitev projekta*

Običajna, grafična oblika »WBS diagrama« je podobna organigramu (primer na sliki), možno pa je delo členiti samo tekstovno, v enem stolpcu, s pomočjo zamikov alinej (kot je to prikazano v orodjih za planiranje projektov). Za večjo preglednost se posameznim nivojem pripišejo ustrezne številke (2. Razvoj, 2.2 SW, 2.2.3 Splet, 2.2.2.1 Radio, ipd.)

Različni avtorji navajajo dva izhodišča členitve projekta. Največkrat je osnova za členitev kar obseg projekta, skupaj z specifikacijami, kot je to prikazano na sliki (PBS = product breakdown structure). Lahko bi mu rekli »vsebinski način členitve«. Našel pa sem tudi členitve, kjer so za izhodišče vzete tipične zaporedne faze izvedbe projekta, ki so povezane z mejniki projekta (npr. načrtovanje, gradnja, opremljanje). Ta pristop bi lahko poimenovali »fazni način«. V praksi pa sem naletel tudi na kombinacijo obeh, a več o tem bom napisal v knjigi.

Izdelava kakovostne členitve dela je zelo pomembna, saj je WBS osnovna vhodna informacija za vse ostale plane projekta –  za mrežni in terminski plan, plan virov in stroškov, ter plan obvladovanja tveganj! Poleg tega je tudi osnova za porazdelitev del med naročnikom, izvajalci in podizvajalci, oziroma med partnerji, ki bodo izvedli projekt.

Prav zaradi slednjega nekateri avtorji predlagajo, da tim pred členitvijo projekta najprej opredeli »taktiko izvedbe«, pri čemer je z vidika členitve projekta potrebno razmisliti, katere dele projekta se bo zaupalo zunanjim izvajalcem oziroma, ali se bodo določene stvari (npr. sestavni deli) kar kupile pri dobaviteljih. Če bo namreč del projekta izvedel pogodbeni izvajalec, nam ni potrebno podrobno členiti njegovega dela, ampak v seznam aktivnosti vključimo aktivnosti od iskanja primernih izvajalcev do podpisa pogodbe.

Priprava (zagon) projekta – planiranje in organiziranje

S potrjenim (internim) »Naročilom projekta«, kot smo na zadnjem debatnem večeru poslovenili »project charter«, projekt preide v drugo fazo – začne se priprava projekta. V omejenem času (rok je običajno tudi naveden v Naročilu) naj bi ožji projektni tim (manager projekta in nosilci posameznih strokovnih področij) izdelal podroben plan izvedbe projekta in organiziral vse deležnike projekta tako, da bi delo potekalo brez nesporazumov, napak, ipd.

Zanimivo, da tuji avtorji večinoma pišejo le o planiranju projekta, organiziranja pa ne obravnavajo kot procesa, ampak večinoma le navedejo možne organizacijske strukture, njihove značilnosti, prednosti in slabosti. Nekateri delno govorijo o organiziranju v sklopu planiranja. Newel (2002) proces poimenuje »organizacijsko planiranje« (organisational planning), kar bi lepše poimenovali »planiranje organizacije«. Meredith in Mantel (2009) na WBS takoj vežeta RAC matriko (pristojnosti / odgovornosti), Burke (2008) omenja plan komunikacij, Kleim in Ludin (1998) pa navajata »project manual«, kot pravilnik delovanja tima.

Kot sem zapisal že v enem od zgodnejših prispevkov, se je kake tri desetletja nazaj pojavil »project start-up«, ki naj bi načeloma združeval vse aktivnosti med snovanjem in izvedbo projekta, torej proces planiranja in organiziranja. Zasledil sem ga pri več avtorjih (Lock, 2009; PRINCE2, Turner in Simister, 2000; Young, 2000), ki pa »start-up« opredeljujejo dokaj različno. Hauc je fazo poimenoval zagon, sam pa sem nekako bolj naklonjen izrazu »Priprava projekta«.

Priprava projekta – proces in dokumenti

Priprava (zagon) projekta - planiranje, organiziranje*

O planiranju in organiziranju sem tudi že pisal, a na kratko lahko opredelitve ponovimo. Poenostavljeno povedano se s planiranjem je opredeli “kaj, kdaj in kdo” bo kaj naredil na projektu, s čim (oprema) ter koliko bo to stalo. Večina avtorjev vključuje tudi plan obvladovanja tveganj, plan financiranja, itd. (glej sliko). Pri opredelitvi organiziranja bi najlažje povzel Newel-a (2002) – določitev vlog, pristojnosti in odgovornosti deležnikov projekta ter opredelitev načina poročanja na projektu. Ne smemo pa pozabiti na komuniciranje, prenos informacij in management dokumentacije projekta, kar bi prav tako lahko vključili v organiziranje projekta. Vse dokumente, ki nastanejo v fazi priprave projekta, lahko združimo v enega, ki ga združbe v Sloveniji največkrat poimenujejo elaborat projekta.

 

Pa še tale misel… Ko razmišljam o tem, kako podrobno pripraviti projekt, se vedno spomnim na trditev, ki sem jo zasledil pred leti v eni knjigi (žal sem pozabil avtorja). Zapisano je bilo nekako takole: »Vrhunski projektni manager (lahko) igra cele dneve golf!« To nekako pomeni, da lahko v primeru idealnega plana manager projekta enkrat tedensko pride samo preverit, če zadeve tečejo po planu. In seveda tečejo, ker je med pripravo projekta s svojim timom izdelal realen plan, jasno razdelil vloge in opredelil razmerja med deležniki, predvidel morebitne zaplete in jih uspel preprečiti… No, to je v današnjem spreminjajočem se času bolj »pravljica«, kot resničnost, kar še ne pomeni, da se dobri managerji ne trudijo čim bolj približati »idealnemu«. In kot pravi stari slovenski pregovor – dobra priprava je pol narejenega!

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!

Page 6 of 9

Powered by WordPress & Theme by Anders Norén