Blog, debatni večeri, raziskave, knjiga…

Category: Izvedba projekta Page 1 of 3

Uspešnost (in učinkovita izvedba) IT projektov v Sloveniji

Najbrž ste opazili, da sem prispevke na tem blogu aktivneje objavljal le dve obdobji – v času pisanja obeh knjig. Z željo, da bi pomagal slovenskim projektnim timom k uspešnejši izvedbi projektov, sem vsebino knjig na blogu predstavil v strnjeni obliki – praktično je tretjina knjig prikazana tukaj, knjigi pa sta bogatejši za podrobnejšo razlago, moja razmišljana, predloge za prakso in primere iz prakse.

Pred časom pa sem prejel zanimivo vprašanje: »Ali imate morda kakšne novejše podatke glede uspešnosti IT projektov v Sloveniji?« Ker menim, da odgovor na to vprašanje zanima več ljudi, sem se odločil, da ga objavim tukaj na blogu. Odgovor sloni na moji raziskavi iz leta 2020, ko sem pripravljal knjigo »Agilno!?«. V raziskavi je sodelovalo 286 podjetij in drugih združb (tukaj je nekaj ključnih ugotovitev), med temi pa se je četrtina odgovorov nanašala na IT projekte.

Preden pa predstavim ugotovitve raziskave, pa naj še enkrat opozorim na razlikovanje pojmov učinkovito in uspešno (kar sem podrobneje razložil tukaj). Uspešen projekt naj bi bil tisti, pri katerem – finančno gledano – koristi, ki izhajajo iz rezultatov projekta (prihranki, prihodki), povrnejo investiran denar. Če pa govorimo o tem, ali je bil projekt zaključen pravočasno (in v proračunu), pa uporabljamo pojem učinkovite izvedbe. Seveda obstaja tudi vrsta nefinančnih sodil uspešnosti projektov, ki si jih tudi lahko ogledate v že omenjenem prispevku.

Dilema glede pojma »uspešnost« IT projektov pa ni prisotna le v Sloveniji, zato priporočam, da vedno, ko preberete, da je npr. “le 37% projektov uspešno zaključenih“, preverite, na osnovi katerih sodil so prišli do te ocene. Lahko, da je projekt zamudil za petino planiranega časa, a je prinesel zelo zadovoljive rezultate – torej je bil uspešen, kljub neučinkoviti izvedbi.  Razlikovanje obeh pojmov je pomembno tudi z vidika odgovornosti – manager projekta je predvsem odgovoren za učinkovito izvedbo, uspešnost pa je odvisna tudi od drugih deležnikov oz. dejavnikov.

No, po daljšem uvodu poglejmo, kako smo IT projekte izvajali v letu 2020. Kot sem omenil, je vzorec je vseboval 77 podjetij, katerih predstavnike sem pozval, naj navedejo povprečne vrednosti sodil za svoje projekte – stanja torej ne prikazujemo na osnovi 77 projektov, ampak na osnovi kakih 3500 (povprečje števila izpeljanih projektov na leto v obravnavanih podjetjih je skoraj 50). Naj povem še to, da je bilo govora o širokem naboru IT projektov (razvoj in uvajanje IT rešitev, razvoj aplikacij za osebne računalnike in pametne telefone, ERP sistemske rešitve, podpora obvladovanju dokumentacije, postavitev spletnih strani, ipd.).

Prva slika prikazuje odstotek projektov, ki so bili (po posameznih sodilih) izpeljani po planu, druga pa povprečno odstopanje projektov, ki niso bili izpeljani po planu. Naj še omenim, da je 27 (35%) sodelujočih navedlo, da projekte izvajajo ciklično (agilno), zato na slikah prikazujem tri podatke.

Seveda me je zanimala tudi uspešnost projektov. Ker sem raziskoval različne tipe projektov (ne le IT), žal nisem uporabil poglobljenega nabora sodil uspešnosti, ki jih predlaga Atkinson (to prepuščam drugim raziskovalcem). Zato prikazane ugotovitve mogoče niso ravno najbolj uporabne (majhen razpon ocen, med 2,3 in 2,8), vseeno pa lahko ugotovimo, da je pred nami še kar nekaj dela, da bi dosegli raven »vzorno«.

Ocena uspešnosti: 1 – manj zadovoljivo, 2 – zadovoljivo, 3 – dokaj zadovoljivo, 4 – vzorno

V nadaljevanju pa prikazujem še nekaj zanimivih ugotovitev glede dejavnikov, ki vplivajo na učinkovito izvedbo in uspešnost projektov. Če pogledamo (ne)sistematičnost uporabe metod projektnega dela, lahko rečemo, da je stanje dokaj zaskrbljujoče, hkrati pa to nekako pojasnjuje nizek odstotek učinkovito izpeljanih projektov. Gledano z bolj optimističnega vidika pa lahko rečemo, da dobro vemo, kje in kako se lahko izboljšamo 😊, kar je odlična osnova za začetek izboljševanja našega delovanja.

Pa še pojasnilo ocen v spodnjih slikah. Anketiranci so ocenili pogostost uporabe pristopov, metod in tehnik: 1 pomeni nikoli, 2 redko, 3 pogosto, 4 pa redno.

Tradicionalna pogodbena razmerja

Pri vseh tipih projektov investitorji del projekta pogosto zaupajo v izvedbo pogodbenim izvajalcem, lahko bi celo trdili, da večina projektov vsebuje vsaj nekaj pogodbenega dela. Za podjetja, katerih ključni posel pa je izvajanje projektov za druge (gradbena in druga inženiring podjetja, IT podjetja, organizatorji dogodkov, svetovalna podjetja, odvetniške pisarne, ipd.), pa vse projekte izvedejo na podlagi pogodb z naročnikom.

Poleg jasne opredelitve obsega projekta in nedvoumnih specifikacij ciljev (s kriteriji kakovosti), pogodbe vključujejo tudi ključna kriterija učinkovite izvedbe – rok in ceno izvedbe. Pri tem seveda velja, da ceno storitve sestavljajo stroški izvedbe in provizija izvajalca (dobiček, ki ga ustvari s projektom), za naročnika pa cena predstavlja njegov strošek po naslednji formuli:

Strošek naročnika = cena storitve = stroški izvajalca + provizija izvajalca

Zelo redko pa se zgodi, da so dejanski stroški izvajalca enaki planiranim. Eden od možnih razlogov je seveda neustrezna ocena izvajalca, obstaja pa še kar nekaj drugih virov spreminjanja stroškov: spremembe zahtev naročnika, dražitev / pocenitev materiala, tehnične težave, nepredvidena dela, itd. V primeru višjih dejanskih stroškov od planiranih bo izvajalec zaslužil manj (manjša provizija), lahko pa se tudi zgodi, da bo projekt izvedel z izgubo. Zato se želi s pogodbo zavarovati tako, ne bo kril vseh dodatnih stroškov, ki niso neposredno njegova krivda (kot je npr. napačna ocena), ampak si kritje le-teh razdeli z naročnikom.

Po drugi strani želi naročnik s pogodbo znižati možnost zamude izvedbe s strani izvajalca, najpogosteje pa se to izvede s stimulativno »nagrado« – ob izvedbi pred rokom, je lahko plačilo višje, ob zamudi pa manjše. To je torej še dodatni dejavnik dejanske končne cene in dodatna pomembna postavka pogodbe.

Poglejmo najprej »tradicionalne« pogodbe (največkrat uporabljanje v gradbeništvu, pa tudi pri »neagilnem« razvoju programske opreme) in ocenimo primernost le-teh za agilne projekte. Poznamo dve osnovni skupini pogodb – pri prvi se v pogodbi določi cena, pri drugi pa stroški in provizija izvajalca.

Verikalna črtkana črta prikaže delitev denarja v določeni situaciji

Najbolj poznana je Pogodba s fiksno ceno. Izvajalec prevzame celotno tveganje s tem, ko sprejme nespremenljivo plačilo za delo, ne glede na dejanske stroške. Pogodba je značilna za projekte “na ključ”, kjer izvajalec prevzame celotno odgovornost, naročnik pa na samo izvedbo nima vpliva, kjer je zelo jasno opredeljen končni cilj (in se večjih sprememb ne pričakuje), poleg tega pa je način izvedbe dokaj »rutinski«. V primeru sprememb obsega in specifikacij sledijo dodatna pogajanja in podpis aneksa. Ker zahteva ta vrsta pogodbe jasno dorečene cilje in »fiksiran« končni rok, je neprimerna za agilne projekte.

Če želimo izvajalca stimulirali za učinkovitejše obvladovanje stroškov in izvedbo pred rokom, izberemo pogodbo s Fiksno (maksimalno) ceno in stimulativno provizijo (ang. Fixed price incentive fee, FPIF). Poleg bonusa za izvajalca, če zaključi izvedbo pred rokom, oz. penalov v primeru zamude, pogodba opredeli tudi kdo krije morebitne dodatne stroške. Izvajalcu ta tip pogodbe ustreza prav z vidika skupnega prevzemanja tveganj, pri čemer se v pogodbi doreče delež prevzema tveganj (npr. 40/60%). Priporoča se, da večji delež prevzame stranka, ki laže obvladuje več tveganj (npr. napake pri izvedbi veliko lažje obvladuje izvajalec, kot naročnik). V razmerju, kot je zabeleženo v pogodbi, tako stranki pokrijeta prekoračitev stroškov ali pa si razdelita prihranek, če so dejanski stroški manjši od planiranih). Velikokrat take pogodbe vključujejo tudi nabor ključnih tveganj in oceno pomembnosti le-teh. Ta pogodba je nekoliko primernejša za agilne projekte, saj vsebuje mehanizem prilagajanja cene ob spreminjanju količine dela, vseeno pa zahteva jasno opredelitev ciljev ob podpisu pogodbe, kar ni značilno za agilne pristope.

Obstaja pa še tretji tip pogodbe s fiksno ceno, imenujmo jo Prilagodljiva fiksna cena   (ang. Fixed price economic price adjustment, FP_EPA), ki prvi tip pogodbe (Fiksna cena) nadgradi z možnostjo spremembe cene zaradi sprememb cen materialov in vrednosti denarja. Govora je o morebitni inflaciji, nihanju valut, spreminjanju cen surovin, ipd. Uporablja se predvsem za daljše mednarodne projekte, kjer je več možnosti inflacije in sprememb cen. Kljub prilagajanju je ta pogodba, iz istih razlogov, kot prva, neprimerna za agilne projekte.

Drugi tip tradicionalnih pogodb ima za osnovo stroške projekta, poznamo pa jih pod nazivom »Stroški+«. Osnovna opcija je pogodba Stroški+ s fiksno provizijo. Izvajalec poroča naročniku o stroških izvedbe, ki mu jih naročnik povrne, ob tem pa še vnaprej dogovorjen dodatek (provizijo, kot % planiranih stroškov). Ne glede na višino stroškov je provizija izvajalca enaka. Ta pogodba je primernejša za agilne projekte, če predpostavimo, da se stroški spreminjajo z spremembami zahtev (obsega). Je pa res, da se donosnost projekta z naraščanjem stroškov (pri nespremenjeni proviziji) manjša, kar ni motivacijsko za izvajalca. Zato obstaja še opcija, kjer »fiksna provizija« pomeni fiksen % dejanskih stroškov (večji stroški > večja provizija), a o tem več v knjigi.

Drugi tip pogodbe je Stroški+ s stimulativno provizijo, pri katerem se provizija spreminja z višino dejanskih stroškov. Pri nižjih stroških od planiranih je dodatek višji, pri višjih pa nižji. Npr. izvedba po planu prinaša izvajalcu provizijo v višini 4% stroškov, v primeru prihranka 6%, ob presežku pa le 1%). Lestvica pa je lahko še bolj progresivna, kjer presežek lahko pomeni tudi izgubo za izvajalca (glej sliko). Zaradi slednjega je pogodba nesprejemljiva za izvajalce agilnih projektov.

Tretji tip pogodbe – Ciljni stroški – je v določenem tolerančnem polju planiranih stroškov podoben pogodbi s fiksno ceno – izvajalec dobi nespremenljivo plačilo kadar so stroški npr. za največ 10% višji ali manjši od planiranih (prihranki gredo izvajalcu, ki krije tudi presežke), v primeru večjih prihrankov ali presežkov pa si izvajalec in naročnik te razdelita v vnaprej dogovorjenem razmerju (kot je to veljalo pri pogodbi s Fiksno ceno in stimulativno provizijo). Tudi ta tip pogodbe je značilen za pogodbe, ki vključujejo tudi oceno tveganj in se običajno uporablja pri razvojnih projektih, ko je rezultat relativno dobro poznan, a ne v celoti (zato je primeren tudi za agilne projekte). Izvajalec se lahko dogovori tudi za odstotke trženja izdelka.

Poročanje nadrejenim o poteku projekta

Nadgradnja kontroliranja projekta je poročanje skrbniku in drugim deležnikom projekta! Le-ti želijo biti redno informirani o poteku projekta – ali  dela potekajo po planu, kaj je bilo že narejeno, zanimajo jih morebitni problemi, verjetnost zaključka v skladu z omejitvami, ipd. Pogostost poročanja je odvisna od posameznih deležnikov, dolžine in vrste projekta. Zahtevnejši in bolj tvegani projekti zahtevajo skrbnejše spremljanje, kot neproblematični.

Avtorji največkrat navajajo, da se projektni manager s skrbnikom običajno srečuje mesečno, z drugimi vplivnejšimi deležniki (glavni manager, naročnik, svet projekta, soinvestitorji) pa ob mejnikih projekta (milestones, zaključkih posameznih faz izvedbe). Pred srečanjem običajno pripravi pisno poročilo, nakar na poročevalskem sestanku prisotnim izpostavi bistvene informacije o stanju, odstopanjih, ukrepih in pričakovanih težavah (tveganjih). Na teh sestankih se tudi išče rešitve za večje še nerešene probleme ter razpravlja in potrjuje večje spremembe projekta.

Vsebina poročila o stanju projekta

Kot je lahko različna pogostost pošiljanja poročil posameznim deležnikom projekta, tako je tudi vsebina lahko različna. Večina strokovnjakov priporoča, naj bodo poročila za nadrejene in druge linijske managerje v združbi  kratka in jedrnata. Največkrat imajo združbe kar predpisan obrazec na eni A4 strani, saj imajo nadrejeni redko čas, da se prebijajo skozi obsežna poročila in iščejo pomembnejše informacije. Seveda je malo drugače, če je projekt sofinanciran z nepovratnimi sredstvi ali če obstajajo drugi različni sofinancerji ter banke. Le-ti običajno zahtevajo obsežnejša poročila, saj imajo za pregled poročil posebej zaposlene ljudi.

Na sliki so prikazane bistvene informacije, ki so vključene v poročilo. Priporočljivo je uporabiti grafični prikaz izvedbe (gantogram) in porabe denarja (EVA). Mnogi avtorji navajajo, da je v poročilu potrebno podati tudi različne kazalnike, kot sta npr. indeksa časa in stroškov – SPI (schedule performance index, razmerje med planiranimi stroški za dejansko opravljeno napram planiranimi stroški za planirano delo v času poročanja) in CPI (cost performance index, razmerje med planiranimi in dejanskimi stroški za trenutno opravljeno delo), skupaj s planiranim proračunom (BAC budget at completion), ter oceno končnih stroškov glede na trenutno stanje (EAC Estimate at Completion), ipd. Več o kazalnikih in njihovih izračunih pa v knjigi.

V primeru, da se v združbi sočasno izvaja veliko podobnih projektov (npr. v razvojnem ali IT oddelku), je smiselno organizirati skupinsko poročanje, ki omogoča  prenos dobre prakse, skupno reševanje problemov na posameznih projektih, razvoj sistemskih rešitev za reševanje problemov, ki se pojavljajo na večini projektov, ipd. Pa še en nasvet – osebno sem zapisnike rednih tedenskih kontrolnih sestankov oblikoval podobno kot mesečna poročila. Ob koncu meseca sem združil tedenske ugotovitve, brisal manjša odstopanja in probleme, ki niso pustili večjih posledic, in dodal poročilo o stroških (ki jih tedensko nismo spremljali). Poročilo je bilo tako pripravljeno hitro in je vsebovalo vse bistvene informacije!

Kontroliranje kakovosti

Kot sem navedel že v prispevku o planu zagotavljanja kakovosti, stroka obvladovanje kakovosti v projektih običajno deli na štiri korake: (1) opredelitev (zahtev) kakovosti, (2) planiranje zagotavljanja kakovosti, (3) zagotavljanje in (4) kontroliranje kakovosti. V omenjenem članku sem predstavil prva dva koraka, danes pa še zadnja dva, pri čemer moram takoj poudariti, da ne obstaja neka splošna metoda kontrole kakovosti, kot to velja za kontrolo časa (gantogram) ali kontrolo stroškov (EVA).

Povsem drugače se namreč kontrolira kakovost pri razvoju programske opreme, razvoju izdelkov, inženiringu ali organizaciji prireditve, kakor so tudi drugačne vhodne zahteve, standardi ali zakonodaja. Čeprav so zgoraj omenjeni koraki enaki pri vseh projektih, pa je postopke in metode kontrole kakovosti potrebno prilagoditi vrsti projekta in posameznim strokovnim področjem projekta.

Zagotavljanje kakovosti sloni na »filozofiji« sodobnega obvladovanja kakovosti, ki daje poudarek preprečevanju in ne zaznavanju napak. Veliko bolje je ustvariti okolje, ki preprečuje napake in slabo kakovost, kot da se trudimo z reševanjem problemov (ne moreš pričakovati kakovostnih rezultatov pri slabi izvedbi). Kontroliranje z odkrivanjem in odpravljanjem napak na koncu sicer tudi pripelje do želene kakovosti, a dodelave in popravila zahtevajo dodatno delo in povzročijo dodatne stroške, lahko pa tudi zamudo projekta! Na zagotavljanje kakovosti močno vplivata dojemanje in način obvladovanja kakovosti v celotni združbi, pa tudi sam management projekta (izbira pravih ljudi za izvedbo aktivnosti, opredelitev prave taktike izvajanja aktivnosti, poudarjanje pomena kakovosti, ipd.).

Kontrola kakovosti najprej vključuje ugotavljanje kakovosti rezultatov aktivnosti, npr. pregled, preskušanje delovanja,  merjenje in analize meritev – veliko združb ima razvite standardne preskusne postopke za posamezne tipe projektov. Sledi primerjava ugotovitev z zahtevami in standardi kakovosti, ter izvedba korektivnih ukrepov (če je potrebno), kot npr. odpravljanje vzrokov za neustrezno delovanje. Termini kontroliranja kakovosti morajo biti zadosti pogosti, da pravočasno odkrijemo odstopanja in ukrepamo. Veliko cenejše je popravilo tehničnega načrta, ki ga izvede projektant v nekaj urah, kot spreminjanje že na pol zgrajenega objekta, ki je običajno daljše, v popravilo pa je vključenih tudi več ljudi in sredstev.

Wysocki (2004) navaja pet nivojev zrelosti kontrole kakovosti v združbah, pri čemer kot najnižji nivo prikaže združbo, kjer neka ustaljena praksa kontrole in standardi kakovosti ne obstajajo, izvedene so le posamezne naključne kontrolne aktivnosti posameznih timov, končna kontrola pa je stvar inženirjev. Najvišji nivo pa združba doseže, ko je kontrola kakovosti uveljavljen proces, ki se stalno izboljšuje na podlagi dobre prakse in preteklih napak. Sicer pa različni avtorji navajajo tudi tipična orodja obvladovanja kakovosti, npr. 7 orodij kakovosti (kot so npr. Demingov krog, Ishikawa diagram vzrokov in posledic, Paretov diagram), pa seveda celovite sisteme zagotavljanja kakovosti, kot so ISO, TQM, SixSigma, itd. »Stric Google« vam bo zagotovo našel zadosti ustreznih obrazložitev!

Kontroliranje stroškov projekta – EVA / EVM

Stroške najenostavneje spremljamo tako, da v tabelo planiranih stroškov vnašamo tudi dejanske stroške ter jih primerjamo med seboj. Vendar pa nam za realno sliko odstopanj porabe sredstev glede na plan manjkata dva podatka – »tretja dimenzija« – čas ter stanje izvedbe aktivnosti / projekta. Aktivnosti so namreč različno dolge, zato je smiselno kontrolirati stroške tudi med samo izvedbo in ne le na koncu. Poleg tega podatek o porabi denarja ne prikaže prav slike, če ne vemo, koliko smo s tem denarjem naredili. Celovito sliko o stanju porabe sredstev nam prikaže metoda prislužene vrednosti (Earned Value Analysis – EVA ali Earned Value Management – EVM).

Osnova za kontroliranje je plan odhodkov po času (S-krivulja), ki naj bi bil popravljen v skladu z morebitnimi spremembami ciljev, zahtev in plana. Za ugotavljanje morebitnega trenutnega odstopanja sta pomembna še dva podatka – poraba sredstev do danega trenutka ter stanje izvedbe projekta. Na podlagi slednjega podatka ugotovimo, koliko sredstev smo planirali za trenutno stanje izvedbe. Šele razlika med porabo sredstev v danem trenutku in planiranimi sredstvi za že izvedene aktivnosti nam prikaže resnično odstopanje stroškov od plana (slika).

Plan stroškov, dejnska poraba in odstopanje stroškov glede na plan

Trenutno odstopanje in poznavanje vzrokov za le-to nam služi tudi za okvirni predračun porabe sredstev ob zaključku projekta. Sicer pa »EVA diagram« običajno prikaže podatke o porabi sredstev za celoten projekt. Da bi imeli boljšo sliko o odstopanjih in našli pravi vzrok za ta odstopanja, je priporočljiv izris več diagramov po posameznih vrstah stroškov – porabljene ure, material, pogodbe ipd. Pomembno je namreč vedeti, da so ukrepi za odpravo ali zmanjšanje odstopanj lahko pravi in uspešni, če so sprejeti na podlagi poznavanja pravega vzroka odstopanj.

Najpogostejši vzroki za odstopanja stroškov so lahko neustrezna ocena v fazi paniranja,  problemi, zamude in dodatne aktivnosti (penali & nadure), podražitve materiala, nepravilnosti pri beleženju porabe ur, izstavljanje računov pogodbenih strank za še ne izvedeno delo ter vnaprej izvedena naročila, ki so bila sicer planirana za kasnejši čas. Odstopanje stroškov pa je običajno neposredno povezano tudi s spremembami obsega, časa, kakovosti, zato smo v prejšnjem prispevku tudi omenili, da je potrebno vsako spremembo oceniti z vidika spremembe stroškov, preden se odobri.

Zajem podatkov o porabi denarja se lahko vrši ročno (manager projekta, administrator, projektne pisarna) ali samodejno, s pomočjo računalniško podprtega informacijskega sistema. Priporočljivo je, da vsak strošek, ki ga zavede za to pristojna služba, vsebuje informacijo o projektu, na katerega se navezuje. Vrsta stroška pa se lahko veže na računovodski tip stroške. Informacijski sistem nam lahko izpisuje poročila v obliki tabel in / ali diagramov samodejno (v določenih časovnih intervalih) ali na poziv udeležencev projekta.

Kontroliranje sprememb / obsega projekta

Na začetku današnjega prispevka moram priznati, da se kljub dolgoletnem delu na projektih osebno s »kontroliranjem obsega« nisem srečal, zato sem z zanimanjem proučil, kaj o tem piše strokovna literatura. Pri tem sem začuden ugotovil, da pod pojmom »scope control« stroka dejansko razume kontroliranje sprememb (obsega, specifikacij).

Do sprememb v projektu skoraj vedno pride, saj je nemogoče vnaprej predvideti vse podrobnosti. Članom tima se lahko porodijo nove ideje ali pa naročnik spremeni zahteve, pri daljših projektih se lahko pojavi nova tehnologija ali material, ali pa nas konkurenca preseneti s podobnim produktom, ipd. Spremeni se lahko sam končni proizvod ali način izvedbe.

Najslabše je, da se spremembe »dogajajo« nekontrolirano, kadar se posameznik ali ožji krog udeležencev projekta sam odloči za določene spremembe, ne da bi o tem obvestil druge ali dobil odobritev, da se sprememba lahko izvede. Milošević (2003) jih je označil za »ubijalce projekta«, ker povečajo obseg del, povzročajo neskladja v delu in zamudo projekta, povišajo stroške, znižajo moralo in produktivnost ter kvarijo odnose med udeleženci projekta.

Sistem obvladovanja sprememb

Management sprememb projekta

Avtorji zato predlagajo definiranje postopka obravnave in odobravanja sprememb, s katerim naj bi preprečili prikrite spremembe. Določiti je potrebno proces ter odgovorne za oceno in odobritev predlaganih sprememb ter pravila informiranja udeležencev projekta o sprejeti spremembi.

Proces obvladovanja sprememb naj bi, poleg priprave formalnega predloga spremembe, vključeval tudi razmislek o več alternativah uresničitve ter oceno vpliva spremembe na cilje projekta. Sledilo naj bi potrjevanje in izvedba (odobrene) spremembe, ki vključuje ali spremembo planov in ciljev projekta ali izvedbo korektivnih aktivnosti. Po izvedbi spremembe ali projekta je koristno preveriti ustreznost prvotnih ocen vpliva, priporočljivo pa je vzdrževati tudi bazo sprememb preteklih projektov, ki služi združbi za učenje in učinkovitejšo izvedbo kasnejših projektov.

Kljub v začetku projekta opredeljenem procesu odobravanja sprememb, pa še vedno lahko prihaja do nekaterih samovoljnih sprememb (zaradi odpora do birokracije, morebitnega predolgega procesa odobravanja, preverjanja ideje,  ali celo zaradi strahu pred zavrnitvijo), zato mora manager projekta na rednih kontrolnih sestankih tudi preverjati, kaj delajo člani tima in preveriti, ali je to v skladu z dogovorjenimi specifikacijami in cilji aktivnosti.

Ukrepanje v primeru zamujanja projekta

Ko projektni manager ugotovi, da določene aktivnosti ne sledijo planu, mora seveda ukrepati, sicer projekt ne bo izpeljan do postavljenega roka, kot smo prikazali ob koncu (in na sliki) prejšnjega prispevka.

Ob časovnih odstopanjih se je najprej potrebno vprašati, kdaj, ob kakšnem zaostanku ukrepati. V prvi vrsti je to seveda odvisno od (ne)kritičnosti aktivnosti in morebitne časovne rezerve. Poznati moramo vzrok za odstopanje, planirano in dejansko porabo ur ter potreben čas in ure za zaključek aktivnosti. Mogoče je izvajalec, ki naj bi sicer na aktivnosti delal le 20% svojega časa, do trenutka kontrole delal na projektih / aktivnostih z višjo prioriteto, do konca planirane aktivnosti pa bo brez problema opravil svoje delo, ker bo delal le na tej aktivnosti.

Pri nekaterih avtorjih sem zasledil predlog, da je potrebno že na začetku projekta določiti tolerance, tako časovna kot stroškovna odstopanja, pri katerih je najkasneje potrebno ukrepati. To je lahko povezano tudi z morebitno časovno rezervo pred koncem projekta, ki smo jo planirali za primer uresničitve tveganj ali dodatnih nepredvidenih problemov in zastojev.

Pristopi za odpravljanje zamud projekta

Do sedaj sem predstavil manj kritične zamude pri izvedbi. V kolikor nimamo nobene časovne rezerve, izvajalci pa (tudi z nadurami) aktivnosti ne bodo mogli izvesti do roka, potem imamo na voljo tri vrste ukrepov. Najprej poskušamo rešiti trenutno aktivnost, s krizno akcijo z najvišjo prioriteto. Za izvedbo krizne aktivnosti je potrebno uporabiti vsa razpoložljiva sredstva, kar včasih predstavlja tudi visok dvig stroškov, sploh če je v reševanje potrebno vključiti tudi dobavitelje ali pogodbenike.

Drugo možnost strokovnjaki angleško poimenujejo fast-tracking, kar bi lahko prevedli kot hitro sledenje. Preverijo se medsebojne povezave aktivnosti, ki še sledijo do konca projekta, pri čemer poskušamo tiste z »mehkimi« povezavami čim bolj prekriti, kar pomeni, da se dve povezani aktivnosti izvajata vzporedno, kolikor je to mogoče. »Razdrtje plana« (angl. schedule crashing) pa pomeni vključevanje večjega števila virov, s katerimi se skrajšajo aktivnosti (in zmanjša zamuda) na kritični poti, kar pa tudi lahko poviša stroške projekta.

Verzuh (2005) pa še posebej opozarja tudi na spremembe izvedbe, ki posredno nastanejo zaradi čakanja na odziv naročnika (npr. potrditev zasnove izdelka). Pri tem predlaga dve rešitvi: izvedbo drugih aktivnosti, ki niso odvisne od naročnika, ter uporabo gantograma, v katerem naročniku prikažemo (končno) zamudo projekta zaradi njegove neodzivnosti, kar naj bi ga spodbudilo k hitrejšemu odzivu. Pomembno z vidika kontroliranja pa je, da se »čakanje« na naročnika pravočasno ugotovi in izvede zgoraj predlagana ukrepa.

Kontroliranje izvedbe (časa)

Ob začetku pisanja tega prispevka sem se nepričakovano znašel v dilemi, kako ga nasloviti. V pogovornem jeziku večinoma govorimo o kontroli časa, v resnici pa kontroliramo stanje izvedbe v času in to primerjamo s prvotnim planom, da preverimo, če gre »vse po planu«. Tako tudi tuji avtorji uporabljajo pojem »schedule control« in ne »time control«. Mogoče bi pojem lahko prevedli v »kontroliranje poteka« projekta, vsekakor pa ne v kontroliranje plana ali urnika…

Najpogostejše uporabljeno orodje za ugotavljanje (pravočasnosti) izvedbe je gantogram, ki sem ga predstavil že pri planiranju projekta. Sodobna orodja za podporo terminskemu planiranju omogočajo, da poleg planiranih terminov aktivnosti v fazi izvedbe projekta v gantogram naknadno vnašamo tudi dejanske začetke, trenutno stanje izvedbe (v %) in zaključke (ter s tem trajanje) izvedenih aktivnosti. Razlika med planirano in dejansko izvedbo v danem trenutku pomeni časovno  odstopanje.

Primer gantograma s prvotnnim terminskim planom, dejansko izvedbo in s prikazom časovnih odstopanj


Najbolj poznana pripomočka obvladovanje časa (kot nadgradnja gantograma) sta linija stanja (angl. Jogging ali Progress Line) in B-C-F analiza (angl. Baseline-Current-Future). Linija stanja prikaže za koliko je izvajanje posamezne aktivnosti pred ali za planiranim rokom (orodje, uporabljeno za izdelavo primera na sliki, pokaže le zamude). Na podlagi poročanja izvajalcev aktivnosti se označi odstotek izvedbe posamezne aktivnosti, nakar se ta stanja poveže (slika: rdeča linija z rombi v krogcih pri aktualnih aktivnostih, z odmikom v levo v primeru zamude). Linija pred aktualnim aktivnostim in za njimi teče po datumu kontrole.

B-C-F analiza: vzporedno se izriše planiran potek izvedbe (Baseline, slika: črne aktivnosti) ter dejanska izvedba aktivnosti (Current, slika: modre in rdeče aktivnosti, polna šrafura pomeni % izvedbe). Ko se vnese še predviden čas za izvedbo trenutne aktivnosti (če le-ta ne poteka po planu), lahko poleg trenutne zamude vidimo tudi predvideno zamudo ob koncu (ali mejnikih) projekta v primeru neukrepanja (Future, slika: razdalja med belim in črnim rombom pri zadnji aktivnosti). Večja, ko je razlika hitreje je potrebno ukrepati (več o ukrepih prihodnjič)!

Seveda je pri vseh projektih oziroma aktivnostih težko oceniti odstotek trenutne izvedbe aktivnosti. Medtem, ko se npr. pri gradbenih projektih to lahko izmeri (metri položenih vodnikov, število zgrajenih nadstropij stavbe, kvadratni metri položene izolacije, ipd.), je po drugi strani težko oceniti odstotek izdelane programske opreme ali razvitega izdelka. Nekateri avtorji zato predlagajo, naj se vnese 25% kadar se je izvedba dejansko začela, 50% nekje na polovici, in 75%, ko je aktivnost blizu konca. Spet drugi predlagajo le 0 (aktivnost se še ni začela), 50 (aktivnost se izvaja) in 100 (aktivnost je zaključena). Ker je omenjen problem kritičen predvsem v primeru dolgih aktivnosti, je za obvladovanje časa priporočljivo take aktivnosti že v fazi planiranja razdeliti na več krajših.

Pridobivanje informacij o poteku projekta in kontrolni sestanki

Za ustrezno kontroliranje projekta je potrebno pridobivati prave informacije v pravem trenutku, zato mora projektni manager že pri pripravi projekta  razmisliti o načinu spremljanja poteka projekta, o čemer sem že nekaj pisal prejšnjič in pri planiranju.

Informacije lahko pridobivamo iz različnih virov, ki jih Cleland (1999) ter Kliem & Ludin (1998) delijo na formalne in neformalne. Formalni viri so razna poročila, kontrolni seznami, kontrolni sestanki, dopisi, zapiski in zaznamki, ter zabeležke in zapisniki revizij. Med neformalne vire štejemo neformalne pogovore, opazovanja izvajalcev ter spremljanje govoric in opravljanja med člani tima ter v okviru združbe.

Osebno sem najbolj naklonjen rednim (30 – 60 minutnim) kontrolnim sestankom (angl. progress ali status meetings), kar navaja tudi večina avtorjev. Na sestankih naj bi manager s spodbujanjem in usmerjanjem odprte diskusije prišel do informacij, ki jih člani tima sicer ne bi zapisali v poročila in druge pisne dokumente. Sestanki omogočajo tudi medsebojno informiranje med prisotnimi (običajno člani ožjega tima), takojšnje reševanje odkritih odstopanj, manager pa ga lahko izkoristi tudi za stalen neformalen pritisk na člane tima (spodbujanje, opozarjanje na roke, …). Pogostost sestankov je odvisna od vrste in kompleksnosti projekta – nekateri avtorji predlagajo dnevne, drugi tedenske, spet tretji le mesečne, Heerkens (2002) pa predlaga sestanek na vsake 4% trajanja projekta.

Načini pridobivanja informacij o poteku projekta

Redni kontrolni sestanki se ne sklicujejo – termin, lokacija in udeleženci se določijo na začetku in se izvajajo do konca projekta! Večji strokovni problemi se na teh sestankih ne rešujejo, ampak se skličejo posebni sestanki, kamor se povabi le del stalnih udeležencev kontrolnih sestankov, po potrebi pa še druge strokovnjake iz združbe ali izven nje.

Od članov tima in pogodbenih izvajalcev lahko zahtevamo pisna poročila po e-pošti ali pa vzpostavimo projektni informacijski sistem / portal, kamor člani tima redno (dnevno, tedensko, mesečno) vnašajo informacije, ki so potrebne za kontroliranje (rezultati, problemi, časovna odstopanja, porabljene ure dela, stroški). To je lahko alternativa kontrolnim sestankom ali pa dodatek. Med formalne vire pa stroka uvršča tudi kontrolne sezname. Ti se uporabljajo kadar neka aktivnost vključuje veliko manjših opravil (tudi kot opomnik), s številom že opravljenih opravil pa se lažje ugotavlja stopnja že izpeljane aktivnosti.

Kleim & Ludin (1998) predlagata redna tedenska »srečanja na štiri oči« s posameznimi člani tima, kar bi lahko šteli med formalne vire (če so dogovorjeni stalni sestanki) ali med neformalne, če se obiski izvajajo po potrebi. Osebno sem bolj za slednje – pogosteje naj bi se dobivali z izvajalci, ki delajo na zahtevnejših aktivnostih (z vidika »časovne kritičnosti«, tveganosti in strokovne zahtevnosti). Pa seveda s tistimi člani tima, s katerimi imamo slabše pretekle izkušnje z vidika zanesljivosti…

V literaturi sem zasledil pojma »management by walking around« in »walking the project«. To seveda vključuje obisk članov tima na terenu oziroma v njihovih prostorih ter neformalni pogovor o stanju, problemih, predpostavkah, tveganjih. Heerkens (2002) poudarja, da manager z obiski ugotavlja tudi raven motiviranosti članov tima, preverja točnost ali veljavnost informacij, ki jih prejema v poročilih in sestankih, ter hitreje odkriva morebitne probleme.

Katzenberg (v Flower, 2006) pa pravi, da včasih opravi nekaj sto pogovorov dnevno, dolgih le minuto ali dve, z namenom, da preveri, kako napreduje delo na projektu. Po njegovem mnenju vzdrževanje odnosov z izvajalci izboljša sodelovanje, predstavlja sistem zgodnjega opozarjanja na probleme ter pripelje do ustvarjanja idej, do katerih posameznik ne bi nikoli prišel.

Kontroliranje projekta

Kot sem zapisal že marca, ko sem pisal o planiranju kontroliranja, je kontroliranje zadnji korak procesa (projektnega) managementa – manager v fazi izvedbe z vodenjem zagotavlja učinkovito izvajanje aktivnosti, s kontroliranjem pa preverja, če izvedba poteka po planu. V omenjenem prispevku sem tudi že na kratko predstavil proces in področja kontroliranja, navedel načine pridobivanja informacij ter priporočila za učinkovito kontroliranje (glej takratno sliko).

Proces kontroliranja torej vključuje spremljanje izvedbe (obseg, čas, kakovost, stroške, tveganja, dobave), primerjavo stanja s planom, ugotavljanje odstopanj in planiranje ter izvedbo korektivnih akcij / ukrepov, s katerimi zagotovimo, da bo projekt izpeljan v okviru postavljenih ciljev. Pri tem moram opozoriti na razliko med kontroliranjem in nadzorom. Manager, katerega funkcija je (tudi) kontroliranje, mora redno spremljati izvedbo in ukrepati v primeru odstopanj, med tem ko nadzornik (običajno mesečno) dobi celovito poročilo in praviloma ne ukrepa (se torej »ne vtika« v delo managerja). Lahko le predlaga zamenjavo managerja, če oceni, da le-ta ne obvladuje projekta, ali pa mu svetuje kako naj ukrepa.

Dejavniki učinkovitega kontroliranja

Osnovna vhodna informacija za kontroliranje je elaborat projekta, saj brez kakovostno opredeljenih zahtev in ustreznega plana ne moremo kontrolirati projekta. Pri kontroli v danem trenutku stanje izvedbe vedno primerjamo s planom in če plana ni (ali če je le »okviren«), primerjava in zaznavanje morebitnih odstopanj (ter velikost  le-teh) ni možno, posledično pa tudi ne moremo vedeti, ali trenutno stanje pomeni, da bo projekt izpeljan v okviru omejitev (čas, stroški…) ali ne.

Kontroliranje mora biti redno! Prej ko odkrijemo odstopanja, manjša so in lažje jih je reševati. Raziskava pred leti je pokazala, da redna tedenska kontrola izvedbe zmanjša zamudo projekta za 10% napram mesečnem kontroliranju. Zelo pomembno je, da člani tima sodelujejo pri kontroli – da dajejo prave informacije o stanju ter da ne prikrivajo problemov in napak. Manager projekta mora biti zato prizanesljiv do »prinašalcev slabih informacij« in biti v prvi vrsti usmerjen predvsem v reševanje problemov in ne v kaznovanje (kot »vodja« pa naj se kasneje le pogovori s tistim, ki je zakrivil problem).

Čeprav morajo biti ugotovitve kontroliranja (stanje, odstopanja) in planirani ukrepi ustrezno dokumentirani, pa mora biti kontrola racionalna, kar se nanaša predvsem na čas, ki ga manager in še posebej člani tima porabijo za informiranje o stanju projekta. Preveč birokracije ljudem jemlje čas za delo na aktivnostih in povzroča nejevoljo pri članih tima! Kateri so nujni podatki in kako jih najbolj učinkovito pridobimo, pa bom navedel pri podrobnejšem opisu kontrole posameznih področij v kasnejših prispevkih.

Kontroliranje bo kakovostnejše, če lahko izvedbo ovrednotimo (poraba sredstev, odstotek že izvedene aktivnosti,…) pri tem pa uporabljamo poznane metode (EVA) ali orodja (gantogram). Pa še nekaj: ne kontroliramo ljudi ampak rezultate njihovega dela!

Page 1 of 3

Powered by WordPress & Theme by Anders Norén