Category: Pojmovnik

Ekstremni projektni management in »dinamično« planiranje

On January 7, 2011

In Agilno, Management, Pojmovnik, Priprava projekta

Tudi ekstremni projektni management naj bi imel korenine v razvoju programske opreme, kjer je poznan pod pojmom »ekstremno programiranje«. Thomsett (2002), ki je celotno knjigo posvetil tej temi, meni, da je tradicionalni projektni management zasnovan na inženirskih modelih, ki več ne delujejo v kaotičnem in negotovem 21. stoletju. Ekstremni projektni management je prilagodljiv in je zasnovan na dinamičnih zahtevah, krajših razvojnih ciklih, virtualnih timih, spremenljivi tehnologiji ter skupnem sodelovanju vseh deležnikov projekta. Odnos naročnik (uporabnik) – izvajalec (projektni tim) sloni na partnerstvu!

Wysocki (2009) navaja, da razlike v pristopih izhajajo iz stopnje (ne)poznavanja rešitve na začetku projekta, pri čemer so glavne razlike v podrobnosti planiranja (kar smo navedli že pri agilnem PM), večjo vlogo pa imata management tveganj in vključevanje naročnika. Avtor takole opredeli uporabo posameznih pristopov:

tradicionalni – rešitev in zahteve so jasno definirane, ne pričakuje se veliko sprememb obsega, projekti so rutinski in ponovljivi, uporabljajo se preizkušene šablone;
agilni – rešitev in zahteve so delno poznane, obstaja možnost dodatnih funkcij, ki jih še ne poznamo, pričakuje se veliko sprememb obsega s strani naročnika (običajno razvojni ali organizacijski projekti);
ekstremni – cilji in zahteve so nejasne, običajno so to raziskovalno razvojni projekti.

Tradicionalni, agilni in ekstremni cikel projekta

Vir: Wysocki, 2009

Če povzamemo glavne razlike posameznih pristopov, (spet) ugotovimo, kot smo že pri agilnem, da zagovorniki ekstremnega projektnega managementa zagovarjajo več partnerskega sodelovanja vseh udeležencev projekta ter več vključevanja končnih uporabnikov pri izvajanju projekta. To seveda ni nekaj ekstremnega in bi bilo smiselno upoštevati pri vseh pristopih! Bistvena razlika pa je v načinu planiranja projekta. Za ekstremno planiranje naj bi se na začetku izdelal le okvirni plan faz, podrobnejši plan aktivnosti pa se izvede ob začetku posamezne faze, pri čemer se upoštevajo trenutni rezultati, nova spoznanja ter spremembe prvotnih predvidevanj in zahtev.

»Fazni« pristop je malce drugačen od »dinamičnega« planiranja, o katerem piše več avtorjev, ki poudarjajo, da se planiranje ne zaključi z začetkom izvedbe projekta. Frame (2003) navaja, da je plan projekta dinamični instrument, ki se prilagaja glede na različne spremembe, dogodke, ugotovitve, okoliščine in odzive. Dejstvo je, da je plan projekta domnevni približek zamisli izvedbe glede na dane informacije v času planiranja.

Dober plan danes je boljši od popolnega jutri! (Conrad Brean, v Thomsett, 2002)

Še nobena bitka ni bila izbojevana v skladu s planom, vendar pa brez plana ni bila dobljena niti ena! (Dwight D. Eisenhower v Berkun, 2005)

Berkun (2005) predlaga planiranje krajših ciklov (delovnih paketov, sklopov aktivnosti), s katerimi se lažje prilagajamo spremembam. Kljub temu pa potrebujemo grobi plan celotnega projekta (z mejniki), ki nas usmerja k končnemu cilju. Kadarkoli se spremenijo cilji, zahteve ali zasnova izvedbe, predhodni plan sicer ne velja več, a ga redko popolnoma zavržemo, saj se spremembe vnesejo v plan (= agilni pristop?!). Še najbolj pa se »ekstremnemu« približa Abramovici (2000), ki predlaga, da se na začetku izdela le grobi plan projekta, podrobni plan aktivnosti pa se izdela vsake pole leta, kar imenuje »premikajoče se plansko okno« (angl. rolling schedule window). O’Neill (2003, članek), ki piše o ekstremnem PM, pa predlaga tedensko podrobno planiranje, v sklopu kontrolnih sestankov, kjer se preverja realizacija zadnjega tedna.

O proučevanju »modernejših« pristopov sta mi na koncu še vedno ostala dva dvoma – planiranje izvajalcev v več-projektnem okolju ter »polzenje« obsega projekta. Če imamo okvirni plan in stalne sodelavce (čista projektna organizacija), je možno sprotno »mikroplaniranje« in delitev nalog, ne vem pa, kako to deluje v matrični organizaciji, kjer ljudje delajo na več projektih hkrati? Druga zadeva pa je nedorečenost končnega proizvoda in sprotno dopolnjevanje zahtev. Spomnim se, kako je to bilo v praksi – nikoli ni bilo konec “ustvarjalnosti”, ne tržnikov (kot predstavnikov končnih uporabnikov), ne razvijalcev. Še huje je bilo pri IT projektih. In noben projekt ni bil zaključen do roka…

Moja izbira je čim boljši plan projekta na začetku, glede na trenutno videnje končnega proizvoda, potem pa dinamično prilagajanje z ustreznim managementom sprememb – vsaka ideja naj bi se preverila z vidika dodatnega dela in stroškov (tim) in z vidika koristi (naročnik). No, pa smo pri partnerskem odnosu…

Agilni projektni management

By Aljaž

On January 4, 2011

In Agilno, Management, Pojmovnik

Kot vsaka stroka se tudi projektni management stalno razvija, rojevajo se nove ideje, razvijajo se novejši, učinkovitejši pristopi. V knjigah in člankih se kot »modernejši« največkrat pojavlja »agilni« projektni management, zasledimo pa tudi pojme, kot so ekstremni, integracijski, nekateri avtorji pa omenjajo tudi neformalnega. Kako bi »po domače« poimenovali agilnost? Slovar tujk opredeli »agilen« kot »delaven, marljiv, prizadeven, spreten, gibčen, živahen«. Bi lahko torej govorili o bolj spretnem in prizadevnem projektnem pristopu? Neka tuja svetovalna firma poudarja, da agilni projektni management »zagotavlja zadovoljitev naročnika projekta na izjemno prilagodljiv in interaktiven način«!?! Pa poglejmo…

Wysocki (2009) v sklopu opredelitve agilnega projektnega managementa govori o različnih modelih življenjskega cikla projekta (PMLC, project management life cycle), pri čemer izpostavi dva modela:

ponavljajoč (angl. iterative) se uporablja tam, kjer je večina rešitev poznanih, malo je nedoločenega, pa še pri tem so alternative že poznane;
prilagodljiv (angl. adaptive) je uporaben za projekte, kjer je na začetku projekta manj znanega in dorečenega.

Avtor nadalje navaja, da so IT strokovnjaki razvili štiri agilne modele razvoja programske opreme (ponavljajoči: RUP, prilagodljivi: Scrum, DSDM, ASD). Več o njih si lahko preberete v njegovi knjigi, kjer je predstavljen tudi peti model APF (angl. adaptive project framework), ki naj bi bil uporaben tudi za razvoj izdelkov in prenovo procesov.

Okvirni “prilagodljivi” cikel projekta (Adaptive Project Framework)

Vir: Wysocki, 2009

Po proučevanju drugih virov sem prišel do naslednjih spoznanj:

sam pojem izhaja iz agilnih metod razvoja informacijskih sistemov (prve so se pojavile že v 80-tih letih prejšnjega stoletja) in se predvsem uporablja za IT projekte;
metode poudarjajo vzporedno izvajanje tradicionalno zaporednih faz izvedbe projekta (pristop »fontana« namesto »waterfall«) ter stalno usklajevanje udeležencev; glede na navedeno so agilne metode primerljive s sočasnim inženirstvom, ki se je prav tako pojavilo v 80-tih;
bistvo metod je sprotno prilagajanje načina izvedbe in podrobno planiranje manjših ciklov izvedbe projekta, glede na trenutno dosežene rezultate, spoznanja, ideje, ipd.;
pomembna je usmerjenost v uporabnika, zato je v projektni tim vključen tudi predstavnik uporabnikov, ki redno preverja delne rezultate projekta (s čimer se zagotovi večja ustreznost končnega proizvoda željam in zahtevam uporabnikov).

Pomembno je zavedanje, da je agilni pristop usmerjen predvsem v fazo izvedbe projekta in ne definira celotnega projektnega cikla, ki ostaja enak (snovanje, priprava, izvedba in zaključek). Agilni pristop vpliva predvsem na »natančnost« planiranja v fazi priprave projekta – vsekakor je potrebno izdelati nek grobi plan izvedbe projekta na začetku, podrobneje pa se posamezni cikli planirajo v fazi izvedbe projekta (način izvedbe, ure dela, izvajalci, ipd.).

Wysocki v svoji knjigi navaja tudi »Agilni manifest«, ki sta ga 2001 zapisala Fowler in Highsmith:

posamezniki in njihovo sodelovanje sta pomembnejša od procesov in orodij;
delo in proizvodi so pomembnejši od obsežne dokumentacije;
sodelovanje uporabnika pri izvedbi projekta je pomembnejše od predpogodbenih pogajanj;
prilagajanju spremembam je pomembnejše od sledenja plana.

Moram priznati, da se iz literature velikokrat čuti boj med »tehniki« in »managerji« (roki, plani, dokumentacija), na kar sem pomislil tudi pri branju navedb manifesta (mimogrede, o tem veliko govori Dilbert. Ga spremljate?). Osebno vedno zagovarjam neko srednjo, zmerno pot: brez dogovorjenih procesov je delo lahko anarhično, rezultati dela in dogovori morajo biti jedrnato dokumentirani, uporabnik naj sodeluje (a naj si sproti ne izmišljuje novih zahtev), plan mora biti, a naj se kontrolirano spreminja glede na situacijo, ideje, dodatne zahteve, ipd. S tem v zvezi menim, da je zelo pomembno kontrolirano obvladovanje sprememb obsega projekta!

Glede na napisano bi lahko rekel, da smo v praksi agilni pristop začeli uporabljati že v začetku 90-tih (pa tega »nismo vedeli«). Praksa je pač velikokrat pred teorijo, kar pa ni nič nenormalnega! Konec koncev se nova teorija vedno rojeva z raziskavami izvajanja v praksi.

Tipični udeleženci projektov in njihove vloge (2)

By Aljaž

On December 4, 2010

In O projektih, Pojmovnik

Stranka ali naročnik (angl.customer) je razlog, zaradi katerega projekt sploh obstaja, saj po zaključku projekta koristi rezultate projekta. V prvi vrsti opredeli namen in cilje projekta, sodeluje s projektnim managerjem pri razčiščevanju zahtev, potrjuje vmesne rezultate in potrdi ter prevzame končni proizvod projekta. Naročnik projekta je lahko notranji, v okviru združbe, kjer se projekt izvaja (služba, oddelek, skrbnik procesa) ali pa zunanji. Kot sem zapisal že ob opisu razlik med projekti glede na naročnika, je naziv »naročnik« dostikrat rezervirano za vrhnji management združbe, ki projektnemu timu naroči izvedbo. Zato bi bilo mogoče smiselno razmisliti, da bi »customer-ja« poimenovali stranka ali uporabnik, ali pa tistega, ki interno odobri projekt imenovati “odobritelj”. Na žalost v SSKJ nimamo pojma za tistega, ki nekaj odobri.

Vloge udeležencev pri pripravi projekta po Verzuh-u

Projektni tim sestavljajo izvajalci projektnih aktivnosti in morajo imeti za to potrebna strokovna znanja. Po navedbi avtorjev obstajata dva nivoja tima:

ožji tim sestavljajo najožji sodelavci managerja projekta, ki so običajno strokovni nosilci posameznih strokovnih področij, ki jih vključuje projekt. Člani ožjega tima, ki projektu posvetijo vsaj 60% (običajno pa 100%) svojega delovnega časa za celoten čas projekta, so največkrat določeni že pred začetkom priprave projekta, lahko na predlog skrbnika, managerja projekta ali sveta projekta. Zaradi strokovnega znanja in izkušenj je zelo pomembna njihova vloga v fazi priprave projekta (strategija izvedbe, potrebne aktivnosti, trajanje aktivnosti in potrebna količina dela, tveganja, ipd.).
širši tim sestavljajo ostali izvajalci projektnih aktivnosti, ki delujejo pod neposrednim vodstvom strokovnih nosilcev. Člani širšega tima se določijo v fazi planiranja projekta, nekateri pa celo med izvajanjem projekta (primer: v planu se določi, da se za montažo potrebuje pet monterjev, monterje pa izbere vodja šele tik pred izvedbo). Za člane širšega tima ni nujno, da so na projektu prisotni celoten čas.

»Tretji nivo« tima predstavljajo zunanji pogodbeni izvajalci.

Poslovno – funkcijski managerji (Young jih imenuje kar »Managerji virov«) kadrujejo svoje podrejene na projekt in so odgovorni, da projektnemu managerju zagotovijo usposobljene strokovnjake, da le-ti niso preobremenjeni z drugimi nalogami ter da so rezultati dela članov oddelka kakovostni in učinkovito doseženi. Po potrebi sodelujejo kot strokovni svetovalci.

Young meni, da ima projekt dva ključna vplivna udeleženca, skrbnika in stranko, ter ostale vplivne subjekte v okviru ali izven združbe. Po vzoru PMBOK, ki jih angleško imenuje influencers jih bom imenoval vplivneži projekta (po SSKJ je vplivnež nekdo, ki ima velik vpliv). Notranji vplivneži so lahko vplivni managerji v združbi, zunanji pa posamezniki, družbeno – politične ali interesne organizacije. Kot smo že omenili, vplivneži lahko s formalno ali prikrito podporo ali nasprotovanjem močno vplivajo na izvajanje in doseganje rezultatov projekta, ter tudi na spremembe ciljev in načina izvedbe projekta. Zato mora projektni tim identificirati potencialne vplivneže, dognati njihove interese in njihov vpliv ter poiskati način zadovoljitve interesov ali način izogibanja možnosti vpliva (Burke).

V kolikor celotnih sredstev za izvedbo projekta ne zagotovi matično podjetje, so pomembni udeleženci tudi (so)financerji projekta. Predvsem pri gradnji družbeno koristnih objektov so to lahko lokalne skupnosti in država. Lahko najdemo sovlagatelje, pokrovitelje, si pomagamo s kreditom, možno pa je tudi pridobiti nepovratna sredstva s strani EU ali države. Potrebno se je zavedati, da sofinancerji želijo imeti svoj vpliv pri opredelitvi ciljev in izvedbe projekta, poleg tega pa zahtevajo stalna in redna poročila o izvedbi.

Običajna razmerja med udeleženci so prikazana na sliki v prejšnjem prispevku.

Tipični udeleženci projektov in njihove vloge (1)

By Aljaž

On November 30, 2010

In O projektih, Pojmovnik

Projekt naj bi zadovoljil interese vseh udeležencev, med katere šteje Kerzner dobavitelje, stranke, zaposlene, posojilodajalce, delničarje in tudi konkurente. Udeleženci projekta (angl. stakeholders, v Sloveniji se vse več uporablja izraz deležniki) so posamezniki ali organizacije, ki so aktivno udeleženi na projektu oziroma katerih interes lahko pozitivno ali negativno vpliva na izvajanje ali zaključek projekta (PMBOK). Nekateri avtorji jih delijo na aktivne udeležence (angl. key players), kateri so vključeni v projektno organizacijo in formalno sodelujejo pri izvajanju projekta, ter na vplivneže projekta (angl. influencers), ki posredno lahko vplivajo na doseganje rezultatov projekta s formalno ali prikrito podporo ali nasprotovanjem.

V nadaljevanju navajam opredelitev tipičnih udeležencev projekta, povzeto po različnih virih (Kerzner, Verzuh, Young, PMBOK). Pri tem moram opozoriti, da navajam tipične vloge, pri čemer lahko na posameznem projektu ena oseba »igra« več vlog – vodja Prodaje je npr. lahko hkrati naročnik in skrbnik projekta.

Udeleženci projektov

Osrednja oseba projekta je projektni manager, ki je osebno odgovoren za učinkovito izvedbo projekta (čas, stroški, kakovost), kar naj bi dosegel z ustreznim planiranjem, organiziranjem, vodenjem tima in kontroliranjem izvedbe. Ker ta blog v osnovi obravnava management projekta, bo o nalogah projektnega managerja še veliko napisanega v nadaljevanju.

Vodstvo združbe (uprava, direktor / predsednik uprave) skrbi, da so cilji projektov usklajeni s strateškimi usmeritvami združbe, odloča o usodi projekta (o začetku, izvedbi, prekinitvi), dodeljuje vire za podporo projekta (denar, ljudi, opremo, ipd.), določa prioritete projektov, nadzoruje projekt skozi celoten življenjski cikel projekta in sodeluje pri pomembnih vsebinskih odločitvah. Vodstvo združbe lahko določi odgovorno osebo, ki v njihovem imenu odloča o projektih, potrjuje elaborate, ipd. To je lahko član uprave, direktor projektne pisarne (direktor portfelja projektov) ali kdo od linijskih managerjev.

Predvsem v večjih združbah, kjer se izvaja veliko projektov, vodilni manager za nadzor projekta določi nadzornika ali skrbnika projekta, katerega nekateri po vzoru angleške literature imenujejo kar sponzor (angl. sponsor). To je običajno kdo od izkušenejših linijsko – funkcijskih managerjev, ki naj bi skrbel, da bo imela združba čim višjo korist od projekta, ki izbere managerja projekta, potrdi plan / elaborat projekta, sodeluje pri pomembnih odločitvah na projektu, nadzira delo tima in napredek projekta, rešuje konflikte med udeleženci ter potrjuje morebitne spremembe. Poleg nadzora projekta naj bi s svojim vplivom in izkušnjami tudi pomagal managerju projekta pri reševanju organizacijskih problemov na projektu. Glede na navedeno lahko ugotovimo, da naziv »nadzornik« ni najbolj ustrezen, saj je vloga skrbnika širša kot le nadziranje delovanja projektnega tima. Angleško slovenski slovar izraz »sponsor« prevaja kot odgovorna oseba, porok, boter, pokrovitelj. Ker večina prevodov opredeljuje preozko pojmovanje, se strinjam z Golobom, da je najustreznejši naziv »skrbnik« (po SSKJ = kdor skrbi za kaj sploh), čeprav menim, da bi bil »boter« še najprimernejši, a na žalost ima izraz preveč negativnih predznakov.

Naloge skrbnika lahko prevzame tudi kolektivni organ – svet projekta (imenovan tudi usmerjevalna skupina). V primeru internih projektov so poleg skrbnika člani sveta lahko tudi naročnik in linijski managerji, katerih podrejeni so člani projektnega tima. Pri zunanjih projektih, predvsem na področju gradnje objektov, kjer projekt pomembno vpliva na širše družbeno okolje, pa so v svetu lahko predstavniki naročnika, vlagateljev, lokalne skupnosti, ipd. Naloge sveta so podobne nalogam skrbnika, predvsem pomembno pa je potrjevanje vmesnih rezultatov ob mejnikih projekta in odobravanje predlogov sprememb, katere bi občutneje dvignile stroške projekta ali ogrozile izvedbo v okviru rokov.

Pomembnejši dokumenti projekta

By Aljaž

On November 16, 2010

In O projektih, Pojmovnik

V tem prispevku bom na kratko predstavil najbolj tipične “organizacijske” dokumente posameznih faz projekta. Podrobneje se bom posameznim dokumentom posvetil kasneje.

Največ avtorjev navaja, da se projekt sproži z listino projekta (angl. project charter). Verzuh (2005) meni, da listina »naznani« obstoj projekta, vključuje pa opredelitev obsega projekta, namen in cilj, potrebe po virih, okvirno oceno stroškov in učinkov (angl. cost-benefit assessment), ter matriko (poslovnih) tveganj. Namen listine je tudi formalni prikaz podpore vodstva združbe in vzpostavlja legitimno avtoriteto managerja projekta. PMI (PMBOK, 2004) naštetim točkam dodaja še mejnike projekta in čas povrnitve vloženih sredstev (angl. return on investment). Lahko bi rekli, da je listina projekta končni proizvod faze snovanja projekta. Na podlagi poznavanja slovenske prakse smatram, da je v Sloveniji bolj poznan izraz »predlog projekta«, katerega bom uporabljal tudi v nadaljevanju bloga.

Dokumenti posameznih faz projekta

Moram pa opozoriti, da se dokument z opisano, dokaj obširno vsebino običajno izdela za interne projekte. V kolikor imamo zunanjega naročnika, potem je vhod v pripravo projekta “povpraševanje” z bolj okrnjeno vsebino (kratek opis namena, cilji – obseg / proizvodi, ključni termini).

Avtorji, ki projektni pristop prikazujejo kot orodje za uvajanje sprememb v združbah, v fazo snovanja vključujejo tudi pripravo »poslovne oziroma idejne rešitve« (angl. business case). Dokument naj bi vseboval razloge za izvedbo projekta (problem, priložnost), obseg pričakovanih sprememb v delovanju združbe ter pričakovane poslovne koristi oziroma prihranke (Prince2, 2002; www.method123.com). Nekateri avtorji dokument slovensko prevajajo kot »poslovna študija«, a menim, da je primernejši izraz »idejna rešitev«. Lahko bi rekli, da je idejna rešitev dejansko zelo nazorna opredelitev organizacije, kot naj bi izgledala ob zaključku projekta, zato jo lahko smatramo kot pomemben del predloga projekta.

Lock (2003) poudarja pomembnost dokumenta s specifikacijo predvidenih proizvodov, na podlagi katerih se nato pripravi obseg del. V literaturi pa smo naleteli tudi na izraz konfiguracija projekta (Charvat, 2002; Cleland, 1999; Kerzner, 2006). Cleland navaja, da management konfiguracije vključuje obvladovanje funkcionalnih in fizičnih karakteristik proizvodov skozi življenjski cikel projekta. Nekateri menijo, da je specifikacija del dokumentacije, ki nastane v fazi priprave projekta. S tem se lahko le delno strinjam, saj je opredelitev specifikacije in obsega projekta stvar naročnika (uporabnika) in ne projektnega tima. Slednji sicer naročniku lahko pomaga s svojim strokovnim znanjem in izkušnjami, a še vedno je naročnik tisti, ki “se podpiše” pod specifikacijo. Glede na vrsto projekta pa se le-ta lahko izdela v sklopu snovanja ali v sklopu priprave projekta.

Večina avtorjem navaja, da se na podlagi predloga projekta (ciljev, obsega in specifikacij) v fazi priprave projekta izdela terminski plan s planom potrebnih virov, predračun stroškov, plan obvladovanja tveganj, organizacija projekta, plan obvladovanja dokumentacije in komuniciranja. Hauc (2007) vse navedene vsebine združi v en dokument, ki ga imenuje »elaborat projekta«. Čeprav se v Sloveniji uporabljajo tudi drugi izrazi, kot so “Plan projekta”, “Poslovni načrt projekta”, “Projektna naloga”, ipd., smatram, da je Haučevo poimenovanje najbolj ustrezno, seveda pa je od vrste projekta in naročnika odvisna vsebina elaborata, kar bom podrobneje prikazal v enem od kasnejših prispevkov.

V fazi izvedbe projekta so najbolj pogosti dokumenti zapisniki rednih kontrolnih sestankov (angl. progress meetings) in redna (mesečna) poročila nadzorniku in/ali naročniku projekta. Vsebina obojih je lahko podobna ali celo enaka, vključuje pa informacije o aktualnih aktivnostih (ki so v izvajanju, ki so bile in/ali ki naj bi bile pravkar izvedene, ki se bližajo in/ali naj bi se bližale zaključku), problemih pri izvedbi in vzrokih za odstopanja izvedbe od plana ter seznam planiranih ukrepov za odpravo odstopanj. V mesečno poročilo se poleg tega običajno vključi še informacija o stroških projekta.

Z združevanjem rednih poročil lahko dokaj hitro izdelamo tudi zaključno poročilo projekta, ki je pomembno za prenos dobre (in preprečevanje slabe) prakse na kasnejše projekte. V poročilu se prikažejo taktične napake pri izvedbi, vzroki za odstopanja (čas, stroški, kakovost) in ukrepi za odpravo, morebitne spremembe, poročilo o obvladovanju tveganj ter analiza delovanja tima.

Faze projekta

By Aljaž

On November 13, 2010

In O projektih, Pojmovnik

Faze projekta ne smemo enačiti s procesom managementa, čeprav so nekateri avtorji s svojo opredelitvijo faz blizu korakom managementa. Faze so bolj vsebinske narave, vsaka vključuje določen proizvod, ki nastane v okviru zaokroženega sklopa aktivnosti – npr. študija izvedljivosti, plan projekta, izdelek, ipd. Strokovnjaki sicer navajajo različne faze, ki pa se po opisu veliko ne razlikujejo; nekateri jih podrobneje razdelijo, drugi pa jih več združijo v eno.

Faze projekta po različnih avtorjih

Pojem “conception” Oxfordov slovar opredeljuje kot proces snovanja ideje ali plana (angl. the process of forming an idea or a plan), angleško-slovenski ga prevaja kot (za)misel oz. osnovo, slovar tujk pa kot zasnovo, zamišljanje ali izoblikovanje nečesa. Zato menim, da bi bil najprimernejši izraz za prvo fazo projekta “snovanje“. Snovanje projekta vsebuje opredelitev ideje, ugotovitev potrebe ali priložnosti (izdelek, sredstvo, storitev), oceno pričakovanih učinkov (in kriterijev uspešnosti) ter utemeljitev, zakaj je projekt potreben (namen projekta). Preuči se možnost izvedbe projekta (študija izvedljivosti) – ocenijo se viri, ki so potrebni in ki so na voljo v združbi. Poleg tega se postavi okvirni plan projekta – groba ideja, kako naj bi projekt potekal, pri čemer nekateri predlagajo tudi izdelavo seznama domnev, tveganj in ovir. Vse to seveda izvede naročnik projekta, ki naj bi kasneje koristil proizvod(e) projekta za doseganje poslovnih ciljev.

Posamezni avtorji omenjajo tudi iniciacijo projekta (angl. initiation = the act of starting something). Angleško slovenski slovar izraz prevaja kot začetek oz. uvod, slovar tujk pa kot začetno stopnjo kakega procesa. Načeloma bi to lahko imenovali začetek projekta, a vendar iniciacijo tuji avtorji različno opredelijo. Začetkov je lahko več (začetek snovanja, priprave, izvedbe), zato menim, da “faze” iniciacije ne bi bilo smiselno posebej izpostavljati kot faze projekta.

Sledi definiranje obsega in planiranje projekta. Nekateri avtorji sicer določitev namena in ciljev projekta uvrščajo v fazo snovanja, drugi v fazo definiranja obsega, vendar menim, da oboje spada v fazo snovanja, ker je to stvar naročnika. Na podlagi jasno opredeljenih ciljev se nato izdela plan projekta (seznam aktivnosti, mrežni / terminski plan, plan virov in stroškov ter plan obvladovanja tveganj), nekateri pa v planiranje vključujejo tudi organizacijo projekta ter sistem komunikacij. V osemdesetih se je kot združen proces planiranja in organiziranja pojavil »project start-up« (omenjajo ga Turner in Simister, 2000, ter Young, 2000), ki naj bi po navedbah omenjenih avtorjev vključeval tudi definiranje obsega. PRINCE2 v proces vključuje imenovanje projektnega tima, predstavitev poslovnega ozadja in namena projekta ter planiranje izvedbe. Hauc, Kovač in Semolič (1993) menijo, da naj bi ta faza združila vse potrebne pripravljalne aktivnosti pred začetkom izvajanja projekta, po različnih avtorjih zajete v fazah snovanja in definiranja projekta. Za razliko od Younga naj bi faza po njihovem mnenju vključevala tudi izdelavo plana projekta. Omenjeni slovenski avtorji »start-up« fazo prevajajo kot zagon, v praksi pa se pogosto uporablja izraz priprava projekta.

Tipične faze projekta

Izvedba projekta vsebuje izvajanje planiranih aktivnosti v skladu s planom. To je običajno najobsežnejša faza projekta, saj v njej sodeluje največ ljudi in se porabi največ sredstev. Za uspešno izvajanje so odločilnega pomena ustrezno usklajevanje udeležencev, vodenje članov tima in kontroliranja izvedbe. Zaključna faza – predaja rezultatov in zaključek projekta – vsebuje izdelavo dokumentacije in predajo rezultatov naročniku. Čeprav se ves čas poteka projekta preverja skladnost izvajanja s cilji in specifikacijo, se dokončna potrditev izdelka pridobi šele v tej fazi. Projekt se zaključi, ko naročnik s prevzemom potrdi ustreznost rezultatov, projektni tim pa izdela zaključno poročilo projekta. Po potrjenem zaključnem poročilu se projekt formalno zaključi, s čimer se tudi razpusti projektni tim.

Nekateri avtorji med faze projekta vključujejo tudi koriščenje (proizvoda), kar seveda ni ustrezno, saj je koriščenje del “rednega operativnega dela”. Vseeno je za naročnika smiselno spremljanje učinkov projekta, da preveri uspešnost projekta oz. ustreznost predhodnih ocen pričakovanih koristi.

Namen, obseg, cilj in proizvod projekta

By Aljaž

On November 9, 2010

In Pojmovnik

V praksi se velikokrat pojavlja, da ljudje ne razumejo oziroma ne razlikujejo pojmov, kot sta namen in cilj. Poleg tega se v tujini v povezavi s tema pojmoma pojavlja tudi “obseg”, ki ga v slovenski teoriji in praksi redkeje srečamo, kar ljudi lahko še dodatno zmede. Da bo zmeda popolna, dodajam še omejitve in proizvode projekta. A vsi navedeni pojmi se dajo lepo razložiti in povezati.

Oxford Advanced Learner’s Dictionary namen in cilje opredeli takole:

Namen (angl. goal) – nekaj, kar se nadejaš, da boš dosegel (angl: something that you hope to achieve), dolgoročnejši cilji. Uporaba (angl.): to work towards a goal to achieve / attain a goal; You need to set yourself some long-term goals.
Cilj (angl. objective) – nekaj, za kar se trudiš, da bi dosegel (angl. something that you are trying to achieve). Uporaba (angl.): the main / primary / principal objective; to meet / achieve your objectives; the main objective of this meeting is to give more information on our plans.

Projekte izvajamo z namenom dolgoročnega koriščenja proizvodov

Projekti se običajno ne izvajajo zaradi projektov samih, ampak zato, da bi prinesli neke koristi. To je namen projekta! Da bi lažje razumeli pojem, se vprašamo: “Zakaj sploh izvajamo projekt?” Namen je nek »posredni cilj« ki se ne uresniči neposredno v okviru projekta, ampak ga na daljši rok uresničijo doseženi cilji projekta. V tuji literaturi smo poleg izraza “goal” našli tudi izraz “purpose”, a se redko uporablja, včasih pa je opredelitev združena: »goal« je specifičen rezultat ali »purpose« projekta (Microsoft, 1997). Andersen (2004) meni, da je namen projekta velikokrat reševanje poslovnega problema , zato bi ga lahko poimenovali tudi »poslovni cilj projekta«, saj je projekt vedno vzpostavljen in izpeljan z namenom, da učinki projekta služijo kot »sredstvo« za doseganje ciljev poslovanja.

Navedimo še nekaj primerov: nov izdelek je namenjen dvigu tržnega deleža, IT podpora procesu cenejšemu in hitrejšemu izvajanju procesa, konferenca promociji stroke, proizvodna hala pa razširitvi proizvodnje.

Tuji avtorji za opredelitev končnega stanja projekta uporabljajo izraza »objectives« (zato Hauc uporablja izraz “objektni cilj”) in »deliverables«. Opredelitev izraza »deliverable« v angleščini je: »a product that a company promises to have ready for a customer«, torej »proizvod za stranko«. Pojem bi tako opredelili kot nekaj, kar nastane kot posledica izvajanja aktivnosti do konca projekta – izdelek, storitev, nova organizacija dela, ipd., kar bi s skupnim izrazom lahko poimenovali proizvod(i).

Pojem, ki ga v neposrednem prevodu nismo našli pri slovenskih avtorjih, je »scope«, ki ga je nabolj smiselno prevajati kot »obseg projekta«, čeprav bi mu lahko rekli tudi vsebina projekta. PMBOK (2004) ločuje obseg projekta in obseg proizvodov (ki naj bi bili del ciljev projekta). Prvi naj bi vključeval obseg del, ki naj bi jih izvedli, da bi ustvarili proizvod, storitev ali rezultat z ustreznimi lastnostmi in funkcijami. Drugi vključuje lastnosti in funkcije, ki določajo proizvod, storitev ali rezultat. Obseg projekta opredeljuje, kaj projekt vsebuje in – kar je včasih še bolj pomembno – česa ne vsebuje (Burke, 2003).

Primer: obseg proizvodov uvedbe IT podpore procesu vključuje prenovljen proces (vključno z organizacijskim predpisom) ter razvit in v delovanje vpeljan SW, obseg del pa (lahko ali ne) popis in prenovo procesa, pripravo in izdajo organizacijskega predpisa, izdelavo specifikacije informacijske podpore, razvoj le-te, usposabljanje uporabnikov in poskusno delovanje.

Omejitve projekta smo opredelili že v prispevku “Značilnosti projektov…” – govora je o “jeklenem trikotniku”: kakovosti, času, stroških. Pri tem smo zapisali, da omejenost projektov pomeni, da mora biti proizvod projekta ustvarjen z določeno minimalno kakovostjo, v okviru predvidenih stroškov in do vnaprej določenega roka. Pomembno je torej zavedanje, da cilj projektnega tima ni le, da ustvari proizvod, ampak ga mora ustvariti v okviru postavljenih omejitev! Zato pojma cilj (objective) in proizvod (deliverable) nista sopomenki, ampak sta logično povezana – pričakovani proizvodi so del cilja.

Z enim stavkom bi tematiko opredelili takole: cilj projekta oziroma naloga projektnega tima je, da planirane proizvode (obseg) z ustrezno kakovostjo ustvari v okviru planiranega časa in predvidenih stroškov (omejitve), naročnik projekta pa bo po zaključku projekta s koriščenjem proizvodov projekta dosegel svoje poslovne (strateške) cilje, kar je namen projekta.