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

UvodProces 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 procesaRazvoj Tehnikih Zahteva (RD) OP koja pokriva definisanje razvoja zahteva za proizvodom i komponentama proizvoda.

1

Zahtevi za proizvodom i komponentama proizvoda i servisom promena ovih zahteva su kljuni za planiranje i replaniranje. 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 praksiSG 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.

2

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

3

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

4

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

5

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 projekatTehniko 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 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 resursimaMetode 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

6

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

7

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

8

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

9

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

10

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

11

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

12

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 moe pristupati podacima i kako treba podatke skladititi da bi se zatitila poverljivost i privatnost podataka, a obezbedio pristup onim korisnicima koji ih trebaju.

13

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

14

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

15

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

16

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

17

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

18

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

19

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

20

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

21

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

Samo za kontinualnu reprezentacijuGenerike 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 reprezentacijaGG 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

22

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

23

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

24

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 reprenzetacijuGG 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-5GG 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: 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

25