Blog, debatni večeri, raziskave, knjiga…

Category: Management Page 1 of 6

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.

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

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.

Dokumentiranje in predaja rezultatov

Podobno, kot to velja za zagotavljanje in kontroliranje kakovosti, se tudi zaključevanje del ter predaja rezultatov naročniku razlikujejo glede na vrsto projekta. Proces, metode in udeleženci so različni pri predaji novo razvitega izdelka v redno proizvodnjo, nove informacijske rešitve uporabnikom, ali poslovne stavbe naročniku. Po drugi strani pa se predaja rezultatov zunanjemu ali notranjemu naročniku ne bi smela razlikovati, a se žal v praksi prevečkrat dogaja, da se interni projekti površno zaključujejo, kar povzroči prikrito delo na projektu po uradnem zaključku, to pa ovira redno delo in kasnejše projekte.

Ena od pomembnejših zaključnih aktivnosti projekta je dokumentiranje, pri čemer avtorji največkrat govorijo o dokumentiranju same izvedbe (o čemer bom še pisal), o tehnični dokumentaciji proizvoda (objekta, proizvodne linije, informacijske rešitve, razvitega izdelka), raznih navodilih (za uporabo, vzdrževanje). Pri gradnji objektov je zelo pomembno, da je dokumentacija usklajena z dejanskim stanjem na terenu, saj med samo gradnjo lahko prihaja do veliko manjših sprememb, ki pa so kasneje lahko tudi nevarne za uporabnike (npr. elektro inštalacije). Ne smemo pozabiti, da dokumentacija lahko nekega dne pristane tudi v sodni dvorani.

Primer: Zapisnik validacije novega izdelka

Nekatere zaključne aktivnosti so sicer tudi formalno povezane z aktivnostmi po zaključku projekta, saj naj bi projektni tim pripravil okvirni plan »poprojektnih« aktivnosti. Običajno naj teh aktivnosti ne bi izvajali člani tima, ker se po koncu projekta večinoma posvetijo novemu projektu, ampak za to namenjeni oddelki, vendar pa naj bi projektni tim z njimi pripravil plan in postopke npr. periodičnega preverjanja stanja in vzdrževanja (objekti, oprema). Pri razvoju informacijskih rešitev se ob zaključevanju lahko dogovarjajo za kasnejše nadgradnje, pri razvoju izdelkov o prilagajanju izdelkom posebnim željam kupcev. Posebno »poglavje« je tudi načrt del in določitev odgovornih za reševanje težav v garancijski dobi.

Pregled in potrjevanje rezultatov projekta je skupna aktivnost naročnika in projektnega tima, zato je smiselno, da  pred tem skupaj pripravita procedure preverjanja ustreznosti (ATP – acceptance test procedure). Največkrat govorimo o verifikaciji končnega proizvoda (proizvodov) – naročnik (ali neodvisna pristojna služba) preveri, ali so le-ti skladni s specifikacijami, standardi in zakonodajo. Pri »procesnih rešitvah« (npr. vzpostavitev proizvodnje novega izdelka, optimizacija procesa ali uvedba IT podpore) govorimo tudi o postopku validacije, kjer ustreznost procesa, metod in priprav potrdijo sodelujoči v procesu. Po verifikaciji (in validaciji) uporabnik prevzame proizvode v uporabo, projektni tim pa se posveti administrativnemu zaključevanju projekta.

Zaključevanje projekta

Čeprav zaključevanje projekta, bolj kot katera koli druga faza, zahteva izjemno raznolik nabor tehničnih, organizacijskih in vodstvenih veščin, raziskave na žalost kažejo, da je to v praksi najbolj “prezrta” in najmanj sistematično izpeljana faza. Projekt se ne zaključi sam od sebe, z zadnjo izpeljano aktivnostjo faze izvedbe, ampak je naloge in opravila zaključevanja projekta potrebno skrbno načrtovati, usklajevati in kontrolirati!

Večino avtorjev navaja, da je zaključevanje projekta samostojna faza s tipičnimi aktivnostmi, čeprav za razliko od drugih faz projektnega cikla ne obstaja močna razmejitev med fazo izvedbe in zaključevanja, kakor prehod med fazama tudi ne vključuje sestanka z ostalimi deležniki, ki bi potrdili, da projekt lahko preide v fazo zaključevanja (kot to lahko velja za prehod med posameznimi fazami izvedbe).

Dva sklopa aktivnosti zaključevanja projekta

Stroka običajno deli aktivnosti zaključevanja v dva sklopa, pri čemer eni pišejo o zaključevanju del in administrativnem zaključku (kot je to prikazano na sliki), drugi pa zaključevanje del poimenujejo zaključevanje pogodb, ki pa tudi vsebuje predajo in verifikacijo proizvodov projekta. Zasledil sem tudi delitev na štiri sklope – aktivnosti v povezavi z naročnikom (predaja in potrjevanje rezultatov, usposabljanja), organizacijsko učenje (dobre in slabe prakse, zaključno poročilo), kadrovske zadeve (ocena članov tima in nagrajevanje) ter upravno administrativne zadeve (plačila in zaprtje računov, arhiviranje dokumentacije).

Pri nekaterih avtorjih sem naletel na predlog, da se v začetku zaključevanja projekta pripravi terminski plan vseh opravil z odgovornimi (angl. punch list schedule & punch list RAM), podobno, kot se pripravi terminski plan aktivnosti projekta, pri čemer naj bi večina aktivnosti lahko potekala vzporedno ali z rahlim prekrivanjem. Izvedba zaključnih aktivnosti se pogosteje kontrolira kot je to običajno v fazi izvedbe, kakor so tudi pogostejši sestanki projektnega tima z drugimi deležniki projekta, še posebej z naročnikom.

Včasih pa se zgodi, da se projekt zaradi dogodkov v okolju projekta (zakonske spremembe, aktivnosti konkurence, problem financiranja, odločitev naročnika) prekine ali celo zaključi pred planiranim koncem, ne da bi dosegli zastavljene cilje. Čeprav v tem primeru običajno odpade nekaj aktivnosti zaključevanja del, pa je potrebno opraviti večino na sliki omenjenih nalog. Konec koncev smo se tudi na tem projektu nekaj naučili, kar bi bilo smiselno upoštevati v kasnejših projektih (zaključno poročilo!) in zakaj tudi v tem primeru ne bi organizirali zaključne zabave?

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.

Page 1 of 6

Powered by WordPress & Theme by Anders Norén