Projektni management

Blog, debatni večeri, raziskave, knjiga…

Category: Priprava projekta (Page 1 of 3)

Plan obvladovanja informacij in dokumentacije projekta

Plan informiranja in obvladovanja dokumentacije, ki ga nekateri tuji avtorji poimenujejo tudi »management komunikacij«, sem omenil že pri pripravi projekta in v poslovniku projektnega tima, a mi teme še ni uspelo podrobneje predstaviti. Vzrok za to leži tudi v dejstvu, da je za nekatere projektne time (in nadrejene združbe) to dokaj nepomembna tema, ker je obvladovanje informacij in dokumentacije projektov zanje že neka vrste rutina, sploh če imajo vpeljan poseben, računalniško podprt projektni informacijski sistem. Govora je predvsem o združbah, kjer se izvaja veliko (podobnih) projektov – gradnja in inženiring, razvoj IT rešitev, razvoj izdelkov…

Če pa se v združbi letno izvede le nekaj projektov, še posebej pa, če se pripravljamo na izvedbo enega obsežnejšega projekta, ki vključuje več partnerjev (EU projekti) in/ali podizvajalcev, potem je planiranje informiranja zelo pomembna tema. Dokumentacija in informacije se namreč prenašajo med mnogimi posamezniki in skupinami – v okviru projektnega tima, med timom in podizvajalci ter naročnikom (stranko), obveščamo pa tudi skrbnika, linijske in vrhnje managerje v združbi (po PMBOK, 2004, je pomemben vhodni dokument za opredelitev komunikacij kar organigram udeležencev projekta – RBS). Včasih je potrebno redno informirati tudi javnost!

Opredelitev informacijskega sistema projekta

Kaj določa informacijski sistem projekta*

Neobvladovanje informacij in dokumentacije lahko povzroči velike probleme na projektu. Ste že slišali za pravilo 1 minute? (vir: Metoda 20 ključev). Naše delovno mesto je ustrezno organizirano, če informacijo, ki jo potrebujemo, najdemo prej kot v eni minuti (med papirji na mizi, v predalu, omari, na svojem osebnem računalniku, na strežniku, internetu…). Če iskanje traja več kot minuto, je to izguba časa! Dodaten problem nastane, če najdemo informacijo, ki jo potrebujemo za svoje delo, pa ne vemo, da je zastarela – vse nadaljnje delo na podlagi te informacije je lahko zaman… Problem je še izrazitejši zaradi delovanja članov tima na različnih lokacijah – če ima vsak dokumente, ki jih je ustvaril, na svojem računalniku in jih občasno posreduje drugim preko e-pošte, obstaja velika verjetnost, da bo določena informacija nepravilna ali je ne bo dosegla pravega človeka ob pravem času.

Wysocki (2009) navaja, da kar 70% IT projektov pade prav zaradi slabega komuniciranja, zato predlaga, da tim na začetku poišče odgovore na tri vprašanja: »Kdo so deležniki projekta?«, »Kaj želijo vedeti o projektu?« ter »Kako jim bomo zagotovili te informacije?«. Burke (2010) dodaja še, da se je potrebno odločiti za medij, preko katerega jih bomo informirali, ter kdaj bodo dobivali informacije (dokumente, zapisnike, poročila, ipd.). Plan informiranja naj bi torej določil kdo bo dobival katere informacije, kako pogosto, na kakšen način (medij) ter ali mora posredovati povratno informacijo (Verzuh, 2008). Za ustrezno razumevanje je priporočljivo pripraviti tudi obrazložitev strokovnih pojmov (PMBOK, 2004). Vse navedeno se seveda vključi v elaborat projekta!

Kot se zapisal že v uvodu, imajo mnoge združbe za podporo planiranja, kontroliranja in obvladovana informacij / dokumentov, vzpostavljen računalniško podprt projektni informacijski sistem (PMISproject management information system). Več o različnih vrstah PMIS pa v jeseni, ko bom pisal o sistemski podpori managementu projektov.

Predstavitev in potrjevanje elaborata

Zapisal sem že, da se faza priprave (zagona) projekta zaključi s potrjevanjem (zagonskega) elaborata projekta. Čeprav bi lahko elaborat poslali v pregled vsem, ki naj bi sodelovali v potrjevanju, le-ti pa bi nam v doglednem času sporočili pripombe oziroma (ne)strinjanje, je bolj priporočljivo, da se potrjevanje izpelje  na sestanku, ki poleg predstavitve projekta omogoča tudi dodatne pojasnitve in diskusijo o morebitnih spremembah.

Udeleženci predstavitvenega sestanka so največkrat člani ožjega projektnega tima, skrbnik projekta, interni naročnik oz. predstavnik uporabnikov ter glavni manager združbe (»uradni« naročnik). Ker se na sestanku potrjuje tudi predlagana organizacija projekta z matriko pristojnosti, je smiselno, da so prisotni tudi vsi linijski managerji tistih oddelkov, iz katerih prihajajo člani projektnega tima. Po potrebi so vabljeni tudi predstavniki pogodbenih izvajalcev ter morebitni svetovalci.

Najpomembnejše vsebine predstavitve elaborata

Vsebine predstavitve elaborata*

Sestanek mora biti usmerjen v vsebine, ki so »pomembne za obe skupini« – projektni tim in nadrejene. Slednjih ne zanimajo vse podrobnosti plana, zato v predstavitev vključimo le bistvene informacije, podrobnosti pa si udeleženci lahko preberejo v svoji kopiji elaborata, ki jim jo je priporočljivo poslati skupaj z vabilom na sestanek. Namesto podrobnega plana z npr. 150 aktivnostmi jim predstavimo le plan faz izvedbe s ključnimi dogodki in okvirno taktiko izvedbe. Stroški se prikažejo po vrstah glede na faze, predstavimo nekaj najpomembnejših tveganj s preventivnimi ukrepi. Za projektni tim je pomembno, da se potrdi razporeditev vseh potrebnih izvajalcev iz oddelkov na projekt ter da se razčistijo in potrdijo pristojnosti in odgovornosti glavnih udeležencev projekta.

Nadrejenih po drugi strani običajno tudi ne zanima, kako bo manager projekta zbiral poročila s strani podrejenih, da bo ustrezno kontroliral projekt, kako bo obvladoval dokumentacijo in na kakšen način bo zagotovil usklajeno sodelovanje izvajalcev. Zato teh vsebin ni nujno predstaviti na sestanku.

Ob koncu sestanka se lahko sprejmejo štirje alternativni sklepi:

  • elaborat se potrdi nespremenjen;
  • elaborat se potrdi z manjšimi spremembami, ki se zabeležijo v zapisniku predstavitve;
  • elaborat se ne potrdi, projektnemu timu pa se da na voljo še nekaj časa, da spremenijo določene nedorečenosti;
  • elaborat se ne potrdi, projekt se zamrzne (v kolikor se ugotovi, da je npr. podrobna analiza stroškov pokazala, da projekt ne bo povrnil vloženih sredstev v ustreznem času).

Do sedaj sem se bolj ali manj usmeril v interne projekte (z notranjim naročnikom). Malce drugače je seveda, če je naročnik zunanji ali če pri projektu sodeluje več partnerskih združb. V primeru, da se bo izvedel projekt za zunanjega naročnika se pred oddajo ponudbe običajno v »izvajalski« združbi izvede krajši usklajevalni sestanek v ožji zasedbi, kjer se potrdita plan in ponudbena cena. Glede na vrsto povpraševanja (zasebno, javni razpis) pa se plan (seveda brez internih stroškov in tveganj) predstavi naročniku. V primeru več vključenih partnerskih združb se lahko glede na kompleksnost projekta pred končno potrditvijo izvedejo interni potrditveni sestanki, na koncu pa se izvede še skupen sestanek.

Priprava projekta – trajanje in sodelujoči

Doslej sem večinoma pisal o področjih, ki jih je potrebno obravnavati v fazi priprave projekta, oziroma o vsebini elaborata, ki nastaja v toku priprave. Velikokrat pa se v združbah sprašujejo, koliko časa sploh posvetiti pripravi projekta in kdo naj pri tem sodeluje.

Kar se trajanja priprave projekta tiče, še nisem zasledil neke »formule«, in verjamem, da je tudi ni možno razviti, saj obstaja preveč različnih vplivnih dejavnikov. Poleg pričakovanega trajanja projekta so to še kompleksnost (število vključenih strokovnih področij, ljudi, oddelkov in zunanjih izvajalcev), (ne)jasnost in (ne)usklajenost videnja končnih ciljev, ter seveda razpoložljivost ljudi, vključenih v pripravo. V literaturi sem našel le eno priporočilo, kjer Wysocki (2009) glede na velikost projekta predlaga trajanje priprave projekta od nekaj ur do nekaj mesecev (slika).

Projekta ne planira le projektni manager, kar je na žalost dokaj običajna praksa v združbah z nižjo projektno kulturo in napaka manj izkušenih managerjev projektov. Star slovenski pregovor pravi »več glav več ve«, zato bo plan boljši, če pri pripravi sodeluje več članov tima. Ker je skoraj nemogoče najti managerja, ki bi zadosti podrobno poznal vsa v projekt vključena strokovna področja (tehnologijo, potrebno delo, morebitne probleme, ipd.), je najbolje, da pri pripravi sodeluje po en predstavnik vsake stroke. Poleg tega je sodelovanje za bodoče izvajalce tudi neke vrste motivacijski dejavnik – večja verjetnost je, da bo nekdo dobro izpeljal svoje naloge, če bo predhodno lahko podal svoje mnenje o zahtevnosti, ocenil potrebno delo, ipd. Poleg tega v primeru timskega planiranja sodelujoči govorijo o »našem projektu«, če pa plan izdela manager projekta samostojno, pa mu člani tima v primeru kasnejše neustrezne izvedbe radi učitajo, da »njegov« projekt ne teče po planu, ker da si je zamislil nemogoče roke…

Priporočljivo trajanje priprave projekta in udeleženci planskih delavnic

Trajanje priprave oz. planiranja projekta in sodelujočiVir (trajanje priprave): Wysocky, 2009

Jedro planskega tima torej predstavljajo manager projekta in strokovni nosilci, po potrebi pa zavoljo kakovostnejšega plana sodelujejo tudi linijski managerji ter seveda predstavnik uporabnikov ter skrbnik projekta. V združbah, kjer se izvaja veliko projektov imajo običajno vzpostavljeno projektno pisarno (PMO, project management office), ki poleg drugega skrbi tudi za organizacijsko učenje in prenos dobre prakse z zaključenih na nove projekte. Tako lahko pri planiranju projekta sodeluje tudi predstavnik PMO (opremljen s podatki predhodnih projektov), ki je hkrati namesto managerja projekta lahko tudi moderator priprave projekta. PMO lahko zagotovi tudi »planerja«, nekoga, ki zelo dobro obvladuje orodja in tehnike planiranja projektov.

Wysocki planske sestanke imenuje JPPS (Joint Project Planning Session). Posamezni sestanki, bolje rečeno »planske delavnice«, naj bi tajale od enega do treh dni, vsaka delavnica pa naj bi bila osredotočena na svoje področje (WBS, terminski plan, plan stroškov,…). Prav z namenom, da priprava poteka osredotočeno na trenutno aktualno vsebine (da sodelujoči ne »skačejo« iz ene teme na drugo) avtor predlaga moderatorja (ki ga sicer imenuje »povezovalec / pospeševalec« – angl. facilitator). Le-ta naj bi imel veliko izkušenj s planiranjem projektov, po drugi strani pa ni obremenjen z vsebino projekta ampak le skrbi, da delavnice potekajo usmerjeno, s ciljem zaključka elaborata do postavljenega roka.

Naj za konec opozorim tudi na to, da je priprava velikega projekta tudi neke vrste svoj projekt. Če nam nadrejeni dajo tri mesece časa za izdelavo elaborata projekta, potem je smiselno na začetku splanirati, kako se bomo lotili priprave, kdo in do kdaj mora poskrbeti posamezne informacije, itd…

Elaborat (plan, načrt) projekta

Elaborat projekta je končni dokument faze priprave projekta. S potrditvijo elaborata nadrejeni v združbi potrdijo mejnike projekta, način izvedbe, proračun projekta, razmerja med udeleženci in njihove vloge, itd. Formalna potrditev se običajno izvede na predstavitvenem sestanku.

Ob proučevanju tuje literature sem dobil občutek, da je elaborat projekta (Hauc ga imenuje »zagonski«, ker fazo priprave imenuje »zagon«) nekakšen slovenski »izum«, saj nisem nikjer našel primerljivega dokumenta. Podoben občutek sem imel tudi pri opredelitvi faz projekta, kjer avtorji večino govorijo o planiranju projekta (in ne o pripravi), »start-up« fazo, ki jo mi razumemo kot pripravo ali zagon, pa omenja le nekaj avtorjev, pa še ti vanjo vključujejo različne naloge in vsebine. Večino avtorjev najprej opredeli faze projekta, nakar posebej opredeli področja projektnega managementa, pri čemer ne navede, kaj naj bi se opredelilo v fazi priprave.

Vsebina elaborata po različnih avtorjih

Elaborat (plan, načrt) projektaViri: Burke (2010), Turner (2009), Meredith & Mantel (2009), Wysocki (2009)

Vsebino elaborata sem okvirno prikazal že v prispevku, v katerem sem opredelil pripravo projekta. V zgornji tabeli pa predstavljam vsebine, ki jih priporočajo nekateri poznani avtorji. Osebno v elaborat najpogosteje vključujem naslednja poglavja:

  1. Uvod – povzetek naročila z namenom, obsegom in omejitvami
  2. Podrobnejša specifikacija proizvodov projekta – včasih je opredelitev proizvodov, ki jih naročnik posreduje v naročilu nepopolna, zato projektni manager v sodelovanju z naročnikom razjasni dileme in dopolni specifikacijo (ki jo naročnik potrdi s podpisom); občasno so potrebne tudi dodatne analiza in študije;
  3. Plani projekta – taktika izvedbe, WBS, terminski plan, plan virov, plan stroškov, plan obvladovanja tveganj, (opcijsko pa tudi plani kontrole, nabave, zagotavljanja kakovosti, …)
  4. Organizacija projekta – organizacijska struktura, organigram udeležencev projekta, opredelitev vlog, management dokumentacije in informiranja, poslovnik projekta.

Ob pisanju bloga in poglobljenem proučevanju literature sem seveda prišel do novih spoznanj in idej, zato bom v prihodnje razmislil, da v elaborat vključim tudi posamezne vsebine, ki sem jih prikazal v priloženi tabeli.

V združbi, kjer se izvaja veliko projektov, je seveda priporočljivo izdelati organizacijski predpis s področja managementa projektov, kjer je navedeno, katere vsebine je potrebno opredeliti, kdo je odgovoren za posamezne vsebine (predstavniki oddelkov, člani ožjega tima) in kdo sploh sodeluje pri pripravi elaborata. Da bi olajšali pripravo in potrjevanje elaborata, je smiselno izdelati obrazec, mogoče tudi s kakšnimi primeri vsebin…

Poslovnik projekta – pravila (so)delovanja tima

Beseda »poslovnik« je znana predvsem tistim, ki se v združbah ukvarjajo z organizacijo in kakovostjo. Poslovniki, imenovani tudi organizacijski predpisi, običajno opredeljujejo način izvajanja določenih procesov (določa potek, vloge udeležencev, dokumentacijo, orodja, obrazce…) ali pa le pravila delovanja določene skupine ljudi.

Organizacijski predpis naj bi zagotavljal enotno izvajanje projektov v združbi, s poslovnikom konkretnega projekta pa manager opredeli način delovanja tima ter način sodelovanja z ostalimi deležniki projekta. Pri tem se mora seveda držati pravil iz organizacijskega predpisa, v kolikor so le-ta opredeljena (npr. kako pogosto mora manager projekta poročati svojemu skrbniku).

Eno od pomembnejših zadev, ki se opredelijo v poslovniku, je prav način poročanja, v prvi vrsti seveda način poročanja članov tima managerju projekta, da bi bil le ta stalno na tekočem s stanjem projekta (kontroliranje!). Določi se pogostost poročanja, podatke, ki morajo biti navedeni v poročilu ter kdaj bo poročanje ustno in kdaj pisno (nekaj sem o tem pisal že v prispevku  Plan kontrole projekta).

Poslovnik projektnega tima *

Ustno člani tima najobičajnejše poročajo na rednih kontrolnih sestankih (angl. progress meetings), zato se v poslovniku določita termin in lokacija teh sestankov, hkrati pa se lahko že rezervira prostor za celotno trajanje projekta. Opredelijo se tudi stalni udeleženci teh sestankov (običajno člani ožjega tima). Kontrolni sestanki se tako med izvedbo projekta posebej ne sklicujejo!

Predvsem v primeru večje fizične oddaljenosti članov tima je potrebno tudi doreči način komuniciranja, kar je še posebej pomembno, če sodeluje več združb, če se udeleženci med seboj še ne poznajo oziroma še niso sodelovali. Odločimo se, ali bo komunikacija tekla le po e-pošti, po telefonu, ali se bodo uporabljale mogoče video konference ali IP telefonija. V poslovniku se v ta namen tudi navedejo ustrezni kontaktni podatki sodelujočih v projektu.

Wysocki (2009), ki govori o »operativnih pravilih tima«, predlaga, da se na začetku projekta določijo tudi postopki / pravila reševanja problemov, odločanja v timu, reševanja konfliktov, doseganja konsenzov ter kdaj in kako je potrebno uporabiti tehnike ustvarjalnega razmišljanja. Tem področjem bi lahko dodali tudi opredelitev procesa obravnavanja sprememb.

Omenil sem že poročanje managerja projekta skrbniku. Glede na njun dogovor se v poslovnik zapiše npr. »Manager in skrbnik projekta se redno sestajata zadnjo sredo v mesecu ob 13h v pisarni skrbnika, dva dni prej pa se skrbniku pošlje pisno poročilo. Vmesni sestanki se izvedejo po potrebi.«

Prav tako se v poslovniku projekta lahko opredeli morebitno redno sodelovanje z linijskimi managerji (npr. da se bo manager razvoja enkrat mesečno udeleževal kontrolnih sestankov). Pri internih projektih se lahko opredeli tudi sodelovanje s končnimi uporabniki, medtem ko je način sodelovanja z zunanjim naročnikom običajno opredeljen v pogodbi. Enako običajno velja tudi za sodelovanje z zunanjimi izvajalci in svetovalci, vseeno pa so povzetki dogovorjenih pravil lahko vključeni tudi v poslovnik projekta.

Vpliv neformalne organizacije na projekt

Ne glede na formalno strukturo združbe ali projekta vedno obstaja tudi neformalna organizacija, ki običajno sloni na prijateljstvu in obslužbenih interesnih dejavnostih (šport, kultura, ipd.), povezave pa izhajajo tudi iz druženja v preteklosti (šola, sosedstvo, delo na istem projektu).

To ustvarja komunikacijske kanale, ki lahko pospešijo izvajanje projekta, predvsem zaradi širjenja dobre prakse med prijatelji in znanci ter pomoči pri problemih. »Prijatelji« članov tima na vplivnejših delovnih mestih v združbi lahko z odkrito podporo projektu zagotovijo višjo prioriteto, boljše kadre, pa tudi »več zanimanja za projekt« s strani najvišjega vodstva. Slednje je predvsem pomembno v primeru, da se projekt »zatakne« v enem od oddelkov, pa ima manager projekta premalo avtoritete, da bi izvedbo premaknil z mrtve točke.

Ne smemo pa pozabiti, da žal obstajajo tudi »negativne« neformalne povezave (nenaklonjenost, antipatičnost, sovražnost), ki lahko izhajajo iz močnega rivalstva dveh managerjev (katerih ljudje delajo na istem projektu) ali strokovnjakov, velikokrat pa so posledica dogodkov iz preteklosti (nerešeni konflikti v službi ali izven nje, potegovanje za isto službo ali dekle). Če je eden od članov uprave moj starejši sosed, s katerim nimam najboljših odnosov, bo vedno našel kaj, s čemer bo lahko škodoval našemu projektu… Pomembno je, da se tim zaveda teh »notranjih vplivnežev« ter že v fazi priprave projekta pripravi ustrezno taktiko sodelovanja.

Neformalne povezave med zaposlenimi

Neformalna organizacija*

Neformalna organizacija ima velik vpliv predvsem na izvajanje projektov, s katerimi uvajamo spremembe v delovanju združbe (nove metode, spremembe procesov / organiziranosti), pomembno vlogo pa ima pri vseh projektih v primeru nedorečenih prioritet in s tem povezanih »ozkih grl« (premalo ljudi, čakanje na interne storitve). Prej mi bodo izdelali prototip, če bom nekomu, s katerim sva »na ti« rekel »Tole bi nujno potreboval do jutri. Dobiš za pijačo!«, kot pa, če bom nastopil »uradno«, odgovor pa bo »Gospod inženir, izdelava vašega prototipa pride na vrsto naslednji teden.«

Res je, da preveč »neformalnega delovanja« prinaša kaos v delovanje združbe, vseeno pa po drugi strani s tem dvignemo prilagodljivost v primeru sprememb in problemov. Iznajdljivi managerji projektov vsekakor koristijo »poznanstva«.

Če že omenjamo »prijateljske povezave« lahko omenim še prijatelje in poklicne kolege izven združbe, kjer se izvaja projekt. V prvi vrsti nam znanci in predvsem poklicni kolegi lahko pomagajo z nasveti in s svojimi izkušnjami (zato tudi obstajajo poklicna združenja, kot npr. ZPM). Poznanstva pridejo prav tudi v primeru, ko poskušamo kje pospešiti obravnavo našega projekta. Žal pa je zadnje čase koriščenja poznanstev v Sloveniji že kar malo preveč, saj so mnogi izgubili občutek »legalnega / legitimnega«, kar pa je spet svoja zgodba…

Matrika pristojnosti in odgovornosti (RAM / RAC)

Z organigrami sem v predhodnih prispevkih prikazal razmerja med udeleženci projekta, danes pa bom prikazal še eno pomembno orodje, ki ga tudi lahko prištevamo v področje organiziranja projekta – matriko pristojnosti in odgovornosti.

Pri tujih avtorjih sem zasledil dve kratici, s katerimi poimenujejo matriko – RAM (responsibility assignment matrix) in RAC (responsibility and competence), nekateri jo imenujejo  le matrika odgovornosti, spet drugi pa linearni grafikon odgovornosti. Z matriko manager projekta zagotovi jasne vloge udeležencev projekta in prepreči kasnejše nesporazume in konflikte v stilu »Za to pa jaz nisem odgovoren!« ali »Tu bi morali pridobiti tudi moje mnenje!«. Pomembno je opredeliti tudi to, kdo dejansko potrdi ustreznost rezultatov neke aktivnosti in s tem zaključek le-te – je to izvajalec sam, njegov nadrejeni, manager projekta, naročnik ali…?

Včasih so managerji v matriko vključili vse aktivnosti ter vse izvajalce projekta. Po tistem, ko so moderna računalniška orodja omogočila planiranje izvajalcev posameznih aktivnosti neposredno v gantogram, pa se le-ti posebej ne vnašajo tudi v matriko. Osebno priporočam, da se v matriko vključijo vsebinski sklopi aktivnosti (glede na obseg projekta, taktiko izvedbe in členitev dela – WBS), vloge pa se določijo za člane ožjega tima, managerja projekta, skrbnika, naročnika (uporabnika), po potrebi pa tudi za glavnega managerja in vključene linijske managerje.

Primer matrike pristojnosti in odgovornosti

Pristojnosti in odgovornosti - responsibility assignment matrix*

Z večje projekte je matrika lahko izdelana v več nivojih, pri čemer nekatere pomembnejše sklope lahko po potrebi še podrobneje razdelamo (slika). Za izbiro števila nivojev in podrobnost delitve pa ni nekega splošnega recepta, ampak je to stvar ocene ožjega projektnega tima v fazi priprave projekta.

In kakšne so vloge, pristojnosti in odgovornosti, ki se vnašajo v matriko? Včasih je bila najpogostejša vloga »izvede«, ki pa jo je kasneje (zaradi določitve izvajalcev v sklopu gantograma) nadomestila vloga »odgovoren«. Le-ta ne izvaja aktivnosti, ampak je odgovoren, da jih izpeljejo sodelavci in/ali zunanji izvajalci, ki jih vodi ali koordinira. Zelo pomembna vloga je »potrdi« (primer z drugega odstavka), veliko se uporabljajo tudi »sodeluje« (kadar je potreben manjši vložek druge stroke…), »poda mnenje« (nujna vključitev vplivnejšega managerja), »je informiran«, »odloči«, »kontrolira« ipd. Posameznik ima lahko na eni aktivnosti več vlog (npr. sodeluje in potrdi).

Običajno se v matriko navedejo prve črke vloge (O – odgovoren, S – sodeluje, ipd.), lahko se nadomestijo s številkami ali znaki. Vsekakor je potrebno na dnu dodati legendo izrazov. Pomembno je, da ima vsaka vrstica en »O« in vsaj en “P”!

Naj povem še to, da se matrika običajno uporablja tudi za opredelitev vlog, pristojnosti in odgovornosti oddelkov in vrhnjega managementa za tipične faze in aktivnosti posameznih tipov projektov v združbi, kar pomeni, da je (obvezni) del organizacijskega predpisa. Matrika, ki se nato izdela v sklopu konkretnega projekta, pa vključuje konkretna imena, poleg tega pa ima podrobnejšo razdelitev nalog.

Organiziranje izvajalcev projekta – OBS / RBS

Včasih združba, v kateri se izvaja projekt, ni velika ali ni razdeljena po oddelkih (manjše podjetje, društvo, neformalna skupina), poleg tega je lahko v projekt vključenih le nekaj internih ljudi (zaposlenih, članov društva), večino dela pa izvedejo zunanji izvajalci. V tem primeru ne moremo opredeliti projektne organizacije, prikazane v predhodnih prispevkih. Vseeno pa je zavoljo jasnejše opredelitve razmerij med člani tima smiselno izdelati organigram sodelujočih na projektu.

Navedel sem že, da običajno obstajajo trije nivoji projektnega tima – ožji tim strokovnimi nosilci, širši tim (zaposleni v podjetju oz. člani društva, ki sodelujejo pri izvedbi aktivnosti) ter zunanji izvajalci. Projektni manager in strokovni nosilci koordinirajo delo ostalih, ki jim poročajo o izvedbi aktivnosti. Kdo sodeluje s kom, kdo komu delegira naloge in komu kdo poroča, se običajno prikaže v posebnem organigramu, katerega tuji avtorji imenujejo RBS (Resource Breakdown Structure).

Sicer pa v tuji literaturi poleg RBS najdemo tudi OBS (Organizational Breakdown Structure), a ne gre za različno poimenovanje istega ampak za dva različna organigrama. Oba tipa sta nadgradnja WBS, še bolje rečeno, WBS je osnova za izdelavo OBS in RBS. Razjasnitev razlik med vsemi tremi pojmi sem zasledil v PMBOK (2000) ter pri Levinu (2002):

  • WBS prikaže členitev proizvodov na delovne pakete,
  • OBS prikaže strukturo oddelkov združbe, vključenih v projekt,
  • RBS prikaže členitev tima po skupinah strokovnjakov iste stroke ali oddelka (npr. programerji) ali po sklopu aktivnosti, povezanem z delom obsega projekta, (npr. programska oprema)

Primer RBS – Organizacija gasilske veselice

Organigram izvajalcev projekta*

Newel (2002) navaja, da so v OBS delovne naloge iz WBS povezane z oddelki, ki bodo naloge izvedli, drugi avtorji pa poudarjajo, da OBS prikazuje oddelke združbe, ki so zadolženi za izvedbo sklopa aktivnosti oz. ki prevzamejo zaokroženo celoto obsega del. Fleming še dodaja, da je z OBS prikazana hierarhija odgovornih za izvedbo nalog po WBS-u do najnižjega managerskega nivoja. Vsak oddelek združbe tako lahko jasno vidi, za kaj je odgovoren!

RBS sem prikazal, ko sem opisoval vlogo tipičnih udeležencev projekta. Newel poudarja, da je razlika med OBS in RBS v tem, da prikaže RBS vse posameznike, ki so navedeni kot izvajalci aktivnosti v terminskem planu, OBS pa prikaže le oddelke. Čeprav je res, da oba organigrama v tuji literaturi nista prav pogosto prikazana, pa se mi zdi predvsem uporaba RBS zelo koristna. Z RBS, ki bi ga lahko poslovenili kot organigram izvajalcev projekta, nazorno prikažemo »podtime« (kateri nosilec s katerimi člani širšega tima pokriva določeno področje), poleg tega pa tudi opredelimo, kdo od internih članov tima je zadolžen za komunikacijo in kontrolo delovanja zunanjih izvajalcev. Nasprotno se mi uporaba OBS ne zdi smiselna, če smo predhodno vključene oddelke (in člane tima iz teh oddelkov) prikazali v sklopu matrične organizacije.

Ko smo že pri členitvah izvajalcev projekta, naj povem, da sem našel tudi CBS (contractor breakdown structure, Brandon, 2006), kjer podobno, kot za interne udeležence projekta, izdelamo hierarhično strukturo vseh podizvajalcev. Vendar pa je CBS za končnega naročnika zgolj informativnega značaja, saj nimajo neposrednega vpliva na pogodbene izvajalce, ki so dejansko podizvajalci naročnikovih podizvajalcev (pogodbe, kontroliranja dela).

Šibka in močna matrična organizacija

Čeprav bi glede na izkušnje lahko rekel, da sta šibka in močna matrična tisti organizaciji, ki jih osebno najbolj priporočam, pa le redki avtorji prejšnjič prikazano matrično organizacijsko strukturo še podrobneje delijo na šibko, uravnoteženo in močno.

Glavna razlika med vsemi tremi je v pristojnostih managerja projekta in s tem povezano “razpoložljivostjo” članov tima. V primeru uravnotežene naj bi imela linijski in projektni manager enakovreden vpliv na člane tima, ki naj bi projektu posvečali pol svojega časa. Napisal sem “naj”, ker je ta »polovička« nekako težko določljiva, poleg tega pa v PMBOK navajajo, da so pristojnosti managerja projekta nizke do zmerne, kar je tudi zelo”relativno” in močno odvisno od projektne organizacijske kulture. Zato je bolj smiselno razmišljati o šibki ali močni matrični organizaciji, ki sta jasneje določljivi in tudi v praksi manj konfliktni.

Šibka matrična struktura je zelo podobna funkcijski, z eno pomembno razliko – obstaja odgovorna oseba, ki skrbi za učinkovito izvedbo projekta. Običajno se imenuje koordinator projekta in ima nižje pristojnosti kot običajen manager projekta, s tem pa tudi manj odgovornosti. Odgovoren je za planiranje in kontroliranje projekta, kar pa se tiče izvedbe, pa koordinira oddelke, med tem ko so linijski managerji odgovorni za izvajanje aktivnosti. Koordinatorju neposredno ne dodelijo članov tima, čeprav lahko sodeluje z izvajalci iz oddelkov, ki pa se glede na taktične odločitve njihovih nadrejenih lahko menjajo. Koordinator lahko vzporedno koordinira več projektov, uporaba te organizacije pa je priporočljiva za organizacijsko enostavnejše prodajne in inženiring projekte.

Šibka in močna matrična organizacijska struktura

Šibka in močna matrična organizacija*

Močna matrična struktura je z vidika pristojnosti managerja projekta zelo podobna čisti projektni organizaciji, razlikuje pa se v tem, da člani tima ostajajo v matičnih oddelkih, a večino svojega delovnega časa posvečajo enemu projektu. Ker več sodelujejo s projektnim kot z linijskim managerjem ima prvi načeloma tudi več vpliva na izvajalce. Projektni manager je polno odgovoren za projekt, linijski managerji pa mu dodelijo osebje s polnim ali delnim delovnim časom in strokovno svetujejo pri izvedbi aktivnosti. Pri tej organizacijski strukturi manager projekta običajno posveča celoten delovni čas le enemu projektu.

Žal pa si nekateri matrično organizacijo predstavljajo po svoje, kar sem omenil že prejšnjič: »managerji projektov so strokovnjaki, ki poleg strokovnega dela tudi koordinirajo projekt«. Ta rešitev ni priporočljiva, saj združba s tem lahko izgubi vrhunskega strokovnjaka in dobi slabega managerja. Petrovo načelo (človek napreduje do nivoja svoje nesposobnosti) se pri projektnem delu izrazi še hitreje, saj so za management projektov pomembne druge osebnostne lastnosti, znanja in veščine, kot za strokovno delo. Nekateri strokovnjaki so neorganizirani, drugim je nelagodno voditi ljudi, se ukvarjati z dokumentacijo in zapisniki, sprejemati odločitve… Management projekta je zato zanje lahko zelo stresno delo, še posebej, ker jih odvrača od njim ljubšega strokovnega dela.

Zato zelo priporočam šibko in močno matrično organizacijo, s sposobnimi organizatorji (koordinatorji, managerji). Projektni management je svoj poklic in je le izjemoma lahko »dodatek« strokovnemu delu.

V prejšnjem prispevku sem tudi omenil, da obstajajo različni položaji managerja projekta v hierarhiji združbe. Danes prikazujem dva primera (slika), kjer je manager / koordinator zaposlen v projektni pisarni (angl. project management office, PMO). Kot vidite, je PMO lahko organizirana štabno ali pa kot oddelek, enakovreden ostalim poslovnim funkcijam ali enotam. O vlogi in lokaciji PMO v združbi bom še pisal, tokrat pa navajam le nekaj možnih funkcij PMO: administrativna podpora projektom, zagotavljanje enotnega načina izvajanja projektov (pravila, postopki, orodja), izobraževanje, svetovanje in mentorstvo, analize projektov in prenos izkušenj, strateški razvoj združbe…

Matrična projektna organizacija

Matrična projektna organizacija je nastala, ko so avtorji poskušali združiti dobre lastnosti (in odpraviti slabosti) funkcijske in projektne strukture. Člani projektnega tima lokacijsko ostanejo v svojih oddelkih, pri čemer lahko opravljajo operativna dela v sklopu matičnega oddelka in hkrati sodelujejo ne enem ali več projektih. Linijski manager poskrbi, da so posamezniki polno zaposleni – če nekdo enemu projektu posveča 30% svojega delovnega časa, ga nadrejeni razporedi še na druge projekte ali mu dodeli druga operativna dela.

Projektni manager tako dobi »na pósodo« ljudi iz različnih oddelkov. Linijski manager je odgovoren, da na projekt razporedi usposobljenega človeka, hkrati pa s svojim znanjem in izkušnjami posredno, preko člana tima, prispeva h kakovostni izvedbi projekta. V primeru, da posameznik projektnih nalog ne izpolnjuje zadovoljivo, oba managerja problem rešujeta skupaj.

Pri matrični organizaciji obstaja več možnih lokacij oz. položajev (fizično, v hierarhiji) managerja projekta – lahko je neposredno podrejen vodstvu (primer na sliki), kar mu daje močno avtoriteto (višje pristojnosti, večja podpora vodstva). Lahko je zaposlen v projektni pisarni, kjer so zaposleni profesionalni managerji projektov, nadrejeni pa je običajno manager portfelja / skrbnik projektov. Zelo pogosto pa so managerji projektov kar strokovnjaki, ki so locirani v svojem matičnem oddelku, poleg svojega strokovnega dela pa tudi koordinirajo projekt. Sledna rešitev ni ravno priporočljiva, več o tem pa naslednjič.

Matrična organizacijska struktura

Prednosti projektno matrične organizacije:

  • optimalna obremenitev članov tima, odpravi se podvajanje dela, strokovnjaki lahko delujejo na več projektih;
  • večja prilagodljivost spremembam v okolju, tehnologiji ali spremenjenim zahtevam kupcev;
  • dobri informacijski tokovi – horizontalno in vertikalno;
  • člani tima ohranjajo stik s stroko, svoje ideje lahko prediskutirajo s kolegi.

Slabosti:

  • problem »dvojnega vodenja« – izvajalec je za izvedbo aktivnosti podrejen managerju projekta, strokovno in disciplinsko pa funkcijski vodji; v primeru konfliktov med nadrejenimi, člani tima trpijo zaradi nedorečenih prioritet svojih nalog in preobremenjenosti;
  • nejasna razmejitev pristojnosti in odgovornosti med projektnim in linijskimi managerji, še posebno v primeru slabo razvite projektne kulture;
  • je kompleksna in težja za upravljanje v multi-projektnem okolju –  v primeru sprememb in reševanja zamud je premeščanje ljudi s projekta na projekt zelo zahtevno.

Pa še to – management projektov v matrični organizaciji je zelo praktičen način izobraževanja, neke vrste trening za bodoče najvišje managerje. Projektni manager mora usklajevati ljudi z različnimi strokovnimi stališči in pogledi, z različnimi vrednotami in načini delovanja. Skozi projekte spozna specifiko posameznih strok in oddelkov, ljudi, način dela in razmišljanja. Po nekaj projektih zelo dobro pozna celotno podjetje…

Page 1 of 3

Powered by WordPress & Theme by Anders Norén