Naloge projektne pisarne, in kaj je novega?

… administrativna podpora, arhiviranje projektne dokumentacije, znanstveno-raziskovalna opazovalnica tekočih projektov? Don't do it! Takšna oblika je prežvečena in tako zelo passé. Bilo je nekoč, prav tako kot dinozavri in vemo, kako so končali.

Vir: DKimages

Dinozavri, razen redkih izjem, niso bili prilagojeni na šoke in spremembe okolja. Projektna pisarna mora biti.

Oblike projektne pisarne (PMO)

• podporna pisarna za potrebe velikega projekta (začasna »organizacijska enota«)
• projektna pisarna za podporo vodenju projektov (klasična projektna pisarna, stalna organizacijska enota)
• programska pisarna (angl. tudi PMO*; organizacijska oblika na ravni programa projektov)

* kratica PMO se v angleščini uporablja glede na kontekst: projektna ali programska.

Nova projektna pisarna

Učinkovita projektna pisarna je hibrid projektne in programske pisarne. Odgovorna je za programe kot za posamezne individualne projekte, tako da na vsak način kratica »PMO« obvelja.

Naloge PMO nadzor in razporejanje virov: človeških, materialnih strokovno vodenje projektov (v primeru da kot organizacijska enota zaposluje vodje projektov) nadzor nad proračunom projektov opreme, stroškov in pogodb s podizvajalci storitev prioretizacija, spremljanje in eskalacija tveganj in odprtih vprašanj na projektih nadzor nad izpolnjevanjem projektnih mejnikov skrb za metodologijo in postopkovna podpora, delovne tokove merjenje uspešnosti in zdravja projektov, statusi za vodstvo obvladovanje portfelja projektov (informacija o ceni količine posameznega projekta, predlogi za »go«-»no go«, »make or buy«) ugotavljanje potreb po izobraževanju in usposabljanjih projektnih vodij skrb za ažurnost informacijskega sistema in skladnost z metodologijo (vsebinske zahteve za storitve razvoja inf. sistema) sprejema in obravnava zahtevke za optimizacijo metodologije in svojega poslovanja od zaposlenih ali zunanjih strank meri zadovoljstvo projektnih članov (izvajalcev), zadovoljstvo naročnika in naročnikovega osebja na in po projektih (išče »room for improvement«) ter ustrezno ukrepa postavlja in uresničuje strategijo razvoja projektnega vodenja in PMO (je pobudnik tovrstnih internih – razvojnih – projektov) preko komunikacije z vodji projektov ugotavlja nove prodajne priložnosti ter jih posreduje v prodajni oddelek spremljanje razpisov in pridobivanje financiranja s strani razvojnih skladov in EU

Po uvedbi osnovnega sistema projektnega vodenja postane organizacija razmeroma hitro ambiciozna in zrela za uvedbo »Nove projektne pisarne«. Takšna projektna pisarna rešuje realne probleme in prispeva k boljšemu poslovanju.

Orodja projektne pisarne:

• zaposleni v PMO: so najbolj dragoceno orodje, saj za učinkovitost in zdrav razvoj potrebujemo pravi »attitude«. Večje kot je število projektov več ljudi PMO potrebuje: vodjo PMO, ter specialiste PMO glede na njene naloge (glej zgoraj). Resne PMO gojijo kulturo projektnega vodenja ter organizacijsko združujejo vodje projektov v svoji sredini.
• podpora vodstva: je najmočnejše »orodje«. Vodstvo se mora zavedati, da na projektih ne sme izgubljati denarja, časa in ugleda. PMO pomeni pomembno varovalko, da se te vrednote zagotavljajo.
• metodologija: postopki in zakonik vodenja projektov v organizaciji. Predstavlja pristope dobre prakse, po katerih vodi naša organizacija projekte. Definira vloge v projektnem vodenju ter načine spoprijemanja z izzivi na projektih.
• informacijska podpora: olajša poslovanje, prihrani čas, energijo, konflikt. Omogoči, da so projektne informacije (tveganja, eskalacije problemov, pridobljene izkušnje, dokumentacija, …) pod nadzorom, da niso pozabljene, in da se na njihovi podlagi lahko pravočasno in učinkovito ukrepa. S postavitvijo skupnega spletnega mesta za projekt spodbudimo sodelovanje naročnika. Informacijska podpora pooseblja metodologijo projektnega vodenja organizacije, tako da zaposlenim ni potrebno na pamet poznati vseh postopkov, iskati med kopico obrazcev in jih papirno izpolnjevati ter jih osebno prenašati ali pošiljati po interni pošti.

Prekrivanje vlog na projektih

V matričnih organizacijah so posameznikom vloge dodeljene glede na potrebe posameznega projekta. Prevzemanje, združevanje ali dodeljevanje več projektnih funkcij na eno osebo lahko povzroči različne učinke zato je potrebno pred takšnim dejanjem pomisliti, kako bo združitev več vlog v isto osebo vplivala na potek in končni izid projekta.

Za Slovenijo, segment manjših in srednjih ter tudi večjih podjetij, je značilno, da projektne vloge niso sistematizirane. Zaposleni prvenstveno opravljajo specifično delo, po potrebi pa so dodeljeni tudi na tekoče projekte. Isti človek tudi znotraj projekta opravlja več vlog (je prodajnik in vodja projekta hkrati, ipd.).

Učinki prekrivanja funkcijskih in projektnih vlog

	Direktor	Prodajnik*	Projektni vodja	Izvajalec	Uporabnik produkta
D	►	Močno sponzorstvo projekta	Visoka prioriteta projekta	Avtoriteta vodje projekta?	Zahtevna pričakovanja do projekta
P*		►	Ukazovalni slog, dobra komunikacija z naročnikom	Ugotovi dodatne prodajne priložnosti	Dobro poznavanje produkta, ki ga prodaja
PM			►	Odmaknjen od vodenja in cilja	»Podaljšana« odgovornost
I				►	Sodelovanje ključnih uporabnikov

* na internih projektih (nekatere organizacije poznajo le interne projekte) v vlogi prodajnika nastopa pobudnik za projekt.

Prekrivanje vlog znotraj projektne ekipe

Če izhajamo iz preproste razdelitve vlog na projektu:

Vodja projekta

Poslovni analitik

Izvajalec (inženir)

Tester

… lahko od združevanja vlog pričakujemo naslednje:

• Vodja projekta + poslovni analitik: imel bo dobro tehnično znanje o zahtevanih rezultatih projekta, hkrati pa bo odgovoren tako za zajem poslovnih in uporabniških zahtev kot tudi za vodenje izvedbe projekta. Na kompleksnih projektih naj si pomaga s tehničnimi specialisti: jim delegira odgovornost nad dokumentacijo uporabniških zahtev glede na posamezno področje, moderira naj proces zajema uporabniških zahtev.
• Vodja projekta + izvajalec: ponavadi (izkušenejši) inženir, ki mu management zaupa vodenje projekta. Osredotočen je na tehnologijo, manj na komunikacijo z naročnikom in vodenje projektne ekipe. Združitev obeh funkcij v isti osebi lahko vodi do osebnega konflikta in zmanjšanje učinkovitosti obeh vlog: vodje in inženirja. Primerno za enostavne, manjše, trivialne projekte, brez vodstvenih izzivov.
• Izvajalec + tester: za vse nas je značilno, da sami nekatere svoje napake, ki ji naredimo pri izvedbi težko ugotovimo. Pisanje bloga je živ dokaz za to.. za seboj lahko trikrat preberem, pa napake ne bom opazil; večina ostalih bralcev pa takoj. Za kakovosten produkt potrebujemo objektiven pristop k testiranju, nepristranski – zato je tudi pomembno, da tester ni ena oseba pač pa ekipa (*tester = »preizkuševalec projektnega izdelka«). Tveganje povzroča predvsem to, ker izvajalec z isto interpretacijo uporabniških zahtev izdelek gradi ter ga potem še testira (*izvajalec = »član projekta, inženir, nosilec naloge…«). Bolje je celo, da izdelek testira nekdo, ki na projektu ni sodeloval, in o produktu razen uporabniških navodil (ali uporabniških zahtev) drugih informacij nima (do sedaj »outsider«, ki pa naj bo že vnaprej imenovan na projekt).
• Poslovni analitik + tester: po mojem mnenju super kombinacija, ki pa ni vedno izvedljiva ali primerna za projekt ali organizacijo. Zakaj super? Poslovni analitik še iz procesa zajema uporabniških zahtev dobro razume subjektivno in objektivno naročnika. Lahko nastopa kot njegov advokat, preden dobi naročnik izdelek zares v roke (sprejemno testiranje).

Ostale kombinacije, ki jih nisem zajel, so seveda tudi realne in povzročajo različne stranske učinke, ki jih organizacije različno občutijo. Pomembno je, da se zavedamo možnosti njihovega »mešanja«, ter se vprašamo: kaj s tem pridobimo, in kaj smo pripravljeni izgubiti (ne pozabimo na odziv zaposlenih ter našo integriteto).

Kako uspešen je (bil) projekt?

Ali kar vemo, ali koga vprašamo, ali počakamo do konca in šele takrat izračunamo njegovo profitabilnost? Dejstvo je, da lahko na uspešnost projekta gledamo z dveh (ali obeh) vidikov:

• zdravje tekočega projekta
• uspešnost končanega projekta
  

Načeloma drži: če je bil projekt vseskozi "zdrav" bo tudi na koncu uspešen.

Zdravje projekta

Koga sploh zanima? Prvi, na operativni ravni, bi moral biti vodja projekta, na strateški ravni pa upniki tega projekta, sponzorji, management. Zato je povsem logično, da je komunikacija med obema ravnema med izvedbo projekta ključnega pomena.

Zdravje projekta lahko ugotovimo na več načinov. Nekateri zgolj povprašajo po mnenju vodje projekta (POZOR: pazite se vodij projektov, ki ne znajo reči "NE"!), sam pa priporočam uveljavljeno metodo merjenja "zdravja" projektov EARNED VALUE MANAGEMENT (EVM) v smislu napredka, porabe čase in stroškov.

Vir: Nasa

Razlaga Nasinega primera: zelena krivulja ("S-krivulja", angl. "S-curve") prikazuje "Earned value" (koliko od projekta je NASA že izvedla), modra prikazje planirano vrednost (vidimo, da Nasin projekt zamuja; SPI<1),>rdeča pa prikazuje, koliko smo potrošili (vidimo, da NASA troši veliko več kot realizira; CPI <1)>Črtkane črte napovedujejo končne vrednosti ob pogoju, da ostaneta CPI in SPI ista (predpostavimo tipični varianci).

Pri EVM gre za osrednjega projektnega predstavnika ključnih indikatorjev delovanja (angl. KPI), ki ga na področju vodenja projektov podpira PMI, in ga kot meritveni pogoj za izvedbo tekočih projektov zahteva od svojih agencij in pogodbenikov ameriška vlada.

EVM je "the" način nadzora in napovedovanja uspešnosti projekta.

Resnica je, da se z implementacijo EVM v naše poslovanje srečamo z mnogo omejitvami in zadržki. Za nebolečo uvedbo pa predlagam naslednje:

• ob vzpostavitvi projekta moramo ob vedeti zahtevanih rezultatih poznati tudi dovoljeni proračun in dovoljeni čas oziroma urno postavko vseh članov projekta
  
• poročanje o delu na projektu naj bo informacijsko podprto (vsak član projekta z minimalnim naporom vpiše svoje ure na projekt)
• poročanje mora biti redno (dnevno, max. tedensko)
• poročati je potrebno tudi o stopnji dokončanosti nalog ("še začeli nismo", "smo na polovici", "smo na 90%") - dejansko gre za občutek, ki pa bo s časom vedno bolj izostren (natančen)
  
• vodstvo organizacije lahko vsak trenutek pogleda števčke in semaforčke ("executive dashboard"), ki prikazujejo status in stanje posameznega projekta kakor tudi celotnega portfelja ter omogočajo nadaljnje poizvedovanje ("drill down")
• na prekoračitve kazalcev je potrebno ustrezno reagirati (glej CPI, SPI v odnosu na vrednost 1)

Ugotavljanje uspešnosti na koncu projekta

Po toči zvoniti je prepozno.

... moramo pa ugotoviti njene posledice.

Dobro zastavljen sistem spremljanja po metodi EVM bo brez večjega napora podal tudi izzid končanih projektov:

• stroškovno-prihodkovni vidik: profitabilnost projekta
• časovno: pravočasnost projekta
• kvalitativno: zadovoljstvo naročnika

Uspešnost na koncu projekta pomeni doseganje CSF - kritičnih dejavnikov uspeha (kaj so pogoji,da rečemo, da je BIL projekt uspešen). V Dashboard-u ustvarimo poseben pogled na končane projekte. Merjenje zadovoljstva naročnika se opravi po izvedbi projekta (če je projekt zelo velik po vsaki fazi) na uveljavljen način.

Z vsakim projektom boljši...

Projektni vodja je profesionalno obvezan, da po vsakem projektu povzame pridobljene izkušnje (angl. "lessons learned"; kaj smo se naučili: "česa ne?" + "kaj ponoviti?") in jih dokumentira v bazo znanja organizacije. Predlagam celo, da jih predstavi ostalim v skupini projektnih vodij - naj bo tudi to mini dogodek z namenom nenehnega razvoja osebnih veščin ter kulture projektnega vodenja v organizaciji.

Še eno darilce lahko da. In sicer članom projektne ekipe: ljudem, ki s svojim DELOM in prizadevnostjo zaslužni, da je projekt končan. Ob zaključku projekta naj jih seznani s pridobljenimi izkušnjami ter jim da priložnost, da povejo: svoje izkušnje, kako so se počtili, jih je kaj motilo za nemoteno opravljanje dela in podobno. Da so slišani! Pogovor naj bo kratek, sproščen, a dokumentiran. Predlogi ekipe bodo vhod v razmislek o nadaljnji optimizaciji procesov in metodologije projektnega vodenja.

Sam sem ravno pred kratkim ob koncu projekta svoji ekipi predlagal še nekaj več. Vsak od njih, vključno z menoj, je od ostalih članov dobil in jim dal povratno informacijo o delu, vedenju in ravnanju. Šlo je za tipično mrežo 21 komunikacijskih kanalov (S+PM=6):
.. kjer S v projektni terminologiji pomeni "Stakeholderja", PM pa seveda "Project manager". Vir: Leadership Champions

V našem primeru je bilo 6 članov ter jaz, kar pomeni, da smo slišali 30 povratnih informacij. Trajalo je šolsko uro, na koncu pa je eden od članov, ki se mu je na začetku mudilo, a je vseeno ostal, povedal, da je bilo to njegovih najbolje v naglici investirane pol ure. Kar pa je še bolj pomembno, videl se je žar v njihovih očeh. Ker so lahko povedali, kar jih je težilo, hvalili in bili "ne-kar-tako" pohvaljeni.

Projektni vodja naj ves čas skrbi za svoje in osebno dostojanstvo drugih ter skrbi za pravila komuniciranja (npr. kritika je lahko podana zgolj v obliki snedviča brez prepovedane besede "ampak", itd.), daje in odvzema besedo, se ne opredeljuje in vrednoti povedanega. Da, projektni vodja je tudi moderator! In soustvarjalec organizacijske klime.

Naročnik želi sedaj nekaj drugega!

PRIMER: Z naročnikom se že nekaj časa pogovarjamo, kako zadovoljiti njegovo potrebo: zapolniti prazen prostor. Naročniku smo predstavili koncept: velik zelen krog. Bili smo prepričljivi, strinjal se je. Podpisali smo pogodbo, da nam bo plačal 10.000 EUR, ko mu velik zeleni krog izdelamo (pogodba s fiksno ceno). Časa imamo do 1.3.2009 (fiksni datum), za vsak prekoračen dan bo naročnik deležen 1% popusta (penali). Drugih pogojev razen tistih standardnih v pogodbi ni, pa kdo bi jo bral.. imamo projekt, in kar je najbolj pomembno: zaslužili bomo!

Čez 2 meseca pokažemo naročniku že skoraj končan izdelek in ko izdelek vidi, dobi nove ideje in pravi, da velikega zelenega kroga ne bo plačal. Naknadno želi sedaj znotraj kroga še moder kvadrat.


Kaj bomo sedaj mi?

• sedaj je končno čas, da dobro preberemo pogodbo in vse "standardne" člene
  
• lahko nadaljujemo delo in delamo nadure, da do deadline-a (1.3.09) predamo izdelek, ki bo po volji naročnika
• se z naročnikom začnemo pogajati o aneksu ali change requestu, ki bo podaljšal deadline ali/in povečal vrednost projekta
• s projektom prenehamo in ne poslujemo več s tem naročnikom
• sodišče, arbitraža, mediacija, poravnava - verjetno predvsem v našo škodo, odvisno od pogodbe, ki pa v prodajnem procesu ni bila deležna pozornosti
  

Kaj lahko izboljšamo za v prihodnje?

• vključimo pravno službo ali pravnega strokovnjaka v sestavo pogodbe
  
• izbira alternativnih tipov pogodb: obračun stroškov po porabi, time&material, cost plus incentive fee, ipd., s katerimi se kot izvajalec zavarujemo pred nepričakovanimi stroški na projektu
• klavzula v pogodbi, ki predvideva, da se za dodatna dela na projektu podpiše aneks, ki ima moč spremembe prvotnih pogodbenih pogojev
• zadolžene za sestavljanje pogodb izobrazimo, kateri tip pogodbe je primernejši za določeno situacijo in prilagodimo predloge pogodb za vprihodnje
• za ta dotični posel vpišemo izkušnjo (lekcijo) v bazo znanja oziroma "lessons learned", kar bo zagotovilo, da podobnih napak naše podjetje ne bo ponavljalo

Kdo je odgovoren? Kdo je kriv?

Nikakor ne smemo iskati krivca poimensko, ker je potrebno izboljšati sistem, predpogodbeni (prodajni) proces. Iz tega primera se lahko veliko naučimo in z naše strani sodelujoči zaposleni bodo v prihodnje veliko bolj pozorni na vsebino pogodbe. Naj staknejo glave za proces odgovorni, npr: vodja prodaje, funkcijski vodja in vodja projektne pisarne - odvisno od situacije in organiziranosti družbe.

Dejansko je za prodajni proces odgovorna PRODAJA, ki zagotovi korektnost pogodbe z vključitvijo POTENCIALNEGA VODJE PROJEKTA (ali ključnega predstavnika/nosilca kasnejše izvedbe), katerga dolžnost je opozarjati in vztrajati pri ustreznih klavzulah in pogodbenih dogovorih. Ker če ga ne bo takrat, bo imel kasneje peklensko delo izpolnjevati nerealna pričakovanja tistih, ki so pogodbo podpisali.

Metodologije razvoja programske opreme

Objava o metodologijah vodenja softverskih projektov: http://www.noop.nl/2008/07/the-definitive-list-of-software-development-methodologies.html

Zanimivo, ker opiše kar nekaj t.i. metodologij in t.i. agilnih metodologij, ki so v SW-skem svetu še posebej razširjene. Ne bom se ponavljal: vsaka organizacija bi lahko razvila sebi ustrezno metodologijo - iz nič (opiranje na osnovne koncepte in stanarde) ali izpeljanko že obstoječe po izbiri.

Sofveraši se bodo celo prej kot v zgornjem seznamu našli na seznamu metodologij, objavljenih na Wikipediji, saj so tam navedeni prijemi (ne bom jih imenoval metodologije, čeprav se ponekod metodološko uporabljajo, in celo zelo dosledno; niti jim ne bom rekel "cvetke", ker izhajajo iz prakse in nekomu elegantno pomagajo), kot so:

• Code and Fix
• Quick and Dirty
• Big Design Up Front
• Don't repeat yourself
• Extreme Programming
• Separation of concerns
• Worse is better
• You Ain't Gonna Need It

Niti ne bom rekel, da so razvojniki in programerj pregovorno alergični na postopke... in dokumentiranje... zgornje je njihov zgovoren odgovor, da se tudi čisti SW-ski projekti zavedajo potrebe po urejenem pristopu.

Oh ta projektni vodja

V različnih situacijah sem do sedaj spoznaval različne okoliščine, v katerih so se izvajali projekti. Okoliščine so večinoma izhajale iz organiziranosti organizacije/družbe. V praksi se tudi pri nas srečujemo z vsemi tremi oblikami ograniziranosti podjetij:

• funkcijska organizacija - oddelki so kot silosi, med seboj slabo komunicirajo, šef silosa ima največjo moč in odloča o vsem


• matrična organizacija (šibka, uravnotežena, močna) - zaposleni imajo svojega silosnega šefa, imajo pa tudi nekoga, ki jih


• projektna organizacija - vodja projekta je the man, odgovoren za uspeh in neuspeh ter za proračun projekta

V vseh treh ima TOP management vizijo izvajanja projektov torej tudi idejo o pozicioniranosti vloge projektnega vodje. Zakaj bi se sami mučili, če lahko za doseganje določenih ciljev preprosto nekoga pooblastijo? To je žalostno dejstvo v funkcijski organizaciji, medtem ko v projektni organizaciji to na srečo ne drži. Pooblastilo v projektni organizaciji pomeni več, nekaj dobrega.

Pod kakšnimi pogoji je vodja projekta res vodja?

Funkcijska organizacija	Matrična organizacija	Projektna organizacija
Deklica za vse	Žongler	Vodja
Nesrečnež	Politik	Motivator
Don Kihot	Black Adder	Robin Hood
Dežurni krivec	Reševalec	Rešitelj

Zavzet vodja projekta bo v funkcijski organizaciji deloval kot generator zahtev po spremembah. Izpostavljal bo svoje bolečine ljudem, ki so ga imenovali in pooblastili. S časom jim bo mogoče postalo jasno, da so - če so projekti za organizacijo pomembni - potrebne spremembe.

Uravnotežena in močna matrična organizacija nista nujno slabi in nista nujno primerni za vse odgovore na tržne izzive. Pri nas je veliko šibkih in zelo malo pravih uravnoteženih ali močnih organizacij, čeprav se tako nazivajo. Za matrično organizacijo je ključnega pomena, da poslovni procesi funkcionirajo tudi v praksi, ne zgolj na papirju.

Projektne organizacije so lahko zelo velike, pri nas pa so to večinoma majhna podjetja, kjer je šef področja istočasno tudi vodja projekta. V pravem pomenu besede celotna organizacija živi za projekte zato ima vodja projekta osrednjo vlogo.

Ali mora biti vodja projekta tudi tehnični strokovnjak?

Ne! Ne mora biti. Je koristno, če se spozna na področje dela, ni pa nujno. Če vodja projekta obvladuje procese projektnega vodenja (torej je strokovnjak na področju projektnega vodenja), lahko vodi vsakršen projekt, katerekoli gospodarske panoge.

Dober vodja projekta KONVERGIRA k tehničnemu področju projekta, ki ga vodi (je radoveden "kako deluje", se uči, sprašuje da si ustvari širšo sliko in logiko projekta). Slab projektni vodja se IZMIKA in ODDALJUJE od vsebine projekta ter postaja projektni papirolog, birokrat.

Seveda pa mu mora biti dodeljen tudi nekdo, ki ga lahko imenujemo "vsebinski vodja" oziroma kar cela ekipa ("project management team"; ni enako "project team", ki zajema vse člane projekta), sestavljena iz vodij tehničnih skupin na projektu.

Za to, da ima vodja projekta na projekt pogled od zgoraj navzdol, pa je resnici na ljubo nujno, da se o osnovnih lastnostih dela in produkta že prej seznani. In da se od tehničnega področja ne distancira, pač pa poglablja - s tem si lahko s časom pridobi expert power ali vsaj ni prepeljan žejen čez lužo.

Za konec še nekaj.. če želimo promovirati izkušenega inženirja v projektnega vodjo se lahko zgodi naslednje:

Izgubimo dobrega inženirja in dobimo slabega vodjo projektov.

Ne razmišljajmo tako. Pri inženirjih je predmet dela tehnologija (stroji, programi, koncepti), pri projektnih vodjih pa doseganje projektnih ciljev in pa glavna "distinkcija": ljudje.

Projektni pregovori

• Ženska potrebuje 9 mesecev, da rodi dojenčka. 9 žensk tega ne more v 1 mesecu.
• Stroške projekta najbolj natančno ocenimo na koncu.
• "NE" je najbolj koristna in najmanj uporabljena beseda projektnega vodje.
• Premalo ljudi na projektu ne more reševati problemov, preveč ljudi jih povzroča več, kot jih lahko rešijo.
• Uporabnik bo odgovoril le na vprašanja, ki mu jih zastavimo. In nič več.
• Prej ko se bomo spravili k programiranju, kasneje bomo končali.
• Če nam ni uspelo planirati, smo splanirali, da nam ne bo uspelo.
• Ustni dogovor ni vreden papirja, na katerem je zapisan.
• Če ne veš, kam greš, bo vsaka pot prava.
• Če se s tveganji ne bomo spoprijeli, se bodo tveganja spoprijela z nami.
• Slabo planiran projekt bo trajal 3-krat dlje, dobro planiran projekt le 2-krat.
• Dobrih projektnih vodij ni, so le srečneži - bolj ko planiramo, bolj se nam nasmiha sreča.
• Če je kladivo naše edino orodje, bo vse izgledalo kot žebelj.

O čem sanja naročnik?

Napake v definiciji obsega projekta so za končni produkt usodne in povzročajo največje stroške popravil.

Kar na koncu boli je tudi, da naročnik projekta ne bo prevzel in plačal. Za naknadno modifikacijo izdelka pa bi bi potreben nov projekt (dodaten budget in čas) - je pa vprašanje, ali bo naročnik ponovno najel nas. Vprašajmo se tudi, ali smo s tem naredili nepopravljivo škodo za naročnika? Glej sliko - drevo je požagano; v praksi pa je naročnik zamudil čas za lansiranje izdelka na trg, prilagoditev poslovanja zakonskim zahtevam in podobno.

Projektna klinika

Projekte izvajamo za naročnike na trgu. - ALI - S projekti rastemo in se prilagajamo tržnim ali zakonskim zahtevam. - ALI - S projekti razvijamo nove produkte in storitve.

Kako pomembni so torej projekti za našo organizacijo?

Tako zelo pomembni kot za kliniko življenja njihovih pacientov? Dejstvo je, da je v IT industriji 60% projektov neuspešnih, klinika pa si tega ne more in ne sme privoščiti. Odmislimo, da naš zdravstveni sistem ni najbolj optimalen in da naši zdravstveni managerji niso najboljši na svetu, da so predolge čakalne dobe in podobno; še vedno je zdravnik osebno odgovoren za življenje pacienta.

Vprašajmo se ali so tudi naši projekti življenjsko pomembni? So stroški projekta, delo naših ljudi na projektih in čas za naše poslovanje smrtno resne zadeve? Če še niso, pa še bodo (beri poglavji o izvajanju projektov v recesiji in o poslovanju organizacije v recesiji).

Predlagam, naj bodo resni sistemi vodenja projektov podobni klinikam, obravnava projektov pa podobna obravnavi pacientov. V spodnji tabeli predlagam nekaj idej o podobnosti:

PACIENT	PROJEKT
Sprejem pacienta, dodelitev sobe in postelje	Sprejem, evidentiranje, zagon projekta
Ambulanta (pacienti pridejo sami)	Prodaja (išče projekte na trgu), interni pobudnik (interni projekti)
Dodelitev zdravnika (klinika – resni primeri)	Imenovanje vodje projekta
Anamneza (pogovor s pacientom in pregled dosedanjih izvidov)	Zajem poslovnih in tehničnih zahtev stranke
Diagnoza	Koncept rešitve
Zdravljenje	Izvedba projekta
Uporaba specialistov medicine	Uporaba tehničnih specialistov (so del projektne ekipe)
Osebna odgovornost zdravnika	Odgovornost vodje projekta – plačna variabila
Omejen začetek in konec zdravljenja	Omejen začetek in konec projekta
Omejna sredstva in resursi	Omejen budget
Pogovor o stanju pacienta, tudi s sorodniki	Komunikacija z naročnikom, sponozorjem
Spremljanje statusa pacienta	Spremljanje statusa projekta
Temperatura, holesterol, eritrociti	Earned value, CPI, SPI, graf napredka
Sodelovanje pacienta pri zdravljenju	Sodelovanje naročnikove ekipe
Zdravnik napiše odpustnico	Primopredajni zapisnik
Papirologija, informacijski sistem	Projektna dokumentacija, informacijski sistem
Nadzorni zdravnik	Vodja projektne pisarne, management
Tedenski raport (pregled stanja pacientov v krogu vseh zdravnikov na kliniki)	Tedenska revizija projektov znotraj projektne pisarne; prisotni vsi projektni vodje
Vizita	Pregled projektov individualnega vodje projekta, tudi pogovor vodje projektne pisarne z naročniki njegovih projektov

.. in ne, naš cilj ne sme biti, da projekt postane pacient.

Projektno vodenje v 15 minutah

Šnelkurs projektnega vodenja I. del, avtor: Bas de Baar



Šnelkurs projektnega vodenja II. del, avtor: Bas de Baar

Temeljna pravila igre

Vsaka organizacija, poslovni odnos, projekt, projektni team, član projekta jih potrebuje. Z njimi se učinkovito izognemo konfliktom in nejasnostim v fazi realizacije rezultatov.

Pravila skrbijo za higieno na projektu, z njimi pa si zagotovimo porabo energije usmerjeno v končne cilje. Z njihovo pomočjo pa oblikujemo dream team.

Navajam nekaj primerov temeljnih pravil igre (vir: ground rules), ki jih predstavimo ekipi na začetnem projektnem sestanku:

• vsi člani projekta so enakovredni (tudi če imajo drugačne urne postavke)
• o problemih govorimo odkrito in neposredno
• namesto destruktivnega kritiziranja uporabljamo sendvič kritiko
• nobeno vprašanje ne more biti neumno
• odločitve se zapišejo v obliki sklepov, zadolži se člana in postavi rok
• zapisana komunikacija je v odnosu z naročnikom edina veljavna
• vsak je odgovoren za svoje ravnanje
• komuniciramo spoštljivo, odkrito, odprto in z občutkom do sogovornika
• medsebojno se podpiramo
• če nečesa ne bom zmogel, to povem brez zavlačevanja
• spoštujemo nasprotja
• bodi prisoten, ne ignoriraj projektnih sestankov in elektronske pošte
• lahko smo skeptični, ampak ne cinični
• spoštujemo zaupnost projektnih informacij
• pokažimo optimizem in pozitiven odnos
• smo pravočasni
• šalimo se, ko je to primerno
• mislimo preden govorimo, smo pripravljeni
• naenkrat govori samo eden, poslušamo brez prekinjanja
• razumemo in upoštevamo, da se vodja projekta zavzema za doseganje zadanih ciljev
• ne parlamentiramo, za cilj smo zavzeti
• ne kritiziramo projektnih zadev sodelavcem na hodniku, ob avtomatu za kavo ali na malici, kritiko sporočimo direktno vodji projekta, ali vsem na projektnem sestanku
  
• ne tožarimo funkcijskemu managementu
  
• med seboj se kličemo po imenih, ne pa z "on", "ona" ali priimkih
• ne vztrajamo pri stvareh, ki v preteklosti niso delovale
• ne bomo trmasti, da se naši predlogi sprejmejo za vsako ceno: skličimo vse v problem vpletene, dobro se pripravimo, bodimo prepričljivi in jim naš predlog razumno predstavimo kot za nas najboljšega. Mogoče slišimo še drugo plat.
• nismo užaljeni, če predlog ni sprejet, ali ne dobimo besede - pozornost si pridobimo z uradnim sklicom sestanka.
• ne izsiljujemo za svoj prav
  
• če potrebujemo, zahtevamo premor (time-out)
• če potrebujemo, zahtevamo pomoč
• ne žalimo ostalih članov, zunanjih sodelavcev ali strank
• damo le najboljše od sebe
• če mislimo/vidimo/slišimo/zvemo, da je uspeh projekta zaradi česarkoli ogrožen, premislimo o najboljši rešitvi in takoj obvestimo vodjo projekta
  

Vsako od navedenih pravil lahko začnemo s "člani projekta se strinjamo, da ...".

Ob izvedbi projekta se bodo člani pravil zavedali in se medsebojno opozarjali. Na projektih, ki nimajo postavljenih temeljnih pravil igre, se bo dogajalo, da člani ne bodo imeli občutka pripadnosti, enakopravnosti in urejenosti. Projekt bo kompakten. Vodji projekta pa ne bo potrebno "igrati policaja".


Pravila poskusimo uveljaviti za vse ostale skupinske aktivnosti.

"Dream-team" in kako ga prepoznamo?

Dogajali so se in se še bodo projekti, katerih rezultat ne bo le izpolnitev cilja, ampak tudi neformalne pozitivne posledice, iz katerih se lahko razvijejo prijateljstva, novi produkti, organizacijske enote ali celo nova podjetja.

Nekaj značilnosti "dream-teamov":

• vsak lahko pove, kako se počuti
• vsak je odgovoren za svoje počutje: vodja projekta ne prevzema odgovornosti za počutje članov projekta
• orientiranost k cilju
• vzporednost zadolžitev
• vodenje je usmerjeno k cilju
• vodja skrbi za jasnost pravil
• vodja je moderator komunikacije (pomislite na talk showe ali tv oddaje; soočenja gostov)
• s sodelovanjem kompenzirajo pomanjkljivosti
• pomanjkljivosti niso izpostavljene negativno -> razvijanje kulture povratne informacije
• feedback je potrebno znati tudi sprejeti
• člani čutijo pripadnost
• projekt je prostor za izmenjvajo informacij in učenje veščin (javnega nastopanja, vodenja, analitičnega mišljenja, ...)
• ni ljubosumnega skrivanja znanja
• ustvarjalno reševanje problemov: nekateri odkrijejo svojo ustvarjalnost šele v teamu

"Nekdo je nekoč rekel, da toliko kot se ob delovanju v teamu naučimo o sebi, se ne naučimo v 30 letih meditacije."

Faze razvoja uspešnega teama

Naloga vodje projekta je, da pričakuje teamsko dinamiko ter se ne ustraši, ko gre team skozi naslednje faze:

1. forming - imenovanje članov na projekt, dodeljevanje in prevzemanje vlog, na psihološki ravni izvajajo izvajajo "samopromocijske" aktivnosti (kdo smo?); POZOR: odgovornost vodje projekta: vodja projekta mora na vse krče uvesti temeljna pravila delovanja v teamu že v tej fazi! Razjasniti mora tudi metodlogijo dela, osnovni plan in mejnike, napovedati projektne sestanke, ipd.
   
2. storming - kontroliran konflikt na začetku, ker so člani različni, imajo svoje izkušnje in poglede, med člani zaveje konkurenca, veliko je čustvenih izpadov, izjav in trme (kako se bomo prenašali?)
   
3. norming - ustvari se občutek pripadnosti, komunikacija med njimi in do vodje projekta je odkrita, sodelujejo.
   
4. performing - izvajajo svoje naloge, energijo usmerijo v naloge. Pomemben je cilj.

NAROBE: Slabše kot da vodja ne naredi ničesar (laissez faire) je, da se temu upira in prvih dveh faz, ko se vzdušje na projektu zdi "problematično", ne sprejema kot normalno ter išče načine za odpravljanje neskladnega obnašanja.

PRAV: Energijo naj usmeri v razumevnje ter iskanje načinov kako elegantno čim prej spraviti team do faze "performing"!

Po mojih izkušnjah so navedene faze značilne tako za projekte kot tudi za manjše enote aktivnosti, kjer je ključna komunikacija:

• večje faze projekta: v primeru,da je projekt kompleksen in je sestavljen iz več faz, kjer sodelujejo različni člani ali pa je projekt časovno raztegnjen in je faze potrebno ponavljati, da članom projekt ne postane tuj
• izvedba sestankov: tukaj je pomembno, da vodja sestanka že na samem začetku definira temeljna pravila, če želi prej doseči fazo performing. Tu ni nujno, da so sestanki projektne narave.
  
• komunikacija med vodjem projekta, sponzorji ter upniki (stakeholders) projekta (manage stakeholders expectations) .
• nova zaposlitev strokovnjaka v podjetje: forming in storming opravi večinoma član že pri sebi. Ob nastopu delovnih nalog pričakuje od novega delodajalca pravila igre (norming).

Opisanemu redosledu stopenj razvoja teama, bi osebno dodal še zadnjo stopnjo v smislu "closing" ali "disbandment", ko team na primeren način razpustimo, jih nagradimo, preverimo, ali se lahko iz našega sodelovanja kaj naučimo za v prohodnje. Tu je tudi čas (pro)slavja: najmanj, kar lahko vodja proejkta naredi je, da člane povabi na kavo, pivo, pico.. S tem si zagotovi pozitivnost za naslednje projekte tudi če krovno podjetje tega formalno ne podpira. Takšen zaključni korak predstavlja tudi garancijo za forming na prihajajočih projektih (ljudje se bodo veliko raje pridružili našim projektom).

Isto znanje, drugo pakovanje

Ob odločanju glede metodologije projektnega vodenja se je potrebno najprej vprašati, kaj zares želimo z uvedbo metodologije doseči. Dejansko je vseeno, kako se potem metodologija imenuje, pomembno je, da je NAŠA. Po mojem mnenju so PMI standardi najboljša podlaga pri razvoju katerekoli metodlogije. Josh Milane postavi bok ob bok v svojem blogu različne metodlogije projektnega vodenja in prikaže, da je metodologija dejansko varovalka, da se bo projekt:

1. formalno postavil,
2. splaniral in koncipiral,
3. izvedel
4. kontroliral
5. in zaključil.

Temu ustrezno moramo potem pripraviti ali spremeniti obstoječe poslovne procese v organizaciji. Slika prikazuje razkrite podobnosti različnih metodologij:

... o čemer pa je že davno tega govoril gospod Deming?

PDCA Demingov krog odličnosti

Metodologija projektnega vodenja za slovensko organizacijo

Najprej svetujem, da takoj pozabite PRINCE, PRINCE2, PMI in podobne metodologije projektnega vodenja, za katere ste dosedaj samo napol slišali.

Raje se vprašajte, kaj zares potrebujete: "Kje ste slabi, kje bi bili radi boljši, kaj znate dobro in bi ponavljali na vsakem projektu?"

PRINCE (2) je narejen za neke druge organizacije, in zelo majhna verjetnost je, da bo ustrezal vaši. Mogoče pa, vendar se na to ne bi zanašal. PMI ponuja standard vodenja projektov, ki je zapisan v knjigi z imenom PMBOK.

Dobra metodologija bo upoštevala standarde iz PMBOK-a, vendar le do stopnje, ko so še izvedljivi / prebavljivi - zato bo dobra metodologija upoštevala tudi možnosti vaše organizacije. Na začetku uvedbe sistema projektnega vodenja (ter s tem projektne metodologije) bo zadostovala osnovna varianta metodologije, ki bo povezala poslovne procese vaše organizacije na način, da jih bodo lahko uporabljali projekti. V nadaljevanju s faznim načinom rasti postopoma zvišujete zrelost sistema projektnega vodenja v organizaciji. Čez noč ne bo šlo - ne zaradi tehnologije ali metodlogije, pač pa zaradi ljudi, ki potrebujejo čas in voljo za spremembe.

Predlagam, da razvoj projektnega vodenja v organizaciji prevzame projektna pisarna ter njen vodja z imenom in priimkom. Naj se bori, ker borba mu ne uide. Strokovni svetovalci iz projektnega vodenja lahko tu veliko pomagajo, saj imajo izkušnje iz ostalih podjetij ter globalno in tehnično znanje.

Projekt uvedbe metodologije projektnega vodenja je del uvedbe "Sistema projektnega vodenja" in naj vsebuje vsaj naslednje faze:

1. Analiza obstoječega poslovanja: prednosti, slabosti, potrebe, priložnosti
2. Definiranje projekta kot (osnovni) poslovni proces v organizaciji: projektne vloge, projektna pisarna, metodlogija projektnega vodenja, definiranje informacijske podpore
3. Implementacija sistema v prakso: uradna predstavitev vsem, izboraževanje, uvajanje
4. Vzdrževanje sistema projektnega vodenja: coaching projektnih vodij, izboraževanja, izmenjava izkušenj, učenje iz uspehov in napak, vzdrževanje projektnega informacijskega sistema

Seveda pa je za uspeh takšnih projektov brezkompromisno potrebna podpora najvišjega vodstva. Koristi projektnega vodenja morajo biti jasne na začetku predvsem njim. Naj bodo ob pomembnih mejnikih in predstavitvah ter izobraževanjih osebno prisotni. Naj se jim izdela dashboard, preko katerega bodo spremljali stanje projektov na zelo user friendly način. Na začetku bodo dali načelno podporo, strinjali se bodo in podpisali kakšen odlok ali podoben dokument. Za uspešno implementacijo pa potrebujemo njihovo konkretno podporo- da podpirajo projekt, ko bo segel na področje reorganizacije, sprememb obstoječih navad zaposlenih ter nenazadnje svojih navad. Največ bodo naredili, če bodo vodili s svojim zgledom in to zahtevali tudi od drugih.

Glejte tudi: Projektno vodenje kot usmerjanje energije

Projekti v recesiji

... ali "THIS IS SPARTA!!!!!"

Recesija je močan argument, da se podjetje zorganizira tako, da kar najbolj učinkovito funkcionira.

Tako kot Špartanci proti Perzijcem. Niso imeli šans, bilo jih je samo 300, Perzijcev par deset tisoč ali celo več. Če razumemo "Kako jim je uspelo?" lahko izboljšamo tudi svoje poslovanje, posebej v teh kriznih časih.

Nekaj idej bom poskusil spraviti v spodnjo tabelo, za vzklik "Heureka!" pa priporočam ponoven ogled filma.

ŠPARTANCI	VPRAŠANJE ZA NAS
Špartanci so bitke planirali.	Kakšna je kultura planiranja v našem podjetju? Kako dobri smo pri planirnju odzivov na realizacijo tveganj in sprememb?
Špartanci so delovali v slogi, "vsi za enega, eden za vse".	Ali vemo kdo in kako med seboj na projektih sodelujemo?
Špartanci so vedeli, kdo je vodja, in kaj pomeni biti vodja.	Kakšno avtoriteto dajemo našim projektnim vodjem? Kakšna je njihova vloga?
Špartanci so v bitki svoje čete oblikovali v trikotne formacije.	Kakšna je naša projektna metodlogija? Kaj naredimo, ko pride na projektu do določene situacije, odstopanja?
Špartanci so bili znani po strogi disciplini.	Ali naši zaposleni upoštevajo postopke in pravila?
Špartanci so bili pripravljeni umreti za domovino.	Kaj smo do sedaj naredili, da so nam sodelavci v podjetju ali na projektu zvesti?
... seveda, ker so se borili zase, za svoje družine, otroke.	Kaj čaka zaposlene, če je projekt uspešen? Kaj sledi, če se ne potrudijo dovolj? Kaj je palica, in kaj korenček? Na kratko, kakšen sistem nagrajevanja imamo?
Špartanci so svoje otroke izurili v vrhunske borce.	Kako zagotavljamo, da strokovnjaki v našem podjetju ne postanejo le izbranci. Da ima vsak karierno pot do strokovnjaka, projektnega vodje ali funkcijskega managerja? Ali vzgajamo naslednike? Kakšen je naš HRM?
Zakaj danes poznamo to zgodbo? Zgodbo so skrbno zapisali in shranili za potomce.	Kakšna je naša kultura dokumentiranja izvedbe projekta? Ali poročamo o napredku? Ponavljamo iste in iste napake? Ali na koncu izvedemo delavnico na temo "lessons learned"?

Vprašajmo se: "Ali lahko kaj naredimo, da bomo od sedaj naprej pri izvedbi projektov boljši?" Časi so že takšni, da moramo biti.. in zgodovina nas lahko veliko nauči.

Preberite tudi: Učinkovita metodologija projektnega vodenja.

Kako prodajati projekte?

Ključnega pomena pri prodajanju projektov je znižati tveganja. Tveganja znižamo z različnimi prijemi. Nekaj napotkov za zavednega prodajnika, verjetno jih že pozna:

1. Razumimo stranko, kaj nam govori in ne govori (ne-verbalna komunikacija)
   
2. Premislimo, kako ji z našo ponudbo lahko pomagamo: po potrebi se pogovorimo z ljudmi znotraj naše organizacije; preverimo s stranko
3. (Pre!)Več komunikacije je bolje kot manj komunikacije: tako s stranko kot z notranjimi sodelavci. Ne glede na občutek, ki ga dobimo ob "presežnem komuniciranju", nadaljujmo z istim tempom komunikacije.
   
4. za tehnični del ponudbe uporabimo inženirje (pridobimo jih pri njihovih funkcijskih vodjih)
5. Prodajni postopek razdelimo v korake, zadnji korak vključuje tehnično specifikacijo, s katero se stranka strinja (npr. funkcionalne specifikacije = tehnični del ponudbe)
6. Pri tehničnem delu ponudbe vključimo predvidenega vodjo projekta oziroma izkušenega vodjo projekta, ki bo z večjo gotovostjo predvidel stroške vodenja projekta
7. Prodajne podatke uskladimo z izvajalci in nabavno službo
8. Naš cilj mora biti, da stranka pred podpisom pogodbe potrdi tehnično specifikacijo, ter eventuelno, da podpiše pogodbo, katere priloga je specifikacija
9. Če izdelava specifikacije zaradi različnih razlogov ni možna, se potegujmo za pogodbo tipa time&material: projekt se razdeli v več manjših, ki jih narekuje stranka
10. Če je projekt skrajno razvojni (produkt bo npr. inovacija) se potegujmo za pogodbo, ki pokrije stroške naših izvajalcev
11. Načeloma drži, da pogodba s fiksnim zneskom ščiti naročnika; pogodba z obračunom stroškov izvajalca pa pred tveganji ščiti izvajalca.
12. Delujmo timsko. Team naročnika bo na projektu del projektnega teama. Mogoče celo isti ljudje. Ljudje na obeh straneh bodo tudi psihično pripravljeni na bližujoč projekt, ki pomeni spremembo v njihovem delavniku.
    
13. Na strani naročnika si pridobimo sponzorja (on financira zato bo tudi najbolj zainteresiran, da bo projekt uspešen - na strani naročnika bo pomagal do virov ali odličitev).
14. Bodimo moralni. O konkurenci govorimo korektno in je ne blatimo. Stranko korektno predstavimo internim izvajalcem.
15. Ob podpisu pogodbe poiščemo imenovanega vodjo projekta in mu predamo vso formalno dokumentacijo, ki je nastala v prodajni fazi tega projekta. Opremimo ga tudi z neformalnimi informacijami v pisni ali ustni obliki. Gre za primopredajo posla v projekt.
    
16. Če ne komunicira z nami, vodjo projekta tedensko vprašamo po statusu projekta. Pokažimo, da nam ni vseeno. Zvedeli pa bomo tudi veliko koristnega o projektu in o novih potrebah stranke.

Ni veliko do cilja, ko bodo tudi vodje projektov, inženirji in ostali priznali, da ste dober prodajnik. Poznate tudi kakšne druge prodajnike?

Procesi projektnega vodenja (str. 70 PMBOK)

Memory dump (moj) s 44-imi procesi, ki ga naredimo pred PMP izpitom, izgleda nekako takole:

Ne printajte :) Vsak naj si izdela svojega - glej PMBOK 2004 str. 70.

NASVET: naredi memory dump vsak dan, 1 mesec pred izpitom.

POZOR: leta 2008 je izšla nova verzija PMBOK-a, str 70 bo temu ustrezno neka druga stran, njena vsebina pa verjetno spremenjena.

Formule za PMP (osnovni paket)

Prepiši na list papirja! Ne printaj.

Legenda:
EV - earned value
AC - actual costs
BAC - budget at completion
PC - planned value
CV - cost variance, [%] procentualno
CPI - cost performance index; večji od 1 = smo znotraj stroškov (under budget), manjši od 1 = porabljamo več kot služimo (behind budget)
SPI - schedule performance index; večji od 1 = smo pred planom (ahead), manjši od 1 = zaostajamo (behind)
TCPI - CPI to completion (da dosežemo predvideni BAC, kakšen CPI moramo sedaj imeti)
VAC - variance at completion

Legenda:
LS - late start
ES - early start
LF - late finish
EF - early finish
O - optimistični scenarij
P - pesimistični scenarij
M - most likely; najbolj verjeten scenarij
SD - standard deviation, [sigma]; standardni odklon

σ² - varianca

n - število subjektov, ki komunicirajo