Planiranje projekta (DOSEG) - mirakul.hr fileupravljanju projektima, što će, naravno, biti slučaj i sa ovom. Zanimljivo je da u većini projekata planiranje zapravo počinje i prije

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


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


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


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.


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


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.


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


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


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


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.


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


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

http://www.computer.org/software/homepage/2001/05Fte/Fte.htm#ref4




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.




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.


• 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


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


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


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


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.


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


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


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.

Documents

Planiranje projekta (DOSEG) - mirakul.hr fileupravljanju projektima, što će, naravno, biti slučaj i sa ovom. Zanimljivo je da u većini projekata planiranje zapravo počinje i prije