Category: Management Page 3 of 6

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

*

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.

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

*

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.

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

*

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

Č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

*

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…