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.

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.

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 Kerzner spominje 3 osnovna elementa planiranja procesa:

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 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 grupe (a) 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.

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.

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

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 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šene. Na primjer, dio pregleda krajnjih isporuka postavke programskog proizvoda Microsoft Office može biti:

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 osnova upravljanja projektima.

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.

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