Projektni management

Blog, debatni večeri, raziskave, knjiga…

Tradicionalni in ciklični projektni življenjski cikel

V naslovu sem namenoma uporabil besedo “tradicionalni”, namesto “slapovni” (ang. waterfall), katerega sicer uporablja večina promotorjev agilnih pristopov. Razlog je v tem, da v podjetju, v katerem sem delal v času »informacijske revolucije«, že v zgodnjih 90-tih nismo več uporabljali klasičnega slapovnega pristopa ampak (delno) sočasnega, kar pomeni, da so se sicer zaporedne faze prekrivale. Lahko bi rekli, da je bil v slovenski praksi klasični »waterfall« že zdavnaj »iz mode«, ko se je pojavil agilni manifest…

Dilemo glede poimenovanja »ne-agilnega« pristopa pa so razčiščevali tudi avtorji priročnika Agile practice guide (PMI, 2017). Ti poleg slapovnega omenjajo še pojme, kot so plansko usmerjan (ang. plan driven) in serijski (ang. serial), priporočajo pa uporabo pojma predictive, s katerim pa imam sam nekaj težav glede prevoda. Napovedni, predvidljivi…? V komentarju bi bil vesel kakšnega vašega predloga 😊.

Sicer pa literatura poleg agilnega in tradicionalnega življenjskega cikla projekta (PMLC, project management life cycle) omenja še dve vrsti, o čemer sem nekaj pisal že pred leti. Takrat sem povzel Wysockega (2009), tu pa se ponovno naslonimo na Agile practice guide, ki omenja še:

  • ponavljajoč pristop (ang. iterative), ki omogoča oziroma zagotavlja povratne informacije o nedokončanem delu za izboljšanje in spreminjanje le-tega, ter
  • postopen pristop (ang. incremental), ki vsakem ciklu zagotovi delujoč delni izdelek, ki ga je že mogoče uporabiti.

Agilni pristop pa naj bi bil tako ponavljajoč, kot postopen – pristop, ki s pomočjo povratnih informacij stalno dostavlja uporabne (pol)izdelke.

Kontinuiteta življenjskih ciklov projektov

Življenjski cikli projektov (Agile Practice Guide, PMI, 2017)

Poglejmo še, v katerih primerih bi bila najbolj smiselna uporaba posameznih pristopov. Kot je prikazano na sliki, naj bi izbira slonela na dveh dejavnikih: možnosti dobav oziroma uporabnosti vmesnih rezultatov (oz. pogostosti dobave le-teh) ter stopnji spremembe oz. novosti, ki jo prinaša projekt.

Tradicionalni pristop naj bi se tako uporabljal, ko so rešitev in zahteve dokaj jasno določene in se naj ne bi veliko spreminjale, pri tem pa delnih rezultatov uporabniki ne morejo koristiti. Wysocki (2009) še navaja, da so projekti rutinski in ponovljivi, uporabljajo pa se preizkušene metode. Vse navedeno bi vsekakor veljalo za gradnjo in druge inženiring projekte.

Ponavljajoč pristop je uporaben za projekte, ko rešitev in zahteve niso jasno dorečene, glede na izkušnje iz preteklih projektov pa tim lahko pričakuje tudi kar nekaj sprememb. Wysocki dodaja, da tim pri tem dokaj dobro pozna možne alternative rešitev. Tudi pri tem pristopu pa delnih rezultatov ni mogoče koristiti. Glede na navedeno, je pristop primeren za razvoj izdelkov z malo neznankami (kjer ni potrebnih raziskav), sploh pri prilagajanju izdelkov po željah kupca.

Postopen pristop naj bi se koristil, ko je možno koristiti delne rezultate, zahteve pa so dokaj jasno določene in se naj ne bi veliko spreminjale. Lahko bi rekli, da je je uporaben za izobraževanje, razvoj (nekaterih) storitev.

Glede na vse navedeno naj bi torej agilen pristop uporabili, ko rešitev in zahteve niso jasno dorečene, delne rezultate pa lahko koristimo, poleg tega pa mogoče niti vnaprej ne vemo, katere metode bomo uporabili pri delu. To je vsekakor značilno za raziskovalne projekte, v novejšem času pa seveda za razvoj programske opreme (kjer so se agilni pristopi tudi razvili in uveljavili), predvsem spletnih rešitev in aplikacij za telefone. Vsekakor je v tem primeru možno koristiti rešitve z osnovnimi funkcijami, dodatne pa se razvijajo postopno, glede na želje (in ideje) uporabnikov.

Ali je povsem agilen pristop uporaben tudi za razvoj izdelkov? Mogoče delno kombiniran, v začetku tradicionalni, nato agilen? Več o tem bom zapisal v knjigi, čakam tudi še na rezultate raziskave, ki je odprta še do konca meseca. Vse skupaj nas najbrž tudi zanima, kateri pristop bi bil pravi za druge vrste projektov … organizacijske (interna reorganizacija ali tista, povezana s prevzemi in združitvami), kateri za organizacijo dogodkov. Tu so še marketinški projekti, pa produkcija televizijskih oddaj, snemanje filmov…

Principi v ozadju Agilnega manifesta

Mnogi avtorji in promotorji agilnosti trdijo, da je agilna miselnost pomembnejša sistematičnega pristopa in orodij, pri čemer naj bi miselnost gradili na vrednotah (Agilni manifest), principih in (dobrih) praksah (glej sliko). Danes si podrobneje poglejmo principe in jih pokomentirajmo (citirani principi so napisana s poševno pisavo):

(1) Naša najvišja prioriteta je zadovoljiti stranko z zgodnjim in nepretrganim izdajanjem vredne programske opreme. Vsekakor se strinjamo, da je pomembno zadovoljiti naročnika, vendar pa ne na škodo lastnega zaslužka, zato moramo tu opozoriti na ustrezen pogodbeni odnos med naročnikom in izvajalskim timom. Seveda pa nas tukaj prepriča drugi del principa, kar lahko ocenimo kot največjo prednost agilnega pristopa – da je del razvite programske opreme že možno uporabljati na koncu prvega cikla, da vsak naslednji cikel prinese novo uporabno vrednost, in da več ciklov prinaša več koristi za naročnika. Žal pa je to možno le pri določenih tipih IT projektov, še težje pa pri drugih vrstah projektov.

(2) Sprejemamo spremembe zahtev, celo v poznih fazah razvoja. Agilni procesi vprežejo tovrstne spremembe v prid konkurenčnosti naše stranke. Spreminjanje programske opreme je praviloma veliko cenejše, kot spreminjanje izdelka ali stavbe, čeprav tudi pri določenih vrstah IT projektov nekaj sprememba lahko povzroči kar obsežno popravljanje dotedanje programske kode, pa tudi dodatne napake v delovanju programa, ki jih je težko odkriti in popraviti. Sicer pa pri vseh vrstah projektov velja, da se vsaka sprememba sprejme, v kolikor prinese zadosti koristi v primerjavi s stroški spremembe, ter seveda, da se tako stroški kot koristi ustrezno porazdelijo med naročnika in izvajalce.

(3) Delujočo programsko opremo izdajamo pogosto, znotraj obdobja nekaj tednov, do nekaj mesecev, s preferenco po krajšem časovnem okvirju. Tako, kot smo napisali že pri prvem – tudi temu principu, ki prikazuje način dela na projektu, ni oporekati. Vprašanje je le, ali je ta način dela možen na ostalih tipih projektov.

(4) Poslovneži in razvijalci morajo skozi celoten projekt dnevno sodelovati. Poslovneži? Žal ne vemo, ali to pomeni uporabnike (v originalu piše »business people«) ali managerje v podjetju izvajalca. Načeloma pa to razumemo tako, da razvijalci, z namenom popolne zadovoljitve želja naročnika in doseganja visoke kakovosti proizvoda, stalno in pogosto preverjajo, če so na pravi poti. To se nam zdi (do neke mere) smiselno. Po drugi strani pa – če nekomu delegiramo neko nalogo, potem pričakujemo, da nas ne bo vsakih nekaj ur spraševal, če je prav razumel zahteve in če je njegova ideja o rešitvi ustrezna. Način dela zna biti kar obremenjujoč za naročnika in vprašanje je, ali je res potrebno tako pogosto usklajevanje. Še posebej, ker se znajo ti projekti kar vleči.

(5) Projekte gradimo okrog motiviranih posameznikov. Omogočimo jim delovno okolje, nudimo podporo in jim zaupamo, da bodo svoje delo opravili. Kdor vsaj malo pozna motivacijske teorije in priporočila glede vodenja ljudi in (projektnih) timov, bo vedel, da brez tega ne gre tudi pri »tradicionalnem« pristopu. Vsekakor temu principu ni oporekati, a ni nikakršna novost.

Miselnost PMBOK
Agilna miselnost (Agile practice guide, 2017)

(6) Najboljša in najučinkovitejša metoda posredovanja informacij razvojni ekipi in znotraj ekipe same, je pogovor iz oči v oči. Podobno kot pri prejšnjem principu moramo tudi tukaj opozoriti na priporočila stroke glede komuniciranja v projektu, ki poudarjajo visoko vrednost osebnega verbalnega komuniciranja. Teorije o vodenju, motiviranju in komuniciranju med sodelavci so se resneje začele razvijati v 60-tih prejšnjega stoletja, možno pa je, da jih tehnično izobraženi strokovnjaki prej niso poznali. Sicer pa je res, da je pogovor (vsaj po telefonu ali drugih medijih, če govorimo o virtualnih timih) najboljši način komuniciranja, tako za iskanje idej, usklajevanje dela, reševanje medosebnih nesoglasij, ustvarjanje visokega delovnega vzdušja, ipd. Moramo pa opozoriti, da preveliko število sestankov lahko ljudi spravlja v slabo voljo (ker jim velikokrat prekinjajo ustvarjalno delo), zato je za manj pomembne informacije smiselno koristiti tudi e-pošto ali projektni informacijski sistem.

(7) Delujoča programska oprema je primarno merilo napredka. Ta princip je nadgradnja prvega in tretjega in je ponovno povezan z glavno prednostjo agilnega pristopa (možnost koriščenja delnih rezultatov), zato mu ni oporekati. Tudi kontroliranje projekta je enostavneje, čeprav je vprašanje, ali je sploh smiselno, saj taki projekti načeloma nimajo nedvoumno določenega končnega roka – resneje se lahko kontrolira le izvedba posameznega cikla.

(8) Agilni procesi promovirajo trajnostni razvoj. Sponzorji, razvijalci in uporabniki morajo biti zmožni konstantnega tempa za nedoločen čas. Ta princip pa je najbolj sporen z vidika projektnega pristopa. Ena od osnovnih definicij projekta je, da je le-ta časovno omejen – če ni vnaprej opredeljenega končnega roka, potem to ni projekt! Lahko pa bi rekli, da je vsak cikel svoj projekt (saj ima jasno določen končni rok, podrobne specifikacije, plan aktivnosti po izvajalcih…), pri čemer naročnik in projektni tim na začetku sodelovanja podpišeta pogodbo (namero) o dolgoročnem sodelovanju in se dogovorita, da se stroški in plačila obračunavajo za vsak cikel posebej, ter da se sodelovanje lahko zaključi po kateremkoli ciklu. Pa še ta dilema: kako naj se izvajalsko podjetje dogovarja za nov posel, če ne ve, kdaj se bodo zaključili trenutni projekti in bodo njihovi zaposleni spet prosti za prevzem novih aktivnosti?

(9) Nenehna težnja k tehnični odličnosti in k dobremu načrtovanju izboljša agilnost. Tale stavek bi lahko razumeli v obe smeri – da tehnična odličnost izboljša agilnost (= prilagodljivost, kar nam nekako ni razumljivo) ali da agilno razmišljanje prispeva k tehnični odličnosti. Kakorkoli že, tehnična odličnost je osnova kakovosti dela in končnih proizvodov, kar velja tudi za »tradicionalni« pristop. Opozorimo pa naj na »previsoko« kakovost – iskanje tehnične dovršenosti lahko zelo podaljša in podraži projekt (nekateri razvijalci vedno mislijo, da bi nekaj lahko naredili še bolje in se lahko izgubijo v spirali nenehnih izboljšav svojih rezultatov)! Učinkovit tim naj bi naročniku zagotovil le tisto, kar ta zahteva – vsa nadgradnja bi lahko bila izguba časa in denarja, če naročnik ni pripravljen plačati višje kakovosti.

(10) Preprostost — umetnost zmanjševanja količine nepotrebnega dela — je bistvena. Ta princip bi bil lahko deloma kontradiktoren s prejšnjim, vendar pa glade na proučevanje drugih virov predpostavljamo, da avtorji tu mislijo na preprostost pri planiranju načina izvedbe cikla (kako čim bolj učinkovito doseči zastavljene cilje cikla). Delno pa bi se ta princip nanašal tudi na poenostavljanje zahtev naročnika – da mu projektni tim glede na namen in potrebe lahko predlaga enostavnejšo rešitev. Oba vidika seveda nista tuja »tradicionalnim« timom, a vsekakor se strinjamo, da je zadnja dva principa smiselno večkrat izpostaviti, da zagotovimo ustrezen način razmišljanja in delovanje udeležencev projekta.

(11) Najboljše arhitekture, zahteve in načrti izhajajo iz tistih ekip, ki so samo-organizirane. Bi lahko rekli, da »tradicionalni« projektni tim ni samo-organiziran, ne glede na to, kako kompleksen je projekt in o katerem nivoju tima govorimo? No, malce sumimo, da avtorji tukaj govorijo o tem, da timi ne potrebujejo managerja, saj si znajo sami organizirati svoje delo. Predpostavljamo, da vemo, od kod ta predlog: pogoj za odličnost managementa je tudi (ali predvsem) odličnost njegovega vodenja, problem pa seveda nastane tam, kjer je manager odtujen od tima, dela svoje plane ne glede na mnenje članov tima, se ukvarja predvsem z administracijo … ampak to je problem posameznikov, ne pa »tradicionalnega« pristopa. Sicer pa ideja mogoče ni tako neumestna, pri tem pa bi opozorili na ugotovitve raziskav, da se v vsakem timu, kateremu se na začetku ne določi vodje, sčasoma spontano uveljavi »neformalni« vodja, ki prevzame večino siceršnjih nalog managerja (vodi planske sestanke, usklajuje delo, opozarja sodelavce na zamude, ipd).

(12) V rednih časovnih razdobjih ekipa išče načine, kako postati učinkovitejša ob rednem prilagajanju svojega delovanja. Temu principu seveda ni oporekati – to naj bi bilo vedno vodilo projektnih timov in menimo, da bi si timi tudi v sklopu daljših »tradicionalnih« projektov morali večkrat vzeti čas, da se pogovorijo o svojem delovanju in poiskati kakovostnejše in učinkovitejše pristope.

Opomba: principe smo brez spreminjanja prepisali z uradne strani Principi v ozadju agilnega manifesta, zato so mogoče nekateri izrazi (prevodi) drugačni, kot jih sicer uporabljamo v prispevkih tega bloga.

Agilno!?! … prihodnost ali modna muha?

O začetkih agilnih pristopov pri razvoju programske opreme sem pisal že leta 2011, kjer sem tudi omenil Agilni manifest (2001), ki ga mnogi smatrajo za začetek agilnega pristopa. No, v resnici so mnogi agilno delovali že prej (najbrž poznate pojme, kot so vitka proizvodnja, vzporedni inženiring, Kanban, ipd.), Gibbs (2006) omenja, da so pionirji agilnega pristopa z iterativnim razvojem programske sledili vzoru Toyotine vitke proizvodnje, njihov namen pa je bil znižanje stroškov nepomembne administracije in krajšanje zamudnih procesov načrtovanja. Vendar pa so avtorji manifesta začeli pristop promovirati in uveljavljati bolj načrtno in predvsem celovito (glej sliko). Seveda jim je pri tem »pomagal« hiter razvoj tehnologije, svetovnega spleta, platfortm, ipd., kar je imelo za posledico neskončno število sprememb (in želj po spremembah), in ker so spremembe ena največjih groženj učinkoviti izvedbi in uspešnosti projektov, je bila želja po drugačnem projektnem pristopu še toliko močnejša.

Seveda so se z »agresivnejšim marketingom« gorečih zagovornikov pojavili tudi prav tako goreči nasprotniki – prvi bi agilno gradili tudi hiše, drugi pa trdijo, da je agilno le potuha (samo, da ni potrebno planirati) in sinonim za nedorečeno in neorganizirano. Najbrž je resnica nekje vmes, odvisno od vrste dejavnikov: tipa in obsežnosti projekta, velikosti tima, števila vključenih strok, več-projektnega okolja, pogodbenih razmerij… Zanimiva pa je tudi trditev zagovornikov, da v prihodnosti ne bo več projektnih managerjev in da se bodo timi organizirali sami. Dokaj »bogokletna« trditev, kajne, sploh če ob tem omenimo še to, da naj bi bil za uspeh projekta odgovoren naročnik projekta (angl. Product Owner) in ne tim ali kdo od odgovornih za izvedbo. Kar veliko tem za raziskavo, kajne.

Pregled literature pa je pokazal, da stroka še ni povsem poenotena glede koristi, ki jih prinaša agilnost na ravni izvajanja projektov. Še več, raziskave kažejo, da se navkljub prepričanosti zagovornikov agilnosti stopnjuje predvsem uporaba hibridnih pristopov (Walenta, 2017). Komus je s sodelavci (2016/17) raziskoval razvitost pristopa v evropskih združbah, pri čemer so ugotovili, da le dvajset odstotkov anketiranih organizacij sledi povsem agilnemu pristopu, oseminšestdeset odstotkov ima razvite hibridne pristope kombinacije agilnih in tradicionalnih konceptov, dvanajst odstotkov pa še vedno uporablja »slapovni« pristop.

“Agilno” je splošni izraz za številne pristope
(Agile Practice Guide, PMI, 2017)

Načeloma ni dvoma o tem, da pristop zagotavlja višjo kakovosti rezultatov in da končni proizvodi bistveno bolje zadostijo željam (in ne le zahtevam) naročnika, vendar pa raziskave še niso nedvoumno potrdile (ali ovrgle) trditev zagovornikov agilnosti – da pristop zagotavlja učinkovitejšo izvedbo projekta, da so projekti krajši in cenejši. Bistveno prednost agilnega pristopa vidimo na prihodkovni strani, ker naj bi bili – če se združbe držijo priporočil stroke – uporabni tudi že delni proizvodi posameznih ciklov projekta.

Naj na koncu dodam še kritiko mlajšim »strokovnjakom«, ki ob predstavitvah agilnih pristopov vehementno zavračajo vse, kar je bilo prej. S svojim načinom bolj škodijo uveljavitvi pristopa, pri tem pa pridno ustvarjajo goreče nasprotnike. Sploh izkušenejši projektni managerji (ki so se tudi pri tradicionalnem projektnem pristopu že mnogokrat srečali z agilnostjo) se sprašujejo, kako lahko nekdo, ki nečesa ni nikoli izkusil v praksi, ocenjuje tisto kot neprimerno. Na podlagi člankov in izkušenj drugih? Pa še nekaj, kot sem omenil na začetku – v prvem desetletju »novejše agilnosti« se je vse nanašalo le na IT projekte in zato sprašujem IT strokovnjake – bi verjeli gradbenikom, ki bi trdili, da morate popolnoma spremeniti način dela, da je vse od prej za v staro šaro? To se namreč dogaja v obratni smeri. In tudi zaradi tega sem se lotil raziskave in obravnave agilnih pristopov v svojem blogu.

Raziskava in nova knjiga: AGILNO !?

Raziskava >>>

Pozdravljeni,

kmalu bo deset let od mojega zadnjega prispevka v tem blogu in od izida moje knjige, zato sem se odločil, da je čas za nadaljevanje – tako objav na blogu, kot nove knjige.

Kmalu po izidu prve knjige sem bil na neki konferenci izzvan, da zagovarjam “svoj tradicionalni” pristop napram modernemu agilnemu, zato sem po tistem začel resno raziskovati agilne pristope, tako v literaturi, kot v praksi. Ugotovitve prvega proučevanja agilnih pristopov sem predstavil na ZPM forumu 2013 (tu si lahko preberete moja takratna razmišljanja), v istem letu izvedel krajšo raziskavo zametkov agilnosti pri projektih razvoja novih izdelkov (članek).

Od takrat sem se z agilnostjo redno srečeval predvsem v praksi, pri tem pa naletel tako na goreče zagovornike, kot na (prav tako goreče) nasprotnike. Mnogo drugih pa je priporočalo kombinacijo pristopov. In tako so vsi ti sogovorniki krepili mojo radovednost in željo, da ugotovim, kdo ima bolj prav, kje so razlike med vrstami projektov, med strokami, vrstami organizacij, branžami…

Lani sem se dokončno odločil, da je čas za resno raziskavo, rezultat raziskovanja bo nova knjiga, ki bo obravnavala:

  • agilnost na treh ravneh delovanja – posameznikov, projektov in podjetij (ter drugih organizacij),
  • smiselnost kombiniranega pristopa (agilno tradicionalnega), ter
  • pogodbena razmerja in način sodelovanja med naročniki in izvajalci.

Vabim vas, da se vključite v raziskavo in izpolnite anketo, ter s tem pomagate h kakovosti moje knjige, posredno pa s svojimi izkušnjami pomagate vsem, ki se v Sloveniji ukvarjajo s projekti.

Hkrati vas prosim, da vabilo posredujete tudi svojim sodelavcem, kolegom in znancem, ki se ukvarjajo s projekti in strategijami.

Povezava na anketo >>>

Ker gre za pomembno in zelo obsežno področje, anketa ni najkrajša, a jo lahko izpolnjujete v več korakih (dotedanji rezultati se bodo shranili). Za malo motivacije pa so tu »nagrade«. Vsi, ki boste izpolnili anketo (in pustili kontaktni naslov) boste:

  • prejeli poročilo s statistično obdelanimi ugotovitvami,
  • vabljeni na on-line debatne večere o posameznih vsebinah (vsake 3 tedne, od 21.5. naprej),
  • povabljeni na 3-urno predavanje ob izidu knjige,
  • deležni 25 % popusta ob nakupu knjige.

Izžrebali pa bomo tudi 15 anketirancev, ki bodo knjigo dobili brezplačno!

Povezava na anketo >>>
Anketa bo aktivna do 22.5.

Že vnaprej se vam zahvaljujem za izpolnitev ankete! Če boste naleteli na kakšno težavo ali dilemo, mi prosim pišite na aljaz@projekt35.si.

In seveda, istočasno s pisanjem knjige bo spet zaživel moj blog, kjer bom tedensko objavljal povzetke posameznih tem, ki bodo sicer podrobneje obravnavane v knjigi. Prvi prispevek lahko pričakujete že v naslednjem tednu…

O projektnem blogu (ki ni čisto pravi blog)

Teh nekaj uvodnih vrstic namenjam vsem tistim, ki ste na blog naleteli šele po letu 2011, v katerem je nastala večina prispevkov.

Blog je začel nastajati oktobra 2010, kot del projekta priprave knjige o projektnem managementu. Glavni namen pisanja bloga je bil pomoč tistim, ki se v praksi srečujejo s projekti, pa niso nikoli uspeli pridobiti nikakršnih teoretičnih znanj s področja managementa projektov. Seveda branje priporočam tudi izkušenim praktikom, predavateljem in svetovalcem, pa tudi študentom… Ne nazadnje upam, da bodo predstavljene vsebine prispevale k uveljavitvi stroke v slovenskem prostoru ter posledično dvignile uspešnost projektov.

V 88 objavljenih prispevkih »male šole projektnega managementa« so obrazloženi osnovni pojmi projektnega managementa, prikazane vloge tipičnih udeležencev projekta, predstavljeni pristopi k snovanju, pripravi, izvedbi ter zaključevanju projektov. Našli boste nasvete, kako voditi projektni tim, prikazani so najprimernejši načini organiziranja projektov, ter izpostavljene priporočljive lastnosti in veščine projektnega managerja. Prikazano je tudi, kako v podjetju zagotoviti projektom naklonjeno okolje.

Prispevki so nastajali na podlagi proučevanja svetovne literature, lastnih izkušenj, raziskav v Sloveniji in raznih diskusij, s konferenc in mesečnih debatnih večerov, ki so bili del projekta priprave knjige. Z izidom knjige se je projekt torej končal. Novih prispevkov načeloma ne načrtujem do začetka priprave druge izdaje knjige, kjer bo več napisanega o managementu portfelja projektov, o posebnostih različnih tipov projektov, o standardih s področja projektnega managementa…

Še vedno pa vas vabim, da komentirate posamezne prispevke (predstavite svoje izkušnje) ali postavite dodatna vprašanja. Lahko v blogu ali pa po e-pošti: aljaz@projekt35.si

Seveda je dileme še najbolje predebatirati v živo. Na naslednjem ZPM forumu?


Zrelostni modeli projektnega managementa

V začetnih prispevkih tega bloga sem v dveh prispevkih prikazal pomembnost stalnega spreminjanja združbe za doseganje konkurenčnosti in preživetje. V sklopu strateškega managementa sem poudaril, da se mora združba primerjati z drugimi, da bi ugotovila, na katerih področjih bi se lahko še izboljšala. Seveda pa konkurenti vsepovprek ne razlagajo, kako delujejo, ker na tem tudi gradijo strateško prednost, zato je stroka razvila neke vrste modele, ki prikazujejo idealno stanje in korake za doseganje le-tega. Zrelostni modeli so tako dejansko alternativa primerjavi z drugimi združbami (benchmarking).

In kako delujejo? Običajno model vključuje vprašanja, na katere odgovarja (samo)ocenjevalec. Negativni odgovori nakazujejo področja, kjer bi se morali izboljšati. Modeli posamezne sklope parametrov tudi grafično prikažejo s tako imenovano »pajkovo mrežo«. Cilj združbe je, da se z dejanskim stanjem čim bolj približa robu mreže.

»Projektne« zrelostne modele smo našli tudi pri vodilnih svetovnih avtorjih (Turner, Kerzner, Wysocki). Stopnje po Kerznerju prikazujemo na sliki, Wysocki pa navaja naslednje:

  1. Obstaja nekaj metodoloških pristopov, a večinoma se timi projektov lotevajo vsak po svoje.
  2. Proces izvedbe projektov je dokumentiran in nekateri timi se ga res držijo.
  3. Proces izvedbe projektov je dokumentiran in vsi timi delajo v skladu z njim.
  4. Proces izvajanja projektov je integriran v portfelj poslovnih procesov.
  5. Proces se stalno načrtno izboljšuje.

Pri tem bi pripomnil, da pod »proces izvedbe projektov« lahko smatramo organizacijski predpis oz. poslovnik o managementu projektov, ki sem ga pred časom že predstavil.

Zrelostne ravni managementa projektov v združbi po Kerznerju (2009)

Heerkens (2002) navaja, da zrelost združbe na področju projektnega managementa opredeljujejo ustreznost organizacijskega predpisa (skladnost z stanjem, ljudje v združbi ga poznajo in se ga držijo), sposobnost timov, da realno ocenijo izvedbo projektov na začetku (realnost planov) ter učinkovitost izvedbe (povprečne zamude in podražitve projektov), uspešnost projektov (prihodkovna stran – trženje, prihranki), sposobnost združbe, da se uči na svojih izkušnjah,  prisotnost stalnih izboljšav projektnega pristopa (sistematičen prenos izkušenj in nadgrajevanje metodologije ter poslovnika).

Če bi si hoteli sami razviti model ocenjevanja, ki bi bil hkrati okviren plan razvoja pristopa v združbi, je to najlažje s pripravo matrike, kjer imate navpično posamezne faze projekta (snovanje, priprava, izvedba, zaključek), vodoravno pa področja PM, kot smo jih prikazali v enem od prvih prispevkov o projektnem managementu oz. na sliki. V »presečišča« oz. polja tabele pa opredelite »idealno stanje« (= teorija) ter nekaj vmesnih korakov… (Crawford 2011)

Vseeno pa se je najbrž bolj smiselno držati že razvitih modelov. Avtorji največkrat omenjajo dva: The capability maturity model integration (CMMI), ki ga je za področje IT projektov razvil The Software Engineering Institute (SEI), ter The organizational project management maturity model (OPM3), katerega avtoji so člani PMI. Če iskalna pojma vnesete v Google, boste našli ogromno slik in pojasnil, npr. smmi1, cmmi2, opm3

Projektna pisarna (PMO)

Projektna pisarna je v osnovi »podporni oddelek v službi vodstva združbe in projektnih managerjev«, a v literaturi in praksi ni enoznačno opredeljena. Oblika, naloge, zaposleni in njeno organizacijsko mesto se razlikujejo glede na velikost združbe, število in vrste projektov ter stopnjo projektne organizacijske kulture. V slovenščini se uporablja izraz »projektna pisarna«, medtem ko tuji avtorji večinoma navajajo izraz project management office (zaradi česar bomo v nadaljevanju uporabljali mednarodno prepoznavno kratico PMO).

 Najpogostejše naloge PMO v ameriških združbah ob koncu 20.stoletja

Vir: Block & Frame, 2001; odstotek anketirancev, ki so potrdili opravljanje naloge PMO

Glede na položaj v hierarhiji združbe stroka najpogosteje omenja tri ravni PMO – a) administrativno  kontrolna pisarna enega projekta; b) projektna pisarna poslovne enote, ki skrbi predvsem za usklajevanje obremenitve ljudi (skupnih virov) večjega števila projektov; ter c) strateška projektna pisarna, štabni oddelek blizu vodstva združbe, kot svetovalno telo pri izbiri in nadzoru projektov ter uveljavljanju projektnega načina dela v združbi. Na različnih ravneh ima PMO različne funkcije, glede na te pa tudi različne zaposlene. V PMO so sicer lahko zaposleni skrbnik projektov (manager PMO), projektni managerji in koordinatorji, skrbnik projektnega informacijskega sistema, analitik  in administrator projektov.

Najpogostejše naloge PMO v slovenskih združbah leta 2006

52 od 137 združb je navedlo, da imajo v združbi vzpostavljeno PMO

Najnižja raven nalog PMO je omejena na administrativno podporo (običajno enemu večjemu projektu). Druga raven vključuje naloge, povezane z zagotavljanjem uspešnosti projektov v združbi (center odličnosti – razvoj in uveljavljanje metodologije, izobraževanje in mentorstvo, vzdrževanje baze znanja, skrb za projektno kulturo, nadzor projektov), tretja raven pa vključuje tudi management projektov. Najvišja raven funkcionalnosti PMO je skrb za strateški razvoj združbe – spremljanje ter analiziranje okolja in podjetja, oblikovanje strateških smernic podjetja, uresničevanje strategij s pomočjo projektov (priprava strateškega in operativnega plana ter izvedba  projektov) ter strateški nadzor.

V prvem odstavku sem navedel, da je pisarna »podporni oddelek v službi vodstva združbe in projektnih managerjev«, zato za konec še nasvet tistim, ki razmišljajo kakšne vrste PMO uvesti v združbo in kako uveljaviti njeno poslanstvo. Za začetek obiščite managerje projektov in jim postavite enostavno vprašanje: »kaj vam gre najbolj na živce pri managementu projektov in bi to za vas mogoče lahko naredila projektna pisarna«. Nato se oglasite pri vodstvu in jih vprašajte: »Katere informacije bi radi imeli o poteku projektov v združbi, pa jih nimate časa poiskati?«

Projektni informacijski sistem (PMIS)

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

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

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

Vsebinska področja PMIS

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

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

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

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

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

Projektna organizacijska kultura

Projektno organizacijsko kulturo sem na kratko omenil že dvakrat. Prvič sem jo uvrstil med najpomembnejše razloge za neučinkovito izvajanje projektov, in drugič, ko sem predstavil najpomembnejše gradnike sistemske podpore projektom. V tem prispevku bom podrobneje predstavil organizacijsko kulturo, prikazal posebnosti projektom (ne)naklonjene kulture v združbi in izpostavil najbolj vplivne dejavnike projektne kulture.

Organizacijska kultura naj bi bila po mnenju strokovnjakov ena pomembnejših »gonilnih sil« združbe in tudi neke vrste konkurenčna prednost.  Najpogosteje se odraža v načinu izvajanja nalog zaposlenih, določanju ciljev in vodenju ljudi za dosego teh ciljev. Kultura vpliva na sprejemanje odločitev, mišljenje, na občutek in ravnanje pri odzivanju na priložnosti in nevarnosti. Prav tako vpliva na izbiro ljudi za opravljanje nalog, kar spet vpliva na izvedbo. Kultura je zakoreninjena v ljudeh in podzavestno vpliva na njihovo vedenje. Po domače bi kulturo lahko opredelili z besedami: “Tako pri nas delamo!” (Lipičnik, 1993) ali “Način, kako se stvari pri nas naredijo!” (Lewis 1995).

Avtor ene bolj poznanih opredelitev organizacijske kulture, Schein (1988), navaja, da je kultura sestavljena iz treh ravni:

  • najbolj vidna je raven vedenja in dejanj (ki kaže, kaj skupina počne, ne pa zakaj),
  • drugo raven predstavljajo vrednote, ki v veliki meri določajo vedenje (vendar jih neposredno ne moremo opazovati in meriti)
  • tretja, najgloblja raven, pa vključuje predpostavke in prepričanja; poznavanje teh dveh dejavnikov nam pomaga razumeti kulturo, a ju je težko preučevati.

Vplivni dejavniki projektne organizacijske kulture

Organizacijska kultura vpliva na izvedbo projekta na dva načina. Prvič, kultura naj bi na podlagi dogovorjenih pravil (organizacijski predpis) zagotavljala urejenost delovanja, neustrezna kultura pa pomeni, da lahko vsak posameznik »dela po svoje« in je zaradi tega potrebno mnogo več usklajevanj in popravkov. Skratka, slaba kultura povzroča motnje pri delu, kar podaljšuje izvedbo projekta.

In drugič, vpliva na motiviranost članov tima. Če le-ti ne čutijo podpore projektu in njihovemu delu s strani celotne združbe, če večkrat naletijo na ovire pri delu, ipd., potem je delovna vnema lahko dokaj nizka, v projektu ne vidijo izziva ali celo smisla, kakovost dela je nižja… Lahko pride do dveh vrst »odziva« na neustrezno kulturo: ali jim je vseeno, kaj se bo s projektom zgodilo in so zaradi tega manj produktivni, ali pa so zelo slabe volje, ker združba ne prepozna njihovega truda, pa veliko časa posvetijo razmišljanju o svojem »trpljenju« (namesto, da bi se posvečali delu), poleg tega zaradi stresa lahko delajo več napak.

Na sliki so prikazani najvplivnejši dejavniki projektne kulture, katere smo leta 2006 tudi vključili v raziskavo v 135 slovenskih podjetjih. Z analizo vpliva pomerjenih dejavnikov na učinkovitost izvedbe smo ugotovili, da se zaradi slabe projektne organizacijske kulture projekti lahko podaljšajo do 5%, projekt pa se lahko podraži do 3%. Še močneje pa vplivajo na motiviranost članov tima.

Zakaj se preučevane skupine vplivnih deležnikov projekta vedejo, kot se, nismo raziskovali. Pomembno pa je zavedanje, da zelo težko spreminjamo vedenje, če prej ne poiščemo vzrokov zanj in poskusimo vplivati na te vzroke. Govorimo seveda o vrednotah, še bolj pa o prepričanjih in predpostavkah. Tokrat pa lahko »ponudim« le nekaj idej za izboljšanje projektne kulture, ki sem jih našel pri tujih avtorjih:

  • managerjem projektov je potrebno zagotoviti ustrezne pristojnosti in jih tudi upoštevati;
  • z dogovorom vseh vpletenih deležnikov je potrebno postaviti smernice sodelovanja projektnih in funkcijskih managerjev:
  • projektna organiziranost mora postati del celotne organiziranosti podjetja, (tudi) linijski managerji morajo nadrejenim poročati o poteku projektov, ki se izvajajo v njihovem oddelku:
  • iskanja bodočih managerjev projektov naj bo stalen proces, neizkušenim pa je priporočljivo omogočiti pomoč “mentorja”.

Organizacijski predpis / poslovnik managementa projektov

Kot sem nakazal že v prejšnjem prispevku, se poslovniki pripravljajo z namenom, da se dorečejo in nato uveljavijo pravila (so)delovanja v sklopu nekega oddelka ali procesa. Strokovnjaki s področja organizacije navajajo, da poslovniki služijo predvsem ohranjanju želenega načina delovanja, kljub fluktuaciji zaposlenih, kar še posebej velja za projekte, saj vsak projekt praviloma izvaja drugače sestavljen projektni tim. Poslovnik lahko pokriva vse tipe projektov, ki se izvajajo v združbi, lahko pa izdelajo različni poslovniki za posamezne vrste projektov.

Vsebina: poslovnik naj bi obravnaval celoten projekt – od pobude, preko snovanja, potrditve, preko priprave in izvedbe do administrativnega zaključka. Opredelijo se tipične faze projekta, mejniki, sklopi aktivnosti in odločitveni dogodki, udeleženci in njihove vloge, prosojnosti in odgovornosti – kdo sprejema odločitve, kdo zagotavlja informacije, kdo pripravi in odobri posamezne vrste dokumentov. Nadalje se opredeli kdo in kdaj izbere managerja in člane tima, kako se določajo prioritete projektov in kdo odloča o tem, ali se določen projekt sploh izvede ali ne.

Primer poteka snovanja projekta in vloge odgovornih

Pomemben vidik je nadzor projektov in morebitna orodja, ki služijo učinkovitejšemu nadzoru (semafor?). Opredeli se tipična organizacijska struktura (npr. šibka matrična), če naj bi veljala za vse projekte istega tipa, pri čemer se še posebej izpostavi vloga funkcijskih managerjev. V kolikor v združbi obstaja projektne pisarna (PMO), je potrebno opredeliti tudi njeno vlogo. Pa tudi morebitno povezavo projektov s strateškim razvojem

Oblika: poslovnik bo preglednejši, če bo poleg teksta vključeval grafične prikaze, predvsem diagrame potekov ključnih faz (z dokumentacijo) in matrike pristojnosti in odgovornosti (slika). V tekstu se lahko dodatno opišejo posamezne aktivnosti, odločitveni dogodki, dokumenti ter vloge ključnih udeležencev projekta, vključno s člani tima. Poslovnik lahko vključuje tudi priloge – najpogosteje so to obrazci za pripravo dokumentov projekta (predlog, naročilo, elaborat, redno in zaključno poročilo, verifikacijski zapisniki, ipd.).

Na sliki sem prikazal primer poteka procesa snovanja projekta, na desni strani pa dodal matriko pristojnosti in odgovornosti. Matrika je podobna tisti, ki smo jo obravnavali pod organizacijo projekta, le da tista velja za konkreten projekt (in je stvar dogovora na začetku projekta), medtem ko ta določa »pravila« za vse projekte (istega tipa). Druga razlika je v odgovornih osebah – v poslovniku niso navedene konkretne osebe z imenom, ampak delovna mesta oz. oddelki (kar pomeni, da je odgovoren manager oddelka).

Page 1 of 10

Powered by WordPress & Theme by Anders Norén