Planiranje projekta

Namena
Oblast procesa Planiranje Projekta (PP) ima za cilj uspostavljanje i
odravanje planova koji definiu projektne aktivnosti.

Uvod
Proces Planiranje Projekta obuhvata sledee osnovne razvojne faze:
1. Razvoj plana projekta
2. Interakcija sa relevantnim uesnicima
3. Obezbeivanje angaovanja za razvoj plana
4. Odravanje plana projekta
Planiranje polazi od zahteva koji definiu ciljeve projekta (izlazne
rezultate projekta ili proizvode).
Prilikom planiranja zadaju se zahtevi koji moraju da se ispune, zadaci koje
treba izvriti, kao i zahtevi za neophodnim resursima i koordinacijom. Ova
dokumenta slue za dobijanje resursa i pravdanje trokova.
Plan je potvrda da su svi zahtevi za resursima kredibilni. Ukoliko se od
sponzora zatrai odobrenje za resurse, oni e hteti da se uvere da li vredi
investirati. Plan projekta treba da ubedi menadment da bi odobrio sve
zahteve.
Planiranje Projekta ne slui samo za velike projekte. Rezultati istraivanja
(PSP) su pokazali da i pojedinci koji obavljaju zadatke koji traju svega par sati
treba da odvoje vreme za planiranje jer time poveavaju kvalitet i
produktivnost rada.
PP obuhvata procenu obima i granica (veliine) projekta, atributa
oekivanih izlaznih rezultata projekta, projektnih zadataka, odreivanje
potrebnih resursa, obezbeivanje angaovanja uesnika, dinamiki plan
aktivnosti, i analizu rizika projekta.
Da bi se uspostavio stabilan Glavni Plan Projekta (GPP) neophodno je ove
faze sprovoditi u vie iteracija. GPP obezbeuje osnovu za izvravanje i
kontrolu projektnih aktivnosti relevantnih uesnika na projektu. Kako se PP
razvija, tako i GPP treba revidirati da bi se obuhvatile sve eventualne promene
u zahtevima i angaovanju, netane procene, neophodne korektivne akcije i
promene procesa nastalih u toku razvoja i implementacije PP. Faze ivotnog
ciklusa razvoja PP opisuju planiranje i replaniranje.
Termin planiranje projekta (PP) korien je u svim generikim i
specifinim praksama ove oblasti procesa i odnosi se na glavni (generalni)
plan upravljanja i kontrole planiranja projekta GPP.

Odnosne oblasti procesa

Razvoj Tehnikih Zahteva (RD) OP koja pokriva definisanje razvoja
zahteva za proizvodom i komponentama proizvoda.
Zahtevi za proizvodom i komponentama proizvoda i servisom promena
ovih zahteva su kljuni za planiranje i replaniranje.

1
 to ranije identifikovati trenutak i vrstu promena koje mogu da se dese.
Upravljanje Zahtevima (REQM) upravljanje zahtevima potrebnim za
planiranje i replaniranje projekta.
I organizacija i projekat treba da definiu generatore za replaniranje.
Upravljanje Rizikom (RSKM) identifikacija i upravljanje rizicima.
Tehnika Reenja (TS) transformisanje zahteva u reenja proizvoda i
komponenata proizvoda.
Monitoring i Kontrola Procesa (PMC) oblast procesa koja prati aktivnosti
plana.

Pregled specifinih ciljeva i praksi

SG 1 Priprema i Procena
SP
1.1 Procena obima projekta
SP
1.2 Procena oekivanih izlaznih rezultata i atributa projektnih zadataka
SP
1.3 Definisanje ivotnog ciklusa projekta
SP
1.4 Procena trokova projekta i potrebnog rada
SG 2 Izrada Plana Projekta
SP 2.1 Plan trokova i dinamiki plan raspodele zadataka
SP 2.2 Identifikovanje rizika projekta
SP 2.3 Plan za upravljanje podacima
SP 2.4 Planiranje resursa za projekat
SP 2.5 Plan za neophodna znanja i vetine
SP 2.6 Plan angaovanja relevantnih uesnika
SP 2.7 Uspostavljanje (izrada) glavnog plana projekta
SG 3 Obezbeivanje angaovanja za realizaciju plana
SP 3.1 Revizija planova od uticaja na projekat
SP 3.2 Usklaivanje nivoa praktinog rada i raspoloivih resursa
SP 3.3 Sprovoenje angaevanja za realizaciju plana

5.1. Specifini ciljevi i prakse

SG 1. Priprema i procena
Procene parametara planiranja projekta su uspostavljene i odravane.
Ova faza se fokusira na obezbeivanje procena parametara PP; stvarne
vrednosti monitorie OP Monitoring i Kontrola Procesa (PMC) kroz SP 1.1.
Parametri PP ukljuuju sve informacije neophodne za projekat da bi se
izvrilo planiranje, obezbedile organizacija i popuna uesnika projekta
ukljuujui i projektni tim, upravljanje projektom, koordinacija rada,
izvetavanje i materijalno-finansijsko obezbeenje.
Procena parametara planiranja treba da bude jasno ustanovljena i
prihvaena sa uverenjem da e svaki drugi plan zasnovan na ovim procenama
imati dovoljne kapacitete da podri projektne ciljeve.
Parametri planiranja projekta su kljuni za upravljanje projektom.
Parametri planiranja su ulazne veliine procene i primarno ukljuuju veliinu,
potreban rad, i trokove.
Faktori koji se razmatraju prilikom procena ovih parametara ukljuuju
sledee:

2
 1. Projektni zahtevi, ukljuujui zahteve za proizvodima, zahteve koje
namee sama organizacija, zahteve korisnika i ostali zahtevi koji
utiu na projekat.
2. Obim (veliina i ogranienja) projekta
3. Projektni zadataci i oekivani izlazni rezultati (proizvodi rada)
4. Tehniko reenje projektnih zahteva
5. Izbor modela za razvoj ivotnog ciklusa projekta (npr., vodopadni,
inkrementalno iterativni, ili spiralni)
6. Veliina, kompleksnost i drugi atributi oekivanih izlaznih rezultata
projekta
7. Vremenski (dinamiki) plan izvravanja aktivnosti projekta
8. Modeli analize arhivskih podataka za konverziju atributa izlaznih
rezultata i projektnih zadataka u potrebne trokove rada (na bazi
ovek/sat rada,...)
9. Kao osnova za procenu mogu da se ukljue arhivski podaci, nalazi
iskusnih procenitelja, ili iskustva i prakse srodnih organizacija.
10. Metodologija (modeli, podaci, algoritmi) korieni za odreivanje
potrebnih materijalnih sredstava za realizaciju projekta, potronog
materijala, vetina, radnih sati i trokova rada
11. BAR (brza analiza rizika) metod analize rizika za analizu rizika
projekta
Primena BAR analize rizika zahteva malo vremena, a daje dobre rezultate za
najkritinije faktore rizika.
Dokumentacije procene opravdanosti angaovanja resursa, potrebnog rada,
i trokova sadre podatke za argumentaciju i validaciju procesa procene, i
neophodna je za sponzore da bi odobrili i podrali razvoj projekta.

SP 1.1 Procena obima projekta

Uspostavljanje strukturne dekompozicije rada (WBS) visokog nivoa
apstrakcije, za procenu obima projekta.
WBS (Work Breakdown Structure) ustanovljava se na samom poetku
razvoja projekta. WBS visokog nivoa apstrakcije obino je dovoljna za
formiranje inicijalne procene obima projekta, jer navodi sve projektne zadatke
koji moraju da se izvre radi dostizanja eljenog rezultata. WBS deli projekat
na mejusobno povezane skupove upravljivih komponenata prezentovane
logikim jedinicama, koje se u CMMI modelu opisuju atributom "radni paketi".
Radni paketi se definiu sa dovoljno detalja koji se koriste za raspodelu
projektnih zadataka, uloga i odgovornosti, potrebnog rada i vremenskog plana
projekta. Razvoj WBS-a celokupan projekat deli na meusobno zavisne
skupove upravljivih objekata. Procena potrebnih resursa, rada, trokova,
vremena, uloga i odgovornosti izvrena je za identifikovane radne pakete, a
zatim za projektne zadatke i projekat u celini. WBS je rezultatski orjentisana
struktura dekompozicije rada, koja obezbeuje pregled i organizacijski
mehanizam za utvrivanje intenziteta rada, raspodele zadataka i
odgovornosti, i koristi se kao osnovni okvir za plan, organizovanje i kontrolu
zavretka rada na projektu.
Preporuka najboljih praksi je da se procena obima zapone
dekompozicijom projekta na manje radne zadatke (WBS), procenom potrebnih
resursa za svaki zadatak, i njihovim logikim pakovanjem u radne pakete. Ovo
e dati mnogo precizniju procenu.
U veini sluajeva neophodna je interaktivna iteracija izmeu planiranja,
definisanja zahteva, i dizajniranja. U svakoj iteraciji projekat moe mnogo da

3
napreduje, a ove inkremente treba ugraditi u plan, zahteve, i dizajn za sledeu
iteraciju.
Tipini oekivani izlazni
rezultati rada
1. Opisi projektnih zadataka
2. Opis radnih paketa (trokovi, npr., ovek/h)
3. WBS
WBS je osnova mnogih upravljaki-orjentisanih zadataka (ne samo za
procenu).
Strukturna dekompozicija rezultata rada PBS (Product Brakedown
Structure) je najee deo WBS i definie komponente proizvoda koje
odreeni projekat treba da razvije.
Subprak
se
1. Razvoj WBS zasnovanog na arhitekturi projekta.
WBS obezbeuje emu organizacije projektnog rada vezanog za proizvod i
proizvodne komponente koje taj rad podrava. WBS bi trebalo da omogui
identifikaciju sledeih stavki:
Identifikovane rizike i zadatke za njihovo ublaavanje
Zadatke za snadbevanje i logistikih aktivnosti
Zadatke za vetinama i akvizicijom znanja
Zadatke za razvoj potrebnih planova podrke, poput planova menadera
konfiguracija, osiguranja kvaliteta, i verifikacione planove.
Zadatke za integraciju i menadment nerazvojnih stavki (gotove stvari
koje organizacija ne razvija, npr., MS tehnologije)
2. Identifikovanje radnih paketa dovoljno detaljno za specifikaciju
procene projektnih zadataka, odgovornosti i raspodele zadataka.
Nivo detalja obino zavisi od nivoa kompletiranosti zahteva. Proirenjem
zahteva obino se proiruju i radni paketi.
WBS se koristi kao pomono sredstvo za definisanje arhitekture.
Namena WBS na nivou arhitekture (najvii nivo apstrakcije) je usklaivanje
uloga, odgovornosti i rada na projektnim zadacima. Vea koliina detalja
WBS-a pomae za razvoj realnog dinamikog plana, to minimizira potrebu
za dodatnim intervencijama upravljakih struktura organizacije.
Efikasna raspodela resursa postie se (srazmerno procenama) dodatnim
angaovanjem upravljakih struktura.
3. Identifikovanje proizvoda rada ili komponenata proizvoda koji bi bili
nabavljani spolja.
Odnosi se na OP Koordinacija sa Snadbevaima gde ima vie informacija o
nabavljanju proizvoda.
4. Identifikovanje proizvoda rada koji se kasnije mogu vie puta
upotrebljavati.
OP Technical Solution (TS) preko SP 2.4 definie ponovnu upotrebu
proizvoda.

SP 1.2 Procena oekivanih izlaznih rezultata i atributa projektnih zadataka

Uspostavljanje i odravanje procenjenih atributa izlaznih rezultata
(rezultata rada) i radnih zadataka.

4
 Veliina i obim projekta su primarni ulazni parametri mnogih modela
korienih za procenu osnovnih resursa projekta, radnog napora, trokova,
vremena, i raspodele zadataka. Modeli procene veliine i obima projekta,
pored funkcionalnih i bezbednosnih zahteva takoe mogu da se baziraju na
ulaznim parametrima kao to su veliina, umreenost (Internet, intranet,
WAN,...), kompleksnost i struktura IKT sistema.
Potrebno je nauiti kvantifikovati resurse za odreeni zadatak
povezivanjem mernih veliina sa svakim tipom proizvoda rada i te podatke
arhivirati. Prikupljeni podaci govore koliko merne veliine utiu na angaovanje
resursa.
Primeri tipova izlaznih rezultata procenjenih prema njihovoj veliini:
1. Isporuiv ili neisporuiv proizvod/usluga rada
2. Papirne i elektronske dokumentacije
3. Operativni i dodatni hardver, softver i firmware za osnovne
funkcionalnosti
Primeri mera veliine:
1. Broj funkcionalnosti
2. Mere veliine potrebnog rada (Function points)
3. Linije izvornog kda
4. Broj klasa i objekata
5. Broj zahteva
6. Broj i kompleksnost interfejsa
7. Broj strana
8. broj ulaza i izlaza
9. Broj stavki tehnikog rizika
10. Koliina podataka
11. Broj logikih gejtova itegralnih kola
12. Broj delova (npr., tampanih ploa, komponenata, i mehanikih
delova)
13. Fizikog ogranienja (npr., teina i zapremina)
Procena mora biti konzistentna sa projektnim zahtevom za odreivanje
napora, trokova, i raspodela zadataka. Trebalo bi naznaiti relativni nivo
smetnji ili kompleksnosti za svaku veliinu atributa.
Vie informacija o procenjivanju obima projekta pokriveno je u knjizi
Stutzke, Richard D., Estimating Software Intensie Systems: Projects;
Products, and Processess, SEI Series in Software Engineering, 2005.
Tipini oekivani izlazni
rezultati rada
1. Tehniko reenje
2. Veliina i kompleksnost projektnih zadataka i proizvoda rada
3. Modeli za procenu
4. Procena atributa projektnih zadataka
Subprak
se
1. Odreivanje tehnikog reenja za projekat
Tehniko reenje definie najvii strateki nivo razvoja proizvoda. Ono
ukljuuje odluke o izboru arhitekture, kao to je distribuirana, klijent/server,
state-of-the-art ili ustanovljenih tehnologija, poput robotike, kompozitnih
materijala, vetake inteligencije; i brojne funkcionalnosti koje se oekuju od

5
 zavrnog proizvoda, npr., pouzdanost, bezbednost, i korisnika
prihvatljivost.
2. Korienje odgovarajuih metoda za odreivanje atributa rezultata
rada i zadataka koji e se koristiti za procenu zahteva za resursima
Metode za odreivanje veliine i kompleksnosti treba da se baziraju na
validnim modelima analize arhivskih podataka.
Metode za odreivanje atributa proiruje razumevanje veze izmeu
karakteristika proizvoda i poveanja broja atributa.
Zrele organizacije uvaju i odravaju arhivske podatke da bi ih iskoristili u
projektima za uspostavljanje racionalnih procena.
Videti specifine prakse OP Merenje i Analiza (MA) SP 1.4, i OP
Upravljanje Integrisanim Procesima (IPM) SP 1.2).
Primer ove metode ukljuuje sledee:
Broj logikih gejtova dizajna itegralnih kola
Linije kda ili mere funkcionalnosti softvera
Broj/kompleksnost ili zahtevi za sistemski inenjering
Kvadratura boravinih prostorija standardom specificirana
Procena atributa proizvoda rada i zadataka.
3. Procena atributa proizvoda rada i zadataka

SP 1.3 Definisanje ivotnog ciklusa projekta

Definisanje faza ivotnog ciklusa projekta za odreivanje obima
rada za planiranje.
Odreivanje faza ivotnog ciklusa projekta obezbeuje planirane periode
evaluacije i donoenja odluka. Obino se definiu za logistiku podrku taaka
odluke bitnih angaovanja resursa i tehnikih reenja. Ove take obezbeuju
planirane dogaaje moguih korekcija i odreivanja obima i trokova projekta
u toku njegovog razvoja..
ivotni ciklus projekta treba da bude definisan u zavisnosti od obima
zahteva, procene projektnih resursa, i prirode projekta. Veliki projekat moe da
sadri veliki broj faza, poput koncepta istraivanja, proizvodnja, fabrike,
poslovanje i upravljanje. U okviru ovih faza mogue su i subfaze. U fazu
razvoja mogu biti ukljuene subfaze poput analiza zahteva, dizajn,
konstrukcija, integracija, i verifikacija. Odreivanje projektnih faza obino
ukljuuje odabir i usklaivanje jednog ili vie modela razvoja u cilju
meuzavisnosti i odgovarajuih koraka aktivnosti u fazama. Na primer, u
vodopadnom modelu razvoja projekta, na kraju faze analiza, evaluirani su
zahtevi za procenu konzistentnosti, kompletiranosti, i izvodljivosti zahteva, i
doneta odluka da li projekat ima spremne resurse (iz tehnike perspektive i
perspektive rizika) za naredhu fazu dizajn. Zavisno od strategije razvoja,
mogue su prelazne faze za kreiranje prototipova, inkrementi kapaciteta, ili
model spiralnog ciklusa.
Razumevanje ivotnog ciklusa projekta je od kljune vanosti za
odreivanje obima planiranog radnog napora, izbor trenutka poetnog
planiranja, i izbor trenutka i kriterijuma (kritine kontrolne take critical
milestones) za replaniranje.
Tipini oekivani izlazni
rezultati rada
1. Faze ivotnog ciklusa projekta.

6
 SP 1.4 Procena trokova projekta i potrebnog rada
Procena radnog napora na projektu, trokova proizvoda rada i
zadataka na osnovu argumentovane procene trokova.
Procena rada i trokova izvrena je na bazi rezultata analize obima i
veliine projekta, aktivnosti i drugih parametara planiranja, kao i na bazi
iskustvenih (arhivskih) podataka.
Primer parametarskog modela za procenu trokova softverskog projekta
je COCOMO II http://csse.usc.edu/research/COCOMOII/.
Poverenje u ove procene trokova zasnovano je na principu odabranog
modela i prirode podataka. Mogue su situacije da se dostupni arhivski podaci
ne mogu primeniti, poput jedinstvenih radnih napora ili gde se tadanji zadaci
ne uklapaju u dostupne modele. Neki radni napor je jedinstven (do nekog
stepena) ukoliko slian proizvod ili komponenta proizvoda ranije nikad nije
razvijana.
Potrebno je uskladiti tehnike i metode za procenjivanje tako da budu
odgovaraju karakteristikama odreenog projekta.
Jedinstveni radni napori su riziniji, zahtevaju vie istraivanja za razvoj
prihvatljive osnove za procenu, i zahtevaju mnogo dodatnih intervencija
upravljakih struktura organizacije. Kad se koriste ovi modeli, specifinosti
projekta se moraju dokumentovati da bi se osigurala osnovna razumevanja
bilo koje pretpostavke iz faze inicijalnog planiranja.
Jedinstveni napori zahtevaju iterativni ili spiralni model razvoja jer nude
mogunost uestalog povratka na problem i analizu rizika da bi se planski ulo
u sledeu iteraciju.
Tipini oekivani izlazni
rezultati rada
1. Procena opravdanosti
2. Procena potrebnog radnog napora za razvoj projekta
3. Procenjeni trokova projekta
Subprak
se
1. Kolekcija modela ili podataka sa prethodnih projekata koji e se
koristiti za transformaciju atributa proizvoda rada i zadataka u
procenu trokova ovek/sat rada.
Ako se koristi samo jedan parametarski model, treba ga uskladiti sa
karakteristikama projekta.
Mnogi parametarski modeli su razvijani da pomognu pri proceni trokova i
raspodela radnih zadataka. Upotreba tih modela kao jedinog izvora
procenjivanja nije preporuljiva, zato to su bazirani na arhivskim
projektnim podacima koji mogu a ne moraju odgovarati aktuelnom projektu.
Korienje vie modela i/ili metoda osigurava vii nivo poverenja u procenu.
Arhivski podaci ukljuuju trokove, radni napor, i raspodelu radnih zadataka
iz prethodno realizovanih projekata, plus odgovarajue nivelisanje podataka
za proraun veliina i kompleksnosti. Nivelisanje je esto pouzdano ako ve
postoje iskustva na slinim projektima.
2. Obuhvaena infrastrukturna podrka potrebna za procenu radnog
napora i trokova.
Infrastrukturna podrka ukljuuje potrebne resurse za razvoj i sredstva za
budui izgled projekta.

7
 Prilikom procene radnih napora i trokova uzima se u obzir potreba za
infrastrukturnim resursima razvojnog okruenja, testnog okruenja,
konstrukcionog okruenja, ciljnog okruenja, ili njihovih kombinacija.
Primeri infrastrukturnih resursa ukljuuju sledee:
Kritini raunarski resursi: memorija, kapacitet diska i mrena
infrastruktura, perifierija, komunikacioni kanali i nihovi kapaciteti
Inenjersko okruenje i alati (alati za prototip, asembliranje, computer
aided design, i simulaciju)
Osnovna sredstva, mainerija, i oprema (npr., radni prostor za sastanke i
smetaj opreme, prostorija za testiranje, radni raunar za
dokumentovanje aktivnosti i progresa implementacije plana projekta
3. Procena potrebnog rada i trokova korienjem modela i/ili arhivskih
podataka.
Procena trokova projekta i potrebnog rada izvrena je na bazi sledeih
ulaznih parametara:
Ekspertskog prosuivanja konsultanta i relevantnih uesnika projekta ili
od strane eksperta ili ekspertske grupe, npr., Delphi Method
Procene faktore rizika projekta, ukljuujui i izvravanje potpuno novih
aktivnosti
Kritine kompetencije i uloge potrebne za izvravanje zadataka
Zahtevi vlasnika za proizvodom i komponentama proizvoda
Tehnika reenja
WBS
Veliina procenjenih rezultata rada i predvianja potrebnih izmena
Trokova nabavke infrastrukturnih komponenti
Odabrani model i procesi ivotnog ciklusa projeka
ivotni ciklus procene trokova
Kapaciteti obezbeenih alata u inenjerskom okruenju
Nivoi vetina menadera i lanova tima za implementaciju plana projekta
Potrebnia znanja, vetine i obuke za planiranje, akviziciju, implementaciju
i odravanje projekta
Potrebna osnovna sredstva (kancelarije, prostorije za sastanke i radna
mesta)
Neophodna inenjerska sredstva
Kapaciteti proizvodnih procesa
Putni trokovi
Bezbednosni zahtevi za projektne zadatke, proizvode rada, softver,
hardver, personal, i radno okruenje
Zahtevi za prekovremeni rad

SG 2. Izrada plana projekta

Plan projekta je uspostavljen i odravan i slui kao osnova za upravljanje
projektom.
Plan projekta je formalan, ratifikovan dokument koji se koristi za
upravljanje i kontrolu izvravanja projekta. Zasnovan je na projektnim
zahtevima i ustanovljenim procenama.
U nekim sluajevima, svaka faza razvoja projekta, pored celokupnog
(glavnog) plana, moe imati sopstveni veoma detaljan plan. Takoe, detaljan
plan se tipino kreira za svaku iteraciju kod iterativno inkrementalnih i
spiralnih metoda razvoja i fokusira se na odreene probleme zahteva, dizajna,
ili analizu rizika.

8
 Plan projekta obuhvata sve faze ivotnog ciklusa projekta. Planiranje
projekta treba da garantuje da e svi planovi koji imaju uticaja na projekat biti
konzistentni sa glavnim planom projekta.

SP 2.1 Plan trokova i dinamiki plan raspodele zadataka

Uspostavljanje i odravanje projektnih trokova i raspodele radnih
zadataka.
Budet projekta (finansijski plan projekta) i dinamiki plan zasnivaju se
na procenama i obezbeuju da su alokacija sredstava, kompleksnost zadataka
i meuzavisnosti zadataka obuhvaeni na odgovarajui nain.
Ako je budet ve odreen izvan projektnog tima i ne pokriva procenjene
neophodne resurse, onda je neophodno izvriti replaniranje u okviru
definisanog budeta. Takoe, ako je dinamika definisana od strane drugih i nije
konzistentna sa planom, replaniranjem treba osigurati da e projekat dati
rezultate (proizvode) na vreme, ili eventualno sa nekoliko osnovnih
karakteristika).
Potvreno je da je za upravljanje rizikom projekta efikasan dinamiki plan
na bazi razvoja dogaaja i minimuma resursa. Identifikovanje rezultata
aktivnosti pre inicijacije dogaaja obezbeuje fleksibilnost prilikom
odreivanja vremena izvravanja dogaaja, razumevanje oekivanja, i bolju
viziju stanja projekta i projektnih zadataka..
Tipini oekivani izlazni
rezultati rada
1. Vremenski plan projekta (dinamiki plan)
2. Meuzavisnosti planiranih aktivnosti (prioriteti izvravanja)
3. Budet projekta
Subprak
se
1. Identifikovanje glavnih kontrolnih taaka.
Kod dogaajem-voenog dinamikog plana, zadaci se zapoinju tek nakon
to se zadovolje odreeni kriterijumi.
Kontrolne take (milestones) faza projekta obezbeuju kontrolu
kompletiranja odreenih aktivnosti i izvravanje odreenih rezultata do
kontrolne take. Kontrolna taka se moe zasnivati na dogaaju (kriterijumi
koji u ovoj taki treba da se ispune da bi otpoeo sledei zadatak prioriteti
izvravanja) ili datumu. Ako se zasniva na datumu esto je teko izvriti
izmene ukoliko se zadatak ne ispuni.
Definisanje kontrolnih taaka u dinamikom planu zasnovanom na dogaaju
i monitoring njihovog zavretka (PMC SP 1.1 sbp 1) obezbeuje uvid u
napredak projekta.
2. Identifikovalje procene vremenskog rasporeda rada.
Nakon inicijalne raspodele rada, uobiajeno je da se definiu procene
trajanja odreenih aktivnosti. Ove pretpostavke se uestalo sprovode na
aktivnostima ije su procene bar malo dokumentovane. Identifikovanje ovih
pretpostavki obezbeuju uvid u nivo neizvesnosti celokupnog dinamikog
plana.
3. Identifikovanje ogranienja.
Faktore koji ograniavaju fleksibilnost upravljakih (menaderskih)
mogunosti treba to pre identifikovati. Procenjivanje atributa proizvoda

9
 rada i radnih zadataka rasvetljava ova ogranienja. Ti atributi mogu da
ukljuuju trajanje zadataka, resurse, ulaze i izlaze.
4. Identifikovanje meuzavisnosti radnih zadataka.
Projektni zadaci tipino mogu biti izvreni po nekim unapred definisanim
sekvencama koje bi minimizirale vreme trajanja projekta. Ovo ukljuuje
identifikaciju zavretka prethodnog (exit) i poetka narednog (entry)
zadatka, to pomae u rasporedu redosleda izvravanja zadataka.
Primeri alata koji pomau u odreivanju optimalnog redosleda izvravanja
aktivnosti na zadacima:
CPM (Critical Path Method) mreni model projektnih aktivnosti za
redukovanje trajanja razvoja projekta
(http://www.netmba.com/operations/project/cpm/)
PERT (Program Evaluation and Review Technique) alat za procenu
trajanja projektnih aktivnosti
(http://www.netmba.com/operations/project/pert/)
Resource limited scheduling dinamiki raspored projektnih aktivnosti
takav da predodreeni nivo raspoloivosti resursa (konstanta ili
promenjiva) ne bude prekoraen u bilo kom trenutku razvoja projekta
(tednja resursa).
Gantogram Ganttov dijagram (projektne aktivnosti/vreme/resursi)
5. Definisanje budeta i rasporeda.
Uspostavljanje i odravanje budeta projekta i vremenskog plana ukljuuje
sledee:
Definisanje angaovanih ili oekivanih raspoloivih resursa i objekata
organizacije
Definisanje vremenskih faza aktivnosti za izvravnje projektnih zadataka
Definisanje probijanja sporednih rasporeda zadataka
Definisanje meuzavisnosti aktivnosti i prioriteta izvravanja
Definisanje rasporeda aktivnosti i kontrolnih taaka za merenje progresa
izvravanja aktivnosti
Identifikovanje kontrolnih taaka za isporuku proizvoda/usluga krajnjem
korisniku
Definisanje odgovarajueg trajanja aktivnosti
Definisanje odgovarajueg vremenskog razdvajanja kontrolnih taaka
Definisanje intervencija menadmenta za potvrdu o nivou ispunjavanja
plana i budeta
Korienje odgovarajuih arhivskih podataka za verifikaciju plana
rasporeda
Definisanje zahteva za inkrementalno finansiranje
Dokumentovanje pretpostavki, procena i argumenata za donoenje odluka
u projektu
6. Uspostavljanje kriterijuma za korektivne akcije
Kriterijumi za korektivne akcije uspostavljaju se za odreivanje znaajnih
devijacija od plana projekta. Potrebno je imati osnov za odluivanje kada
treba preduzeti korektivne akcije. Korektivne akcije mogu zahtevati
replaniranje, ukljuujui reviziju originalnog plana, potpisivanje novih
sporazuma ili aktivnosti za ublaavanje rizika u okviru tekueg plana.
Da bi se obezbedila odgovarajua i konzistentna znanja o moguim
problemima na projektu, potrebno je to ranije ustanoviti kriterijume
korektivnih akcija.

SP 2.2 Identifikovanje rizika projekta

10
 Identifikacija i analiza rizika koji mogu uticati na uspenu
realizaciju projekta.
Upravljanje Rizikom Projekta (RSKM) OP koja pokriva aktivnosti vezane
za upravljanjem rizikom. Upravljanje rizikom je kljuna OP za uspeh realizacije
projekta.
Kontrola i Monitoring Projekta (PMC) ova oblast procesa preko
specifine prakse SP 1.3 (Monitorisanje Projektnih Rizika) definie aktivnosti
praenja rizika.
Faktore rizika projekta treba identifikovati ili otkriti i analizirati u fazi
pripreme projekta, da bi se podrala i obezbedila realizacija plana projekta.
Ova specifina praksa bi trebala da se proiri na sve planove koji utiu na
projekat, da bi se obezbedio odgovarajui interfejs izmeu relevantnih
uesnika za identifikovanje faktora rizika.
Identifikovanje faktora rizika u fazi planiranja projekta tipino obuhvata
sledee:
Identifikovanje faktora rizika
Analiza faktora rizika i odreivanje verovatnoe pojave
Ustanovljeni prioriteti znaaja rizika po intenzitetu i verovatnoi
pojave
Tipini oekivani izlazni
rezultati rada
1. Identifikovani faktori rizika
2. Uticaji i verovatnoe pojave faktora rizika
3. Prioriteti ublaavanja rizika
Subprak
se
1. Identifikovanje rizika.
Identifikovanje faktora rizika ukljuuje identifikovanje potencijalnih pretnji,
hazarda, ranjivosti, itd. koji mogu negativno uticati na potreban rad i
planove projekta. Faktori rizika moraju biti opisani na razumljiv nain pre
same analize. Identifikovanje faktora rizika i alati za analizu (procenu) rizika
mogu se koristiti za identifikovanje moguih problema u projektu.
Primeri alata za identfikovanje faktora i analizu rizika su sledei:
Taksonomija rizika
Metode procene rizika
Kontrolne liste
Strukturirani intervjui (Brza analiza rizika BAR)
Brainstorming
Modeli izvravanja
Modeli trokova
Mrena analiza
Analiza faktora kvaliteta
Alati za identifikaciju i analizu rizika obezbeuju kompletniju i bru
identifikuju i mnogo konzistentniju analizu, i imaju mogunost primene
ranijih iskustava, iz prethodnih projekata na novi projekat.
2. Dokumentovanje rizika.

11
 Sve faktore rizika proceniti po intenzitetu i verovatnoi pojave prema skali
gradacije: nizak, srednji, visok i detaljno dokumentovati u planu projekta.
3. Razmatranje i dobijanje saglasnosti relevantnih uesnika za
kompletnost i korektnost dokumentovanih rizika.
4. Redovno revidiranje rizika.
Relevantni uesnici projekta treba da pregledaju i ispitaju kompletnost i
korektnost dokumentovanih faktora rizika i predloe eventualnu reviziju
faktora rizika, ako je potrebno.
Identifikovani faktori rizika mogu zahtevati reviziju u odreenim
sluajevima, na primer:
Kada je identifikovan novi faktor rizika
Kada rizik postaje problem
Kada rizik vie nije relevantan
Kada se dogodi znaajna promena projektnog okruenja

SP 2.3 Plan za upravljanje podacima

Plan za upravljanje podacima razvoja projekta.
Ova faza treba da pomogne u izboru relevantnih podataka koji treba da
se prikupljaju, rasporede, predaju, i arhiviraju. Definie prava pristupa
podacima i na koji nain podaci treba da se uvaju, u smislu njihove zatite od
onih koji nemaju pravo pristupa.
Podaci projekta su razliite forme dokumentacije koje se zahtevaju za
podrku programa realizacije projekta u svim oblastima: administrativnoj,
inenjerskoj, upravljanju konfiguracijom, finansijskoj, logistickoj, sistemu
kvaliteta, bezbednosti, proizvodnoj i snabdevakoj. Podaci mogu imati bilo
koju formu: izvetaji, prirunici, zabeleke, dijagrami, crtei, specifikacije,
datoteke ili prepiska. Podaci mogu postojati na svakom mediju: papiru,
fotografiji, elektronskoj formi ili multimedijalnoj formi. Podaci mogu biti
isporuivi (stavke identifikovane programom projekta za isporuku
korisnicima/kupcima, npr., digitalni sertifikati), ili neisporuivi:(neformalni
podaci, studije izvodljivosti, tehnike analize, interni sastanci, interna revizija
projekta/dizajna, dokumentovana iskustva i akcioni planovi). Distribucija
podataka projekta moe imati razliite forme ukljuujui elektronsku
transmisiju.
Da bi se pomoglo rukovaocu podacima, podatke treba to jasnije
interpretirati. Kreiranje standardne forme kolekcije podataka doprinosi boljoj
komunikaciji i eliminie eventualne dvosmislenosti.
Zahteve za podacima projekta treba uspostaviti i za podatke koje treba
kreirati izvravanjem projektnih zadataka i za njihov sadraj i formu, na bazi
uobiajenog ili standardnog skupa zahteva za podacima. Uniformni sadraj i
format zahteva za podacima pomae lake razumevanje sadraja podataka i
konzistentno upravljanje resursa podataka.
Razlozi za sakupljanje svakog dokumenta/podatka moraju biti jasno
navedeni. Ovaj zadatak ukljuuje analizu i verifikaciju isporuivih i
neisporuivih rezultata razvoja projekta i podataka koje dostave kupci/korisnici
projekta. esto se podaci sakupljaju bez jasnog objanjenja kako ih treba
koristiti. Podaci su skupi i treba ih sakupljati samo ako su potrebni. Razlozi za
prikupljanjem podataka podstiu organizaciju da ih obezbedi.
Ova aktivnost pomae da se donese odluka koje podatke na projektu
treba sakupljati, distribuirati, isporuivati i arhivirati; kako i kada to raditi; ko

12
moe pristupati podacima i kako treba podatke skladititi da bi se zatitila
poverljivost i privatnost podataka, a obezbedio pristup onim korisnicima koji ih
trebaju.
Plan za sakupljanje podataka definie podatke potrebne za projekat, ko ih
poseduje, gde se nalaze, i na koji nain su upotrebljeni. Plan za sakupljanje
podataka moe da specifira akcije koje se preduzimaju nad podacima ukoliko
se projekat ugasi.
Tipini oekivani izlazni
rezultati rada
1. Plan za sakupljanje podataka projekta
2. Plan upravljanja podacima
3. Glavna lista upravljanih podataka
4. Sadraj podataka i format opisa
5. Lista podataka o zahtevima za nabavku i snabdevanje projekta
6. Zahtevi za zatitu privatnosti
7. Zahtevi za zatitu poverljivosti, integriteta i raspoloivosti
8. Procedure zatite
9. Mehanizmi za izvlaenje podataka, reprodukciju i distribuciju
10. Spisak podataka projekta koje treba sakupljati
Subprak
se
1. Uspostaviti zahteve i procedure obezbeivanja privatnosti i zatite
podataka.
U veini projekata svaki uesnik ne mora imati potrebu ili ovlaenje za
pristup svim podacima projekta. Treba izraditi procedure za identifikaciju lica
koja treba da pristupaju i kojim podacima i kada mogu pristupati tim
podacima.
Trebalo bi razmotriti privatnost i zatitu podataka, mada za neke projekte to
nije potrebno.
2. Uspostaviti mehanizme za arhiviranje podataka i pristup arhiviranim
podacima.
Podaci kojima treba pristupati u toku realizacije i odravanje projekta treba
da budu u razumljivoj formi, npr., da se nalaze u pristupnoj bazi podataka u
raunaru, ili da se predstavljaju u svojoj originalnoj generisanoj formi.
Merni podaci su podskup projektnih podataka. OP Merenje i Analiza kroz SP
1.3 i 2.3 definie sakupljanje, smetanje, i kontrolu pristupa mernim
podacima.
3. Izraditi listu klasa podataka/dokumenata projekta koje treba: samo
identifikovati, sakupljati i/ili distribuirati za potrebe projekta.

SP 2.4 Planiranje resursa za projekat

Plan za neophodnim resursima za realizaciju projekta.
Ova faza se odnosi na sve resurse, ne samo na lanove tima. Definisanje
projektnih resursa: rada, opreme, potronog materijala i metoda, kao i koliina
potrebnih za izvravanje projektnih aktivnosti, zasniva se na inicijalnim
procenama i obezbeuju dodatne informacije koje se mogu primeniti za
proirivanje WBS sa vie detalja, koji se koristi za upravljanje projektom.
WBS inicijalno kreiran na visokom nivou apstrakcije, kao mehanizam za
procenu, tipino se proiruje sa daljom dekompozicijom objekata WBS u

13
"radne pakete" koji predstavljaju jedinstvene radne jedinice (zadatke
projektnih aktivnosti) koji se odvojeno (relativno nezavisno) mogu pripisivati
izvriocima, izvravati i pratiti. Ova dekompozicija vri se radi distribucije
upravljakih odgovornosti i obezbeenja bolje kontrole upravljanja projektom.
Svakom radnom paketu ili proizvodu rada u WBS dokumentu treba da bude
pripisan jedinstveni identifikator (broj) koji omoguava praenje izvravanja.
WBS se moe zasnivati na zahtevima, aktivnostima, proizvodima rada ili
njihovim kombinacijama. Opis posla na svakom radnom paketu u WBS treba
da prati dalju dekompoziciju strukture.
WBS ustanovljena u SP 1.1 (Procena obima projekta) proiruje se da bi
se: razjasnile uloge, razvojni procesi, objekti, i neophodni alati; odredili radni
zadaci; dobila angaovanja za izvoenje zadataka; i pratila njihova
izvravanja. Za ovu aktivnost su od velike pomoi razni alati.
Tipini oekivani izlazni
rezultati rada
1. WBS radni paketi
2. Renik WBS zadataka
3. Zahtevi za popunu projektnog tima na bazi veliine i obima projekta
4. Lista kriticnih objekata/opreme
5. Definicija i dijagram toka/procesa
6. Lista zahteva za administraciju programa projekta
Subprak
se
1. Definisanje procesa zahteva.
Proces za upravljanje projektom mora biti identifikovan, definisan, i
koordiniran sa svim relevantnim uesnicima da bi se obezbedile delotvorne
operacije u toku izvravanja projekta.
Na 3. nivou zrelosti sama organizacija je tipino glavni generator procesa
zahteva, standardnih procesa, i pomonih sredstava. Videti OP Fokus
Organizacijskih Procesa (OPF) SP 2.3, i OP Definisanje Organizacijskih
Procesa (OPD).
2. Definisanje zahteva za popunu projektnog tima.
Popuna projektnog tima zavisi od nivoa dekompozicije projektnih zahteva u
zadatke, uloge i odgovornosti za ispunjavanje projektnih zahteva, kako je
postavljeno u radnim paketima WBS.
Zahtevi za popunu projektnog tima moraju se definisati na bazi znanja i
vetina koje se trae za svaku od identifikovanih pozicija, kako je definisano
u sledeoj fazi Planiranje neophodnih znanja i vetina.
3. Definisanje zahteva za objekte, opremu i komponente.
Veina projekata su u nekom smislu jedinstveni i zahtevaju neki skup
jedinstvenih objekata (osnovnih sredstava) za postizanje projektnih ciljeva.
Odreivanje i blagovremena akvizicija ovih objekata od kritinog je znaaja
za uspeh projekta.
Neke stavke (neuobiajene sposobnosti, znanja, vetine, i slino) oduzimaju
mnogo vremena za akviziciju, zato je neophodno to ranije identifikovati
ovakve potrebe.
Vremenski period izmeu nabavke i isporuke sredstava treba to ranije
identifikovati radi definisanja naina isporuke. ak i kada zahtevana
sredstva nisu jedinstvena, kreiranje liste svih sredstava, opreme, i delova
(npr., broj raunara za personalni rad na projektu, softverskih aplikacija, i

14
 kancelarijskog prostora) obezbeuje sagledavanje obima potrebnog rada
koji se esto previde.

SP 2.5 Plan za neophodna znanja i vetina

Plan akvizicije znanja i vetina za izvravanje planiranih aktivnosti
projektnih zadataka.
Ova faza upuuje na obuku koja je specifina za projekat. Na 2. nivou
zrelosti organizacija moda nema dovljne kapacitete da obezbedi neophodnu
obuku za odreeni projekat. Svaki projekat upuuje na potrebna znanja i
vetine. Na 3. nivou zrelosti organizacija sama preuzima odgovornosti
obuavanja za opte potrebe projekta (npr., skup standardnih procesa
obuavanja).
Obezbeivanje Tekuih Znanja i Vetina (OT) OP koja bolje pokriva
znanja i vetine koje treba definisati u planu projekta.
Znanja potrebna za projekat ukljuuju obuku interno zaposlenih uesnika
u realizaciji projketa i angaovanje znanja i vetina spoljneg
saradnika/konsultanta.
Popuna projektong tima zavisi od odgovarajuih i raspoloivih znanja i
vetina za izvravanje projektnih zadataka i aktivnosti.
Tipini oekivani izlazni
rezultati rada
1. Lista potrebnih vetina
2. Plan popune internim i spoljnim lanovima tima
3. Baza podataka (znanja, obuavanja)
I projekat i organizacija mogu odravati ove rezultate rada.
Subprak
se
1. Identifikovati potrebna znanja i vetine za izvrenje projektnih
zadataka.
Razmotriti sva znanja i vetine koje zahteva projekat, ne samo sa tehnikog
aspekta
2. Omoguiti pristup bazi podataka (bazi znanja i obuavanja).
3. Odabrati mehanizme za obezbeivanje potrebnih znanja i vetina.
Primeri mehanizama za obezbedjivanje potrebnih znanja i vetina su
sledei:
Interna obuka za projekat u organizaciji
Obuka izvan organizacije
Popuna sa iznajmljivanjem strunih kadrova
Akvizicija spoljnih saradnika sa potrebnim vetinama
Izbor mehanizma za obezbeivanje potrebnih znanja i vetina zavisi od
raspoloivih strunih kadrova organizacije, kapaciteta organizacije za obuku,
poslovnih ciljeva i dinamikog plana projekta. Izabrani mehanizam treba
ugraditi u plan projketa. Ako su vetine potrebne za tekui projekat, a ne
oekuje se njihova potreba za budue projekte, onda je najbolje reenje
iznajmljivanje spoljnog saradnika u formi konsultanta.
Ukoliko su vetine potrebne samo za aktuelni projekat, ne i za neke naredne
projekte, tada je dobar izbor akvizicija vetina spolja. Meutim, ukoliko ima
izgleda da e zahtevane vetine biti i dalje potrebne, onda bi trebalo

15
 razmotriti mogunost treninga postojeih zaposlenih ili zapoljavanje novih
radnika.
4. Integrisati odabrane mehanizme za obezbeivanje potrebnih znanja i
vetina u plan projekta.

SP 2.6 Plan angaovanja relevantnih uesnika

Plan angaovanja identifikovanih relevantnih uesnika.
Angaovanje relevantnih uesnika projekta (Sponzor, vlasnici akcija,
dobavljai,) mora biti dvosmerna komunikacija sa dobrim meusobnim
razumevanjem svakog razmatranog pitanja.
GP 2.7 (Identifikovani i Angaovani Relevantni Uesnici) oblasti procesa:
Monitoring i Kontrola Projekta (PMC) SP 1.5, Integrisano Upravljanje Projektom
(IPM) i Planiranje Projekta (PP), bolje definiu identifikovanje i angaovanje
relevantnih uesnika.
Relevantni uesnci projekta identifikovani su za sve faze ivotnog ciklusa
projekta na bazi uloga i funkcija potrebnih za realizaciju projekta, i opisani sa
aspekta njihovog znaaja i stepena ukljuivanja u specifine projektne
aktivnosti. Uobiajena forma za identifikaciju angaovanja svih uesnika
projekta je dvodimenzionalna matrica uesnik-aktivnost. Relevantnost i znaaj
uesnika u datoj fazi projekta moe se prikazati elijama matrice u
odgovarajuem preseku uesnik-aktivnost sa indikatorom nizak, srednji, visok.
Dvodimenzionalna matrica uesnik-projektna aktivnost obezbeuje
jednoznanu predstavu svakog uesnika, njegovu ulogu i odgovornost za
izvravanje planiranih aktivnosti na koordinatnim osama (red-kolona, apscisa-
ordinata). Povezanost relevantnih uesnika sa aktivnostima u odreenom delu
projektne faze i koliina oekivanih interakcija prikazana je na presecima osa
aktivnosti projektnih faza i uesnika.
Za svaku fazu projekta idnentifikovani uesnici odgovorni su za uspeh
faze projekta i dodeljene su im sledee uloge: relevantni uesnik, konsultant,
supervizor, lider projektnog tima, revizor stanja procesa projekta,
implementator 1, implementator 2, lan projektnog tima. Ova lista uesenika
verovatno e se promeniti tokom razvoja pojekta kroz faze ivotnog ciklusa.
Za svaku projektnu fazu, identifikovanje relevantnih uesnika je bitno za uspeh
te faze i uloga u njoj (npr., implementator, supervizor, ili konsultant). Ove
informacije potrebno je predstaviti matricom radi unapreivanja komunikacije,
dobijanja potrebnog angaovanja (SP 3.3), i monitorisanja stanja projekta (OP
Monitoring i Kontrola Projekta SP 1.5).
Za svaku glavnu aktivnost projektnog zadatka angaovan je uesnik koji
ima lini i profesionalni interes i adekvatnu strunost, koja je potrebna za
izvravanje te aktivnosti.
Svi identifikovani uesnici u projektu nisu i relevantni uesnici. Samo se
ogranien broj uesnika projekta smatra relevantnim i oni su odreeni da
interaktivo rade na projektu i progresu rada.
Pre postizanja saglasnosti za angaovanje uesnika projekta, svaki
uesnik projekta treba da analizira ta mu je potrebno da ispuni preuzetu
ulogu i odgovornosti u projektu. Svaki uesnik koji prihvati angaovanje na
projektu treba da neprekidno preispituje i evaluira svoju sposobnost za
izvravanje preuzetih obaveza, da rezultate odmah prenosi drugim uesnicima
na koje njegova aktivnost moe uticati ako se ne izvri na vreme i sa
zahtevanim kvalitetom. Na taj nain obezbeuju se uslovi za ublaavanje

16
posledica uticaja rizika od objektivne nemogunosti izvravanja neke
aktivnosti.
Pre prihvatanja svakog angaovanja na projektu, uesnik treba od lidera
projekta zahtevati odgovor na pitanje, "koliko loe moe biti po projekat
njegovo neizvravanje preuzetih obaveza".
Primeri faktora koje treba ukljuiti u plan angaovanja relevantnih
uesnika:
1. Lista rrelevantnih uesnika
2. Argumenti za ukljuivanje relevantnih uesnika
3. Uloge i odgovornosti relevantnih uesnika za sve faze ivotnog
ciklusa projekta
4. Meusobni odnosi (relacije) uesnika
5. Relativni znaaj uesnika za uspeh projekta po fazama ivotnog
ciklusa
6. Resursi (obuka, materijal, vreme i finansijska sredstva) potrebni za
obezbeenje angaovanja uesnika projekta
7. Vremenski plan angaovanja relevantnog uesnika
Sprovoenje ove faze oslanja se na deljenje ili razmenu informacija sa
prethodnom fazom Planiranje Neophodnih Znanja i Vetina.
Tipini oekivani izlazni
rezultati rada
1. Plan angaovanja relevantnih uesnika

SP 2.7 Uspostavljanje (izrada) glavnog plana projekta

Uspostavljen i odravan sadraj glavnog plana projekta.
Dokumentovan celovit Glavni (generalni) plan GPP koji obuhvata sve
relevantne planske elemente, potreban je za lake postizanje uzajamnog
razumevanja i komunikacija u projektu, angaovanja i performansi pojedinaca
i grupa i organizacije koja mora izvriti ili podrati realizaciju planova projketa.
Plan generisan za projekat treba da definie sve aspekte povezane na logian
nain u jedinstven dokument: razmatranje ivotnog ciklusa projekta; tehniki i
upravljaki zadaci; budet i vremenski plan; kontrolne take; upravljanje
podacima; identfikacija rizika; zahtevi za materijalne resurse, znanja i vetine,
i angaovanje uesnika i njihove interakcije. Opisi infrastrukture obuhvataju
odgovornosti i obaveze koje se odnose na lanove tima, menadment, i ostalo
osoblje organizacije.
Kako se bolje sagledavaju i razumevaju zahtevi, tako se i na projektnim
planovima vre izmene planiranog prekovremenog rada, dakle, treba planirati
kako i kada e se plan odravati i usklaivati. Dokument Plana treba da
odraava projektna stanja kao promenu zahteva i projektnog okruenja.
Dokumenta za planiranje razvoja softvera esto se odnosi na sledee:
Razvojni plan
Projektni plan
Glavni plan
Dokumentovan plan potrebnih komunikacionih resursa, oekivanja i
angaovanja sadri radni plan za relevantne uesnike, ukljuujui i projektni
tim (SP 3.3), dokumentuje angaovanja menadmenta i drugih izvora
snadbevanja, i osnova je za upravljanje projektom.
Dokumenta za planiranje razvoja za hardverski inenjering:

17
 Dokument za planiranje razvoja hardvera obino se naziva Plan Razvoja
Hardvera. Razvojne aktivnosti od pripreme do proizvodnje mogu biti ukljueni
u plan razvoja hardvera ili u poseban plan Produkcioni Plan.
Primeri planova korienih u amerikom ministarstvu odbrane:
1. Integrisani Glavni Plan plan baziran na dogaajima koji
dokumentuje znaajnija dostignua prema kriterijumu
izvren/neizvren, kako za poslovne tako i za tehnike elemente
projekta, to povezuje svako izvrenje za kljune planirane dogaaje.
2. Integrisani Glavni Dinamiki Plan integrisani i povezani vieslojni
dinamiki planovi zadataka predvieni za kompletiranje potrebnog
rada dokumentovanog u Integrisanom Glavnom Planu.
3. Sistemsko-Inenjerski Upravljaki Plan plan detaljnog opisa
integrisanog tehnikog uloenog rada kroz ceo razvoj projekta.
4. Sistemsko-Inenjerski Glavni Dinamiki Plan dinamiki plan baziran
na dogaajima koji sadri zbir svih tehnikih dostignua po merljivim
kriterijumima zahtevajui uspeno kompletiranje identifikovanih
dogaaja.
5. Sistemsko-Inenjerski Detaljni Dinamiki Plan detaljan, vremenski
zavisan, rezultatski-orjentisan (baziran na izvrenju dodeljenih
zadataka) dinamiki plan koji povezuje specifirane datume i
kontrolne take sa Sistemsko-Inenjerskim Glavnim Dinamikim
Planom.
Tipini oekivani izlazni
rezultati rada
1. Glavni plan projekta (GPP)
Glavni plan projekta treba da reflektuje stanje projekta u skladu sa
promenama zahteva i okruenja. Dokumentovani plan treba da obuhvati
potrebne resurse, oekivane izlazne rezultate i potrebni rad; da sadri plan
angaovanja relevantnih uesnika i projektnog tima; da dokumentuje
angaovanje menadmenta i drugih provajdera resursa i da ini bazu za
upravljanje projketom.

SG 3. Obezbeivanje angaovanja za realizaciju plana

Potvrda da je glavni plan projekta GPP uspostavljen i odravan.
Da bi bio efektivan, plan projekta zahteva angaovanje onih koji su
odgovorni za implementaciju i podrku plana projekta. Angaovanja su
obraena u sledeim OP: zahtevi u REQM, dokumentovana i usklaena u PP,
monitorisana u PMC, i najvie u IPM.

SP 3.1 Revizija planova od uticaja na projekat

Revizija svih planova koji utiu na projekat za razumevanje
angaovanja na projektu.
Planovi razvijeni u drugim OP tipino sadre informacije sline onima
sakupljenim u Glavnom Planu Projekta. Ovi planovi mogu sadravati dodatne
detalje i treba da budu kompatibilni sa GPP i da ga podravaju, ukazujui na to
ko ima kakva ovlacenja, odgovornosti i kontrolu. Svi planovi koji utiu na
projekat treba da budu revidirani da bi se obezbedilo opte razumevanje
obima, ciljeva, uloga i meusobnih odnosa koji se zahtevaju za uspenu
realizaciju projekta. Mnogi od ovih planova su u svakoj OP opisani generikom
praksom GP 2.2 (Planiraj Proces).

18
 Planovi od uticaja na projekat variraju od projekta do projekta. Uzimajui
u obzir relevantne uesnike i zadatke koje treba izvriti da bi se dolo do
planova koji utiu na projekat.
Tipini oekivani izlazni
rezultati rada
1. Lista revidiranih planova od uticaja na projekat.

SP 3.2 Usklaivanje nivoa praktinog rada i raspoloivih resursa

Usklaen plan projekta odraava dostupne i procenjene resurse.
Da bi se uspostavio izvodljiv projekat treba obezbediti angaovanje
relevantnih uesnika i uskladiti sve razlike izmeu procena zahteva za
planiranje parametara projekta i raspoloivih resursa. Ovo usklaivanje tipino
se vri revizijom svih planova projekta, smanjivanjem ili izmenom zahteva za
tehnike performanse, zahtevanjem vie resursa, poveavanjem
produktivnosti, iznajmljivanjem strunih saradnika, prilagoavanjem
(kombinovanjem) vetina uesnika i lanova projektnog tima ili revizijom svih
planova koji utiu na projekat ili dinamiki plan realizacije projekta.
Tipini oekivani izlazni
rezultati rada
1. Revidirani metodi i odgovarajui procenjeni parametri (korienje
boljih alata za procenu)
Dobro napisan plan ukljuuje procenu potrebnih resursa za uspean
zavretak projekta. Ako procene prevazilaze dostupne resurse, tada situacija
mora da se uskladi da bi relevantni uesnici mogli potvrditi izvodljivost
plana.
2. Zahtev za dodatni budet projekta
3. Revidiran dinamicki plan projekta
Nekad ima, a nekad nema smisla odnosne planove drati u jednom
dokumentu. Meutim, svi planovi moraju biti konzistentni i konzistentno
aurirani.
4. Revidirana lista projektnih zahteva
5. Obnovljeni sporazumi za angaovanje uesnika projekta
Poto je dostupnost resursa podlona promenama, takva usklaivanja je
potrebno vriti vie puta za vreme ivotnog ciklusa projekta.

SP 3.3 Sprovoenje angaovanja za realizaciju plana

Obezbeivanje angaovanja relevantnih uesnika odgovornih za
sprovoenje i podrku izvravanja plana.
Interni i spoljni uesnici projekta moraju na odgovarajui nain da se
angauju za izvravanje i podrku izvravanja plana projekta. Pojedinci i tim
moraju biti uvereni da se planirani rad moe izvriti u okviru planiranih
trokova, vremena i ogranienja performansi. Privremena angaovanja su u
veini sluajeva adekvatna jer ve u startu daju procenu odgovarajueg nivoa
punog angaovanja.
Tipini oekivani izlazni
rezultati rada
1. Dokumentovani zahtevi za angaovanje

19
 Kod organizacija na nivou zrelosti 1, upravljake strukture obino imaju
drugaiji pogled na projekat od osoblja. Ova nekonzistentnost ne daje
potrebna angaovanja.
2. Dokumentovano angaovanje (matrica uesnik-projektna aktivnost)
Dokumentovana angaovanja jasno govore o odgovornostima svih uesnika
na projektu.
Subprak
se
Kada se zahtevaju angaovanja treba koristiti WBS za potvrdu da su svi
zadaci dobro razmotreni. Koristiti plan (ili matricu) uesnika koji su ukljueni u
projekat da bi se obezbedila potvrda da su razmatrani relevantni uesnici.
1. Identifikovati potrebnu podrku i razgovore uesnika sa
specijalistima.
WBS moe da se koristi kao kontrolna lista za potvrdu da su angaovani
uesnici upoznati sa svojim zadacima. Kod svakog angaovanja treba
koristiti projektne zadatke iz WBS dokumenta da bi se obezbedilo
angaovanje koje je zaista potrebno.
Plan interakcije sa relevantnim uesnicima identifikuje sve strane od kojih
treba traiti angaovanje.
2. Dokument angaovanja cele organizacije, za potpuna i za privremena
angaovanja, potvruje relevantni potpisnik.
Dokumentovanje angaovanja uesnika je obavezno i obezbeuje
prihvatanje odgovornosti angaovanog uesnika. Svaki dokument o
angaovanju uesnika treba da bude obostrano potpisan. Ovaj dokument je
potreban za praenje izvravanja preuzetih obaveza uesnika, i uzajamno
razumevanje i odravanje stabilnosti aktivnosti. Privremeno angaovanje
treba da bude opisano sa faktorom rizika od ovakvog angaovanja.
Nedokumentovano angaovanje treba smatrati kao da angaovanje ne
postoji.
3. Kad god je mogue, angaovanje internih uesnka u projektu treba
analizirati i revidirati sa najviim menadmentom organizacije.
Senior menader mora biti informisan o spoljnjim angaovanjima (naroito
ako se radi o muterijama, korisnicima, i snadbevaima), kako se
organizacija ne bi izlagala neptrebnom riziku.
4. Revidirati sa najviim menadmentom organizacije angaovane
spoljnje uesnike.
Menadment treba da ima neophodne uvide i autoritet da minimizira rizike
koji se odnose na spoljnje uesnike.
5. Identifikovati angaovanja na interfejsima meu elementima projekta
i ostalim projektima u organizacionim jedinicama, da bi mogli biti
monitorisani.
Dobro definisan interfejs ini osnovu za angaovanja.
OP Integrisano Upravljanje Projektom (IPM) kroz SG 2 opisuje upravljanje
angaovanjima, zavisnostima, i problemima koordinacije izmeu relevantnih
uesnika. OP Integracija Proizvoda (PI) SG 2 opisuje identifikaciju i
upravljanje interfejsima.

5.2. Generiki ciljevi i prakse

20
Samo za kontinualnu reprezentaciju
Generike prakse identifikuju indikatore izvravanja specifinih praksi i
odreuju stepen njihove implementacije.

GG 1. Specifine prakse su izvrene

Proces planiranja projekta podrava i omoguava izvravanje specifinih
ciljeva OP putem transformacije identifikovanih ulaza proizvoda rada u
proizvedene rezultate rada
Izvravanje ovih SP ne mora biti rigorozno planirano i praeno.
Izvravanje SP zavisi od individualnih znanja, vetina i napora. Proizvodi rada
OP ispituju se na izvravanje. Pojedinci u organizaciji prepoznaju da neka
akcija treba biti izvrena i postoji opta saglasnost da je neka akcija izvrena
kada i gde se to zahteva. Postoji proizvod rada procesa koji se moe
identifikovati.

GP 1.1. Izvri specifine prakse

Izvravanje specifinih praksi procesa planiranja projekta za razvoj
proizvoda rada i obezbeivanje servisa za dostizanje specifinih
ciljeva OP.

Kontinualna i fazna reprezentacija

GG 2. Institucionalizuj upravljiv proces

Proces je institucionalizovan kao i upravljiv proces (planiran i praen).

GP 2.1. Uspostavi organizacionu politiku

Uspostavljena i odravana organizaciona politika za planiranje i
izvoenje procesa planiranja projekta.
Elaboracija:
Ova politika uspostavlja predvianja organizacije za procenjivanje
parametara planiranja, kreiranje internih ili eksternih angaovanja, i
razvoj plana za upravljanje projektom.

GP 2.2. Planiraj proces

Uspostavljen i odravan plan za izvravanje procesa planiranja
projekta.
Elaboracija:
Odnosi se na tabelu Table 6.2 na strani 95 u Generic Goals and Generic
Practices o odnosu GP 2.2 i OP Planiranje Projekta (PP). U tabeli je
navedeno da proces Planiranje Projekta moe u potpunosti da
implementira GP 2.2 na svaku OP iz projektne kategorije (osim na samu
sebe, odnosno, na PP). GP 2.2 primenjena na PP moe da se okarakterie
kao planiraj plan i pokrije aktivnosti planiranja u procesu planiranja
projekta.

GP 2.3. Obezbedi resurse

Obezbeeni su adekvatni resursi za izvravanje procesa planiranja
projekta, razvoj proizvoda rada, i obezbeenje servisa procesa.
Elaboracija:
U planiranju projekta mogu biti zahtevane specijalne ekspertize, oprema,
i objekti. Specijalne ekspertize u planiranju projekta mogu da ukljue
sledee:

21
 Iskusne procenjivae
Kreatore dinamikog plana
Tehnike eksperte za odgovarajuu oblast (na primer, domen i
proizvodna tehnologija)
Primeri drugih obezbeenih resursa ukljuuju sledee alate:
Programe za tabelarni proraun
Modele za procenjivanje
Programske pakete za planiranje projekta i dinamiki raspored

GP 2.4. Pripii odgovornosti

Pripisane su odgovornosti i autoritetet za izvravaje procesa,
razvoj proizvoda, i obezbeenje servisa procesa planiranja
projekta.

GP 2.5. Obezbedi obuku

Pojedinci su odgovarajue obueni za izvravanje ili za podrku
procesa planiranja projekta.
Elaboracija:
Primeri predmeta obuke ukljuu sledee:
Procenjivanje
Finansijsko planiranje
Pregovaranje
Identivikovanje i analiza rizika
Upravljanje podacima
Planiranje
Vremensko planiranje

GP 2.6. Upravljaj konfiguracijama

Proizvodi rada OP podvrgnuti su kontroli verzije, ili odgovarajucem
procesu upravljanja konfiguracijom.
Elaboracija:
Primeri proizvoda rada pod kontrolom:
Strukturna dekompozicija rada
Plan projekta
Plan upravljanja podacima
Plan ukljuivanja relevantnih uesnika

GP 2.7. Identifikuj i ukljui relevantne uesnike

Relevantni uesnici su identifikovani i ukljueni u skladu sa
planom.
Elaboracija:
Odnosi se na Table 6.2 na strani 95 u Generic Goals and Generic Practices
o odnosu GP 2.2 i OP Plan ukljuivanja relevantnih uesnika(PSI) u
oblasti procesa Planiranje Projekta.
Primeri aktivnosti za ukljuivanje relevantnih uesnika Examples
ukljuuju sledee:
Uspostavljanje procene
Revidiranje i razreavanje pitanja potpunosti i korektnosti projektnih
rizika
Revidiranje planova za upravljanje podacima

22
 Uspostavljanje projektnih planova
Revidiranje projektnih planova i razreavanje pitanja rada i resursa

GP 2.8. Kontrolii i prati proces sa merenjem

Proces planiranja projekta je monitorisan i kontrolisan u skladu sa
planom izvravanja procesa i preduzimanjem korektivnih akcija.
Elaboracija:
Primeri mera i proizvoda rada korienih u praenju i kontroli su:
Broj revizija plana
Cena kotanja, vremenski raspored, i varijacije napora po reviziji plana
Dinamiki raspored za program razvoja i odravanja planova

GP 2.9. Objektivno evaluiraj striktnost sprovoenja OP

Striktnost procesa planiranja projekta je objektivno evaluirana u
saglasnosti sa sadrajem, standardima, procedurama, i
neispunjenim ciljevima procesa.
Elaboracija:
Primeri revidiranih aktivnosti:
Uspostavljanje procena
Razvoj plana projekta
Dobijanje angaovanja za plan projekta
Primeri revidiranih proizvoda rada:
WBS
Plan projekta
Plan upravljanja podacima
Plan ukljuivanja relevantnih uesnika

GP 2.10. Revidiraj status sa najviim menadmentom

Revidirani su status, aktivnosti, i rezultati procesa planiranja
projekta i razreena su sva pitanja sa najviim menadmentom.

Samo za faznu reprenzetaciju

GG 3 i njegove prakse ne primenjuju se za rangiranje 2. nivoa zrelosti, ali
se primenjuju za rangiranje u kontinualnoj reprezentaciji za 3. ili vii nivo
zrelosti.

Samo za kontinualnu reprezentaciju nivo zrelosti kapaciteta 3-5

GG 3. Institucionalizuj dobro definisan proces

Proces je institucionalizovan kao definisan proces.

GP 3.1. Uspostavi definisan proces

Uspostavljen je i odravan sadraj procesa planiranja projekta.

GP 3.2. Izvri akviziviju informacija poboljanja

Prikupi rezultate rada, mere, rezultate merenja, i informacije o
napretku koje potiu od planiranja i izvravanja procesa planiranja
projekta, za podrku budue upotrebe i poboljanja organizacijskih
procesa i sredstava procesa.
Elaboracija:

23
 Primeri rezultata rada, mera, mernih rezultata, i informacija poboljanja:
Struktura biblioteke projektnih podataka
Procene atributa projekta
Uticaji i mogunosti pojavljivanja rizika

GG 4. Institucionalizuj kvantitativno upravljan proces

Proces je institucionalizovan kao kvantitativno upravljan proces.

GP 4.1. Uspostavi ciljeve za kvantitativno upravljanje procesa

Uspostavi i odravaj ciljeve za kvantitativno upravljanje procesa
planiranja projekta, koji se odnosi na kvalitet i performanse
procesa, bazirano na potrebama korisnika i poslovnim ciljevima.

GP 4.2. Stabilizuj izvravanje podprocesa

Jedan ili vie podprocesa je stabilno izvravan i moe se odrediti
kapaciteta procesa planiranja projekta u odnosu na ustanovljeni
kvalitet i ciljeve izvravanja procesa.

GG 5. Institucionalizuj optimizovan proces

Proces je institucionalizovan kao optimizovan proces.

GP 5.1. Kontinualno poboljavaj proces

Obezbeeno je kontinualno poboljavanje procesa u skladu sa
relevantnim poslovnim ciljevima organizacije.

GP 5.2. Eliminii uzroke defekata

Identifikovani su i otklonjeni uzroci defekata i ostalih problema u
procesu planiranja projekta. 74B 1949B1847

24