Blog, debatni večeri, raziskave, knjiga…

Author: Aljaž Page 1 of 9

Raziskava in nova knjiga: AGILNO !?

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.

Raziskavo sem izvedel v maju 2020, delno je anketo izpolnilo 250 anketirancev, v celoti pa 201. Za začetek le ta informacija, da je četrtina sodelujočih navedla, da projekte izvajajo ciklično, pri čemer jih 86% pripravi plan ciklov na začetku projekta, cikli pa so v povprečju dolgi 4 – 6 tednov.

Kaj več bom napisal v kasnejših prispevkih, kakšnem članku in seveda v knjigi.

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).

Sistemska podpora projektom v združbi

Učinkovita izvedba projekta žal ni odvisna le od managerja projekta in članov projektnega tima, saj na izvedbo projektov v združbi vpliva še kar nekaj dejavnikov. Zmotno je mišljenje, da bo posameznik, ki smo ga poslali na nekajdnevno usposabljanje s področja projektnega managementa, brez pomoči drugih lahko učinkovito izpeljal projekt. Še več, kakor hitro bo naletel na ovire, dvome in nasprotovanja, bo začel delati »na star način«. To še posebej velja za tiste, ki jim smisel za organizacijo in obvladovanje časa nista ravno močnejši osebnostni lastnosti. In četudi bi usposobili več projektnih managerjev, bi le-ti težko vzpostavili okolje, kjer naj bi projekti praviloma uspevali.

Vsekakor so usposobljeni (in sposobni) managerji projektov eden glavnih dejavnikov uspešnosti projektov, vendar sami ne morejo storiti vsega. Najprej potrebujejo kakovosten tim – člani tima morajo imeti prava znanja in izkušnje, ter čas, da lahko delajo na projektu. Žal pa se v združbi običajno izvaja po več projektov hkrati (poleg rednega dela), ustreznih ljudi, s katerimi bi pokrili vse potrebe, pa ni zadosti. Ker manager projekta ne odloča o pomembnosti svojega projekta napram ostalim, največkrat tudi ne odloča o tem, koga bo vključil v svoj tim, ampak je to pristojnost vrhnjega managementa, oziroma še pogosteje linijsko-funkcijskih managerjev.

Veliko je odvisno tudi od tega, kdo, na podlagi katerih argumentov in na čigavo pobudo je sprejel odločitev, da se projekt izvede. Pa tudi kdo je izbral managerja in skrbnika projekta. Vse navedeno naj bi bilo del dogovorjenega in uveljavljenega sistema, ki je zapisan v organizacijskem predpisu oz. poslovniku managementa projektov v združbi. Zapisana pravila, postopki, obrazci, ipd. naj bi določali tudi kako postopati, če se več managerjev projektov bori za istega človeka ali opremo, ipd.

Pomembni sistemski dejavniki uspeha projektov v združbi

Celoten sistem in udeleženci bodo delovali še bolje, če bo v združbi razvita »hišna metodologija«, ki poleg poslovnika vključuje tudi priročnik (priporočila, metode) in orodja (obrazci, IT podpora), o čemer sem že pisal v prispevku o metodologijah.

Poleg tega ni zadosti, da pravila le zapišemo, ljudje se jih morajo tudi držati. S tem pridemo do naslednjega pomembnega »sistemskega« dejavnika – projektne organizacijske kulture, ki vpliva na motiviranost projektnega tima in posledično na učinkovito izvedbo projekta. Značilni vsakodnevni pokazatelji kulture v združbi so recimo zamujanje na sestanke in upoštevanje dogovorov (ustnih in tistih v raznih zapisnikih). Za projektno kulturo so poleg teh značilni npr. upoštevanje pristojnosti managerja projekta, določanje in upoštevanje prioritet, način kadrovanja, podpora managerjev…

Razvitejše »projektne družbe«, kjer se izvaja večje število projektov, običajno investirajo v dva pomembna »sistemska gradnika«. Prvi je računalniško podprt projektni informacijski sistem (PMIS, angl. project management information system), s katerim obvladujejo kopico dokumentacije in informacij, planirajo, kontrolirajo ter nadzorujejo projekte, analizirajo zaključene projekte ter vzdržujejo bazo znanja. Drugi gradnik pa je oddelek (ali pa za začetek le en strokovnjak), ki skrbi za delovanje in razvoj celotnega »projektnega sistema«. Stroka ga imenuje projektna pisarna (PMO, angl. project management office).

Razpustitev tima, darila in nagrade ter zaključna zabava

Po predaji proizvodov naročniku se projektni tim razpusti, le člani ožjega tima nekaj časa sodelujejo z managerjem projekta pri pripravi zaključnega poročila. Turner (2009) predlaga, da si člani tima privoščijo krajši počitek in si naberejo moči (in volje) za naslednji projekt. Še pred tem pa je potrebno proslaviti zaključek projekta. Zaključevanje na bo slavnostno – ljudje naj si zapomnijo, kdaj so uspešno zaključili projekt!

Zaključni sestanek, na katerem se tim uradno razpusti, je skoraj tako pomemben kot uvodni, »kick-off« sestanek. Ljudem omogoča, da izrazijo / pokažejo veselje, obžalovanje ali razočaranje, da so bili člani tima. Young (2007) predlaga, da se na sestanek povabi tudi tiste deležnike, ki so poleg članov projektnega tima največ prispevali k učinkoviti izvedbi projekta. Uvodni govor na sestanku pripada skrbniku projekta, ki poda splošno oceno izvedbe in pohvali prispevek vseh prisotnih. Tiste, ki so se najbolj trudili, je smiselno še posebej izpostaviti.

Sledi proslavitev zaključka. Turner meni, da so praznovanja pomembni motivatorji, ki naj se izvedejo ob vseh pomembnih dogodkih (mejnikih) projekta in ne le ob koncu projekta. Zaključek projekta lahko proslavimo po zaključnem sestanku v sejni sobi (s prigrizkom in penino), na slavnostni večerji, ali na celodnevnem pikniku, kamor so povabljeni tudi družinski člani – odvisno od vrednosti projekta in velikosti projektnega tima… Hall & Johnson (2002) omenjata večje gradbene projekte, kjer se po otvoritvi objekta z govorom naročnika in glavnega managerja začne zabava, ki običajno traja kar 24 ur! Zaključek »s stilom« je lahko tudi promocija podjetja za kasnejše posle (projekte).

Uspešnemu projektu lahko nazdravimo trikrat

Mnogi avtorji predlagajo, da se na zaključnem sestanku ali zabavi članom tima ob zahvali razdelijo simbolična darila, kot npr. majica ali kavna skodelica z logotipom projekta, karte za športno tekmo, brezplačno koriščenje počitniške hišice za vikend. Lahko se jim razdelijo tudi pisna priporočila, ki jih kasneje uporabijo na svoji karierni poti v združbi ali izven nje. Potrebno pa se je zavedati, da je odnos do članov tima pomemben ves čas projekta in ne le na koncu…

V mnogih združbah pa članom uspešnih timov namenijo tudi finančne nagrade, o čemer sem že pisal. Tokrat dodajam le še razmišljanje Turnerja (2009), ki pravi, da se člani tima običajno močno trudijo in za uspeh projekta žrtvujejo mnoge proste ure (tudi na račun družine). Če njihov trud na koncu ni ustrezno prepoznan in po možnosti tudi nagrajen, je zaključek projekta bolj žalosten, ljudje so lahko užaljeni, slabo voljo pa lahko prenesejo v naslednji projekt. Vodstva združb se ne zavedajo, da na koncu mogoče niti ni toliko pomemben znesek nagrade, kot to, da so »opazili« učinkovit projektni tim…

Pa še nekaj. V prejšnjem prispevku sem navedel, da uspešnemu projektu lahko nazdravimo kar trikrat (glej sliko). Prvič, ko naročnik prevzame proizvod(e) projekta, drugič, ko dosežemo namen projekta (tržni delež, letni prihranek, ipd.), in tretjič, ko s koristmi projekta povrnemo vložena sredstva. Pri izvedbenih projektih, kjer se vložek povrne v obliki plačila s strani naročnika, se načeloma proslavlja le po »primopredaji«, a so izvajalci v teh kriznih časih še bolj veseli takrat, ko naročnik nakaže zadnji obrok plačila.

Zaključno poročilo in ugotavljanje uspešnosti projekta

Ne glede na to, ali je projekt uspešno končan ali zaradi kateregakoli razloga prekinjen, se ob koncu (ali prekinitvi) izdela zaključno poročilo, ki vsebuje predstavitev rezultatov, odstopanja le-teh od planiranih, razloge za ta odstopanja, analizo napak in morebitnih zamud projekta ter finančno poročilo. V poročilo je priporočljivo vključiti tudi vse pridobljene izkušnje ter analizo tveganj in sprememb.

Poročilo izdela manager projekta, lahko tudi s pomočjo projektne pisarne. Aktivnosti za izdelavo končnega poročila se naj ne bi odlagale do zaključka projekta – vsaka faza projekta se običajno zaključi z vmesnim poročilom, tudi zato, da se ne bi izgubila kakšna pomembna informacija. Izdelava končnega poročila je za “striktnega” managerja projekta tako le povzetek faznih oziroma rednih vmesnih poročil. Tako kot vsa dokumentacija projekta, se tudi končno poročilo po formalni odobritvi arhivira za potrebe kasnejših projektov.

Zaključno poročilo se običajno predstavi ključnim deležnikom projekta, v prvi vrsti skrbniku in nadrejenim managerjem. Posebej se predstavi zunanjemu naročniku (običajno brez informacij o stroških izvedbe), tretja možna predstavitev pa je namenjena drugim managerjem projektov v združbi. Namen izdelave poročila je namreč dvojen: prvič, tim si izdela »čisto sliko« o kakovosti svojega dela (del tega je prejšnjič predstavljena ocena izvedbe); in drugič, s poročilom se pridobljene izkušenje prenesejo na kasnejše projekte. V javnem sektorju, kjer se projekti financirajo s proračunskih sredstev, poznajo še tretji namen poročila – revizijo projekta (ki preveri, če so bila javna sredstva racionalno trošena). V tem primeru je poročilo podrobnejše in obsežnejše predvsem z vidika financ.

Priprava in vsebina zaključnega poročila projekta

Pri nekaterih avtorjih sem naletel na trditev, da zaključno poročilo vsebuje tudi oceno uspeha, učinka ali prihodkov projekta oziroma, da koristi primerjamo s tistimi iz predloga projekta. Tu bi bralca spomnil, da je potrebno razlikovati med uspešnostjo in učinkovitostjo (več o tem…).

Poslovni uspeh projekta seveda lahko takoj, še pred pripravo zaključnega poročila, pomerimo v primeru izvedbenih projektov za zunanjega naročnika (takojšnje plačilo) ali pri organizaciji prireditev. Pri večini ostalih vrst (internih) projektov bi koristi lahko prvič »pomerili« ob koncu poskusnega delovanja (izvajanja, uporabe) prenovljenega procesa, nove IT podpore, nove metode dela, nova proizvodne linije ali prenovljenega objekta, ipd. Poskusno delovanje je namreč običajno del obsega in ena od aktivnosti projekta, zato se zaključno poročilo izdela šele po koncu tega preizkusnega obdobja. Nasprotno pa prihodke trženja novo razvitega izdelka ali pa nove poslovalnice ne moremo ugotoviti takoj, ker je potreben čas za uveljavitev na trgu.

Ne glede na to, če smo po poskusnem delovanju pomerili učinke (hitrejši proces, manj ur dela, manj napak, prihranek pri materialu, energiji…) in jih finančno ovrednotili, je potrebno za »čisto sliko« učinke projekta spremljati daljše obdobje (npr. eno leto), kar pa ni nujno, da izvaja projektni manager, sploh pa ne člani tima, ki so po predaji proizvodov prevzeli naloge na drugih projektih ali so se vrnili na vsakodnevna opravila v sklopu matičnega oddelka. Za merjenje učinkov je torej potrebno določiti osebo ali oddelek (predstavnik uporabnikov, kontroling, projektna pisarna) ter opredeliti metriko, pogostost merjenja in način poročanja.

Čeprav dejansko ugotovljene koristi za projektni tim, ki je izvedel projekt, niso nujno potrebna informacija, jim je vsekakor priporočljivo sporočiti ugotovitve merjenja, ki so lahko dodatna povratna informacija kakovosti njihovega dela, če pa je projekt zelo uspešen, pa je to še en razlog za odprtje šampanjca. Po koncu projekta uspeh lahko proslavimo trikrat, a o tem več prihodnjič.

Ocena izvedbe projekta in organizacijsko učenje

Preden se projektni manager loti priprave zaključnega poročila, ki ga bom predstavil naslednjič, naj bi člani (vsaj ožjega) projektnega tima skupaj ocenili izvedbo projekta in se pogovorili o pridobljenih izkušnjah: kateri pristopi, ideje ali rešitve so jim »še posebno uspeli« in katere so bile njihove največje napake, kaj bi naslednjič definitivno morali storiti drugače. Nabor pridobljenih izkušenj je kasneje priporočljivo predstaviti članom ostalih projektnih timov – na napakah se učimo, a učenje na tujih napakah je cenejše…

Pri ocenjevanju projekta si tim pomaga s primerjavo plana in dejanske izvedbe (roki, stroški, kakovost proizvodov, skladnost s specifikacijami), na podlagi odstopanj pa se ugotavljajo viri in razlogi neustrezne izvedbe, kaj je delovalo in kaj ne (delo tima, projektna metodologija v združbi, tehnika, naročnik, okolje – glej sliko), ter podajo predlogi izboljšav za prihodnje projekte. Frame (2003) in Turner (2009) predlagata, da naj večje projekte, zlasti tiste, katerih izvedba je izdatno odstopala od plana, oceni nekdo, ki ni bil član tima (lahko tudi zunanji svetovalec), ki tudi poda predloge izboljšav za kasnejše projekte. Hkrati pa Frame opozarja na možen odpor članov tima in nepripravljenost na sodelovanje z zunanjim ocenjevalcem.

Ocena izvedbe, pridobljene izkušnje in predlogi izboljšav

Pri ocenjevanju izvedbe lahko sodelujejo tudi drugi udeleženci projekta, predvsem skrbnik in naročnik. Slednji oceni delo tima, sodelovanje in odnos tima do naročnika, ali je končni proizvod tak, kot so želeli (in si ga predstavljali), ter ali bo prinesel koristi v takšni meri, kot so pričakovali. Načeloma je za slednjo oceno v večini primerov potrebno še nekaj časa spremljati koriščenje proizvoda projekta, a o tem več naslednjič.

Lahko bi rekli, da zbiranje in beleženje dobre in slabe prakse jemlje čas in povzroča dodatne stroške, vendar pa, če se tim tega loti sistematično, to sploh ne zahteva veliko časa. Namreč, zbiranje lahko poteka ves čas izvedbe projekta, ugotovitve pa se beležijo v zapisnikih kontrolnih sestankov in rednih poročil – praktično nastanejo kot »stranski produkt« sestankov. Martin & Tate (2001) predlagata dodaten neformalen»ustvarjalni« zaključni sestanek ob koncu projekta, kjer tim skupno oceni svoje delo ter izdela končni pregleden nabor pridobljenih izkušenj.

Izkušnje se lahko prenesejo v bazo znanja za uporabo v prihodnjih projektih, smiselno pa jih je tudi predstaviti drugim managerjem projektov na mesečnem »preglednem projektnem sestanku«. Ne samo dobra in slaba praksa, kar celotni plani (začetni ali posodobljeni, glede na dejansko izvedbo) se lahko uporabijo kot osnova za naslednji podoben projekt. Vsi vzroki za odstopanja pa so lahko tudi potencialna tveganja v bodočih projektih!

Page 1 of 9

Powered by WordPress & Theme by Anders Norén