Feeds:
Objave
Komentarji

Archive for the ‘Pojmovnik’ Category

Združbe seveda ne »zgrabijo« vsake ideje in pobude, zato se takoj ne lotijo projekta, ampak se preudarno odločijo, če in kateri projekt bi bilo smiselno (smotrno) izvesti. Da ugotovimo »ali se splača« izvesti projekt, si pomagamo s primerjavo stroškov izvedbe s pričakovanimi koristmi. Ker je idej lahko veliko, je dostikrat  potrebno izbrati najboljše – načeloma izberemo tiste projekte, ki bodo čim prej prinesli največ koristi. A obstaja še kar nekaj dejavnikov, katerih vplive stroka vključuje v študijo izvedljivosti.

Čeprav sem v praksi izdelal kar nekaj študij, moram priznati, da sem v preteklosti študijo izvedljivosti jemal »dobesedno« kot oceno zmožnosti izvedbe. No, podrobnejši pregled literature mi je razkril, da vključuje tudi vrsto drugih analiz in preverb – vse z namenom, da je odločitev o izvedbi projekta kar najbolj optimalna.

Čeprav naj bi pobuda projekta vsebovala okvirno oceno koristi projekta, je potrebno preveriti, če pobudnik mogoče ni bil preveč optimističen ali pa je mogoče je zanemaril določene dejavnike. Razmisliti je tudi potrebno, ali predlagan projekt dejansko najbolj optimalno rešuje poslovni problem (oz. izkorišča priložnost). Ali mogoče obstajajo druge alternative in kakšne koristi prinašajo? Koristi se seveda finančno ovrednotijo, pri čemer se morajo upoštevati »operativni« stroški npr. proizvodnje izdelka, vzdrževanja linije, ipd.

Študija izvedljivosti

Študija izvedljivosti projektaPrirejeno po: Brandon 2006, Heldman&Heldman 2007, Kerzner 2001, Lock 2007, Newell 2002, Thomset 2002, Turner 2009

Drugi del vsebuje oceno zmožnosti izvedbe projekta. Tudi tu je potrebno razmisliti o več alternativah – ali naj se celoten projekt izvede v združbi ali s pomočjo zunanjih izvajalcev? Naj rešitev kar kupimo? Pri tem je seveda potrebno upoštevati zmožnosti zaposlenih (znanje, izkušnje, razpoložljivost), razmisliti je potrebno o potrebnih delovnih sredstvih. Je res, da so zaposleni cenejši od zunanjih, glede na trajanje aktivnosti in kakovost izvedbe? V kakšnem času smo sploh sposobni izvesti projekt? Z vidika pričakovanih koristi je smiselno »finančno ovrednotiti« čas izvajanja (npr. koliko več koristi prinese mesec dni krajši projekt).

Sledi okvirna ocena stroškov izvedbe, pri kateri združbe večinoma uporabijo metodo »top-down«, pri kateri se projekt stroškovno oceni na podlagi dejanskih stroškov preteklih primerljivih projektov. Lahko si pomagajo z oceno svetovalcev, ki so v preteklosti delali na podobnih projektih, ne gre pa zanemariti poklicnih kolegov iz drugih (nekonkurenčnih) združb, sošolcev… ter drugih znancev z izkušnjami s primerljivih projektov. V veliko pomoč snovalcem projekta je pri tem lahko projektna pisarna, ki sistematično analizira zaključene projekte in gradi bazo znanja, lahko pa se vključi tudi predvideni manager projekta.

Po oceni koristi  in stroškov se »analiza stroškov in koristi« (Cost Benefit Analysis) zaključi s primerjavo obeh. Najbolj enostavna ocena smotrnosti izvedbe je seveda razmerje med koristmi in stroški, ki naj bi bilo večje od 1 (donosnost projekta), zanima pa nas tudi, k kolikšnem času bodo prihodki (ali prihranki) povrnili porabljena sredstva (doba vračanja). Za daljše projekte je za realnejšo oceno potrebno upoštevati tudi diskontno stopnjo (NSV – neto sedanja vrednost, razlika med diskontiranim tokom vseh koristi in vseh stroškov investicije / projekta), zelo uveljavljena pa je metoda izračuna interne stopnje donosnosti (IRR, diskontna stopnja, pri kateri je NSV enaka nič).

Pred dokončnim izborom najustreznejše alternative oziroma pred potrditvijo projekta je smiselno tudi preveriti, ali obstaja kakšna možnost, da vračanje vloženih sredstev ne po potekalo pričakovanjih. Mogoče se izdelek ne bo tako dobro prodajal, stanovanj v novem bloku ne bomo mogli tako hitro prodati, prireditev bo obiskalo manjše število ljudi, ali pa nova programska oprema ne bo zmanjšala stroškov procesa za toliko, kot smo se nadejali. Ta vprašanja lahko vključimo v področje ocene »poslovnih tveganj«, upoštevajo pa se pri pesimističnih ocenah pričakovanih koristi, ki se tudi upoštevajo pri izračunu prej navedenih kazalnikov projekta.

Mogoče še to – študija izvedljivosti ne služi le vodstvu, ki se odloča, ali se bo projekt izvedel, podobne študije zahtevajo tudi banke, pri katerih se združbe dogovarjajo za najem kredita za izvedbo projekta!

Na žalost v sklopu preučevanja literature nisem našel priporočila, koliko časa in stroškov je smiselno porabiti za izdelavo študije izvedljivosti. Vsekakor je to odvisno od trajanja in vrednosti projekta, a bi težko navedel priporočljiv odstotek, sploh ker je to odvisno tudi od vrste projekta. Pa pustimo to dilemo za debatni večer…

Na spodnjih povezavah pa najdete še več informacij o obravnavani problematiki:
Uredba o enotni metodologiji za pripravo in obravnavo investicijske dokumentacije na področju javnih financ (Uradni list)
Pravilnik o metodologiji izdelave in vsebini študije izvedljivosti alternativnih sistemov za oskrbo stavb z energijo (Uradni list)
Priročnik za izdelavo analize stroškov in koristi investicijskih projektov (Računovodja.com)
Investicijski elaborat (Računovodja.com)

Advertisements

Read Full Post »

Pri preučevanju faze snovanja (inicializacije oz. koncipiranja) v literaturi sem naletel na različne opredelitve procesa z različno poimenovanimi dokumenti. V enem zgodnejših prispevkov sem na kratko že predstavil charter in business case, poleg podrobnejše opredelitve omenjenih dveh dokumentov pa bom v naslednjih nekaj prispevkih prikazal še študijo izvedljivosti, »cost/benefit« analizo, specifikacije, SOW, POS, itd.

Najprej naj opozorim, da je faza snovanja sicer del projekta, a vendar aktivnosti te faze niso del managementa projekta. Sodelovanje projektnega managerja pri snovanju projekta je sicer priporočljivo (kot sem omenil zadnjič), vendar pa je ta faza v domeni pobudnika, končnih uporabnikov in/ali bodočega skrbnika projekta (običajno predstavnika končnih uporabnikov). Poleg tega je značilna le za »interne projekte«, katerih rezultati (nov objekt ali oprema, reorganizacija, IT podpora procesu, nov način dela, nov izdelek…) naj bi združbi pobudnika prinesli dolgoročnejše koristi. Združbe, ki projekt izvedejo proti plačilu za znanega zunanjega naročnika, se s snovanjem projekta ne ukvarjajo, razen če pomagajo (svetujejo) bodočemu naročniku pri oceni izvedljivosti še preden slednji sploh objavi povpraševanje.

Vsaka »projektna« pobuda se nedvomno porodi na podlagi lastnih problemov pri delu, ob kritičnem opazovanju delovanja oziroma analizi poslovanja združbe, spremljanju konkurence ali nasploh zaradi sprememb v okolju. Pobudnik projekta mora v začetku predstaviti ozadje problematike (dogajanja na trgu, v združbi), izpostaviti probleme, ki naj bi jih projekt rešil, oziroma priložnosti, ki bi jih bilo smiselno izkoristiti (primere sem prikazal na sliki). V velikih primerih, sploh če projekti izhajajo strateških planov združbe, probleme in priložnosti najdemo v SWOT analizi.

Primeri vsebine predlogov projektov

Predlog projekta / business case*

Strokovnjaki navajajo, da ima prvi dokument projekta, imenovan »business case«, katerega pripravi pobudnik projekta, naslednje vsebine:

  • ozadje in poslovni problem oz. priložnost
  • tržni vidik
  • predlagano rešitev (oz. več alternativ s projekcijami učinkov)
  • prikaz usklajenosti s strategijo združbe
  • poslovne in organizacijske koristi (če je možno, prikazane finančno)
  • način merjenja učinkov projekta (prihodkov, prihrankov)

Dokumentu bi lahko rekli tudi »poslovna utemeljitev projekta«, saj naj bi jasno opredelil razloge za izvedbo projekta. Idejna rešitev naj bi bila kasnejši končni proizvod projekta, iz koristi pa izhaja namen projekta. Na podlagi jasno opredeljene pobude se vodstvo združbe prvič odloča o projektu. V primeru pozitivnega mnenja, se snovanje projekta nadaljuje s poglobljeno oceno smotrnosti izvedbe in opredelitvijo obsega projekta.

Omenil sem že, da nekateri slovenski avtorji »business case« prevajajo kot »poslovna študija«, sam pa sem v že omenjenem prispevku navedel, da bi bil primernejši izraz  »idejna rešitev« (opredelitev organizacije, kot naj bi izgledala ob zaključku projekta). Zdaj, ko sem podrobneje pregledal opredelitve več kot dvajset tujih avtorjev, pa bi se mogoče bolj strinjal s »poslovno študijo«, saj, kot sem prikazal v prejšnjem odstavku, vsebuje več, kot le prikaz končne rešitve. Lahko pa bi ga enostavno poimenovali »predlog projekta«? Kaj pa v dokument vključujete vi in kako ga imenujete?

Read Full Post »

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

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

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

Proces in vsebina snovanja projekta

Faza snovanja projekta

Poglejmo še nekaj definicij faze snovanja:

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


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

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

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

 

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

 

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

 

Poglejmo še nekaj definicij faze snovanja:

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

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

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

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

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

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

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

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

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

Read Full Post »

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

Management / vodenje projekta - tradicionalno, agilno in ekstremnoVir: 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…

Read Full Post »

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)

APF agilni management / vodenje projektaVir: 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.

Read Full Post »

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

Management vodenje projektov - vloge v pripravi projekta*

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.

Read Full Post »

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

Management vodenje projektov - udeleženci*

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.

Read Full Post »

« Newer Posts - Older Posts »

%d bloggers like this: