Category: Pojmovnik Page 1 of 2

PMIS sem omenil že v prispevku »Plan obvladovanja informacij in dokumentacije projekta«, kjer sem izpostavil pomembnost omenjenega področja ter predlagal plan komuniciranja za primere enkratnih projektov, na katerem prvič dodeluje več različnih združb. Nasprotno pa v se združbah, kjer izvajajo veliko projektov, v fazi priprave projekta ne ukvarjajo s komunikacijami in dokumentacijo če imajo vpeljan poseben »projektni« informacijski sistem za podporo projektnemu delu.

Projektni informacijski sistem (PMIS, angl. project management information system) je po mnenju strokovnjakov zbir (običajno računalniško podprtih) orodij, ki podpirajo planiranje aktivnosti in virov ter zbiranje in prenos informacij (Heldman, 2005; Brandon, 2006). Je tudi sistem za sledenje napredovanja (www.maxwideman.com) in kontroliranja projekta ter zagotavlja učinkovito komuniciranje (Verma, 1995).

Projektni informacijski sistem je lahko sestavljen iz več delov, katere lahko delimo glede na tipe dokumentov (vsebinsko) ali glede na orodja, ki se uporabljajo (baze, dokumenti, gantogrami, e-pošta). Načeloma so meje med temi deli le teoretične, so pa smiselne, zaradi večje preglednosti dokumentacije. Nekateri so lahko tudi združeni, struktura pa je odvisna od programske opreme, ki jo uporabljamo. Nekaj tipičnih vsebinskih področij sem prikazal na sliki.

Vsebinska področja PMIS

Kar se tiče komuniciranja, informiranja in prenosa dokumentov, obstajata dve možnosti:

informacije se prenašajo preko e-pošte in vsak si gradi svojo »informacijsko bazo« ali arhiv – urejenost je seveda odvisna od posameznika;
informacije in dokumenti se hranijo na centralnem mestu (portal projekta) in deležniki poiščejo ustrezno informacijo, ko jo potrebujejo (ne pošiljamo zapisnikov po e-pošti, ampak so objavljeni na portalu).

Druga izvedba je vsekakor boljša, zahteva pa sistematičnega skrbnika PMIS in ustrezno urejenost vseh dokumentov, da jih uporabnik hitro najde (1 minuta!). Tak informacijski portal omogoča tudi razne preglednice za boljše informiranje deležnikov v stilu »kaj je novega«, ki si jih vsak lahko ogleda vsako jutro pred začetkom dela. Primeri: spremembe zahtev, korektivne akcije (krajše naloge na podlagi sklepov kontrolnih sestankov), odkrite napake in težave (za odpravo), druge novosti.

In kakšno programsko orodje lahko uporabimo za PMIS? Menim, da je večina od vas že slišala za MsProject, kot najbolj razširjeno orodje za podporo managementu projektov. Moram opozoriti, da to ni PMIS, ampak le orodje za planiranje in kontroliranje časa, virov in stroškov projekta. Šele povezava z drugimi orodji omogoča tudi obvladovanje dokumentacije. Žal pa zadeva kljub kakovosti ni tako poceni, zato so se mnogi uporabniki začeli ozirati po brezplačnih, odprtokodnih rešitvah.

Kolega Marko Nemec Pečjak si je zadnjo zimo večere krajšal z analizo funkcij PMIS, ki jih je našel na spletu. Za 101 program je preveril, če omogočajo klasično planiranje časa in virov, pa tudi ali omogočajo skupinsko delo, sledenje problemov, management dokumentacije in management portfelja projektov. Poleg tega je preveril, če obstaja spletna verzija, pa seveda, ali je paket brezplačen. Slednjih je našel kar 24, od tega jih 12 omogoča obvladovanje časa in virov, pet »brezplačnikov« pa ima vse zgoraj navedene funkcije: Daptiv PSA Solution, Endeavour Sw Project Mgm, Openpoint Project, Project.net in Project-Open. Sicer pa rezultate analize lahko ogledate na njegovi prezentaciji z letošnjih DSI.

Terminski plan projekta – gantogram

By Aljaž

On February 15, 2011

In Management, Pojmovnik, Priprava projekta

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

* 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

By Aljaž

On February 11, 2011

In Management, Pojmovnik, Priprava projekta

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

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

By Aljaž

On February 10, 2011

In Pojmovnik, Priprava projekta

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

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

By Aljaž

On February 5, 2011

In Management, Pojmovnik, Priprava projekta

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

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!

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

By Aljaž

On January 29, 2011

In Pojmovnik, Snovanje projekta

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

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

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

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

Primer: Listina oz. odločba za pripravo projekta

Vir: Wysocki, 2009

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

Sicer pa avtorji najpogosteje navajajo naslednjo vsebino dokumenta:

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

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

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

Obseg, zahteve, specifikacije, konfiguracija proizvodov

By Aljaž

On January 26, 2011

In Pojmovnik, Snovanje projekta

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

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

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

Priprava specifikacij – proces in primer

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

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

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

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

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

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

By Aljaž

On January 22, 2011

In Pojmovnik, Snovanje projekta

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)

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

By Aljaž

On January 18, 2011

In Pojmovnik, Snovanje projekta

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?

Snovanje projekta

By Aljaž

On January 14, 2011

In O projektih, Pojmovnik, 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

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.

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)

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…

Blog, debatni večeri, raziskave, knjiga…

Category: Pojmovnik Page 1 of 2

Projektni informacijski sistem (PMIS)

Vsebinska področja PMIS

Terminski plan projekta – gantogram

Primer gantograma s prikazano kritično potjo

Mrežno planiranje in kritična pot – CPM

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

Členitev projekta in izdelava seznama aktivnosti – WBS

Primer Strukture del projekta

Priprava (zagon) projekta – planiranje in organiziranje

Priprava projekta – proces in dokumenti

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

Primer: Listina oz. odločba za pripravo projekta

Obseg, zahteve, specifikacije, konfiguracija proizvodov

Priprava specifikacij – proces in primer

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

Študija izvedljivosti

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

Primeri vsebine predlogov projektov

Snovanje projekta

Proces in vsebina snovanja projekta