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
Management Institute Inc. Visą PMI prekių ženklų sąrašą galite rasti PMI teisės skyriuje.
PMI leidinių skyrius dėkingas priims bet kokius pataisymus ir pastabas, susijusias su PMI publikacijomis. Praneškite apie rašybos klaidas, formatavimo klaidas ar kitas pastebėtas klaidas. Norėdami tai padaryti, tiesiog nukopijuokite norimą puslapį, pažymėkite jame pastebėtą klaidą ir nusiųskite šią kopiją adresu:
Knygų redaktorius, PMI leidiniai, 14 Campus Boulevard, Newtown Square, PA 19073-3299 JAV.
Dėl perpardavimo ar edukacinio naudojimo nuolaidų 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 (kitose šalyse)
Faksas: +1-770-280-4113
Elektroninio pašto adresas: [apsaugotas el. paštas]
Išspausdinta Jungtinėse Amerikos Valstijose. Be išankstinio rašytinio leidėjo leidimo jokia šio kūrinio dalis negali būti atgaminta ar perduota jokia forma ar bet kokiomis priemonėmis, elektroniniu būdu, ranka, fotografuojant ar garso įrašais, arba naudojant bet kokias informacijos saugojimo ir atkūrimo sistemas.
Š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
JAV Kongreso bibliotekos bibliografinis įrašas
Projektų valdymo žinių įstaigos vadovas (PMBOK® vadovas). -- Penktasis leidimas.
žr. puslapius
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, kuriems priklauso šis dokumentas, buvo sukurti savanorišku, konsensusu pagrįstu standartų kūrimo procesu. Šis procesas suburia savanorius ir (arba) sujungia asmenų, besidominčių leidinio tema, komentarus ir nuomones. Nors PMI administruoja šį procesą ir nustato taisykles, užtikrinančias, kad sutarimas nebūtų šališkas, PMI nerašo dokumento ir savarankiškai netikrina, nevertina ar netikrina PMI paskelbtuose standartuose ir gairėse pateiktos medžiagos tikslumo ar išsamumo. Taip pat PMI neperžiūri šiuose dokumentuose išsakytų nuomonių pagrįstumo.
PMI neatsako už jokius sužalojimus, žalą turtui ar bet kokius kitus ypatingus, pasekminius ar pavyzdinius nuostolius, tiesiogiai ar netiesiogiai kylančius dėl šio dokumento paskelbimo, naudojimo ar naudojimo. PMI neteikia jokių aiškių ar numanomų pareiškimų ar garantijų dėl bet kokios šiame dokumente esančios medžiagos tikslumo ar išsamumo ir neteikia pareiškimų ar garantijų, kad šiame dokumente esanti informacija atitiks jūsų tikslus ar poreikius. PMI negarantuoja jokio atskiro gamintojo ar mažmenininko produktų ar paslaugų kokybės, atsirandančios dėl šio standarto ar vadovo naudojimo.
Skelbdama ir platindama šį dokumentą, PMI neteikia profesionalių ar kitų paslaugų jokiam asmeniui ar subjektui arba jų vardu; taip pat PMI nevykdo jokio asmens ar subjekto įsipareigojimų jokiai trečiajai šaliai. Naudodamasis šiuo dokumentu, šio dokumento naudotojas turėtų 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 susijusius standartus, galima gauti iš kitų šaltinių, kurie pateikiami dėl papildomos informacijos, kurios nėra šiame dokumente.
PMI neturi įgaliojimų ir neprisiima jokių įsipareigojimų stebėti esamos praktikos atitiktį šio dokumento turiniui arba suderinti šią praktiką su šiuo dokumentu. PMI nesertifikuoja, netestuoja ir netikrina gaminių, konstrukcijų ar projektų, skirtų saugaus eksploatavimo ar vartotojų sveikatos saugos požiūriu. Bet koks sertifikatas ar kitas atitikties pareiškimas, atitinkantis bet kurią šiame dokumente esančią saugos ar sveikatos informaciją, negali būti priskirtas PMI; tokiu atveju visa atsakomybė tenka pažymėjimą išdavusiam arba tokį tvirtinimą pateikusiam asmeniui.

TURINYS
aš
TURINYS
1. ĮVADAS............................................... .................................................. .................................. vienas
1.1 PMBOK® gairių tikslas
................................................................................................... 2
1.2 Kas yra projektas? .................................................. ................................................ .. .......3
1.2.1. Portfelių, programų ir projektų ryšiai................................................ ............4
1.3 Kas yra projektų valdymas? .................................................. ................................... penki
1.4 Portfelio valdymo, programos valdymo, valdymo ryšiai
projektų valdymas ir organizacinis projektų valdymas ................................................ ..................................7
1.4.1 Programos valdymas................................................ .. ..............................................devyni
1.4.2 Portfelio valdymas................................................ .. ..............................................devyni
1.4.3 Projektai ir strateginis planavimas ................................................ ................................ 10
1.4.4 Projektų valdymo biuras................................................ ................................................................ ... vienuolika
1.5 Santykis tarp projektų valdymo, operacijų valdymo
ir organizacijos strategija ................................................... ................................................................ ...... 12
1.5.1 Operacijų valdymas
ir projektų valdymas ................................................... ............................................................ ... 12
1.5.2 Organizacijos ir projektų valdymas................................................ ...................................... keturiolika
1.6 Verslo vertė................................................ ................................................................ .......................... 15
1.7 Projekto vadovo vaidmuo................................................ ...................................................... ..... 16
1.7.1 Projekto vadovo pareigos ir kompetencijos ............................................ ...... 17
1.7.2 Projekto vadovo tarpusavio bendravimo įgūdžiai ................................................ ..... 17
1.8 Projektų valdymo žinių kompleksas ................................................ .............................................. aštuoniolika
2. ORGANIZAVIMO POVEIKIS IR PROJEKTO GYVIMO CIKLO ............................................. .............................................. 19
2.1 Organizacijos įtaka projektų valdymui ................................................ ...................... ................ dvidešimt
2.1.1 Organizacijų kultūros ir stiliai ................................................ ...................................................... dvidešimt
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 Bendra projektų valdymo procesų sąveika ................................................ .............................. .. penkiasdešimt
3.2 Projektų valdymo procesų grupės................................................ .................................................. 52
3.3 Proceso inicijavimo 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 rengimas: 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 Projekto darbo vadovavimas ir kontrolė................................... .................................. 79
4.3.1 Vadovavimas ir vadovavimas projektiniam darbui: indėlis ............................................ ..... 82
4.3.2 Projektinio darbo vadovavimas ir kontrolė: priemonės ir metodai .................. 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 Stebėkite ir valdykite projekto darbą: įvestis ................................................ .............................. 88
4.4.2 Projekto darbo stebėjimas ir kontrolė: įrankiai 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 keitimo valdymas: išėjimai ................................................... .............................. 99
4.6 Projekto ar etapo uždarymas................................................ ...................................................... ... šimtas
4.6.1 Projekto arba etapo uždarymas: įvestis ............................................ ...................................................... 102
4.6.2 Projekto arba etapo uždarymas: įrankiai ir metodai ................................................ ....... 102
4.6.3 Projekto arba etapo uždarymas: rezultatai ............................................ .................................................. 103
5. PROJEKTO APIMTIES VALDYMAS................................................ .............................................................. ............ 105
5.1 Turinio valdymo planavimas................................................ .............................................. 107
5.1.1 Turinio valdymo planavimas: įvestis ................................................ ...................... 108
5.1.2 Turinio 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 Reikalavimai rinkimui: į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 Apimties apibrėžimas: priemonės ir metodai ................................................ .......................... .122
5.3.3 Turinio nustatymas: 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: įėjimai................................................ ..................................... 138
5.6.2 Turinio valdymas: įrankiai ir metodai ................................................ ...... 139

2012 m. gruodžio 31 d. PMI išleido naują Projektų valdymo žinių vadovo (PMBOK® Guide – 5th Edition) leidimą.

PMI specialistai išleisdami PMBoK vertimą į rusų kalbą žada, kad šis darbas bus atliktas iki metų pabaigos, o Rusijos profesionalų bendruomenė galės visapusiškai 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 tada jie bus jo kokybė.

Vertinant ekspertų nuomone, ilgas darbo terminas pasiteisina: reikia paaiškinti daug naujų terminų, aprašyti naujus procesus, patikslinti senų terminų ir procesų vertimus, derinti vertimus su kitais PMI išleistais standartais.

Kas naujo naujajame PMBOK 5?

X1 skirsnyje „Penktojo leidimo pakeitimai“ mums tik tai pasakyta. Tarp visos bendro pobūdžio 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 pakeistas perkeltas į A1 priedą), taip pat naudinga:
1. Terminija ir derinimas

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

Be to, PMBOK 5 buvo suderintas su standartu ISO 21500:2012 „Projektų valdymo gairės“ ir pavadinimų, procesų, įvesties, išvesties, įrankių ir metodų suderinimas su kitais PMI standartais (pvz., „Portfelio valdymo standartas“). ir kt.) .

Galiausiai jie nustojo vesti žmones į stuporą dėl savo „teigiamos rizikos“. 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ė „suvaldyti laivą tarp uolų“, t.y. galima nesėkmės rizika.

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

2. Projekto sėkmė

Kadangi projektai yra laikini, 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ų reikalavimų pokyčių dinamika yra tokia didelė, kad iki galo projektas išeina iš visų įmanomų ir neįsivaizduojamų apribojimų. Todėl besikeičiančių reikalavimų valdymas, fiksavimas projektiniuose dokumentuose ir pakartotines derybas Pagrindiniai įgūdžiai yra vis labiau paklausūs projektų vadovų įgūdžiai. Tai atsispindėjo PMBOK 5 sakinyje „Projekto sėkmė turėtų būti siejama su naujausių, įgaliotų suinteresuotųjų šalių patvirtintų bazinių standartų įgyvendinimu“. Nemanau, kad geriau sakyti. Jeigu 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švalandžių ir 3 kartus padidinto biudžeto.

3. Planavimo požiūriai į valdymą

PMBOK 4 dalis pagalbinių planų pasirodė iš oro. Pavyzdžiui, Apimties valdymo plano aprašymas buvo pateiktas tiesiogiai „Projekto apimties valdymo“ žinių srities aprašyme, o kokiame procese jis kuriamas, nenurodoma. 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 ir ne be trūkumų. Taigi „be priežiūros“ liko du planai – Pokyčių valdymo planas ir Konfigūracijos valdymo planas. Logiška, kad konfigūracijos valdymo planas turėtų būti rodomas kartu su turinio valdymo planu, o pokyčių valdymo planas – rengiant bendrą projekto valdymo planą, tačiau PMBOK 5 tai tik numanoma.

4. Reikalavimai

Reikalavimų rinkimo procesas buvo išplėstas, siekiant sutelkti dėmesį į visų reikalavimų, būtinų projekto sėkmei, gavimą.

„Verify Scope“ procesas buvo visiškai pakeistas. Pirma, jis buvo pervadintas į Patvirtinkite taikymo sritį. Antra, buvo pabrėžta, kad šis procesas yra ne tik rezultatų priėmimas, bet ir tai, kad rezultatai bus vertingi verslui ir atitiks projekto tikslus.

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

5. Gutaperča

Per visus ankstesnius PMBOK žodžius „vikrus“ niekada nebuvo nebuvo naudojamas. Dabartiniame PMBOK tai pasitaiko net 10 kartų.

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

Todėl į projekto tvarkaraščio rengimo procesą buvo įtraukta judraus projektų valdymo koncepcija.

Teisingai, reikia saugoti nosį nuo vėjo! Tai šiuolaikiška tiek madingi, tiek komerciškai paklausūs.

6. Projekto komunikacijos

Projekto įgyvendinimo metu gautos informacijos ir žinių sutvarkymas jau seniai brendo. Vienas iš revoliucingiausių PMBOK 5 pakeitimų yra DIKW (duomenų, informacijos, žinių, išminties) modelio taikymas – informacijos hierarchija, kur kiekvienas lygis prideda tam tikras savybes prie ankstesnio lygio:

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ą. Projektavimo darbų metu 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 ar elektroninis informacijos apie darbo atlikimą pateikimas, skirtas sprendimams priimti, problemoms ir problemoms išryškinti, veiksmams generuoti ar situacijos suvokimui.

Jei čia pridėsime ir patirties pamokas, ciklas užsidaro ir visos projekto įgyvendinimo procese sugeneruotos žinios bus surenkamos ir apdorojamos. ir būti naudojamas valdant visus organizacijos projektus.

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

Suinteresuotųjų šalių valdymas yra labai svarbus PMBOK 5. Beveik visi skyriai buvo paliesti, siekiant geriau pabrėžti projekto suinteresuotąsias šalis ir jų poveikį projektui. Pridėta nauja (10-oji) žinių sritis „Projektų suinteresuotųjų šalių valdymas“, apimanti du „Projektų komunikacijos valdymo“ procesus, ir pridėti du nauji procesai.

Pagrindinės tokios 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 platinimas informacija apie projektą, taip pat stebėti bendrus projekto ryšius, 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. Viena vertus, projekto komunikacijos poreikių planavimas ir valdymas ir, kita vertus, suinteresuotųjų šalių poreikiai, 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 atitiktų naujas augančias projektų valdymo tendencijas ir būtų labai įdomus mokslininkams bei praktikuojantiems projektų vadovams. 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 kompensavo prarastą laiką.

Taigi, nauja žinių sritis apima procesus:

Suinteresuotųjų šalių identifikavimas.
Suinteresuotųjų šalių valdymo plano rengimas.
Suinteresuotųjų šalių įtraukimo valdymas.
Suinteresuotųjų šalių dalyvavimo kontrolė.

8. „Minkštieji įgūdžiai“

Į tarpasmeninius įgūdžius įtrauktas pasitikėjimo stiprinimas, konfliktų valdymas ir mentorystė. Be to, 1 skyrius „Įvadas“ buvo įtrauktas į naują skyrių, kuriame nurodoma projekto vadovo bendravimo su asmeniniais įgūdžiais svarba ir skaitytojas nukreipiamas į X3 priedą, kuriame pateikiamas išsamus šių įgūdžių aprašymas.

9. Dokumentacija

Na, o svarbiausias dalykas projekto dokumentavimui - bendras dokumentų tvarkymas, prasidėjęs PMBOK 4, tęsėsi 5 d. Dabar vienintelė įvestis į procesus yra dokumentai, kurie atlieka pagrindinį vaidmenį vykdant procesą. Dokumentai ir jų sudėtis tapo aiškesni ir konkretesni. Nors pačių dokumentų pavadinimai tekste visur buvo rašomi maža raide, todėl tekste sunku vizualiai rasti dokumentus, o norint dirbti su dokumentais, reikia gerai išmanyti PMBOK terminiją arba naudoti šabloninį paketą. .

Apskritai, PMBOK 5 tapo geriau struktūrizuotas, nuoseklus, su normaliais santykiais tarp procesų, patikrinta terminija

________________________________________________________________________________________________

1. ĮVADAS

2. ORGANIZACIJOS POVEIKIS IR PROJEKTO GYVIMO CIKLAS

3. PROJEKTŲ VALDYMO PROCESAI

4. PROJEKTŲ INTEGRACIJOS VALDYMAS

5. PROJEKTO APIMTIES 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Ų PIRKIMO VALDYMAS

13. 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 gaminio, produkto patobulinimo ar galutinio produkto sudedamoji dalis;

· paslauga arba galimybę teikti paslaugą (pavyzdžiui, verslo funkciją, kuri palaiko 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 suteikia naujų žinių, kurias naudojant galima nustatyti, ar yra naujo proceso tendencija ar nauda visuomenei).

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

Šios 5 procesų grupės yra tokios:

iniciacija,

planavimas,

egzekucija,

Stebėjimas ir kontrolė

uždarymas.

Projekto apribojimai:

· kokybė,

· tvarkaraštis,

biudžetas

išteklius

Dėl pokyčių potencialo projekto valdymo plano kūrimas yra kartotinis ir nuosekliai tobulinamas įvairiais projekto gyvavimo ciklo etapais. Laipsniškas tobulinimas leidžia projekto valdymo komandai apibrėžti darbo apimtį ir valdyti jį detalesniu lygiu, kai projektas vystosi.

Programa- susijusių projektų, paprogramių ir programos veiklų rinkinys, valdomas koordinuotai, siekiant gauti naudos, kurios nebūtų gaunama, jei būtų valdoma atskirai. Programose gali būti su jomis susijusių darbų elementų, kurie nepatenka į atskirų programos projektų apimtį. 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 keliamus reikalavimus ir gauti naudą bei kontrolę, kurios nebūtų galima atskirai valdant projektus.

Programos projektai yra susieti per bendrą galutinį rezultatą arba bendrą galimybę. Jei ryšys 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 būtų nauja palydovinio ryšio sistema su palydovų ir palydovinių žemės stočių projektavimo, kiekvienos iš jų pastatymo, sistemos integravimo ir palydovo paleidimo projektais.

Portfelis yra projektų, programų, subportfelių ir operacijų elementų rinkinys, valdomas kaip grupė, siekiant strateginių tikslų. Programos yra sugrupuotos portfelyje ir susideda iš paprogramių, projektų ir kitų koordinuotai valdomų veiklų portfeliui paremti. Atskiri projektai, kurie yra programoje arba už jos ribų, taip pat laikomi portfelio dalimi. Nors nebūtinai vienas nuo kito priklausomi arba tiesiogiai susiję, portfelio projektai ar programos yra susieti su organizacijos strateginiu planu per organizacijos portfelį.

Portfelio valdymas- centralizuotas vieno ar kelių portfelių valdymas strateginiams tikslams pasiekti. Portfelio valdymas yra orientuotas į projektų ir programų analizę, 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 metodais. PMO pareigos gali būti įvairios – 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.

· kontroliuojantis. PMO kontrolė teikia paramą ir reikalauja atitikties įvairiomis priemonėmis. Atitiktis gali būti susijusi su projektų valdymo struktūrų ar metodikų pritaikymu, specialių šablonų, formų ir priemonių naudojimu arba valdymo reikalavimų laikymusi. PMO kontrolės laipsnis yra vidutinis.

· vadovaujantis. Vadovaujantys PMO kontroliuoja projektus tiesiogiai valdydami tuos projektus. PMO kontrolės laipsnis yra aukštas.

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

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

· projektų valdymo metodikos, geriausios praktikos ir standartų apibrėžimas ir tobulinimas;

instruktavimas, mentorystė, mokymas ir supervizija;

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

politikos, procedūrų, projektų šablonų ir kitos bendros 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 sutelkia dėmesį į 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, siekdamas tiksliau įgyvendinti projekto tikslus, o PMO optimizuoja bendrų organizacijos išteklių 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.

Eksploatacinė veikla yra nuolatinė veikla, kuri duoda pasikartojančius rezultatus, o ištekliai skiriami atlikti beveik identišką užduočių rinkinį pagal standartus, įterptus į produkto gyvavimo ciklą. Skirtingai nuo veiklos, kuri yra nuolatinė, projektai yra laikinas verslas.

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, gamybos 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ė, visų materialių ir nematerialių elementų suma. Materialiųjų objektų pavyzdžiai yra piniginis turtas, ilgalaikis turtas, nuosavas kapitalas ir komunikacijos. Nematerialių elementų pavyzdžiai yra reputacija, prekės ženklo žinomumas, viešoji gėrybė ir prekių ženklai. Priklausomai nuo organizacijos, verslo vertės turinys gali būti trumpalaikis, vidutinis ir ilgalaikis. Vertė gali būti sukurta efektyviai valdant kasdienes operacijas. 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- vykdančiosios organizacijos paskirtas asmuo vadovauti komandai ir atsakingas už projekto tikslų įgyvendinimą.

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

RP kompetencijos:

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

· Vykdymo kompetencijos- ką projekto vadovas gali padaryti ar pasiekti, pritaikydamas savo projektų valdymo žinias.

· Asmeninės kompetencijos- kaip projekto vadovas elgiasi vykdydamas projektą ar su juo susijusią veiklą. Asmeniniai rezultatai apima nuostatas, pagrindines asmenybės savybes ir lyderio savybes – 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,

instruktavimas.

2. ORGANIZACIJOS POVEIKIS IR PROJEKTO GYVIMO CIKLAS

Organizacijos proceso turtas yra planai, procesai, politika, procedūros ir žinių bazės, būdingos vykdančiajai organizacijai ir jos naudojamos. Jie apima bet kokius kai kurių arba visų projekte dalyvaujančių organizacijų artefaktus, metodus ir žinias, 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 procesų turtas yra daugumos planavimo procesų įvestis. Viso projekto metu komandos nariai gali atnaujinti ir prireikus papildyti organizacijos procesų išteklius. Organizacijos procesų turtą galima suskirstyti į dvi kategorijas:

procesus ir procedūras

įmonės žinių bazė

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

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

• geografinis įrangos ir išteklių pasiskirstymas;

· vyriausybės ir pramonės standartai (pvz., reglamentai, elgesio kodeksai, gaminių standartai, kokybės standartai, gamybos standartai);

Infrastruktūra (pvz., esami įrenginiai ir pagrindinė įranga);

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

· personalo valdymas (pavyzdžiui, įdarbinimo ir atleidimo gairės, veiklos analizė ir personalo mokymo įrašai, atlyginimų ir viršvalandžių politika bei darbo laiko sekimas);

padėtis rinkoje;

suinteresuotųjų šalių tolerancija rizikai;

politinis klimatas;

organizacijoje priimti komunikacijos kanalai;

· komercinės duomenų bazės (pvz., standartizuotos išlaidų sąmatos, pramonės rizikos tyrimai 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 interneto sąsajos su kitomis internetinėmis automatizuotomis 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 projekto rezultatų kūrimo darbą.

· Pagalbiniai ekspertai. Pagalbiniai ekspertai atlieka veiklą, būtiną projekto valdymo planui parengti arba vykdyti. Tai gali apimti sutarčių sudarymą, finansų valdymą, logistiką, teisinę pagalbą, saugumą, kūrimą, testavimą ar kokybės kontrolę. Priklausomai nuo projekto dydžio ir reikalingos paramos lygio, pagalbiniai ekspertai gali dirbti visą darbo dieną arba tiesiog būti komandos dalimi, kai reikia specifinių jų įgūdžių.

· Vartotojų ar klientų atstovai. Organizacijos nariai, kurie priims projekto rezultatus ar produktus, gali veikti kaip atstovai spaudai arba tarpininkai, kad užtikrintų tinkamą koordinavimą, patarimus dėl reikalavimų arba projekto rezultatų patvirtinimą.

· Pardavėjai. Pardavėjai, taip pat vadinami agentais, tiekėjais arba rangovais, yra trečiųjų šalių įmonės, sudariusios sutartis dėl projekto komponentų ar paslaugų teikimo. Projekto komanda dažnai yra atsakinga už tiekėjo pateiktų produktų ar 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čiųjų šalių įmonės, tačiau su įmone juos sieja ypatingas ryšys, kartais įgyjamas sertifikavimo būdu. Verslo partneriai teikia specializuotą patirtį arba atlieka jiems priskirtą vaidmenį, pvz., įdiegia, pritaiko, moko ar palaiko.

Projekto gyvavimo ciklas- etapų rinkinys, per kurį projektas pereina nuo jo pradžios 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 veiklų visuma, kurios kulminacija yra vieno ar kelių pasiektų rezultatų pasiekimas.

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.

Iteratyvūs 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 geriau supranta produktą. Iteratyvumas apibrėžia produkto kūrimą per daugybę pasikartojančių ciklų, o inkrementiškumas apibrėžia laipsnišką produkto funkcionalumo augimą. Per šiuos gyvavimo ciklus gaminys kuriamas tiek iteratyviai, tiek laipsniškai.

Adaptyvūs gyvavimo ciklai(taip pat žinomas kaip pokyčių skatinama arba judri praktika) siekiama reaguoti į didelius pokyčius ir visada reikia didelio suinteresuotųjų šalių įsitraukimo. Prisitaikantys metodai taip pat yra pasikartojantys ir laipsniški, tačiau skiriasi tuo, kad iteracijos yra labai greitos (trukmė paprastai yra 2–4 ​​savaitės) ir yra fiksuotos laiko ir išlaidų atžvilgiu. Judrūs projektai paprastai vykdo kelis procesus per kiekvieną iteraciją, nors ankstyvosios iteracijos gali būti labiau sutelktos į planavimo operacijas. Bendra projekto apimtis yra suskirstyta į reikalavimų rinkinį, o atliktini darbai kartais vadinami neatsilikimu (reikalavimų žurnalu). Iteracijos pradžioje komanda nustato, kiek aukšto prioriteto atsilikimo elementų galima gauti 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ų, priemonių 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, kurie gali būti taikomi, taip pat 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 nustatyta be tam tikro pagrindinio supratimo, kaip sukurti tam tikrą produktą. Pavyzdžiui, nustatant bendrą statomo pastato sudėtingumą, reikėtų atsižvelgti į įvairias statybos technologijas ir priemones.

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šaiškinti tikslus ir nustatyti veiksmų eigą, reikalingą projekto tikslams pasiekti.

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

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

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

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

Vykdant projekto gyvavimo ciklą surenkama, analizuojama, transformuojama ir išplatinama projekto komandos nariams ir kitoms suinteresuotosioms šalims daug įvairių formatų duomenų ir informacijos. Projekto duomenys renkami įvairių vykdymo procesų metu, po kurių jie pateikiami projekto komandos nariams.

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

· Darbo atlikimo duomenys. Neapdoroti stebėjimai ir matavimai, nustatyti atliekant projektus vykdomas veiklas. Pavyzdžiai: fiziškai atliktų darbų procentinė dalis, kokybės ir techninės veiklos rodikliai, grafiko veiklos pradžios ir pabaigos datos, pakeitimų užklausų skaičius, defektų skaičius, faktinės išlaidos, faktinė trukmė ir pan.

· Informacija apie darbų atlikimą. Veiklos duomenys, surinkti per įvairius kontrolės procesus, analizuojami kontekste ir apibendrinami remiantis sąsajomis skirtingose ​​srityse. Veiklos informacijos pavyzdžiai apima rezultatų būseną, pakeitimų užklausų įgyvendinimo būseną ir prognozių įvertinimą iki pabaigos.

· 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, pagrindimai, informaciniai biuleteniai, elektroninės informacijos suvestinės, rekomendacijos 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į arba veiklos sritį. Šios 10 žinių sričių beveik visada naudojamos daugumoje projektų. Projekto komandos turėtų naudoti šias 10 žinių sričių ir kitas žinių sritis, kurių reikia konkrečiam projektui. Specializuotos sritys apima:

Projektų integravimo valdymas

Projekto turinio valdymas

projekto laiko valdymas,

projekto išlaidų valdymas,

Projekto kokybės valdymas

Projekto žmogiškųjų išteklių valdymas

Projekto komunikacijos valdymas

Projekto rizikos valdymas

Projektų pirkimų valdymas

projekto suinteresuotųjų šalių valdymas.

4. PROJEKTŲ INTEGRACIJOS VALDYMAS

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

Projekto chartijoje yra:

Projekto tikslas arba pagrindimas;

išmatuojami projekto tikslai ir susiję sėkmės kriterijai;

Aukšto lygio reikalavimai

· Prielaidos ir apribojimai;

Aukšto lygio projekto aprašymas ir ribos;

Aukšto lygio rizika

padidintas kontrolinių renginių grafikas;

Padidintas biudžetas

suinteresuotų šalių sąrašas;

· reikalavimai projekto tvirtinimui (t. y. kas tiksliai reiškia projekto sėkmę, kas nusprendžia, kad projektas buvo 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 (-ių) projekto chartiją, įgaliojimai.

Kūrinių aprašymas(darbo ataskaita, SOW) yra žodinis produktų, paslaugų ar rezultatų, kuriuos turi sukurti projektas, 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 sąnaudų ir naudos palyginimas įtraukiami į verslo atvejį, kad pagrįstų projektą.

· Prekės turinio aprašymas. Produkto apimties aprašymas apima produkto, paslaugos ar rezultato, kurį bandoma sukurti projektu, charakteristikas. Aprašymas taip pat turėtų atspindėti ryšį tarp kuriamų produktų, paslaugų ar rezultatų ir verslo poreikio, kurį norima patenkinti projektu.

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

Verslo atvejis

Verslo atvejis ar panašus dokumentas pateikia reikalingą verslo informaciją, leidžiančią nustatyti, ar projektas vertas reikiamų investicijų. Jį dažniausiai naudoja su projektu susiję 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 dažniausiai verslo analitikas atlieka šią analizę 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ų gamintojas patvirtina projektą, kurio tikslas – sukurti 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ė patvirtina projektą statyti naują pastotę, tiekiančią elektros energiją naujai pramonės zonai);

· technologinė pažanga (pavyzdžiui, aviakompanija leidžia vykdyti naują e. bilietų kūrimo projektą, kuris, remiantis technologijų pažanga, pakeistų popierinius bilietus);

· teisinis reikalavimas (pavyzdžiui, dažų gamintojas duoda leidimą projektui parengti toksiškų medžiagų tvarkymo gaires);

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

· socialinis poreikis (pavyzdžiui, nevyriausybinė organizacija besivystančioje šalyje leidžia įgyvendinti projektą, skirtą bendruomenėms, kenčiančioms nuo didelio choleros atvejų, aprūpinti geriamuoju vandeniu, tualetais ir sveikatos mokymu).

Susitarimai

Susitarimai naudojami pirminiams projekto ketinimams apibrėžti. Susitarimai gali būti sudaryti kaip sutartis, susitarimo memorandumas, susitarimas dėl paslaugų lygio, susitarimo raštas, ketinimų protokolas, žodinis susitarimas, el. paštas ar kita rašytinė sutartis. 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 (pvz., elgesio kodeksai, kokybės standartai arba darbuotojų apsaugos standartai);

organizacinė kultūra ir struktūra;

rinkos situaciją.

Organizacijos proceso turtas

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

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

Šablonai (pavyzdžiui, projekto chartijos šablonas)

istorinė informacija ir žinių bazė (pavyzdžiui, projektai, įrašai ir dokumentai, visa projekto užbaigimo informacija ir dokumentai, informacija apie ankstesnių projektų atrankos sprendimų rezultatus, informacija apie ankstesnių projektų rezultatus ir informacija apie rizikos valdymo operacijas).

Projekto valdymo planas yra dokumentas, aprašantis, kaip projektas bus vykdomas, kaip jis bus stebimas ir kontroliuojamas. Jis integruoja ir sujungia visus planavimo procesų paplanus ir bazines linijas.

Pagrindiniai projekto planai, be kita ko, apima:

Pagrindinis turinio planas

pagrindinis tvarkaraštis;

pagrindinis išlaidų planas.

Papildomi planai apima, bet tuo neapsiriboja:

turinio valdymo planas

Reikalavimų valdymo planas

tvarkaraščio valdymo planas

Išlaidų valdymo planas

kokybės valdymo planą;

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

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

Išsami informacija apie projekto valdymo komandos priimtus pritaikymo sprendimus, būtent:

o Projekto valdymo komandos parinkti 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 reikalingus įvesties ir išvesties duomenis.

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

pokyčių valdymo planą, kuriame dokumentuojama, kaip pokyčiai stebimi ir kontroliuojami;

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

bazinių planų vientisumo palaikymo tvarkos aprašas;

· suinteresuotųjų šalių bendravimo reikalavimai ir būdai;

· pagrindinės valdymo peržiūros veiklos, susijusios su turiniu, ribomis ir terminais, siekiant išspręsti esamas problemas ir laukiamus sprendimus.

Planuoti prognozes

Tvarkaraščio prognozės yra pagrįstos pažanga pagal pradinį tvarkaraštį ir numatomą prognozės laiką iki užbaigimo (ETC). Paprastai jie išreiškiami kaip laiko nuokrypis (RTD) ir laiko našumo indeksas (TDI). Projektams, kuriuose nenaudojamas uždirbtos vertės valdymas, nurodomi nukrypimai nuo planuotų ir numatomų užbaigimo datų.

Prognozė gali būti naudojama norint nustatyti, ar projektas yra tolerancijos diapazone, ir nustatyti būtinus pakeitimų užklausas.

Išlaidų prognozės

Išlaidų prognozės yra pagrįstos pažanga pagal pradinį išlaidų planą ir numatomą užbaigimo prognozę (MUP). Paprastai jie išreiškiami kaip išlaidų dispersija (CVA) ir išlaidų efektyvumo indeksas (CFI). Užbaigimo prognozė (PCF) gali būti lyginama su baigtumo biudžetu (BPC), kad būtų galima nustatyti, ar projektas atitinka leistiną nuokrypį, 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, žymimi produktai ir dokumentai, tvarkomi pakeitimai ir į juos atsižvelgiama.

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

· Patvirtinkite ir patikrinkite konfigūraciją. Konfigūracijos patvirtinimas ir auditas užtikrina, kad projekto konfigūracijos elementų dizainas būtų teisingas, 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 APIMTIES 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 įtraukta ir kas neįtraukta į projektą.

Projekto kontekste terminas „turinys“ gali reikšti:

Reikalavimai 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, kurie apibūdina suinteresuotosios šalies ar suinteresuotųjų šalių grupės poreikius.

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

o Funkciniai reikalavimai apibūdina gaminio elgesį. Pavyzdžiai apima procesus, duomenis ir produktų sąveiką.

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

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

· Projekto reikalavimuose aprašomos veiklos, procesai ar kitos sąlygos, kurias turi atitikti projektas.

· Kokybės reikalavimai, apimantys bet kokias sąlygas ar kriterijus, būtinus sėkmingam projekto rezultato pristatymui ar kitiems projekto reikalavimams patvirtinti.

6. PROJEKTŲ LAIKO VALDYMAS

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

Veiklos priklausomybės tipai:

· Baigti startą(finišas-startas, FS). Loginis ryšys, kuriame kitos veiklos pradžia priklauso nuo ankstesnės veiklos pabaigos. Pavyzdys: apdovanojimų ceremonija (paskesnė operacija) negali būti pradėta tol, kol nesibaigė ankstesnės operacijos lenktynės).

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

· Startas-pradžia(startas-startas, SS). Loginis ryšys, kuriame tolesnės operacijos pradžia priklauso nuo pirmtako operacijos pradžios. Pavyzdys: Betono paviršiaus išlyginimas (toliau operacija) negali prasidėti prieš išliejant pamatą (ankstesnė 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 sargybos pamaina (paskesnė operacija) negali baigtis, kol neprasidės antroji apsaugos pamaina (ankstesnė operacija).

Trijų taškų įvertinimas

Vieno taško veiklos trukmės įverčių tikslumą galima pagerinti į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ų atlikimą, realų jų prieinamumo šiai operacijai įvertinimą, priklausomybes nuo kitų dalyvių, taip pat į darbo pertrūkius.

· optimistiškas(kam). 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 paskirstymas. tE = (tO + tM + tP) / 3

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

Kritinio kelio metodas

Kritinio kelio metodas yra metodas, naudojamas apskaičiuoti minimalią projekto trukmę ir nustatyti planavimo lankstumo laipsnį loginiuose keliuose tinkle pagal planavimo modelį. Tinklo analizės metodas apskaičiuoja ankstyvą pradžios ir pabaigos datas, taip pat vėlyvas pradžios ir pabaigos datas visoms veikloms, neatsižvelgiant į išteklių apribojimus, atlikdamas pirmyn ir atgal perdavimo analizę per projekto tinklą, kaip parodyta Fig. 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, kuri yra ilgiausias kelias projekto tvarkaraštyje ir apibrėžia trumpiausią įmanomą projekto trukmę. Gautos ankstyvos pradžios ir pabaigos datos nebūtinai yra projekto tvarkaraštis; veikiau jie nurodo laiko periodus, per kuriuos galima atlikti operaciją, naudojant parametrus, įvestus į grafiko modelį, susijusius su operacijų trukmėmis, loginėmis nuorodomis, laidais, vėlavimais ir kitais žinomais apribojimais. Kritinis metodas

kelias naudojamas planavimo lankstumo laipsniui apskaičiuoti tinklo loginiuose keliuose pagal planavimo modelį.

Kritinės grandinės metodas

Kritinės grandinės metodas(CCM) yra tvarkaraščio kūrimo technika, leidžianti 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ų išlyginimo ir

neapibrėžtumas dėl veiklos trukmės kritiniame kelyje, kaip nustatyta 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 operacijų konkrečiuose projekto taškuose pagal projekto tvarkaraštį, kad būtų atsižvelgta į ribotus išteklius ir su projektu susijusius neapibrėžtumus. Kritinis kelias su išteklių apribojimais žinomas kaip „kritinė grandinė“.

7. PROJEKTO IŠLAIDŲ VALDYMAS

Projekto išlaidų valdymas apima procesus, reikalingus planuoti, įvertinti, sudaryti biudžetą, kaupti lėšas, finansuoti, valdyti ir kontroliuoti išlaidas, siekiant užtikrinti, kad projektas būtų įgyvendintas 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 eigą ir našumą. Tai plačiai naudojamas projekto našumo matavimo metodas. Jis sujungia bazinę apimties liniją su sąnaudų bazine linija ir projekto tvarkaraščio bazine linija, kad sudarytų bazinę našumo 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. EVM kuria ir stebi tris pagrindines kiekvieno darbo paketo ir valdymo paskyros metrikas:

· Planuojamas tūris. Planuojama apimtis (PV) – planuojamai veiklai skirtas įgaliotas biudžetas. Tai yra patvirtintas biudžetas, skirtas atlikti darbus pagal veiklos arba darbų suskirstymo struktūros komponentą, neįskaitant valdymo pašalpos. Šis biudžetas yra skiriamas projekto gyvavimo ciklo etapams, tačiau tam tikru momentu planuojama apimtis nulemia fizinį darbą, kurį reikia atlikti. Kaupiamoji programinė įranga kartais vadinama našumo matavimo bazine linija (PMB). Visas projekto biudžetas taip pat žinomas kaip baigiamasis biudžetas (BFC).

· Uždirbta vertė. Uždirbta vertė (EV) – atliktų darbų kiekis, išreikštas autorizuotam šiam darbui skirtu 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. OO dažnai naudojamas projekto baigtumo procentams apskaičiuoti. Kiekvienam WBS komponentui turėtų būti nustatyti atlikto darbo eigos vertinimo kriterijai. Projektų vadovai stebi TOE tiek laipsniškai, kad nustatytų dabartinę būseną, tiek bendrai, kad nustatytų ilgalaikes veiklos tendencijas.

· tikroji kaina. Faktinės išlaidos (FC) – faktinės sąnaudos, patirtos atliekant darbą per operaciją tam tikrą laikotarpį. Tai visos išlaidos, patirtos atliekant darbus, matuojamos TOE. FS pagal apibrėžimą turėtų atitikti tai, kas buvo įtraukta į programinę įrangą ir išmatuota TOE (pavyzdžiui, tik tiesioginės darbo valandų išlaidos, tik tiesioginės išlaidos arba visos išlaidos, įskaitant netiesiogines). FS neturi viršutinės ribos; matuojama viskas, kas išleidžiama TOE pasiekti.

Taip pat stebimi nukrypimai nuo patvirtinto pradinio lygio:

· Laiko nuokrypis. Laiko dispersija (RTV) yra tvarkaraščio našumo rodiklis, išreikštas kaip skirtumas tarp uždirbtos vertės ir suplanuotos vertės. Laikas, per kurį projektas vėluoja arba lenkia planuojamą pristatymo datą tam tikru momentu. Tai yra projekto grafiko vykdymo matas. Jo vertė lygi uždirbtai vertei (OO), atėmus planuojamą vertę (PV). Laiko dispersija EVM yra naudinga metrika, nes ji parodo, kada projektas atsilieka nuo pradinio lygio arba lenkia jį. Projekto pabaigoje EVM laiko nuokrypis bus lygus nuliui, nes iki to laiko visi suplanuoti kiekiai turėjo būti įvykdyti. Laiko dispersiją geriausia naudoti kartu su kritinio kelio metodo (CPM) planavimu ir rizikos valdymu. Formulė: OSR \u003d OO - PO

· Sąnaudų nuokrypis. Išlaidų dispersija (CV) yra biudžeto deficito arba pertekliaus suma tam tikru momentu, išreikšta skirtumu tarp uždirbtos vertės ir faktinių išlaidų. Tai yra projekto išlaidų efektyvumo matas. Jis lygus uždirbtai vertei (EV), atėmus faktines išlaidas (FC). Sąnaudų nuokrypis projekto pabaigoje bus lygus skirtumui tarp užbaigto biudžeto (BPC) ir faktiškai išleistos sumos. OST yra nepaprastai svarbus, nes parodo ryšį tarp fizinės veiklos ir išleistų lėšų. Neigiamas OST dažnai neatgaunamas projektui. Formulė: OST \u003d OO - FS.

OSR ir TSR vertes galima konvertuoti į našumo rodiklius, kad atspindėtų bet kurio projekto sąnaudas ir laiką, palyginti su visais kitais projektais arba projektų portfelyje. Nukrypimai yra naudingi nustatant projekto būseną.

· Termino našumo indeksas. Laiko užbaigimo indeksas (TII) yra grafiko našumo rodiklis, išreikštas uždirbtos vertės ir planuojamos vertės santykiu. Jis matuoja, kaip efektyviai projekto komanda naudoja savo laiką. Kartais jis naudojamas kartu su išlaidų įvykdymo indeksu (CFI), kad būtų galima numatyti galutinius projekto užbaigimo įvertinimus. WRI reikšmė mažesnė nei 1,0 rodo, kad atlikta mažiau darbų nei planuota. WPI reikšmė didesnė nei 1,0 rodo, kad atlikta daugiau darbų nei planuota. Kadangi RIMS matuoja visą projekto darbą, taip pat būtina išanalizuoti našumą kritiniame kelyje, kad būtų galima nustatyti, ar projektas bus baigtas prieš ar po jo numatytos pabaigos datos. RIVR yra lygus OO ir programinės įrangos santykiui. Formulė: IVSR \u003d OO / PO

· Išlaidų vykdymo indeksas. Sąnaudų efektyvumo indeksas (CFI) yra biudžete numatytų išteklių sąnaudų efektyvumo matas, išreikštas uždirbtos vertės ir faktinių išlaidų santykiu. Tai laikoma svarbiausia EVM metrika ir matuoja atlikto darbo ekonomiškumą. Mažesnė nei 1,0 PVCT reikšmė rodo atlikto darbo viršijimą. Didesnė nei 1,0 PICT reikšmė rodo nepakankamą lėšų panaudojimą, kai įvykdoma tam tikrą dieną. RIVR yra lygus TOE ir FS santykiui. Indeksai yra naudingi nustatant projekto būseną, taip pat suteikia pagrindą įvertinti bendrą projekto laiką ir išlaidas. Formulė: IVST = OO / FS

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

Prognozavimas

Vykstant projektui, projekto komanda gali parengti užbaigtą biudžetą (CPC), kuris gali skirtis nuo biudžeto užbaigimo (BPC), atsižvelgiant į projekto rezultatus. Jei paaiškėja, kad BPP nebėra realus, projekto vadovas turėtų peržiūrėti PPP. PPP kūrimas apima sąlygų ir įvykių, kurie įvyks projekto ateityje, prognozavimą, remiantis informacija apie esamus rezultatus ir kitomis prognozavimo metu turimomis žiniomis. Prognozės generuojamos, atnaujinamos ir iš naujo išduodamos remiantis

veiklos duomenys, gauti projekto eigoje. Darbo našumo informacija apima ankstesnį projekto vykdymą ir bet kokią informaciją, kuri gali turėti įtakos projektui ateityje.

PGP paprastai apskaičiuojamas kaip faktinės atlikto darbo sąnaudos ir likusių darbų prognozė iki užbaigimo (EPC). Projekto komandai pavesta numatyti, su kuo ji gali susidurti įgyvendindama EVP, remiantis dabartine patirtimi. EVM metodas puikiai veikia kartu su rankiniu būdu sukurtomis reikalingo LTF prognozėmis. Plačiausiai naudojamas KPP prognozavimo metodas yra projekto vadovo ir projekto komandos rankinis apibendrinimas iš apačios į viršų.

Projekto vadovo taikomas „iš apačios į viršų“ PPP metodas yra pagrįstas faktinių sąnaudų apskaita ir atliktų darbų patirtimi, todėl prieš užbaigiant likusius projekto darbus reikia sudaryti naują prognozę. Formulė: PPP \u003d FS + PDZ „iš apačios į viršų“.

Projekto vadovo rankiniu būdu sukurtas PPV greitai palyginamas su apskaičiuotų PPV rinkiniu, atspindinčiu įvairius rizikos scenarijus. Skaičiuojant PPV reikšmes, paprastai naudojamos suminės TIWT ir TIVR reikšmės. Nors EVM duomenys greitai pateikia daug statistinių PPV, toliau aprašomi tik trys dažniausiai naudojami metodai:

· PPP VPSP darbams, atliekamiems pagal biudžetinius įkainius. Šis PPP metodas naudoja faktinį projekto našumą konkrečią datą (gerą ar blogą), atspindintį 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 tuo atveju, jei tai patvirtina projekto rizikos analizė. Formulė: PPZ = FS + (BPZ - OO)

· PPP VPSP darbams, atliekamiems su dabartine IVST. Taikant šį metodą daroma prielaida, kad projektas bus tęsiamas ir ateityje taip pat, kaip buvo tęsiamas iki šiol. Daroma prielaida, kad EP veikla bus vykdoma pagal tą patį kaupiamojo sąnaudų efektyvumo indekso (CPI) lygį, koks iki šiol buvo pasiektas įgyvendinant projektą. Formulė: PPZ = BPZ / IVST

· PPZ PDZ darbams, atsižvelgiant į abu veiksnius PVSR ir CVST. Šioje prognozėje PD darbas bus atliktas efektyviai, atsižvelgiant į tiek sąnaudų, tiek laiko veiklos rodiklius. Šis metodas yra naudingiausias, kai vienas iš veiksnių, turinčių įtakos EAP, yra projekto grafikas. Šio metodo variantai įvertina RVSI ir RVSR įvairiais santykiais (pvz., 80/20, 50/50 ar kitomis proporcijomis), atsižvelgiant į projekto vadovo nuomonę. Formulė: PPZ = FS + [(BPZ - OO) / (IVST x EVSR)]

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

Našumo iki užbaigimo indeksas (PPI)

Našumo indeksas iki pabaigos(IBPI) – tai numatomas projekto kaštų efektyvumas, kurį reikia pasiekti su likusiais ištekliais, kad būtų pasiektas nustatytas valdymo tikslas, išreikštas likusios darbų dalies užbaigimo sąnaudų ir likusio biudžeto santykiu. BPI yra apskaičiuotas išlaidų efektyvumo indeksas, kuris turi būti pasiektas likusiose darbo vietose, kad būtų pasiektas konkretus valdymo tikslas, pvz., BPP arba BPP. Jei paaiškėja, kad BPP nebėra realus, projekto vadovas turėtų peržiūrėti PPP. Patvirtinus, PPP gali pakeisti BPI skaičiuojant EITI. BPHI formulė, pagrįsta BPZ, yra (BPZ – GS)/(BPZ – FS). EITI konceptualiai pavaizduotas toliau pateiktame paveikslėlyje. EITI formulė parodyta apatiniame kairiajame kampe kaip likęs darbas (apibrėžiamas kaip BPV atėmus QA), padalytas iš likusių lėšų (kurios gali būti apskaičiuotos kaip BPV atėmus FS arba RP atėmus FS).

Jei kaupiamasis TFI yra mažesnis už bazinę liniją (kaip parodyta paveikslėlyje toliau), visi būsimi projekto darbai turi būti nedelsiant atlikti pagal EITI (BOI) (kaip parodyta viršutinėje paveikslo eilutėje toliau). likti įgaliotame BPO. Ar galima pasiekti tam tikrą našumo lygį, sprendžiama remiantis daugeliu aspektų, įskaitant riziką, tvarkaraštį ir techninius rezultatus. Šis našumo lygis pavaizduotas kaip IPDZ (PPZ) linija. PPP pagrįsto PPP formulė yra (BPP – GS)/(PPP – FS). EVM formulės pateiktos toliau esančioje lentelėje.

Veiklos analizė

Našumo analizė lygina išlaidų našumą per tam tikrą laiką, suplanuoja veiklą arba darbų paketus, kurie viršija arba per mažai numatė biudžetą, ir apskaičiuoja pinigų, reikalingų atliekamam darbui atlikti. Jei naudojamas EVM, apibrėžiama ši informacija:

· Nukrypimų analizė. Dispersijos analizė, kai naudojama EVM, yra išlaidų (CST = TS - FS), tvarkaraščio (SSR = TS - TS) ir dispersijos užbaigimo (CPV = BPV - CPV) skirtumų paaiškinimas (priežastis, poveikis ir korekciniai veiksmai). . Dažniausiai analizuojami nukrypimai yra sąnaudos ir laikas. Projektams, kuriuose netaikomas uždirbtos vertės valdymas, panašią dispersijos analizę galima atlikti lyginant planuojamas operacijos išlaidas su faktinėmis operacijos išlaidomis, kad būtų galima nustatyti skirtumus tarp faktinio projekto vykdymo ir pradinės sąnaudos. Galima atlikti tolesnę analizę, siekiant nustatyti nukrypimo nuo pradinio lygio priežastį ir mastą bei būtinus korekcinius ar prevencinius veiksmus. Išlaidų įvykdymo matavimai naudojami norint įvertinti nukrypimo nuo pradinės sąnaudų vertės dydį. Svarbūs projekto išlaidų valdymo aspektai apima nukrypimo nuo pradinės sąnaudos priežasties ir masto nustatymą bei sprendimą, ar reikia korekcinių ar prevencinių veiksmų. Atliekant vis daugiau darbo, procentinės paklaidos diapazonas bus linkęs mažėti.

· 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 naudingi norint suprasti našumą tam tikrą dieną ir palyginti su būsimais BPO našumo tikslais, palyginti su PPP ir užbaigimo datos formatais.

· Uždirbtos vertės vykdymas. Uždirbtos vertės vykdymas apima pradinio veiklos plano palyginimą su faktiniu laiko ir sąnaudų našumu. Jei EVM nenaudojamas, sąnaudų vykdymo palyginimui naudojama pradinių sąnaudų analizė 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 valdymo sistemą projekto kontekste ir, jei reikia, palaiko nuolatinį vykdančios 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 duodama produkcija arba rezultatas yra „laipsnis, kuriuo būdingų charakteristikų rinkinys atitinka reikalavimus“ (ISO 9000). Įvertinimas kaip projektavimo tikslas – tai kategorija, priskirta rezultatams, kurių funkcionalumas yra tas pats, bet skiriasi specifikacijos. Projekto vadovas ir projekto valdymo komanda yra atsakingi už kompromisų siekimą, kad būtų užtikrintas reikiamas kokybės ir lygio lygis. Kokybės reikalavimų neatitinkantis kokybės lygis visada yra problema, o žemas įvertinimas gali būti ne problema.

Siekiant atitikties ISO kontekste, modernūs kokybės valdymo metodai siekia kuo labiau sumažinti nukrypimus ir pasiekti tam tikrus reikalavimus atitinkančių rezultatų. Šie metodai pripažįsta šių dalykų svarbą:

· Klientų pasitenkinimas. Klientų reikalavimų supratimas, įvertinimas, nustatymas ir valdymas, siekiant patenkinti klientų lūkesčius. Tam reikia derinti tinkamumą (projektas turi sukurti tai, ko buvo imtasi) ir tinkamumą naudoti (produktas ar paslauga turi atitikti realius poreikius).

· Prevencija yra svarbesnė už patikrinimą. Kokybė turėtų būti planuojama, plėtojama ir įdiegta, o ne tikrinama projektų valdymo ar projekto rezultatų pristatymo metu. Klaidų prevencijos kaina paprastai yra daug mažesnė nei jų ištaisymo kaina, kai jos buvo aptiktos patikrinimo ar 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 Lean Six Sigma kartu gali pagerinti projekto valdymo kokybę ir projekto produkto kokybę. Proceso tobulinimo modeliai apima Malcolmo Baldridge 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ž reikiamų išteklių tiekimą reikiamu kiekiu.

· Kokybės kaina(kokybės kaina, COQ). Kokybės kaina yra bendros atitikties darbo ir neatitikimo darbų, kurie turi būti atliekami kaip kompensacinės pastangos, sąnaudos, nes pirmą kartą bandant atlikti darbą, yra galimybė, kad dalis reikiamo darbo kiekio gali būti arba ne. buvo padaryta neteisingai.. Kokybės užtikrinimo veiklos išlaidos gali atsirasti per visą produkto gyvavimo ciklą. Pavyzdžiui, projekto komandos priimti sprendimai gali turėti įtakos veiklos išlaidoms, susijusioms su užbaigto rezultato naudojimu. Kokybės išlaidos po uždarymo gali atsirasti dėl produktų grąžinimo, pretenzijų dėl garantijos ir gaminių atšaukimo kampanijų. Taigi, dėl laikino projekto pobūdžio ir galimos naudos, kurią galima gauti sumažinus poprojektines kokybės išlaidas, remiančios organizacijos gali nuspręsti investuoti į produktų kokybės gerinimą. Šios investicijos paprastai skiriamos atitikties darbų srityje, siekiant išvengti defektų arba sumažinti defektų kainą, tikrinant reikalavimų neatitinkančius įrenginius. Be to, su poprojektiniu COQ susiję klausimai turėtų būti sprendžiami programos valdymo ir portfelio valdymo procese, pavyzdžiui, projektų, programų ir portfelio valdymo biurai turėtų taikyti tam tinkamus analizės metodus, šablonus ir lėšų paskirstymo metodus.

Septynios esminės kokybės priemonės

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

· Priežasties ir pasekmės diagramos, dar vadinamos žuvies kaulų diagramomis arba Ishikawa diagramomis. Problemos aprašymas, esantis žuvies kaulo galvoje, yra naudojamas kaip išeities taškas norint atsekti problemos šaltinį iki pagrindinės priežasties, dėl kurios reikia imtis veiksmų. Problemos aprašymas paprastai yra problemos kaip spragos, kurią reikia pašalinti, arba tikslo, kurį reikia pasiekti, pareiškimas. Priežasčių paieška atliekama išnagrinėjus problemos aprašymą ir ieškant atsakymų į klausimą „kodėl“, kol bus nustatyta pagrindinė priežastis, dėl kurios reikia imtis veiksmų, arba kol išnaudotos visos pagrįstos galimybės kiekvienoje žuvies skeleto dalyje. Žuvies kaulų diagramos dažnai yra naudingos, kai bandoma susieti nepageidaujamą poveikį, matomą kaip konkretų pokytį, su nustatyta priežastimi, dėl kurios projekto komandos turi imtis taisomųjų veiksmų, kad pašalintų tą konkretų valdymo diagramoje esantį pokytį.

· Struktūrinės schemos, 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ų vykdymo tvarką, kaip žemėlapį pateikdamos procedūrų, kurios egzistuoja horizontalioje SIPOC modelio vertės grandinėje, detales. Struktūrinės diagramos gali padėti suprasti ir įvertinti proceso kokybės sąnaudas. Tai pasiekiama naudojant darbo eigos šakojimo logiką ir su ja susijusius santykinius dažnius, siekiant įvertinti numatomą atitikties darbo ir neatitikties darbų piniginę vertę, reikalingą norint pateikti atitinkamą rezultatą.

· 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 tvarkyti faktus taip, kad būtų veiksmingai užfiksuoti naudingi duomenys apie galimą kokybės problemą. Jie ypač naudingi renkant parametrų duomenis patikrų metu, siekiant nustatyti defektus. Pavyzdžiui, naudojant duomenų rinkimo lapus surinkti duomenys apie defektų dažnį ar pasekmes 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ą, atsižvelgiant į 100 % galimų stebėjimų. Kiekvienos pažymėtos priežasties atitinkamo pasireiškimo dažnio reikšmė, parodyta horizontalioje ašyje, mažėja, kol pasiekiamas numatytasis šaltinis, vadinamas „kita“, kuris yra atsakingas už nenurodytas priežastis. Paprastai Pareto diagrama suskirstyta į kategorijas, kurios matuoja pasireiškimo dažnumą arba pasekmes.

· Histogramos yra speciali juostinė diagrama, naudojama apibūdinti pasiskirstymo 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 nustatytais reikalavimais. Jie atspindi didžiausias ir mažiausias leistinas vertes. Gali būti taikomos nuobaudos, susijusios su verčių, viršijančių specifikacijoje nustatytas ribas, išvedimu. Viršutinė ir apatinė valdymo ribos skiriasi nuo specifikacijoje nurodytų ribų. Kontrolės ribos nustatomos naudojant standartinius statistinius skaičiavimus ir principus, siekiant galutinai nustatyti natūralią proceso stabilizavimo galimybę. 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 paprastai yra išlaikyti natūralų stabilaus ir veiksmingo proceso stabilumą. Pasikartojančių procesų valdymo ribos paprastai yra ±3 sigmos proceso vidurkio, kuris nustatytas į 0. Procesas laikomas nekontroliuojamu, jei: (1) duomenų taškas yra už valdymo ribų; (2) septyni iš eilės taškai yra virš vidurinės linijos; arba (3) septyni iš eilės taškai yra žemiau vidurinės linijos. Valdymo diagramos gali būti naudojamos įvairių tipų išvesties kintamiesiems valdyti. Nors dažniausiai naudojami siekiant sekti pasikartojančią veiklą, reikalingą pramoniniams produktams gaminti, jos taip pat gali būti naudojamos kontroliuoti sąnaudų ir tvarkaraščio skirtumus, apimties ir apimties pokyčių dažnumą arba kitus valdymo rezultatus, padedančius nustatyti, ar projektų valdymo procesai yra kontroliuojami.

· Sklaidos diagramos brėžiamos sutvarkytos poros (X, Y), kartais vadinamos koreliacijos grafikais, nes jais paaiškinamas priklausomo kintamojo Y pokytis, palyginti su pastebėtu nepriklausomo kintamojo X pokyčiu. Koreliacijos kryptis gali būti proporcinga. (teigiama koreliacija), atvirkštinė (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ę.

Kokybės valdymo ir kontrolės priemonės

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

· Giminystės diagramos. Afiniteto diagrama yra panaši į minčių kartografavimą, nes ji naudojama idėjoms generuoti, kurias galima derinti, kad susidarytų tvarkingas mąstymo apie problemą būdas. Projekto valdymo procese WBS kūrimas gali būti patobulintas naudojant giminingumo diagramą turinio skaidymo struktūrai.

· Programos įgyvendinimo eigos schemos(proceso sprendimų programos diagramos, PDPC). Naudojamas siekiant suprasti tikslą, susijusį su veiksmais, kurių buvo imtasi tikslui pasiekti. PDPC yra naudinga nuostolių planavimo technika, nes ji padeda komandoms numatyti tarpinius veiksmus, kurie gali trukdyti pasiekti tikslą.

· Orientuoti santykių grafikai. Santykių diagramų pritaikymas. Orientuoti santykių grafikai yra kūrybiško problemų sprendimo procesas vidutiniškai sudėtinguose scenarijuose, kuriems būdingi susipynę loginiai ryšiai iš iki 50 susijusių elementų. 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ų, pvz., WBS, rizikos skirstymo struktūros (RBS) ir organizacinės suskirstymo struktūros (OBS), skaidymą. Valdant projektus medžio diagramos yra naudingos norint vizualizuoti tėvų ir antrinių santykių hierarchiją, kuri naudoja sistemingą taisyklių rinkinį ataskaitų teikimo ryšiams apibrėžti. Medžių diagramos gali būti horizontalios (pvz., rizikos hierarchija) arba vertikalios (pvz., komandos hierarchija arba OBS). Kadangi medžio diagramos leidžia įdėti įdėtas šakas, kurios baigiasi vienu sprendimo tašku, jos yra naudingos kaip sprendimų medžiai nustatant tikėtiną riboto skaičiaus ryšių, kurie sistemingai brėžiami, vertę.

· Prioritetinės matricos. Naudojamas siekiant nustatyti pagrindines problemas ir tinkamas alternatyvas, kurias galima teikti pirmenybe, kaip įgyvendinimo sprendimų rinkinį. Kriterijai yra suskirstyti į prioritetus ir pasverti prieš juos pritaikant visoms galimoms alternatyvoms, kad būtų gautas matematinis balas, leidžiantis įvertinti visas alternatyvas.

· Operacijų tinklo diagramos. Anksčiau vadintos rodyklėmis. Jie apima tokius tinklo diagramų formatus kaip operacijos su lankais (aktyvumas rodyklėje, AOA) ir dažniausiai naudojamas operacijos formatas mazguose (veikla mazge, AON). Veiklos tinklo diagramos naudojamos su projektų planavimo metodais, tokiais kaip programos vertinimo ir peržiūros metodas (PERT), kritinio kelio metodas (CPM) ir pirmumo diagramos metodas (PDM).

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

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, kurie yra apibrėžę vaidmenis ir atsakomybę už projekto įgyvendinimą. Projekto komandos nariai gali turėti skirtingus įgūdžius, gali 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 yra priskirti specifiniai vaidmenys ir atsakomybė, visų komandos narių dalyvavimas projekto planavime ir sprendimų priėmime yra vertingas projektui. Komandos narių įtraukimas leidžia panaudoti turimą patirtį projektų planavime 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 projekto užduotys pateikiamos pagalbiniuose planuose, pvz., rizikos, kokybės ar komunikacijos planuose. Nepriklausomai nuo to, koks metodas naudojamas, tikslas visada yra tas pats – užtikrinti, kad kiekvienas darbo paketas turėtų nedviprasmišką atsakomybę už jo vykdymą ir kad kiekvienas komandos narys aiškiai suprastų savo vaidmenį ir pareigas. Pavyzdžiui, hierarchinis formatas gali būti naudojamas aukšto lygio vaidmenims atstovauti, teksto formatas geriau tinka išsamiai dokumentuoti atsakomybės sritis.

Žmogiškųjų išteklių valdymo planas, be kitų dalykų, apima:

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

o Vaidmuo. Darbuotojo priimta arba projekto darbuotojui 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. Teisė skirti projekto išteklius, priimti sprendimus, pasirašyti patvirtinimus, priimti rezultatus ir daryti įtaką kitiems komandos nariams atlikti projekto darbus. Sprendimų, kuriems reikalingas aiškus ir tikslus įgaliojimas, pavyzdžiai yra operacijos atlikimo būdo pasirinkimas, kokybės pripažinimas ir kaip reaguoti į projekto nukrypimus. Komandos nariai dirba geriau, kai kiekvieno iš jų autoritetas atitinka individualią atsakomybės sritį.

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, projektui gali kilti pavojus. Nustačius tokius neatitikimus, reikėtų imtis prevencinių veiksmų, pavyzdžiui, apmokyti, samdyti kvalifikuotus specialistus arba atlikti atitinkamus projekto grafiko ar apimties pakeitimus.

Projekto organizavimo schemos. Projekto organizacijos diagrama 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 organizacijos diagrama, kurioje dirba 20 žmonių.

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

o Įdarbinimas. Planuojant projekto komandos narių įdarbinimą, iškyla nemažai klausimų. Pavyzdžiui, ar bus naudojami esami organizacijos žmogiškieji ištekliai, ar jie bus samdomi iš išorės sutarties pagrindu; ar komandos nariai dirbs toje pačioje vietoje, ar gali dirbti nuotoliniu būdu; kokia kaina atitinka kiekvieną projektui reikalingą įgūdžių lygį; ir kokio lygio projekto komandos paramą gali suteikti organizacijos žmogiškųjų išteklių skyrius ir funkciniai vadovai.

o Išteklių kalendoriai. Kalendoriai, nustatantys konkretaus resurso prieinamumą tam tikromis darbo dienomis ir pamainomis. Personalo planas nurodo projekto komandos narių individualių ir kolektyvinių įsitraukimų laiką, taip pat laikas, kada turėtų prasidėti įdarbinimo veikla, pvz., darbuotojų samdymas. Vienas iš žmogiškųjų išteklių diagramų sudarymo įrankių yra išteklių juostinė diagrama, kurią projekto valdymo komanda naudoja kaip priemonę vizualizuoti 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 metu. Diagramoje gali būti horizontali linija, nurodanti maksimalų valandų skaičių, apskaičiuotą tam tikram ištekliui. Jei diagramos juostos yra už maksimalių galimų valandų ribų, 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 projektų įsipareigojimų, naudinga tiek projektui, tiek komandos nariams. Kai komandos nariai yra atleidžiami nuo dalyvavimo projekte, tai pašalina mokėjimus darbuotojams, kurie jau atliko savo darbo dalį projekte, ir taip sumažinamos projekto išlaidos. 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 įgyvendinimo metu arba jo pabaigoje.

o Mokymų poreikiai. Jei nerimaujama, kad projektui priskirtų komandos narių kvalifikacijos gali nepakakti, tuomet į projekto planą reikėtų parengti personalo mokymo planą. Į planą taip pat gali būti įtrauktos komandos narių mokymo programos, kurios padės gauti sertifikatus, kurie prisidės prie sėkmingo projekto užbaigimo.

o Pripažinimas ir apdovanojimai. Aiškūs kriterijai ir suplanuota atlygio sistema padeda paskatinti ir palaikyti norimą projekte dalyvaujančių žmonių elgesį. Kad pripažinimas ir apdovanojimai būtų veiksmingi, jie turi būti pagrįsti asmens kontroliuojamais veiksmais, rezultatais ir našumu. Pavyzdžiui, komandos narys gali būti apdovanotas tik už tam tikros išlaidų normos atitikimą, jei jis turi pakankamai įgaliojimų kontroliuoti sprendimus, turinčius įtakos sąnaudoms. Sudarius planą su atlygio laiku, atlygis nebus pamirštas. Pripažinimas ir apdovanojimai yra projekto komandos tobulinimo proceso dalis.

o Atitiktis. Į personalo valdymo planą gali būti įtrauktos strategijos, skirtos užtikrinti, kad projektas atitiktų esamus vyriausybės reglamentus, darbo sutarčių sąlygas ir kitą nustatytą žmogiškųjų išteklių politiką.

o Saugumas. Personalo planas, taip pat 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 & Jensen, 1977), apimančios penkis vystymosi etapus, kuriuos komandos turi pereiti. Dažniausiai šie etapai ateina eilės tvarka, tačiau neretai komanda užstringa tam tikrame etape arba grįžta į 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 formalius savo vaidmenis ir atsakomybę jame. Komandos nariai šioje fazėje linkę būti nepriklausomi vienas nuo kito ir ne itin 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. Prisitaikymo etape komandos nariai pradeda dirbti kartu ir koreguoja savo darbo įpročius bei elgesį, kad palengvintų komandinį darbą. Komandos nariai išmoksta pasitikėti vieni kitais.

· Efektyvumas. Spektaklio sceną pasiekusios komandos funkcionuoja 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 žmonės atleidžiami iš projekto po to, kai baigiami rezultatai, arba kai projekto uždarymo proceso ar etapo dalis.

Kiekvieno konkretaus etapo trukmė priklauso nuo komandos dinamikos, jėgos ir lyderystės. Projektų vadovai turi gerai suprasti komandos vystymosi dinamiką, kad komandos nariai galėtų efektyviai pereiti visus etapus.

Yra penki pagrindiniai konfliktų sprendimo būdai.

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

· Vengimas/vengimas. Nukrypimas iš 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 / prigludimas. Sąlyčio taškų akcentavimas vietoj prieštaravimų, savo pozicijos atsisakymas kitų poreikių naudai, siekiant išlaikyti harmoniją ir santykius.

· Kompromisas/atsiskaitymas. Ieškoma sprendimų, kurie tam tikru mastu tenkintų visas šalis, siekiant laikinai arba iš dalies išspręsti konfliktą.

· Prievarta / nurodymai. Lobizmas dėl kažkieno požiūrio kitų sąskaita, siūlo tik „vienas laimi, visi pralaimi“ sprendimus, dažniausiai iš galios pozicijų, siekiant išspręsti kritinę situaciją.

· Bendradarbiavimas/problemų sprendimas. Daugelio požiūrių ir požiūrių iš skirtingų perspektyvų derinimas, bendradarbiavimo ir atviro dialogo poreikis, dėl kurio dažniausiai pasiekiamas visų šalių sutarimas ir pritarimas sprendimui.

Tarpasmeninių įgūdžių pavyzdžiai kuriuos dažniausiai naudoja projekto vadovas:

· Vadovavimas. Kad projektas būtų sėkmingas, reikalingi išlavinti lyderystės įgūdžiai. Lyderystė yra svarbi visuose projekto gyvavimo ciklo etapuose. Egzistuoja daug lyderystės teorijų, apibrėžiančių vadovavimo stilius, kurias esant reikalui kiekviena komanda turėtų panaudoti 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 galios savo komandos nariams pagal matricą, jų gebėjimas laiku daryti įtaką projekto dalyviams yra labai svarbus projekto sėkmei. Pagrindiniai influencerio įgūdžiai:

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

o aukšto lygio aktyvaus ir efektyvaus klausymosi įgūdžiai;

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. Štai keletas rekomendacijų priimant sprendimą:

o reikia sutelkti dėmesį į siektinus tikslus;

o turi būti laikomasi sprendimų priėmimo procedūrų;

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į kolektyvo 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 vykdymui ar rezultatams.

Veiksniai, galintys turėti įtakos pasirenkant ryšių technologiją, yra šie:

· Informacijos gavimo skubumas. Reikia atsižvelgti į informacijos, kuri turi būti teikiama, skubumą, dažnumą ir formatą, nes tai gali skirtis atsižvelgiant į projektą ir skirtinguose to paties projekto etapuose.

· Technologijos prieinamumas. Turi būti užtikrinta, kad technologija, reikalinga komunikacijai užtikrinti, būtų suderinama ir prieinama visoms suinteresuotosioms šalims per visą projekto laikotarpį.

· Naudojimo paprastumas. Turi būti užtikrinta, 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 projekto aplinkoje yra kokių nors kitų veiksnių, tokių kaip kultūra, galinčių turėti įtakos komunikacijai.

· Informacijos slaptumas ir konfidencialumas. Būtina nustatyti, ar perduodama informacija yra įslaptinta, ar konfidenciali ir ar jai apsaugoti reikalingos papildomos priemonės. Taip pat reikėtų apsvarstyti tinkamiausias tokios informacijos perdavimo priemones.

Pagrindinis komunikacijos modelis turi tokią veiksmų seką:

· Kodavimas. Siuntėjo vykdomas minčių ar idėjų pavertimas (kodavimas) į kodų kalbą.

· Siunčia žinutę. Siuntėjo informacijos siuntimas informacijos kanalu (informacijos perdavimo terpe). Įvairūs veiksniai (pvz., atstumas, nepažįstamos technologijos, nepakankama infrastruktūra, kultūriniai skirtumai ir papildomos informacijos trūkumas) gali trukdyti perduoti šią žinią. Š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 žinutė gauta, tačiau tai nebūtinai reiškia, kad žinutė priimta ar suprasta.

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

Informacijos sklaidai tarp projekto suinteresuotųjų šalių naudojami keli komunikacijos būdai.

Šiuos metodus galima suskirstyti į šias dideles grupes:

· Interaktyvus bendravimas. Tarp dviejų ar daugiau šalių, dalyvaujančių daugiašaliuose informacijos mainuose. Šis metodas yra veiksmingiausias siekiant užtikrinti, kad visi dalyviai bendrai suprastų tam tikras problemas; tai apima susitikimus, 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. Nepageidaujama komunikacija apima laiškus, pastabas, ataskaitas, el. laiškus, faksogramas, balso pašto žinutes, tinklaraščius, pranešimus spaudai ir kt.

· Bendravimas pagal pareikalavimą. Naudojamas labai dideliems informacijos kiekiams arba labai didelei auditorijai ir reikalauja, kad gavėjai savo noru pasiektų perduodamą turinį. Tokie metodai apima intraneto svetaines, el. mokymąsi, išmoktų pamokų duomenų bazes, žinių saugyklas ir kt.

Veiksmingo komunikacijos valdymo metodai ir aspektai apima, bet neapsiriboja:

Siuntėjo-gavėjo modelis. Įdiekite grįžtamojo ryšio kilpas, kad sudarytumėte palankias galimybes įsitraukti / dalyvauti ir pašalinti bendravimo kliūtis.

· Ryšio priemonių pasirinkimas. Situacijų pasirinkimas, kada bendrauti žodžiu, o kada raštu, kada rengti neoficialius užrašus ir kada pateikti oficialią ataskaitą, o kada kalbėti asmeniškai, o ne el. paštu.

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

· Posėdžių 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 metodai. Aktyvus klausymas (supratimo patvirtinimas, paaiškinimas ir patikrinimas) ir kliūčių, galinčių iškreipti supratimą, pašalinimas.

11. PROJEKTO RIZIKOS VALDYMAS

Projekto rizikos valdymas apima procesus, susijusius su rizikos valdymo planavimu, identifikavimu, analize, atsako planavimu ir projekto rizikos kontrole. Projekto rizikos valdymo tikslai – padidinti palankių įvykių tikimybę ir poveikį bei sumažinti nepageidaujamų įvykių tikimybę ir poveikį projekto įgyvendinimo metu.

Projekto rizika yra neaiškus įvykis arba sąlyga, kurios įvykis neigiamai arba teigiamai veikia projekto tikslus, tokius kaip apimtis, tvarkaraštis, kaina ir kokybė. Rizika gali kilti dėl vienos ar kelių priežasčių ir, jei ji atsiranda, gali turėti įtakos vienam ar daugiau aspektų.

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

· Metodika. Metodų, įrankių ir duomenų šaltinių, kurie bus naudojami šio projekto rizikai valdyti, nustatymas.

· Vaidmenys ir pareigos. Kiekvienai į rizikos valdymo planą įtrauktai veiklai vadovaujančių komandos narių, pagalbinių komandos narių ir rizikos valdymo komandos narių nustatymas ir jų atsakomybės išaiškinimas.

· Biudžeto plėtra. Reikalingų lėšų sąmata, atsižvelgiant į skirtus išteklius, įtraukti į bazinį planą sąnaudomis ir rezervo galimiems nuostoliams bei valdymo rezervo panaudojimo procedūrų parengimas.

· Terminų apibrėžimas. Rizikos valdymo procesų laiko ir dažnumo nustatymas per visą projekto gyvavimo ciklą, galimų nuostolių grafiko rezervų panaudojimo procedūrų parengimas, taip pat rizikos valdymo veiklų, kurios bus įtrauktos į projekto grafiką, nustatymas.

· Rizikos kategorijos. Suteikia galimybę suskirstyti galimus rizikos šaltinius. Gali būti naudojami keli metodai, pvz., struktūra, pagrįsta projekto tikslais pagal kategorijas. Rizikos hierarchijos struktūra (RBS) padeda projekto komandai įvertinti 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 arba RBS forma. 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 yra pritaikyti konkrečiam projektui rizikos valdymo planavimo proceso metu ir naudojami tolesniuose procesuose. Žemiau esančioje lentelėje pateikiamas neigiamo poveikio apibrėžimų, kuriuos galima naudoti vertinant su keturiais projekto tikslais susijusios rizikos poveikį, pavyzdys (teigiamam poveikiui galima sukurti panašias lenteles). Žemiau esančioje lentelėje parodytas ir santykinis, ir skaitinis (šiuo atveju netiesinis) metodas.

· Tikimybių ir poveikio matrica. Tikimybių ir poveikio matrica yra lentelė, rodanti kiekvienos rizikos atsiradimo tikimybę ir jos poveikį projekto tikslams, jei ji įvyktų. Rizikos prioritetai nustatomi pagal tikėtinus jų padarinius, kurie gali turėti įtakos projekto tikslams. Įprastas prioritetų nustatymo būdas yra naudoti paieškos lentelę arba tikimybių ir poveikio matricą. Paprastai pati organizacija nustato tikimybės ir poveikio derinius, kurių pagrindu nustatomas „aukštas“, „vidutinis“ arba „žemas“ rizikos lygis.

· Rafinuota suinteresuotųjų šalių tolerancija. Rizikos valdymo planavimo proceso metu suinteresuotųjų šalių tolerancija gali būti koreguojama, kad tiktų konkrečiam projektui.

· Ataskaitų formatai. Ataskaitų teikimo formatai nustato, kaip rizikos valdymo proceso rezultatai bus dokumentuojami, analizuojami ir dalijamasi. Ataskaitų 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 ryšių diagramos.Šios diagramos, dar žinomos kaip Ishikawa diagramos arba žuvų kaulų diagramos, naudojamos rizikos priežastims nustatyti.

· 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 (SSGG), todėl rizikos identifikavimas yra išsamesnis, atsižvelgiant į rizikas 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 visas 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 stiprybės atsveria grėsmes, ir nustatomos galimybės, kurias galima panaudoti trūkumams įveikti.

Rizikos registras

Pagrindinis rizikos nustatymo proceso rezultatas yra pradinis įrašas į rizikos registrą. Rizikos registras yra dokumentas, kuriame pateikiami rizikos analizės ir rizikos reagavimo planavimo rezultatai. Rizikos registre fiksuojami kitų rizikos valdymo procesų rezultatai juos įgyvendinant, todėl laikui bėgant rizikos registre esančios informacijos lygis ir įvairovė didėja. Rizikos registro rengimas pradedamas rizikos nustatymo proceso metu, kurio metu registras užpildomas tokia informacija. Tada ši informacija yra prieinama kitiems su projekto valdymu ir rizikos valdymu susijusiems procesams.

· Nustatytų pavojų sąrašas. Nustatyta rizika yra pakankamai išsamiai aprašyta. Š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 PASEKMES. Be to, sudarant nustatytų pavojų 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 riziką šiame ir kituose projektuose.

· 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, į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 privalumas yra tai, kad jame pateikiama kiekybinė rizikos informacija, padedanti priimti sprendimus, siekiant 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 plačiausiai naudojamiems paskirstymo modeliams reikia rinkti informaciją apie optimistinį (maža tikimybė), pesimistinį (didelė tikimybė) ir labiausiai tikėtiną scenarijų. Rizikos intervalų ir su jomis susijusių prielaidų pagrindimo dokumentavimas yra svarbus rizikos pokalbio 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 tokių verčių neapibrėžtumą kaip grafiko veiklos trukmė ir projekto komponentų kaina. Diskretūs skirstiniai gali būti naudojami neaiškiems įvykiams, pvz., bandymo rezultatams arba galimiems sprendimų medžio scenarijams, pavaizduoti. Ant pav. Žemiau pateikiami du dažniausiai naudojamų nuolatinių paskirstymų pavyzdžiai. Tokie pasiskirstymai apibūdina modelius, kurie atitinka duomenis, paprastai gaunamus iš kiekybinės rizikos analizės. Vienodus skirstinius galima naudoti tais atvejais, kai tarp nurodytų viršutinių ir apatinių ribų nėra akivaizdžios reikšmės, kuri būtų labiau tikėtina nei kitos, pvz., ankstyvame projektavimo etape.

Kiekybinės analizės ir rizikos modeliavimo metodai

Plačiai naudojami metodai analizei naudoja ir įvykiais, ir projektais pagrįstus 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 projekto elemento neapibrėžtumas paveikia tiriamą tikslą, o visi kiti neapibrėžti elementai yra jų pradinėse vertėse. Vienas tipiškas jautrumo analizės rodymo būdas yra tornado diagrama (pav. toliau), kuri yra naudinga lyginant santykinę kintamųjų, turinčių didelį neapibrėžtumo laipsnį, svarbą ir poveikį su kitais, stabilesniais kintamaisiais. Tornado diagrama taip pat naudinga analizuojant rizikos prisiėmimo scenarijus, taikomus tam tikroms rizikoms, kurių kiekybinė analizė rodo, kad galima nauda yra didesnė už atitinkamą nustatytą neigiamą poveikį. Tornado diagrama yra speciali juostinė diagrama, naudojama jautrumo analizei palyginti santykinę kintamųjų svarbą. Tornado diagramoje y ašis yra kiekvieno tipo neapibrėžtis pradinėse vertėse, o x ašis yra neapibrėžtumo dėl tiriamos išvesties sklaida arba koreliacija. Šiame paveikslėlyje kiekviena neapibrėžtis turi horizontalią juostą (liniją), o vertikaliai rodomi neapibrėžtumai, kurių skirtumas nuo pradinių verčių mažėja.

· Tikėtinos piniginės vertės analizė. Tikėtinos piniginės vertės (EMV) analizė yra statistinis metodas, apskaičiuojantis vidutinį rezultatą, kai ateityje yra scenarijų, kurie gali įvykti arba ne (t. y. analizė neapibrėžtumo sąlygomis). Palankių galimybių EMV dažniausiai išreiškiamas teigiamai, o grėsmių – neigiama. EMV reikalauja rizikos atžvilgiu neutralios prielaidos – nei linkusios į pernelyg didelę riziką, nei, priešingai, visiškai jos atmetimo. Norėdami apskaičiuoti projekto EMV, turite padauginti kiekvieno galimo rezultato vertę iš jo atsiradimo tikimybės ir tada pridėti gautas reikšmes. Paprastai tokio tipo analizė naudojama sprendimų medžio analizės forma.

· Modeliavimas ir imitacija. 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), o kiekvienai iteracijai atsitiktine tvarka iš šių kintamųjų tikimybių skirstinių parenkamos įvesties reikšmės (pavyzdžiui, sąnaudų sąmatos ar veiklos trukmės). Iteracijų metu apskaičiuojama histograma (pavyzdžiui, bendra kaina arba užbaigimo data). Išlaidų rizikos analizėje naudojami sąnaudų įvertinimai. Tvarkaraščio rizikos analizė naudoja tvarkaraščio tinklo diagramą ir trukmės įvertinimus. Sąnaudų rizikos modeliavimo, naudojant trijų elementų modelį ir rizikos diapazonus, rezultatas parodytas 1 paveiksle. žemiau. Paveiksle parodyta atitinkama tikimybė pasiekti tam tikrus vertės tikslus. Panašios kreivės gali būti sukurtos kitiems projekto 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 izoliuoti projekto tikslus nuo rizikos arba pakeisti tikslą, kuriam gresia pavojus (pavyzdžiui, išplėsti grafiko apimtį, pakeisti strategiją arba sumažinti apimtį). Radikaliausia vengimo strategija yra visiškai nutraukti projektą. Kai kurių rizikų, kylančių projekto pradžioje, galima išvengti patikslinus reikalavimus, gavus informaciją, tobulinant komunikaciją ar įgyjant patirties.

· Transliacija. Rizikos perdavimas – atsako į riziką strategija, pagal kurią projekto komanda perduoda grėsmės pasekmes kartu su atsakomybe už reagavimą trečiajai šaliai. Perdavus riziką, atsakomybė už jos valdymą perkeliama kitai šaliai; rizika nėra pašalinta. Rizikos perdavimas nereiškia atsakomybės už ją atsisakymo, perduodant ją būsimam projektui ar kitam asmeniui, pastarajam nepranešus ar nesudarius su juo sutarties. Rizikos perkėlimas beveik visada susijęs su rizikos premijos mokėjimu rizikuojančiai šaliai. Atsakomybės už riziką perdavimas yra efektyviausias finansinės rizikos atžvilgiu. Perdavimo priemonės gali būti labai įvairios ir apima, bet tuo neapsiribojant: draudimą, įsipareigojimų vykdymo garantijas, garantijas ir tt Sutartys ar susitarimai gali būti naudojami siekiant perduoti atsakomybę už tam tikrą riziką kitai šaliai. Pavyzdžiui, kai pirkėjas turi pasirinkimo galimybių, kurių pardavėjas neturi, gali būti tikslinga dalį darbų ir su tuo susijusių rizikų grąžinti pirkėjui pagal sutartį. Daugeliu atvejų išlaidų rizika gali būti perduota pirkėjui pagal kompensuojamą kainą, o rizika gali būti perduota pardavėjui pagal fiksuotos kainos sutartį.

· nuosmukis. Rizikos mažinimas – tai reagavimo į riziką strategija, kurios metu projekto komanda veikia siekdama sumažinti rizikos tikimybę ar poveikį. Tai apima neigiamos rizikos tikimybės ir (arba) poveikio sumažinimą iki priimtinų slenksčių. Ankstyvieji veiksmai, kurių imamasi siekiant sumažinti rizikos atsiradimo tikimybę ir (arba) jos poveikį projekto eigoje, dažnai yra veiksmingesni, nei bandymai ištaisyti riziką jau atsiradus. Rizikos mažinimo veiksmų pavyzdžiai yra mažiau sudėtingų procesų įgyvendinimas, daugiau bandymų arba patikimesnio tiekėjo pasirinkimas. Be to, norint sumažinti sumažinimą, gali prireikti sukurti prototipą, kad būtų sumažinta proceso ar produkto mastelio keitimo rizika, palyginti su stendo modeliu. Jei tikimybės sumažinti neįmanoma, mažinimo veiksmai turėtų būti sutelkti į rizikos poveikį, būtent į tas sąsajas, kurios lemia poveikio sunkumą. Pavyzdžiui, sistemos dubliavimo dizainas gali sumažinti pradinio elemento gedimo sunkumą.

· Įvaikinimas. Rizikos priėmimas – tai reagavimo į riziką strategija, kai projekto komanda nusprendžia pripažinti riziką ir nesiimti jokių veiksmų, kol rizika nepasireikš. Ši strategija naudojama, jei bet koks kitas būdas reaguoti į tam tikrą riziką neįmanoma arba nėra 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 iškyla, ir periodiškai peržiūrėti grėsmę, kad įsitikintų, jog ji reikšmingai nepasikeitė. Dažniausia aktyvaus priėmimo strategija yra rezervuoti galimiems nuostoliams, įskaitant tam tikrą laiko, pinigų ar išteklių, reikalingų rizikai valdyti, sumas.

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

· Naudojimas. Reaguoti į riziką, turinčią teigiamą poveikį, gali būti pasirinkta eksploatavimo strategija, jei organizacijos požiūriu būtina, kad galimybė būtų garantuota. Ši strategija skirta pašalinti neapibrėžtumą, susijusį su tam tikra teigiama rizika, taikant priemones, užtikrinančias, kad galimybė bus įgyvendinta. Tiesioginio naudojimo atsakymai apima geriausių organizacijos talentų įtraukimą į projektą, kad sutrumpėtų projekto užbaigimo laikas, arba naujų ar patobulintų technologijų naudojimas siekiant sumažinti išlaidas ir laiką, reikalingą projekto tikslams pasiekti.

· Padidinti. Didinimo strategija naudojama siekiant padidinti galimybės tikimybę ir (arba) teigiamą poveikį. Nustačius ir maksimaliai padidinus pagrindinius šios teigiamo poveikio rizikos veiksnius, gali padidėti jų atsiradimo tikimybė. Galimybių didinimo pavyzdžiai apima papildomų išteklių skyrimą operacijai, kad ji būtų atlikta anksčiau.

· Atskyrimas. Teigiamas rizikos pasidalijimas apima dalies arba visos atsakomybės už galimybę perdavimą trečiajai šaliai, kuri gali geriausiai pasinaudoti galimybe projekto naudai. Dalijimosi veikla apima rizikos pasidalijimo partnerysčių, komandų, atskirų įmonių ar bendrų įmonių steigimą, kurios gali būti steigiamos siekiant aiškaus tikslo pasinaudoti galimybe visoms šalims.

· Įvaikinimas. Galimybės priėmimas – tai noras pasinaudoti galimybe, jei ji ateina, jos aktyviai nesiekiant.

12. PROJEKTŲ PIRKIMO VALDYMAS

Projekto pirkimų valdymas apima produktų, paslaugų ar produktų, reikalingų projektui vykdyti už projekto komandos ribų, pirkimo ar įsigijimo procesus. 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 sutartims ar pirkimo užsakymams, kuriuos rengia įgalioti projekto komandos nariai, sudaryti ir administruoti.

Sutarčių rūšys

· Fiksuotos kainos sutartys. Tokio 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., planuojamoms pristatymo datoms, techniniams ir sąnaudų rezultatams arba kitiems kiekybiškai įvertinamiems ir išmatuojamiems rodikliams. Pagal fiksuotos kainos sutartis pardavėjai yra teisiškai įpareigoti laikytis tokių sutarčių arba patirti galimų finansinių nuostolių, jei jų nėra. Pirkėjai, vadovaudamiesi tokių sutarčių nuostatomis, privalo tiksliai identifikuoti perkamą prekę ar paslaugą. Turinys gali keistis, tačiau paprastai tai lemia sutarties kainos padidėjimą.

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 nesikeičia, jei nesikeičia darbo turinys. Už bet kokį vertės padidėjimą, atsiradusį dėl neigiamų rezultatų, atsako pardavėjas, kuris privalo atlikti darbą. Pagal FFP pirkėjas privalo tiksliai identifikuoti perkamą prekę ar paslaugą, 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 nukrypti nuo veiklos rezultatų ir suteikia finansinių paskatų laikytis sutartų metrikų. Paprastai tokios finansinės paskatos yra susijusios su pardavėjo išlaidomis, grafiku ar techniniais rezultatais. Veiklos rodiklių tikslinės vertės nustatomos pradžioje, o galutinė sutarties kaina nustatoma atlikus visus darbus, priklausomai nuo pardavėjo atliktų darbų. Pagal FPIF yra kainos lubos, o už visas išlaidas, viršijančias kainos lubas, atsako pardavėjas, kuris turi užbaigti darbą.

o Fiksuota kaina su ekonominės kainos koregavimo sutartimis (FP-EPA). Ši sutarties rūšis naudojama, jei pardavėjas sutarties įvykdymas trunka ilgą laiką, ko dažniausiai siekiama ilgalaikiuose santykiuose. Sutartis su fiksuota kaina, bet su specialia nuostata, leidžiančia iš anksto galutinai pakoreguoti sutarties vertę dėl besikeičiančių sąlygų, tokių kaip infliacija arba tam tikrų prekių kainų padidėjimas (sumažėjimas). Kainos koregavimo sąlyga turi būti susieta su patikimu finansiniu indeksu, naudojamu tiksliai pakoreguoti galutinę kainą. FP-EPA sukurta siekiant apsaugoti pirkėją ir pardavėją nuo išorinių sąlygų, kurių jie negali kontroliuoti.

· Išlaidų kompensavimo sutartys.Šios rūšies sutartys apima visų teisėtų faktinių išlaidų, patirtų dėl darbų atlikimo, apmokėjimą (kompensavimą) pardavėjui ir atlyginimą, sudarantį jo pelną. Išlaidomis kompensuojamose sutartyse dažnai yra sąlygos, skatinančios viršyti arba pagerinti projekto 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 atlygis (Cost Plus Award Fee Contract, CPAF). Išlaidų kompensuojama sutartis suteikia projektui lankstumo, leidžiant pardavėjui keisti instrukcijas tuo atveju, kai iš pradžių negalima tiksliai apibūdinti darbų apimties ir ją reikia koreguoti, arba darbų vykdymo metu kyla didelė rizika.

o Išlaidų kompensavimo ir fiksuoto mokesčio (CPFF) sutartys. Pardavėjui kompensuojamos visos sutartos darbų atlikimo pagal sutartį išlaidos, taip pat sumokamas fiksuotas mokestis, kuris yra tam tikras procentas 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, jei nesikeičia projekto turinys.

o Cost Reimbursement Plus Incentive (CPIF) sutartys. Pardavėjui atlyginamos visos sutartos sutartyje numatytų darbų atlikimo išlaidos, taip pat iš anksto nustatytas skatinamasis mokestis už konkrečių sutartyje numatytų veiklos rodiklių pasiekimą. CPIF sutartyse numatyta, kad jei galutinės išlaidos yra didesnės arba mažesnės už pradines apskaičiuotas išlaidas, sutaupytos lėšos / perteklinės išlaidos paskirstomos tarp pardavėjo ir pirkėjo iš anksto nustatytu santykiu, pavyzdžiui, santykiu 80/20 skirtumo tarp planuojamų išlaidų ir faktinių pardavėjo veiklos rezultatų.

o Išlaidų kompensavimo ir apdovanojimo (CPAF) sutartys. Pardavėjui atlyginamos visos pagrįstos išlaidos, tačiau didžioji dalis atlygio sumokama tik remiantis sutartyje apibrėžtų plačiai interpretuojamų subjektyvių vykdymo kriterijų visuma. Atlygio nustatymas grindžiamas tik pirkėjo subjektyviu pardavėjo sutarties vykdymo vertinimu ir paprastai neskundžiamas.

· Sutartys „laikas ir medžiagos“(Laiko ir medžiagų sutartys, T&M). Laiko ir medžiagų sutartys yra mišrios rūšies sutartys, apimančios ir išlaidų kompensavimo, ir fiksuotų kainų sutartis. Jie dažnai naudojami personalo papildymui, ekspertų pritraukimui 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šlaidų kompensavimo sutartis, nes jos leidžia keisti ir padidinti pirkėjo vertę. Pirkėjas sutarties sudarymo metu negali nurodyti bendros sutarties vertės ir tikslaus pristatomų prekių skaičiaus. Taigi, T&M sutarčių kaina gali padidėti, kaip ir kompensuojamų sutarčių atveju. Kad būtų išvengta neriboto vertės augimo, daugelis organizacijų reikalauja, kad visose T&M sutartyse būtų nustatyti kainos ir laiko apribojimai. Kita vertus, T&M sutartys gali priminti ir fiksuotos kainos susitarimus, kai sutartyje yra nurodyti tam tikri parametrai. Darbo valandinius įkainius arba medžiagų sąnaudas, įskaitant pardavėjo pelną, pirkėjas ir pardavėjas gali nustatyti iš anksto, jei abi šalys susitaria dėl tam tikrų kategorijų išteklių sąnaudų, pvz., dėl tam tikro vyriausiųjų inžinierių valandinio įkainio arba tam tikros kainos už medžiagos vienetą. .

13. SUINTERESUOTŲJŲ ŠALIŲ VALDYMAS

Projekto suinteresuotųjų šalių valdymas apima procesus, būtinus identifikuoti žmones, grupes ir organizacijas, kuriems projektas gali turėti arba gali turėti įtakos, išanalizuoti suinteresuotųjų šalių lūkesčius ir jų poveikį projektui bei sukurti tinkamas valdymo strategijas efektyviam įsitraukimui. ir projekto vykdymas. Suinteresuotųjų šalių valdymas taip pat orientuojasi į nuolatinį bendravimą su suinteresuotosiomis šalimis, siekiant suprasti jų poreikius ir lūkesčius, reaguoti į iškilusias problemas, valdyti prieštaringus interesus ir palengvinti tinkamą suinteresuotųjų šalių įtraukimą į sprendimų priėmimą ir projekto veiklą. Suinteresuotųjų šalių pasitenkinimas turėtų būti vienas iš pagrindinių projekto tikslų.

Suinteresuotųjų šalių analizėje naudojami įvairūs klasifikavimo modeliai, tokie kaip:

· galios / interesų matrica, suinteresuotųjų šalių grupavimas pagal jų autoritetą („institucija“) ir suinteresuotumo lygį („suinteresuotumas“) projekto rezultatų atžvilgiu;

· galios/įtakos matrica suinteresuotųjų šalių grupavimas 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ą lemti pokyčius planuojant ar vykdant projektą („poveikis“);

· funkcijų modelis, kuri apibūdina suinteresuotųjų šalių klases, priklausomai nuo jų galios lygio (gebėjimo primesti savo valią), skubumo (neatidėliotinų veiksmų poreikio) ir teisėtumo (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 priešinasi pokyčiams.

· Neutralus. Suinteresuota šalis žino apie projektą, bet nepritaria pokyčiams ir jiems neprieštarauja.

· 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 projektui, įdomiausias projekto gyvavimo ciklo etapas.

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

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

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

pakeitimo apimtis ir poveikis suinteresuotosioms šalims;

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

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

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

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

reikalingos informacijos skleidimo suinteresuotoms šalims laikas ir dažnumas;

· Suinteresuotųjų šalių valdymo plano atnaujinimo ir tobulinimo metodas projektui progresuojant ir tobulėjant.

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

JAV Kongreso bibliotekos bibliografinis įrašas

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

Pavadinimas: Projektų valdymo žinių rinkinio 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

Proceedings of the Project Management Institute, Inc. autorių teisės saugomos pagal JAV intelektinės nuosavybės įstatymą, kuris pripažįstamas daugumoje šalių. Turite gauti mūsų leidimą pakartotinai publikuoti arba atkurti PMI medžiagą. 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 Nepriklausomų leidėjų grupe:

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 Jokia šio leidinio dalis negali būti atgaminta ar perduota jokia forma ar bet kokiomis priemonėmis, elektroniniu, rankiniu būdu, kopijuojant, įrašant arba naudojant bet kokią informacijos saugojimo ir paieškos sistemą, be išankstinio leidimo leidėjas.

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 teisės skyriumi. Visi kiti šiame dokumente esantys prekių ženklai, paslaugų ženklai, prekių pavadinimai, prekės pavadinimai, produktų pavadinimai ir logotipai yra atitinkamų jų savininkų nuosavybė. Visos teisės, kurios nėra aiškiai suteiktos šiame dokumente, pasilieka autorių teisių savininkui.

Visos teisės saugomos. Visą 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ą, leidimas, dizaino leidykla "Olimp - Business", 2018 m

Pranešimas

Projektų valdymo instituto, Inc., sutrumpintai PMI paskelbti standartai ir gairės, kuriems priklauso šis dokumentas, buvo sukurti savanorišku, konsensusu pagrįstu standartų kūrimo procesu. Šis procesas suburia savanorius ir (arba) sujungia asmenų, besidominčių leidinio tema, komentarus ir nuomones. 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 paskelbtuose standartuose ir gairėse pateiktos medžiagos tikslumo ar išsamumo. Taip pat PMI neperžiūri šiuose dokumentuose išsakytų nuomonių pagrįstumo.

PMI neatsako už jokius sužalojimus, žalą turtui ar bet kokius kitus ypatingus, pasekminius ar pavyzdinius nuostolius, tiesiogiai ar netiesiogiai kylančius dėl šio dokumento paskelbimo, naudojimo ar naudojimo. PMI neteikia jokių aiškių ar numanomų pareiškimų ar garantijų dėl bet kokios šiame dokumente esančios medžiagos tikslumo ar išsamumo ir neteikia pareiškimų ar garantijų, kad šiame dokumente esanti informacija atitiks jūsų tikslus ar poreikius. PMI negarantuoja jokio atskiro gamintojo ar mažmenininko produktų ar paslaugų kokybės, atsirandančios dėl šio standarto ar vadovo naudojimo.

Skelbdama ir platindama šį dokumentą, PMI neteikia profesionalių ar kitų paslaugų jokiam asmeniui ar subjektui arba jų vardu; taip pat PMI nevykdo jokio asmens ar subjekto įsipareigojimų jokiai trečiajai šaliai. Naudodamasis šiuo dokumentu, šio dokumento naudotojas turėtų pats nuspręsti, kokių veiksmų reikia imtis tam tikromis aplinkybėmis, pasikliaudamas tik savo sprendimu arba, jei reikia, kompetentingo specialisto patarimu. Informacijos šia tema, kuriai taikomas šis dokumentas arba susiję standartai, galima gauti iš kitų šaltinių, į kuriuos vartotojas, jei reikia, gali kreiptis dėl papildomos informacijos, kurios nėra šiame dokumente.

PMI neturi įgaliojimų ir neprisiima jokių įsipareigojimų stebėti esamos praktikos atitiktį šio dokumento turiniui arba suderinti šią praktiką su šiuo dokumentu. PMI nesertifikuoja, netestuoja ir netikrina gaminių, konstrukcijų ar projektų, skirtų saugaus eksploatavimo ar vartotojų sveikatos saugos požiūriu. Bet koks sertifikatas ar kitas atitikties pareiškimas, atitinkantis bet kurią šiame dokumente esančią saugos ar sveikatos informaciją, negali būti priskirtas PMI; tokiu atveju visa atsakomybė tenka pažymėjimą išdavusiam arba tokį tvirtinimą pateikusiam asmeniui.

1 dalis. Projektų valdymo žinių įstaigos vadovas (PMBOK® vadovas)

1. Įvadas

1.1 Šio vadovo apžvalga ir tikslas

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

Gizos piramidės

Olimpinės žaidynės,

Didžioji Kinijos siena

Taj Mahal,

Knygos vaikams leidimas

Panamos kanalas,

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

vakcina nuo poliomielito,

Žmogaus nusileidimas mėnulyje

Komercinės kompiuterių taikomosios programos,

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

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

Praktiniai šių projektų laimėjimai buvo lyderių ir vadovų pritaikymo projektų valdymo praktikos, principai, procesai, įrankiai ir metodai. Šių projektų vadovai panaudojo keletą pagrindinių įgūdžių ir pritaikė žinias, reikalingas savo klientams ir kitiems projekte dalyvaujantiems ar jo paveiktiems asmenims patenkinti. XX amžiaus viduryje projektų vadovai pradėjo siekti, kad projektų valdymas būtų pripažintas kaip profesija. Vienas iš šio darbo aspektų buvo susitarimo dėl žinių visumos (BOK), vadinamos projektų valdymu, turinio. WOK tampa žinoma kaip Projektų valdymo žinių įstaiga (PMBOK). Projektų valdymo institutas (PMI) sukūrė pagrindines PMBOK schemas ir žodynėlius. Netrukus projektų vadovai suprato, kad PMBOK negalima pilnai sutalpinti į vieną knygą. Todėl PMI sukūrė ir paskelbė „Projektų valdymo žinių skyriaus vadovas“ (PMBOK® vadovas).

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

Žinių korpusas (BQK) apima ir paskelbtą, ir neskelbtą medžiagą. Ši žinių visuma nuolat tobulėja. Dabartis PMBOK® vadovas pabrėžia tą Projektų valdymo žinių grupės dalį, kuri yra visuotinai priimta geroji praktika.

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

? Gera praktika reiškia, kad bendrai sutariama, 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ų pasiektos laukiamos verslo vertės ir rezultatai.

Projekto vadovas dirba su projekto komanda ir kitomis suinteresuotosiomis šalimis, kad nustatytų ir panaudotų kiekvienam projektui priimtą gerą praktiką. Tinkamo projekto valdymo procesų, įvesties, įrankių, metodų, rezultatų ir gyvavimo ciklo fazių derinio nustatymas vadinamas šiame vadove aprašytų žinių „pritaikymu“.

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

1.1.1 Projekto valdymo standartas

Šis vadovas yra pagrįstas Projektų valdymo standartas. Standartas – tai įgaliotos institucijos, papročių arba bendru susitarimu kaip pavyzdį ar pavyzdį sudarytas dokumentas. Projektų valdymo standartas buvo sukurtas kaip Amerikos nacionalinio standartų instituto (ANSI) standartas, naudojant procesą, pagrįstą sutarimu, atvirumu, tinkamu procesu ir pusiausvyra. Projektų valdymo standartas yra pagrindinė PMI profesinio tobulėjimo programų ir projektų valdymo praktikos nuoroda. Kadangi reikia pritaikyti projektų valdymą, kad jis atitiktų konkretaus projekto poreikius, tiek standartas, tiek vadovas yra pagrįsti 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 reikalavimų dėl privalomo tam tikrų specifinių procesų ar praktikos įgyvendinimo. Projektų valdymo standartasįtraukta į II dalį Projektų valdymo žinių centro gairės (PMBOK® vadovas).

IN PMBOK® vadovas Daugiau informacijos apie pagrindines koncepcijas, 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 .

1.1.2 Bendrasis žodynas

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

1.1.3 Profesinės etikos ir elgesio kodeksas

PMI skelbia ugdyti 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 sukompromituoti savo vertybes. Vertybės, kurias pasaulinė projektų valdymo bendruomenė įvardija kaip svarbiausias, yra atsakomybė, pagarba, sąžiningumas ir sąžiningumas. Šios keturios vertybės remiasi Profesinės etikos ir elgesio kodeksu.

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 vertinti, kaip laikomasi skatinimo standartų, nėra lengva, tačiau elgesys pagal juos tikimasi iš tų specialistų, kurie laiko save profesionalais, tai yra, šie standartai negali būti laikomi neprivalomais. Privalomi standartai yra privalomi reikalavimai ir kai kuriais atvejais riboja arba draudžia tam tikrą praktikų elgesį. Praktikams, kurie tuo pačiu metu yra PMI nariai, sertifikatų turėtojai ar savanoriai, kurie savo veikloje pažeidžia šiuos standartus, yra taikomos PMI etikos komiteto drausminės procedūros.

1.2 Steigimo elementai

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

1.2.1 Projektai

Projektas yra laikina pastanga sukurti unikalų produktą, paslaugą ar rezultatą.

? Unikalus produktas, paslauga ar rezultatas. Projektai įgyvendinami siekiant tikslų, sukuriant 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 arba galimybė teikti paslaugą, kurios reikia procesui, etapui ar projektui užbaigti. Rezultatai gali būti materialūs arba nematerialūs.

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

Unikali prekė, kuri gali būti arba kitos prekės sudedamoji dalis, arba 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, pavyzdžiui, galutinis rezultatas ar dokumentas (pavyzdžiui, tyrimo projektas suteikia naujų žinių, kurias naudojant galima nustatyti, ar koks nors naujas procesas yra tendencija ar nauda visuomenei);

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

Tam tikri elementai gali pasikartoti kai kuriuose produktuose ir projekto 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.

Be kita ko, projektų pavyzdžiai:

Naujų vaistų kūrimas rinkai;

Ekskursijų turizmo paslaugų plėtra;

Dviejų organizacijų sujungimas;

Verslo procesų organizacijoje tobulinimas;

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

Naftos telkinių žvalgymas regione;

Organizacijoje naudojamos kompiuterinės programos modifikavimas;

Tyrimų atlikimas siekiant sukurti naują gamybos procesą;

Pastato konstrukcija.

? Laikina įmonė. Laikinas projektų pobūdis rodo tam tikrą pradžią ir pabaigą. Apibrėžimas „laikinas“ nebūtinai reiškia, kad projektas kuriamas trumpam. Projektas baigiasi, kai yra teisingas vienas ar keli iš šių teiginių:

Pasiektus projekto tikslus;

Tikslai nebus arba negali būti pasiekti;

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

Dingo projekto poreikis (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 ar 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 duoti socialinių, ekonominių, materialinių ar aplinkosaugos rezultatų. Pavyzdžiui, nacionalinio paminklo projektas sukuria rezultatą, kuris, kaip tikimasi, truks šimtmečius.

? Projektai skatina pokyčius. Projektai yra pokyčių organizacijose varomoji jėga. 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š projekto pradžią organizacija yra pradinėje būsenoje. O norimas pokyčio rezultatas projekto eigoje apibūdinamas kaip būsimas būsena.

Kai kurie projektai gali apimti pereinamosios būsenos sukūrimą, kai imamasi kelių žingsnių, kurie vienas nuo kito kyla, 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 „Pokyčių valdymas organizacijose: praktinis vadovas“ (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 verte laikoma gauta nauda tokiomis formomis kaip laikas, pinigai, prekės ar nematerialusis turtas mainais į tam tikras investicijas. Cm. Verslo analizė praktikams: praktikos vadovas, 185 p.

Projektų verslo vertė suprantama kaip nauda, ​​kurią suinteresuotosios šalys gauna dėl konkretaus projekto įgyvendinimo. 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,

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 rusišką versiją, kad atsisiųstumėte PMBOK® Guide 5th edition, šis pranešimas bus paragintas, pavyzdžiui, „FileOpen sistema susieja jūsų narių leidimus 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ą ir 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 toliau nurodytų reikalavimų.