planiranje projekta (doseg) - mirakul.hr fileupravljanju projektima, što će, naravno, biti slučaj...
TRANSCRIPT
PROJEKTURA
Metodologija upravljanja projektima
Planiranje projekta (DOSEG)
Dokument je sastavni dio Metodologije upravljanja porojektima koja se koristi u PROJEKTURA timskom
okruženju.
(C) 2007 PROJEKTURA Upravljanje projektima. Sva prava pridržana.
Metodologija upravljanja projektima: Planiranje projekta I stranica 2
Sadržaj
Metodologija: Planiranje projekta ........................................................................................................................................... 4
Što je to planiranje projekta? ............................................................................................................................................... 5
Proces planiranja projekta ..................................................................................................................................................... 6
Doseg projekta ...................................................................................................................................................................... 6
Doseg projekta: Radni zadaci WBS (Work Breakdown Structure) ..................................................................... 9
Doseg projekta: vremenski raspored radnih zadataka (Scheduling) ............................................................. 19
Doseg projekta: Izračunavanje kritičnog puta (Critical Path) ........................................................................... 22
Metodologija upravljanja projektima: Planiranje projekta I stranica 3
Sadržaj: Dokument daje pregled osnovnih znanja o planiranju projekta i sastavni je dio metodologije
upravljanja projektima. Može se koristiti kao dio projektne metdologije određenom tima ili
organizacije te je podložan promjeni u svakom trenutku.
PROJEKTURA
Zadnja promjena: 18. kolovoz, 2018
Verzija: 0.3
Autor: Ratko Mutavdžić, PROJEKTURA
© 2018 PROJEKTURA d.o.o. Sva prava pridržana.
PROJEKTURA ne odgovara za uporabu sadržaja te za rezultate koji iz takve uporabe mogu proizaći. Sve
informacije napisane u dokumentu napisane su kao najbolje iskustvo i najbolja praksa u određenom
trenutku.
Metodologija upravljanja projektima: Planiranje projekta I stranica 4
Metodologija: Planiranje projekta
U ovom poglavlju (dokumentu) obrađuju se osnovne planiranja projekta te daju odgovori na pitanja
poput: što je to planiranje projekta, zašto je planiranje projekta ključni element uspjeha, kako i na koji
način izvesti pojedine aktivnosti prilikom planiranja, koje osobe i u kojim rolama sudjeluju u ovom
dijelu izvođenja projekta, uz predstavljanje osnovnih alata koji su vam potrebni da bi ovaj dio projekta
uspješno ili barem jednostavnije odradili.
Planiranje projekta je, po mnogima koji imaju što reći o upravljanju projektima ili imaju to zadovoljstvo
da od njega žive, kruh i maslac bilo kojeg projekta. Planiranje mora odgovoriti na nekoliko pitanja koji
se postavljaju u projektu. Što je potrebno napraviti? Kako ćemo napraviti ono što je potrebno
napraviti? Tko će to napraviti? Kada je rok da se to napravi? Koliko će nas koštati to što je potrebno
napraviti? Koju kvalitetu je pri tome potrebno postići? Izvršite li nekvalitetno planiranje projekta ili se u
najmanju ruku prema njemu postavite po poznatoj uzrečici „lako ćemo“ s velikom vjerojatnosti će vaš
projekt završiti u famoznih 78% projekata koji, nakon što počnu, nikad ne dožive i svoj uspješni kraj i.
Pored toga, vjerojatno se upravo planiranju projekta posvećuje najveći prostor u bilo kojoj knjizi o
upravljanju projektima, što će, naravno, biti slučaj i sa ovom.
Zanimljivo je da u većini projekata planiranje zapravo počinje i prije no što započne sam projekt (jedan
moj kolega bi rekao: „Projekt prije projekta“), te ne bi završilo niti kad bi sam projekt formalno bio
predan te se obavile sve potrebne post-mortem radnje. Planiranje je sastavni dio svakog pojedinog
razmatranja mogućnosti da se projekt uopće pokrene, pretprodajnog ciklusa, faze definiranja zahtjeva
ili bilo kojeg sastanka koji se odvija u sklopu nečeg velikog što bi nazvali projekt. Sadrži li vaš projekt
značajno upravljanje rizicima u projektu, planiranje je nešto što ćete imati u vidu svake sekunde
projekta. No kako se svaka ozbiljna knjiga ili ozbiljni projektant drži metodologije, i mi uvodimo fazu u
projektu koju ćemo jednostavno zvati – planiranje.
Metodologija upravljanja projektima: Planiranje projekta I stranica 5
Što je to planiranje projekta?
Tražimo li ovdje definiciju planiranja projekta, vjerojatno ćemo zapeti na nečemu što bi počinjalo s
riječju proces. No, pokušamo li pronaći što su drugi rekli za planiranje, evo nekoliko svjetskih
odgovora. Tako, na primjer, Harold Kerznerii spominje 3 osnovna elementa planiranja procesa:
1. Definiranje radnih proizvoda (work products)
2. Definiranje kvantitete i kvalitete radnih proizvoda
3. Definiranje resursa potrebnih za izvođenje radnih proizvoda
Prema J. LeRoy Warduiii, planiranje projekta može biti:
1. Stvaranje i upravljanje projektnim planom; prepoznavanje projektnih ciljeva, aktivnosti
potrebnih da bi se završio projekt te resursi i njihova zahtijevana količina da bi se izvršila
pojedina aktivnost ili zadatak u projektu, ili
2. Sustavni pristup koji određuje kako početi, izvršiti i zatvoriti projekt.
Primijetite vrlo bitnu razliku između onog što se nalazi u ovoj fazi i onoga što je sadržano u fazi
inicijacije projekta. Inicijacija se fokusira na stvaranje i objašnjavanje poslovnih zahtjeva te povezivanje
misije i ciljeva organizacije s cijevima projekta – projekt mora imati svoju vrijednost za organizaciju koja
ga pokreće i mora biti povezan s strateškim ciljevima organizacije. Planiranje je već korak dalje i
uglavnom se fokusira na konkretne korake kako projekt ostvariti, i kako odgovoriti na niz pitanja koja
su postavljena u uvodu poglavlja – odnosno na dodatna pitanja, ciljeve i ideje koje su postavljene u
fazi inicijacije projekta.
Kako ste primijetili, u fazi inicijacije navode se high-level ciljevi projekta (uvijek značajno povezani s
ciljevima organizacije), dok se ovdje ti isti high- level ciljevi razrađuju u detalje i planiranja kako će isti
biti ostvareni. Ponekad se upravo u nerazumijevanju razlika između inicijacije i planiranja čini osnovna
pogreška u upravljanju projektom: u fazi inicijacije se pokušava opisati što više elemenata koji se
stvarno moraju nalaziti negdje u fazi planiranja projekta.
Nije da za to nema uvijek i dobrih razloga, ali razlozi uglavnom počivaju na neiskustvu voditelja
projekta ili (daleko više) u određenoj dozi agresivnosti što naručitelja projekta što vremenskom dosegu
projekta (odnosno, ljudi bi znali reći - vremenskoj stisci), ali o tome sam dovoljno lamentirao u
prethodnom poglavlju.
Metodologija upravljanja projektima: Planiranje projekta I stranica 6
Proces planiranja projekta
Proces planiranja projekta razlikuje se od metodologije do metodologije, ali gotovo sve imaju osnovne
elemente zajedničke. Za potrebe ove knjige definirati ćemo pet osnovnih elemenata oko kojih gradimo
proces planiranja projekta: doseg (scope), nabavu (procurement), komunikaciju (communication), rizik
(risk) te kvalitetu (quality). Pojedini autori ovdje dodaju i razne druge elemente a ponekad ih i grupiraju
u različite primarne i sekundarne grupeiv koje objedinjuju elemente u funkcionalne cjeline. Zanimljivo je
da bez obzira na pristup, sve metodologije završavaju fazu planiranja projekta s ultimativno točnim i
konkretnim (korektnim) projektnim planom, bez obzira da li se on vodio na papiru ili imate na
raspolaganju moderne elemente vođenja projekta kao što je npr. Microsoft Project proizvod.
Doseg projekta
Planiranje dosega projekta je proces koji završava s jasno definiranim elementima što projekt treba
postići i što se od njega očekuje – ovdje ne treba miješati doseg projekta s dokumentom inicijacije
projekta (vidjeti Metodologija: inicijacija projekta). Planiranje dosega zapravo možete promatrati kao
pretfazu ispred procesa planiranja, gdje tim razjašnjava sve pretpostavke, ograničenja, objašnjenja,
specifikacije, nedoumice, opise radnih procesa te konačne isporuke projekta.
Pretpostavke projekta
Pretpostave na projektu su svi oni elementi planiranja projekta za koje se zna da moraju postojati da bi
se projekt uspješno i na vrijeme ostvario. Na primjer, prilikom postavke programskog rješenja,
pretpostavka može biti da korisnik posjeduje određeno sklopovlje koje može uspješno upogoniti
programsko rješenje. Kod izvođenja građevinskih radova, pretpostavka je da podizvođač posjeduje sve
radne strojeve potrebne za izvođenje njegovog dijela posla, dok je kod uvođenja ISO standarda u
organizaciji pretpostavka da organizacija posjeduje prateću dokumentaciju svojih procesa.
Primijetite da pretpostavka nije uvijek i nužno ispunjena u trenutku pisanja dosega projekta – ona se
samo taksativno navodi kako bi se ista mogla kasnije, tijekom projekta, i pratiti i ispunjavati kroz
projektni plan i plan upravljanja rizicima – pretpostavke gotovo uvijek uključuju i rizik.
Ograničenja projekta
Ograničenja na projektu su svi oni elementi planiranja projekta koji mogu utjecati na pozitivan
napredak projekta, bilo da ga usporavaju ili ga u potpunosti zaustavljaju. Na primjer, prilikom postavke
programskog rješenja, ograničenje može biti dostupnost kvalificiranih i stručnih djelatnika naručitelja
projekta koji moraju sudjelovati u projektu – čest slučaj na našim lokalnim implementacijama.
Ograničenja na projektu nisu uvijek tako rizična kao što su pretpostavke, ograničenja su uvijek jasno
definirana i njima je lako upravljati, jedino postoji problem njihovog pravodobnog uočavanja i već
prema tome planiranja projekta.
Objašnjenja projekta su nešto jednostavnija i proizlaze iz faze inicijacije projekta. Recimo da je
inicijacija projekta objasnila što su strateški ciljevi projekta – povezivanje projekta s ciljevima
organizacije, poslovna vrijednost koju organizacija može očekivati izvođenjem projekta itd. No, ovdje
vam nedostaje operativna i taktička razina projektnih ciljeva i to je upravo ono što se definira kroz
objašnjenje projekta unutar dosega – koje ciljeve projekt ima na operativnom (taktičkom) nivou. Na
primjer, projekt implementacije programske podrške može donijeti na nivou organizacije povećanu
kontrolu troškova i povećanje profitabilnosti, ali to znači promjene u radnim procesima organizacije
koje će biti implementirani ne samo kroz programsku podršku nego i kroz promjenu politika i
procedura koje podržavaju trenutne radne procese.
Metodologija upravljanja projektima: Planiranje projekta I stranica 7
Specifikacija proizvoda
Specifikacija krajnjeg proizvoda uvijek je tema oko koje se lome koplja – no bitka ovdje još uvijek ne
započinje. Funkcionalna specifikacija nije nešto što bi se trebalo nalaziti u dosegu projekta, no
detaljnije razjašnjenje onog što piše u inicijaciji projekta (odnosno, ovisno o tome kako je projekt
započet, u tenderu ili zahtjevu za ponudom) svakako je nešto što bi se trebalo nalaziti ovdje.
Za razliku od specifikacije krajnjeg proizvoda, krajnje isporuke je prilično jednostavno definirati – i to
upravo razmatrajući projekt s stanovišta što korisnik želi dobiti na kraju projekta. Ako su svi uvjeti
(ciljevi) projekta ispunjeni, korisnik će završetak projekta vjerojatno potvrditi nekakvim zapisnikom o
primopredaji a koji će u sebi sadržavati pregled krajnjih isporuka projekta te potpise korisnika da su
upravo te isporuke i izvršenev. Na primjer, dio pregleda krajnjih isporuka postavke programskog
proizvoda Microsoft Office može biti:
• Korisnici će moći čitati i slati elektroničku poštu kad su spojeni na mrežu, s time da će se
razmjena elektroničke pošte događati istodobno kada je pošta poslana, odnosno kada je
primljena na centralni poslužitelj
• Korisnici će moći čitati i slati elektroničku poštu kada nisu spojeni na mrežu, s time da će se
razmjena elektroničke pošte događati u trenutku kada se korisnik spoji na mrežu, te kada je
moguće dohvatiti centralni poslužitelj
• Korisnici će moći čitati i slati elektroničku poštu uporabom Internet Web preglednika, s
ograničenom funkcionalnošću, sa bilo kojeg javnog i privatnog pristupnog mjesta
• Korisnici će moći čitati i slati elektroničku poštu uporabom handheld PocketPC te SmartPhone
korisničkih uređaja, nakon što se spoje na mrežu uporabom GPRS ili ActiveSync pristupnih
protokola...
Ako su uvjeti ispunjeni, ispunjen je i cilj projekta – organizacija u ovom trenutku možda ne zna koliko
je i kakvih resursa potrebno za projekt, kakva će se tehnologija primijeniti, koliko će dugo projekt
trajati, ali gledajući s poslovnom aspekta, prilično im je jasno što s projektom organizacija dobiva.
No to ne znači da pojedini elementi kao što su cijena, trajanje i performanse projekta neće biti
navedene u ovom dokumentu – čak štoviše, to su obavezni elementi dosega projekta. No, za razliku od
pojedinačnih planova koji pokrivaju te elemente, ovdje oni mogu biti navedeni samo taksativno i na
visokom nivou – ukupna cijena bez brakdown strukture, okvirno trajanje projekta u čovjek/mjesecima
ili kalendarskim mjesecima itd. Pitanje je naravno koliko to može biti točno u trenutku kada niti nije
gotov krajnji plan projekta – tako da se prilikom procjene moraju koristiti prethodna iskustva koje
ponuditelj posjeduje ili jednostavno treba uzeti vanjskog stručnjaka koji tako nešto može potvrditi, no
bitno je navesti da je ovo samo procjena, a ne i konačna ponuda (odnosno izračun). Bitno je zapamtiti
da u fazi dosega projekta ne postoji točna ili detaljna procjena – svi elementi koji se iznose, iznose se
samo stoga da bi projekt bio razumljiviji te da bi se na osnovu nečega moglo krenuti s detaljnijim
planiranjem projekta.
Na kraju, isto tako kao što je bitno uključiti sve elemente koji pripadaju projektu, bitno je i isključiti one
elemente koje projekt neće obuhvatiti. Zašto je ovo bitno, upitati će čitatelj samog sebe? U ovom
trenutku to i nije tako vidljivo, ali kada korisnik tijekom projekta započne s nekontroliranim zahtjevima
o proširenju funkcionalnosti projekta, sjetiti ćete se da je „što ovaj projekt ne obuhvaća“ lista zapravo
vaša najbolja garancija obrane od propasti projekta i čudnih izjava tipa „pa mi smo mislili da se to
podrazumijeva“. No, ponuditelj ni u ludilu nije nešto „podrazumijevao“ pa naravno da dolazi do
sukoba interesa – kako još nisam sreo projekt u kome je upravitelj uspio odbiti baš 100% svih novih
Metodologija upravljanja projektima: Planiranje projekta I stranica 8
zahtjeva, logika nalaže da će se projekt promijeniti. A time se mijenjaju svi parametri projekta – sjetite
se trokuta iz prethodnog poglavlja.
I na kraju, nakon što imamo sve elemente dosega projekta, potrebno je potvrditi dokument. To
uglavnom znači i formalno potpisani dokument od svih zainteresiranih strana projekta: korisnici,
izvođači, nadzorni organi itd. Bitno je razumijevati da je tako potpisan dokument osnova cijelog
projekta – ako se što mijenja u projektu, mijenja se i dokument (odnosno, njegova nova verzija) – ali
kao što sam već napisao, onda to uzrokuje i promjene parametara projekta.
Metodologija upravljanja projektima: Planiranje projekta I stranica 9
Doseg projekta: Radni zadaci WBS (Work Breakdown Structure)
Za početak podsjetimo se kako su naši stari išli na ljetovanje na naš plavi Jadran prije recimo
dvadesetak, tridesetak godina. Ja se toga ne samo dobro sjećam nego sam bio i živi sudionik napora
koje je naša mala zajednica imala svake godine da bi se provelo 7 dana u nekom sindikalnom
ljetovalištu pržeći se na suncu i pokušavajući pronaći najkraći put do koliko toliko tamne boje. Za one
mlađih godina koji su od početka imali priliku uživati u blagodatima autoceste ili nekih boljih
prijevoznih sredstava (čitaj: klima i može povući brže od 200 na sat), odlazak na more je bio prava
pustolovina: danima se planiralo kako izbjeći nesnosne vrućine (nemate klimu pa na put krećete u
03:00 dok je mrak), gdje natočiti gorivo (stojadin troši 17 litara supera na 10 kilometara, a ni benzinske
nisu baš na svakih nekoliko kilometara), gdje stati i jesti (jer eto djeca su non stop gladna a i nekako je
OK napraviti pauzu nakon 8 sati neprekidne vožnje) i slično. Takav put je zahtijevao detaljno planiranje
– što odraslih koji su bili zaduženi za to, tako i nas djece jer eto, nikada ne znaš što ti se na moru može
dogoditi (recimo, možda neka prva morska ljubav s Veronikom iz Brna). Dakle, planiranja nije
nedostajalo, barem ne u mojoj obitelji. No, znam za neke koje su isto tako išle navrat nanos na more, i
začudo, stigle tamo bez ikakvih problema. A i nama se ponekad nešto nepredviđeno dogodilo.
Planiranje je osnova bilo koje akcije koju današnji čovjek (bez obzira išao na more ili ne), mora
poduzeti da bi ostvario svoj cilj.
Namjena WBS strukture
Razgovaramo li o upravljanju projektom, većina ljudi pred očima ima hijerarhijski WBS – cjelovit i
konzistentan pregled radnih zadataka projekta, tako jednostavno i pregledno složen da bi ga i većina
managementa (ali i moja baka) mogli razumjeti (za one upućenije, uglavnom se radi o pogledu na
Gantt Chart, što nije ekvivalentno s WBS pregledom zadatakavi). Ponekad se za WBS govori da je to
jednostavno popis zadataka (task list) s obzirom da je glavna namjena WBS strukture pretvoriti to
veliko i komplicirano čudovište zvano projekt u male, upravljive jedinice zvane radni (projektni) zadaci.
PMBoK definira WBS kao „grupiranje projektnih elemenata koji organiziraju i definiraju ukupni radni
doseg projektavii“. Već time je jasno da je WBS ključni element projekta – ovdje se napuštaju priče
vezane uz high-level opise te preglede za management i slične koji nemaju vremena čitati više od dvije
stranice teksta. Koji su osnovni zadaci kreiranja WBS struktureviii?
• Pregledno određivanje specifičnih radnih aktivnosti koje je potrebno ostvariti da bi se
ostvario cilj projekta. Iako doseg posla definira zahtijevani napor na projektu na
konceptualnom nivou, tek će ga WBS struktura stvarno prikazati što je potrebno napraviti na
projektu.
• Pomoć u određivanju zahtijevanih resursa koji će odraditi aktivnosti kao i određivanje
nivoa njihovih znanja i sposobnosti. Uporabnom WBS strukture djelatnici dobivaju precizne
upute što im je za raditi na projektu, a ujedno mogu vidjeti gdje i kako se njihov posao uklapa
u sliku cijelog projekta.
• Pružanje osnove za procjenu cijene, resursa i vremena koji će se angažirati za ostvarenje
projektaix. Pojedini WBS zadatak mora sadržavati elemente resursa, vremena i učinka za
navedeni zadatak – što je osnova za procjenu trajanja projekta te količinu resursa koje je
potrebno angažirati za dovršetak projekta.
• Prepoznavanje osnova za mjerenje učinkovitosti i stvarnog napretka projekta, ovisno o
tome što i kada očekujemo od projektax. Kako je svaki zadatak u WBS strukturi jednostavno
„mjeriti“ (koliko je i da li je izvršen), lako je pratiti napredak projekta.
• Pružanje osnove za stvaranje učinkovitog upravljanja promjenama u projektu
Razni projekti imaju razne pristupe uporabi WBS strukture. Prema rigidnim metodologijama, WBS je
toliko bitan dio projekta da je potrebno izuzetno točno i detaljno specificirati svaku aktivnost u
Metodologija upravljanja projektima: Planiranje projekta I stranica 10
projektu – ako nije specificirana, aktivnost nije dio projekta. Naravno, većina ljudi bi vam rekla da je to
gotovo nemoguće, no to ostavljam za odluku pojedinom upravitelju projekta kako će pristupiti ovom
problemu. Predetaljno specificiranje radnih zadataka vjerojatno nije učinkovito s obzirom na vrijeme i
resurse, a ponekad ga zbilja nije ni moguće ostvariti (recimo da dio projekta ovisi o rezultatima
testiranja proizvoda u laboratoriju). No, praksa je pokazala – što detaljnije, to bolje.
Kreiranje WBS strukture
Kako pristupiti kreiranju WBS strukture? Iako na prvi pogleda izgleda ponešto komplicirano, čak i
uporaba obične olovke i papira jest dovoljna da se kreira potpuno detaljna (ne nužno i kompleksna)
struktura radnih zadataka. Sjetite se da vam je za početak nužan doseg projekta, koji definira osnovne
ciljeve projekta te ujedno i načine kako ćemo do njih stići – sada je na nama da definiramo detalje koji
će ovakav zadatak i ispuniti. Postoje dva osnovne pristupa kreiranju WBS strukture, jedan kroz uporabu
formalne metodologije, a drugi kroz primjenu krajnjih isporuka. Jedan ne isključuje drugog, naprotiv,
formalna metodologija uvijek sadrži elemente krajnje isporuke – samo se projekt formalno vodi kroz
metodologiju, te pojedine isporuke koincidiraju s završetkom pojedine faze formalne metodologije.
Tako, na primjer, bez uporabe formalne metodologije, osnovni pristup kreiranju hijerarhijske strukture
projekta bi bio:
• Projekt
o Cilj projekta A
o Cilj projekta B
o Cilj projekta C
Dok bi uz uporabu formalnog načina to izgledaloxi:
• Projekt
o Projekt: inicijacija
o Projekt: planiranje
o Projekt: izvršenje
▪ Projekt: Izvršenje: Izvršenje projekta A
▪ Projekt: Izvršenje: Izvršenje projekta B
▪ Projekt: Izvršenje: Izvršenje projekta C
o Projekt: kontrola
▪ Projekt: Kontrola: Cilj projekta A
▪ Projekt: Kontrola: Cilj projekta B
▪ Projekt: Kontrola: Cilj projekta C
o Projekt: zatvaranje
Drugi način prikazivanja WBS strukture je prikazivanje putem Chart forme (odnosno isto tako u
hijerarhijskog strukturi ali daleko preglednije):
Metodologija upravljanja projektima: Planiranje projekta I stranica 11
slika: Work breakdown struktura u Chart formi
Malo više pregledne kontrole, zar ne? Grafički prikaz daje pregledniju sliku o tome što je sve potrebno
napraviti, ali je hijerarhijski list prikaz puno praktičniji pogotovo ako se projekt sastoji od nekoliko
desetaka ili stotina zadataka – ažuriranje takve WBS strukture je puno jednostavnije nego grafičke
Chart forme.
KLJUČNI POJAM. Da bi u potpunosti razumjeli kako se izvršava WBS struktura, bitno je primijetiti da
postoje dva tipa WBS zadataka: zbirni zadatak te radni zadatak (možda je jednostavnije engleski
napisati summary task te work package). Zbirni zadatak je skup pojedinačnih radnih zadataka i sam po
sebi ne predstavlja zadatak koji je potrebno izvršiti – njegovo izvršenje nastupa tek kada su u
potpunosti izvršeni svi radni zadaci. Na primjer, na prethodnoj slici Projekt izvršenje je zbirni zadatak,
dok su Izvršenje projekta A, Izvršenje projekta B i Izvršenje projekta C radni zadaci. Tek kada se
izvrše sva tri navedena zadatka, možemo smatrati da je i zbirni zadatak izvršen. No, uvijek imajte u vidu
čemu stvarno služi zbirni zadatak – on sam po sebi nema uz sebe vezanu neku akciju, te služi isključivo
za potrebe pojašnjavanja i informiranja. Ako zbirni zadatak nema te odlike – slobodno ga brišite iz
strukture.
No, kao što sam i napisao, forma uglavnom ovisi o metodologiji, no potrebno je pripaziti s formama i
predlošcima koje donosi metodologija (odnosno, uglavnom pripadajući CD ili Web site – pogrešna
uporaba predloška jedan je od najvećih smrtnih grijeha koje si upravitelj projekta može dozvoliti
(pogledati dodatnu informaciju o Steve McConnellu).
Kako pristupiti kreiranju WBS strukture?
Pet je osnovnih koraka koje je potrebno poduzeti da bi izgradili dobru WBS strukturu:
1. Započnite od vrha strukture i gradite ju prema dolje, do najdetaljnijih zadataka. Struktura
se uobičajeno gradi od vršnih (major) elemenata prema nižim (minor) elementima – zadacima
WBS strukture, prilično slično onome što možete koristiti u Microsoft Word programu,
odnosno u njegovom Outline pogledu na dokument. Ovakav pristup u stručnoj literaturi se
uobičajeno naziva top – bottom pristup. Uobičajeno, vršni elementi upravo su oni elementi koji
se pojavljuju u Vision / Scope ili Charter dokumentima projekta (pogledajte fazu Inicijacije
Metodologija upravljanja projektima: Planiranje projekta I stranica 12
projekta). Time ste osigurali da i management razumije što gradite u projektnom planu
(uporabom WBS strukture) jer upravo ponavljate njihove odrednice koje su definirane u
navedenim dokumentima. Naravno, za pretpostaviti da će upravo one biti high – level opisne
odrednice, jer kao što smo naveli u dokumentima tog tipa se ne ide u detaljnu razradu
projektnog zadatka. Graditi strukturu na pregledan način nije jednostavno i jedini ispravan
način je uz uporabu široko dostupne programske podrške za upravljanje projektima – na
primjer, Microsoft Project. Teško je zamisliti da ćete sve ispravno napraviti od prve, a i da neće
biti izmjena – radni zadaci će se seliti i mijenjati na dnevnoj bazi u vrijeme planiranja i zgodno
je imati pri ruci pametan softver koji će vam to olakšati.
2. Obavezno uključite i pravilno imenujte sve zadatke koji završavaju s određenom
projektnom isporukom. Pravila imenovanja zadataka su vrlo jednostavna: ako krećete od
isporuka, onda takve isporuke uglavnom imenujemo imenicama: „sklopovlje“, „program“,
„dokumentacija“ itd. Takvim imenicama potrebno je dodati glagole: „postavljanje sklopovlja“,
„instalacija programa“, „isporuka dokumentacije“. Slijedeći korak je daljnja nadogradnja
odnosno dekompozicija zadataka te ponovno primjenjivanje procesa imenovanja. Tako se na
primjer „instalacija programa“ može sastojati od „sklopovlja“ i „programskog koda“, odnosno
„priprema sklopovlja“, „testiranja sklopovlja“, „instalacije programskog koda“, „provjere
programskog koda“ itd. Iako ovo izgleda jednostavno, zahtjeva uključivanje svih članova
projektnog tima, jer će upravitelj projekta teško znati koje je sve projektne zadatke potrebno
uspostaviti da bi se projekt uspješno završio. Uobičajeno vršne zadatke može definirati ekspert
ili upravitelj, ali se nakon toga podgrupe zadataka predaju pojedinim članovima tima –
ekspertima da bi detaljno razradili sve zadatke koji su potrebni. No, prije no što se to napravi,
potrebno je usvojiti određena pravila imenovanja i zajedničke konvencije kako bi projektni
plan ipak imao unificirano imenovanje zadataka, odnosno sličnije razmišljanje članova
projektnog tima što točno dekompozicija zadatka znači i do koje dubine obrade takvog
zadatka je potrebno ići – nema smisla da jedan ekspert svoj zadatak raščlani na 2 podzadatka
(jer eto, ipak se sve podrazumijeva i jasno je) dok će drugi svoju raspodjelu napraviti na
100tinjak podzadataka (jer eto, bolje da što detaljnije razjasnimo što nam je za činiti). Osim
toga, zanimljivo je da se ovim pristupom na neki način „kupuje“ uključivanje članova tima u
projekt, jer članovi tima sami definiraju što im je za činiti i koji se zadaci od njih očekuju.
3. Držite se pravila 8/80. Zapravo je ovdje bolje započeti s raspravom o tome koliko bi stvarno
maksimalno ili minimalno trebao trajati radni zadatak. Vidio sam zadatke koji traju po nekoliko
mjeseci i uključuju nekoliko resursa – no, tada je takve mega-zadatke pogrešno i nazivati
„zadatkom“, to je više podprojekt ili projekt sam za sebe. Ovakvi zadaci propast su već sami po
sebi – ne samo što je gotovo nemoguće pratiti njihovo nastajanje i tijek odnosno gotovost,
nego je nemoguće dobiti uopće informaciju o stanju ili kvaliteti odrađivanja zadatka. Zato,
zlatno pravilo kaže: „držite se 8/80 pravila“ (pravilo o pravilu). Vrlo je jednostavno – niti jedan
zadatak ne bi smio biti manji od 8 sati, niti jedan zadatak ne bi smio biti veći od 80 sati.
Odnosno, u radnim danima – dnevno bi se trebao odrađivati najviše jedan zadatak i jedan
zadatak bi trebao trajati najviše 2 tjedna. Primijetite da se ovdje govori o 2 radna tjedna – što u
praksi znači 10 radnih dana, a ne 14. Osim ako već ne radite na projektu kojim je tako dobro
upravljano da vam dva radna tjedna zapravo znače 18 dana.
4. Držite se pravila kontrolnih točaka. Poput gornje navedenog pravila i ovo je jednostavno –
ako već postoje kontrolne točke, iskoristite ih za ograničavanje svojih projektnih zadataka. Uz
kontrolne točke uobičajeno se veže i određeno izvještavanje – time je jednostavnije izvijestiti o
statusu projekta. Pojedini autori kažu da bi bilo zgodno imati tjedne sastanke odnosno
izvještavanje pa već prema tome niti jedan zadatak ne bi trebao trajati duže od tjedan dana.
No, osim što je to u suprotnosti s 8/80 pravilom, ipak je na vama odrediti hoćete li kao
kontrolne točke imati točke izvještavanja ili same kontrolne točke projekta (milestones). Ako se
odlučite na ovo drugo, onda su stvari jasne, jer već po pravilima upravljanja projekta niti jedan
zadatak ne može trajati duže od kontrolne točke – inače kontrolna točka i nije baš – kontrolna.
Metodologija upravljanja projektima: Planiranje projekta I stranica 13
5. Ostala opća pravila definiranja zadataka. Ostala pravila i nisu baš pravila nego grupa zdravo
razumskih akcija odlučivanja o tome kako kreirati zadatke u projektu. Na primjer, upravitelj
projekta će ipak imati najbolji osjećaj koliko detaljno treba ići u razradu projektnih zadataka.
Pravio 8/80 možda izgleda kao vrlo intuitivno i razumno, ali ako se radi o specifičnim detaljima
koje mogu odrediti tijek projekta i njegov završetak – detaljizirajte vi koliko je god potrebno,
pa makar došli do micromanagementa (zanimljivo je da se micromanagement ili inchstone
planning kao projektni pristupi redovito sreću kod projekata koji su izvan kontrole pa ih
pokušavate vratiti u normalu, ali o tome u pripadajućem poglavlju). Isto tako, ako imate
problema s resursima (čitaj: djelatnicima) u projektu, vjerojatno je da ćete dio zadataka
prilagoditi upravo onome čime raspolažete u projektu. Ako je resursa manje, vjerojatnije je da
će dobivati veće i dugotrajnije zadatke kako bi jednostavno mogli upravljati svojim vremenom
kojeg ionako neće biti previše.
KLJUČNI POJAM. Upravljanje projektima postoji već nekoliko stotina godina – možda se samo tako
nije od početka zvalo. U svojoj novijoj povijesti, već se stotinjak godina prati i bilježi kako se izvode
projekti, a informatički projekti su izrazito podložni dokumentiranju što i kako s zadatkom. TO samo
znači da je projekt sličan ili istovjetan vašem već negdje odrađen, pitanje je samo kako navedeni
projektni plan izgleda i odgovara li vašim potrebama. Ako se malo potrudite lako možete uporabom
Interneta ili vanjskih kuća koje se bave upravljanjem projektima vrlo brzo imati respektabilnu bazu
projektnih planova (ali i ostale dokumentacije) koja vam može ukazati na to kako određeni zadatak
riješiti ali i kako drugi ljudi pristupaju rješavanju problema. No, takvi predlošci nisu uvijek i najbolje
rješenje za vas – pročitajte što o tome misli Steve McConnnell.
9 smrtnih grijeha projektnog planiranja Steve McConnella
U vrijeme kada su pojedine projektne organizacije postigle gotovo savršenu kontrolu izvedbe
projekata, druge još uvijek postižu tek prosječne rezultate - istraživanja ukazuju da je jedan od
ključnih problema loše planiranje projekata. Kako prepoznati loše planirani projekt? Evo devet
smrtnih grijeha koje je moguće pronaći u planiranju projekata.
1. Planiranje uopće ne postoji
Daleko najveći problem s planiranjem je nepostojanje istoga – i to je grijeh kojeg je vrlo lako izbjeći.
Osoba ne mora biti stručnjak da bi bila sposobna učinkovito planirati. Nebrojeno je primjera u
kojem su amateri vodili projekte i koji su završili vrlo uspješno jednostavno zbog činjenice da su svi
ljudi uključeni u projekt vrlo savjesno razmotrili potrebe projekta. Ako je potrebno odlučiti između
eksperta u planiranju koji ne prolazi detaljno kroz svoj plan i amatera koji će vrlo detaljno proći kroz
sve potrebe i zavisnosti projekta, ja uvijek biram amatera.
2. Nedovoljno posvećena pažnja određenim projektnim aktivnostima
Ako je Smrtni Grijeh br. 1 nepostojanje planiranja, onda je Smrtni Grijeh br. 2 nedovoljno planiranje.
Pojedini projektni planovi zasnivaju se na činjenicama da se nitko u projektnom timu neće razboljeti,
otići na trening, uzeti godišnji odmor ili jednostavno dati otkaz. Ključne aktivnosti se uglavnom
podcjenjuju – planovi koji se temelje na nerealističnim pretpostavkama uglavnom su siguran put u
propast.
Postoje razne varijacije ne tu temu. Pojedini projekti jednostavno zanemaruju činjenice da je
potrebno kreirati i (ako za primjer uzmemo programske proizvode) programe za postavku,
konvertirati podatke iz starih ili prethodnih verzija programa, pripremiti odraditi prijelaz na novo
programsko rješenje, provesti detaljno testiranje kompatibilnosti te odraditi sav ostali nenadani
Metodologija upravljanja projektima: Planiranje projekta I stranica 14
posao koji uvijek postoji u projektu, ali ga većina upravitelja ignorira jer nije dio izvedbe osnovne
funkcionalnosti.
Ponekad projekti koji su u zakašnjenju pokušavaju nadoknaditi izgubljeno vrijeme smanjujući
vrijeme koje je planirano za testiranje proizvoda; imajući u glavi pretpostavku da se vjerojatno neće
pojaviti značajnija količina problema koje je potrebno prepoznati i ispraviti. (Kao domaća zadaća
ostavlja se čitatelju otkrivanje razloga zašto – ako je to već stvarno tako – nije već u početku
planirano kraće vrijeme testiranja.)
3. Nepostojanje upravljanja rizikom u projektu
U knjizi Design Paradigms,xii Henry Petroski tvrdi da su najveće pogreške u dizajnu mostova nastajale
nakon određenog razdoblja uspjeha u dizajnu i gradnji istih što je dovelo do jednostavnog
ponavljanja dizajna novih mostova. Dizajneri su jednostavno kopirali atribute postojećih mostova ne
obraćajući dovoljno pažnje na potencijalne uzroke problema koji su uvijek bili specifični za svaki
novi most.
Za većinu projekata, aktivno izbjegavanje pogrešaka je bitno kao i postizanje uspješnog završetka
projekta. U većini poslovnih okruženja, riječ „rizik“ se uglavnom ne spominje sve dok projekt nije u
dubokim problemima. Kod projekata, upravitelj projekta koji ne koristi riječ „rizik“ svakodnevno i koji
ne uključuje upravljanje rizicima u svoje planove vjerojatno ne radi svoj posao. Kao što Tom Gilb
kaže, "Ako aktivno ne napadate rizike u svom projektu, oni će aktivno napasti vas“xiii
4. Uporaba istog projektnog plana za svaki projekt
Pojedine organizacije razvijaju svoje pristupe i metodologije kako voditi projekte, pristup poznat
pod nazivom „način kako mi radimo ovdje“. Kada organizacija koristi ovaj pristup, bilo koji novi
projekt koji je sličan starom projektu ima velike šanse za uspjeh. Međutim, kada je novi projekt ne
sliči starom projektu, uporaba postojećih planova za upravljanje projektom može više štetiti projektu
nego što će mu pomoći.
Dobri projektni planovi uvijek adresiraju određene uvjete u kojima projekt nastaje. Većina elemenata
može biti ponovo upotrebljiva, ali upravitelji projekta moraju pažljivo razmisliti o tome u kojem se
dosegu pojedini element prethodnog plana može primijeniti u okruženju novog projekta.
5. Pojednostavljena uporaba predložaka projektnih planova
Vrlo sličan problem kao što je Smrtni Grijeh br. 4 je uporaba generičkih predložaka projektnih
planova koje je kreirao netko drugi bez primjene kritičkog razmišljanja o specifičnim potrebama
vašeg projekta. "Nečiji plan“ uglavnom stiže u obliku knjige ili metodologije koju upravitelj projekta
primjenjuje out-of-the-box. Najbolji primjeri toga su Rational Unified Process,4 Extreme
Programming,5 i donekle (uprkos mojim namjerama da postignem upravo suprotno) sadržaj moje
knjige Software Project Survival Guide6 te metodologija moje tvrtke CxOne. Ovi predlošci mogu
pomoći kod izbjegavanja Smrtnog Grijeha br. 1 Smrtnog Grijeha br. 2, ali ne mogu zamijeniti
razmišljanje o planu te njegovoj optimizaciji prema jedinstvenim zahtjevima vašeg projekta.
Niti jedan vanjski ekspert ne može tako dobro razumjeti specifične potrebe projekta kao što to
mogu ljudi koji su u projekt direktno uključeni – ljudi koji kreiraju stvarni projektni plan moraju
prilagoditi plan „eksperta“ prema specifičnim zahtjevima svog projekta. Iskustvo je pokazalo da,
srećom, upravitelji projekata koji čitaju knjige o programskom inženjerstvu uglavnom posjeduju
dovoljno zdrave pameti da znaju izabrati koje dijelove predložaka mogu uporabiti u svom projektu.
6. Projektni plan ne slijedi projektnu stvarnost
Uobičajeni pristup planiranju uključuje kreiranje projektnog plana na početku projekta, koji se
potom odloži negdje na policu i skuplja prašinu tijekom ostatka projekta. Kako se projektni uvjeti
Metodologija upravljanja projektima: Planiranje projekta I stranica 15
mijenjaju, plan postaje nepotpun i nevažeći, tako da već negdje u sredini projekta projekti žive
svojim životom, bez stvarne veze između projektnog plana koji se nije mijenjao i stvarnosti projekta.
Ovaj Smrtni Grijeg donekle proizlazi iz Smrtnog Grijeha br. 5 – upravitelji projekata koji prihvaćaju
predloške projektnih planova kakvi već jesu u principu nerado mijenjaju planove tijekom projekta
kada se ustanovi da isti ne funkcioniraju. Većina upravitelja misli da postoji problem u primjeni
predloška projektnog plana kada u stvarnosti ono što nije ispravno jest sam projektni plan. Dobro
upravljanje projektom primjenjuje upravljanje tijekom cijelog projekta.
7. Planiranje previše detalja prerano u projektu
Pojedini upravitelji projekata (u dobroj namjeri) pokušavaju predvidjeti cijeli projekt – sve aktivnosti
vezane uz njega – što ranije u projektu. No, većina projekata se sastoji od neprestano mijenjajućeg
seta odluka koje utječu na stvarno odvijanje projekta – jedna projektna faza kreira ovisnosti za
drugu projektnu fazu itd. Kako upravitelji nemaju kristalne kugle s kojima mogu predvidjeti
budućnost, pokušaj planiranja aktivnosti koje su gotovo nepredvidive zapravo je samo vježba u
birokraciji koja je gotovo jednako loša kao i potpuno nepostojanje projektnog plana.
Što više se truda uloži u stvaranje vrlo detaljnog projektnog plana u ranim fazama projekta, to je
vjerojatnije da će projektni plan završiti negdje skupljajući prašinu na polici (Smrtni Grijeh br. 6).
Kako nitko ne voli odbaciti nešto u što je uloženo puno truda, upravitelji projekta ponekad
pokušavaju realnosti u projektu prilagoditi ranije definiranim planovima, namjesto da prilagode
projektne planove stvarnosti u projektu.
Vjerujem da je dobro upravljanje projektima nešto poput vožnje auta s upaljenim svjetlima tijekom
noći. Vozač može imati kartu koja će mu reći kako stići od Grada A do Grada B, ali pre sobom vidi
samo onoliko koliko u osvjetljavaju svjetla njegovog auta. Na srednje velikim i velikim projektima,
potrebno je napraviti high level projektne planove koji zahvaćaju procese od početka do kraja
projekta. Detaljni, micro-level planovi moraju se razvijati na nivou planiranja za slijedećih nekoliko
tjedana, ili ako to projekt dozvoljava, uporabom „just in time" principa planiranja.
8. „Planiranje“ naknadnog završetka zadataka
Tipična greška za projekte koji kasne je planiranje mogućnosti da se zakašnjenje nadoknadi kasnije u
projektu. Postoji razmišljanje: „Tim je imao zbilja težak početak projekta – morali smo učiti na svojim
pogreškama. Ali sada kad smo naučili i prošli tu fazu, sad znamo što treba napraviti i u mogućnosti
smo brzo završiti projekt“. Pogrešno razmišljanje! Studije pokazuju da projekti rijetko uspiju
nadoknaditi vrijeme – upravo suprotno – većina projekata nastavlja gubiti vrijeme tijekom cijelog
projekta.7 Pogreška u racionalizaciji leži u razmišljanju da projektni timovi kreiraju svoje najbitnije
odluke relativno ranije u projektu – vrijeme kada se usvajaju nove tehnologije, nova poslovna znanja
i nove metodologije. Kako timovi rade dalje na projektu, projekt se ne ubrzava; naprotiv, on se
usporava jer se susreće s posljedicama pogrešnih odluka koje su ranije donesene u projektu, te se
troši dodatno vrijeme na ispravljanje posljedica takvih odluka.
9. Neučenje iz napravljenih pogrešaka
Najveći smrtni grijeh koji je moguće počiniti je ne učiti iz grešaka koje smo napravili. Projekti mogu
trajati dugo vremena, a ljudska sjećanja mogu biti zamagljena egom i protekom vremena. Do kraja
dugog projekta biti će teško sjetiti se svih odluka koje su utjecale na stvarnost projekta.
Jedan od dobrih načina da se izađe na kraj s tim problemom i time možda spriječe neki drugi smrtni
grijesi jest provođenje strukturiranog projektnog postmortem pregleda.8 Postmortem pregled
možda neće izbrisati grijehe koji su napravljeni tijekom projekta, ali će sigurno pomoći da se isti ne
ponove na budućim projektima.
Metodologija upravljanja projektima: Planiranje projekta I stranica 16
Kad već pričamo o radnim zadacima, bitno je da vas ne zbuni razlika između radnog zadatka i
aktivnosti. Iako pojedini izvori razdvajaju njihova značenjaxiv, vjerojatnije je bolje poistovjetiti ih i time
sebi pojednostaviti razumjevanje onoga što se u projektu treba napraviti.
Što je točno radni zadatak? Radni zadatak je jedinica posla koju mogu obaviti jedan ili dva djelatnika u
vremenu ne dužem od dva tjedna (barem tako kaže jedna od bezbrojnih definicija). Zašto se
uobičajeno koristi ova odrednica? Ako radni zadatak mora obaviti više od dva djelatnika, to je
vjerojatno dobar znak da ga treba dalje razdvajati na podzadatke u kojima će se detaljnije specificirati
što koji od djelatnika radi. Ako radni zadatak traje duže od dva tjedna, vjerojatno će biti kompliciranije
pratiti što se s zadatkom događa i da li će se uspješno završiti. Zašto je ovakav naglasak na radnim
zadacima? Pa, po teoriji planiranja kvalitetno definirani radni zadaci ne samo što će pojednostaviti
izvršenje projekta nego će naravno i odrediti koji resursi ih trebaju odraditi te koliko će projekt u
konačnici trajati. A cijena resursa ili cijena projekta (ovisno o tome da li projekt razmatrate kroz
time/material ili fixed fee troškovni pristup) u dvije glavne stvari o kojima ćete razgovarati s „gornjim“
managementom. Ili sa svojim neposrednim managerom, ovisno o tome da li vam ide sjajno ili je
projekt u gabuli.
Što bi pojedini radni zadatak morao sadržavati? Ovdje to ne znači – što bi trebali upisati u Project
programsku podršku ili negdje drugdje ne papir, nego jednostavno, što bi o projektnom zadatku
trebali znati da bi ga mogli kao takvog usvojiti:
• Naziv projektnog zadatka. Možda izgleda na prvi pogled glupo, ali ne samo da se mora
definirati, nego se mora kvalitetno definirati (odnosno, naziv mora imati smisla). Nemojte pisati
literarne sastave - već smo definirali kako se daju nazivi projektnog zadatka u prethodnom
dijelu teksta.
• Vlasnik projektnog zadatka. Ovo je nešto jednostavnije – tko „duži“ projektni zadatak. Bitno
je da je uvijek vlasnik samo jedna osoba – bez obzira koliko je djelatnika pridodjeljeno zadatku
(sjetite se da jedan projektni zadatak može raditi više osoba, preporučljivo maksimalno dvije),
samo jedna od njih može biti vlasnik projektnog zadatka. No, primijetite da ovdje govorim
„može“ – vlasnik projektnog zadatka uopće ne mora biti dio tima koji će izvršiti projektni
zadatak, nego bilo koja druga osoba koja je na neki način uključena u projekt. Bez obzira na to
na koji način je odgovornost pridodjeljena - mora se znati tko je odgovoran – sistem
kolektivne odgovornosti nikada nije ni postojao u kapitalizmu, a i našim prostorima polako
izumire.
• Broj radnog zadatka. Vjerojatno samoopisujuće – redni broj radnog zadatka u WBS shemi.
Iako će se brojni ljudi složiti da ovo baš i nije od nekakve bitne koristi u projektu, prilično
dobro dođe kod referenciranja radnog zadatka – ako vam projekt ima više stotina radnih
zadataka biti će ih prilično teško pronaći kada vam trebaju. Ako postoje brojevi, onda je to
jednostavno. Većina prosječnih programskih rješenja ima automatizirani sustav dodjele
brojeva, tako da o tome ne treba posebno voditi računa. Za one koji preferiraju uporabu
„svojih“ alata, kao što su vođenje radnih zadataka u Notepadu, mali savjet: ne dodjeljujte
brojeve sve dok niste u potpunosti organizirali SVE radne zadatke, inače ćete imati zamoran
posao mijenjanja rednih brojeva svaki put kada se promjeni WBS struktura. No, ako vodite svoj
projekt u Notepadu, možda ste i zaslužili ovakav tip zabave.
• Početak radnog zadatka (Start). Datum početka rada na radnom zadatku. Ako koristite
programsku podršku, onda je određivanje početka rada na radnom zadatku prilično
jednostavna stvar – početak uglavnom određuju prethodni radni zadaci (dakle, njihov početak
i trajanje zadatka). S druge strane, ako postoji paralelizam ili zadaci ne ovise o prethodnim
zadacima, onda je određivanje početka radnog zadatka stvar planiranja resursa i/ili neovisnih
grana u projektu.
Metodologija upravljanja projektima: Planiranje projekta I stranica 17
• Trajanje i učinak radnog zadatka. Trajanje je jednostavno vremenski period koliko će dugo od
početka radnog zadatka trajati njegovo izvršenje. Koja je razlika između trajanja i učinka radnog
zadatka? Učinak je ukupno vrijeme provedeno na realizaciji radnog zadatka (na primjer, djelatnik
može raditi samo 4 sata dnevno; ako je za realizaciju zadatka potrebno 20 sati to znači da će mu
ukupno trebati 5 dana. Ovdje je učinak 20 sati, ali je trajanje radnog zadatka 5 dana. Pametan
poslodavac plaća po učinku, a ne po trajanju, zar ne?)xv. Tko određuje trajanje i učinak radnog
zadatka? Iako bi trebalo biti pravilo da to uvijek određuje onaj djelatnik koji će izvršiti zadatak, to
nije uvijek slučaj. I to ne pišem stoga da bih vam objasnio da se kod nas radi krivo (odnosno, da
trajanje definiraju korisnici ili manageri projektnih timova), nego da i sami djelatnici ponekad
pretjeruju i daju vrlo nerazumne okvire trajanja pojedinih radnih zadataka (ali o tome više
naknadno). Pri tome veliku ulogu ima poznavanje „proizvodnog“ procesa od strane upravitelja
projekta – ako vam djelatnik kaže da mu za nešto treba 10 dana, a vi nemate pojma da li je to OK
ili čovjek jednostavno radi svoj interni „projektni buffer“ onda ste u grdnim problemima. Naravno,
djelatnik će se potruditi da trajanje projektnog zadatka bude upravo onakvo kakvo je i
specificirano projektnim planom – ranije se sigurno neće završiti je se uvijek nešto dodatno može
napraviti ne bi li taj zadatak bio izvršen što bolje (znate onu japansku „kaitzen“ – ništa nije
dovoljno dobro da ne bi moglo biti bolje). Ta dilema me zapravo podsjeća na članak koji sam
svojedobno napisao u svom blogu na temu što nam je u projektima potrebnije: konzultant ili
upravitelj projekta (vidi kolumnu). Koliko stvarno o projektu mora znati profesionalni upravitelj
projekta? Ovdje ne govorim o tome kako će se projekt odvijati nego što će projekt postići.
Kako prikupiti ove podatke? Postoje formalni i neformalni način – formalni je precizniji i uključuje
pisane podatke (recimo, formu ili tablicu) dok je neformalni zapravo direktno unošenje ovih
podataka u programski alat kao što je Microsoft Project. Osobno, mislim da je neformalni sasvim
dovoljan za većinu projekata, ali ako imate nešto što može gorjeti pod nogama, onda je možda
bolje imati tablicu (formu) kao što je na slijedećoj slici:
Projektni alat br. 1
Opis radnog zadatka
Naziv zadatka
Vlasnik zadatka
WBS broj Resursi
Početak
Trajanje
Učinak
Ovisnosti
Napomene
Projektni alat br. 1: Opis radnog zadatka
Metodologija upravljanja projektima: Planiranje projekta I stranica 18
Primijetiti ćete neke odrednice koje nisu bile do sada spomenute:
• Ovisnosti. Ovdje se navode oni radni zadaci (uglavnom samo WBS broj) koje je potrebno
završiti prije no što je moguće započeti (ili završiti, ovisno o tipu radnog zadatka) trenutni
radni zadatak. Na primjer, prije no što se pristupi testiranju proizvoda, potrebno je kreirati test
scenarije, odrediti test korisnike, kreirati test dokumentaciju te educirati test korisnike).
• Napomene. No, ovo je lagano – ovdje je moguće dodatno opisati radni zadatak – iz naziva
radnog zadatka to ćete teško shvatiti, a kako je inteligenciju čitača (djelatnika) prilično
nezahvalno prognozirati, bolje vam je što detaljnije opisati što bi trebalo postići radnim
zadatkom. Ponekad, kod radnih zadataka „više“ kategorije ove napomene mogu unijeti i krajnji
korisnici i time zapravo opisati kakvu funkcionalnost žele od krajnjeg proizvoda.
• Resursi. Tko će odraditi projektni zadatak? Ponekad niste u mogućnosti odmah upisati točno
ime djelatnika koji će projektni zadatak odraditi, ali je moguće upisati rolu (na primjer Software
Developer), pa naknadno odrediti i osobu. S druge strane, ako nemate programski alat koji će
vam pomoći oko raspodjele resursa – bolje je ostaviti samo rolu i ne igrati se s djelatnicima sve
dok nemate sve elemente projekta završene – teško ćete „ručno“ predvidjeti koji su vam
resursi slobodni ili koliko su opterećeni u određeno vrijeme.
Jedna od temeljnih pogrešaka upravitelja projekta – početnika (ali i onih naprednijih) čvrsto držanje do
projektnog plana poput, iskoristit ćemo narodnu mudrost „slijepac plota“. Nije ovdje u pitanju samo
projektni plan, već i cjelokupna projektna struktura koja eto uključuje i popis radnih zadataka. Naime,
sve se u projektu može promijeniti – i količina rada i trajanje i doseg i što već – samo je pitanje da li je
to moguće napraviti na kontrolirani način. Kako se projekt odvija, tako će se i njegovi pojedinačni
elementi mijenjati – projekt će se odvijati brže ili će kasniti, trebat će nam više ili manje resursa za
pojedine zadatke. I to je sasvim normalno – pod uvjetom da to staloženo prihvatite i dobro razmislite
kako i na koji način će to utjecati na vaš projekt.
Dakle, ako do promjene dođe (na primjer, trajanje zadatka se poveća sa 2 na 3 dana, to je sasvim u
redu – ionako negdje postoji buffer period koji upravo tome i služi) Ili ne postoji? S druge strane,
postoji i upravljanje rizicima, koje bi trebalo adresirati upravo problematiku lošeg planiranja. Loše
planiranje nastaje upravo zbog nedostatka informacija koje su nam potrebne kod planiranja radnih
zadataka. Što nam je manje informacija dostupno, lošije planiramo svoje radne zadatke i to lošije po
jednom ili više parametara: doseg, vrijeme i resursi. Imamo li problema s nedostatkom informacija,
takav je radni zadatak potrebno istaknuti kao rizik u tablici rizika koja je sastavni dio upravljanja
rizicima (ali o tome ste mogli više pročitati u dotičnom poglavlju knjige).
Metodologija upravljanja projektima: Planiranje projekta I stranica 19
Doseg projekta: vremenski raspored radnih zadataka (Scheduling)
Prilično dug naslov za nešto što bi se na engleskom jeziku jednostavno reklo – Scheduling. Malo manje
formalne osobe možda bi mogle reći: žongliranje u cirkusu. Upravo tako ponekad izgleda proces
upravljanja vremenom (koristiti ćemo ovaj izraz za gore navedeni podulji naslov) – na stolu vam se
nalazi gomila definiranih radnih zadataka, procjene trajanja i učinka istih te dostupni (i nedostupni)
resursi koje možete uporabiti u svojem projektu. Kako sad pristupiti ostvarenju projektnih zadataka?
Koji zadaci će se izvršiti prvi i kada? Koji zadaci se mogu odvijati paralelno, a koji su obavezni prije no
što se pristupi drugim zadacima? Odgovore na ova i slična pitanja daje – upravljanje vremenom.
Upravljanje vremenom može postati full-time posao upravitelja projekta i ako vam od pomoći nije
jedan od profesionalnih alata za upravljanje projektima – vrlo je velika vjerojatnost da ćete brzo biti
izgubljeni. Uporaba ovakvih alata uvelike pojednostavljuje proces – i početniku se može činiti da je ovo
prilično jednostavan dio planiranja projekta. Osim što vas grafički vodi kroz organizaciju radnih
zadataka te njihov paralelizam, trajanje te učinak, alat vam može pojednostaviti i razumijevanje procesa
upravljanja vremenom (pogledajte samo ljepotu uporabe Gantt Chart prikaza projekta), ali i, ako niste
svjesni što točno radite, dati krive informacije o trajanju pojedinog zadatka odnosno ukupnog projekta.
Cilj ovog poglavlja je dati razumijevanje osnovnih principa kao upravljati vremenom u projektu, ali i
ukazati na pojedine najbolje pristupe istom (recimo, best practices), jer ako se (još) u čemu griješi na
našim prostorima (naravno, moram reći da je ovdje upravljanje dosegom ipak – nedodirljivo broj 1),
onda je to ovaj segment upravljanja projektima. A rezultat krivog upravljanja vremenom vam je i više
nego jasan – projekti kasne, djelatnici su prenapeti, korisnik nezadovoljan.
Pogledajmo za početak fantastično bajkovit scenarij: nakon što smo odredili točno što treba napraviti u
projektu uporabom definiranja projektnih zadataka, sjeli smo za stol, definirali resurse koji su nam
raspolaganju te njihovu učinkovitost, potom kreirali vremenski raspored i – objavili kada ćemo završiti
projekt, kako bi marketing i management ekipa mogla planirati domjenak prilikom završetka projekta.
U stvarnosti, gotovo da i nisam sreo projekt koji je išao ovim tijekom – većinom se barem nekoliko
stvari u planiranju ne poštuje, ali jedna od onih koja sigurno ulazi u top 10 je „management je definirao
kraj projekta“ – odnosno, u projekt ulazite s „idejom“ ili „željom“ nekoga daleko iznad vas kada i kako
će se završiti projekt. Znači li to da je ta osoba stručna ili ima savjetnika koji zahvaljujući iskustvu ili
nekoj vama nepoznatoj metodologiji može predvidjeti kada će se projekt završiti? Naravno da ne –
želja je ovdje uvijek i samo – želja, osobni ili grupni interesi do kada bi netko želio vidjeti projekt za koji
vi odgovarate gotovim. Ono što vama uobičajeno u tom trenutku nedostaje su raspoloživi resursi,
vrijeme, detaljno planiranje i tako dalje, ali to nekoga ne sprječava da „marketinški“ jasno odredi datum
završetka prije no što se i upoznao s vama kao novim upraviteljem projekta. I onda priča počinje
ispočetka – baš kad ste si rekli – nema boga, slijedeći put idemo „by the book“ – nekako vas objasne
metodama kojih se ne bi postidio ni KGB da bi bilo najbolje za sve da prihvatite datum koji je određen
jer, e sad tu dolazi kvaka, ionako možete upravljati dosegom projekta. I onda vi mladi i naivni
pristanete na tu igru, potpišete datum i potom, nekoliko dana kasnije, shvatite da se opis projekta
sastoji od jednog dokumenta na dvije stranice te nekoliko email poruka koje su razmijenili
zainteresirani djelatnici. A kao što i moja baka zna, doseg je vrlo fluidna stvar i kao što smo definirali u
prethodnom poglavlju, zna završiti u opakim izjavama „pa mi smo očekivali da je jasno što treba
napraviti“.
OK, svi to znamo, s nelagodom će primijetiti koncentrirani čitatelj. Većina projekata i zapadne u krizu
upravo zbog nerealnih očekivanja koja se oko njega gomilaju – kako riješiti ovu problematiku i kako ju
izbjeći u budućnosti. Pa, kako ju riješiti ovisi o dotičnom projektu, ali kako ju probati izbjeći ipak
zahtjeva malo predznanja iz planiranja. Pa ako imate kvalitetno planiranje, možda ćete nekome i uspjeti
Metodologija upravljanja projektima: Planiranje projekta I stranica 20
objasniti koliko vam uistinu treba dana za završetak projekta. Još jednom, odokativna i palčana metoda
ovdje definitivno ne dolaze u obzir.
Prvi korak u kreiranju upravljanja vremenom je kreiranje mrežnog dijagrama zadataka koji se trebaju
izvršiti tijekom projekta. Kao i uvijek, u ovom će vam pomoći programska podrška, ali kod manjih
projekata ili podprojekata, moguće je jednostavnom ručnom metodom napraviti ovako nešto. Princip
je jednostavan: projektni zadaci se smještaju u određeni redoslijed – zadatak koji se prvi mora napraviti
smatra se zadatkom 1, zadatak koji slijedi je zadatak 2 i tako dalje. Ovdje vrijedi princip ovisnosti –
zadatak 2 se ne može izvršiti prije no što se završi zadatak 1 (naravno, ovo je vrlo pojednostavljeno
kako bi objasnili princip – u praksi, zadatak može početi i paralelno ili tijekom izvedbe prethodnog
zadatka). Primjer je moguće lako savladati pogledom na slijedeću sliku – projektni primjer.
Strelice koje postoje između pojedinih radnih zadataka ukazuju na poredak i smjer izvršavanja
pojedinih zadataka, odnosno, obrnutim pravcem, o kojim zadacima ovisi trenutni projektni zadatak. U
stvarnosti, jedan zadatak može ovisiti o više projektnih zadataka, kao što i više zadataka može ovisiti o
jednom projektnom zadatku (slijedeća slika).
Kao što je vidljivo iz slike, tijek projektnih zadataka se može razdvojiti, jedno vrijeme odvijati paralelno
a potom ponovo spojiti u zajedničkom završetku – sve ovisi o tijeku projekta. Isto tako, tijek zadataka
se može odvojiti te nastaviti u nebrojeno paralelnih tijekova, od kojih će svaki imati svoj završetak
(slijedeća slika).
Metodologija upravljanja projektima: Planiranje projekta I stranica 21
Paralelni tijek odvijanja zadataka uvijek je najučinkovitiji način rješavanja pitanja brzine projekta.
Teoretski, kada bi imali onoliko resursa koliko bi bilo projektnih zadataka, cijeli projekt bi mogli
napraviti u jednom koraku (naravno, ovo je samo teoretski, ali nije izvodivo i u praksi, ipak neki zadaci
prethode nekim drugima). No, bilo koji i malo složeniji projekt imati će u obilju paralelnih zadataka koji
se spajaju, prethode i obavezni su za neke druge zadatke. Cijela matrica mrežnog dijagrama tada će
biti izuzetno uzbudljiva i prostorno velika, ali još uvijek lako čitljiva – jedan od prednosti mrežnog
dijagrama (Network Diagram) je upravo lakoća praćenja pojedinih tijekova u projektu – što prethodi
čemu i što je potrebno odraditi u trenutnom projektom zadatku.
Kakve sad ovo veze ima s upravljanjem vremenom? Jednostavno, kada završite mrežni dijagram,
potrebno je uzeti u obzir trajanje koje ste predvidjeli za pojedini projektni zadatak, postaviti
informacije na svoja mjesta, zbrojiti vrijeme i – presto – dobili ste ukupnu dužinu trajanja projekta.
Metodologija upravljanja projektima: Planiranje projekta I stranica 22
Doseg projekta: Izračunavanje kritičnog puta (Critical Path)
Poznajem upravitelje projekta koji misle da je za uspješan projekt dovoljno imati vremenski raspored
projektnih zadataka te izračun kritičnog puta. To ne znači da upravitelji nemaju pojma što rade već da
se izračunu kritičnog puta uvijek pridodaje znakovita pažnja – uvijek ga možete vidjeti kao jedan od
prioritetnih zadataka postavke projekta. Za razliku od prije nekoliko (desetaka) godina, danas izračun
kritičnog puta obavljaju za nas programska rješenja i rijetko koji upravitelj projekta upustiti će se u
avanturu zvanu izračun kritičnog puta. Puno je jednostavnije upisati osnovne elemente u program,
pustiti da nas taj isti program dovede u red (čitaj, ispravi pogreške koje smo „željeli“ upisati u projektni
plan) i potom nam jednostavno kroz Pert Chart nacrta kritični put. Jednostavnije ne može i eto –
problem je riješen. Ali kao i uvijek, nije ovdje cilj rješavanje problema nego njegovo razumijevanje – pa
eto, potrošiti ćemo neku stranicu i na izračunavanje kritičnog puta.
Pojednostavljeno, izračun kritičnog puta sastoji se od tri koraka:
1. izračun forward pass vrijednosti
2. izračun backward pass vrijednosti
3. Izračun kritičnog puta
Izračun forward pass vrijednosti
Ovaj dio izračuna kritičnog puta izvodi se uz uporabu dva datuma (ovdje: varijable): najraniji mogući
početak rada (early start date) i najraniji mogući završetak rada (early finish date). Kao što naziv kaže,
najraniji mogući početak rada je datum kada je, s obzirom na ostale okolnosti projekta te na zavisnosti
koje zadatak ima vezano za prethodne zadatke i resurse, moguće započeti rad na zadatku. Isto tako,
najraniji mogući završetak rada na zadatku je datum kada je, s obzirom na ostale okolnosti projekta,
najraniji mogući početak zadatka te predviđeno trajanje zadatka, moguće završiti rad na zadatku.
Forward pass započinje s prvim zadatkom u projektu i završava s zadnjim zadatkom u projektu –
najraniji mogući završetak zadnjeg zadatka ujedno je najraniji mogući završetak cjelokupnog projekta.
Izračun backward pass vrijednosti
Ovaj dio izračuna kritičnog puta izvodi se također uz uporabu dva datuma (ovdje: varijable): najkasniji
mogući početak rada (late start date) i najkasniji mogući završetak rada (late finish date) i to za svaki
pojedini zadatak u projektu. Kao što bi razuman čovjek i očekivao, najkasniji mogući početak rada je
zadnji datum kada zadatak može početi a da bi slijedeći zadatak počeo u planirano vrijeme. Slično
tome, najkasniji mogući završetak rada je datum kada najkasnije zadatak mora završiti da bi slijedeći
zadatak počeo u planirano vrijeme. Za razliku od forward pass pristupa, backward pass kreće s zadnjim
zadatkom u projektu i vraća se prema početku projekta – kao što bi i bilo za očekivati, najkasniji
mogući početak rada prvog zadatka u projektu je najkasniji datum kada projekt mora započeti da bi se
završio u predviđeno vrijeme.
Izračun kritičnog puta
Za početak, izračunava se float (slack), odnosno vrijeme za koje možemo odgoditi početak zadatka a
bez ugrožavanja najkasnijeg mogućeg završetka projekta. Uobičajeno se slack izračunava kao razlika
između najranijeg mogućeg početka i najkasnijeg mogućeg početka ili najranijeg mogućeg kraja i
najkasnijeg mogućeg kraja. Tako na primjer, pojedini zadaci mogu imati slack vrijednost veću od nule,
što znači da taj specifičan zadataka možemo odgoditi (odnosno, njegov početak) za upravo toliko
dana a da ne ugrozimo najkasniji mogući završetak projekta. Pojedini zadaci imat će slack vrijednost 0
– upravo svi oni zadaci koji imaju tu vrijednost 0 čine kritičan put u projektu. To znači da se ti zadaci ne
Metodologija upravljanja projektima: Planiranje projekta I stranica 23
mogu odgoditi niti za jedan dan – ako se odgode, time se pomiče i datum najkasnijeg mogućeg
završetka projekta.
Iako je poznavanje tehnologije izračuna kritičnog puta zanimljiva i fascinantna stvar, za vas će se uvijek
pobrinuti programska podrška – osim što ovo radi automatski, svi programi će vam na interesantan i
pregledan način „nacrtati“ kritični put kako bi u svakom trenutku mogli biti svjesni da li je trenutni
zadatak na kojem radite na kritičnom putu ili je tek neki koji možete odgoditi jer se, eto, glavni
programer ženi slijedeći tjedan.
i Standish Group ii Harold Kerzner, Ph.D., Project Management: A Systems Approach to Planning, Scheduling and Controling (New
York: John Wiley and Sons, 1988) iii J. LeRoy Ward, Project Management Terms 2nd Edition (ESI International, 2000) iv Kevin R. Callahan, Lynne M. Brooks, Essentials of Strateic Project Management (New York: John Wiley and Sons,
2004). Zanimljivo je da ovdje autori definiraju Primarni procesi (Doseg, Skup zadataka, Zadatak, Vremenski
raspored, Resursi, Cijena) te Sekundarni procesi (Nabava, Komunikacija, Rizik, Kvaliteta). Primarni procesi su
procesi koji se jednostavno moraju izvršiti tijekom projekta i uobičajeno se izvode onim rasporedom kojim su i
navedeni, jer svaki pojedini proces ovisi o procesu koji se morao izvršiti prije njega. Sekundardni procesi su procesi
koji podržavaju primarne procese, ali ne ovise jedan o drugom, te ne postoje nužno u svim projektima. v Ovisno o metodologiji koja se primjenjuje, završetak projekta može se potvrditi kroz verifikaciju krajnjih isporuka
ili kroz jednostavno potpisivanje funkcionalnosti projekta. Pojedine metodologije idu korak dalje, te uz jasne i
definirane krajnje isporuke projekta definiraju i dodatne elemente (nontangible) koje krajnji korisnik smatra
bitnima kako bi potvrdio da je projekt, s njegovog stanovišta, uspio. Na primjer, moguće je definirati uvjete
zadovoljstva korisnika (Conditions of Satisfaction) koji sadrže razne elemente poput „projekt je uspio ako
zahvaljujući njemu dobijem godišnji bonus“. Čudno, ali istinito. vi Dobar dio upravitelja projekata pa i onih koji se time ne bave direktno miješaju WBS i Gantt Chart. WBS ipak nije
ništa drugo nego pregled zadataka koje je potrebno izvršiti da bi se projekt doveo do svog cilja – i što se forme
tiče, može biti najjednostavnija lista u Notepadu. Ili, ako ste maštovitiji, možete kreirati tu listu koristeći
hijerarhijsku organizaciju pregleda a koju ćete kreirati uporabom određenog alata za kreiranje hijerarhijskog
pregleda. Ponekad je to Visio, a ponekad – Gantt Chart. vii Zapravo točan original jest: „A deliverable-oriented grouping of project elements that organizes and defines the
total work scope of the project. Each descending level represents an increasingly detailed definition of the project
work.“, što je skraćeno i prilagođeno potrebama knjige. viii Kevin R. Callahan, Lynne M. Brooks, Essentials of Strateic Project Management (New York: John Wiley and Sons,
2004). ix Ovisno o tome koje alate koristite za stvaranja WBS strukture, ovi elementi radnih zadataka mogu je lakše ili
jednostavnije ostvariti. Tako na primjer, ako koristite Notepad da bi jednostavno prikupili listu aktivnosti, onda
vam nema druge nego ručno prikupljati i računati vrijeme potrebo za projekt ili zauzeće resursa. Profesionalni alati
će vam automatski izračunati ove elemente, pod uvjetom da koristite njihove mogućnosti i na vrijeme unesete
resurse projekta, njihove cijene, te ih potom dodijelite aktivnostima (zadacima) koje je potrebno ostvariti – i, eto
vam ovih elemenata uz dva, tri dodatna klika mišem. x Pogledati napomenu 8. xi Ono što uporabom ovakvog načina planiranja nije jednostavno vidjeti je paralelizam određenih aktivnosti u
projektu, za to je ipak potreban drugačiji prikaz aktivnosti projekta. xii Design Paradigms xiii Tom Gilb xiv Na primjer, PMBoK definira aktivnost kao „najniži nivo WBS strukture, ali koji se dalje može razdijeliti u zadatke“ xv Naravno, idealno bi bilo da se može ovako detaljno voditi struktura rada, ali to nije uvijek slučaj. Većina
djelatnika ne radi sukcesivno na zadacima – iako vam kažu da će im za nešto trebati „barem“ 8 sati, to znači da će
Metodologija upravljanja projektima: Planiranje projekta I stranica 24
u pravilu možda i završiti za 8 ali budite uvjereni da će se vraćani na doradu ili ponovnu izradu istog zadatka. Isto
tako, u psihi je ljudi da uglavnom rade 1 zadatak dnevno, ne više od toga.