Category: Management Page 5 of 6

Terminski plan projekta – gantogram

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.

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!

Ekstremni projektni management in »dinamično« planiranje

By Aljaž

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.

Metodologije in standardni projektnega managementa

By Aljaž

On December 29, 2010

In Management, O projektih

Že kar nekaj časa me je mučilo vprašanje, ali sploh obstaja kakšna »uradna« metodologija projektnega managementa, zato sem malo pobrskal po literaturi in internetu. V SSKJ je zapisano, da je metodologija »skupek metod, ki se uporabljajo pri raziskovanju«, Dinsmore (2010) pa jo opredeli kot »zbir metod in pravil v znanosti ali stroki«.

Lahko bi torej rekli, da je metodologija nabor metod, vprašanje pa je, ali metodologija predpisuje proces, zaporednost uporabe metod ter ali je uporaba metod »obvezujoča«, saj se projektni cikel razlikuje glede na vrsto in obseg projekta. Četudi nekateri omenjajo več projektnih metodologij, bi med njimi tudi težko našli večje razlike, saj vse vključujejo metode WBS, CPM, EVA, enake organizacijske strukture, podobno se lotevajo projektnih tveganj, ipd.!

Sicer pa se v praksi največ omenja tri »metodologije« – IPMA, PMI in PRINCE, vendar bi le slednjo pogojno lahko uvrstili med metodologije. Razvita je bila v 80-tih za potrebe obvladovanja projektov v britanski javni upravi, druga verzija, PRINCE2 iz leta 1996, pa je bila zastavljena širše, saj je pri pripravi menda sodelovalo kar 150 organizacij. Osebno menim, da je dokaj omejeno uporabna, a naj si vsak ustvari svoje mnenje… Priročnik PMBOK ni PMI metodologija, ampak – kot navaja Dinsmore – nabor znanj v sklopu stroke, neke vrste priročnik, ki se običajno upošteva kot »standard dobre prakse«. No, avtorji so ga uspeli tudi uradno »standardizirati« (več v nadaljevanju). IPMA pa zaenkrat sploh nima metodologije, čeprav se govori, da naj bi »za svojo« prevzela PRINCE2.

Torej, namesto, da iščemo »najboljšo splošno metodologijo«, bi bilo primerneje narediti nabor vseh možnih metod s priporočilom kdaj in na katerem tipu projekta naj se uporabijo…

Razvoj “lastne” metodologije združbe

Kaj pa standardi? SSKJ opredeli »standard« kot predpis, ki opredeljuje mere, kakovost, postopke, ipd. Za področje projektnega managementa sta najbolj poznana standarda ISO 21500: 2008 Project Management – Guide to project Management (prej ISO 10006: 2004) ter ANSI PMI 99-001: 2008, ki je nastal na podlagi PMBOK-a. Kdor se kdaj ukvarjal z ISO standardi ve, da zagotavljajo urejeno poslovanje (procesi, postopki, obrazci…), ki naj bi posledično omogočilo učinkovito delovanje in nižje stroške poslovanja. Slabost standardov pa je, da večinoma bolj opredeljujejo “kaj” je potrebno delati (narediti), ne pa “kako”.

Sicer pa standardi lahko nastanejo načrtno (določi se skupina strokovnjakov, ki pripravi standard) ali pa standard nastane na podlagi metodologije, priporočil, ipd., kot je bil PMBOK osnova za ameriški standard in PRINCE2 za britanskega. Mogoče čaka podobno usodo tudi trenutno »neuradni standard« IPMA ICB V3, ki »predpisuje« priporočljive kompetence / veščine projektnih managerjev, IPMA model projektne odličnosti, ali pa kakšnega od zrelostnih modelov. Pomembno pa je tudi dejstvo, da na podlagi uradnih in neuradnih standardov združbe in posamezniki lahko pridobijo certifikate, ki jih lahko koristijo tudi v tržne namene…

Kaj torej upoštevati pri svojem delu? Pri Dinsmoreju in pri Kerznerju (2009) smo zasledili navedbo, da naj bi združba imela enoten pristop, neke vrsto svojo interno metodologijo, ki naj bi omogočala čim bolj racionalno izvajanje projektov. Priporočilo omenjenih avtorjev je, da naj bi bila metodologija prej skupek priporočil in obrazcev, kot pa pravil in procedur, čeprav menim, da moramo opredeliti tudi slednje. Vsekakor pa mora biti metodologija zadosti prilagodljiva, da se lahko uporabi za različne vrste projektov v združbi, priporočljivo pa je tudi, da je prilagojena organizacijski kulturi združbe in ne obratno – napačno je mišljenje, da le z novim organizacijskim predpisom lahko korenito spremenimo odnos zaposlenih do projektov. Wisocky (2009) pa dodaja, da je odličnost projektnega managementa v upoštevanju zdrave pameti!

Torej, z veliko mero zdrave pameti je pri organiziranju projektov v združbi potrebno upoštevati standarde in priporočila, uporabiti preizkušene metode, upoštevati naravo dela v združbi ter pripraviti svojo metodologijo. In ne pozabiti, da se projekti izvajajo tudi v sodelovanju z drugimi (partnerstvo, podizvajalci)…

Priporočljive osebnostne lastnosti projektnega managerja

By Aljaž

On December 21, 2010

In Management, Manager projekta, Vodenje tima

Čeprav se znanstveno nisem nikoli ukvarjal z osebnostnimi lastnostmi ljudi, bom tokratni prispevek pripravil na izkustveni predpostavki, da so osebnostne lastnosti ljudi prirojene. Dolgoletno sodelovanje v različnih skupinah in timih mi je nekako vcepilo občutek, da obstajajo določene sposobnosti, ki se jih ne da priučiti. Le v primeru, da jih človek »nosi v sebi«, jih lahko nadgrajuje z usposabljanjem in prakso. Verjamem, da bi temu mnenju nasprotovali svetovalci s področja vodenja (ki trdijo, da se da vse naučiti) in psihologi (ki osebnostne lastnosti proučujejo znanstveno), pa vendar s to predpostavko v nadaljevanju predstavljam priporočljive prirojene osebnostne lastnosti managerjev projektov. Vse, ki poznajo drugačna dognanja ali imajo drugačne izkušnje, pa pozivam, da napišejo kakšen komentar.

Menim, da je najbolj pomembna lastnost projektnega managerja smisel za organizacijo. Kdor sebi ne zna organizirati dela, se ne drži rokov in dogovorov (ne obvladuje časa in običajno zamuja), ta bo toliko težje organiziral delo drugih. »Občutku za čas« je potrebno dodati sposobnosti koordinacije dela članov tima in zunanjih izvajalcev, pri čemer je pomembno zaupanje do podrejenih, ki je osnova za ustrezno delegiranje s prenosom odločanja na nižji nivo tima. V skupino organizacijskih lastnosti avtorji vključujejo tudi podjetnost (stalno razmišljanje o alternativni učinkovitejši izvedbi), strateško gledanje (planiranje različnih scenarijev poteka projekta, predvidevanje posledic trenutnih odločitev v prihodnosti), sistematičnost in prilagodljivost različnim situacijam.

Najpomembnejše osebnostne lastnosti projektnega managerja

Dober vodja z zanosom, optimizmom, energijo, vztrajnostjo, pogumom in osebno zrelostjo vpliva na podrejene, da mu sledijo. To je pri projektih še toliko pomembneje, ker člani tima prihajajo iz različnih oddelkov in niso neposredno podrejeni managerju projekta. Občutek za vodenje ljudi vključuje obvladovanje medsebojnih odnosov, ustvarjanje dobre delovne klime, zagotavljanje pripadnosti timu, nedenarno motiviranje, inspiracijo in mentorstvo. Pokazati mora zadovoljstvo ob uspehih, pohvaliti ljudi za vložen napor, a vseeno znati kitično oceniti delo tima. Med vodstvene sposobnosti bi lahko šteli tudi pripravljenost na reševanje medosebnih konfliktov. To naj bi mu predstavljalo izziv, ne pa da si zatiska oči pred njimi ali jih celo izkoristi za »obvladovanje« skreganih posameznikov. Pa še nekaj: navkljub temu, da je vodja, mora še vedno ostati timski delavec!

Ena od vitalnih lastnosti je tudi komunikativnost. Pri projektih je velikokrat pomembnejše neformalno sodelovanje, kot pa trdi birokratski odnosi z dopisi, pravilniki in sklicevanjem na pooblastila. Projektni manager mora biti sposoben komunicirati na vseh nivojih v podjetju in tudi izven njega, pri čemer mora različnim situacijam in sogovornikom prilagoditi stil komuniciranja. S komuniciranjem vpliva na obnašanje drugih ljudi – sposoben mora biti pogovora s člani tima, jih poslušati in razumeti, obvladovati mora pogajanja z linijskim managementom, da si zagotovi podporo in ljudi. Kot “ambasador” projekta mora o napredovanju projekta informirati vodstvo podjetja in naročnika. Skratka, vase zaprti ljudje, ki prisegajo na sodobno informatiko in so sposobni komunicirati samo preko elektronske pošte, so slabi vodje, pogajalci, promotorji projekta…

Če bi za prve tri lastnosti še lahko trdili, da so veščine, ki se jih da priučiti (čeprav se s tem težko strinjam), pa za »neposredne« osebnostne lastnosti načeloma ni dileme – morajo biti prirojene. Ker je so projekti povezani s tveganji, nepredvidenimi zapleti, prepleteni z različnimi interesi udeležencev projekta, je zelo pomembna čustvena stabilnost in obvladovanje stresnih situacij. Poleg tega mora biti manager samozavesten, verjeti vase in v svoj tim, a hkrati dovolj samokritičen, da stalno teži k izboljšavam delovanja. Pomembna je tudi odločnost, a ni nujno, da vse odločitve sprejme sam, mora pa poskrbeti, da se čim prej sprejme odločitev.

Osebno bi navedenim lastnostim dodal še eno: ker je vsak projekt deloma ali zelo drugačen od predhodnih, so managerji projektov neke vrste »avanturisti«, ki se vedno podajajo »v neznano«, hkrati pa so projekti blizu tistim, ki v življenju stalno iščejo kaj novega in se hitro naveličajo vsakodnevnih opravil.

Obstajajo pa tudi tipi osebnosti, kateri naj ne bi bili dobri managerji projektov. Izogibati se je potrebno tehnokratov, birokratov in »prodajalcev«. Tehnokrat bi raje neskončno dolgo iskal idealno rešitev, kot tako, ki bi zadovoljivo rešila potrebe naročnika. Ker uživa v strokovnemu delu, mu primanjkuje časa, želje in zmožnosti za koordiniranje drugih in za »administrativno« delo. Birokratu je pomembneje, da se izvajanje drži dogovorjenih postopkov in pravil, kot da je dobro opravljeno. Obožuje formularje in poročila, zaradi pretirane pedantnosti pa je neučinkovit, hkrati pa nadloga za kolege. Najhuje pa je, da svojih poročil ne uporablja za kakršenkoli produktiven namen. »Prodajalec« pa je tip managerja, ki veliko govori, a bolj malo naredi, zato od projekta velikokrat ostaneta le sijajen načrt in zamujena priložnost.

Lastnosti projektnega managerja sem povzel po naslednjih virih: Andersen et al. (2009), Charvat (2002), Heerkens (2002), Heldman & Heldman (2007), Kerzner (2001), Kleim & Ludin (1998), Meredith & Mantel (2009), PMBOK (1996), Škarabot (1994), Turner (1993), Weiss & Wysocky (1992) ter Young (2007).

Veščine in kompetence projektnega managerja

By Aljaž

On December 17, 2010

In Management, Manager projekta

Če malo pobrskamo po internetu, najdemo mnogo opredelitev kompetenc. V eni od predstavitev sem našel tole opredelitev (Bagon): “kompetence so tiste lastnosti, ki posamezniku omogočajo uspešno in učinkovito opravljanje dela glede na zahteve organizacijske vloge. Med te lastnosti štejemo sposobnosti, znanja in veščine ter motivacijo, samopodobo in socialno vlogo”. V tem prispevku bom predstavil prvi vidik – priporočljive kompetence projektnega managerja z vidika znanja in veščin, v naslednjem prispevku pa še potrebne osebnostne lastnosti uspešnega projektnega managerja.

Mislim, da o (teoretičnem) znanju ni potrebno veliko pisati. Znanja s področja managementa se lahko pridobijo s formalnim izobraževanjem na fakultetah, iz knjig, na internetu, ali z dodatnim usposabljanjem (npr. seminarji Projektne akademije Agencije Poti), pa tudi na strokovnih srečanjih (konferencah – ZPM forum). Skratka, imeti znanje pomeni, da vemo, kako naj bi nekaj delali. Veščina pa pomeni, da smo pridobljeno znanje uporabili in osvojili tudi v praksi! Dokler ne poskusiš, niti ne veš, če teorija 100% velja za tvoj tip projekta in če imaš za to potrebne sposobnosti (npr. vodstvene, organizacijske, ipd.).

Kompetence projektnega managerja po IPMA ICB 3.0

Strokovnjaki, ki so pri IPMA razvili program certificiranja (v Sloveniji SloCert), so opredelili kar 46 kompetenc, ki naj bi jih imel uspešen projektni manager. Kompetence so razdelili na tri področja, kar pomeni, da naj bi manager projekta obvladoval metode in orodja projektnega managementa, delo z ljudmi, ter poznal zakonitosti in delovanje okolja projekta. Vprašanje bi lahko bilo, če niso malo pretiravali… Ali res lahko vse navedeno obvladamo oziroma ali je res potrebno imeti vse navedene kompetence. Mislim, da je odvisno od kompleksnosti (organizacijske zahtevnosti) in vrste projekta. Ravno zato obstajajo štirje nivoji certifikatov. Sicer pa podrobnejši opis kompetenc najdete v ICB 3.0, ki si ga lahko brezplačno prenesete z IPMA spletne strani.

Leta 2016 je IPMA izdala novo verzijo – ICB 4.0. Glej…

Kompetence projektnega managerja po IPMA ICB 4.0

In veščine? Glede na teoretično opredelitev kompetenc, bi lahko rekli, da so “IPMA kompetence” prej nabor veščin, kot kompetenc. Je pa res, da tuji strokovnjaki zadeve dostikrat poenostavijo. Morris & Pinto (2007) na primer navajata, da so kompetence “zmožnosti, da nekaj izvedemo dobro in uspešno”. V knjigah uveljavljenih strokovnjakov (Charvat, Heerkens, Heldman, Kerzner, Lewis, Meredith & Mantel, Newell, Philips, Thomsett, Verzuh) sem našel dokaj različne nabore potrebnih veščin, ko pa sem jih združil, sem ugotovil, da sem “sestavil” “IPMA oko kompetenc”.

Navajam pa še nekaj zanimivih: sposobnosti delegiranja, tolerantnost do napak, podjetnost, sposobnost pisanja (zapisnikov, poročil, pogodb), administrativne spretnosti in sposobnosti javnega nastopanja (predstavitve), Young (2007) pa med veščine šteje tudi:

izbiro pravih članov ekipe z ustreznimi znanji;
zmožnost prepoznavanja in razumevanja osebnosti članov tima;
usklajevanje ciljev aktivnosti z osebnimi cilji izvajalcev;
ustvarjanje pravega občutka za odgovornost v timu;
vzpostavitev medsebojne povezanosti članov tima in zavezanosti projektu;
razumljivo razlago odločitev ter učinkovito obveščanje vseh o napredku projekta;
usklajevanje in obvladovanje pogodbenih izvajalcev, dobaviteljev in svetovalcev;
razumevanje dejanskih potreb končnih uporabnikov.

Naj bi bil torej vrhunski projektni manager neke vrste “Superman”? Niti ne, vendar pa, kot pravi slovenski pregovor – več znaš, več veljaš! Pri projektih bi to pomenilo, da obvladovanje več omenjenih veščin pripomore k manjšemu številu problemov pri delu (manj sivih las?) in učinkovitejšo izvedbo. Poleg tega pa obsežen nabor veščin lepo pokaže, da vsega žal ne moremo osvojiti z izobraževanjem, ampak je potrebno izpeljati kar nekaj projektov, da stvari res obvladujemo. Na napakah se učimo in leta prakse naredijo svoje.

Pa še nekaj. Omenjeno je bilo tudi obvladovanje “tehnike” oziroma strokovnih področij, potrebnih za izvedbo projekta. Potrebno se je zavedati, da bolj kot je organizacijsko zahteven projekt, manj se manager ukvarja s stroko! Dobro je, da stroko pozna, da se zna pogovarjati s člani tima ter da ga le-ti ne “goljufajo”, vsekakor pa nima smisla, da je najboljši strokovnjak. Praviloma je to še slabše, ker mu je potem strokovno delo pomembnejše od managerskih nalog. Več o tem pa v naslednjih dveh prispevkih.

Vloga in naloge managerja projekta

By Aljaž

On December 15, 2010

In Management, Manager projekta

Projektni manager je odgovoren skoraj za vse na projektu, zato bi bilo lažje opredeliti, za kaj ni odgovoren, kot pa za kaj je (Newel, 2002). V osnovi je seveda nosilec funkcij managementa, kamor štejemo planiranje, organiziranje, vodenje in kontroliranje. Kerzner (2009) sicer kot tretji korak navaja usmerjanje oz. koordiniranje (angl. directing), Rozman (2008) pa pravi, da projektni manager uveljavlja plan. Lahko bi rekli, da v fazi izvedbe manager projekta koordinira izvedbo aktivnosti, pri čemer z ustreznim vodenjem zagotavlja učinkovito delovanje članov tima.

Poleg navedenega »osnovnega nabora« nalog managementa, pa obstaja še množica opravil, ki naj bi zagotovile kakovostno pripravo in učinkovito izvedbo projekta. V nadaljevanju navajam nekaj pomembnejših nalog, še zdaleč pa to ni celoten nabor.

Priprava projekta

Čeprav njegova neposredna naloga ni opredelitev zahtev, pa mora 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 ter da bo na podlagi zahtev pridobil ustrezne člane tima in zagotovil druge vire za izvedbo projekta. Zahteve mora tudi jasno predstaviti linijskim managerjem, ki mu »posodijo« ljudi za izvedbo projekta.

Naloge managerja projekta

Izvedba projekta

Skrbi za pravočasni začetek izvedbe posameznih aktivnosti – čeprav bi lahko mislili, da izvajalci aktivnosti ob planiranem času samoumevno začnejo z izvedbo svojih aktivnosti, se to brez spodbude managerja projekta velikokrat ne zgodi. Pomembno je tudi, da poskrbi za usklajeno delovanje zunanjih (pogodbenih) in internih izvajalcev ter pravočasno dobavo materiala s strani dobaviteljev. Skrbi tudi za sodelovanje vseh udeležencev projekta (ne le članov tima) v primeru obravnave predlaganih sprememb, reševanja problemov ali odstopanj. Z usklajevanjem skuša zadovoljiti pričakovanja vseh udeležencev.

Pravočasno odpravlja morebitne ovire, stalno je na preži za morebitnimi problemi. Poskrbi, da člani time na svojo roko ne spreminjajo taktike izvedbe ali dogovorjenih rešitev. Vse predlagane spremembe mora tim (glede na velikost spremembe pa studi v sodelovanju s skrbnikom, naročnikom) prediskutirati in jih sprejeti (ali zavrniti) na podlagi jasne slike predvidenih posledic izpeljane spremembe.

Organizira in vodi projektne sestanke. Pri tem velja, da so kontrolni sestanki redni, z vnaprej določenimi udeleženci, terminom in lokacijo (se ne sklicujejo vsakič posebej), problemski pa se sklicujejo po potrebi (potrjevanje idej, predlogov, reševanje problemov, ipd.).

Izpeljati mora »težje« razgovore, kadar je potrebno zamenjati člana tima, od članov tima zahtevati, da delajo izven običajnega delovnega časa, ukrotiti ali kaznovati posamezne člane tima ali rešiti medosebni konflikt, kjer pa naj bi bil »mediator« in ne razsodnik.

Redno poroča nadrejenim (skrbniku, vodstvu, naročniku) o statusu, odstopanjih od planov, problemih, predvidenem nadaljnjem poteku projekta… Manager projekta si ne sme privoščiti, da bi nadrejene presenetil z negativnimi informacijami!

V prejšnjem prispevku sem že tudi omenil odločanje. Pri tem ni nujno, da projektni manager sprejema odločitve sam, saj to lahko zahteva (pre)več časa, poleg tega odločitev mogoče sploh ni najbolj ustrezna, ker imam premalo znanja, izkušenj, ipd. Menim, da mora odločno poskrbeti, da se sprejme odločitev (npr. čim prej organizira krizni sestanek), pri tem naj si pomaga ne samo z mnenji članov tima, ampak naj poskuša izkoristiti znanje in izkušnje najkompetentnejših sodelavcev združbe.

Posamezni avtorji med odgovornosti managerja projekta vključujejo tudi identifikacijo in predstavitev poslovnega problema oz. priložnosti, identifikacijo in opredelitev najboljše rešitve projekta ter opredeli obsega in specifikacij proizvodov. Vendar pa to ne velja za vse projekte. Še več, velja le za ozek nabor projektov. Navedene vsebine mora namreč opredeliti naročnik (koristnik rezultatov) projekta. Manager projekta mu lahko pomaga pri specifikaciji proizvodov s svojim poznavanjem področja, izkušnjami in znanjem, toda pod končno specifikacijo se mora podpisati naročnik, saj bo to osnova za prevzem ustvarjenih proizvodov. Nekoliko večjo vlogo ima pri opredelitvi manager projekta, če je hkrati pobudnik (internega) projekta, sploh če bo tudi sam med koristniki proizvodov. V zvezi s tem sem zasledil tudi navedbo, da mora z »vizijo« projekta prepričati nadrejene, da se projekt izvede oziroma, da mora »prodati idejo« nadrejenim. To pa je velikokrat lahko dvorezen meč – projekt je lahko odobren »s figo v žepu« (pa naj ga izvede, če želi…), širše neformalne podpore (linijskega managementa) pa mogoče ne bo pridobil. Posledice so seveda slabša kadrovska zasedba tima, nestrinjanje z rešitvami, konflikti, ipd.

Pa še nekaj. Manager projekta mora delovati proaktivno in se ne prepustiti »toku dogodkov«. Redno in zadosti pogosto mora kontrolirati izvedbo (tedensko!), iskati mora informacije za svoje delovanje in odločanje, neformalno k odločanju vključevati različne strokovnjake ter pravočasno širiti prave informacije med prave ljudi.

(Viri: Kerzner, 2009; Kerzner & Saladis, 2009; Meredith & Mantel, 2008; Portny, 2007; Heldman & Heldman, 2007; Lewis, 2006; Verzuh, 2005; Charvat, 2002, Martin & Tate, 2001; Davidson, 2000)

Projektni management – namen, narava, cilji…

By Aljaž

On December 12, 2010

In Management

V literaturi najdemo veliko različnih prikazov oziroma obrazložitev racionalnega managementa projektov. Največkrat ga opredelijo:

kot proces (planiranje, organiziranje, vodenje, kontroliranje – prvi prispevek)
s področji delovanja (management obsega, časa, stroškov, kakovosti, virov… prejšnji prispevek)
z veščinami, ki naj bi jih obvladoval vrhunski manager projekta (tehnične, vedenjske… kar bom predstavil v enem od kasnejših prispevkov)

Poleg tega nekateri še posebej poudarjajo vlogo, pristojnosti, odgovornosti in naloge projektnega managerja, kar pa bom predstavil naslednjič.

Pri posameznih avtorjih sem naletel tudi na pojme, kot so “principi”, “namen” in “narava” projektnega managementa, a večinoma so bile opredelitve pojmov podobne vsebinam, ki sem jih navedel v zgornjih alinejah. Namen je Po Harrisonu in Locku (2004) na primer uresničitev vseh (dokaj zahtevnih) zahtev projekta, ne glede na tveganja, ki so povezana z nedomačim ali celo sovražnim okoljem. Zakaj ne bi bil to cilj?

Narava projektnega dela poudarja delov timih – projektni management je v bistvu doseganje ciljev s pomočjo sodelavcev, kar zahteva konstruktivne medosebne odnose med vsemi udeleženci projekta. Rozman (2008) pa kot pomemben vidik managementa poudarja usklajevanje in odločanje. Njegova opredelitev: po vsebini je management projekta usklajevanje (tehnično razdeljenega dela, pa tudi vseh drugih razmerij med seboj in z okoljem, v prostoru in času); po namenu proces planiranja, uveljavljanja in kontroliranja (= zagotavljanje smotrnega delovanja zaposlenih), in po metodi proces odločanja (odloča o načinu izvedbe, aktivnostih, ocenah trajanja, izvajalcih, rešitvah problemov…).

Še največ avtorji pišejo o ciljih projekta, o čemer (v povezavi z namenom) sem že pisal, v prejšnjem prispevku pa sem tudi že omenil trikotnik projektnega managementa: kakovost – stroški – čas, s katerim največkrat opredelijo cilje. Zanimivo je, da ima omenjen trikotnik po navedbah različnih avtorjev različne nazive: omejitve projekta, cilje projekta ali cilji projektnega managementa. Ker so “trikotniki” dokaj različni, jih prikazujem na spodnji sliki.

Cilji / omejitve projektnega managementa po različnih avtorjih

viri: Lock 2007, Kezner 2009, Lewis 2007, Wysocki 2009

Osebno vsekakor ostajam na opredelitvi ciljev, kot sem jo navedel na koncu osmega prispevka, pri čemer ne vidim razlike med cilji projekta in cilji projektnega managementa. Avtorji “trikotnike” večinoma razlagajo z omejenostjo navedenih dejavnikov. Na primer: cilj managerja je, da projekt izpelje z omejenimi viri. Kerzner navaja šest najpomembnejših vrst virov: denar, zaposleni, oprema, zmogljivosti, material, informacije / tehnologija; pri čemer izpostavi še ovire na poti k ciljem: kompleksnost, specialne zahteve naročnika in spremembe le-teh, organizacijske spremembe, tveganja, tehnološke spremembe, vnaprejšnje planiranje in cenitve.