Blog, debatni večeri, raziskave, knjiga…

Category: Organizacija projekta

Agilna organizacija

V zadnjih letih se je močno uveljavil pojem »VUCA« svet. VUCA je kratica besed nestanovitnost, negotovost, kompleksnost in nejasnost (angl. volatility, uncertainty, complexity, ambiguity). Načeloma pa že kakih 30 let govorimo o tem, da je sprememba edina stalnica našega službenega in privatnega življenja. Informacijska revolucija je res »vrgla svet s tečajev«.

Seveda je vsem jasno, da se je spremembam v okolju treba prilagajati, če želiš preživeti in biti konkurenčen, zato se spreminja tudi organiziranost podjetij in drugih združb (organizacij). Res je, da se vse branže ne spreminjajo enako hitro, pa tudi velikost podjetja (in s tem povezan tržni položaj) vpliva na nujnost in hitrost spreminjanja. Sicer nismo nikjer zasledili trditev, da bi se morale vse združbe nujno prestrukturirati, poglejmo pa, kaj razumemo pod pojmom agilna organizacija in na kakšen način se tradicionalne prelevijo v agilne.

Ob proučevanju literature smo se hitro spomnili na projekte informatiziranja poslovnih procesov, ki so se začeli v 90-tih letih prejšnjega stoletja. Informatizacija je seveda zahtevala tudi prenovo poslovnih procesov, saj je programska oprema avtomatizirala mnoge postopke in procese. Zgodila pa se je tudi velika sprememba v delu managerjev. Naj spomnimo, ključna vloga managerjev je usklajevanje (aktivnosti, zaposlenih, sredstev) ter odločanje (organizacijsko, vsebinsko in strokovno), procesno gledano pa management vključuje planiranje izvajanja nalog, organiziranje ljudi, vodenje ljudi in kontroliranje izvedbe. Pomembno »vsebinsko« področje je tudi skrb za zadovoljivo usposobljenost podrejenih, kar pomeni, da skrbijo za redna dodatna izobraževanja in usposabljanja.

Ukinitev managerskih ravni za večjo agilnost organizacije

V omenjenem času informatizacije pa se je obremenjenost managerjev z navedenimi nalogami močno zmanjšala, saj so njihovi podrejeni začeli dobivati mnogo nalog mimo njih (poslovni procesi!), z opolnomočenjem ljudi pa se je veliko odločanja delegiralo na nižje ravni – manager je po uvedenih spremembah npr. odločal le še o 20% izjemnih primerih, med tem, ko je podrejeni sam sprejel 80% strokovnih (vsebinskih) odločitev. Z manj usklajevanja (kdo bo kaj naredil) in odločanja se je obremenitev managerjev z operativnim delom znižala, zato so mnogi strokovnjaki takrat trdili, da bi morali managerji po novem 50% svojega časa posvetiti razmišljanju, kako bi svojim podrejenim olajšali delo (sistem, metode, dodatna znanja, ipd).

Po drugi strani se je – vsaj tako je slutiti iz mnogih »agilnih« člankov – odvijala borba med izvajalci aktivnosti in managerji projektov (če se omejimo le na projekte, kjer se je agilni pristop najprej uveljavil). Po mnenju prvih, so managerji postavljali nerazumne roke in pozabili, da odličnega managerja – poleg organizacijskih – krasijo predvsem njegove voditeljske veščine. Ne trdimo, da je to ključni vzrok, da so »agilneži« začeli zagovarjati samo-organizirane time (v smislu »postite nas pri miru, mi bolje vemo, kako je treba kaj narediti, kot vi«), je pa vsekakor eden od pomembnejših razlogov.

Žal pa tudi pri samo-organiziranih timih ne gre vse brez težav, poleg tega se v »agilnem svetu« nekako zanemarjajo osebnostne lastnosti ljudi – predpostavlja se, da so vsi ljudje enaki ali vsaj zelo podobni, ne glede na to, da je nekdo bolj ustvarjalec, drugi voditelj, tretji analitik in četrti »prodajalec«. Da ne govorimo o tem, da so nekateri bolj timski delavci, kot drugi, eni bolj uživajo v svojem delu, eni živijo za kariero, ipd. Tako se je pojavila »formalna vloga« uslužnega vodje (o čemer smo že pisali), torej nekoga, ki je koordinator tima, katerega član je, ne pa kot nadrejeni manager.

Vse navedeno je nekako pripeljalo do tega, da so moderne agilne organizacije zmanjšale število managerski ravni, managerji pa so se pridružili timom, katerimi so bili prej nadrejeni (slika 1). No, težko je reči, da so se take spremembe res dogajale v večjih starejših organizacijah, vsekakor pa so mlajše organizirane bolj plosko. Opozorimo pa še na to, da je o agilni organizaciji veliko lažje govoriti v primeru »virtualnih« izdelkov oz. storitev (torej, kadar podjetja ne proizvajajo fizičnih izdelkov) – IT podjetja, storitve bančništva in zavarovalništva, marketinške agencije, spletne rešitve, ipd…

Kot trdi Holub (2015), je šel proces prestrukturiranja še naprej. Kot vidite na desni strani prve slike, so »nadrejeni« narisani pod izvajalskimi timi. Avtor trdi, da »nadrejeni« v agilnih organizacijah ne ukazujejo, delegirajo in kontrolirajo, ampak »uslužno« skrbijo, da timi ustvarjajo š čim manj težavami. No, nekdo mora tudi poskrbeti, da timi proizvajajo »prave stvari«, kar pomeni, da imajo nadrejeni še vedno pristojnosti odločanja, kateri projekti se bodo izvajali.

Agilna organizacija – managerji se preselijo v time

Mnogi »agilni« avtorji tudi omenjajo »silose«, kot značilnost zastarelih organizacij. Saj veste, gre za sindrom »mi in oni … mi smo najboljši, z njimi si ne moremo pomagati«, kar naj bi pomenilo, da se oddelki brigajo le za svoje naloge in težko sodelujejo z drugimi. Res se to še dogaja, a v bolj mili obliki, kot včasih. Predvsem pa so več-disciplinarni projektni timi (ki se niso pojavili šele z agilnostjo) promotorji in spodbujevalci sodelovanja med različnimi strokami in oddelki. No, poleg projektne matrične organizacije obstajata tudi produktno ali regijsko matrična organizacija, ki spodbujata sodelovanje in rušita silose in nevidne zidove med oddelki.

»Agilna nadgradnja« matričnih organizacij pa je prej omenjeno vključevanje managerjev / vodij v delo timov (desna stran slike 2). Managerji projektov so tako postali uslužni vodje timov, managerji področij (funkcijski, regijski, produktni) pa strokovni koordinatorji svojih področij. Poleg tega, da na enem projektu opravljajo svojo strokovno nalogo (kot član tima), so povezovalci vseh zaposlenih iz svojega področja, kjer skrbijo za razvoj stroke in medsebojni prenos dobre prakse (ter opozarjanje na težave in slabo prakso). Naj omenimo še to, da so v nekaterih agilnih organizacijah time preimenovali v moštvo (angl. squad), če pa ima projekt več timov, pa se skupaj imenujejo pleme (angl. tribe).

Za konec pa še – bolj za šalo, kot zares – pohvalimo »agilno« zavest slovenskih managerjev. Čeprav strokovnjaki stalno poudarjamo nujnost profesionalizacije projektnega managementa (zaradi potrebnih organizacijsko vodstvenih veščin managerjev), se v naši praksi to relativno slabo upošteva. Tako projekte – poleg svojega strokovnega dela – vodijo ključni strokovnjaki, kar je v vseh pogledih agilno. Ali pa imajo najboljši »kreativci« tudi sposobnosti uslužnega vodje, je pa že druga zgodba…

Projektna pisarna (PMO)

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

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

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

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

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

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

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

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

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…

Projekti v funkcijski organizaciji ter projektna organizacija

V prejšnjem, uvodnem prispevku s področja organiziranja projektov, sem navedel, da si večina pod »organizacijo projekta« predstavlja tipične organizacijske strukture, s katerimi je opredeljeno razmerje med projektnim timom in nadrejeno organizacijo. Zato bom v naslednjih nekaj prispevkih predstavil te strukture. Za začetek si oglejmo izvajanje projektov v funkcijski organizaciji ter njeno popolno nasprotje, vsaj kar se tiče pristojnosti managerja projekta, (čisto) projektno organizacijo.

Klasično linijsko – funkcijsko organizacijo si predstavljamo z bolj ali manj tipičnimi oddelki (proizvodnja, nabava, prodaja, razvoj…), pri čemer obstajata dva tipa projektov, ki se izvajata v taki organizaciji. Pri prvem večino aktivnosti izvedejo v enem oddelku, manager oddelka pa je odgovoren za projekt (uvajanje spremembe, npr. IT podpore). V drugem primeru pa oddelki zaporedno izvajajo posamezne sklope aktivnosti, brez da bi pri tem resneje sodelovali. Zaradi tega mnogokrat pride do kritiziranja rezultatov aktivnosti predhodnikov, s tem pa do popravil ali celo do vračanje projekta v prejšnjo fazo. V veliko primerih se za te projekte ne določi odgovornega za celoten projekt, ampak je vsak funkcijski manager je odgovoren za svoj del. Zaposleni, ki opravljajo »projektne aktivnosti«, niti ne čutijo pripadnosti projektu, saj so te aktivnosti zanje »vsakodnevno operativno delo«, ki jim ga delegira nadrejeni.

Funkcijska in projektna organizacija*

Takšna organizacija izvajanja projektov je vse manj v uporabi, značilna pa je za združbe z nizko stopnjo projektne organizacijske kulture. Težko bi celo rekli, kdaj je njena uporaba smiselna; mogoče le v manjših podjetjih, kjer projektov ni veliko in niti niso zelo pomembni. Vsekakor pa je pomembno, da določimo nekoga, ki poskrbi za koordinacijo vseh oddelkov v združbi in je odgovoren za celoten projekt. Največkrat ima naziv koordinator projekta (Kerzner govori o »Line staff organisation«), vendar pa je to že neke vrste (šibka) matrična organizacija. O njej pa drugič…

*

PROJEKTI V FUNKCIJSKI ORGANIZACIJI
  • PREDNOSTI
  • fleksibilnost izkoriščanja kadrov v enoti
  • strokovnjaki delujejo na več projektih
  • skupno reševanje problemov v enoti
  • prenos znanja in izkušenj
  • Enostavno nadomeščanje izvajalcev
  • SLABOSTI
  • redno delo ima prioriteto
  • aktivnosti niso strogo usmerjene h kupcu
  • nihče ni odgovoren za celoten projekt
  • ignoriranje projekta s strani izvajalcev
  • šibka motivacija za delo na projektu

*

O projektni organizaciji, ki jo nekateri poimenujejo tudi »čista projektna« (angl. pure; Kerzner, Lock, Meredith & Mantel), govorimo, ko združba ustanovi začasni samostojni oddelek, kamor se iz matičnih oddelkov za čas izvedbe projekta prerazporedijo uslužbenci, člani projektnega tima. V primeru, da kadri s potrebnimi veščinami in znanjem v združbi trenutno niso na razpolago, se jih za čas projekta na novo zaposli. Vsi zaposleni v oddelku so torej člani projektnega tima in delajo celoten delovni čas le na aktivnostih v sklopu projekta. Nadrejeni oddelka je manager projekta, ki prevzame polno odgovornost za projekt in ima popolno avtoriteto – njegove pristojnosti so enake pristojnostim managerjev ostalih oddelkov, pri čemer slednji na projekt nimajo nobenega vpliva.

Organizacija je najbolj primerna za projekte, kjer se večina aktivnosti izvaja na področju ene stroke, za operativno delo v projektno organiziranih IT, inženirskih ali gradbenih podjetjih ali za hitro izvedbo kriznih projektov.

PROJEKTNA ORGANIZACIJA
  • PREDNOSTI
  • celovit pristop k projektu
  • jasne odgovornosti in pristojnosti v timu
  • spodbuja sodelovanje v timu
  • možno sprejemanje hitrih odločitev
  • izkušen uigran tim za nov projekt
  • SLABOSTI
  • konfliktnost z matično organizacijo
  • slabša motiviranost pred zaključkom
  • slabša strokovnost
  • slaba izkoriščenost ljudi
  • višji stroški projekta (delovne ure)

*

 

Organiziranje projekta

Z današnjim prispevkom prehajam na drugi del priprave projekta – na organiziranje. Pojem »organizacija« ima več pomenov: lahko jo vidimo kot proces zagotavljanja smotrnega delovanja (pogovorno: organizacija dela); kot družbeno (socialno) enoto – združbo, ki deluje zaradi uresničitve skupnega cilja; ter kot sestav medsebojnih razmerij med člani združbe, ki zagotavlja obstoj in razvoj ter smotrno uresničevanje ciljev združbe. Prvi, procesni vidik, smo obdelali s planiranjem projekta, v tem delu pa se bomo posvetili slednjemu.

Večina pod organizacijo projekta najprej pomisli na tipične organizacijske strukture, s katerimi opredelimo razmerje med projektnim timom in nadrejeno organizacijo (npr. matrično ali projektno organizacijo). Tudi večina avtorjev pod tem pojmom v knjigah opisuje značilnosti, prednosti in lastnosti različnih struktur. Vendar pa organiziranje vključuje več stvari – pomembna so še razmerja v projektnem timu ter med vsemi udeleženci projekta (stakeholders), ter jasno opredeljene njihove vloge, pristojnosti in odgovornosti.

Področja organizacije projekta

Organiziranje oz. organizacija projekta*

Pojmi, ki se poleg organizacijskih struktur največkrat pojavljajo v povezavi z organiziranjem in jih bom podrobneje opisal v kasnejših prispevkih, so OBS oz. RBS (Organizational / Resource Breakdown Structure), ki prikaže razmerja med udeleženci projekta (tudi v povezavi z WBS), ter RAC matrika oz. RAM (Responsibility and Competence matrix / Responsibility Assignment Matrix), s katero se določijo vloge, pristojnosti in odgovornosti udeležencev.

Organizacijske strukture se prikažejo z organigramom, ki grafično prikaže oddelke / skupine in posameznike po različnih ravneh, hierarhične odnose, formalne in komunikacijske povezave med njimi. Lahko se nadgradi tudi z opisi delovnih nalog posameznikov in skupin. Višji v hierarhiji določa cilje in delegira naloge nižjim, ki navzgor poročajo o izvedbi nalog.

Organiziranje zagotavlja urejeno delovanje z jasnimi odnosi in odgovornostm ter preprečuje različne možne medosebne konflikte v času izvedbe projekta – npr. izjave, kot so »To pa ni moje delo« ali »O tej zadevi bi nujno morali dobiti še moje mnenje«…

Nekateri med organiziranje vključujejo tudi opredelitev pravil delovanja projektnega tima (npr. način komuniciranja in poročanja), organizacijo obvladovanja dokumentacije in informacij, ter jasno opredelitev sodelovanja z linijskim managementom, svetovalci, naročnikom in drugimi vpletenimi strankami. Omenjena področja bi lahko vključili tudi v plan komunikacij in plan kontrole, a ker jih še nisem podrobneje obravnaval, jih bom prikazal v sklopu organiziranja projekta.

Powered by WordPress & Theme by Anders Norén