Atsisiųsti knygą pm 5-asis leidimas rusų kalba. PMBOK, penktasis leidimas, santrauka. Profesinės etikos ir elgesio kodeksas

________________________________________________________________________________________________

1. ĮVADAS

2. ORGANIZACIJOS IR PROJEKTO GYVIMO CIKLO ĮTAKA

3. PROJEKTŲ VALDYMO PROCESAI

4. PROJEKTŲ INTEGRACIJOS VALDYMAS

5. PROJEKTO TURINIO VALDYMAS

6. PROJEKTŲ LAIKO VALDYMAS

7. PROJEKTO IŠLAIDŲ VALDYMAS

8. PROJEKTO KOKYBĖS VALDYMAS

9. PROJEKTO ŽMOGIŠKŲJŲ IŠTEKLIŲ VALDYMAS

10. PROJEKTŲ KOMUNIKACIJOS VALDYMAS

11. PROJEKTO RIZIKOS VALDYMAS

12. PROJEKTŲ PIRKIMŲ VALDYMAS

13. PROJEKTO SUINTERESUOTŲJŲ ŠALIŲ VALDYMAS

1. ĮVADAS

Projektas yra laikina įmonė, kuria siekiama sukurti unikalų produktą, paslaugą ar rezultatą.

Projektas gali sukurti:

· produktas, kuri yra kito produkto sudedamoji dalis, produkto patobulinimas arba galutinis produktas;

· paslauga arba galimybė teikti paslaugą (pavyzdžiui, verslo funkcija, palaikanti gamybą ar platinimą);

· tobulinimas esama produktų ar paslaugų linija (pavyzdžiui, Six Sigma projektas, vykdomas siekiant sumažinti defektus);

· rezultatas, pavyzdžiui, galutinis rezultatas ar dokumentas (pavyzdžiui, tyrimo projektas sukuria naujų žinių, kurios gali būti naudojamos siekiant nustatyti, ar naujas procesas yra tendencingas ar naudingas visuomenei).

Projektų valdymas yra žinių, įgūdžių, įrankių ir metodų taikymas projekto darbui, siekiant patenkinti projekto reikalavimus. Projektų valdymas atliekamas tinkamai taikant ir integruojant logiškai sugrupuotus 47 projektų valdymo procesus, suskirstytus į 5 procesų grupes.

Šios 5 procesų grupės yra tokios:

· inicijavimas,

· planavimas,

· vykdymas,

· stebėjimas ir kontrolė,

· uždarymas.

Projekto apribojimai:

· kokybė,

· tvarkaraštis,

· biudžetas,

· ištekliai,

Dėl pakeitimo galimybės projekto valdymo plano kūrimas yra kartotinis ir nuosekliai tobulinamas įvairiais projekto gyvavimo ciklo etapais. Progresyvus tobulinimas leidžia projekto valdymo komandai detaliau apibrėžti ir valdyti darbus projektui progresuojant.

Programa- eilė susijusių projektų, paprogramių ir programos veiklų, kurios valdomos koordinuotai, siekiant gauti naudos, kurios nebūtų pasiekiama valdant individualiai. Programose gali būti su jomis susijusių darbų elementų, tačiau jie nepatenka į atskirų programos projektų taikymo sritį. Projektas gali būti programos dalis arba nebūti, tačiau programoje visada yra projektų.

Programos valdymas- žinių, įgūdžių, priemonių ir metodų taikymas programai, siekiant patenkinti programos reikalavimus ir gauti naudą bei kontrolę, kurios nebūtų pasiekiamos valdant projektus individualiai.

Programos projektai yra susieti per bendrą rezultatą arba bendrą galimybę. Jei santykiai tarp projektų yra tik bendras klientas, pardavėjas, technologija ar ištekliai, pastangos turėtų būti valdomos kaip projektų portfelis, o ne programa.

Programos valdymas sutelkia dėmesį į projektų tarpusavio priklausomybes ir padeda nustatyti geriausią jų valdymo metodą.

Programos pavyzdys yra nauja palydovinio ryšio sistema su projektais, skirtais palydovų ir palydovinių antžeminių stočių projektavimui, kiekvienos iš jų statybai, sistemos integravimui ir palydovo paleidimui.

Portfelis yra projektų, programų, subportfelių ir veiklos elementų rinkinys, valdomas kaip grupė strateginiams tikslams pasiekti. Programos yra sugrupuotos į aplanką ir susideda iš paprogramių, projektų ir kitų koordinuotai valdomų veiklų, padedančių portfeliui palaikyti. Atskiri projektai, kurie yra programoje arba už jos ribų, taip pat laikomi portfelio dalimi. Nors portfelyje esantys projektai ar programos nebūtinai yra tarpusavyje priklausomi arba tiesiogiai susiję, jie yra susieti su organizacijos strateginiu planu per organizacijos portfelį.

Portfelio valdymas- centralizuotas vieno ar kelių portfelių valdymas strateginiams tikslams pasiekti. Portfelio valdymas orientuotas į projektų ir programų analizės teikimą, siekiant nustatyti išteklių paskirstymo prioritetus ir suderinti bei suderinti portfelio valdymą su organizacijos strategijomis.

Projektų valdymo biuras (PMO)- organizacinė struktūra, kuri standartizuoja projektų valdymo procesus ir palengvina keitimąsi ištekliais, metodikomis, priemonėmis ir technikomis. PMO pareigos gali svyruoti nuo projektų valdymo pagalbos iki tiesioginio vieno ar kelių projektų valdymo.

Organizacijose yra keletas PMO struktūrų tipų, kurių kiekvienas skiriasi kontrolės ir įtakos projektams organizacijoje laipsniu, būtent:

· Palaikantis. Parama PMO atlieka patariamąjį vaidmenį, teikdama šablonus, geriausią praktiką, mokymus, prieigą prie informacijos ir kitų projektų pamokas. Šio tipo PMO tarnauja kaip projektų saugykla. PMO kontrolės laipsnis yra žemas.

· Kontroliuojant. PMO teikia paramą ir užtikrina, kad būtų laikomasi reikalavimų įvairiomis priemonėmis. Atitiktis gali apimti projektų valdymo sistemų ar metodikų pritaikymą, konkrečių šablonų, formų ir įrankių naudojimą arba valdymo reikalavimų įvykdymą. PMO kontrolės laipsnis yra vidutinis.

· Pirmaujantis. PMO vadovai kontroliuoja projektus tiesiogiai valdydami šiuos projektus. PMO kontrolės laipsnis yra aukštas.

Pagrindinė PMO funkcija yra remti projektų vadovus įvairiais būdais, įskaitant, bet neapsiribojant:

· visų PMO administruojamų projektų bendrų išteklių valdymas;

· metodologijos, geriausios praktikos ir projektų valdymo standartų nustatymas ir tobulinimas;

· koučingas, mentorystė, mokymas ir supervizija;

· projektų valdymo standartų, politikos, procedūrų ir šablonų laikymosi stebėsena atliekant projektų auditus;

· politikos, procedūrų, projektų šablonų ir kitos bendrosios dokumentacijos (organizacinio proceso turto) kūrimas ir valdymas;

· komunikacijos tarp projektų koordinavimas.

Projektų vadovai ir PMO turi skirtingus tikslus, taigi ir reikalavimus. Visi jų veiksmai yra suderinti su strateginiais organizacijos interesais. Skirtumas tarp projekto vadovo ir PMO vaidmens gali būti toks:

· Projekto vadovas orientuojasi į konkrečius projekto tikslus, o PMO valdo didelius programos turinio pokyčius ir gali juos vertinti kaip potencialias galimybes geriau pasiekti verslo tikslus.

· Projekto vadovas kontroliuoja projektui skiriamus išteklius, kad būtų tiksliau pasiekti projekto tikslai, o PMO optimizuoja bendrų organizacijos resursų panaudojimą visuose projektuose.

· Projekto vadovas valdo atskirų projektų suvaržymus (apimtį, tvarkaraštį, sąnaudas ir kokybę ir kt.), o PMO – metodikas, standartus, bendras rizikas/galimybes, metrikas ir projektų tarpusavio priklausomybes įmonės lygiu.

Operatyvinė veikla yra nuolatinė veikla, kuri duoda pasikartojančius rezultatus, o ištekliai skiriami iš esmės panašioms užduotims atlikti pagal standartus, įterptus į produkto gyvavimo ciklą. Skirtingai nuo operatyvinės veiklos, kuri yra nuolatinio pobūdžio, projektai yra laikina veikla.

Operacijų valdymas yra verslo operacijų priežiūra, vadovavimas ir kontrolė. Operacijos naudojamos kasdieninei veiklai palaikyti ir yra būtinos organizacijos strateginiams ir taktiniams tikslams pasiekti. Pavyzdžiai: gamybos operacijos, proceso operacijos, apskaitos operacijos, programinės įrangos palaikymas ir priežiūra.

Verslo vertė- kiekvienai organizacijai būdinga koncepcija. Verslo vertė apibrėžiama kaip bendra organizacijos vertė, bendra visų materialių ir nematerialių elementų suma. Materialiųjų elementų pavyzdžiai yra piniginis turtas, ilgalaikis turtas, akcinis kapitalas ir ryšiai. Nematerialių elementų pavyzdžiai yra reputacija, prekės ženklo atpažinimas, viešoji nauda ir prekių ženklai. Priklausomai nuo organizacijos, verslo vertės turinys gali būti trumpalaikis, vidutinis ir ilgalaikis. Vertė gali būti sukurta efektyviai valdant vykdomą operatyvinę veiklą. Tačiau efektyviai taikydamos projektų, programų ir portfelio valdymo disciplinas, organizacijos įgyja galimybę taikyti patikimus, pripažintus procesus strateginiams tikslams pasiekti ir iš savo projektų investicijų gauti didesnę verslo vertę.

Projekto vadovas- asmuo, kurį vykdančioji organizacija paskyrė vadovauti komandai ir yra atsakingas už projekto tikslų įgyvendinimą.

Projekto vadovo vaidmuo skiriasi nuo funkcinio ar operacijų vadovo. Paprastai funkcinis vadovas yra orientuotas į funkcinio ar verslo padalinio priežiūrą, o dirbantys vadovai yra atsakingi už verslo operacijų efektyvumo užtikrinimą.

RP kompetencijos:

· Žinių kompetencijos- ką vadovas žino apie projektų valdymą.

· Veiklos kompetencijos- ką projektų vadovas gali padaryti ar pasiekti taikydamas savo projektų valdymo žinias.

· Asmeninės kompetencijos- kaip elgiasi projekto vadovas vykdant projektą ar su juo susijusią veiklą. Asmeninis efektyvumas apima nuostatas, pagrindines asmenybės savybes ir vadovavimo įgūdžius – gebėjimą vadovauti projekto komandai siekiant projekto tikslų ir subalansuoti projekto suvaržymus.

RP įgūdžiai:

· vadovavimas,

· komandos stiprinimas,

· motyvacija,

· bendravimas,

· įtaka,

· priimti sprendimus,

· politinis ir kultūrinis sąmoningumas,

· derybos,

· kurti pasitikėjimu grįstus santykius,

· konfliktų sprendimas,

· koučingas.

2. ORGANIZACIJOS IR PROJEKTO GYVIMO CIKLO ĮTAKA

Organizacinių procesų turtas yra planai, procesai, politika, procedūros ir žinių bazės, būdingos vykdančiajai organizacijai ir jos naudojamos. Jie apima bet kokius artefaktus, metodus ir žinias apie kai kurias arba visas projekte dalyvaujančias organizacijas, kurios gali būti naudojamos projektui vykdyti arba jam vadovauti. Be to, proceso turtas apima organizacijos žinių bazes, tokias kaip išmoktos pamokos ir istorinė informacija. Organizacijos proceso turtas gali apimti užbaigtus grafikus, rizikos duomenis ir uždirbtos vertės duomenis. Organizacijos proceso turtas yra daugumos planavimo procesų įvestis. Viso projekto metu komandos nariai gali atnaujinti ir prireikus papildyti organizacijos procesų išteklius. Organizacijos proceso turtą galima suskirstyti į dvi kategorijas:

· procesai ir procedūros

· įmonės žinių bazė

Įmonės aplinkos veiksniai labai skiriasi pagal tipą ar pobūdį. Įmonės aplinkos veiksniai apima, bet neapsiriboja:

· organizacinė kultūra, struktūra ir lyderystė;

· geografinis įrangos ir išteklių pasiskirstymas;

· vyriausybės ir pramonės standartai (pavyzdžiui, reguliavimo institucijų nuostatai, elgesio kodeksai, gaminių standartai, kokybės standartai, gamybos standartai);

· infrastruktūra (pvz., esamos struktūros ir kapitalinė įranga);

· turimi žmogiškieji ištekliai (pvz., įgūdžiai, žinios, specializacijos, tokios kaip projektavimas, kūrimas, teisiniai, sutarčių sudarymas ir pirkimai);

· personalo valdymas (pavyzdžiui, įdarbinimo ir atleidimo gairės, veiklos ir efektyvumo apžvalgos ir personalo mokymo įrašai, kompensacijų ir viršvalandžių politika ir laiko registravimas);

· rinkos situacija;

· suinteresuotųjų šalių rizikos tolerancija;

· politinis klimatas;

· organizacijoje priimti bendravimo kanalai;

· komercinės duomenų bazės (pavyzdžiui, standartizuoti įvertinimo duomenys, pramoninių pavojų tyrimų duomenys ir rizikos duomenų bazės);

· projektų valdymo informacinė sistema (pavyzdžiui, automatizuotos sistemos, tokios kaip tvarkaraščio valdymo programinė įranga, konfigūracijos valdymo sistema, informacijos rinkimo ir paskirstymo sistema arba žiniatinklio sąsajos su kitomis automatizuotomis internetinėmis sistemomis).

Projekto komandos nariai atlieka šiuos vaidmenis:

· Už projektų valdymą atsakingi darbuotojai. Komandos nariai, atliekantys projektų valdymo veiklas, tokias kaip planavimas, biudžeto sudarymas, ataskaitų teikimas ir kontrolė, komunikacija, rizikos valdymas ir administracinė pagalba. Šią funkciją gali atlikti arba palaikyti projektų valdymo biuras (PMO).

· Projekto darbuotojai. Komandos nariai, kurie atlieka darbą, kad sukurtų galutinius projekto rezultatus.

· Pagalbiniai ekspertai. Pagalbiniai ekspertai atlieka veiklą, būtiną projekto valdymo planui parengti arba vykdyti. Tai gali būti derybos dėl sutarties, finansų valdymas, logistika, teisinė pagalba, saugumas, kūrimas, bandymai ar kokybės kontrolė. Priklausomai nuo projekto dydžio ir reikalingos paramos lygio, pagalbiniai ekspertai gali dirbti visą darbo dieną arba tiesiog prisidėti prie komandos, kai reikia specifinių jų įgūdžių.

· Vartotojų ar klientų atstovai. Organizacijos nariai, kurie priims projekto rezultatus ar produktus, gali veikti kaip atstovai arba ryšininkai, kad užtikrintų tinkamą koordinavimą, patartų dėl reikalavimų arba patvirtintų projekto rezultatų priimtinumą.

· Pardavėjai. Pardavėjai, dar vadinami agentais, tiekėjais ar rangovais, yra trečiųjų šalių įmonės, sudarančios sutartis teikti projektui reikalingus komponentus arba paslaugas. Projekto komanda dažnai yra atsakinga už rezultatų ar pardavėjo paslaugų vykdymo ir priėmimo priežiūrą. Jei pardavėjai prisiima didelę riziką pristatydami projekto rezultatus, jie gali atlikti svarbų vaidmenį projekto komandoje.

· Verslo partnerių organizacijų nariai. Tinkamam koordinavimui užtikrinti į projekto komandą gali būti priskirti verslo partnerių organizacijų nariai.

· Verslo partneriai. Verslo partneriai taip pat yra trečiosios šalys, tačiau juos su įmone sieja ypatingi santykiai, kartais įgyjami sertifikavimo būdu. Verslo partneriai teikia specializuotą patirtį arba atlieka tam tikrą vaidmenį, pvz., diegimą, pritaikymą, mokymą ar palaikymą.

Projekto gyvavimo ciklas- etapų rinkinys, per kurį projektas pereina nuo jo inicijavimo iki uždarymo momento.

Visi projektai gali turėti tokią gyvavimo ciklo struktūrą:

· projekto pradžia;

· organizavimas ir paruošimas;

· projektinių darbų vykdymas;

· projekto užbaigimas.

Projekto etapas- logiškai susijusių projekto operacijų, kurios baigiasi vieno ar kelių rezultatų pasiekimu, rinkinys.

Nuspėjamieji gyvenimo ciklai(taip pat žinomas kaip visiškai pagrįstas planu) yra projekto gyvavimo ciklo tipas, kai projekto apimtis ir laikas bei sąnaudos, kurių reikia šiai apimčiai užbaigti, nustatomi kuo anksčiau.

Iteraciniai ir laipsniški gyvavimo ciklai yra gyvavimo ciklai, kurių metu projekto fazės (taip pat vadinamos iteracijomis) sąmoningai kartoja vieną ar daugiau projekto veiklų, kai projekto komanda pradeda geriau suprasti produktą. Iteratyvumas apibrėžia produkto kūrimą per pasikartojančių ciklų seriją, o inkrementiškumas apibrėžia nuoseklų produkto funkcionalumo didėjimą. Per šiuos gyvavimo ciklus gaminys kuriamas tiek iteratyviai, tiek laipsniškai.

Prisitaikantys gyvavimo ciklai(taip pat žinomi kaip pokyčiais skatinami arba judrūs metodai) siekia reaguoti į didelius pokyčius ir reikalauja nuolatinio didelio suinteresuotųjų šalių įsitraukimo. Adaptaciniai metodai taip pat yra pasikartojantys ir laipsniški, tačiau skiriasi tuo, kad kartojimai vyksta labai greitai (dažniausiai trunka 2–4 ​​savaites) ir yra fiksuoti laiko ir sąnaudų požiūriu. Adaptyviuose projektuose per kiekvieną iteraciją paprastai atliekami keli procesai, nors ankstyvosios iteracijos gali būti labiau sutelktos į veiklos planavimą. Bendra projekto apimtis yra suskirstyta į reikalavimų rinkinį, o darbai, kuriuos reikia atlikti, kartais vadinami atsilikimu. Iteracijos pradžioje komanda nustato, kiek aukšto prioriteto elementų iš atsilikimo gali būti paimta per kitą iteraciją. Kiekvienos iteracijos pabaigoje produktas turi būti paruoštas klientų peržiūrai.

3. PROJEKTŲ VALDYMO PROCESAI

Projektų valdymas yra žinių, įgūdžių, įrankių ir metodų taikymas projektiniam darbui, siekiant patenkinti projekto reikalavimus. Šis žinių pritaikymas reikalauja efektyvaus projektų valdymo procesų valdymo.

Procesas yra tarpusavyje susijusių veiksmų ir operacijų, atliekamų siekiant sukurti iš anksto nustatytą produktą, paslaugą ar rezultatą, visuma. Kiekvienas procesas apibūdinamas jo įvestimis, įrankiais ir metodais, kuriuos galima taikyti, ir gaunamais rezultatais.

Projekto procesus galima suskirstyti į dvi pagrindines kategorijas:

· Projektų valdymo procesai. Šie procesai užtikrina efektyvų projekto vykdymą per visą jo gyvavimo ciklą. Šie procesai apima priemones ir metodus, susijusius su žinių srityse aprašytų įgūdžių ir gebėjimų taikymu.

· Į produktą orientuoti procesai.Šie procesai apibrėžia ir sukuria projekto produktą. Į produktą orientuoti procesai paprastai apibrėžiami pagal projekto gyvavimo ciklą ir skiriasi priklausomai nuo taikymo srities bei produkto gyvavimo ciklo fazės. Projekto apimtis negali būti apibrėžta be tam tikro pagrindinio supratimo, kaip sukurti tam tikrą produktą. Pavyzdžiui, nustatant bendrą statomo pastato sudėtingumą, reikia atsižvelgti į įvairias statybos technologijas ir įrankius.

Projektų valdymo procesai skirstomi į penkias kategorijas, žinomas kaip projektų valdymo procesų grupės (arba procesų grupės):

· Iniciacijos proceso grupė. Procesai, atliekami siekiant apibrėžti naują projektą arba naują esamo projekto etapą, gavus leidimą pradėti projektą ar etapą.

· Planavimo proceso grupė. Procesai, reikalingi norint nustatyti darbų apimtį, išsiaiškinti tikslus ir nustatyti veiksmų, reikalingų projekto tikslams pasiekti, eigą.

· Vykdymo proceso grupė. Procesai, naudojami projekto valdymo plane nurodytam darbui užbaigti, kad atitiktų projekto specifikacijas.

· Stebėjimo ir kontrolės procesų grupė. Procesai, reikalingi projekto vykdymui stebėti, analizuoti ir reguliuoti; teritorijų, kuriose reikia keisti planą, nustatymas; ir inicijuoti atitinkamus pakeitimus.

· Uždarymo proceso grupė. Procesai, atliekami siekiant užbaigti visas veiklas visose procesų grupėse, siekiant oficialiai užbaigti projektą ar etapą.

Proceso grupės nėra projekto gyvavimo ciklo fazės!

Projekto gyvavimo ciklo metu surenkama, analizuojama, transformuojama ir įvairiais formatais išplatinama nemažai duomenų ir informacijos projekto komandos nariams ir kitoms suinteresuotoms šalims. Projekto duomenys yra renkami įvairiais vykdymo procesais ir pateikiami projekto komandos nariams.

Šios gairės sumažina nesusipratimų skaičių ir padeda projekto komandai vartoti tinkamą terminiją:

· Darbo atlikimo duomenys. Neapdoroti stebėjimai ir matavimai, nustatyti atliekant projekto darbus. Pavyzdžiai: fiziškai atlikto darbo procentinė dalis, kokybės ir techninio našumo rodikliai, grafiko veiklos pradžios ir pabaigos datos, pakeitimų užklausų skaičius, defektų skaičius, faktinės išlaidos, faktinė trukmė ir kt.

· Informacija apie darbų atlikimą. Veiklos duomenys, surinkti iš įvairių kontrolės procesų, analizuojami kontekste ir apibendrinami remiantis disciplinų santykiais. Veiklos informacijos pavyzdžiai apima rezultatų būseną, pakeitimų užklausų įgyvendinimo būseną ir prognozių įvertinimą iki užbaigimo.

· Darbo atlikimo ataskaitos. Projekto dokumentuose surinktos darbo atlikimo informacijos fizinis arba elektroninis atvaizdavimas, skirtas sprendimams priimti ar problemoms formuluoti, veiksmams atlikti ar sąmoningumui formuoti. Pavyzdžiai: būsenos ataskaitos, atmintinės, motyvai, informaciniai lapeliai, elektroninės informacijos suvestinės, patarimai ir naujiniai.

47 projektų valdymo procesai, aprašyti PMBOK vadove, yra suskirstyti į 10 skirtingų žinių sričių. Žinių sritis – tai išsami sąvokų, terminų ir veiklų sistema, sudaranti profesinę sritį, projektų valdymo sritį ar veiklos sritį. Šios 10 žinių sričių yra beveik nuolat naudojamos daugelyje projektų. Projekto komandos turėtų naudoti šias 10 žinių sričių ir kitas žinių sritis, kurių reikia jų konkrečiam projektui. Specializuotos sritys apima:

· projektų integravimo valdymas,

· projekto turinio valdymas,

· Projekto laiko valdymas,

· projekto išlaidų valdymas,

· projektų kokybės valdymas,

· projektų žmogiškųjų išteklių valdymas,

· projektų komunikacijos valdymas,

· projekto rizikos valdymas,

· projektų pirkimų valdymas,

· projekto suinteresuotųjų šalių valdymas.

4. PROJEKTŲ INTEGRACIJOS VALDYMAS

Projektų integravimo valdymas apima procesus ir veiklą, būtinus įvairiems projektų valdymo procesams ir veiklai projektų valdymo procesų grupėse apibrėžti, tobulinti, sujungti, integruoti ir koordinuoti.

Projekto chartijoje yra:

· projekto tikslas ar pagrindimas;

· išmatuojamus projekto tikslus ir atitinkamus sėkmės kriterijus;

· aukšto lygio reikalavimai;

· prielaidos ir apribojimai;

· aukšto lygio projekto aprašymas ir ribos;

· aukšto lygio rizikos;

· padidintas kontrolinių renginių grafikas;

· padidintas biudžetas;

· suinteresuotų šalių sąrašas;

· projekto patvirtinimo reikalavimai (t. y. kas tiksliai yra projekto sėkmė, kas nusprendžia, kad projektas sėkmingas ir kas pasirašo projektą);

· paskirtas projektų vadovas, atsakomybės sritis ir įgaliojimų lygis;

· PILNAS VARDAS. ir rėmėjo arba kito (-ų) asmens (-ų), suteikiančio (-ų) projekto chartiją, įgaliojimai.

Darbo aprašymas Projekto darbo ataskaita (SOW) yra žodinis produktų, paslaugų ar rezultatų, kuriuos tikimasi pasiekti įgyvendinant projektą, aprašymas.

SOW atspindi:

· Verslo poreikis. Organizacijos verslo poreikis gali būti pagrįstas rinkos paklausa, technologijų pažanga, teisiniais reikalavimais, vyriausybės nuostatomis arba aplinkosaugos sumetimais. Paprastai verslo poreikis ir lyginamoji kaštų ir naudos analizė įtraukiama į verslo atvejį, siekiant pagrįsti projektą.

· Prekės turinio aprašymas. Produkto apimties pareiškimas apima produkto, paslaugos ar rezultato, kurį ketinama sukurti pagal projektą, charakteristikas. Aprašymas taip pat turi atspindėti ryšį tarp kuriamų produktų, paslaugų ar rezultatų ir verslo poreikio, kurį turi patenkinti projektas.

· Strateginis planas. Strateginis planas apima organizacijos strateginę viziją, tikslus ir uždavinius bei aukšto lygio misijos formuluotę. Visi projektai turi atitikti organizacijos strateginį planą. Derinimas su strateginiu planu leidžia kiekvienam projektui prisidėti prie bendrų organizacijos tikslų.

Verslo atvejis

Verslo atvejis ar panašus dokumentas pateikia verslo požiūriu reikalingą informaciją, kad būtų galima nustatyti, ar projektas vertas reikiamų investicijų. Jį dažniausiai naudoja aukštesnio lygio projektų vadovai, priimdami sprendimus. Paprastai verslo atvejis apima verslo poreikį ir lyginamąją kaštų ir naudos analizę, kad pagrįstų projektą ir apibrėžtų jo ribas, o paprastai tokią analizę atlieka verslo analitikas, naudodamas įvairią informaciją, gautą iš suinteresuotųjų šalių. Rėmėjas turi susitarti dėl verslo atvejo turinio ir apribojimų. Verslo atvejis sukuriamas dėl vieno ar kelių iš šių veiksnių:

rinkos paklausa (pavyzdžiui, automobilių įmonė leidžia projektui gaminti ekonomiškesnius automobilius, reaguojant į benzino trūkumą);

· organizacijos poreikis (pavyzdžiui, dėl didelių pridėtinių išlaidų įmonė gali derinti personalo funkcijas ir optimizuoti procesus, kad sumažintų išlaidas);

· kliento reikalavimas (pavyzdžiui, elektros įmonė įgalioja projektą statyti naują pastotę, tiekiančią elektros energiją naujai pramoninei zonai);

· technologinė pažanga (pavyzdžiui, aviakompanija duoda leidimą naujam projektui sukurti elektroninius bilietus, kurie pakeistų popierinius bilietus, remiantis technologijų pažanga);

· teisinis reikalavimas (pavyzdžiui, dažų gamintojas įgalioja projektą parengti toksiškų medžiagų tvarkymo gaires);

· poveikis aplinkai (pavyzdžiui, įmonė autorizuoja projektą, siekdama sumažinti jo poveikį aplinkai);

· socialinis poreikis (pavyzdžiui, nevyriausybinė organizacija besivystančioje šalyje leidžia įgyvendinti projektą, kuriuo siekiama aprūpinti geriamojo vandens sistemas, tualetus ir sveikatos švietimą bendruomenėms, kenčiančioms nuo didelio choleros lygio).

Susitarimai

Susitarimai naudojami pirminiams projekto ketinimams apibrėžti. Susitarimai gali būti sudaryti kaip sutartis, supratimo memorandumas, susitarimas dėl paslaugų lygio, įsipareigojimo raštas, ketinimų protokolas, žodiniai susitarimai, elektroninis ryšys ar kiti rašytiniai susitarimai. Paprastai sutartis naudojama, jei projektas vykdomas išorės užsakovui.

Įmonės aplinkos veiksniai

Įmonės aplinkos veiksniai, galintys turėti įtakos projekto chartijos kūrimo procesui, yra, bet jais neapsiribojant:

· vyriausybės ir pramonės standartai ar taisyklės (pavyzdžiui, elgesio kodeksai, kokybės standartai arba darbuotojų apsaugos standartai);

· organizacijos kultūra ir struktūra;

· rinkos situacija.

Organizacinių procesų turtas

Organizacinio proceso turtas, galintis turėti įtakos projekto chartijos kūrimo procesui, apima, bet tuo neapsiribojant:

· standartiniai organizacijos procesai, politika ir procesų aprašymai;

· šablonai (pavyzdžiui, projekto chartijos šablonas);

istorinė informacija ir žinių bazė (pvz., projektai, įrašai ir dokumentai, visa projekto užbaigimo informacija ir dokumentacija, informacija apie ankstesnių projektų atrankos sprendimų rezultatus kartu su informacija apie ankstesnių projektų rezultatus ir informacija apie rizikos valdymo veiklą).

Projekto valdymo planas- tai dokumentas, aprašantis, kaip projektas bus vykdomas, kaip jis bus stebimas ir kontroliuojamas. Ji integruoja ir konsoliduoja visus pagalbinius ir pradinius planus, atsirandančius dėl planavimo procesų.

Projekto pagrindai apima, bet tuo neapsiribojant:

· pagrindinis turinio planas;

· bazinis grafikas;

· bazinis išlaidų planas.

Pagalbiniai planai apima, bet tuo neapsiribojant:

· turinio valdymo planas;

· reikalavimų valdymo planas;

· tvarkaraščio valdymo planas;

· išlaidų valdymo planas;

· kokybės vadybos planas;

· procesų tobulinimo planas;

· žmogiškųjų išteklių valdymo planas;

· ryšių valdymo planas;

· rizikos valdymo planas;

· pirkimų valdymo planas;

· suinteresuotųjų šalių valdymo planas.

Be kita ko, į projekto valdymo planą taip pat gali būti įtraukta:

· projekto gyvavimo ciklas ir procesai, kurie bus taikomi kiekviename etape;

išsami informacija apie projekto valdymo komandos priimtus prisitaikymo sprendimus, būtent:

o projekto valdymo komandos pasirinkti projektų valdymo procesai;

o kiekvieno pasirinkto proceso įgyvendinimo lygis;

o priemonių ir metodų, kurie bus naudojami šiems procesams atlikti, aprašymai;

o Aprašymas, kaip pasirinkti procesai bus naudojami konkrečiam projektui valdyti, įskaitant šių procesų priklausomybes ir sąveikas, taip pat reikiamus įvesties ir išvesties duomenis.

· darbų, skirtų projekto tikslams pasiekti, atlikimo tvarka;

· pokyčių valdymo planas, nurodantis, kaip pokyčiai stebimi ir kontroliuojami;

· konfigūracijos valdymo planas, kuriame dokumentuojama, kaip valdoma konfigūracija;

· pradinių planų vientisumo palaikymo tvarkos aprašas;

· suinteresuotųjų šalių bendravimo reikalavimai ir metodai;

· pagrindinės vadovybės peržiūros veiklos, susijusios su svarstytinų klausimų ir priimtinų sprendimų turiniu, apimtimi ir terminais.

Suplanuokite prognozes

Tvarkaraščio prognozės sudaromos atsižvelgiant į pažangą, palyginti su pradiniu grafiku, ir prognozuojamu laiku iki užbaigimo (ETT). Paprastai jie išreiškiami tvarkaraščio dispersija (SDV) ir tvarkaraščio atlikimo indeksu (MSI). Projektams, kuriuose nenaudojamas uždirbtos vertės valdymas, pranešama apie nukrypimus nuo planuotų ir numatomų pabaigos datų.

Prognozė gali būti naudojama norint nustatyti, ar projektas atitinka toleranciją, ir nustatyti būtinus pakeitimų prašymus.

Išlaidų prognozės

Išlaidų prognozės sudaromos remiantis pažanga, palyginti su pradine sąnaudų linija ir numatoma prognoze iki užbaigimo (ELP). Paprastai jie išreiškiami sąnaudų dispersija (CVI) ir išlaidų efektyvumo indeksu (CVPI). Prognozė iki užbaigimo (FCP) gali būti lyginama su biudžetu iki užbaigimo (BOC), siekiant nustatyti, ar projektas atitinka toleranciją, ar reikia pateikti pakeitimų užklausas. Projektams, kuriuose nenaudojamas uždirbtos vertės valdymas, pateikiami nukrypimai nuo planuotų ir faktinių išlaidų, taip pat numatomos galutinės išlaidos.

Toliau pateikiamos kai kurios konfigūracijos valdymo veiklos, įtrauktos į integruotą pakeitimų valdymo procesą:

· Konfigūracijos apibrėžimas. Apibrėžkite ir pasirinkite konfigūracijos elementus, kad sukurtumėte pagrindą, kuriuo remiantis apibrėžiama ir patvirtinama gaminio konfigūracija, ženklinami produktai ir dokumentai, kontroliuojami pakeitimai ir tvarkoma apskaita.

· Pranešimas apie konfigūracijos būseną. Kai reikia pateikti atitinkamus duomenis apie konfigūracijos elementą, informacija yra dokumentuojama ir pranešama. Tokia informacija apima patvirtintų nustatytų konfigūracijos elementų sąrašą, siūlomų konfigūracijos pakeitimų būseną ir patvirtintų pakeitimų įgyvendinimo būseną.

· Konfigūracijos patvirtinimas ir auditas. Konfigūracijos patvirtinimas ir auditas užtikrina, kad projekto konfigūracijos elementų struktūra būtų teisinga, o atitinkami pakeitimai būtų registruojami, įvertinami, patvirtinami, sekami ir tinkamai įgyvendinami. Taip užtikrinama, kad būtų laikomasi konfigūracijos dokumentacijoje nustatytų funkcinių reikalavimų.

5. PROJEKTO TURINIO VALDYMAS

Projekto apimties valdymas apima procesus, reikalingus užtikrinti, kad projekte būtų visi ir tik darbai, kurių reikia norint sėkmingai užbaigti projektą. Projekto apimties valdymas yra tiesiogiai susijęs su apibrėžimu ir kontrole, kas yra ir kas neįtraukta į projektą.

Projekto kontekste terminas „turinys“ gali reikšti:

Reikalavimų klasės:

· Verslo reikalavimai, apibūdinantys aukšto lygio visos organizacijos poreikius, pavyzdžiui, organizacijos problemas ar galimybes, ir priežastis, kodėl buvo imamasi projekto.

· Suinteresuotųjų šalių reikalavimai, apibūdinantys suinteresuotos šalies ar suinteresuotųjų šalių grupės poreikius.

· Sprendimo reikalavimai, apibūdinantys produkto, paslaugos ar rezultato ypatybes, funkcijas ir charakteristikas, kurios patenkins verslo ir suinteresuotųjų šalių reikalavimus. Reikalavimai sprendimui savo ruožtu skirstomi į funkcinius ir nefunkcinius reikalavimus:

o Funkciniai reikalavimai apibūdina gaminio elgesį. Pavyzdžiui, procesai, duomenys ir produktų sąveika.

o Nefunkciniai reikalavimai papildo funkcinius reikalavimus ir apibūdina sąlygas arba aplinkos savybes, būtinas produkto veiksmingumui užtikrinti. Pavyzdžiai: patikimumas, sauga, našumas, sauga, paslaugų lygis, palaikomumas, saugojimo / šalinimo reikalavimai ir kt.

· Perėjimo reikalavimai apibūdina laikinąsias galimybes, pvz., duomenų transformavimo ir mokymosi reikalavimus, reikalingus norint ateityje pereiti iš dabartinės būsenos „kaip yra“ į būseną „būti“.

· Projekto reikalavimai apibūdina veiklas, procesus ar kitas sąlygas, kurias turi atitikti projektas.

· Kokybės reikalavimai, apimantys bet kokią sąlygą ar kriterijų, būtiną sėkmingam projekto rezultato pasiekimui arba kitų projekto reikalavimų įvykdymui įrodyti.

6. PROJEKTŲ LAIKO VALDYMAS

Projekto laiko valdymas apima procesus, būtinus užtikrinti, kad projektas būtų baigtas laiku.

Veiklos priklausomybių tipai:

· Finišas-pradžia(finišas-startas, FS). Loginis ryšys, kuriame tolesnės operacijos pradžia priklauso nuo ankstesnės operacijos pabaigos. Pavyzdys: medalių įteikimo ceremonija (įpėdinio operacija) negali būti pradėta tol, kol nebus baigtos ankstesnės operacijos lenktynės).

· Apdaila-apdaila(apdaila-apdaila, FF). Loginis ryšys, kuriame tolesnės operacijos pabaiga priklauso nuo ankstesnės operacijos pabaigos. Pavyzdys: dokumento kūrimas (pirmtako operacija) turi būti baigtas prieš baigiant jo redagavimą (paskesnę operaciją).

· Startas – startas(startas-startas, SS). Loginis ryšys, kuriame vėlesnės operacijos pradžia priklauso nuo ankstesnės operacijos pradžios. Pavyzdys: Betoninio paviršiaus išlyginimas (tolimesnė operacija) negali prasidėti prieš išliejant pamatą (pirmtakė operacija).

· Startas-finišas(startas-finišas, SF). Loginis ryšys, kuriame tolesnės operacijos pabaiga priklauso nuo ankstesnės operacijos pradžios. Pavyzdys: pirmoji saugos pamaina (įpėdinė operacija) negali baigtis tol, kol neprasidės antroji saugos pamaina (pirmtakė).

Trijų balų įvertinimas

Vieno taško veiklos trukmės įverčių tikslumas gali būti pagerintas įvertinus įvertinimo neapibrėžtumą ir riziką. Ši koncepcija kilusi iš programos vertinimo ir peržiūros technikos (PERT). PERT naudoja tris įverčius, kad nustatytų apytikslį veikimo trukmės diapazoną:

· Labiausiai tikėtina(tM). Operacijos trukmė nustatoma atsižvelgiant į išankstinį išteklių paskirstymą, jų našumą, realų jų galimybių užbaigti operaciją įvertinimą, priklausomybę nuo kitų dalyvių, taip pat į darbo pertrūkius.

· Optimistiškas(tO). Operacijos trukmė pagrįsta geriausio operacijos scenarijaus analize.

· Pesimistas(tP). Operacijos trukmė pagrįsta blogiausio operacijos scenarijaus analize.

Atsižvelgiant į numatomą reikšmių pasiskirstymą trijų įverčių diapazone, numatoma trukmė tE apskaičiuojama pagal formulę. Dvi labiausiai paplitusios formulės yra trikampis skirstinys ir beta paskirstymas.

· Trikampis pasiskirstymas. tE = (tO + tM + tP) / 3

· Beta paskirstymas (iš tradicinio PERT metodo). tE = (tO + 4tM + tP) / 6

Kritinio kelio metodas

Kritinio kelio metodas- metodas, naudojamas minimaliai projekto trukmei įvertinti ir tvarkaraščio lankstumo laipsniui loginiais tinklo keliais pagal tvarkaraščio modelį nustatyti. Grafiko tinklo analizės metodas leidžia apskaičiuoti visų veiklų ankstyvą pradžios ir pabaigos datas, taip pat vėlyvas pradžios ir pabaigos datas, neatsižvelgiant į išteklių apribojimus, atliekant projekto tinklo pirmyn ir atgal eigos analizę, kaip parodyta pav. 6-18. Šiame pavyzdyje ilgiausias kelias apima veiklas A, C ir D, todėl seka A-C-D yra kritinis kelias. Kritinis kelias – tai veiklų seka, nurodanti ilgiausią kelią projekto tvarkaraštyje, kuris lemia trumpiausią įmanomą projekto trukmę. Ankstyvos pradžios ir pabaigos datos nebūtinai yra projekto tvarkaraštis; veikiau jie nurodo laiko periodus, per kuriuos veikla gali būti atliekama naudojant parametrus, įvestus į grafiko modelį, susijusius su veiklos trukme, loginiais ryšiais, potencialiais klientais, vėlavimais ir kitais žinomais apribojimais. Kritinis metodas

kelias naudojamas tvarkaraščio lankstumo laipsniui apskaičiuoti pagal tinklo loginius kelius tvarkaraščio modelyje.

Kritinės grandinės metodas

Kritinės grandinės metodas(CCM) yra tvarkaraščio kūrimo metodas, leidžiantis projekto komandai bet kuriame tvarkaraščio kelyje įdėti buferius, kad būtų atsižvelgta į išteklių apribojimus ir su projektu susijusius neapibrėžtumus. Jis sukurtas naudojant kritinio kelio metodą ir atsižvelgiama į paskirstymo, optimizavimo, išteklių niveliavimo poveikį, taip pat

neapibrėžtumas dėl veiklos trukmės kritiniame kelyje, nustatytas kritinio kelio metodu. Kritinės grandinės metodas apima buferių ir buferio valdymo sąvokas. Kritinės grandinės metodas naudoja operacijas, kurių trukmė neapima saugos ribų, loginių ryšių ir išteklių prieinamumo

Statistiškai apibrėžti buferiai, apimantys bendras saugos ribas operacijoms konkrečiuose projekto taškuose projekto tvarkaraščio kelyje, kad būtų atsižvelgta į ribotus išteklius ir neapibrėžtumą, susijusį su projektu. Kritinis kelias su išteklių apribojimais yra žinomas kaip „kritinė grandinė“.

7. PROJEKTO IŠLAIDŲ VALDYMAS

Projekto kaštų valdymas apima procesus, būtinus planuoti, įvertinti, sudaryti biudžetą, kaupti lėšas, finansuoti, valdyti ir kontroliuoti išlaidas, kad projektas būtų vykdomas neviršijant patvirtinto biudžeto.

Uždirbtos vertės valdymas

Uždirbtos vertės valdymas(EVM) – tai metodika, apjungianti apimtį, tvarkaraštį ir išteklių vertinimus, siekiant įvertinti projekto pažangą ir pasiektą efektyvumą. Tai plačiai pripažintas projekto našumo matavimo metodas. Jis sujungia bazinę apimtį su pradine sąnaudų linija ir projekto tvarkaraščio bazine linija, kad sudarytų pradinę vykdymo liniją, leidžiančią projekto valdymo komandai įvertinti ir įvertinti projekto našumą ir pažangą. Tai projektų valdymo metodas, reikalaujantis sukurti integruotą bazinę liniją, pagal kurią būtų galima įvertinti našumą viso projekto metu. Galima taikyti EVM principus

visi projektai bet kurioje pramonės šakoje. Naudojant EVM, kiekvienam darbo paketui ir kontrolės paskyrai sukuriami ir stebimi šie trys pagrindiniai rodikliai:

· Planuojamas tūris. Planuojama apimtis (PO) – tai patvirtintas biudžetas, skirtas planuojamiems darbams atlikti. Tai patvirtintas biudžetas, skirtas darbams, atliekamiems pagal operacijos arba darbų suskirstymo struktūros komponentą, neįskaitant valdymo rezervo. Šis biudžetas yra paskirstomas projekto gyvavimo ciklo etapams, tačiau tam tikru momentu planuojama apimtis nulemia fizinį darbą, kuris turėjo būti atliktas. Suvestinė programinė įranga kartais vadinama našumo matavimo bazine linija (PMB). Visa planuojama projekto apimtis taip pat žinoma kaip biudžetas, kurį reikia užbaigti (BOC).

· Įvaldytas tūris. Asimiliuota apimtis (AS) – tai atliktų darbų apimtis, išreikšta šiems darbams skirtu įgaliotu biudžetu. Tai biudžetas, susietas su atliktais įgaliotais darbais. Išmatuotas TOE turi būti susietas su PMB, o išmatuotas TOE negali viršyti patvirtinto to komponento programinės įrangos biudžeto. TOE dažnai naudojamas skaičiuojant projekto užbaigimo procentą. Kiekvienam WBS komponentui turi būti nustatyti atlikto darbo eigos matavimo kriterijai. Projektų vadovai stebi TOE tiek palaipsniui, kad nustatytų dabartinę būseną, tiek bendrai, kad nustatytų ilgalaikes veiklos tendencijas.

· Tikroji kaina. Faktinės išlaidos (AC) – tai faktinės išlaidos, patirtos atliekant darbą kaip operacijos dalį tam tikrą laikotarpį. Tai bendros išlaidos, patirtos vykdant veiklą, vertinamos OO. FS pagal apibrėžimą turi atitikti tai, kas buvo įtraukta į programinę įrangą ir matuojama OO (pavyzdžiui, tik tiesioginės darbo laiko sąnaudos, tik tiesioginės išlaidos arba visos išlaidos, įskaitant netiesiogines). FS neturi viršutinės ribos; matuojama viskas, kas išleidžiama OO pasiekti.

Taip pat stebimi nukrypimai nuo patvirtinto pradinio plano:

· Laiko nuokrypis. Tvarkaraščio nuokrypis (SDV) yra grafiko vykdymo rodiklis, išreiškiamas skirtumu tarp įsisavinto ir planuojamo apimties. Laikas, per kurį projektas atsilieka nuo planuojamos pristatymo datos tam tikru momentu arba lenkia jį. Tai projekto grafiko vykdymo matavimas. Jo reikšmė lygi įsisavintam tūriui (VM) atėmus planuojamą tūrį (VP). EVM tvarkaraščio dispersija yra naudinga metrika, nes ji parodo, kada projektas atsilieka nuo pradinio lygio arba lenkia jį. Projekto pabaigoje EVM tvarkaraščio nuokrypis galiausiai bus lygus nuliui, nes iki to laiko turi būti užbaigti visi suplanuoti kiekiai. Laiko dispersiją geriausia naudoti kartu su kritinio kelio metodo (CPM) planavimu ir rizikos valdymu. Formulė: OSR = OO - PO

· Sąnaudų dispersija. Išlaidų dispersija (CVV) yra biudžeto deficito arba pertekliaus suma tam tikru momentu, išreiškiama kaip skirtumas tarp uždirbtos vertės ir faktinių išlaidų. Tai yra projekto našumo matavimas sąnaudų požiūriu. Ji lygi uždirbtai vertei (EV), atėmus faktines išlaidas (FC). Sąnaudų skirtumas projekto pabaigoje bus lygus skirtumui tarp užbaigto biudžeto (BOC) ir faktiškai išleistos sumos. OST yra nepaprastai svarbus, nes jis parodo ryšį tarp fizinio našumo ir išleistų lėšų. Neigiamas OST dažnai neatgaunamas projektui. Formulė: OST = OO – FS.

OCP ir OCP vertės gali būti konvertuojamos į veiklos rodiklius, kad atspindėtų bet kurio projekto išlaidas ir grafiką, palyginti su visais kitais projektais arba projektų portfelyje. Nukrypimai yra naudingi nustatant projekto būseną.

· Termino laikymosi indeksas. Laiko atitikties indeksas (DMI) yra tvarkaraščio efektyvumo rodiklis, išreiškiamas įsisavintos apimties ir planuojamos apimties santykiu. Jis matuoja, kaip efektyviai projekto komanda naudoja savo laiką. Jis kartais naudojamas kartu su išlaidų užbaigimo indeksu (CVSI), kad būtų galima numatyti galutinius projekto užbaigimo įvertinimus. VSI vertė mažesnė nei 1,0 rodo, kad atlikta mažiau darbų nei planuota. Didesnė nei 1,0 VSI reikšmė rodo, kad atlikta daugiau darbų nei planuota. Kadangi TST matuoja visą projekto veiklą, taip pat būtina išanalizuoti našumą kritiniu keliu, kad būtų galima nustatyti, ar projektas bus baigtas iki numatytos pabaigos datos, ar po jos. IVSR yra lygus OO ir PO santykiui. Formulė: IVSR = OO/PO

· Sąnaudų našumo indeksas. Išlaidų efektyvumo indeksas (CVTI) – tai į biudžetą įtrauktų išteklių efektyvumo savikaina rodiklis, išreiškiamas uždirbtos apimties ir faktinių išlaidų santykiu. Tai laikoma svarbiausia EVM metrika ir matuoja atlikto darbo ekonomiškumą. IVST reikšmė mažesnė nei 1,0 rodo atlikto darbo sąnaudų viršijimą. IVST reikšmė didesnė nei 1,0 rodo, kad konkrečią datą vykdymo metu nepanaudotos lėšos. IVSR yra lygus OO ir FS santykiui. Indeksai yra naudingi nustatant projekto būseną, taip pat suteikia pagrindą įvertinti galutinį projekto laiką ir kainą. Formulė: IVST = OO/FS

Trys planuojamos apimties, uždirbtos vertės ir faktinių sąnaudų rodikliai gali būti stebimi ir pateikiami periodiškai (dažniausiai kas savaitę arba kas mėnesį) arba kaupiami.

Prognozavimas

Vykstant projektui, projekto komanda gali parengti užbaigimo prognozę (BCT), kuri gali skirtis priklausomai nuo biudžeto iki užbaigimo (BCP), atsižvelgiant į projekto rezultatus. Jei paaiškėja, kad BPF nebėra realus, projekto vadovas turėtų peržiūrėti BPF. PPP kūrimas apima sąlygų ir įvykių, kurie įvyks projekto ateityje, prognozavimą, remiantis dabartine veiklos informacija ir kitomis žiniomis, turimomis prognozės sudarymo metu. Prognozės generuojamos, atnaujinamos ir iš naujo išleidžiamos remiantis

darbų atlikimo duomenys, gauti projekto eigoje. Darbo našumo informacija apima ankstesnius projekto rezultatus ir bet kokią informaciją, kuri gali turėti įtakos projektui ateityje.

PPV paprastai apskaičiuojamas kaip faktinės atlikto darbo sąnaudos, pridėjus likusio darbo prognozę iki užbaigimo (FTC). Projekto komanda, remdamasi šiuo metu turima patirtimi, turi numatyti, su kuo ji gali susidurti įgyvendindama projektą. EVM metodas gerai veikia kartu su rankiniu būdu sukurtomis reikiamo PPV prognozėmis. Plačiausiai naudojamas PPV prognozavimo metodas yra rankinis sumavimas iš apačios į viršų, kurį atlieka projekto vadovas ir projekto komanda.

Projekto vadovo naudojamas „iš apačios į viršų“ BPM metodas yra pagrįstas įrašytomis faktinėmis išlaidomis ir atliktų darbų patirtimi, todėl prieš užbaigiant likusius projekto darbus reikia sudaryti naują prognozę. Formulė: PPZ = FS + PDZ „iš apačios į viršų“.

Projekto vadovo rankiniu būdu sukurtas KPI greitai palyginamas su daugybe apskaičiuotų KPI, atspindinčių įvairius rizikos scenarijus. Skaičiuojant PPV reikšmes, paprastai naudojamos suminės IVST ir IVSR vertės. Nors EVM duomenys gali greitai sukurti daug statistinių PPV, toliau aprašomi tik trys dažniausiai naudojami metodai:

· PPZ už PPZ darbus, atliekamus pagal biudžetinius įkainius. Šis PPP metodas naudoja faktinį projekto našumą konkrečią datą (palankią ar nepalankią), atspindinčią faktines išlaidas, ir prognozuoja, kad visi būsimi VPP darbai bus atlikti pagal biudžete numatytus tarifus. Kai faktiniai rezultatai yra nepalankūs, prielaida, kad būsimi rezultatai gerės, turėtų būti priimta tik tada, kai tai pagrįsta projekto rizikos analize. Formulė: PPZ = FS + (BPZ – OO)

· PPZ PPZ darbams, atliekamiems su dabartine IVST. Taikant šį metodą daroma prielaida, kad projektas tęsis ateityje taip pat, kaip buvo iki šiol. Daroma prielaida, kad PD darbas bus atliktas tame pačiame kaupiamojo sąnaudų efektyvumo indekso (CVPI) lygyje, kuris buvo pasiektas projekte iki šio taško. Formulė: PPZ = BPZ/IVST

· PPZ PDZ darbams, atsižvelgiant tiek į IVSR, tiek į IVST veiksnius. Šioje prognozėje PD darbai bus atliekami efektyviai, atsižvelgiant į tiek sąnaudų, tiek laiko veiklos rodiklius. Šis metodas yra naudingiausias, kai vienas iš veiksnių, turinčių įtakos projekto tvarkaraščiui, yra projekto grafikas. Šio metodo variantus IVST ir IVSR svarsto įvairiais santykiais (pavyzdžiui, 80/20, 50/50 ar kitomis proporcijomis), atsižvelgdami į projekto vadovo nuomonę. Formulė: PPZ = FS + [(BPZ – OO)/(IVST x IVSR)]

Kiekvienas iš šių metodų gali būti taikomas bet kuriam konkrečiam projektui ir suteikia projekto valdymo komandai „išankstinio įspėjimo“ signalą, jei PPP neatitinka priimtų leistinų nuokrypių.

Našumo iki užbaigimo indeksas (PTI)

Našumo indeksas iki užbaigimo(IPDZ) - numatomas projekto efektyvumo sąnaudų atžvilgiu rodiklis, kurį reikia pasiekti su likusiais ištekliais, kad būtų pasiektas nustatytas valdymo rodiklis, išreikštas likusios darbo dalies užbaigimo išlaidų santykiu. į likusį biudžetą. IPD yra apskaičiuotas vertės pateikimo indeksas, kurį reikia pasiekti atlikus likusį darbą, kad būtų pasiektas konkretus valdymo tikslas, pvz., BPZ arba PPZ. Jei paaiškėja, kad BPF nebėra realus, projekto vadovas turėtų peržiūrėti BPF. Patvirtinus, PPZ gali pakeisti BPZ apskaičiuojant IPPD. IPPD formulė, pagrįsta BPZ: (BPZ – OO)/(BPZ – FS). IPPD konceptualiai pateiktas toliau pateiktame paveikslėlyje. IPD formulė parodyta apatiniame kairiajame kampe – likęs darbas (apibrėžiamas kaip BP atėmus OO) padalytas iš likusių lėšų (kurias galima apskaičiuoti kaip BP atėmus FS arba PP atėmus FS).

Jei kaupiamasis ICSI yra mažesnis už bazinę liniją (kaip parodyta paveikslėlyje žemiau), visi būsimi projekto darbai turi būti nedelsiant atlikti pagal BPSI (kaip parodyta viršutinėje paveikslo eilutėje), kad liktų įgaliotoje BPZ . Sprendimas, ar tam tikras veiklos lygis yra pasiekiamas, priimamas remiantis daugeliu aspektų, įskaitant riziką, tvarkaraštį ir techninius rezultatus. Šis našumo lygis pavaizduotas kaip IPD linija (PPZ). IPPD formulė, pagrįsta PPZ: (BPZ - OO)/(PPZ - FS). EVM formulės pateiktos toliau esančioje lentelėje.

Veiklos analizė

Našumo analizė lygina sąnaudų efektyvumą laikui bėgant, suplanuoja veiklas arba darbų paketus, kurie viršija arba nesiekia biudžeto, ir lėšų, reikalingų atliekamam darbui užbaigti, įvertinimus. Jei naudojamas EVM, nustatoma ši informacija:

· Nukrypimų analizė. Dispersijos analizė, naudojama EVM, yra sąnaudų (COV = OO - FS), grafiko (OSR = OO - PO) ir užbaigimo dispersijų (HCP = BP - PPZ) dispersijų paaiškinimas (priežastis, poveikis ir korekciniai veiksmai). Dažniausiai analizuojami nukrypimai yra kaina ir grafikas. Projektams, kuriuose nenaudojamas uždirbtos vertės valdymas, galima atlikti panašią dispersijos analizę, lyginant planuojamos veiklos sąnaudas su faktinėmis veiklos sąnaudomis, kad būtų galima nustatyti faktinio projekto našumo nuokrypį nuo pradinių išlaidų. Galima atlikti tolesnę analizę, siekiant nustatyti nukrypimo nuo pradinio grafiko priežastį ir mastą bei būtinus korekcinius ar prevencinius veiksmus. Sąnaudų efektyvumo rodikliai yra naudojami nukrypimo nuo pradinės sąnaudų linijos dydžiui įvertinti. Svarbūs projekto sąnaudų valdymo aspektai apima nukrypimo nuo pradinių išlaidų priežasties ir masto nustatymą bei sprendimą, ar reikia imtis korekcinių ar prevencinių veiksmų. Atliekant vis daugiau darbų, priimtinų nuokrypių procentas mažės.

· Tendencijos analizė. Tendencijų analizė apima projekto veiklos duomenų tyrimą laikui bėgant, siekiant nustatyti, ar projekto našumas gerėja, ar blogėja. Grafinės analizės metodai yra vertingi norint suprasti našumą iki konkrečios datos ir palyginti su būsimais našumo tikslais BPV ir PPV bei užbaigimo datų forma.

· Uždirbtos vertės vykdymas. Uždirbtos vertės įgyvendinimas apima pradinio vykdymo plano palyginimą su faktiniu terminų ir išlaidų įgyvendinimu. Jei EVM nenaudojamas, sąnaudų našumui palyginti naudojama bazinė sąnaudų analizė, palyginti su faktinėmis atlikto darbo sąnaudomis.

8. PROJEKTO KOKYBĖS VALDYMAS

Projekto kokybės valdymas apima vykdančiosios organizacijos procesus ir veiklą, apibrėžiančią kokybės politiką, tikslus ir atsakomybę, kad projektas atitiktų poreikius, dėl kurių jis buvo įgyvendintas. Projekto kokybės vadyba naudoja politiką ir procedūras, kad įgyvendintų organizacijos kokybės vadybos sistemą projekto kontekste ir, jei reikia, palaiko nuolatinį vykdomosios organizacijos vykdomų procesų tobulinimą. Projekto kokybės valdymo tikslas yra užtikrinti, kad projekto reikalavimai, įskaitant gaminio reikalavimus, būtų įvykdyti ir patikrinami.

Kokybė ir klasė yra konceptualiai skirtingos sąvokos. Kokybė, kaip pateikta produkcija arba rezultatas, yra „laipsnis, kuriuo būdingų charakteristikų rinkinys atitinka reikalavimus“ (ISO 9000). Įvertinimas kaip projektavimo tikslas – tai kategorija, priskiriama produktams, kurių funkcinė paskirtis yra tokia pati, bet skiriasi techninėmis charakteristikomis. Projekto vadovas ir projekto valdymo komanda yra atsakingi už kompromisus, kad būtų pasiektas reikiamas kokybės ir lygio lygis. Kokybės reikalavimų neatitinkantis kokybės lygis visada yra problema, tačiau žemas įvertinimas gali ir nebūti.

Siekiant atitikties ISO kontekste, šiuolaikiniai kokybės valdymo metodai siekia kuo labiau sumažinti skirtumus ir pasiekti konkrečius reikalavimus atitinkančių rezultatų. Šie metodai pripažįsta šių dalykų svarbą:

· Klientų pasitenkinimas. Kliento reikalavimų supratimas, įvertinimas, apibrėžimas ir valdymas, siekiant patenkinti klientų lūkesčius. Tam reikia derinti tinkamumą (projektas turi sukurti tai, ko buvo imtasi pasiekti) ir tinkamumo naudoti (produktas ar paslauga turi patenkinti realų poreikį).

· Prevencija yra svarbesnė už patikrinimą. Kokybė turi būti suplanuota, suprojektuota ir įdiegta, o ne tikrinama, valdant projektą ar teikiant projekto rezultatus. Klaidų prevencijos išlaidos paprastai yra daug mažesnės nei jų ištaisymo išlaidos, kai jos aptinkamos patikrinimo arba naudojimo metu.

· Nuolatinis tobulinimas. Ciklas planuok – daryk – patikrink – veik (PDCA), modelis, kurį aprašė Shewhart ir patobulino Demingas, yra kokybės gerinimo pagrindas. Be to, kokybės gerinimo iniciatyvos, tokios kaip Total Quality Management (TQM), Six Sigma ir kombinuotas Six Sigma bei Lean Six Sigma taikymas gali pagerinti projektų valdymo ir projekto produkto kokybę. Proceso tobulinimo modeliai apima Malcolmo Baldrige kokybės modelį, organizacijos projektų valdymo brandos modelį (OPM3®) ir integruotą gebėjimų brandos modelį (CMMI®).

· Vadovybės atsakomybė. Sėkmė reikalauja visų projekto komandos narių dalyvavimo. Tačiau vadovybė, prisiimdama atsakomybę už kokybę, išlaiko atitinkamą atsakomybę už tinkamų išteklių suteikimą atitinkama suma.

· Kokybės kaina(kokybės kaina, COQ). Kokybės sąnaudos – tai bendros atitikties darbų ir neatitikties darbų išlaidos, kurios turi būti atliekamos kaip kompensacinės pastangos, nes pirmą kartą pabandžius atlikti darbą gali būti atlikta arba atlikta netinkamai tam tikra reikalaujamo darbo dalis. . Kokybės užtikrinimo veiklos sąnaudos gali atsirasti per visą pateikto rezultato gyvavimo ciklą. Pavyzdžiui, projekto komandos priimti sprendimai gali turėti įtakos operacijos išlaidoms, susijusioms su užbaigto rezultato naudojimu. Išlaidos, susijusios su kokybės užtikrinimu po projekto uždarymo, gali atsirasti dėl gaminių grąžinimo, pretenzijų dėl garantijos ir gaminių atšaukimo kampanijų. Taigi, dėl laikinojo projekto pobūdžio ir galimos naudos, kurią gali gauti sumažinus poprojektines kokybės išlaidas, remiančios organizacijos gali nuspręsti investuoti į produkto kokybės gerinimą. Šios investicijos paprastai skiriamos atitikties pastangoms, siekiant išvengti defektų arba sumažinti defektų kainą, tikrinant reikalavimų neatitinkančius įrenginius. Be to, klausimai, susiję su COQ po projekto, turėtų būti sprendžiami per programos ir portfelio valdymo procesus, pavyzdžiui, projektų, programų ir portfelio valdymo biurai turėtų taikyti tinkamus analizės metodus, šablonus ir metodus, skirtus šiam tikslui skirti lėšų.

Septyni esminiai kokybės įrankiai

Septyni esminiai kokybės įrankiai, pramonėje taip pat žinomi kaip 7QC įrankiai, naudojami PDCA ciklo kontekste, siekiant išspręsti kokybės problemas. Ryžiai. Žemiau pateikiama konceptuali septynių pagrindinių kokybės įrankių iliustracija, įskaitant:

· Priežasčių ir pasekmių diagramos, dar vadinamos žuvies kaulų diagramomis arba Ishikawa diagramomis. Problemos aprašymas, esantis žuvies kaulo galvutėje, naudojamas kaip atspirties taškas norint atsekti problemos šaltinį iki pagrindinės priežasties, dėl kurios reikia imtis veiksmų. Problemos aprašymas paprastai yra problemos kaip trūkumo, kurį reikia pašalinti, arba tikslo, kurį reikia pasiekti, pareiškimas. Priežasčių paieška vykdoma nagrinėjant problemos aprašymą ir ieškant atsakymų į klausimą „kodėl“, kol bus nustatyta pagrindinė priežastis, dėl kurios reikia imtis veiksmų, arba kol bus išnaudotos visos pagrįstos galimybės kiekvienoje žuvies skeleto dalyje. Žuvies kaulų diagramos dažnai yra naudingos susiejant nepageidaujamą poveikį, kuris laikomas specifiniu pokyčiu, su nustatyta priežastimi, dėl kurios projekto komandos turi imtis taisomųjų veiksmų, kad pašalintų tą konkretų valdymo diagramoje nurodytą pokytį.

· Blokinės diagramos, dar vadinami procesų žemėlapiais, nes jie parodo proceso žingsnių seką ir šakojimosi galimybes, kurios vieną ar kelias įvestis paverčia viena ar daugiau išėjimų. Struktūrinės schemos atspindi operacijas, sprendimo taškus, ciklus, lygiagrečius kelius ir procesų išdėstymą, kaip žemėlapį pateikdamos procedūrų, kurios egzistuoja horizontaliojoje SIPOC modelio vertės grandinėje, detales. Struktūrinės schemos gali būti naudingos norint suprasti ir įvertinti proceso kokybės sąnaudas. Tai atliekama naudojant darbo eigos logiką ir su ja susijusius santykinius dažnius, siekiant įvertinti numatomą atitikties darbo ir neatitikties darbų, reikalingų norint pateikti reikalavimus atitinkančią išvestį, piniginę vertę.

· Duomenų rinkimo lapai, taip pat žinomi kaip skaičiavimo lapai, gali būti naudojami kaip kontroliniai sąrašai renkant duomenis. Duomenų rinkimo lapai naudojami faktams tvarkyti taip, kad būtų lengviau rinkti naudingus duomenis apie galimą kokybės problemą. Jie ypač naudingi renkant parametrų duomenis patikrų metu, siekiant nustatyti defektus. Pavyzdžiui, duomenys apie defektų dažnį ar poveikį, surinkti naudojant duomenų rinkimo lapus, dažnai rodomi naudojant Pareto diagramas.

· Pareto diagramos yra specialios formos vertikalios juostinės diagramos ir naudojamos norint nustatyti kelis svarbiausius šaltinius, sukeliančius daugumą problemos padarinių. Horizontalioje ašyje pateiktos kategorijos atspindi esamą tikimybių pasiskirstymą, sudarantį 100 % galimų stebėjimų. Kiekvienos nustatytos priežasties atitinkamo pasireiškimo dažnio reikšmė, parodyta horizontalioje ašyje, mažėja, kol pasiekia numatytąjį šaltinį, vadinamą „kitu“, kuris yra atsakingas už nenustatytas priežastis. Paprastai Pareto diagrama suskirstyta į kategorijas, kurios matuoja pasireiškimo dažnumą arba pasekmes.

· Histogramos yra specialaus tipo juostinė diagrama, naudojama apibūdinti skirstinio centrą, dispersiją ir statistinio skirstinio formą. Skirtingai nei valdymo diagramoje, histogramoje neatsižvelgiama į laiko poveikį pasiskirstymo variacijai.

· Kontrolės kortelės yra naudojami norint nustatyti, ar procesas yra stabilus, ar ne ir ar jis veikia nuspėjamai. Specifikacijoje nurodytos apatinės ir viršutinės ribos yra pagrįstos sutartyje nurodytais reikalavimais. Jie atspindi didžiausias ir mažiausias priimtinas vertes. Jei vertės viršija nurodytas ribas, gali būti taikomos nuobaudos. Viršutinė ir apatinė valdymo ribos skiriasi nuo specifikacijų ribų. Kontrolės ribos nustatomos naudojant standartinius statistinius skaičiavimus ir principus, kad galiausiai būtų nustatytas natūralus proceso gebėjimas stabilizuotis. Projekto vadovas ir atitinkamos suinteresuotosios šalys gali naudoti statistiškai apskaičiuotas kontrolės ribas, kad nustatytų taškus, kuriuose bus imamasi taisomųjų veiksmų, kad būtų išvengta nenatūralaus veikimo. Korekcinių veiksmų tikslas, kaip taisyklė, yra išlaikyti natūralų stabilaus ir veiksmingo proceso stabilumą. Pakartojamiems procesams valdymo ribos paprastai yra ± 3 sigmos nuo proceso vidurkio, kuris buvo nustatytas į 0. Procesas laikomas nekontroliuojamu, jei: (1) duomenų taškas yra už kontrolės ribų; (2) septyni iš eilės taškai yra virš vidurinės linijos; arba (3) septyni taškai iš eilės yra žemiau vidurinės linijos. Valdymo diagramos gali būti naudojamos įvairių tipų išvesties kintamiesiems stebėti. Nors valdymo diagramos dažniausiai naudojamos siekiant sekti pasikartojančią veiklą, reikalingą pramoniniams produktams gaminti, jos taip pat gali būti naudojamos stebėti sąnaudų ir tvarkaraščio skirtumus, apimties pasikeitimų apimtį ir dažnumą ar kitus valdymo rezultatus, kurie padeda nustatyti, ar projekto valdymo procesai. yra kontroliuojami.

· Sklaidos brėžiniai brėžiamos sutvarkytos poros (X, Y), kartais vadinamos koreliacijos diagramomis, nes jos naudojamos paaiškinti priklausomo kintamojo Y pokytį, palyginti su pastebėtu nepriklausomo kintamojo X pokyčiu. Koreliacijos kryptis gali būti proporcinga ( teigiama koreliacija), priešingai (neigiama koreliacija) arba koreliacijos modelio gali nebūti (nulinė koreliacija). Jei galima nustatyti koreliaciją, galima nustatyti regresijos liniją ir įvertinti, kaip nepriklausomo kintamojo pokytis pakeis priklausomo kintamojo reikšmę.

Valdymo ir kokybės kontrolės įrankiai

Kokybės užtikrinimo procese naudojami kokybės valdymo planavimo ir kokybės kontrolės procesų įrankiai ir metodai. Be to, kiti galimi įrankiai apima:

· Giminystės diagramos. Artimumo diagrama yra panaši į minčių kartografavimo metodą, nes ji naudojama idėjoms generuoti, kurias galima derinti, kad susidarytų organizuotas mąstymo apie problemą būdas. Projekto valdymo proceso metu WBS kūrimas gali būti patobulintas naudojant giminingumo diagramą, kad būtų pateikta apimties suskirstymo struktūra.

· Programos proceso diagramos(procesų sprendimų programos diagramos, PDPC). Naudojamas siekiant suprasti tikslą, susijusį su veiksmais, kurių buvo imtasi tikslui pasiekti. PDPC yra naudingas nuostoliais pagrįsto planavimo metodas, nes padeda komandoms numatyti tarpinius veiksmus, kurie gali užkirsti kelią tikslams pasiekti.

· Nukreiptų santykių grafikai. Santykių diagramų pritaikymas. Nukreiptų santykių grafikai vaizduoja kūrybiško problemų sprendimo procesą vidutiniškai sudėtinguose scenarijuose, kuriems būdingi susipynę iki 50 susijusių elementų loginiai ryšiai. Nukreiptų santykių grafiką galima sudaryti iš duomenų, gautų naudojant kitus įrankius, pvz., giminingumo diagramą, medžio diagramą arba žuvies kaulų diagramą.

· Medžių diagramos. Taip pat žinomos kaip sisteminės diagramos, jas galima naudoti norint parodyti hierarchijų, tokių kaip WBS, rizikos suskirstymo struktūra (RBS) ir organizacinė suskirstymo struktūra (OBS), suskirstymą. Projekto valdymo procese medžio diagramos yra naudingos vizualizuoti tėvų ir vaikų santykius bet kokioje skaidymo hierarchijoje, kuri naudoja sistemingą taisyklių rinkinį pavaldumo ryšiams apibrėžti. Medžio diagramos gali būti horizontalios (pavyzdžiui, rizikos hierarchija) arba vertikalios (pavyzdžiui, komandos hierarchija arba OBS). Kadangi medžių diagramos leidžia sukurti įdėtas šakas, kurios baigiasi vienu sprendimo tašku, jos yra naudingos kaip sprendimų medžiai nustatant tikėtiną riboto skaičiaus ryšių, sistemingai pavaizduotų diagramoje, vertę.

· Prioritetinės matricos. Naudojamas norint nustatyti pagrindines problemas ir tinkamas alternatyvas, kad jos būtų suskirstytos į įgyvendinimo sprendimų rinkinį. Kriterijai yra suskirstyti į prioritetus ir pasverti prieš juos pritaikant visoms galimoms alternatyvoms, kad būtų gautas matematinis balas visų variantų reitingavimui.

· Veikimo tinklo diagramos. Anksčiau vadintos rodyklėmis. Tai apima tinklo diagramų formatus, pvz., veiklos rodyklėje (AOA) ir dažniausiai naudojamą veiklą mazge (AON) formatą. Veiklos tinklo diagramos naudojamos su projektų planavimo metodais, tokiais kaip programos įvertinimo ir peržiūros technika (PERT), kritinio kelio metodu (CPM) ir pirmumo diagramos metodu (PDM).

· Matricos diagramos. Valdymo ir kokybės kontrolės įrankis, naudojamas duomenims analizuoti organizacinėje struktūroje, sukurtoje matricoje. Naudojant matricinę diagramą, siekiama parodyti priklausomybių tarp veiksnių, priežasčių ir tikslų, rodomų matricoje eilučių ir stulpelių pavidalu, stiprumą.

9. PROJEKTO ŽMOGIŠKŲJŲ IŠTEKLIŲ VALDYMAS

Projekto žmogiškųjų išteklių valdymas apima projekto komandos organizavimo, valdymo ir vadovavimo procesus. Projekto komandą sudaro žmonės, kuriems priskirti vaidmenys ir atsakomybė už projekto užbaigimą. Projekto komandos nariai gali turėti skirtingus įgūdžių rinkinius, dirbti visą darbo dieną arba ne visą darbo dieną, o projekto eigoje jie gali būti įtraukti į komandą arba pašalinti iš jos. Projekto komandos nariai taip pat gali būti vadinami projekto darbuotojais. Nors projekto komandos nariams priskiriami konkretūs vaidmenys ir atsakomybė, visų komandos narių dalyvavimas projekto planavime ir sprendimų priėmime yra vertingas projektui. Komandos narių įtraukimas leidžia jiems panaudoti turimą patirtį planuojant projektus ir sustiprina komandos susitelkimą į projekto rezultatų siekimą.

Organizacinės schemos ir pareigybių aprašymai

Yra įvairių formatų, skirtų komandos narių vaidmenų ir pareigų pasiskirstymui dokumentuoti. Dauguma formatų skirstomi į vieną iš trijų tipų: hierarchinį, matricinį ir tekstinį. Be to, kai kurios projektų užduotys nurodytos pagalbiniuose planuose, pvz., rizikos, kokybės ar ryšių planuose. Nepriklausomai nuo to, koks metodas naudojamas, tikslas visada yra tas pats – užtikrinti, kad kiekvienas darbo paketas turėtų aiškų savininką ir kad kiekvienas komandos narys aiškiai suprastų savo vaidmenį ir atsakomybę. Pavyzdžiui, hierarchinis formatas gali būti naudojamas aukšto lygio vaidmenims pavaizduoti, o teksto formatas geriau tinka išsamiam atsakomybės sričių dokumentavimui.

Žmogiškųjų išteklių valdymo planas, be kita ko, apima:

· Vaidmenys ir pareigos. Išvardydami vaidmenis ir pareigas, kurių reikia projektui užbaigti, atsižvelkite į šiuos dalykus:

o Vaidmuo. Projekto darbuotojo priimta arba jam priskirta funkcija. Projekto vaidmenų pavyzdžiai yra statybos inžinierius, verslo analitikas ir bandymų koordinatorius. Turi būti dokumentuojamas aiškus vaidmens aprašymas, susijęs su įgaliojimais, atsakomybe ir ribomis.

o Valdžia. Galimybė skirti projekto išteklius, priimti sprendimus, pasirašyti patvirtinimus, priimti rezultatus ir paveikti kitus komandos narius užbaigti projekto darbą. Sprendimų, kuriems reikalingas aiškus ir tikslus įgaliojimas, pavyzdžiai yra operacijos atlikimo būdo pasirinkimas, kokybės priėmimas ir kaip reaguoti į projekto nukrypimus. Komandos nariai dirba geriau, kai kiekvieno komandos nario valdžios lygis atitinka jų individualias atsakomybės sritis.

o Atsakomybė. Paskirtos pareigos ir darbas, kurį projekto komandos narys turi atlikti, kad užbaigtų projekto veiklą.

o Kvalifikacija. Įgūdžiai ir gebėjimai, reikalingi priskirtai veiklai atlikti pagal projekto apribojimus. Jei projekto komandos nariai neturi reikiamos kvalifikacijos, gali kilti pavojus projekto užbaigimui. Jei nustatomi tokie neatitikimai, reikia imtis prevencinių veiksmų, pavyzdžiui, apmokyti, samdyti kvalifikuotus darbuotojus arba atlikti atitinkamus projekto grafiko ar apimties pakeitimus.

· Projekto organizacinės schemos. Projekto organizacijos schema yra grafinis projekto komandos sudėties ir jos narių ataskaitų teikimo santykių vaizdas. Priklausomai nuo projekto reikalavimų, jis gali būti formalus arba neformalus, detalus arba apibendrintas. Pavyzdžiui, 3000 žmonių reagavimo į ekstremalias situacijas komandos projekto organizacijos diagrama bus daug detalesnė nei vidinio projekto, kuriame dirba 20 žmonių, organizacijos diagrama.

· Personalo planas. Personalo planas yra žmogiškųjų išteklių valdymo plano komponentas, kuriame aprašoma, kada ir kaip bus naudojami projekto komandos nariai ir kiek laiko jų reikės. Jame aprašomas žmogiškųjų išteklių poreikių tenkinimo būdas. Priklausomai nuo projekto reikalavimų personalo planas gali būti formalus arba neformalus, detalus arba apibendrintas. Siekiant atspindėti vykdomas veiklas papildyti ir tobulinti projekto komandą, šis planas projekto metu nuolat atnaujinamas. Personalo plane pateikiama informacija skirsis priklausomai nuo taikymo srities ir projekto dydžio, tačiau bet kuriuo atveju turėtų būti šie elementai:

o Įdarbinimas. Planuojant įdarbinti projekto komandos narius, iškyla nemažai klausimų. Pavyzdžiui, ar bus naudojami turimi organizacijos žmogiškieji ištekliai, ar jie bus samdomi iš išorės pagal sutartį; ar komandos nariai dirbs vienoje vietoje, ar gali dirbti nuotoliniu būdu; kokios yra išlaidos, susijusios su kiekvienu projektui reikalingu įgūdžių lygiu; ir kokio lygio pagalbą projekto komandai gali suteikti organizacijos personalo skyrius ir funkciniai vadovai.

o Išteklių kalendoriai. Kalendoriai, nustatantys tam tikrų išteklių prieinamumą tam tikromis darbo dienomis ir pamainomis. Personalo planas nurodo projekto komandos narių, tiek individualių, tiek kolektyvinių, įsitraukimo laiką, taip pat laikas, kada turėtų prasidėti personalo atrankos veikla, pavyzdžiui, įdarbinimas. Vienas iš įrankių grafiškai parodyti žmogiškuosius išteklius yra išteklių juostinė diagrama, kurią projekto valdymo komanda naudoja kaip priemonę vizualiai pavaizduoti arba paskirstyti išteklius visoms suinteresuotosioms šalims. Šioje diagramoje rodomas valandų skaičius, kurio asmeniui, skyriui ar visai projekto komandai reikia kiekvieną savaitę ar mėnesį projekto trukmės laikotarpiu. Diagramoje gali būti horizontali linija, nurodanti maksimalų valandų skaičių, apskaičiuotą tam tikram ištekliui. Jei diagramos juostos viršija maksimalų galimų valandų skaičių, reikia taikyti išteklių optimizavimo strategiją, pvz., skirti papildomų išteklių arba planuoti iš naujo.

o Darbuotojų atleidimo planas. Nustatyti, kaip ir kada atleisti komandos narius nuo projekto įsipareigojimų, naudinga ir projektui, ir komandos nariams. Kai komandos nariai atleidžiami nuo projekto, jie pašalina mokėjimus darbuotojams, kurie jau atliko savo darbo dalį su projektu, taip sumažindami projekto išlaidas. Bendras moralinis klimatas pagerėja, jei jau iš anksto planuojamas sklandus perėjimas prie naujų projektų. Darbuotojų atleidimo planas taip pat gali sumažinti žmogiškųjų išteklių riziką, kuri gali kilti projekto metu arba po jo.

o Mokymų poreikiai. Jei nerimaujama, kad projektui priskirti komandos nariai gali būti nepakankamai kvalifikuoti, mokymo planas turėtų būti parengtas kaip projekto plano dalis. Į šį planą taip pat gali būti įtrauktos mokymo programos komandos nariams, kurios padės jiems gauti sertifikatus, kurie prisidės prie sėkmingo projekto užbaigimo.

o Pripažinimas ir atlygis. Aiškūs kriterijai ir suplanuota atlygio sistema padeda paskatinti ir išlaikyti norimą projekte dalyvaujančių žmonių elgesį. Kad pripažinimas ir atlygis būtų veiksmingi, jie turi būti pagrįsti veiksmais ir efektyvumo bei efektyvumo priemonėmis, kurias asmuo gali kontroliuoti. Pavyzdžiui, komandos narys gali būti apdovanotas už tam tikro išlaidų tikslo pasiekimą tik tuo atveju, jei jis turi pakankamai įgaliojimų kontroliuoti sprendimus, turinčius įtakos sąnaudoms. Sukūrę planą su laiku mokamu atlygiu užtikrinsite, kad atlygis nebus pamirštas. Pripažinimas ir atlygis yra projekto komandos tobulinimo proceso dalis.

o taisyklių laikymasis. Į žmogiškųjų išteklių planą gali būti įtrauktos strategijos, užtikrinančios, kad projektas atitiktų galiojančius vyriausybės reglamentus, profesinių sąjungų sutartis ir kitą nustatytą žmogiškųjų išteklių politiką.

o Saugumas. Personalo planas ir rizikos registras gali apimti politiką ir procedūras, skirtas apsaugoti komandos narius nuo nelaimingų atsitikimų.

Vienas modelis, naudojamas apibūdinti komandos vystymąsi, yra Tuckmano kopėčios (Tuckman, 1965; Tuckman ir Jensen, 1977), apimančios penkis vystymosi etapus, kuriuos komandos turi pereiti. Paprastai šie etapai vyksta eilės tvarka, tačiau dažnai komanda gali užstrigti tam tikrame etape arba grįžti į ankstesnį. Projektuose, kuriuose komandos nariai anksčiau dirbo kartu, tam tikri etapai gali būti praleisti.

· Formavimas. Šiame etape komanda susirenka ir sužino apie projektą bei oficialius savo vaidmenis ir atsakomybę jame. Komandos nariai šioje fazėje linkę būti nepriklausomi vienas nuo kito ir nėra ypač atviri.

· Audra. Šiame etape komanda pradeda studijuoti darbą su projektu, techninis sprendimai ir požiūris į projektų valdymą. Jei komandos nariai nėra linkę bendradarbiauti ir nėra atviri įvairioms idėjoms ir perspektyvoms, aplinka gali tapti neproduktyvi.

· Atsiskaitymas. Atsiskaitymo etape komandos nariai pradeda dirbti kartu ir koreguoja savo darbo įpročius bei elgesį, kad skatintų komandinį darbą. Komandos nariai išmoksta pasitikėti vieni kitais.

· Efektyvumas. Spektaklio sceną pasiekusios komandos veikia kaip gerai organizuotas vienetas. Jie yra nepriklausomi ir ramiai bei efektyviai sprendžia problemas.

· Užbaigimas. Šiame etape komanda baigia darbą ir pereina prie kito projekto. Paprastai tai atsitinka, kai darbuotojai atleidžiami iš projekto po pristatymo arba kaip projekto ar etapo uždarymo proceso dalis.

Kiekvieno konkretaus etapo trukmė priklauso nuo komandos dinamikos, dydžio ir lyderystės. Projektų vadovai turi gerai suprasti komandos dinamiką, kad padėtų užtikrinti, kad komandos nariai efektyviai pereitų per visus etapus.

Yra penki pagrindiniai konfliktų sprendimo būdai.

Kadangi kiekvienas iš jų turi savo paskirtį ir pritaikymą, metodai pateikiami ne tam tikra tvarka:

· Vengimas/vengimas. Nukrypimas nuo esamos ar galimos konfliktinės situacijos, problemos sprendimo atidėjimas vėlesniam laikui, siekiant geriau pasiruošti jos sprendimui arba perduoti jos sprendimą kitiems.

· Išlyginimas/apgyvendinimas. Sutarimo taškų, o ne prieštaravimų, akcentavimas, savo pozicijos atsisakymas kitų poreikių naudai, siekiant išlaikyti harmoniją ir santykius.

· Kompromisas/atsiskaitymas. Rasti sprendimus, kurie kažkiek tenkintų visas šalis, siekiant laikinai arba iš dalies išspręsti konfliktą.

· Prievarta/nurodymai. Lobizmas dėl savo požiūrio kitų sąskaita, siūlo tik vieno laimėjimo, visų nuostolių sprendimus, dažniausiai iš galios pozicijų, siekiant išspręsti kritinę situaciją.

· Bendradarbiavimas / problemų sprendimas. Kelių požiūrių ir požiūrių iš skirtingų perspektyvų sujungimas, noro bendradarbiauti ir atviro dialogo poreikis, dėl kurio dažniausiai visos šalys sutaria ir palaiko sprendimą.

Tarpasmeninio bendravimo įgūdžių pavyzdžiai Dažniausiai projektų vadovas naudojasi:

· Vadovavimas. Projekto sėkmei reikalingi išlavinti lyderystės įgūdžiai. Lyderystė yra svarbi visuose projekto gyvavimo ciklo etapuose. Yra daug lyderystės teorijų, apibrėžiančių vadovavimo stilius, kuriuos kiekviena komanda turėtų naudoti, kai tinkama atitinkamoje situacijoje. Ypač svarbu komandos nariams perteikti bendrą projekto viziją ir įkvėpti juos siekti aukšto darbo efektyvumo ir efektyvumo.

· Įtaka. Kadangi projektų vadovai dažnai turi mažai arba visai neturi tiesioginės valdžios savo komandos nariams matricos nustatymuose, jų gebėjimas laiku paveikti projekto suinteresuotąsias šalis yra labai svarbus projekto sėkmei. Pagrindiniai įtakos įgūdžiai apima:

o gebėjimas įtikinamai ir aiškiai reikšti požiūrį ir poziciją;

o aukštas aktyvaus ir efektyvaus klausymosi įgūdžių lygis;

o suprasti ir atsižvelgti į skirtingas perspektyvas bet kurioje situacijoje;

o Esminės ir kritinės informacijos rinkimas svarbioms problemoms spręsti ir susitarimams pasiekti išlaikant abipusį pasitikėjimą.

· Efektyvus sprendimų priėmimas. Tai apima gebėjimą derėtis ir daryti įtaką organizacijai bei projekto valdymo komandai. Toliau pateikiamos kelios gairės, kaip priimti sprendimus:

o būtina orientuotis į siektinus tikslus;

o būtina laikytis sprendimo priėmimo tvarkos;

o būtina tirti aplinkos veiksnius;

o būtina išanalizuoti turimą informaciją;

o būtina ugdyti asmenines komandos narių savybes;

o būtina skatinti kūrybinį komandos požiūrį į darbą;

o Riziką reikia valdyti.

10. PROJEKTŲ KOMUNIKACIJOS VALDYMAS

Projekto komunikacijos valdymas apima procesus, būtinus užtikrinti savalaikį ir tinkamą projekto informacijos planavimą, rinkimą, kūrimą, platinimą, saugojimą, gavimą, valdymą, kontrolę, stebėjimą ir galiausiai archyvavimą/disponavimą. Projektų vadovai didžiąją laiko dalį praleidžia bendraudami su komandos nariais ir kitomis projekto suinteresuotosiomis šalimis, nesvarbu, ar jie yra organizacijos viduje (visuose organizacijos lygiuose), ar išorėje. Veiksminga komunikacija sukuria tiltą tarp skirtingų suinteresuotųjų šalių, kurios gali turėti skirtingą kultūrinį ir organizacinį pagrindą, skirtingus žinių lygius ir skirtingus požiūrius bei interesus, kurie turi įtakos arba gali turėti įtakos projekto veiksmingumui ar rezultatams.

Veiksniai, galintys turėti įtakos komunikacijos technologijų pasirinkimui, yra šie:

· Informacijos gavimo skubumas. Turi būti atsižvelgta į teikiamos informacijos skubumą, dažnumą ir formatą, nes tai gali skirtis įvairiuose projektuose, taip pat skirtinguose to paties projekto etapuose.

· Technologijos prieinamumas. Būtina užtikrinti, kad technologija, reikalinga komunikacijai užtikrinti, būtų suderinama ir prieinama visoms suinteresuotosioms šalims per visą projekto gyvavimo ciklą.

· Naudojimo paprastumas. Būtina užtikrinti, kad pasirinktos komunikacijos technologijos būtų tinkamos projekto dalyviams ir, esant poreikiui, būtų planuojama atitinkama mokymo veikla.

· Projekto aplinka. Būtina nustatyti, ar komanda susitiks ir veiks asmeniškai, ar virtualiai; ar komandos nariai bus vienoje ar keliose laiko juostose; ar jie bendraudami naudos kelias kalbas; ir galiausiai, ar yra kokių nors kitų projekto aplinkos veiksnių, tokių kaip kultūra, kurie gali turėti įtakos komunikacijai.

· Informacijos slaptumas ir konfidencialumas. Būtina nustatyti, ar perduodama informacija yra įslaptinta, ar konfidenciali, ir ar reikia imtis papildomų priemonių jai apsaugoti. Taip pat reikia apsvarstyti tinkamiausią tokios informacijos perdavimo būdą.

Pagrindinis komunikacijos modelis turi tokią veiksmų seką:

· Kodavimas. Siuntėjo vykdomas minčių ar idėjų konvertavimas (kodavimas) į užkoduotą kalbą.

· Siunčia žinutę. Siuntėjo informacijos siuntimas informacijos kanalu (informacijos perdavimo terpe). Įvairūs veiksniai gali trukdyti perduoti šią žinią (pvz., atstumas, nepažįstamos technologijos, nepakankama infrastruktūra, kultūriniai skirtumai ir papildomos informacijos trūkumas). Šie veiksniai bendrai vadinami triukšmu.

· Dekodavimas. Pranešimą gavėjas paverčia prasmingomis mintimis ir idėjomis.

· Patvirtinimas. Gavėjas, gavęs pranešimą, gali išsiųsti signalą (patvirtinimą), kad pranešimas buvo gautas, tačiau tai nebūtinai reiškia sutikimą su pranešimu ar žinutės supratimą.

· Atsiliepimai/atsakymas. Kai gautas pranešimas iššifruojamas ir suprantamas, gavėjas mintis ir idėjas paverčia (užkoduoja) į pranešimą ir perduoda tą pranešimą pirminiam siuntėjui.

Informacijos sklaidai tarp projekto suinteresuotųjų šalių naudojami keli komunikacijos metodai.

Šiuos metodus galima suskirstyti į šias dideles grupes:

· Interaktyvus bendravimas. Tarp dviejų ar daugiau šalių, dalyvaujančių daugiašaliuose informacijos mainuose. Šis metodas yra veiksmingiausias užtikrinant bendrą visų dalyvių supratimą tam tikrais klausimais; tai apima susitikimus, telefono skambučius, momentines žinutes, vaizdo konferencijas ir kt.

· Bendravimas informuojant be prašymo. Informacija siunčiama konkretiems gavėjams, kuriems ją reikia gauti. Šis būdas užtikrina informacijos sklaidą, tačiau negarantuoja, kad ją iš tikrųjų gaus ar supras tikslinė auditorija. Nepageidaujami pranešimai apima laiškus, pastabas, ataskaitas, el. laiškus, faksogramas, balso pašto žinutes, tinklaraščius, pranešimus spaudai ir kt.

· Susisiekimas su informacija pagal pageidavimą. Naudojamas labai dideliam informacijos kiekiui arba labai didelei auditorijai ir reikalauja, kad gavėjai savo nuožiūra pasiektų perduodamą turinį. Tokie metodai apima intraneto svetaines, el. mokymąsi, išmoktų pamokų duomenų bazes, žinių saugyklas ir kt.

Efektyvaus komunikacijos valdymo metodai ir aspektai apima, bet tuo neapsiriboja:

· Siuntėjo-imtuvo modeliai. Įdiekite grįžtamojo ryšio kilpas, kad užtikrintumėte teigiamas sąveikos / dalyvavimo galimybes ir pašalintumėte bendravimo kliūtis.

· Ryšio priemonių parinkimas. Nuo situacijos priklausomi pasirinkimai apima, kada bendrauti žodžiu, o ne raštu, kada rengti neoficialius užrašus, o ne oficialią ataskaitą ir kada kalbėti asmeniškai, o ne el. paštu.

· Rašymo stilius. Aktyvaus ar pasyvaus balso vartojimas, sakinio sandara, žodžių pasirinkimas.

·Susitikimų valdymo metodai. Darbotvarkės rengimas ir konfliktų sprendimas.

· Pristatymo metodai. Kūno kalbos poveikio suvokimas ir vaizdinių priemonių kūrimas.

· Grupinio darbo organizavimo metodai. Pasiekti sutarimą ir įveikti kliūtis.

· Klausymosi technikos. Aktyvus klausymasis (supratimo patvirtinimas, paaiškinimas ir tikrinimas) ir kliūčių, galinčių iškreipti supratimą, pašalinimas.

11. PROJEKTO RIZIKOS VALDYMAS

Projekto rizikos valdymas apima procesus, susijusius su rizikos valdymo planavimo įgyvendinimu, identifikavimu, analize, atsako planavimu ir rizikos valdymu projekte. Projekto rizikos valdymo tikslai yra padidinti palankių įvykių atsiradimo tikimybę ir sustiprinti jų poveikį bei sumažinti nepalankių įvykių tikimybę ir susilpninti nepalankių įvykių poveikį projekto įgyvendinimo metu.

Projekto rizika yra neaiškus įvykis arba sąlyga, kurios įvykis turi neigiamą arba teigiamą poveikį projekto tikslams, tokiems kaip apimtis, tvarkaraštis, kaina ir kokybė. Rizika gali turėti vieną ar daugiau priežasčių ir, jei ji atsiranda, gali turėti įtakos vienam ar keliems aspektams.

Rizikos valdymo planas yra projekto valdymo plano komponentas, kuriame aprašoma, kaip bus struktūrizuota ir vykdoma rizikos valdymo veikla. Rizikos valdymo planą sudaro šie elementai:

· Metodika. Nustatykite metodus, įrankius ir duomenų šaltinius, kurie bus naudojami tam tikro projekto rizikai valdyti.

· Vaidmenys ir pareigos. Nurodykite kiekvienos veiklos, įtrauktos į rizikos valdymo planą, vadovų komandos narius, pagalbinės komandos narius ir rizikos valdymo komandos narius ir paaiškinkite jų pareigas.

· Biudžeto rengimas.Įvertinant reikiamas lėšas, atsižvelgiant į skirtus išteklius, įtraukti į bazinių išlaidų planą ir parengti rezervo galimiems nuostoliams ir valdymo rezervo panaudojimo tvarką.

· Terminų nustatymas. Nustatyti rizikos valdymo procesų laiką ir dažnumą per visą projekto gyvavimo ciklą, parengti tvarkaraščio rezervų panaudojimo galimiems nuostoliams tvarką ir nustatyti rizikos valdymo veiklas, kurios bus įtrauktos į projekto grafiką.

· Rizikos kategorijos. Suteikite galimybę suskirstyti galimus rizikos šaltinius į grupes. Galima naudoti kelis metodus, pvz., struktūrą, pagrįstą projekto tikslais pagal kategorijas. Rizikos hierarchijos sistema (RBS) padeda projekto komandai apsvarstyti daugybę šaltinių, iš kurių gali kilti projekto rizika rizikos nustatymo proceso metu. Įvairių tipų projektai atitinka skirtingas RBS struktūras. Organizacija gali naudoti iš anksto sukurtą rizikos skirstymo į kategorijas schemą, kuri gali būti paprasto kategorijų sąrašo forma arba suformatuota kaip RBS. RBS yra hierarchinis rizikos vaizdavimas pagal rizikos kategorijas.

· Rizikos tikimybės ir poveikio nustatymas. Gera ir patikima rizikos analizė apima skirtingus rizikos tikimybės ir poveikio lygius projekto kontekste. Bendrieji tikimybės lygių ir poveikio lygių apibrėžimai pritaikomi konkrečiam projektui rizikos valdymo planavimo procese ir naudojami tolesniuose procesuose. Žemiau esančioje lentelėje pateikiamas neigiamo poveikio apibrėžimų pavyzdys, kurį galima naudoti rizikos, susijusios su keturiais projekto tikslais, poveikiui įvertinti (teigiamam poveikiui galima sukurti panašias lenteles). Toliau pateiktoje lentelėje parodytas ir santykinis, ir skaitinis (šiuo atveju netiesinis) metodai.

· Tikimybių ir poveikio matrica. Tikimybių ir poveikio matrica yra lentelė, rodanti kiekvienos rizikos atsiradimo tikimybę ir jos poveikį projekto tikslams, jei ji atsiranda. Rizika yra suskirstyta į prioritetus, atsižvelgiant į galimas jų pasekmes, kurios gali turėti įtakos projekto tikslams. Tipiškas prioritetų nustatymo būdas yra atitikties lentelės arba tikimybių ir poveikio matricos naudojimas. Paprastai pati organizacija nustato tikimybės ir poveikio derinius, kuriais remiantis nustatomas rizikos lygis „aukštas“, „vidutinis“ arba „žemas“.

· Išaiškinta suinteresuotųjų šalių tolerancija. Rizikos valdymo planavimo proceso metu suinteresuotųjų šalių tolerancijos gali būti koreguojamos, kad atitiktų konkretų projektą.

· Ataskaitų formatai. Ataskaitų teikimo formatai nustato, kaip bus dokumentuojami, analizuojami ir perduodami rizikos valdymo proceso rezultatai. Ataskaitų teikimo formatuose aprašomas rizikos registro turinys ir formatas, taip pat visos kitos privalomos rizikos ataskaitos.

· Stebėjimas. Stebėjimo dokumentai, kaip registruojama visa su rizika susijusi veikla tam tikro projekto tikslais, kada ir kaip bus audituojami rizikos valdymo procesai.

Diagramos metodai

Rizikos diagramos metodai apima:

· Priežasties ir pasekmės diagramos.Šios diagramos, taip pat žinomos kaip Ishikawa diagramos arba žuvų kaulų diagramos, naudojamos siekiant nustatyti, kodėl kyla rizika.

· Proceso ar sistemos schemos.Šio tipo grafinis ekranas parodo įvairių sistemos elementų tarpusavio sąveikos tvarką ir jų priežasties-pasekmės ryšius.

· Poveikio diagramos. Grafinis situacijų vaizdavimas, rodantis priežasties ir pasekmės ryšius, įvykių sekas laikui bėgant ir kitus ryšius tarp kintamųjų ir rezultatų.

SSGG analizė

Šis metodas leidžia analizuoti projektą kiekvieno aspekto požiūriu: stiprybės, silpnybės, galimybės ir grėsmės (stiprybės, silpnybės, galimybės ir grėsmės, SSGG), todėl rizikos identifikavimas yra išsamesnis, atsižvelgiant į atsižvelgti į riziką projekte. Naudojant šį metodą, pirmiausia reikia nustatyti organizacijos stipriąsias ir silpnąsias puses, sutelkiant dėmesį į projektą, organizaciją arba visą verslo sritį. Tada SSGG analizė nustato bet kokias projekto galimybes, kylančias iš organizacijos stipriųjų pusių, taip pat visas grėsmes, kylančias iš jos silpnybių. Šioje analizėje taip pat nagrinėjama, kaip organizacijos privalumai atsveria grėsmes, ir nustatomos galimybės, kurias galima išnaudoti siekiant įveikti trūkumus.

Rizikos registras

Pagrindinis rizikos nustatymo proceso rezultatas yra pradinis įrašas į rizikos registrą. Rizikos registras – dokumentas, kuriame pateikiami rizikos analizės ir atsako į riziką planavimo rezultatai. Rizikos registras fiksuoja kitų rizikos valdymo procesų rezultatus, kai jie vyksta, todėl laikui bėgant rizikos registre esančios informacijos lygis ir įvairovė didėja. Rizikos registro rengimas prasideda rizikos identifikavimo procesu, kurio metu registras užpildomas žemiau nurodyta informacija. Tada ši informacija yra prieinama kitiems su projekto valdymu ir rizikos valdymu susijusiems procesams.

· Nustatytų pavojų sąrašas. Nustatytos rizikos aprašytos pakankamai išsamiai. Šiame sąraše rizikai apibūdinti gali būti naudojama specifinė struktūra, pavyzdžiui: gali įvykti ĮVYKIS, kuris turės POVEIKĮ, arba, jei yra PRIEŽASTIS, gali įvykti ĮVYKIS, kuris turės POVEIKĮ. Be to, sudarius nustatytų rizikų sąrašą, pagrindinės tos rizikos priežastys gali tapti aiškesnės. Tai yra pagrindinės sąlygos arba įvykiai, galintys sukelti vieną ar daugiau nustatytų pavojų. Jie turėtų būti registruojami ir naudojami siekiant padėti ateityje nustatyti šio ir kitų projektų riziką.

· Galimų atsakymų sąrašas. Kartais rizikos nustatymo procesas gali nustatyti galimus atsakymus į jas. Tokie atsakymai, jei jie nustatomi šio proceso metu, turėtų būti įvesti į atsako į riziką planavimo procesą.

Kokybinė rizikos analizė- rizikos prioritetų nustatymo procesas tolesnei analizei arba veiksmui, atliekamas įvertinant ir lyginant jų poveikį ir atsiradimo tikimybę. Pagrindinis šio proceso pranašumas yra tai, kad jis leidžia projektų vadovams sumažinti netikrumą ir sutelkti dėmesį į aukšto prioriteto riziką.

Kiekybinė rizikos analizė- nustatytos rizikos poveikio viso projekto tikslams skaitinės analizės procesas. Pagrindinis šio proceso pranašumas yra tas, kad jame pateikiama kiekybinė rizikos informacija, padedanti priimti sprendimų priėmimo procesą ir sumažinti projekto neapibrėžtumą.

Informacijos rinkimo ir pateikimo metodai

· Interviu vedimas. Interviu metodai suteikia patirties ir istorinių duomenų, leidžiančių kiekybiškai įvertinti rizikos tikimybę ir poveikį projekto tikslams. Reikalinga informacija priklauso nuo naudojamo tikimybių skirstinio tipo. Pavyzdžiui, kai kuriems iš plačiausiai naudojamų pasiskirstymo modelių būtina rinkti informaciją apie optimistinį (maža tikimybė), pesimistinį (didelė tikimybė) ir labiausiai tikėtiną scenarijų. Rizikos diapazonų ir susijusių prielaidų pagrindimo dokumentavimas yra svarbus rizikos pokalbių elementas, nes šie dokumentai leidžia daryti išvadas apie analizės patikimumą ir pagrįstumą.

· Tikimybių skirstinys. Nuolatiniai tikimybių skirstiniai, plačiai naudojami modeliuojant ir modeliuojant, rodo neapibrėžtas reikšmes, tokias kaip grafiko veiklos trukmė ir projekto komponentų išlaidos. Diskretūs skirstiniai gali būti naudojami neaiškiems įvykiams, pvz., bandymo rezultatams arba galimiems sprendimų medžio scenarijams, pavaizduoti. Fig. Žemiau pateikiami du plačiai naudojamų nuolatinių paskirstymų pavyzdžiai. Tokie pasiskirstymai apibūdina modelius, kurie derinami su duomenimis, paprastai gaunamais iš kiekybinės rizikos analizės. Vienodus skirstinius galima naudoti tais atvejais, kai nėra akivaizdžios vertės, kuri labiau nei kitos galėtų patekti tarp nurodytų viršutinių ir apatinių ribų, pvz., projektavimo pradžioje.

Kiekybinės analizės ir rizikos modeliavimo metodai

Plačiai naudojami metodai analizei naudoja ir į įvykius, ir į projektus orientuotus metodus, įskaitant:

· Jautrumo analizė. Jautrumo analizė padeda nustatyti rizikas, turinčias didžiausią įmanomą poveikį projektui. Tai padeda suprasti, kaip projekto tikslų skirtumai koreliuoja su įvairių neapibrėžtumų skirtumais. Kita vertus, jis nustato, kiek kiekvieno dizaino elemento neapibrėžtumas veikia tiriamą tikslą, o visi kiti neapibrėžti elementai yra savo bazinėse vertėse. Vienas tipiškas jautrumo analizės atvaizdavimo būdas yra tornado diagrama (paveikslas žemiau), kuri yra naudinga lyginant santykinę kintamųjų, kurie turi didelį neapibrėžtumo laipsnį, svarbą ir poveikį su kitais, stabilesniais kintamaisiais. Tornado diagrama taip pat naudinga analizuojant rizikos prisiėmimo scenarijus, taikomus konkrečiai rizikai, kurių kiekybinė analizė rodo, kad galima nauda yra didesnė už atitinkamą nustatytą neigiamą poveikį. Tornado diagrama yra specialaus tipo juostinė diagrama, naudojama jautrumo analizei palyginti santykinę kintamųjų svarbą. Tornado diagramoje y ašis yra kiekvienos rūšies neapibrėžtumas pagrindinėse reikšmėse, o x ašis yra neapibrėžtumo apie tiriamą išvestį sklaida arba koreliacija. Šiame paveikslėlyje kiekviena neapibrėžtis turi horizontalią juostą (liniją), o vertikalioje – neapibrėžtis, kurių sklaida mažėja nuo bazinių verčių

· Numatomos piniginės vertės analizė. Tikėtinos piniginės vertės (EMV) analizė yra statistinis metodas, apskaičiuojantis vidutinį rezultatą, kai yra ateities scenarijų, kurie gali įvykti arba neįvykti (t. y. analizė neapibrėžtumo sąlygomis). Galimybių EMV paprastai išreiškiamas teigiamais terminais, o grėsmių EMV – neigiama. EMV reikalauja rizikos atžvilgiu neutralios prielaidos – nei tokios, kuri apima pernelyg didelę riziką, nei tokios, kuri ją visiškai atmeta. Norėdami apskaičiuoti projekto EMV, padauginkite kiekvieno galimo rezultato vertę iš jo atsiradimo tikimybės, o tada sudėkite gautas reikšmes. Paprastai tokio tipo analizė naudojama sprendimų medžio analizės forma.

· Modeliavimas ir modeliavimas. Projekto modeliavimas naudoja modelį, kad nustatytų galimą detalių neapibrėžčių poveikį projekto tikslams. Modeliavimas dažniausiai atliekamas Monte Karlo metodu. Modeliuojant projekto modelis skaičiuojamas daug kartų (iteratyviai), kiekvienai iteracijai turint įvesties reikšmes (pavyzdžiui, sąnaudų ar veiklos trukmės įvertinimus), atsitiktinai parinktas iš šių kintamųjų tikimybių skirstinių. Iteracijų metu apskaičiuojama histograma (pavyzdžiui, bendra kaina arba užbaigimo data). Sąnaudų rizikos analizė, naudojant modeliavimo metodą, naudoja sąnaudų sąmatas. Tvarkaraščio rizikos analizė naudoja tvarkaraščio tinklo diagramą ir trukmės įvertinimus. Vertės rizikos modeliavimo, naudojant trijų elementų modelį ir rizikos diapazonus, rezultatas parodytas Fig. žemiau. Paveiksle parodyta atitinkama tikimybė pasiekti tam tikrus išlaidų tikslus. Panašios kreivės gali būti sukurtos kitiems projektavimo tikslams.

Reagavimo į neigiamą riziką (grėsmės) strategijos

· Išsiskyrimas. Rizikos vengimas – tai reagavimo į riziką strategija, kai projekto komanda veikia siekdama pašalinti grėsmę arba apsaugoti projektą nuo jos poveikio. Paprastai tai apima projekto valdymo plano pakeitimą taip, kad grėsmė būtų visiškai pašalinta. Projekto vadovas taip pat gali apsaugoti projekto tikslus nuo rizikos arba pakeisti tikslą, kuriam gresia pavojus (pavyzdžiui, išplėsti tvarkaraštį, pakeisti strategiją ar sumažinti apimtį). Drastiškiausia vengimo strategija yra visiškai nutraukti projektą. Kai kurių rizikų, kylančių projekto pradžioje, galima išvengti patikslinus reikalavimus, gavus informaciją, gerinant komunikaciją ar įgyjant patirties.

· Transliacija. Rizikos perkėlimas – tai reagavimo į riziką strategija, pagal kurią projekto komanda grėsmės pasekmes kartu su atsakomybe už atsaką perduoda trečiajai šaliai. Perdavus riziką, atsakomybė už jos valdymą pereina kitai šaliai; tai nepanaikina rizikos. Rizikos perdavimas nereiškia atsakomybės už ją atsisakymo, perduodant ją būsimam projektui ar kitam asmeniui pastarojo neinformavus ar nesudarius su juo sutarties. Rizikos perkėlimas beveik visada apima rizikos priemokos sumokėjimą šaliai, kuri prisiima riziką. Atsakomybės už riziką perdavimas yra efektyviausias finansinėms rizikoms. Perdavimo priemonės gali būti gana įvairios ir apima, bet neapsiriboja: draudimu, įsipareigojimų vykdymo užtikrinimu, įsipareigojimų įvykdymo užtikrinimu ir kt. Sutartys arba susitarimai gali būti naudojami atsakomybės už tam tikrą riziką perkėlimui kitai šaliai. Pavyzdžiui, kai pirkėjas turi galimybių, kurių neturi pardavėjas, gali būti tikslinga grąžinti pirkėjui kai kuriuos darbus ir su tuo susijusią riziką. Daugeliu atvejų kompensuojamoje sutartyje išlaidų rizika gali būti perkelta pirkėjui, o pagal fiksuotos kainos sutartį rizika gali būti perkelta pardavėjui.

· Atmesti. Rizikos mažinimas – tai reagavimo į riziką strategija, kurios metu projekto komanda veikia siekdama sumažinti rizikos atsiradimo ar poveikio tikimybę. Tai apima neigiamos rizikos tikimybės ir (arba) poveikio sumažinimą iki priimtinų slenksčių. Ankstyvieji veiksmai, siekiant sumažinti rizikos atsiradimo tikimybę ir (arba) jos poveikį projekto eigoje, dažnai yra veiksmingesni nei ištaisymo pastangos, kurių imamasi po rizikos. Rizikos mažinimo veiksmų pavyzdžiai yra mažiau sudėtingų procesų įgyvendinimas, daugiau bandymų arba patikimesnio tiekėjo pasirinkimas. Sumažinti taip pat gali prireikti sukurti prototipą, kad būtų sumažinta proceso ar produkto mastelio mažinimo rizika, palyginti su stendo modeliu. Jei tikimybės sumažinti neįmanoma, rizikos mažinimo veiksmai turėtų būti nukreipti į rizikos poveikį, būtent į tuos ryšius, kurie lemia poveikio sunkumą. Pavyzdžiui, projektuojant sistemos dubliavimą, galima sumažinti pradinio elemento gedimo pasekmių sunkumą.

· Įvaikinimas. Rizikos priėmimas – tai reagavimo į riziką strategija, kai projekto komanda nusprendžia prisiimti riziką ir nesiimti jokių veiksmų, kol rizika nepasireikš. Ši strategija naudojama, jei bet koks kitas būdas reaguoti į tam tikrą riziką yra neįmanomas arba ekonomiškas. Tai rodo, kad projekto komanda nusprendė nekeisti projekto valdymo plano, kad būtų pašalinta rizika, arba negali nustatyti kitos tinkamos reagavimo strategijos. Ši strategija gali būti pasyvi arba aktyvi. Pasyviam priėmimui nereikia jokių kitų veiksmų, išskyrus strategijos dokumentavimą – projekto komanda turės susidoroti su rizika, kai ji atsiranda, ir periodiškai peržiūrėti grėsmę, kad įsitikintų, jog ji reikšmingai nepasikeitė. Dažniausia aktyvaus priėmimo strategija yra sukurti nuostolių rezervą, apimantį konkrečias laiko, pinigų ar išteklių sumas, reikalingas rizikai valdyti.

Reagavimo į teigiamą riziką strategijos (galimybės)

· Naudojimas. Galima pasirinkti išnaudojimo strategiją, kad būtų galima reaguoti į riziką, turinčią teigiamą poveikį, jei organizacijai reikia užtikrinti, kad galimybė būtų įgyvendinta. Ši strategija sukurta siekiant pašalinti neapibrėžtumą, susijusį su konkrečia teigiama rizika, taikant priemones, užtikrinančias, kad galimybė bus įgyvendinta. Tiesioginio naudojimo atsakymai apima geriausių organizacijos talentų įtraukimą į projektą, kad sutrumpėtų projektui užbaigti reikalingas laikas, arba naujų ar atnaujintų technologijų naudojimas siekiant sumažinti išlaidas ir laiką, reikalingą projekto tikslams pasiekti.

· Padidinti. Tobulinimo strategija naudojama siekiant padidinti galimybės tikimybę ir (arba) teigiamą poveikį. Nustačius ir maksimaliai padidinus pagrindinius veiksnius, kurie prisideda prie šios teigiamo poveikio rizikos atsiradimo, gali padidėti jų atsiradimo tikimybė. Galimybių tobulinimo pavyzdžiai apima papildomų išteklių skyrimą operacijai, siekiant ją užbaigti anksti.

· Atskyrimas. Teigiamas rizikos pasidalijimas apima dalies arba visos atsakomybės už galimybę perdavimą trečiajai šaliai, kuri gali geriausiai pasinaudoti galimybe gauti naudos projektui. Dalijimosi veikla apima rizikos pasidalijimo partnerysčių, komandų, specialios paskirties įmonių ar bendrų įmonių kūrimą, kurios gali būti steigiamos siekiant aiškaus visų šalių, besinaudojančių šia galimybe, tikslo.

· Įvaikinimas. Galimybės priėmimas – tai noras pasinaudoti galimybe, kai ji atsiranda, jos aktyviai nesinaudojant.

12. PROJEKTŲ PIRKIMŲ VALDYMAS

Projekto pirkimų valdymas apima produktų, paslaugų ar produktų, reikalingų projektui vykdyti, pirkimo ar įsigijimo procesus, nepriklausančius projekto komandai. Organizacija gali veikti kaip produktų, paslaugų ar projekto rezultatų pirkėja ir pardavėja.

Projekto pirkimų valdymas apima sutarčių valdymo procesus ir pakeitimų kontrolės procesus, reikalingus įgaliotų projekto komandos narių parengtoms sutartims ar pirkimo užsakymams sudaryti ir administruoti.

Sutarčių rūšys

· Fiksuotos kainos sutartys.Šio tipo sutartyse numatoma bendra fiksuota pristatyto produkto, paslaugos ar rezultato kaina. Fiksuotų kainų sutartyse taip pat gali būti numatytos finansinės paskatos tam tikriems nurodytiems projekto tikslams pasiekti arba tobulinti, pvz., suplanuotoms pristatymo datoms, techniniams ir išlaidų rezultatams arba kitiems kiekybiniams ir vėliau išmatuojamiems rodikliams. Pagal fiksuotos kainos sutartis pardavėjai yra teisiškai įpareigoti vykdyti tokias sutartis arba patirti galimus finansinius nuostolius, jei jie neįvykdys. Pirkėjai, vadovaudamiesi tokių sutarčių nuostatomis, privalo tiksliai identifikuoti perkamą prekę ar paslaugą. Turinys gali pasikeisti, bet dažniausiai dėl to sutarties kaina padidės.

o Fiksuotos kainos sutartys (FFP). Plačiausiai naudojamas sutarčių tipas yra FFP. Dauguma perkančiųjų organizacijų teikia pirmenybę tokio tipo sutartims, nes prekių kaina nustatoma pačioje pradžioje ir negali keistis, nebent pasikeistų darbo turinys. Bet koks išlaidų padidėjimas, atsiradęs dėl neigiamų rezultatų, yra pardavėjo pareiga užbaigti darbą. Pagal FFP pirkėjas privalo tiksliai nurodyti perkamą prekę ar paslaugas, o bet kokie pirkimo specifikacijos pakeitimai gali padidinti pirkėjo išlaidas.

o Fiksuotų kainų skatinimo mokesčių sutartys (FPIF). Šis fiksuotos kainos susitarimas suteikia pirkėjui ir pardavėjui tam tikro lankstumo, nes leidžia našumo skirtumams ir suteikia finansinių paskatų pasiekti sutartus rodiklius. Paprastai tokios finansinės paskatos yra susietos su kaina, tvarkaraščiu arba pardavėjo techniniais rezultatais. Tiksliniai veiklos rodikliai nustatomi pradžioje, o galutinė sutarties kaina nustatoma atlikus visus darbus, priklausomai nuo jų atlikimo pardavėjo. Pagal FPIF nustatomos kainos lubos, o už visas išlaidas, viršijančias viršutines kainos ribas, tenka pardavėjui, kuris privalo atlikti darbus.

o Sutartys su fiksuota kaina ir sąlyga dėl galimo kainos koregavimo (Fiksuota kaina su ekonominiu kainų koregavimu, FP-EPA). Ši sutarties rūšis naudojama, jei pardavėjo sutarties įvykdymas pratęsiamas per reikšmingą laikotarpį, kurio dažniausiai siekiama ilgalaikiuose santykiuose. Sutartis su fiksuota kaina, bet su specialia nuostata, leidžiančia iš anksto galutinai pakoreguoti sutarties kainą dėl pasikeitusių sąlygų, tokių kaip infliacija arba tam tikrų prekių kainų padidėjimas ar sumažėjimas. Kainos koregavimo sąlyga turi būti susieta su patikimu finansiniu indeksu, naudojamu galutinei kainai tiksliai pakoreguoti. FP-EPA sukurta siekiant apsaugoti pirkėją ir pardavėją nuo išorinių sąlygų, kurių jie negali kontroliuoti.

· Išlaidas kompensuojamos sutartys.Šios rūšies sutartys apima visų teisėtų faktinių išlaidų, patirtų dėl darbų atlikimo, apmokėjimą (kompensavimą) pardavėjui ir atlygį, kuris sudaro jo pelną. Išlaidomis kompensuojamose sutartyse dažnai yra nuostatos, skatinančios viršyti arba pagerinti projekto veiklos tikslus (pavyzdžiui, išlaidas, tvarkaraštį ar techninius rezultatus). Trys dažniausiai pasitaikantys išlaidų kompensavimo sutarčių tipai yra šie: Cost Plus Fixed Fee Contract (CPFF), Cost Plus Incentive Fee Contract (CPIF), Cost Plus Fixed Fee Contract (CPIF), Cost Plus Fixed Fee Contract (CPIF) ir Cost Plus. Fiksuoto mokesčio sutartis (CPIF) (Cost Plus Award Fee Contract, CPAF). Išlaidomis kompensuojama sutartis suteikia projekto lankstumo, nes leidžia keisti pardavėjo nurodymus, jei iš pradžių negalima tiksliai apibūdinti darbų apimties ir ją reikia koreguoti arba darbų metu kyla didelė rizika.

o Išlaidų plius fiksuoto mokesčio (CPFF) sutartys. Pardavėjui kompensuojamos visos sutartos darbų atlikimo pagal sutartį išlaidos, taip pat sumokamas fiksuotas mokestis, lygus tam tikram procentui nuo pradinės numatomos projekto kainos. Atlyginimas mokamas tik už atliktus darbus ir nesikeičia priklausomai nuo pardavėjo veiklos. Atlyginimo dydžiai nesikeičia, nebent pasikeistų projekto turinys.

o Cost Plus Incentive Fee (CPIF) sutartys. Pardavėjui atlyginamos visos sutartos sutartyje numatytos darbų atlikimo išlaidos, taip pat iš anksto nustatytas skatinamasis mokestis už konkrečių sutartyje nurodytų veiklos rodiklių pasiekimą. CPIF sutartyse numatyta, kad jei galutinės išlaidos yra didesnės ar mažesnės už pradinę apskaičiuotą kainą, sutaupytos lėšos / perteklinės išlaidos paskirstomos tarp pardavėjo ir pirkėjo iš anksto sutartu santykiu, pavyzdžiui, santykiu 80/20 sumos. skirtumą tarp planuojamų išlaidų ir realių pardavėjo veiklos rezultatų.

o Cost Plus Premium Fee (CPAF) sutartys. Pardavėjui kompensuojamos visos pagrįstos išlaidos, tačiau didžioji dalis kompensacijų išmokama tik atsižvelgiant į daugelio plačiai interpretuojamų subjektyvių sutartyje apibrėžtų vykdymo kriterijų įvykdymą. Atlyginimo nustatymas grindžiamas tik subjektyviu pirkėjo vertinimu, kaip pardavėjas įvykdė sutartį, ir paprastai neskundžiamas.

· Laiko ir medžiagų sutartys(Laiko ir medžiagų sutartys, T&M). Laiko ir medžiagų sutartys yra mišrios rūšies sutartiniai susitarimai, kuriuose yra nuostatos dėl išlaidų kompensuojamų ir fiksuotų kainų sutarčių. Jie dažnai naudojami personalo papildymui, ekspertų samdymui ir bet kokiai trečiųjų šalių pagalbai tais atvejais, kai neįmanoma greitai sukurti tikslaus darbo aprašymo. Šios sutarčių rūšys yra panašios į išlaidas kompensuojamas sutartis, nes jos leidžia keisti ir padidinti pirkėjo išlaidas. Pirkėjas sutarties sudarymo metu negali nurodyti bendros sutarties kainos ir tikslaus tiekiamų prekių skaičiaus. Taigi T&M sutarčių kaina gali padidėti, kaip ir kompensuojamų sutarčių atveju. Siekdamos išvengti neriboto išlaidų padidėjimo, daugelis organizacijų reikalauja, kad visose T&M sutartyse būtų nurodytos kainos ir terminų limitai. Kita vertus, T&M sutartys gali priminti ir fiksuotos kainos susitarimus, kai sutartyje yra nurodyti tam tikri parametrai. Dėl darbo valandų įkainių arba medžiagų sąnaudų, įskaitant pardavėjo pelną, pirkėjas ir pardavėjas gali susitarti iš anksto, jei abi šalys susitaria dėl tam tikrų kategorijų sąnaudų, pvz., tam tikro valandinio įkainio vyriausiiesiems inžinieriams ar tam tikra kaina už medžiagos vienetą.

13. PROJEKTO SUINTERESUOTŲJŲ ŠALIŲ VALDYMAS

Projekto suinteresuotųjų šalių valdymas apima procesus, reikalingus siekiant nustatyti žmones, grupes ir organizacijas, kurios gali turėti įtakos projektui arba būti jo paveiktos, analizuoti suinteresuotųjų šalių lūkesčius ir jų poveikį projektui bei sukurti tinkamas valdymo strategijas, skirtas veiksmingai įtraukti suinteresuotąsias šalis priimant sprendimus ir projekto vykdymas. Suinteresuotųjų šalių valdymas taip pat sutelkia dėmesį į nuolatinį bendravimą su suinteresuotosiomis šalimis siekiant suprasti jų poreikius ir lūkesčius, reaguoti į iškilusias problemas, valdyti prieštaringus interesus ir skatinti tinkamą suinteresuotųjų šalių įtraukimą į sprendimų priėmimą ir projekto veiklą. Suinteresuotųjų šalių pasitenkinimas turėtų būti vienas iš pagrindinių projekto tikslų.

Atliekant suinteresuotųjų šalių analizę, naudojami įvairūs klasifikavimo modeliai, tokie kaip:

· galios/interesų matrica, suinteresuotųjų šalių grupavimas pagal jų autoritetą („galią“) ir suinteresuotumo lygį („susidomėjimas“) projekto rezultatais;

· galios/įtakos matrica, grupuojant suinteresuotąsias šalis pagal jų autoritetą („galią“) ir aktyvų dalyvavimą („įtaka“) projekte;

· įtakos / poveikio matrica, suinteresuotųjų šalių grupavimas pagal jų aktyvų dalyvavimą ("įtaką") projekte ir jų gebėjimą pakeisti projekto planavimą ar vykdymą ("poveikis");

· funkcijų modelis, kuriame apibūdinamos suinteresuotųjų šalių klasės, atsižvelgiant į jų galios lygį (jų gebėjimą primesti savo valią), skubumą (neatidėliotinų veiksmų poreikį) ir teisėtumą (jų dalyvavimas yra tinkamas).

Suinteresuotųjų šalių dalyvavimo lygiai gali būti klasifikuojami taip:

· Neinformuotas. Suinteresuota šalis nežino apie projektą ir galimą poveikį.

· Priešinasi. Suinteresuota šalis žino apie projektą ir galimą poveikį ir yra atspari pokyčiams.

· Neutralus. Suinteresuota šalis žino apie projektą, bet nepalaiko pokyčių ir jiems nesipriešina.

· Palaikantis. Suinteresuota šalis žino apie projektą, galimą poveikį ir palaiko pokyčius.

· Pirmaujantis. Suinteresuota šalis žino apie projektą, galimą poveikį ir aktyviai dalyvauja užtikrinant projekto sėkmę.

Pagrindinis suinteresuotųjų šalių identifikavimo proceso rezultatas yra suinteresuotųjų šalių registras. Jame pateikiama visa informacija, susijusi su nustatytomis suinteresuotosiomis šalimis, įskaitant, bet tuo neapsiribojant:

· Identifikavimo informacija: Vardas, pavardė, pareigos organizacijoje, vieta, vaidmuo projekte, kontaktinė informacija.

· Vertinimo informacija: pagrindiniai reikalavimai ir lūkesčiai, galimas poveikis projekte, įdomiausias projekto gyvavimo ciklo etapas.

· Suinteresuotųjų šalių klasifikacija: vidinė/išorinė, palaikanti/neutrali/atspari ir kt.

Be duomenų iš suinteresuotųjų šalių registro, suinteresuotųjų šalių valdymo plane dažnai taip pat bus:

· pageidaujamas ir esamas pagrindinių suinteresuotųjų šalių įtraukimo lygis;

· pakeitimo apimtis ir poveikis suinteresuotosioms šalims;

· nustatyti ryšiai ir galimas suinteresuotųjų šalių susikirtimas;

· suinteresuotųjų šalių reikalavimai komunikacijai dabartiniame projekto etape;

· informacija apie suinteresuotosioms šalims platinamą informaciją, įskaitant kalbą, formatą, turinį ir išsamumo lygį;

· šios informacijos skleidimo priežastis ir numatomas poveikis suinteresuotųjų šalių įtraukimo lygiui;

· reikiamos informacijos skleidimo suinteresuotoms šalims laikas ir dažnumas;

· Suinteresuotųjų šalių valdymo plano atnaujinimo ir tobulinimo metodas projektui progresuojant ir vystantis.

Projektų valdymo žinių įstaigos vadovas (PMBOK vadovas)

Kongreso bibliotekos bibliografinis įrašas

Pavadinimai: Projektų valdymo institutas (PMI), leidėjas.

Pavadinimas: Projektų valdymo žinių vadovas (PMBOK vadovas) / Projektų valdymo institutas.

Kiti pavadinimai: PMBOK vadovas

Aprašymas: Šeštasis leidimas | Newtown Square, PA: Projektų valdymo institutas, 2017. | Serija: PMBOK vadovas |

Identifikatoriai: LCCN 2017032505 (spausdinti) | LCCN 2017035597 (el. knyga) | ISBN 9781628253900 (ePUP) |

ISBN 9781628253917 (Kindle) | ISBN 9781628253924 (interneto PDF) | ISBN 9781628251845 (minkštas viršelis)

Tema: LCSH: Projektų valdymas. | BISAC: VERSLAS IR EKONOMIKA / Projektų valdymas (BUSINESS & ECONOMICS / Projektų valdymas).

Klasifikacija: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (spausdinti) | DDC 658.4/04-dc23

LC įrašą galima rasti adresu https://lccn.loc.gov/2017032505

Projektų valdymo institutas, Inc.

14 Campus Boulevard

Newtown Square, Pensilvanija 19073-3299 JAV

Telefonas: +1 610-356-4600

Faksas: +1 610-356-4647

El. paštas Paštas: [apsaugotas el. paštas]

Svetainė: https://www.PMI.org

Medžiaga iš Project Management Institute, Inc. yra saugomi autorių teisių pagal JAV intelektinės nuosavybės įstatymą, kuris pripažįstamas daugumoje šalių. Norėdami iš naujo publikuoti arba atkurti PMI medžiagą, turite gauti mūsų leidimą. Norėdami gauti daugiau informacijos, apsilankykite http://www.pmi.org/permissions_for_details.

Norėdami pateikti prekybos užsakymą arba gauti informacijos apie kainas, susisiekite su Independent Publishers Group:

Nepriklausomų leidėjų grupė

Užsakymų skyrius

814 North Franklin Street

Chicago, IL 60610 JAV

Telefonas: +1 800-888-4741

Faksas: +1 312-337-5985

El. paštas Paštas: [apsaugotas el. paštas](tik užsakymams)

Visais kitais klausimais kreipkitės į PMI knygų aptarnavimo centrą.

PMI knygų aptarnavimo centras

P.O. Box 932683, Atlanta, GA 31193-2683 USA

Telefonas: 1-866-276-4764 (JAV arba Kanada) arba +1-770-280-4129 (visame pasaulyje)

Faksas: +1-770-280-4113

El. paštas Paštas: [apsaugotas el. paštas]

Išspausdinta Jungtinėse Amerikos Valstijose Be išankstinio leidėjo leidimo jokia šio leidinio dalis negali būti atgaminta ar perduota jokia forma ir bet kokiomis priemonėmis, elektroniniu, rankiniu būdu, kopijavimu, įrašymu ar bet kokia informacijos saugojimo ir paieškos sistema.

PMI, PMI logotipas, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJEKTŲ VALDYMO ŽURNALAS, PM TINKLAS, PMI ŠIANDIEN, PROFESIJOS PULSAS ir KŪRIMO šūkis VERSLO REZULTATAMS BŪTINAS PROJEKTŲ VALDYMAS.

yra Project Management Institute, Inc. prekių ženklai. Norėdami gauti visą PMI prekių ženklų sąrašą, susisiekite su PMI Legal. Visi kiti čia esantys prekių ženklai, paslaugų ženklai, prekių pavadinimai, prekės apranga, produktų pavadinimai ir logotipai yra atitinkamų savininkų nuosavybė. Visos teisės, kurios nėra aiškiai suteiktos čia, pasilieka autorių teisių savininkui.

Visos teisės saugomos. Visą knygą ar jos dalį bet kokia forma atgaminti be raštiško leidėjo leidimo draudžiama.

© Autorių teisės 2017 Project Management Institute, Inc. Visos teisės saugomos.

© Vertimas į rusų kalbą, leidinys, dizainas Olympus – verslo leidykla, 2018 m

Pranešimas

Projektų valdymo instituto, Inc. (sutrumpintai PMI) paskelbti standartai ir gairės, įskaitant šį dokumentą, yra parengti standartų kūrimo procesu, pagrįstu savanorišku dalyvavimu ir bendru sutarimu. Šiame procese sujungiamos savanorių pastangos ir (arba) sujungiamos publikacijoje aptariama tema besidominčių asmenų pastabos ir nuomonės. Nors PMI administruoja procesą ir nustato taisykles, užtikrinančias nešališkumą siekiant sutarimo, PMI nerašo dokumento ir savarankiškai netikrina, neįvertina ar netikrina PMI išleistuose standartuose ir gairėse pateiktos medžiagos tikslumo ar išsamumo. Taip pat PMI netikrina šiuose dokumentuose išsakytų nuomonių pagrįstumo.

PMI neprisiima atsakomybės už jokius asmens sužalojimus, žalą turtui ar kitą žalą, faktinę, netiesioginę ar pavyzdinę, tiesiogiai ar netiesiogiai kilusią dėl šio dokumento paskelbimo, taikymo ar naudojimo. PMI nėra atsakinga ir neteikia jokios aiškios ar numanomos garantijos dėl bet kokios čia pateiktos medžiagos tikslumo ar išsamumo ir neprisiima atsakomybės ar garantijų, kad čia pateikta informacija atitiks jūsų tikslus ar poreikius. PMI nesuteikia jokių garantijų dėl bet kokio atskiro gamintojo ar pardavėjo gaminių ar paslaugų kokybės, atsirandančios dėl šio standarto ar gairių naudojimo.

Išleisdama ir platindama šį dokumentą, PMI neteikia profesionalių ar kitų paslaugų jokiam asmeniui ar subjektui arba jų vardu; taip pat PMI nevykdo jokių asmens ar subjekto įsipareigojimų jokiai trečiajai šaliai. Naudodamas šį dokumentą, juo besinaudojantis asmuo turi pats nuspręsti, kokių veiksmų reikia imtis tam tikromis aplinkybėmis, pasikliaudamas tik savo sprendimu arba, jei reikia, kompetentingo specialisto patarimu. Informacijos apie temą, kuriai taikomas šis dokumentas arba susiję standartai, galima gauti iš kitų šaltinių, kuriuos vartotojas gali peržiūrėti, jei reikia, norėdamas gauti papildomos informacijos, kurios nėra čia.

PMI neturi įgaliojimų ir neprisiima įsipareigojimų stebėti esamos praktikos atitiktį šio dokumento turiniui arba užtikrinti, kad tokia praktika atitiktų šį dokumentą. PMI nesertifikuoja, reguliariai netestuoja ir netikrina gaminių, konstrukcijų ar projektų, susijusių su naudojimo sauga ar vartotojų sveikata. Bet koks čia pateiktos informacijos apie eksploatavimo saugą ar sveikatos saugą sertifikatas ar kitas atitikties pareiškimas negali būti priskirtas PMI; tokiu atveju visa atsakomybė tenka pažymėjimą išdavusiam ar tokį pareiškimą padariusiam asmeniui.

1 dalis: Projektų valdymo žinių grupės vadovas (PMBOK® vadovas)

1. Įvadas

1.1 Šio vadovo apžvalga ir tikslas

Projektų valdymas nėra naujiena. Žmonės jį naudojo daugelį šimtmečių. Užbaigtų projektų pavyzdžiai:

Gizos piramidės,

Olimpinės žaidynės,

Didžioji kinų siena,

Taj Mahal,

Išleisdama knygą vaikams,

Panamos kanalas,

Komercinių reaktyvinių lėktuvų kūrimas,

vakcina nuo poliomielito,

Nusileidęs žmogus į mėnulį,

Komercinės kompiuterių programos,

Nešiojamieji įrenginiai, skirti naudoti pasaulinę padėties nustatymo sistemą (GPS),

Tarptautinės kosminės stoties paleidimas į žemąją Žemės orbitą.

Praktiniai šių projektų laimėjimai buvo vadovų ir vadovų projektų valdymo praktikos, principų, procesų, priemonių ir metodų taikymas savo darbe rezultatas. Šių projektų vadovai panaudojo keletą pagrindinių įgūdžių ir pritaikė žinias, reikalingas savo klientams ir kitiems projekte dalyvaujantiems ar jo paveiktiems žmonėms patenkinti. Iki XX amžiaus vidurio projektų vadovai pradėjo dirbti siekdami pripažinti projektų valdymą kaip profesiją. Vienas iš šio darbo aspektų buvo susitarimo dėl žinių rinkinio (BOK), vadinamo projektų valdymu, turinio. EQA tampa žinoma kaip Projektų valdymo žinių įstaiga (PMBOK). Projektų valdymo institutas (PMI) sukūrė pagrindinius PMBOK metmenis ir žodynėlius. Netrukus projektų vadovai suprato, kad PMBOK negalima visiškai sutalpinti į vieną knygą. Todėl PMI buvo sukurtas ir paskelbtas „Projektų valdymo žinių skyriaus vadovas“ (PMBOK® vadovas).

Kaip apibrėžia PMI, Projektų valdymo žinių įstaiga (PMBOK) yra sąvoka, apibūdinanti projektų valdymo profesijos žinias. Projektų valdymo žinių kompleksas apima nusistovėjusias ir plačiai naudojamas tradicines praktikas bei naujai atsirandančias novatoriškas praktikas.

Žinių rinkinys (BKK) apima ir publikuotą, ir neskelbtą medžiagą. Ši žinių visuma nuolat tobulėja. Dabartis PMBOK® vadovas pabrėžia tą Projektų valdymo žinių grupės dalį, kuri visuotinai pripažįstama kaip gera praktika.

? Paprastai pripažinta reiškia, kad aprašytos žinios ir praktika daugeliu atvejų pritaikomos daugeliui projektų ir sutariama dėl jų vertės ir naudos.

? Gera praktika reiškia, kad yra bendras sutarimas, kad tinkamas šių žinių, įgūdžių, įrankių ir metodų taikymas projektų valdymo procesuose gali padidinti įvairių projektų sėkmės tikimybę, kad būtų pasiekta laukiama verslo vertė ir rezultatai.

Projekto vadovas dirba su projekto komanda ir kitomis suinteresuotosiomis šalimis, siekdamas nustatyti ir naudoti gerą, visuotinai priimtą praktiką kiekvienam projektui. Tinkamo procesų, sąnaudų, įrankių, metodų, rezultatų ir gyvavimo ciklo etapų derinio nustatymas projektui valdyti vadinamas šiame vadove aprašytų žinių „pritaikymu“.

Dabartis PMBOK® vadovas nėra metodika. Metodika – tam tikroje veiklos srityje naudojamų praktikų, metodų, procedūrų ir taisyklių sistema. Dabartis PMBOK® vadovas yra pagrindas, kuriuo remdamasi organizacija gali kurti savo metodikas, politiką, procedūras, taisykles, įrankius ir metodus bei gyvavimo ciklo fazes, reikalingas projektų valdymo praktikoje.

Šis vadovas yra pagrįstas Projektų valdymo standartas. Standartas – tai įgaliotos institucijos, papročių arba bendru susitarimu parengtas dokumentas kaip pavyzdys arba pavyzdys. Projektų valdymo standartas buvo sukurtas kaip Amerikos nacionalinio standartų instituto (ANSI) standartas, naudojant procesą, pagrįstą sutarimo, atvirumo, tinkamo proceso ir pusiausvyros principais. Projektų valdymo standartas yra pagrindinė PMI profesinio tobulėjimo programų ir projektų valdymo praktikos informacinė medžiaga. Kadangi reikia pritaikyti projektų valdymą, kad jis atitiktų konkretaus projekto poreikius, ir standartas, ir vadovas remiasi aprašomasis, bet ne direktyva praktikos. Šis standartas apibrėžia procesus, kurie daugeliu atvejų yra tinkami daugeliui projektų. Šis standartas taip pat apibrėžia įvestis ir išvestis, kurios paprastai yra susijusios su šiais procesais. Standarte nėra jokių konkrečių procesų ar praktikos privalomo įgyvendinimo reikalavimų. Projektų valdymo standartasįtraukta į II dalį Projektų valdymo žinių organizacijos (PMBOK® vadovas) vadovai.

IN PMBOK® vadovas Pateikiama daugiau informacijos apie pagrindines sąvokas, atsirandančias tendencijas, projektų valdymo procesų pritaikymo svarstymus ir informaciją apie tai, kaip projektams pritaikyti įrankius ir metodus. Projektų vadovai, įgyvendindami šiame standarte aprašytus projektų valdymo procesus, gali naudoti vieną ar kelias metodikas.

? Portfelio valdymo standartas, Ir

? Programos valdymo standartas .

Bendrasis žodynas yra esminis bet kurios profesinės disciplinos elementas. PMI projektų valdymo terminų žodynas pateikia pagrindinį profesinės terminijos žodyną, kurį gali nuosekliai naudoti organizacijos, projektų, programų ir portfelio vadovai bei kitos projekto suinteresuotosios šalys. Leksika laikui bėgant vystysis. Šio vadovo žodynėlyje yra įtrauktų žodžių žodynėlis Leksika terminai, taip pat papildomi apibrėžimai. Projektuose gali būti naudojami kiti konkrečiai pramonės šakai būdingi terminai, apibrėžti pramonės literatūroje.

PMI skelbia siekiant sustiprinti pasitikėjimą projektų vadovo profesija ir padėti asmeniui priimti pagrįstus sprendimus, ypač sudėtingose ​​situacijose, kai jo gali būti paprašyta elgtis nesąžiningai arba pakenkti savo vertybėms. Vertybės, kurias pasaulinė projektų valdymo bendruomenė įvardija kaip svarbiausias, yra atsakomybė, pagarba, sąžiningumas ir sąžiningumas. Profesinės etikos ir elgesio kodeksas yra pagrįstas šiomis keturiomis vertybėmis.

Profesinės etikos ir elgesio kodeksas apima ir skatinamuosius, ir privalomus standartus. Skatinimo standartai apibūdina elgesį, kurio turėtų siekti praktikai, kurie taip pat yra PMI nariai, sertifikatų turėtojai ar savanoriai, dėl savo vidinių įsitikinimų. Nors skatinimo standartų laikymąsi įvertinti nelengva, tačiau juos atitinkančio elgesio tikimasi iš tų specialistų, kurie laiko save profesionalais, tai yra, šie standartai negali būti laikomi neprivalomi. Privalomi standartai yra privalomi reikalavimai ir kai kuriais atvejais riboja arba draudžia tam tikrą praktikų elgesį. Praktikams, kurie yra PMI nariai, sertifikatų turėtojai arba savanoriai, kurie užsiima veikla, pažeidžiančia šiuos standartus, taikomos PMI etikos komiteto drausminės procedūros.

1.2 Pagrindiniai elementai

Šiame skyriuje aprašomi pagrindiniai elementai, reikalingi norint dirbti šioje srityje ir suprasti projektų valdymo discipliną.

Projektas – tai laikina veikla, kuria siekiama sukurti unikalų produktą, paslaugą ar rezultatą.

? Unikalus produktas, paslauga ar rezultatas. Projektai įgyvendinami siekiant tikslų, sukuriant duodamus rezultatus. Tikslas yra galutinis rezultatas, į kurį turėtų būti nukreiptas darbas; strateginė pozicija, kurios reikia imtis; problema, kurią reikia išspręsti; rezultatas, kurį reikia gauti; gaminamas produktas; ar teikiama paslauga. Rezultatas yra bet koks unikalus ir patikrinamas produktas, rezultatas ar paslaugos galimybė, reikalinga procesui, etapui ar projektui užbaigti. Pateikti rezultatai gali būti apčiuopiami arba neapčiuopiami.

Pasiekus projekto tikslus, galima pasiekti vieną ar daugiau iš šių rezultatų:

Unikali prekė, kuri gali būti kitos prekės sudedamoji dalis, kurios nors prekės patobulinimas ar pataisymas, arba naujas galutinis produktas pats savaime (pavyzdžiui, galutinio produkto defekto pašalinimas);

Unikali paslauga arba galimybė teikti paslaugą (pavyzdžiui, verslo padalinys, palaikantis gamybą ar platinimą);

Unikalus rezultatas, pvz., rezultatas arba dokumentas (pavyzdžiui, tyrimo projektas sukuria naujų žinių, kurios gali būti naudojamos siekiant nustatyti, ar naujas procesas yra tendencingas ar naudingas visuomenei);

Unikalus vieno ar daugiau produktų, paslaugų ar rezultatų (pavyzdžiui, programinės įrangos, susijusios dokumentacijos ir techninės pagalbos paslaugų) derinys.

Tam tikri elementai gali pasikartoti kai kuriuose projekto rezultatuose ir veikloje. Šis kartojimas nekeičia esminių ir unikalių projektinio darbo savybių. Pavyzdžiui, biurų pastatai gali būti statomi iš tų pačių medžiagų arba tos pačios statybos komandos. Tačiau kiekvienas statybos projektas išlieka unikalus savo pagrindinėmis savybėmis (pvz., vieta, dizainas, aplinka, aplinka, dalyvaujantys žmonės).

Projektai vykdomi visuose organizacijos lygiuose. Projekte gali dalyvauti vienas ar daugiau žmonių. Projekte gali dalyvauti vienas organizacijos struktūrinis padalinys arba keli skirtingų organizacijų struktūriniai padaliniai.

Projekto pavyzdžiai apima, bet tuo neapsiribojant:

Naujų vaistų kūrimas rinkai;

Ekskursinio turizmo paslaugų plėtra;

Dviejų organizacijų susijungimas;

Verslo procesų organizacijoje tobulinimas;

Naujos kompiuterinės įrangos, skirtos naudoti organizacijoje, pirkimas ir įdiegimas;

Naftos telkinių žvalgymas regione;

Organizacijoje naudojamos kompiuterinės programos modifikavimas;

Tyrimų atlikimas siekiant sukurti naują gamybos procesą;

Pastato statyba.

? Laikinoji įmonė. Laikinas projektų pobūdis rodo, kad yra tam tikra pradžia ir pabaiga. Sąvoka „laikinas“ nebūtinai reiškia, kad projektas turi trukti trumpai. Projektas baigiasi, kai yra teisingas vienas ar keli iš šių teiginių:

Pasiekti projekto tikslai;

Tikslai nebus arba negali būti pasiekti;

Finansavimas projektui išnaudotas arba nebegali būti skiriamas;

Projekto poreikis nutrūko (pavyzdžiui, užsakovas nebenori, kad projektas būtų baigtas, pasikeitus strategijai ar prioritetams reikia nutraukti projektą, organizacijos vadovybė nurodo projektą nutraukti);

Išnaudoti žmogiškieji arba materialiniai ištekliai;

Projektas nutraukiamas dėl teisinių ar tikslingumo priežasčių.

Projektai yra laikini, tačiau jų rezultatai gali egzistuoti ir pasibaigus projektui. Projektai gali būti socialinio, ekonominio, materialinio ar aplinkosauginio pobūdžio rezultatai. Pavyzdžiui, nacionalinio paminklo projektas sukuria rezultatą, kuris, kaip tikimasi, truks šimtmečius.

? Projektai skatina pokyčius. Projektai yra pokyčių organizacijose varikliai. Verslo požiūriu projekto tikslas yra perkelti organizaciją iš vienos valstybės į kitą, kad būtų pasiektas konkretus tikslas (žr. 1-1 pav.). Paprastai manoma, kad prieš prasidedant projektui organizacija yra pradinės būklės. O norimas pokyčių rezultatas projekto metu apibūdinamas kaip ateities būsena.

Kai kurie projektai gali apimti pereinamosios būsenos sukūrimą, kai keli žingsniai eina vienas po kito, kad būtų pasiekta būsimo būsena. Sėkmingo projekto užbaigimo rezultatas – organizacijos perėjimas į būsimą būseną ir konkretaus tikslo pasiekimas. Daugiau informacijos apie projektų ir pokyčių valdymą rasite dokumente Portfelių, programų ir projektų valdymas: praktikos vadovas.

Ryžiai. 1–1. Organizacijos perėjimas į naują būseną projekto pagalba

? Projektai kuria verslo vertę. PMI verslo vertę apibrėžia kaip grynąją, kiekybiškai įvertinamą naudą, gaunamą iš verslo įmonės. Nauda gali būti apčiuopiama, neapčiuopiama arba abi. Verslo analizėje verslo vertė yra nauda, ​​gaunama tokiomis formomis kaip laikas, pinigai, prekės ar nematerialus turtas mainais į tam tikras investicijas. Cm. Verslo analizė praktikams: praktikos vadovas, 185 p.

Projektų verslo vertė reiškia naudą, kurią suinteresuotosios šalys gauna įgyvendindamos konkretų projektą. Projekto nauda gali būti apčiuopiama, neapčiuopiama arba abi.

Medžiagų elementų pavyzdžiai:

grynieji pinigai,

Akcinis kapitalas,

Tinklo inžinerija,

Ilgalaikis turtas,

2012 m. gruodžio 31 d. PMI išleido naują Projektų valdymo žinių grupės vadovo leidimą (PMBOK® vadovas – 5-asis leidimas).

PMI specialistai, išleisdami PMBoK vertimą į rusų kalbą, žada, kad iki metų pabaigos šis darbas bus atliktas, o Rusijos profesionalų bendruomenė galės pilnai sužinoti visas naujojo PMBoK leidimo naujienas ir subtilybes. Turint omenyje skundus dėl PMBoK v.4 vertimo, geriau leisti rusišką versiją paskelbti vėliau, bet jie tai padarys jo kokybė.

Ekspertų nuomone, ilgas darbo laikotarpis pasiteisina: reikia paaiškinti daug naujų terminų, aprašyti naujus procesus, patikslinti senų terminų ir procesų vertimus, vertimai turi atitikti kitus PMI leidžiamus standartus.

Kas naujo naujajame PMBOK 5?

X1 skirsnyje „Penktojo leidimo pakeitimai“ pasakojama tik apie tai. Tarp visos bendros informacijos (pvz., „visas dokumento tekstas ir grafika buvo peržiūrėti, kad informacija būtų tikslesnė, aiškesnė, išsamesnė ir naujesnė“ arba „Procesų grupės skyrius buvo perkeltas į A1 priedą“) , taip pat yra naudinga:
1. Terminija ir derinimas

Autoriai išdidžiai tvirtina, kad visa terminija yra suderinta su PMI projektų valdymo terminų žodynu. Tuo pačiu metu pirmenybė teikiama PMI žodyno terminologijai. Jei PMBOK 5 vertimas į rusų kalbą prasideda nuo teisingos terminijos sukūrimo, tada yra vilties gauti kompetentingai išverstą žinių bagažą.

Be to, PMBOK 5 atitinka ISO 21500:2012 standartą „Projektų valdymo gairės“ ir pavadinimų, procesų, įvesties, išvesties, įrankių ir metodų suderinimą su kitais PMI standartais (pvz., „Portfelio valdymo standartas“, ir tt) užtikrinama .

Galiausiai jie nustojo klaidinti žmones su savo „teigiama rizika“. Galų gale, kas yra rizika? Tai yra pavojaus ar nesėkmės galimybė! Terminas kilęs iš graikų risikon, t.y. „uola“ arba „uola“. Senovės Graikijos didybės ir galios laikais „rizikuoti“ reiškė „laviruoti laivu tarp uolų“, t.y. galimas nesėkmės pavojus.

PMBOK 5 buvo pakeistas projekto rizikos valdymo aprašymas ir akcentas nuo termino „teigiama rizika“ perkeltas į terminą „galimybė“. Į tekstą taip pat buvo įtrauktos tokios sąvokos kaip požiūris į riziką, apetitas rizikuoti, tolerancija rizikai ir rizikos slenksčiai.

2. Projekto sėkmė

Kadangi projektai yra laikino pobūdžio, projekto sėkmė turi būti matuojama atsižvelgiant į projekto užbaigimą, atsižvelgiant į apimties, laiko, sąnaudų, kokybės, išteklių ir rizikos apribojimus.

Tačiau šiuolaikinių projektų kintančių reikalavimų dinamika yra tokia didelė, kad iki galo projektas peržengia visus įmanomus ir neįsivaizduojamus apribojimus. Todėl besikeičiančių reikalavimų valdymas ir jų fiksavimas projektiniuose dokumentuose ir pakartotinis koordinavimas Pagrindinis planavimas yra vis labiau geidžiamas projektų vadovų įgūdis. Tai atsispindi PMBOK 5 sakinyje „Projekto sėkmė turėtų būti siejama su naujausių bazinių planų, patvirtintų įgaliotų suinteresuotųjų šalių, įgyvendinimu“. Mano nuomone, nėra geresnio būdo tai pasakyti. Jei likus dviem dienoms iki projekto pabaigos pavyko susitarti su užsakovu dėl projekto terminų ir biudžeto padidinimo, vadinasi, projektas sėkmingas, nepaisant 2 kartus viršytų terminų ir 3 kartus padidinto projekto įgyvendinimo terminų. biudžetas.

3. Planavimo valdymo metodai

PMBOK 4 kai kurie pagalbiniai planai pasirodė tarsi iš oro. Pavyzdžiui, Apimties valdymo plano aprašymas buvo pateiktas tiesiogiai „Projekto apimties valdymo“ žinių srities aprašyme, tačiau nenurodyta, kokiame procese jis buvo sukurtas. Dabar buvo įtraukti keturi nauji planavimo procesai: apimties valdymo planavimas, tvarkaraščio valdymo planavimas, išlaidų valdymo planavimas ir suinteresuotųjų šalių valdymo planavimas. Tai numato aiškios gairės projekto komandai, kad ji galėtų aktyviai apgalvoti ir planuoti visų žinių sričių valdymo metodus.

Nors čia buvo ir trūkumų. Taigi du planai liko „neprižiūrimi“ – Pokyčių valdymo planas ir Konfigūracijos valdymo planas. Logiškai suprantama, kad konfigūracijos valdymo planas turėtų būti rodomas kartu su apimties valdymo planu ir pokyčių valdymo planu rengiant bendrą projekto valdymo planą, tačiau tai tik numanoma PMBOK 5.

4. Reikalavimai

Reikalavimų rinkimo procesas buvo išplėstas, siekiant pabrėžti visų reikalavimų, būtinų projekto sėkmei, gavimą.

„Verify Scope“ procesas buvo visiškai pertvarkytas. Pirma, jis buvo pervadintas į Patvirtinimo sritį. Antra, buvo pabrėžta, kad procesas yra ne tik rezultatų priėmimas, bet ir tai, kad rezultatai suteiks verslo vertę ir atitiks projekto tikslus.

Juokinga, bet PMBOK 4 buvo nelabai teisingas „Verify Scope“ vertimas kaip „Turinio patvirtinimas“. Dabar tai lems, kad rusų kalba PMBOK 5 šis procesas nepakeis pavadinimo. Tik įdomu, kaip vertėjams seksis išversti skyrių apie pakeitimus?

5. Gutaperča

Visuose ankstesniuose PMBOK kartu niekada nebuvo vartojamas žodis „vikrus“. nėra naudojamas. Dabartiniame PMBOK jis pasirodo net 10 kartų.

PMI niekada neslėpė, kad pagrindinis PMBOK vadovo tikslas yra pabrėžti tą Projektų valdymo žinių korpuso dalį, kuri paprastai laikoma gerąja praktika. Tie. Aprašytos žinios ir praktika yra pritaikomos daugeliui projektų daugelyje situacijų, o teisingas šių įgūdžių, įrankių ir metodų pritaikymas gali padidinti įvairių projektų sėkmės tikimybę.

Todėl lankstaus projektų valdymo sąvoka „vikrus“ buvo įtraukta į projekto grafiko rengimo procesą.

Teisingai, reikia laikyti nosį nuo vėjo! Tai irgi modernu tiek madingi, tiek komerciškai paklausūs.

6. Projekto komunikacijos

Projekto įgyvendinimo metu gautos informacijos ir žinių racionalizavimas buvo seniai lauktas. Vienas revoliucingiausių PMBOK 5 pakeitimų yra DIKW (duomenų, informacijos, žinių, išminties) modelio panaudojimas – informacijos hierarchija, kai kiekvienas lygis prie ankstesnio lygio prideda tam tikras savybes:

Apačioje yra duomenys.
Informacija papildo kontekstą.
Žinios prideda atsakymą į klausimą „kaip? (naudojimo mechanizmas).
Išmintis prideda atsakymą į klausimą „kada? (Naudojimo sąlygos).

Tai buvo išreikšta aiškia duomenų iš laukų rinkimo, kaupimo ir apdorojimo seka šiais dokumentais:

1. Duomenys apie darbų atlikimą. Įgyvendinant projektavimo darbus nustatyti „neapdoroti“ stebėjimai ir matavimai.

2. Informacija apie darbų atlikimą. Darbo atlikimo duomenys analizuojami ir integruojami remiantis skirtingų projekto sričių/fazių ryšiais.

3. Darbų atlikimo ataskaitos. Fizinis arba elektroninis darbo atlikimo informacijos pateikimas, skirtas padėti priimti sprendimus, pabrėžti problemas ir problemas, plėtoti veiksmus arba suprasti situaciją.

Jei čia pridėsime ir Pamokas iš patirties, ciklas bus uždarytas, o visos projekto įgyvendinimo procesuose sukurtos žinios bus surinktos ir apdorotos. ir būti naudojamas visų organizacijos projektų valdymo procesuose.

Na, o procesai, kurie daugelį supainiojo savo ribų neryškumu ir nesuprantama seka: „Informacijos sklaida“ ir „Veiklos ataskaitų rengimas“ buvo atitinkamai pervadinti į „Ryšių valdymas“ ir „Ryšių valdymas“ su loginiais įėjimais ir išėjimais.
7. „Akcijų savininkų“ valdymas

PMBOK 5 daug dėmesio skiria suinteresuotųjų šalių valdymui. Aprašyti beveik visi skyriai, siekiant geriau suprasti, kas yra projekto suinteresuotosios šalys ir kokia jų įtaka projektui. Pridėta nauja (10-oji) žinių sritis: „Projekto suinteresuotųjų šalių valdymas“, apimantis du „Projektų komunikacijos valdymo“ procesus, taip pat pridėti du nauji procesai.

Pagrindinės šio komunikacijos žinių srities atsiradimo priežastys yra šios:

1. Reikėjo aiškesnio projekto komunikacijos valdymo dėmesio skirti projekto komunikacijos poreikių planavimui, surinkimui, saugojimui ir sklaida informacija apie projektą, taip pat apie bendrų projekto ryšių stebėjimą, siekiant užtikrinti jų efektyvumą.

2. Realus suinteresuotųjų šalių valdymas apima ne tik jų lūkesčių, jų poveikio projektui analizę ir atitinkamų jų valdymo strategijų kūrimą, bet ir nuolatinį dialogą. su susidomėjusiušalys patenkinti jų poreikius ir lūkesčius, sprendžiant klausimus kaip jų atsiradimas, ir suinteresuotųjų šalių įtraukimas į sprendimų priėmimą ir projektinę veiklą.

3. Projekto komunikacijos poreikių planavimas ir valdymas, iš vienos pusės, ir suinteresuotųjų šalių poreikiai, kita vertus, yra du skirtingi projekto sėkmės raktai.

Projekto suinteresuotųjų šalių valdymo atskyrimas nuo projektų komunikacijos valdymo, be 3 aukščiau aprašytų problemų sprendimo, užtikrina, kad PMBOK 5 atitiks naujas augančias projektų valdymo tendencijas ir didelį mokslininkų bei praktikuojančių projektų vadovų susidomėjimą. sąveikai su suinteresuotosiomis šalimis, kaip vienas iš raktų į bendrą projekto sėkmę. Šios tendencijos jau atsispindi „Programų valdymo standarte“ ir ISO 21500:2012 „Projektų valdymo gairėse“. Taigi PMBOK pasivijo.

Taigi, nauja žinių sritis apima procesus:

Suinteresuotųjų šalių nustatymas.
Suinteresuotųjų šalių valdymo plano rengimas.
Suinteresuotųjų šalių dalyvavimo valdymas.
Suinteresuotųjų šalių dalyvavimo stebėjimas.

8. Minkštieji įgūdžiai

Prie tarpasmeninių įgūdžių pridėtas pasitikėjimo stiprinimas, konfliktų valdymas ir Mentorystė. Be to, prie 1 skyriaus „Įvadas“ buvo pridėtas naujas skyrius, kuriame pabrėžiama projektų vadovo minkštųjų įgūdžių svarba ir skaitytojas nukreipiamas į X3 priedą, kuriame pateikiamas išsamus šių įgūdžių aprašymas.

9. Dokumentacija

Na, o svarbiausia projekto dokumentavimui yra bendras dokumentų organizavimas, kuris prasidėjo PMBOK 4, tęsėsi PMBOK 5. Dabar proceso įvestis yra tik dokumentai, kurie atlieka pagrindinį vaidmenį vykdant procesą. Dokumentai ir jų sudėtis tapo aiškesni ir konkretesni. Nors dokumentų pavadinimai tekste visur rašomi mažomis raidėmis, todėl sunku vizualiai rasti dokumentus tekste, o norint dirbti su dokumentais, reikia gerai išmanyti PMBOK terminiją arba naudoti šablonų paketą.

Apskritai, PMBOK 5 tapo geriau struktūrizuota, nuosekli, su normaliais procesų santykiais ir patikrinta terminija

PMBOK-5 ® vadovas yra visuotinai pripažinta geroji projektų valdymo profesijos praktika.

Kaip atsisiųsti PMBOK

Naujasis PMBOK vadovas 5-asis leidimas buvo paskelbtas 2008 m. gruodžio 31 d. Dabar jis prieinamas visiems PMI nariams šiame puslapyje:

Rasite nuorodą su pavadinimu Projektų valdymo žinių fondo vadovas (PMBOK. vadovas), penktasis leidimas kuris bus naudojamas šiai PMBOK versijai įsigyti. Taigi tiesiog spustelėkite šią nuorodą, kuri suteiks galimybę į pirkinių krepšelį įtraukti standarto kopiją. Šiuo metu jo kaina yra 65,95 USD ne nariams ir 49,50 USD PMI nariams. Galiausiai atlikite patikrą ir atsisiųskite jos PDF versiją. Atsisiunčiant PMBOK 5 kopiją reikia atlikti šią procedūrą.

„Windows“ naudotojai:

Kai spustelėsite anglišką versiją, kad atsisiųstumėte PMBOK ® Guide 5th edition, šis pranešimas bus paragintas, pavyzdžiui, „FileOpen sistema susieja jūsų nario teises su leidiniu“ ir paragins atsisiųsti ir įdiegti „FileOpen Adobe Reader“ papildinį.

Šis veiksmas reikalingas tik naudojant pirmą kartą. Spustelėkite Taip, kad pradėtumėte „Adobe Reader“ papildinio diegimą.“ Tada sėkmingai įdiegę „Fileopen“ papildinį uždarykite langą, grįžkite ir atsisiųskite, tačiau norėdami pasiekti turite būti PMI narys.

„Mac“ naudotojai:

„Mac“ naudoja „Safari“, kuri naršyklėje atidaro PDF failus. Tai negali veikti, jei saugos ir kitos išplėstinės funkcijos yra įterptos į PDF. Tam reikia įdiegti pilną PDF skaitytuvo arba Adobe Acrobat versiją.

Čia yra APPLE palaikymo komentaras apie PDF skaitymą naudojant „Safari“. „Adobe PDFViewer“, skirta „Mac OS X“, neveiks tinkamai sistemoje, kuri neatitinka šių reikalavimų.

Pasaulinis Standartinis

Projektų valdymo institutas
VADOVAS ŽINIŲ ORGANUI
PROJEKTAI
(PMBOK® vadovas) – penktasis leidimas

ISBN 978-1-62825-008-4
Leidėjas:
Projektų valdymo institutas, Inc.
14 Campus Boulevard
Newtown Square, Pensilvanija 19073-3299 JAV
Telefonas: +610-356-4600
Faksas: +610-356-4647
Elektroninio pašto adresas: [apsaugotas el. paštas]
Internetas: www.PMI.org
©2013 Project Management Institute, Inc. Visos teisės saugomos.
„PMI“, PMI logotipas, „PMP“, PMP logotipas, „PMBOK“, „PgMP“, „Project Management Journal“, „PM Network“ ir „PMI Today“ logotipas yra registruotieji „Project Management Institute, Inc.“ prekių ženklai. „Quarter Globe Design“ yra projekto prekės ženklas
Valdymo institutas, Inc. Visą PMI prekių ženklų sąrašą galite rasti PMI Legal.
PMI leidinių skyrius laukia bet kokių pataisymų ar pastabų dėl PMI publikacijų. Nedvejodami praneškite apie rašybos klaidas, formatavimo klaidas ar kitas klaidas. Norėdami tai padaryti, tiesiog nukopijuokite reikiamą puslapį, pažymėkite jame pastebėtą klaidą ir išsiųskite šią kopiją šiuo adresu:
Knygų redaktorius, PMI leidiniai, 14 Campus Boulevard, Newtown Square, PA 19073-3299 JAV.
Norėdami gauti daugiau informacijos apie nuolaidas perpardavimui ar mokomajam naudojimui, kreipkitės į PMI knygų aptarnavimo centrą.
PMI knygų aptarnavimo centras
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Telefonas: 1-866-276-4764 (JAV ir Kanada) arba +1-770-280-4129 (likęs pasaulis)
Faksas: +1-770-280-4113
Elektroninio pašto adresas: [apsaugotas el. paštas]
Išspausdinta Jungtinėse Amerikos Valstijose. Jokia šio kūrinio dalis negali būti atgaminta ar perduodama jokia forma ar bet kokiomis priemonėmis, tiek elektroniniu, tiek raštu, fotografuojant ar įrašant garso įrašą, arba naudojant bet kokią informacijos saugojimo ir paieškos sistemą be išankstinio raštiško leidėjo leidimo.
Šis dokumentas atitinka JAV nuolatinio popieriaus standartą, paskelbtą Nacionalinės informacijos standartų organizacijos, Nr. Z39.48-1984.
10 9 8 7 6 5 4 3 2 1
Kongreso bibliotekos bibliografinis įrašas
Projektų valdymo žinių įstaigos vadovas (PMBOK® vadovas). -- Penktasis leidimas.
puslapių cm
Apima bibliografines nuorodas ir abėcėlinę rodyklę.
ISBN 978-1-62825-008-4 (minkštu viršeliu)
1. Projektų valdymas. I. Projektų valdymo institutas. II. Pavadinimas: PMBOK vadovas.
HD69.P75G845 2013 658.4'04--dc23 2012046112
FSC LABEL.pdf 1 12/18/12 13:16 PM

PRANEŠIMAS
Projektų valdymo instituto, Inc. (sutrumpintai PMI) paskelbti standartai ir gairės, įskaitant šį dokumentą, yra parengti standartų kūrimo procesu, pagrįstu savanorišku dalyvavimu ir bendru sutarimu. Šiame procese sujungiamos savanorių pastangos ir (arba) sujungiamos publikacijoje aptariama tema besidominčių asmenų pastabos ir nuomonės. Nors PMI administruoja procesą ir nustato taisykles, užtikrinančias, kad sutarimas būtų pasiektas be šališkumo, PMI nerašo dokumento ir savarankiškai netikrina, neįvertina ar netikrina PMI išleistuose standartuose ir gairėse pateiktos medžiagos tikslumo ar išsamumo. Taip pat PMI netikrina šiuose dokumentuose išsakytų nuomonių pagrįstumo.
PMI neatsako už jokius sužalojimus, žalą turtui ar kitą žalą, faktinę, pasekminę ar pavyzdinę, tiesiogiai ar netiesiogiai kilusią dėl šio dokumento paskelbimo, taikymo ar naudojimo. PMI nėra atsakinga ir neteikia jokios aiškios ar numanomos garantijos dėl bet kokios čia pateiktos medžiagos tikslumo ar išsamumo ir neprisiima atsakomybės ar garantijų, kad čia pateikta informacija atitiks jūsų tikslus ar poreikius. PMI nesuteikia jokių garantijų dėl bet kokio atskiro gamintojo ar pardavėjo gaminių ar paslaugų kokybės, atsirandančios dėl šio standarto ar gairių naudojimo.
Išleisdama ir platindama šį dokumentą, PMI neteikia profesionalių ar kitų paslaugų jokiam asmeniui ar subjektui arba jų vardu; taip pat PMI nevykdo jokių asmens ar subjekto įsipareigojimų jokiai trečiajai šaliai. Naudodamas šį dokumentą, juo besinaudojantis asmuo turi pats nuspręsti, kokių veiksmų reikia imtis tam tikromis aplinkybėmis, pasikliaudamas tik savo sprendimu arba, jei reikia, kompetentingo specialisto patarimu. Informacijos apie temą, kuriai taikomas šis dokumentas arba susiję standartai, galima gauti iš kitų šaltinių, kuriuose galima ieškoti papildomos informacijos, kurios nėra šiame dokumente.
PMI neturi įgaliojimų ir neprisiima įsipareigojimų stebėti esamos praktikos atitiktį šio dokumento turiniui arba užtikrinti, kad tokia praktika atitiktų šį dokumentą. PMI nesertifikuoja, reguliariai netestuoja ir netikrina gaminių, konstrukcijų ar projektų, susijusių su naudojimo sauga ar vartotojų sveikata. Bet koks čia pateiktos informacijos apie eksploatavimo saugą ar sveikatos saugą sertifikatas ar kitas atitikties pareiškimas negali būti priskirtas PMI; tokiu atveju visa atsakomybė tenka pažymėjimą išdavusiam ar tokį pareiškimą padariusiam asmeniui.

TURINYS
aš
TURINYS
1. ĮVADAS............................................... .................................................. ......................................1
1.1 PMBOK® vadovo paskirtis
................................................................................................... 2
1.2 Kas yra projektas? .................................................. ...................................................... ..........................3
1.2.1. Portfelių, programų ir projektų sąsajos................................................ .......4
1.3 Kas yra projektų valdymas? .................................................. ......................................................5
1.4 Portfelio valdymo, programos valdymo ir valdymo sąsajos
projektų ir organizacinis projektų valdymas................................................. .............................. 7
1.4.1 Programos valdymas................................................ ..........................................................9
1.4.2 Portfelio valdymas................................................ ...................................................... .9
1.4.3 Projektai ir strateginis planavimas................................................ ...................... 10
1.4.4 Projektų valdymo biuras................................................ ........ .................................. vienuolika
1.5 Projekto valdymo ir operacijų valdymo ryšys
ir organizacijos strategija............................................ ...................................................... 12
1.5.1 Operacijų valdymas
ir projektų valdymas................................................ ...................................................... 12
1.5.2 Organizacijos ir projektų valdymas................................................ ...................................... 14
1.6 Verslo vertė................................................ ...................................................... ...................... 15
1.7 Projekto vadovo vaidmuo................................................ ...................................................... .... 16
1.7.1 Projekto vadovo atsakomybės ir kompetencijos sritys................................................ ....... 17
1.7.2 Projekto vadovo tarpusavio bendravimo įgūdžiai................................................ ...... 17
1.8 Projekto valdymo žinių visuma................................................ ...................................... 18
2. ORGANIZACIJOS IR PROJEKTO GYVIMO CIKLO ĮTAKA....................................... ...................... 19
2.1 Organizacijos įtaka projektų valdymui................................................ ...................... 20
2.1.1 Organizacijų kultūros ir stiliai................................................ ...................................... 20
2.1.2 Organizaciniai ryšiai................................................ .......................................... 21
2.1.3 Organizacinės struktūros................................................ .............................................. 21
2.1.4 Organizacinio proceso turtas................................................ ...................................... 27
2.1.5 Įmonės aplinkos veiksniai................................................ .............................................. 29
2.2 Suinteresuotosios šalys ir projekto valdymas................................................ ..... ......... trisdešimt
2.2.1 Projekto suinteresuotosios šalys................................................ ............... ...................... trisdešimt

TURINYS
II
©2013 Projektų valdymo institutas. Projektų valdymo žinių fondo vadovas (PMBOK® vadovas) – penktasis leidimas
2.2.2 Projekto valdymas................................................ ...................................................... 34
2.2.3 Projekto sėkmė................................................ ...................................................... .............. 35
2.3 Projekto komanda................................................ .............................................................. .......................................... 35
2.3.1 Projekto komandų sudėtis................................................ ...................................................... .. 37
2.4 Projekto gyvavimo ciklas................................................ ...................................................... ............ 38
2.4.1 Projekto gyvavimo ciklo charakteristikos................................... ...................... 38
2.4.2 Projekto etapai................................................ ...................................................... ...................... 41
3. PROJEKTŲ VALDYMO PROCESAI................................................ ...................................................... .... 47
3.1 Bendrosios projektų valdymo procesų sąveikos................................................ ......... .. 50
3.2 Projektų valdymo procesų grupės................................................ ...................................................... 52
3.3 Iniciacijos proceso grupė................................................ ...................................................... ... 54
3.4 Planavimo proceso grupė................................................ ...................................................... ......... 55
3.5 Vykdymo proceso grupė................................................ ...................................................... 56
3.6 Stebėjimo ir kontrolės proceso grupė................................................ ...................................... 57
3.7 Proceso grupės uždarymas................................................ ...................................................... ................... 57
3.8 Informacija apie projektą................................................ ...................................................... ...................... 58
3.9 Žinių sričių vaidmuo................................................ ...................................................... ...................... 60
4. PROJEKTŲ INTEGRACIJOS VALDYMAS................................................ ...................................................... .... 63
4.1 Projekto chartijos rengimas................................................ ...................................................... ......... 66
4.1.1 Projekto chartijos kūrimas: indėlis................................................ ...................................................... 68
4.1.2 Projekto chartijos kūrimas: įrankiai ir metodai................................................ ............... 71
4.1.3 Projekto chartijos rengimas: rezultatai................................................ .......................................... 71
4.2 Projekto valdymo plano rengimas................................................ ...................................... 72
4.2.1 Projekto valdymo plano kūrimas: indėlis................................................ .............. 74
4.2.2 Projekto valdymo plano kūrimas: įrankiai ir metodai................................................. 76
4.2.3 Projekto valdymo plano rengimas: rezultatai................................................ ............... 76
4.3 Projektinio darbo valdymas ir valdymas................................................ ...................................... 79
4.3.1 Vadovavimas ir vadovavimas projektiniam darbui: indėlis................................................ ............ 82
4.3.2 Vadovavimas ir vadovavimas projektiniam darbui: įrankiai ir būdai................................................. 83
4.3.3 Projekto darbo vadovavimas ir valdymas: rezultatai................................................ .............. 84
4.4 Projekto darbo stebėsena ir kontrolė................................................ ...................................... 86

TURINYS
III
©2013 Projektų valdymo institutas. Projektų valdymo žinių fondo vadovas (PMBOK® vadovas) – penktasis leidimas
4.4.1 Projekto darbo stebėsena ir kontrolė: indėlis................................... .......................... 88
4.4.2 Projekto darbo stebėsena ir kontrolė: priemonės ir metodai................................... 91
4.4.3 Projekto darbo stebėsena ir kontrolė: rezultatai................................................ ...................... 92
4.5 Integruotas pakeitimų valdymas................................................ ...................................... 94
4.5.1 Integruotas pakeitimų valdymas: įėjimai................................................ ...................... 97
4.5.2 Integruotas pakeitimų valdymas: įrankiai ir metodai................................................. 98
4.5.3 Integruotas pakeitimų valdymas: išėjimai................................................ ...................... 99
4.6 Projekto ar etapo uždarymas................................................ ...................................................... ... 100
4.6.1 Projekto arba etapo uždarymas: įvestis................................................ ........................................ 102
4.6.2 Projekto arba etapo uždarymas: įrankiai ir būdai................................................ .............. 102
4.6.3 Projekto arba etapo uždarymas: rezultatai................................................ .......................................... 103
5. PROJEKTO TURINIO VALDYMAS................................................ ...................................................... .............. 105
5.1 Turinio valdymo planavimas................................................ ...................................... 107
5.1.1 Turinio valdymo planavimas: įėjimai................................................ ...................... 108
5.1.2 Apimties valdymo planavimas: įrankiai ir metodai................................................ 109
5.1.3 Turinio valdymo planavimas: rezultatai................................................ ...... 109
5.2 Surinkimo reikalavimai................................................ ...................................................... ...................... 110
5.2.1 Reikalavimai rinkimui: įvestis................................................ ...................................................... 113
5.2.2 Reikalavimų rinkimas: įrankiai ir būdai................................................ ...................................... 114
5.2.3 Reikalavimų rinkimas: išėjimai................................................ ...................................................... 117
5.3 Turinio apibrėžimas.................................................. ..................................................... 120
5.3.1 Turinio apibrėžimas: įvestis................................................ ...................................... 121
5.3.2 Turinio apibrėžimas: įrankiai ir metodai................................................ ........ .122
5.3.3 Turinio apibrėžimas: išėjimai................................................ ...................................... 123
5.4 WBS kūrimas................................................ .............................................................. .......................................... 125
5.4.1 WBS kūrimas: įėjimai................................................ ...................................................... ...... 127
5.4.2 WBS kūrimas: įrankiai ir metodai................................................ .............................. 128
5.4.3 WBS kūrimas: išėjimai................................................ ...................................................... ... 131
5.5 Turinio patvirtinimas................................................ ...................................................... 133
5.5.1 Turinio patvirtinimas: įvestis................................................... ...................................... 134
5.5.2 Turinio patvirtinimas: įrankiai ir metodai................................................ ......... 135

TURINYS
IV
©2013 Projektų valdymo institutas. Projektų valdymo žinių fondo vadovas (PMBOK® vadovas) – penktasis leidimas
5.5.3 Turinio patvirtinimas: išėjimai................................................ ...................................... 135
5.6 Turinio valdymas................................................ ...................................................... ....... .. 136
5.6.1 Turinio valdymas: įvestys................................... ...................................... 138
5.6.2 Turinio valdymas: įrankiai ir metodai................................................ ...................... 139