Category: Priprava projekta

Planiranje virov projekta

On February 19, 2011

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

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

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

Plan virov v gantogramu

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

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

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

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

Terminski plan projekta – gantogram

By Aljaž

On February 15, 2011

In Management, Pojmovnik, Priprava projekta

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

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

Primer gantograma s prikazano kritično potjo

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

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

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

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

Mrežno planiranje in kritična pot – CPM

By Aljaž

On February 11, 2011

In Management, Pojmovnik, Priprava projekta

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

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

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

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

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

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

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

Členitev projekta in izdelava seznama aktivnosti – WBS

By Aljaž

On February 10, 2011

In Pojmovnik, Priprava projekta

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

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

Primer Strukture del projekta

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

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

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

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

Priprava (zagon) projekta – planiranje in organiziranje

By Aljaž

On February 5, 2011

In Management, Pojmovnik, Priprava projekta

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

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

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

Priprava projekta – proces in dokumenti

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

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

Izbira managerja projekta

By Aljaž

On January 11, 2011

In Manager projekta, Priprava projekta, Snovanje projekta

O nalogah, veščinah in osebnostnih lastnostih managerja projekta sem že pisal, tokrat pa bi napisal še nekaj o tem, kdaj, kdo in na podlagi česa izbere managerja (bodočega) projekta. V »projektno« razvitih« združbah je to utečen postopek, še posebej če pri tem sodeluje projektna pisarna, ki sistematično spremlja projekte in ocenjuje delo managerjev projektov.

Pri odločitvi »kdaj?« moramo opozoriti na razliko med internimi in zunanjimi projekti. Pri slednjih se projekt izvede na podlagi pogodbe, ki se sklene na podlagi razpisa / povpraševanja oziroma pripravljene ponudbe. Dokler ni podpisane pogodbe, ni smiselno vlagati preveč truda v projekt, res pa je, da je potrebno pripraviti kakovostno ponudbo, z realnimi roki in ceno, ki bo pokrila stroške izvedbe. Mnogi managerji v inženiring podjetjih se pritožujejo, da tržniki vsevprek pošiljajo ponudbe, ter pridobivajo posle z nemogočimi roki. Mogoče sem prav zato naletel na podjetja, kjer se vodilni pritožujejo, da vse manj ljudi želi prevzeti projekte… Potencialni projektni manager bi moral zato sodelovati tudi že pri pripravi ponudbe, kar mu niti ne bi vzelo preveč časa, sploh če lahko za osnovo uporabi kakšen plan podobnega, že zaključenega projekta.

Pri internih projektih je priporočljivo vključiti predvidenega managerja projekta v snovanje projekta, kjer s svojimi izkušnjami poskrbi za realna pričakovanja (internega) naročnika in vodstva združbe. Kot pa sem že omenil v enem od predhodnih prispevkov, ni priporočljivo, da je manager projekta nosilec snovanja projekta in s tem tisti, ki poskuša prepričati nadrejene, da je projekt potrebno izvesti. Oziroma, kot navaja Thomsett (2002) – skrivnost odličnosti managementa projekta je, da manager projekta ni pobudnik projekta, ter da ima projekt skrbnika, ki res želi, da se projekt izpelje.

Izbira managerja (bodočega) projekta

Kdo izbere managerja projekta? Na to vprašanje bi težko odgovoril z nekim pravilom, saj je to odvisno od projektne kulture, vloge linijskih managerjev pri izvedbi projektov, vrste projekta, ipd. Nekateri priporočajo, da managerja izbere skrbnik projekta, v manjših združbah je to direktor, lahko je to usmerjevalno – nadzorna skupina (Svet projekta). Pristojnosti za izbiro ima lahko tudi projektna pisarna, sploh če je manager le-te hkrati direktor portfelja projektov. Pravila izbire imajo združbe zapisana v organizacijskem predpisu.

Ko že omenjam projektno pisarno (PMO), lahko o njeni vlogi napišem kaj več. PMO lahko po eni strani skrbi za usposabljanje projektnih managerjev, hkrati pa beleži njihove projektne (ne)uspehe. V interni bazi potencialnih managerjev projektov so zavedena njihova pretekla usposabljanja (z morebitnimi certifikati) ter zaključeni projekti, kjer je sodeloval kot manager ali član ožjega tima. Za vsak projekt se lahko nadalje zabeleži vrsta, kompleksnost, vrednost, trajanje, velikost tima…, kazalniki učinkovite izvedbe (roki, stroški), lahko pa dodamo tudi oceno s strani skrbnika in članov tima. Na podlagi teh informacij bo izbira pravega managerja prihajajočega projekta lažja in zaneslivejša.

Dejavniki izbire večinoma izhajajo iz prioritet in zahtevnosti projekta – organizacijski zahtevnejši in za združbo pomembnejši projekti se seveda zaupajo najbolj (pre)izkušenim projektnim managerjem, podobno kot to velja tudi za določitev članov ožjega projektnega tima. Dejavnike izbire sem prikazal na priloženi sliki.

Charvat (2002) v svoji knjigi navaja, da je »za večino projektov malo verjetno, da bo za managerja projekta izbran nekdo, ki dela v podjetju«. Na žalost nadalje ne opiše razlogov za to, niti ne navaja virov, na podlagi katerih je to napisal. Vseeno pa je smiselno omeniti tudi možnost »najetja zunanjega managerja«, čeprav v Sloveniji ne poznam prav veliko primerov. Mislim, da to še ni »praksa« s našem prostoru, vrhnji management še bolj zaupa lastnim kadrom, katere ima »neposredno pod kontrolo«, predvsem pa je vprašljiva odgovornost zunanjih managerjev, povezana z njihovimi pristojnostmi v združbi, kjer »gostuje«. Namreč – če projekt ne teče po planu, se lahko manager projekta izgovarja na to, da je kriva projektna kultura v združbi (ali npr. razpoložljivost kadrov), po drugi strani pa so »domači« lahko zelo nezaupljivi do zunanjih začasnih managerjev. Da ne omenjam nevoščljivosti… Sicer pa v Sloveniji tudi nisem zasledil izkušenih projektnih managerjev, ki bi ponujali te vrste storitev. Je delo pretežko ali odgovornost prevelika? Ima kdo od vas, ki spremljate blog, kakšne izkušnje s tem? Dodajte komentar…

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…

Vzroki za neuspeh projekta – snovanje in priprava projekta

By Aljaž

On November 24, 2010

In Management, O projektih, Priprava projekta, Snovanje projekta

V prejšnjem prispevku (Uspeh in učinkovita izvedba projekta) sem med drugim zapisal, da se uspešnost projekta ocenjuje z razmerjem koristi, ki jih prinese proizvod projekta, in porabljenih sredstev za izvedbo projekta. Vendar pa večina tujih avtorjev, ki govori o vzrokih za neuspeh projekta, (ne)uspeh enači z (ne)učinkovito izvedbo – z doseganjem rezultatov znotraj dogovorjenih časovnih omejitev, v okviru finančnih omejitev (predračuna stroškov) ter ob ustrezni kakovosti proizvodov. Poglejmo torej najbolj tipične vzroke za neučinkovito izvedbo projekta. Povzel sem jih po več tujih avtorjih (Andersen, Young, Wysocki, White) in seveda po lastnih izkušnjah, predvsem pa se nanašajo na neustrezno delovanje različnih udeležencev projekta.

Snovanje projekta

Prvi problem, ki je osnova za mnogo kasnejših, je neustrezna obravnava ideje oziroma predloga projekta. Kot smo zapisali v opisu faze snovanja (Faze projekta) naj bi se na začetku preverila na podlagi jasnega proizvoda projekta ocenile koristi in izvedljivost projekta.

Vzroki za neučinkovito izvedbo projekta

Predvsem pri organizacijskih projektih se dostikrat zgodi, da je projekt formalno odobren, a ga večina (predvsem linijskih managerjev) podpira »s figo v žepu«. Zaradi manjše podpore ima projekt manjšo prioriteto, manager pa težje dobi ustrezne in razpoložljive kadre. Le-ti mogoče tudi ne podpirajo projekta, kar seveda vpliva na njihovo motivacijo. Pri obravnavanju poročil o projektu se vedno znova sprašujejo o smiselnosti projekta, projektni tim pa je deležen manjše pomoči pri reševanju morebitnih problemov. Zato je pomembno, da je projekt v veliki meri skladen s strateškimi usmeritvami združbe, da so v fazi snovanja jasno opredeljene koristi projekta (za celotno združbo), vodstvo združbe pa mora pred odobritvijo zahtevati od vseh, da izrazijo in utemeljijo kakršnekoli pomisleke glede projekta.

Problemi v kasnejših fazah pa izhajajo tudi iz neusklajene taktike izvedbe – čeprav je način izvedbe ožje gledano stvar projektnega tima, naj bi bil le-ta usklajen tudi z naročnikom in s tistimi linijskimi managerji, katerih zaposleni so člani tima. V nasprotnem primeru bo pri izvajanju prihajalo do nesporazumov, neusklajenega delovanja, odpora, konfliktov, ipd.

Opozorim pa naj še na problem neustrezno definiranega proizvoda, do katerega lahko pride zaradi premalo strokovnega znanja naročnika, neusklajenosti ali zaradi premalo vključevanja končnih uporabnikov (npr. uporabnikov IT rešitve). Nedefinirane zahteve povzročijo neustrezno oceno koristi projekta, sploh pa ogromno sprememb v fazi izvedbe projekta, zato jih je priporočljivo jasno opredeliti že v fazi snovanja oziroma najkasneje v fazi priprave pred začetkom planiranja.

Priprava projekta

Neustrezno planiranje ima za posledico pomanjkljiv terminski in stroškovni plan, projektni tim pa tudi ni pripravljen na kakršnekoli ovire pri izvedbi (kaj šele, da bi te ovire »odstranil« vnaprej). Govorim seveda o površnem planu obvladovanja tveganj.

Prvi vzrok za slab plan je lahko samostojno planiranje managerja projekta, brez sodelovanja nosilcev aktivnosti oziroma nosilnih strokovnjakov za posamezna področja. »Več glav več ve!« Ta rek še kako velja za planiranje projektov. Zelo redki so (če sploh obstajajo) managerji projektov, ki poznajo vsa strokovna področja projekta do potankosti, kar je pogoj za realen plan. Sodelovanje pri planiranju tudi dvigne motiviranost izvajalcev, da bi dosegli dogovorjene (obljubljene) roke.

Plani so nerealni tudi zaradi dveh drugih razlogov – ali so člani tima pri planiranju preveč optimistični (kar se spet dogaja mlajšim in manj izkušenim) ali pa pri planiranju podležejo željam naročnika (kar velja predvsem za interne projekte), brez upoštevanja dejstva, da se projekti redko izvedejo natanko po planu. Pri tem igra dodatno vlogo projektna kultura v podjetju, kjer vodstvo velikokrat od timov zahtevajo nemogoče, le ti pa podležejo pritiskom z željo, da se izkažejo. Spet drugje pa se vsi skupaj sprijaznijo s površnim in nerealnim planom ter že na začetku projekta tudi s kasnejšo zamudo projektov, kar tudi kaže na nizko projektno kulturo. Površen plan seveda pomeni, da je premalo podroben, da so izpuščene posamezne aktivnosti ali je neustrezna ocena potrebnega dela, da ni upoštevana različna usposobljenost izvajalcev, da se zanemarijo morebitni problemi…

Na to opozarjam tudi zato, ker mnogi manj izkušeni managerji pač naredijo samo toliko plana, kot je potrebno za zadovoljitev potreb nadrejenih (nekaj rokov, okvirne stroške in glavne izvajalce), zaradi česar kasneje, med izvedbo, ne obvladujejo časa in običajno zamudijo postavljene roke. Projektni manager mora zase (in ne za nadrejene) izdelati podroben plan, ki mu bo omogočil obvladovano izvajanje aktivnosti!