Global Standard
Project Management Institute
КЕРІВНИЦТВО ДО ЗВОДУ ЗНАНЬ З УПРАВЛІННЯ
ПРОЕКТАМИ
(Посібник PMBOK®) - П'яте видання
ISBN 978-1-62825-008-4
Видавець:
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA
Телефон: +610-356-4600
Факс: +610-356-4647
Адреса електронної пошти: [email protected]
Інтернет: www.PMI.org
©2013 Project Management Institute, Inc. Всі права захищені.
PMI, логотип PMI, PMP, логотип PMP, PMBOK, PgMP, Project Management Journal, PM Network та логотип PMI Today є зареєстрованими торговими знаками Project Management Institute, Inc. "Quarter Globe Design" є торговою маркою Project
Management Institute, Inc. Повний список торгових марок PMI можна отримати у юридичному відділі PMI.
Відділ публікацій PMI з вдячністю прийме будь-які виправлення та коментарі, що стосуються видань PMI. Будь ласка, надсилайте ваші повідомлення про помічені помилки, помилки форматування або будь-які інші помилки. Для цього просто зробіть копію потрібної сторінки, позначте на ній помічену помилку та надішліть цю копію за адресою:
Book Editor, PMI Publications, 14 Campus Boulevard, Newtown Square, PA 19073-3299 USA.
Щоб отримати інформацію про знижки на продаж або використання в освітніх цілях, будь ласка, зверніться до сервісного центру PMI (PMI Book Service Center).
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Телефон: 1-866-276-4764 (у США та Канаді) або +1-770-280-4129 (в інших країнах)
Факс: +1-770-280-4113
Адреса електронної пошти: [email protected]
Надруковано у Сполучених Штатах Америки. Жодна з частин цієї роботи не може бути відтворена або передана в будь-якій формі або за допомогою будь-яких засобів, будь то в електронному вигляді, в рукописній формі, фотографуванням або аудіозаписом, або з використанням будь-яких систем зберігання та відтворення інформації, без попереднього письмового дозволу видавця.
Ця , яка відповідає стандарту США з якості паперу для друкованих видань (Permanent Paper Standard), опублікованому Національною організацією зі стандартів інформації (National Information Standards Organization), № Z39.48-1984.
10 9 8 7 6 5 4 3 2 1
Бібліографічний запис Бібліотеки Конгресу США
Посібник із Зводу знань з управління проектами (Підручник PMBOK®). - П'яте видання.
сторінки див
Включає бібліографічні довідки та алфавітний покажчик.
ISBN 978-1-62825-008-4 (м'яка обкладинка)
1. Управління проектами. I. Project Management Institute. ІІ. Заголовок: Посібник PMBOK.
HD69.P75G845 2013 658.4'04 - dc23 2012046112
FSC LABEL.pdf 1 12/18/12 1:16 PM
ПОВІДОМЛЕННЯ
Публіковані Інститутом управління проектами (Project Management Institute, Inc., скорочено PMI) стандарти та керівництва, до яких належить і цей документ, розроблені згідно з процесом розробки стандартів на основі добровільної участі та загального консенсусу. У ході такого процесу об'єднуються зусилля волонтерів та/або зводяться докупи зауваження та думки осіб, зацікавлених у предметі, якому присвячено дане видання. Хоча PMI адмініструє цей процес і встановлює правила, що гарантують неупередженість при досягненні консенсусу, PMI не займається написанням документа , а також незалежним тестуванням, оцінкою та перевіркою точності або повноти матеріалу, що міститься у стандартах, що видаються PMI, та посібниках. Подібним чином, PMI не займається перевіркою обґрунтованості думок, висловлених у цих документах.
PMI не несе відповідальності за будь-які травми, пошкодження, завдані власності, або будь-які інші збитки, будь то реальні, непрямі чи компенсаторні, що відбулися безпосередньо чи опосередковано внаслідок видання, застосування чи використання цього документа. PMI не несе відповідальності і не надає пряму або передбачувану гарантію щодо точності або повноти будь-якого матеріалу, що міститься в даному документі, а також не несе відповідальності і не надає гарантію того, що інформація, що міститься в даному документі, відповідає будь-яким вашим цілям або потребам. . PMI не надає гарантії щодо якості будь-яких продуктів або послуг окремого виробника або продавця, що випливає з використання цього стандарту або посібника.
Видаючи та розповсюджуючи цей документ, PMI не надає професійні чи інші послуги будь-якій особі чи організації або від імені будь-якої особи чи організації; також PMI не виконує зобов'язання будь-якої особи або організації стосовно будь-якої третьої сторони. При використанні цього документа особа, яка його використовує, повинна самостійно визначати дії, необхідні в конкретних обставинах, покладаючись при цьому виключно на своє судження або, при необхідності, на раду компетентного професіонала. Інформація щодо теми, що висвітлюється цим документом, або стандарти, що відносяться до цієї теми, можуть бути отримані з інших джерел, до яких , щоб отримати додаткову інформацію, що не міститься в даному документі.
PMI не має повноважень і не бере на себе зобов'язання щодо контролю за відповідністю існуючих практик змісту даного документа або приведення цих практик у відповідність із цим документом. PMI не займається сертифікацією, проведенням контрольних випробувань чи інспекцій щодо продуктів, проектів чи конструкцій щодо безпеки їх експлуатації чи безпеки для здоров'я споживачів. Будь-який сертифікат або інше затвердження відповідності будь-якої інформації щодо безпеки експлуатації або безпеки для здоров'я, що міститься в цьому документі, не можуть бути приписані PMI; у такому разі відповідальність лежить цілком на особі, яка видала сертифікат або висловила таке твердження.
ЗМІСТ
I
ЗМІСТ
1. ВВЕДЕННЯ............................................... .................................................. ..................................1
1.1 Мета Посібника PMBOK®
................................................................................................... 2
1.2 Що таке проект? .................................................. .................................................. ..........3
1.2.1. Зв'язки між портфелями, програмами та проектами.........................................4
1.3 Що таке управління проектом? .................................................. ....................................5
1.4 Зв'язки між управлінням портфелем, управлінням програмою, управлінням
проектом та організаційним управлінням проектами............................................. .....7
1.4.1 Управління програмою............................................. .........................................9
1.4.2 Управління портфелем............................................. ............................................9
1.4.3 Проекти та стратегічне планування........................................... ................ 10
1.4.4 Офіс управління проектами............................................ .................................. 11
1.5 Зв'язок між управлінням проектами, управлінням операційною діяльністю
та організаційною стратегією............................................... ......................................... 12
1.5.1 Управління операційною діяльністю
та управління проектами............................................... ...................................... 12
1.5.2 Організації та управління проектами........................................... .................... 14
1.6 Бізнес-цінність.............................................. .................................................. ............. 15
1.7 Роль керівника проекту .............................................. .............................................. 16
1.7.1 Сфери відповідальності та компетенції керівника проекту............ 17
1.7.2 Навички міжособистісного спілкування керівника проекту 17
1.8 Зведення знань з управління проектами ............................................ .............................. 18
2. ВПЛИВ ОРГАНІЗАЦІЇ І ЖИТТЯВИЙ ЦИКЛ ПРОЕКТУ.......................................... .................. 19
2.1 Вплив організації на управління проектами ............................................ ................ 20
2.1.1 Організаційні культури та стилі........................................... ........................ 20
2.1.2 Організаційні комунікації............................................. ......................... 21
2.1.3 Організаційні структури............................................. ................................. 21
2.1.4 Активи процесів організації............................................ .............................. 27
2.1.5 Фактори середовища підприємства............................................ ................................. 29
2.2 Зацікавлені сторони та керівництво проектом............................................ ......... 30
2.2.1 Зацікавлені сторони проекту............................................ ...................... 30
ЗМІСТ
II
©2013 Project Management Institute. Посібник до Зводу знань з управління проектами (Посібник PMBOK®) - П'яте видання
2.2.2 Керівництво проектом............................................. ........................................... 34
2.2.3 Успіх проекту............................................. .................................................. ....... 35
2.3 Команда проекту............................................... .................................................. ............ 35
2.3.1 Склад команд проектів............................................ ......................................... 37
2.4 Життєвий цикл проекту.............................................. ................................................. 38
2.4.1 Характеристики життєвого циклу проекту........................................... ............ 38
2.4.2 Фази проекту............................................. .................................................. ...... 41
3. ПРОЦЕСИ УПРАВЛІННЯ ПРОЕКТОМ............................................. .............................................. 47
3.1 Загальні взаємодії процесів управління проектом............................................ .. 50
3.2 Групи процесів управління проектом............................................. ........................... 52
3.3 Група процесів ініціації.............................................. ............................................ 54
3.4 Група процесів планування.............................................. ....................................... 55
3.5 Група процесів виконання.............................................. ........................................... 56
3.6 Група процесів моніторингу та контролю............................................ ......................... 57
3.7 Група процесів закриття.............................................. ............................................... 57
3.8 Інформація проекту............................................... .................................................. ..... 58
3.9 Роль областей знань.............................................. .................................................. ...... 60
4. УПРАВЛІННЯ ІНТЕГРАЦІЄЮ ПРОЕКТУ............................................. ............................................ 63
4.1 Розробка статуту проекту.............................................. ................................................ 66
4.1.1 Розробка статуту проекту: входи......................................................... ........................... 68
4.1.2 Розробка статуту проекту: інструменти та методи........................................ ... 71
4.1.3 Розробка статуту проекту: виходи.......................................... ......................... 71
4.2 Розробка плану управління проектом............................................. ........................... 72
4.2.1 Розробка плану управління проектом: входи ......................................... ....... 74
4.2.2 Розробка плану управління проектом: інструменти та методи 76
4.2.3 Розробка плану управління проектом: виходи......................................... .... 76
4.3 Керівництво та управління роботами проекту............................................ ..................... 79
4.3.1 Керівництво та управління роботами проекту: входи........................................ 82
4.3.2 Керівництво та управління роботами проекту: інструменти та методи.............. 83
4.3.3 Керівництво та управління роботами проекту: виходи 84
4.4 Моніторинг та контроль робіт проекту............................................ ................................ 86
ЗМІСТ
III
©2013 Project Management Institute. Посібник до Зводу знань з управління проектами (Посібник PMBOK®) - П'яте видання
4.4.1 Моніторинг та контроль робіт проекту: входи........................................ ............ 88
4.4.2 Моніторинг та контроль робіт проекту: інструменти та методи......................... 91
4.4.3 Моніторинг та контроль робіт проекту: виходи........................................ ......... 92
4.5 Інтегрований контроль змін.............................................. ........................... 94
4.5.1 Інтегрований контроль змін: входи............................................ ....... 97
4.5.2 Інтегрований контроль змін: інструменти та методи 98
4.5.3 Інтегрований контроль змін: виходи.......................................... ..... 99
4.6 Закриття проекту або фази............................................. ............................................. 100
4.6.1 Закриття проекту або фази: входи......................................... ........................ 102
4.6.2 Закриття проекту або фази: інструменти та методи............................ 102
4.6.3 Закриття проекту або фази: виходи......................................... ...................... 103
5. УПРАВЛІННЯ ЗМІСТ ПРОЕКТУ............................................. ........................................ 105
5.1 Планування управління змістом .............................................. ....................... 107
5.1.1 Планування управління змістом: входи.......................................... ... 108
5.1.2 Планування управління змістом: інструменти та методи ..... 109
5.1.3 Планування управління змістом: виходи.......................................... 109
5.2 Збір вимог............................................... .................................................. .......... 110
5.2.1 Збір вимог: входи........................................... ........................................ 113
5.2.2 Збір вимог: інструменти та методи......................................... ............... 114
5.2.3 Збір вимог: виходи........................................... ..................................... 117
5.3 Визначення змісту............................................... .............................................. 120
5.3.1 Визначення змісту: входи........................................... .......................... 121
5.3.2 Визначення змісту: інструменти та методи ......................................... .
5.3.3 Визначення змісту: виходи........................................... ....................... 123
5.4 Створення ІСР............................................... .................................................. ................ 125
5.4.1 Створення ІСР: входи........................................... .............................................. 127
5.4.2 Створення ІСР: інструменти та методи......................................... ..................... 128
5.4.3 Створення ІСР: виходи........................................... ........................................... 131
5.5 Підтвердження змісту............................................... .......................................... 133
5.5.1 Підтвердження змісту: входи........................................... ...................... 134
5.5.2 Підтвердження змісту: інструменти та методи...................................... 135
ЗМІСТ
IV
©2013 Project Management Institute. Посібник до Зводу знань з управління проектами (Посібник PMBOK®) - П'яте видання
5.5.3 Підтвердження змісту: виходи........................................... ................... 135
5.6 Контроль змісту............................................... .................................................. .. 136
5.6.1 Контроль змісту: входи........................................... ................................ 138
5.6.2 Контроль змісту: інструменти та методи......................................... ....... 139
31 грудня 2012 року PMI випустив нову редакцію Посібника до зведення знань з управління проектами (PMBOK® Guide - 5th Edition).
Фахівці PMI з випуску перекладу PMBoK російською мовою обіцяють, що до кінця року цю роботу буде зроблено, і російська професійна спільнота в повній мірі зможе дізнатися про всі новини та тонкощі нової редакції PMBoK. Пам'ятаючи про нарікання до перекладу PMBoK v.4, краще нехай оприлюднять російську версію пізніше, зате зроблять її якісною.
Судячи з думки експертів, тривалий термін роботи виправданий: потрібно пояснити безліч нових термінів, описати нові процеси, уточнити переклад старих термінів і процесів, узгодити переклади з іншими стандартами, випущеними PMI.
Що ж нового у новому PMBOK 5?
Розділ X1 «Зміни в п'ятому виданні» саме розповідає нам про це. Серед усієї інформації загального характеру (типу, «переглянутий весь текст та графіка в документі, щоб інформація стала більш точною, ясною, повною та актуальною» або «глава Групи процесів була перенесена до Додатку A1») є і корисна:
1. Термінологія та гармонізація
Автори з гордістю стверджують, що вся термінологія приведена у відповідність до PMI Lexicon of Project Management Terms. При цьому за пріоритет взято саме термінологію з PMI Lexicon. Якщо ще й переклад PMBOK 5 російською мовою почнеться зі створення правильної термінології, то є надія отримати грамотно переведений звід знань.
Також PMBOK 5 приведено у відповідність до стандарту ISO 21500:2012 «Guidance on project management» та забезпечено узгодження назв, процесів, входів, виходів, інструментів та методів з іншими стандартами PMI (типу, «The Standart for Portfolio Management» та ін.) .
Нарешті перестали ставити народ у ступор своїм «позитивним ризиком». Адже що таке ризик? Це можливість небезпеки чи невдачі! Термін походить від грецького рісікон, тобто. «скеля» або «скеля». За часів величі й могутності Стародавню Грецію «ризикувати» означало «лавірувати на судні між скелями», тобто. потенційну небезпеку невдачі.
У PMBOK 5 були внесені зміни до опису управління ризиками проекту та зміщені акценти з терміна «позитивний ризик» до терміна «можливість». До тексту також були додані такі поняття, як ставлення до ризику, схильність до ризику, толерантність до ризику та ризикові пороги.
2. Успіх проекту
Оскільки проекти мають тимчасовий характер, успіх проекту має бути виміряний з точки зору завершення проекту в рамках обмежень: зміст, час, вартість, якість, ресурси та ризики.
Але динаміка зміни вимог у сучасних проектах настільки висока, що до свого фіналу проект вилазить за всі мислимі та немислимі обмеження. Тому управління вимогами, що змінюються, фіксація їх у документах проекту та переузгодженнябазових планів стає все більш затребуваною навичкою керівника проекту. Це знайшло відображення у PMBOK 5 у пропозиції «Успіх проекту слід віднести до реалізації останніх базових планів, затверджених уповноваженими зацікавленими сторонами». На мою думку, краще і не скажеш. Якщо примудрився погодити із замовником збільшення термінів та бюджету проекту за два дні до закінчення проекту, то проект успішний, незважаючи на 2-кратне перевищення строків та 3-кратне збільшення бюджету.
3. Планування підходів до управління
У PMBOK 4 частина допоміжних планів з'являлася з повітря. Наприклад, опис Плану управління змістом було наведено у описі галузі знань «Управління змістом проекту», а якому процесі він створюється - не зазначено. Тепер додано чотири нові процеси планування: Планування управління змістом, Планування управління розкладом, Планування управління вартістю та Планування управління зацікавленими сторонами. Це забезпечуєЧітке керівництво команді проекту активно продумувати та планувати підходи до управління всіма областями знань.
Хоча не обійшлося тут без недоробок. Так і залишилися «без нагляду» два плани – План управління змінами та План управління конфігурацією. За логікою зрозуміло, що План керування конфігурацією має з'явитися разом із Планом керування змістом, а План керування змінами - під час розробки загального Плану керування проектами, але в PMBOK 5 це тільки мається на увазі.
4. Вимоги
Процес збору вимог був розширений, щоб акцентувати увагу на отриманні всіх вимог, необхідних успіху проекту.
Повністю перероблений процес перевірки змісту (Verify Scope). По-перше, він перейменований на Підтвердження змісту (Validate Scope). По-друге, було додано акцент, що цей процес не тільки про прийняття результатів, а й про те, що результати будуть представляти цінність для бізнесу та задовольняти цілі проекту.
Смішно, але в PMBOK 4 був не дуже коректний переклад Verify Scope, як Підтвердження змісту. Тепер це призведе до того, що в PMBOK 5 цей процес не змінить назву. Тільки цікаво, як перекладачі викрутяться, перекладаючи розділ зміни?
5. Гутаперчевість
У всіх минулих PMBOK-ах разом узятих слово «agile» жодного разу не вживалося.Нинішнього PMBOK воно зустрічається аж 10 разів.
PMI ніколи не приховував, що основною метою Посібника PMBOK є виділення тієї частини Зводу знань з управління проектами, яка зазвичай вважається гарною практикою. Тобто. Описані знання та практики застосовні до більшості проектів у більшості випадків, а правильне застосування цих навичок, інструментів та методів здатне підвищити ймовірність успіху для широкого діапазону різних проектів.
Тому і концепцію гнучкого управління проектами «agile» було включено до розробки розкладу проекту.
Правильно, потрібно тримати ніс за вітром! Це і сучасно,і модно, і комерційно затребуване.
6. Комунікації проекту
Давно назрівало впорядкування інформації та знань, що генеруються під час реалізації проекту. Однією з найбільш революційних змін PMBOK 5 є застосування моделі DIKW (data, information, knowledge, wisdom) - інформаційної ієрархії, де кожен рівень додає певні властивості до попереднього рівня:
На підставі знаходяться дані.
Інформація додає контекст.
Знання додає відповідь на запитання "як?" (механізм використання).
Мудрість додає відповідь на запитання "коли?" (Умови використання).
Виразилося це у чіткій послідовності збору, агрегування та обробки даних із полів у вигляді наступних документів:
1. Дані виконання робіт. «Сирі» спостереження та вимірювання, виявлені під час виконання проектних робіт.
2. Інформація про виконання робіт. Дані про виконання робіт аналізуються та інтегруються на підставі взаємозв'язків між різними областями/етапами проекту.
3. Звіти про виконання робіт. Фізичне або електронне подання інформації про виконання робіт, призначене для прийняття рішень, висвітлення питань та проблем, вироблення дій або усвідомлення ситуації.
Якщо сюди прикрутити ще й Уроки досвіду, цикл замикається, і всі знання, що генеруються в процесах реалізації проекту, будуть збиратися, оброблятися та використовуватисяу процесах управління усіма проектами у створенні.
Ну, а процеси, які плутали багатьох розмитістю своїх кордонів та незрозумілою послідовністю: «Поширення інформації» та «Підготовка звітів про виконання», перейменовані, відповідно, в «Управління комунікаціями» та «Контроль комунікацій» із логічними входами та виходами.
7. Управління «власниками частки»
Величезне значення PMBOK 5 приділено управлінню стейкхолдерами. Зачеплено майже всі розділи, щоб краще висвітлити, хто ж такі зацікавлені сторони проекту та їхній вплив на проект. Додано нову (10-ту) область знань «Управління зацікавленими сторонами проекту», до якої увійшли два процеси з «Управління комунікаціями проекту», а також додано два нові процеси.
Основні причини такого брунькування галузі знань з комунікацій такі:
1. Потрібно було більш чітке фокусування управління комунікаціями проекту на плануванні комунікаційних потреб проекту, на зборі, зберіганні та поширенняінформації у проекті, а також на моніторингу спільних взаємозв'язків проекту з метою забезпечення їхня ефективність.
2. Реальне управління стейкхолдерами включає як аналіз їх очікувань, їх на проект і розробку відповідних стратегій управління ними, а й постійний діалог із зацікавленимисторонами для задоволення їхніх потреб та очікувань, вирішення питань у міру їх виникнення,а також залучення зацікавлених сторін у прийняття рішень та діяльність проекту.
3. Планування та управління комунікаційними потребами проекту, з одного боку, а також потреб зацікавлених сторін, з іншого, – це два різні ключі до успіху проекту.
Виділення Управління зацікавленими сторонами проекту з Управління комунікаціями проекту, окрім вирішення 3-х описаних вище проблем, забезпечує відповідність PMBOK 5 новим тенденціям, що зростають, в управлінні проектами і великому інтересу дослідників і практикуючих керівників проекту до взаємодії зі стейкхолдерами,як один із ключів до загального успіху проекту. Ці тенденції вже відображені у «The Standart for Program Management» та ISO 21500:2012 «Guidance on project management». Ось і PMBOK надолужив втрачене.
Отже, нова галузь знань включає процеси:
Визначення зацікавлених сторін.
Розробка Плану управління заінтересованими сторонами.
Управління залученням зацікавлених сторін.
Контролює залучення зацікавлених сторін.
8. «М'які навички»
До навичок міжособистісної взаємодії додані Управління конфліктами та Наставництво.Більше того, до розділу 1 «Вступ» додано новий розділ, що вказує на важливість міжособистісних навичок менеджера проекту та відсилає читача до Додатка X3 з детальним описом цих навичок.
9. Документування
Ну, і найважливіше для документування проекту - загальне впорядкування документів, розпочате в PMBOK 4, продовжилося і 5-го. Наразі входами процесів є лише документи, які відіграють ключову роль у виконанні процесу. Документи та їх склад стали зрозумілішими та конкретнішими. Хоча самі назви документів у тексті написали скрізь з маленької літери, через що візуально знаходити документи в тексті складно і для роботи з документами потрібно добре знати PMBOK-івську термінологію або використовувати пакет шаблонів.
В цілому PMBOK 5 став краще структурованим, послідовним, з нормальними взаємозв'язками між процесами, вивіреною термінологією.
Посібник із Зводу знань з управління проектами (Підказка PMBOK)
Бібліографічний запис Бібліотеки Конгресу США
Назва: Інститут управління проектами (Project Management Institute, PMI), видавець.
Заголовок: Керівництво до зведення знань з управління проектом (Інструкція PMBOK) (Інститут управління проектами).
Інші заголовки: Посібник PMBOK
Опис: Шосте видання | Newtown Square, PA: Project Management Institute, 2017. | Серія: Посібник PMBOK |
Ідентифікатори: LCCN 2017032505 (print) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |
ISBN 9781628253917 (kindle) | ISBN 9781628253924 (Web PDF) | ISBN 9781628251845 (paperback)
Тематика: LCSH: Управління проектом (Project Management). | BISAC: БІЗНЕС ТА ЕКОНОМІКА / Управління проектом (BUSINESS & ECONOMICS / Project Management).
Класифікація: LCC HD69.P75 (ebook) LCC HD69.P75 G845 2017 (print) | DDC 658.4/04-dc23
Запис LC доступний на веб-сайті https://lccn.loc.gov/2017032505
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 США
Телефон: +1 610-356-4600
Факс: +1 610-356-4647
Ел. пошта: [email protected]
Веб-сайт: https://www.PMI.org
Матеріали Project Management Institute, Inc. охороняються авторським правом відповідно до закону США про інтелектуальну власність, який визнано у більшості країн. Для перевидання або відтворення матеріалів PMI вам необхідно отримати дозвіл. Для отримання більш детальної інформації відвідайте http://www.pmi.org/permissions_for_details.
Для розміщення торгового замовлення або отримання інформації про ціни зверніться до Independent Publishers Group:
Independent Publishers Group
Order Department
814 North Franklin Street
Chicago, IL 60610 США
Телефон: +1 800-888-4741
Факс: +1 312-337-5985
Ел. пошта: [email protected](тільки для замовлень)
З усіх інших питань звертайтесь до PMI Book Service Center.
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Телефон: 1-866-276-4764 (у США чи Канаді) або +1-770-280-4129 (по всьому світу)
Факс: +1-770-280-4113
Ел. пошта: [email protected]
Надруковано в Сполучених Штатах Америки Забороняється відтворення або передача в будь-якій формі або будь-якими засобами, електронними, ручними, шляхом копіювання, запису або за допомогою будь-якої системи зберігання та вилучення інформації будь-якої частини даного видання без попереднього дозволу видавця.
PMI, логотип PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION та девіз MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS.
є торговими марками Project Management Institute, Inc. Щоб отримати повний список товарних знаків PMI, зверніться до юридичного відділу PMI. Усі інші товарні марки, знаки обслуговування, торговельні найменування, торгове оформлення, назви товарів хороших і логотипи, що у цьому документі, є власністю їх відповідних власників. Будь-які права, не передані у явній формі цього документа, належать власнику авторського права.
Всі права захищені. Відтворення всієї книги чи її частини у будь-якому вигляді забороняється без письмового дозволу видавця.
© Copyright 2017 Project Management Institute, Inc. Всі права захищені.
© Переклад російською мовою, видання, оформлення видавництво «Олімп – Бізнес», 2018
повідомлення
Публіковані Інститутом управління проектами (Project Management Institute, Inc., скорочено PMI) стандарти та керівництва, до яких належить і цей документ, розроблені згідно з процесом розробки стандартів на основі добровільної участі та загального консенсусу. У ході такого процесу об'єднуються зусилля волонтерів та/або зводяться докупи зауваження та думки осіб, зацікавлених у предметі, якому присвячено дане видання. Хоча PMI адмініструє цей процес і встановлює правила, що гарантують неупередженість при досягненні консенсусу, PMI не займається написанням документа, а також незалежним тестуванням, оцінкою та перевіркою точності або повноти матеріалу, що міститься у стандартах, що видаються PMI, і посібниках. Подібним чином, PMI не займається перевіркою обґрунтованості думок, висловлених у цих документах.
PMI не несе відповідальності за будь-які травми, пошкодження, завдані власності, або будь-які інші збитки, будь то реальні, непрямі чи компенсаторні, що сталися безпосередньо чи опосередковано внаслідок видання, застосування чи використання цього документа. PMI не несе відповідальності і не надає пряму або передбачувану гарантію щодо точності або повноти будь-якого матеріалу, що міститься в даному документі, а також не несе відповідальності і не надає гарантію того, що інформація, що міститься в даному документі, відповідає будь-яким вашим цілям або потребам. . PMI не надає гарантії щодо якості будь-яких продуктів або послуг окремого виробника або продавця, що випливає з використання цього стандарту або посібника.
Видаючи та розповсюджуючи цей документ, PMI не надає професійні чи інші послуги будь-якій особі чи організації або від імені будь-якої особи чи організації; також PMI не виконує зобов'язання будь-якої особи або організації стосовно будь-якої третьої сторони. При використанні цього документа особа, яка його використовує, повинна самостійно визначати дії, необхідні в конкретних обставинах, покладаючись при цьому виключно на своє судження або, при необхідності, на раду компетентного професіонала. Інформація щодо теми, що висвітлюється цим документом, або стандарти, що відносяться до цієї теми, можуть бути отримані з інших джерел, до яких користувач може при необхідності звернутися, щоб отримати додаткову інформацію, що не міститься в цьому документі.
PMI не має повноважень і не бере на себе зобов'язання щодо контролю за відповідністю існуючих практик змісту даного документа або приведення цих практик у відповідність із цим документом. PMI не займається сертифікацією, проведенням контрольних випробувань чи інспекцій щодо продуктів, проектів чи конструкцій щодо безпеки їх експлуатації чи безпеки для здоров'я споживачів. Будь-який сертифікат або інше затвердження відповідності будь-якої інформації щодо безпеки експлуатації або безпеки для здоров'я, що міститься в цьому документі, не можуть бути приписані PMI; у такому разі відповідальність лежить цілком на особі, яка видала сертифікат або висловила таке твердження.
Частина 1. Посібник із Зводу Знань з Управління Проектом (Підручник PMBOK®)
1. Введення
1.1 Огляд та призначення цього посібника
Управління проектами не є чимось новим. Люди користуються ним упродовж багатьох століть. Серед прикладів здійснених проектів можна назвати:
Піраміди в Гізі,
Олімпійські ігри,
Велику китайську стіну,
Тадж Махал,
Видання книги для дітей
Панамський канал,
Створення комерційних реактивних літаків,
Вакцину від поліомієліту,
Висадку людини на Місяці,
Комерційні комп'ютерні прикладні програми,
Портативні пристрої для використання глобальної системи позиціонування (GPS),
Виведення міжнародної космічної станції на навколоземну орбіту.
Практичні досягнення цих проектів стали результатом застосування керівниками та управлінцями у своїй роботі практик, принципів, процесів, інструментів та методів управління проектами. Керівники цих проектів використовували низку ключових навичок та застосовували знання, необхідні для задоволення своїх клієнтів та інших людей, зайнятих у здійсненні або зазнають впливу проекту. До середини XX століття керівники проектів розпочали роботу з метою домогтися визнання управління проектами як професію. Одним із аспектів цієї роботи стало досягнення угоди щодо змісту склепіння знань (body of knowledge, BOK) під назвою «управління проектом» (project management). ВОК стає відомим як "Звід знань з управління проектом" (Project Management Body of Knowledge, PMBOK). Інститут управління проектами (Project Management Institute, PMI) створив базові схеми та глосарії для PMBOK. Керівники проектів незабаром дійшли розуміння, що PMBOK неможливо повністю вмістити в одній книзі. Тому PMI розробив та опублікував «Керівництво до Зводу знань з управління проектом» (PMBOK® Guide).
Відповідно до даного інститутом PMI визначенню, «звід знань з управління проектом» (PMBOK) – це поняття, яке описує знання у сфері професії управління проектом. Звід знань з управління проектом включає в себе традиційні практики, що зарекомендували себе і широко використовувані, а також інноваційні практики, що недавно з'явилися.
Звід знань (ВОК) включає як опубліковані, і неопубліковані матеріали. Це зведення знань постійно розвивається. Справжнє Посібник PMBOK®виділяє ту частину Зводу знань з управління проектом, яка є загальновизнаною гарною практикою.
? Загальновизнаніозначає, що знання і практики, що описуються, застосовні до більшості проектів у більшості випадків, причому щодо їх цінності та користі існує консенсус.
? Хороша практикаозначає, що загалом існує згода щодо того, що правильне застосування цих знань, навичок, інструментів та методів до процесів управління проектом здатне підвищити ймовірність успіху у широкому діапазоні різних проектів для забезпечення на виході очікуваних бізнес-цінностей та результатів.
Щоб визначити та використовувати для кожного проекту належні загальновизнані практики, керівник проекту працює з командою проекту та іншими заінтересованими сторонами. Визначення належного поєднання процесів, входів, інструментів, методів, виходів та фаз життєвого циклу для управління проектом називається «адаптацією» знань, описаних у цьому Посібнику.
Справжнє Посібник PMBOK®не є методологією. Методологія – це система практик, методів, процедур та правил, що використовуються у певній сфері діяльності. Справжнє Посібник PMBOK®є основою, де організація може розробити свої методології, політики, процедури, правила, інструменти та методи, і навіть фази життєвого циклу, необхідних практиці управління проектом.
В основу цього Посібника покладено Стандарт управління проектом. Стандарт – це документ, встановлений уповноваженим органом, звичаєм або за загальною згодою як модель або зразок. Стандарт управління проектомбув розроблений як стандарт Американського національного інституту стандартів (American National Standards Institute, ANSI) з використанням процесу, заснованого на принципах консенсусу, відкритості, дотримання процесуальних норм та збалансованості. Стандарт управління проектомє основним довідковим матеріалом для програм PMI з професійного розвитку та у практиці управління проектом. Оскільки існує необхідність адаптації управління проектом з метою забезпечення відповідності потреб конкретного проекту, в основу як Стандарту, так і Посібники покладено описові, а не директивніпрактики. Внаслідок цього цей Стандарт визначає процеси, які є хорошими практиками при здійсненні більшості проектів у більшості випадків. Цей Стандарт також визначає входи та виходи, які зазвичай пов'язані з цими процесами. Стандарт не містить вимог щодо обов'язкового виконання тих чи інших конкретних процесів чи практик. Стандарт управління проектомвходить до складу частини ІІ Посібники з Зводу знань з управління проектом (Посібник PMBOK®).
У Керівництво PMBOK®докладніше викладені ключові поняття, нові тенденції, міркування щодо адаптації процесів управління проектом та інформація про те, як застосовувати інструменти та методи при здійсненні проектів. Керівники проектів можуть використовувати одну або кілька методологій для реалізації процесів управління проектом, описаних у цьому Стандарті.
? Стандарт управління портфелем, і
? Стандарт управління програмою .
Загальний словник є важливим елементом будь-якої професійної дисципліни. Лексикон термінів управління проектами PMI (PMI Lexicon of Project Management Terms)є основним словником професійної термінології, який можуть однаково використовувати організації, керівники проектів, програм і портфелів та інші зацікавлені сторони проектів. Лексиконз часом розвиватиметься. Глосарій цього Посібника включає словник що входять до Лексикон (Lexicon)термінів, і навіть додаткові определения. У проектах можуть використовуватись інші прийняті в конкретних галузях терміни, визначення яких дано у галузевій літературі.
PMI публікує з метою зміцнити довіру до професії управління проектами та допомогти людині у прийнятті розумних рішень, особливо у важких ситуаціях, коли їй (їй) може бути запропоновано зробити нечесний вчинок або поступитися своїми цінностями. Цінності, які світова спільнота фахівців з управління проектами визначила як найважливіші, – це відповідальність, повага, справедливість та чесність. В основі Кодексу професійної етики та поведінки лежать ці чотири цінності.
Кодекс професійної етики та поведінкивключає як спонукальні, і обов'язкові стандарти. Споживні стандарти описують поведінку, до якої практикуючі фахівці, які є водночас членами PMI, власники сертифікатів або волонтери повинні прагнути внутрішніх переконань. Хоча оцінити дотримання спонукальних стандартів нелегко, поведінка відповідно до них є очікуваною для тих фахівців, які вважають себе професіоналами, тобто ці стандарти не можна вважати необов'язковими. Обов'язкові стандарти є обов'язковими вимогами, а в деяких випадках обмежують або забороняють певну поведінку фахівців-практиків. Спеціалісти-практики, які є одночасно членами PMI, власниками сертифікатів або волонтерами, які допускають у своїй діяльності порушення зазначених стандартів, підлягають дисциплінарним процедурам Комітету PMI з питань етики.
1.2 Основні елементи
У цьому розділі дається опис основних елементів, необхідних для роботи в галузі та розуміння дисципліни управління проектами.
Проект – це тимчасове підприємство, спрямоване створення унікального продукту, послуги чи результату.
? Унікальний продукт, послуга або результат. Проекти реалізуються для досягнення цілей шляхом створення результатів, що поставляються. Мета – це кінцевий результат, який мають бути спрямовані роботи; стратегічна позиція, яку слід зайняти; завдання, яке слід розв'язати; результат, який слід отримати; продукт, який слід зробити; або послуга, яку потрібно надати. Поставлений результат – це будь-який унікальний продукт, результат чи здатність надати послугу, які необхідно отримати для завершення процесу, фази або проекту. Результати, що поставляються, можуть бути матеріальними і нематеріальними.
Досягнення цілей проекту може зробити один або кілька з наведених нижче результатів:
Унікальний продукт, який може бути компонентом іншого продукту, або поліпшенням або виправленням якогось продукту, або сам по собі новим кінцевим продуктом (наприклад, усунення дефекту в кінцевому продукті);
Унікальна послуга чи здатність надавати послугу (наприклад, бізнес-підрозділ, який підтримує виробництво чи дистрибуцію);
Унікальний результат, такий як кінцевий результат чи документ (наприклад, дослідницький проект приносить нові знання, які можна використовувати визначення визначення тенденції чи вигоди будь-якого нового процесу суспільства);
Унікальне поєднання одного або кількох продуктів, послуг або результатів (наприклад, програмна програма, пов'язана з ним документація та послуги служби технічної підтримки).
Ті чи інші елементи можуть повторюватися в деяких результатах і операціях проекту, що постачаються. Дане повторення не змінює фундаментальних та унікальних характеристик робіт проекту. Наприклад, офісні будівлі можуть будуватися з однакових матеріалів або однією будівельною бригадою. Однак кожен будівельний проект залишається унікальним за своїми головними характеристиками (наприклад, місце розташування, проектне рішення, навколишнє середовище, обстановка, люди, що беруть участь).
Проекти здійснюються на всіх рівнях організації. У проекті можуть брати участь одна чи кілька осіб. У проекті може брати участь один структурний підрозділ чи кілька структурних підрозділів різних організацій.
Як приклади проекту можна навести, серед іншого:
Розробку нових фармацевтичних препаратів на ринку;
Розширення екскурсійних туристичних послуг;
Злиття двох організацій;
Удосконалення бізнес-процесу в організації;
Придбання та встановлення нового комп'ютерного апаратного забезпечення для використання в організації;
Розвідка нафтових родовищ у регіоні;
Модифікація комп'ютерної програми, що у організації;
проведення досліджень для розробки нового виробничого процесу;
Будівництво будівлі.
? Тимчасове підприємство. Тимчасовий характер проектів вказує на наявність певного початку та закінчення. Визначення "тимчасовий" не обов'язково означає, що проект розрахований на короткий час. Закінчення проекту настає, коли вірним є одне або кілька таких тверджень:
Досягнуто цілей проекту;
Цілі не будуть або не можуть бути досягнуті;
Фінансування здійснення проекту вичерпано чи більше може бути виділено;
Потреба у проекті відпала (наприклад, замовник більше не хоче завершення проекту, зміна у стратегії чи пріоритетах вимагає припинення проекту, керівництво організації дає вказівку припинити проект);
Вичерпано людські чи матеріальні ресурси;
Проект припиняється з юридичних причин чи міркувань доцільності.
Проекти є тимчасовими, але їх результати можуть існувати і після закінчення проекту. Проекти можуть давати результати соціального, економічного, матеріального чи екологічного характеру. Наприклад, проект зі зведення пам'ятника державного значення виробляє результат, який, як очікується, залишиться на століття.
? Проекти служать рушійною силою змін. Проекти є рушійною силою змін в організаціях. З точки зору бізнесу мета проекту полягає в переході організації з одного стану в інший для досягнення конкретної мети (див. рис. 1–1). Зазвичай вважається, що на початок проекту організація перебуває у вихідному стані. А бажаний результат зміни під час здійснення проекту описується як майбутній стан.
Деякі проекти можуть передбачати створення перехідного стану, коли виконується кілька кроків для досягнення майбутнього стану. Результатом успішного завершення проекту є перехід організації до майбутнього стану та досягнення конкретної мети. Додаткову інформацію з управління проектом та змінами дивіться у документі «Управління змінами в організаціях: практичний посібник» (Governance of Portfolios, Programs, and Projects: A Practice Guide).
Мал. 1-1. Перехід організації до нового стану за допомогою проекту
? Проекти дозволяють створювати бізнес-цінність. PMI визначає бізнес-цінність як чисту, кількісно визначену вигоду, що отримується від бізнес-підприємства. Вигода може бути матеріальною, нематеріальною або і тією, і іншою. У бізнес-аналізі бізнес-цінністю вважається одержана вигода у таких формах, як час, гроші, товари чи нематеріальні активи, в обмін на якесь вкладення. Див. «Бізнес-аналіз для фахівців-практиків: практичний посібник» (Business Analysis for Practitioners: A Practice Guide, сс. 185).
Під бізнесовою цінністю проектів розуміється вигода, яку в результаті здійснення конкретного проекту отримують зацікавлені сторони. Вигода від реалізації проекту може бути матеріальною, нематеріальною або і тією, і іншою.
Як приклади матеріальних елементів можна назвати:
Грошові кошти,
Акціонерний капітал,
Інженерні мережі,
Основні засоби,
________________________________________________________________________________________________
1. ВВЕДЕННЯ
2. ВПЛИВ ОРГАНІЗАЦІЇ І ЖИТТЯВИЙ ЦИКЛ ПРОЕКТУ
3. ПРОЦЕСИ УПРАВЛІННЯ ПРОЕКТОМ
4. УПРАВЛІННЯ ІНТЕГРАЦІЄЮ ПРОЕКТУ
5. УПРАВЛІННЯ ЗМІСТ ПРОЕКТУ
6. УПРАВЛІННЯ ТЕРМІНАМИ ПРОЕКТУ
7. УПРАВЛІННЯ ВАРТОМ ПРОЕКТУ
8. УПРАВЛІННЯ ЯКОСТІМ ПРОЕКТУ
9. УПРАВЛІННЯ ЛЮДСЬКИМИ РЕСУРСАМИ ПРОЕКТУ
10. УПРАВЛІННЯ КОМУНІКАЦІЯМИ ПРОЕКТУ
11. УПРАВЛІННЯ РИЗИКАМИ ПРОЕКТУ
12. УПРАВЛІННЯ ЗАКУПІВЛЯМИ ПРОЕКТУ
13. УПРАВЛІННЯ ЗАцікавленими сторонами проекту
1. ВВЕДЕННЯ
Проект- це тимчасове підприємство, спрямоване створення унікального продукту, послуги чи результату.
Проект може створити:
· продукт, що є компонентом іншого виробу, поліпшення виробу або кінцевий виріб;
· послугуабо здатність надавати послугу (наприклад, бізнес-функція, що підтримує виробництво чи дистрибуцію);
· покращенняіснуючої лінійки продуктів або послуг (наприклад, проект за методикою «шість сигм» (Six Sigma), зроблений для зменшення дефектів);
· результат, Такий як кінцевий результат або документ (наприклад, дослідницький проект приносить нові знання, які можна використовувати для визначення наявності тенденції або користь будь-якого нового процесу для суспільства).
Управління проектом- це додаток знань, навичок, інструментів та методів до робіт проекту для задоволення вимог, що висуваються до проекту. Управління проектом здійснюється за допомогою належного застосування та інтеграції логічно згрупованих 47 процесів управління проектом, об'єднаних у 5 груп процесів.
Ці 5 груп процесів наступні:
· Ініціація,
· Планування,
· Виконання,
· Моніторинг та контроль,
· Закриття.
Обмежень проекту:
· Якість,
· розклад,
· Бюджет,
· Ресурси,
Через можливу зміну розробка плану управління проектом носить ітеративний характер і проходить через послідовне уточнення на різних стадіях життєвого циклу проекту. Послідовне уточнення дозволяє команді управління проектом визначати фронт робіт і здійснювати управління ними більш детальному рівні з розвитком проекту.
Програма- ряд пов'язаних один з одним проектів, підпрограм та операцій програми, управління якими координується для отримання вигод, які були б недоступні під час управління ними окремо. Програми можуть містити елементи робіт, які мають до них відношення, але лежать поза змістом окремих проектів програми. Проект може бути частиною програми, але програма завжди містить проекти.
Управління програмою- додаток знань, навичок, інструментів та методів до програми для задоволення вимог, що висуваються до програми, та отримання вигод та контролю, які були б недоступні під час управління проектами окремо.
Проекти в рамках програми пов'язані через загальний кінцевий результат або спільні можливості. Якщо зв'язок між проектами полягає тільки в наявності спільного клієнта, продавця, технології або ресурсу, зусиллями слід керувати як портфелем проектів, а не програмою.
Управління програмою приділяє основну увагу взаємозалежності проектів та допомагає визначити оптимальний підхід до управління ними.
Як приклад програми можна навести нову супутникову систему зв'язку з проектами з проектування супутника та наземних станцій супутникового зв'язку, з будівництва кожної з них, з інтеграції системи та запуску супутника.
Портфель- це набір проектів, програм, підпортфелів та елементів операційної діяльності, керованих як група з метою досягнення стратегічних цілей. Програми згруповані всередині портфеля і складаються з підпрограм, проектів та інших робіт, що керуються скоординованим чином на підтримку портфеля. Окремі проекти, які знаходяться або всередині, або за межами програми, вважаються частиною портфеля. Незважаючи на те, що проекти або програми портфеля не обов'язково є взаємозалежними або безпосередньо пов'язаними, вони пов'язані зі стратегічним планом організації за допомогою портфеля організації.
Управління портфелями- Централізоване управління одним або декількома портфелями для досягнення стратегічних цілей. Управління портфелями сфокусовано на забезпеченні аналізу проектів та програм з метою встановлення пріоритетів при розподілі ресурсів, а також узгодження та приведення у відповідність управління портфелем зі стратегіями організації.
Офіс управління проектами (ОУП)- Організаційна структура, що стандартизує процеси керівництва проектами та сприяє обміну ресурсами, методологіями, інструментами та методами. Сфера відповідальності ОУП може змінюватись від надання підтримки в управлінні проектами до прямого управління одним або більше проектами.
В організаціях існує кілька типів структур ОУП, кожен з яких відрізняється ступенем контролю та впливу, який надається на проекти всередині організації, а саме:
· Підтримуючий. Підтримуючі ОУП відіграють консультативну роль, надаючи шаблони, найкращі практики, навчання, доступ до інформації та уроки з інших проектів. Даний тип ОУП служить як сховище проекту. Ступінь контролю з боку ОУП низький.
· Контролюючий. Контролюючі ОУП надають підтримку та вимагають відповідності вимогам за допомогою різних засобів. Відповідність може припускати адаптацію структур чи методологій управління проектами, використання специфічних шаблонів, форм та інструментів чи відповідність вимогам керівництва. Ступінь контролю з боку ОУП середня.
· Керівник. Керівні ОУП контролюють проекти шляхом безпосереднього управління цими проектами. Ступінь контролю з боку ОУП висока.
Основна функція ОУП полягає у підтримці керівників проектів різними способами, які можуть включати, серед іншого:
· Управління спільними ресурсами всіх проектів, що адмініструються ОУП;
· Визначення та розробка методології, кращих практик та стандартів управління проектами;
· Коучинг, наставництво, навчання та нагляд;
· моніторинг відповідності стандартам, політикам, процедурам та шаблонам управління проектами за допомогою аудитів проектів;
· Розробка та управління політиками, процедурами, шаблонами проекту та іншою загальною документацією (активами процесів організації);
· Координація комунікацій між проектами.
Керівники проектів та ОУП мають різні цілі і, таким чином, керуються різними вимогами. Усі їхні дії приведені у відповідність до стратегічних інтересів організації. Різниця між роллю керівника проекту та ОУП може полягати в наступному:
· Керівник проекту зосереджується на конкретних цілях проекту, в той час як ОУП управляє основними змінами у змісті програми і може розглядати їх як потенційні можливості для успішнішого досягнення бізнес-цілей.
· Керівник проекту контролює ресурси, виділені під проект, з більш точного виконання цілей проекту, а ОУП оптимізує використання загальних ресурсів організації переважають у всіх проектах.
· Керівник проекту керує обмеженнями (змістом, розкладом, вартістю та якістю тощо) окремих проектів, а ОУП керує методологіями, стандартами, загальними ризиками/можливостями, метриками та взаємозалежностями проектів на рівні підприємства.
Операційна діяльність- це постійний вид діяльності, який виробляє повторювані результати, у своїй ресурси виділяються до виконання практично аналогічного низки завдань відповідно до стандартами, впровадженими у життєвий цикл продукту. На відміну від операційної діяльності, що носить постійний характер, проекти є тимчасовими підприємствами.
Управління операційною діяльністю- це спостереження, керівництво та контроль за бізнес-операціями. Операції використовуються для підтримки повсякденної діяльності та необхідні для досягнення стратегічних та тактичних завдань організації. Приклади включають: виробничі операції, технологічні операції, бухгалтерські операції, підтримку програмного забезпечення та технічне обслуговування.
Бізнес-цінність- Концепція, унікальна для кожної організації. Бізнес-цінність визначається як вся цінність організації, загальна сума всіх матеріальних та нематеріальних елементів. Прикладами матеріальних елементів є грошові активи, кошти, акціонерний капітал та комунікації. До прикладів нематеріальних елементів відносяться репутація, впізнаваність марки, суспільне благо та торгові марки. Залежно від організації зміст бізнес-цінності може бути коротко-, середньо- та довгостроковим. Цінність може бути створена шляхом ефективного керування поточною операційною діяльністю. Однак завдяки результативному застосуванню дисциплін управління проектом, програмою та портфелем організації набувають здатності застосовувати надійні визнані процеси для досягнення стратегічних цілей та отримання більшої бізнес-цінності від своїх інвестицій у проект.
Керівник проекту- Особа, призначена виконавчою організацією керувати командою та відповідальна за досягнення цілей проекту.
Роль керівника проекту відрізняється від ролі функціонального керівника чи керівника операційної діяльності. Як правило, функціональний керівник зосереджений на забезпеченні нагляду за функціональним або бізнес-підрозділом, а керівники операційної діяльності відповідають за забезпечення ефективності бізнес-операцій.
Компетенції РП:
· Компетенції у знаннях- Те, що керівник знає про управління проектом.
· Компетенції у виконанні- те, що керівник проекту здатний зробити чи досягти, застосовуючи свої знання про управління проектом.
· Особистісні компетенції- те, як керівник проекту поводиться під час виконання проекту чи пов'язаної з ним діяльності. Особиста результативність охоплює установки, основні особистісні характеристики та лідерські якості – здатність керувати командою проекту при досягненні цілей проекту та врівноваженні обмежень проекту.
Навички РП:
· Лідерство,
· Зміцнення командою,
· Мотивація,
· комунікація,
· Вплив,
· прийняття рішень,
· Політична та культурна поінформованість,
· Переговори,
· Побудова довірчих відносин,
· Врегулювання конфліктів,
· Коучинг.
2. ВПЛИВ ОРГАНІЗАЦІЇ ТА ЖИТТЄВИЙ ЦИКЛ ПРОЕКТУ
Активи процесів організації- це плани, процеси, політики, процедури та бази знань, специфічні для виконуючої організації та використовувані нею. Вони включають будь-які артефакти, методи і знання деяких або всіх організацій, що беруть участь у проекті, які можуть бути використані для виконання або керівництва проектом. Крім того, активи процесу включають бази знань організації, такі як викладені уроки та історичну інформацію. Активи процесів організації можуть включати завершені розклади, дані про ризики і дані про освоєні обсяги. Активи процесів організації є входами більшість процесів планування. Протягом проекту члени команди можуть оновлювати та доповнювати активи процесів організації за необхідності. Активи процесів організації можуть бути розбиті на дві категорії:
· процеси та процедури
· Корпоративна база знань
Чинники середовища підприємства широко різняться за типом чи характером. Фактори середовища підприємства включають, серед іншого:
· Організаційну культуру, структуру та керівництво;
· Географічне розподіл обладнання та ресурсів;
· Державні та промислові стандарти (наприклад, розпорядження контролюючих органів, кодекси поведінки, стандарти на продукцію, стандарти якості, стандарти виготовлення);
· Інфраструктуру (наприклад, існуючі споруди та основне обладнання);
· Наявні людські ресурси (наприклад, навички, знання, спеціалізації, такі як проектування, розробка, юридичні питання, укладання договорів та закупівлі);
· управління персоналом (наприклад, керівні вказівки щодо прийому на роботу та звільнення, аналіз ефективності та результативності роботи та запису про навчання персоналу, політика винагород та понаднормової роботи, а також облік робочого часу);
· Ситуація на ринку;
· Толерантність до ризику зацікавлених сторін;
· Політичний клімат;
· Канали комунікацій, прийняті в організації;
· комерційні бази даних (наприклад, стандартизовані кошторисні дані, дані вивчення промислових ризиків та бази даних ризиків);
· інформаційна система управління проектами (наприклад, автоматизовані системи, такі як програмне забезпечення для управління розкладом, система управління конфігурацією, система збирання та розподілу інформації або веб-інтерфейси до інших автоматизованих систем, що працюють в режимі онлайн).
Члени команди проекту виконують такі ролі:
· Персонал, який відповідає за управління проектом.Члени команди, що виконують операції управління проектом, такі як складання розкладу, розробка бюджету, ведення звітності та контроль, комунікації, управління ризиками та адміністративна підтримка. Цю функцію може виконувати чи підтримувати офіс керування проектами (ОУП).
· Персонал проекту.Члени команди, які виконують роботу зі створення результатів проекту, що поставляються.
· Підтримуючі експерти. Експерти, що підтримують, виконують дії, необхідні для розробки або виконання плану управління проектом. Це може включати укладення договорів, управління фінансами, логістику, юридичну підтримку, безпеку, розробку, тестування або контроль якості. Залежно від розміру проекту та рівня необхідної підтримки, підтримуючі експерти можуть працювати повний робочий день або просто брати участь у команді, коли потрібні їхні певні навички.
· Представники користувачів чи замовників. Члени організації, які прийматимуть результати або продукти проекту, що поставляються, можуть діяти як представники або посередники з метою забезпечення належної координації, консультування щодо вимог або підтвердження прийнятності результатів проекту.
· Продавці. Продавці, також звані агентами, постачальниками чи підрядниками, - це сторонні компанії, які уклали договір про надання компонентів чи послуг, необхідні проекту. Команда проекту часто несе відповідальність за нагляд за виконанням і прийняттям результатів або послуг продавців, що постачаються. Якщо продавці несуть значну частку ризику при наданні результатів проекту, вони можуть відігравати важливу роль у команді проекту.
· Члени організацій ділових партнерівЧлени організацій ділових партнерів можуть призначатися до команди проекту з метою забезпечення належної координації.
· Ділові партнери.Ділові партнери також є сторонніми компаніями, але вони мають із підприємством особливі взаємини, іноді набуті за допомогою процедури сертифікації. Ділові партнери надають спеціалізовану експертну допомогу або грають відведену ним роль, наприклад, здійснюють встановлення, налаштування відповідно до вимог користувача, навчання або підтримку.
Життєвий цикл проекту- Набір фаз, через які проходить проект з моменту його ініціації до моменту закриття.
Усі проекти можуть мати таку структуру життєвого циклу:
· Початок проекту;
· Організація та підготовка;
· Виконання робіт проекту;
· Завершення проекту.
Фаза проекту- Сукупність логічно пов'язаних операцій проекту, що завершуються досягненням одного або ряду результатів, що поставляються.
Предиктивні життєві цикли(також відомі як повністю керовані планом) - вид життєвого циклу проекту, при якому зміст проекту, а також терміни та вартість, необхідні для виконання даного змісту, визначаються на якомога ранішій стадії життєвого циклу.
Ітеративні та інкрементні життєві цикли- це життєві цикли, у яких фази проекту (також звані ітераціями) навмисно повторюють одну чи більше операцій проекту в міру того, як команда проекту починає краще розуміти продукт. Ітеративність визначає розробку продукту шляхом виконання ряду циклів, що повторюються, в той час як інкрементність визначає послідовне нарощування функціональності продукту. Під час цих життєвих циклів продукт розробляється як ітеративно, і інкрементно.
Адаптивні життєві цикли(також відомі як керовані змінами або гнучкі (agile) методи) спрямовані на реагування на високі рівні змін і потребують постійного високого рівня залучення зацікавлених сторін. Адаптивні методи є також ітеративними та інкрементними, але відрізняються тим, що ітерації відбуваються дуже швидко (тривалість зазвичай становить 2-4 тижні) та фіксовані за термінами та вартістю. В адаптивних проектах під час кожної ітерації зазвичай виконуються кілька процесів, хоча ранні ітерації можуть концентруватися на плануванні операцій. Загальний зміст проекту розбивається на набір вимог, а робота, яка має бути виконана, іноді називається беклогом (журналом вимог). На початку ітерації команда визначає, скільки високопріоритетних елементів з беклогу може бути отримано під час наступної ітерації. Наприкінці кожної ітерації продукт має бути готовий до аналізу замовником.
3. ПРОЦЕСИ УПРАВЛІННЯ ПРОЕКТОМ
Управління проектом- це додаток знань, навичок, інструментів та методів до робіт проекту для задоволення вимог, що висуваються до проекту. Ця програма знань вимагає результативного управління процесами управління проектом.
Процес- це набір взаємопов'язаних дій та операцій, що здійснюються для створення заздалегідь визначеного продукту, послуги чи результату. Кожен процес характеризується своїми входами, інструментами та методами, що можуть бути застосовані, а також результуючими виходами.
Процеси проекту можна розділити на дві основні категорії:
· Процеси управління проектом. Ці процеси забезпечують результативне виконання проекту протягом його життєвого циклу. Ці процеси охоплюють інструменти та методи, пов'язані із застосуванням навичок та можливостей, описаних у галузях знань.
· Процеси, орієнтовані продукт.Ці процеси визначають та створюють продукт проекту. Процеси, орієнтовані продукт, зазвичай визначаються життєвим циклом проекту і різняться залежно від прикладної області, і навіть від фази життєвого циклу продукту. Зміст проекту може бути визначено без деякого базового розуміння, як створити заданий продукт. Наприклад, при визначенні загальної складності будівлі, яку необхідно звести, слід враховувати різноманітні будівельні технології та інструменти
Процеси управління проектом поділяються на п'ять категорій, відомих як групи процесів управління проектом (або групи процесів):
· Група процесів ініціації.Процеси, які виконуються визначення нового проекту чи нової фази існуючого проекту шляхом отримання авторизації початку проекту чи фази.
· Група планування процесів.Процеси, необхідні встановлення змісту робіт, уточнення цілей і визначення напрями дій, необхідних досягнення цілей проекту.
· Група процесів виконання. p align="justify"> Процеси, що застосовуються для виконання робіт, зазначених у плані управління проектом, з метою відповідності специфікаціям проекту.
· Група процесів моніторингу та контролю. Процеси, необхідні для відстеження, аналізу та регулювання виконання проекту; виявлення областей, які потребують внесення змін до плану; та ініціювання відповідних змін.
· Група процесів закриття. Процеси, які виконуються для завершення всіх операцій у межах всіх груп процесів з метою формального закриття проекту чи фази.
Групи процесів є фазами життєвого циклу проекту!
В рамках життєвого циклу проекту відбувається збір, аналіз, трансформація та поширення значної кількості даних та інформації у різних форматах для членів команди проекту та інших зацікавлених сторін. Збір даних проекту виконується внаслідок різних процесів виконання, після чого вони надаються членам команди проекту.
Наступні керівні вказівки зводять до мінімуму непорозуміння та допомагають команді проекту використати належну термінологію:
· Дані виконання робіт.Необроблені спостереження та вимірювання, виявлені під час операцій, що виконуються для виконання робіт проекту. Приклади включають відсоткові дані про фізично виконану роботу, показники якості та показники технічного виконання, дати старту та фінішу операцій розкладу, кількість запитів на зміни, кількість дефектів, фактичну вартість, фактичну тривалість тощо.
· Інформація про виконання робіт.Дані про виконання, зібрані в рамках різних процесів контролю, проаналізовані в контексті та узагальнені на основі зв'язків у різних галузях. Приклади інформації про виконання включають статус результатів, що постачаються, статус реалізації запитів на зміни та оцінку прогнозів до завершення.
· Звіти щодо виконання робіт.Фізичне чи електронне подання інформації про виконання робіт, зібране у документах проекту, призначене для винесення рішень чи формулювання проблем, виконання дій чи формування обізнаності. Приклади включають звіти про статус, службові записки, обґрунтування, інформаційні бюлетені, електронні інформаційні панелі, рекомендації та оновлення.
Описані в Посібнику PMBOK 47 процесів управління проектом розбиті на 10 окремих галузей знань. Область знань є всеосяжною системою понять, термінів та дій, що становлять професійну галузь, галузь управління проектами або галузь діяльності. Ці 10 областей знань завжди використовують у більшості проектів. Команди проектів повинні за необхідності використовувати ці 10 областей знань та інші галузі знань для свого конкретного проекту. Області знань включають:
· Управління інтеграцією проекту,
· Управління змістом проекту,
· Управління термінами проекту,
· Управління вартістю проекту,
· Управління якістю проекту,
· Управління людськими ресурсами проекту,
· Управління комунікаціями проекту,
· Управління ризиками проекту,
· Управління закупівлями проекту,
· Управління зацікавленими сторонами проекту.
4. УПРАВЛІННЯ ІНТЕГРАЦІЄЮ ПРОЕКТУ
Управління інтеграцією проекту включає в себе процеси та операції, необхідні для визначення, уточнення, комбінування, об'єднання та координації різних процесів та операцій з управління проектом у рамках груп процесів управління проектом.
Статут проекту містить:
· Призначення або обґрунтування проекту;
· вимірні цілі проекту та відповідні критерії успіху;
· Високорівневі вимоги;
· Допущення та обмеження;
· Високорівневі опис та межі проекту;
· Високорівневі ризики;
· укрупнений розклад контрольних подій;
· укрупнений бюджет;
· Список зацікавлених сторін;
· вимоги до схвалення проекту (тобто саме становить успіх проекту, хто вирішує, що проект виявився успішним, і хто підписує проект);
· Призначений керівник проекту, сфера відповідальності та рівень повноважень;
· П.І.Б. та повноваження спонсора або іншої особи (осіб), що авторизує (авторизують) статут проекту.
опис робіт(statement of work, SOW) проекту - це словесний опис продуктів, послуг чи результатів, які має зробити проект.
SOW відображає:
· Бізнес-потреба. Бізнес-потреба організації може бути заснована на ринковому попиті, технологічному прогресі, правових вимогах, постановах уряду чи міркуваннях щодо захисту навколишнього середовища. Зазвичай бізнес-потреба та порівняльний аналіз витрат та вигод включені до бізнес-кейсу для обґрунтування проекту.
· Опис вмісту продукту. Опис змісту продукту включає характеристики продукту, послуги чи результатів, створення яких робиться проект. Опис повинен також відображати взаємозв'язок між продуктами, послугами або результатами, що створюються, і бізнес-потребою, яку повинен задовольнити проект.
· Стратегічний план. Стратегічний план включає стратегічне бачення, цілі та завдання організації, а також високорівневий опис місії. Усі проекти мають відповідати стратегічному плану організації. Відповідність стратегічному плану дозволяє кожному проекту сприяти загальним цілям організації.
Бізнес-кейс
Бізнес-кейс або подібний документ надає необхідну з погляду бізнесу інформацію, що дозволяє визначити, чи проект потребує інвестицій. Він зазвичай використовується вищестоящими стосовно проекту керівниками прийняття рішень. Як правило, у бізнес-кейсі міститься бізнес-потреба та порівняльний аналіз витрат та вигод для обґрунтування проекту та визначення його меж, і зазвичай подібний аналіз виконує бізнес-аналітик, використовуючи різну інформацію, отриману від зацікавлених сторін. Спонсор повинен узгодити зміст та обмеження бізнес-кейсу. Бізнес-кейс створюється як результат дії одного чи кількох з наступних факторів:
· Вимога ринку (наприклад, автомобілебудівна компанія авторизує проект з виготовлення більш економічних автомобілів у відповідь на дефіцит бензину);
· Потреба організації (наприклад, у зв'язку з високими накладними витратами компанія може об'єднати функції персоналу та оптимізувати процеси для скорочення витрат);
· Вимога замовника (наприклад, електрична компанія авторизує проект з будівництва нової підстанції для електропостачання нового промислового району);
· технологічний прогрес (наприклад, авіакомпанія авторизує новий проект з розробки електронних квитків для заміщення квитків, надрукованих на папері, ґрунтуючись на технологічних досягненнях);
· юридична вимога (наприклад, виробник фарб авторизує проект для розробки керівних вказівок щодо поводження з токсичними матеріалами);
· Екологічні впливи (наприклад, компанія авторизує проект для зменшення свого впливу на навколишнє середовище);
· соціальна потреба (наприклад, неурядова організація в країні, що розвивається, авторизує проект з надання систем питного водопостачання, туалетів та санітарної освіти співтовариствам, що страждають від високого рівня випадків захворювань на холеру).
Угоди
Угоди використовуються визначення початкових намірів щодо проекту. Угоди можуть набувати форми договору, меморандуму про взаєморозуміння, угоди про рівень послуг, листа-угоди, листа про наміри, усних домовленостей, електронного повідомлення або інших письмових угод. Зазвичай, договір використовується, якщо проект виконується для зовнішнього замовника.
Фактори середовища підприємства
Фактори середовища підприємства, які можуть впливати на процес розробки статуту проекту, включають, серед іншого:
· державні та промислові стандарти або розпорядження (наприклад, кодекси поведінки, стандарти якості або стандарти захисту трудящих);
· Організаційну культуру та структуру;
· Ситуацію на ринку.
Активи процесів організації
Активи процесів організації, які можуть впливати на процес розробки статуту проекту, включають, серед іншого:
· Стандартні процеси організації, політики та описи процесів;
· Шаблони (наприклад, шаблон статуту проекту);
· історичну інформацію та базу накопичених знань (наприклад, проекти, записи та документи, всю інформацію та документацію щодо закриття проекту, інформацію про результати рішень щодо відбору попередніх проектів поряд з інформацією про виконання попередніх проектів, а також інформацію про операції з управління ризиками).
План управління проектом- це документ, що описує, як проект виконуватиметься, як відбуватиметься його моніторинг та контроль. Він інтегрує та консолідує всі допоміжні та базові плани, отримані в результаті процесів планування.
Базові плани проекту включають, серед іншого:
· Базовий план за змістом;
· Базовий розклад;
· Базовий план за вартістю.
Допоміжні плани включають, серед іншого:
· План управління змістом;
· План управління вимогами;
· План управління розкладом;
· План управління вартістю;
· План управління якістю;
· План удосконалення процесів;
· План управління людськими ресурсами;
· План управління комунікаціями;
· План управління ризиками;
· План управління закупівлями;
· План управління зацікавленими сторонами.
Серед іншого план управління проектом також може включати таке:
· Вибраний для проекту життєвий цикл та процеси, які будуть застосовуватися в кожній фазі;
· Деталі рішень з адаптації, винесених командою управління проектом, а саме:
o процеси управління проектом, обрані командою управління проектом;
o рівень реалізації кожного обраного процесу;
o описи інструментів та методів, які будуть використані для виконання даних процесів;
o опис порядку використання вибраних процесів для управління конкретним проектом, включаючи залежності та взаємодії між цими процесами, а також необхідні входи та виходи.
· Порядок виконання робіт для досягнення цілей проекту;
· План управління змінами, що документує порядок моніторингу та контролю змін;
· План управління конфігурацією, що документує порядок управління конфігурацією;
· Опис порядку підтримки цілісності базових планів;
· вимоги та методи комунікації між зацікавленими сторонами;
· Ключові заходи щодо аналізу управління щодо змісту, кордонів та термінів для розгляду наявних проблем та рішень, що очікують прийняття.
Прогнози щодо розкладу
Прогнози щодо розкладу складаються з урахуванням прогресу щодо базового розкладу та розрахункового часу прогнозу до завершення (ПДЗ). Вони зазвичай виражаються як відхилення за термінами (ОСР) і індексу виконання термінів (ИВСР). Для проектів, які не використовують управління освоєним обсягом, зазначаються відхилення від запланованих та прогнозованих дат фінішу.
Прогноз можна використовувати, щоб визначити, чи знаходиться проект в області допустимих значень, та виявити необхідні запити на зміни.
Прогнози щодо вартості
Прогнози щодо вартості складаються з урахуванням прогресу щодо базового плану щодо вартості та розрахункового прогнозу до завершення (ПДЗ). Вони зазвичай виражаються у вигляді відхилення за вартістю (ОСТ) та індексу виконання вартості (ІВСТ). Прогноз після завершення (ППЗ) можна порівняти з бюджетом після завершення (БПЗ), щоб визначити, чи знаходиться проект в області допустимих значень, чи необхідне складання запитів на зміни. Для проектів, які не використовують управління освоєним обсягом, зазначаються відхилення від запланованих та фактичних витрат, а також прогнозована остаточна вартість.
Нижче наведено деякі операції з управління конфігурацією, що входять до процесу інтегрованого контролю змін:
· Визначення конфігурації. Визначення та вибір елементів конфігурації для отримання основи, виходячи з якої, визначається та підтверджується конфігурація продукту, маркуються продукти та документи, здійснюється управління змінами та забезпечується облік.
· Звітність за статусом конфігурації. При необхідності надання відповідних даних про елемент конфігурації інформація документується, і з неї складається звіт. Така інформація включає список схвалених ідентифікованих елементів конфігурації, статус запропонованих конфігураційних змін і статус реалізації схвалених змін.
· Підтвердження та аудит конфігурації. Підтвердження та аудити конфігурації дозволяють переконатися, що структура елементів конфігурації проекту є правильною, а відповідні зміни зареєстровані, оцінені, схвалені, відстежені та належним чином реалізовані. Це гарантує дотримання функціональних вимог, визначених у документації конфігурації.
5. УПРАВЛІННЯ ЗМІСТ ПРОЕКТУ
Управління змістом проекту включає процеси, необхідні для забезпечення того, щоб проект містив всі і тільки ті роботи, які потрібні для успішного виконання проекту. Управління змістом проекту безпосередньо пов'язане з визначенням та контролем того, що включено та що не включено до проекту.
У контексті проекту термін «зміст» може означати:
Класи вимог:
· Бізнес-вимоги, що описують високорівневі потреби організації в цілому, наприклад, проблеми або сприятливі можливості організації, а також причини, з яких проект було здійснено.
· Вимоги заінтересованих сторін, що описують потреби заінтересованої сторони або групи заінтересованих сторін.
· Вимоги до рішення, що описують властивості, функції та характеристики продукту, послуги або результату, що задовольнить бізнес-вимоги та вимоги зацікавлених сторін. Вимоги до рішення, у свою чергу, групуються у функціональні та нефункціональні вимоги:
o Функціональні вимоги описують поведінка товару. Приклади включають процеси, дані та взаємодії з продуктом.
o Нефункціональні вимоги доповнюють функціональні та описують умови або якості середовища, необхідні для забезпечення ефективності продукту. Приклади включають: надійність, захищеність, продуктивність, безпеку, рівень обслуговування, можливість підтримки, вимоги до зберігання/знищення і т.д.
· Вимоги до переходу описують тимчасові можливості, такі як вимоги до перетворення даних та навчання, необхідні для переходу з поточного стану "як є" в стан "як має бути" у майбутньому.
· Вимоги до проекту описують дії, процеси чи інші умови, яким має відповідати проект.
· Вимоги до якості, що включають будь-який стан або критерій, необхідні для підтвердження успішного отримання результату проекту, що поставляється, або виконання інших вимог до проекту.
6. УПРАВЛІННЯ ТЕРМІНАМИ ПРОЕКТУ
Управління термінами проекту включає процеси, необхідні для того, щоб забезпечити своєчасне виконання проекту.
Типи залежності операцій:
· Фініш-старт(Finish-Start, FS). Логічний зв'язок, коли старт подальшої операції залежить від фінішу попередньої операції. Приклад: церемонія нагородження (наступна операція) не може бути розпочата, доки не закінчиться гонка попередня операція).
· Фініш-фініш(Finish-Finish, FF). Логічний зв'язок, коли фініш наступної операції залежить від фінішу попередньої операції. Приклад: створення документа (попередня операція) має бути закінчено до завершення його редагування (наступна операція).
· Старт-старт(Start-Start, SS). Логічний зв'язок, коли старт наступної операції залежить від старту попередньої операції. Приклад: вирівнювання бетонної поверхні (наступна операція) не може розпочатися до початку заливання фундаменту (попередня операція).
· Старт-фініш(Start-finish, SF). Логічний зв'язок, коли фініш наступної операції залежить від старту попередньої операції. Приклад: перша зміна служби охорони (наступна операція) не може закінчитися, доки не почнеться друга зміна служби охорони (попередня операція).
Оцінка за трьома точками
Точність оцінок тривалості операцій по одній точці може бути покращена шляхом розгляду невизначеності оцінок та ризиків. Ця концепція походить із методу оцінки та аналізу програм (program evaluation and review technique, PERT). Для визначення приблизного діапазону тривалості операції PERT використовує три оцінки:
· Найбільш імовірна(tM). Тривалість операції визначається з урахуванням попереднього виділення ресурсів, їхньої продуктивності, реалістичної оцінки їх доступності до виконання цієї операції, залежностей з інших учасників, і навіть з урахуванням переривань у роботі.
· Оптимістична(tO). Тривалість операції ґрунтується на аналізі найбільш сприятливого сценарію для операції.
· Песимістична(tP). Тривалість операції ґрунтується на аналізі найбільш несприятливого сценарію для операції.
Будучи залежною від передбачуваного розподілу значень у діапазоні трьох оцінок, очікувана тривалість tE розраховується за формулою. Дві найбільш поширені формули - трикутний розподіл та бета-розподіл.
· Трикутний розподіл. tE = (tO + tM + tP) / 3
· Бета-розподіл (з традиційного методу PERT). tE = (tO + 4tM + tP) / 6
Метод критичного шляху
Метод критичного шляху- метод, що використовується для оцінки мінімальної тривалості проекту та визначення ступеня гнучкості розкладу на логічних шляхах у мережі в рамках моделі розкладу. Метод аналізу мережі розкладу дозволяє розрахувати дати раннього старту та фінішу, а також дати пізнього старту та фінішу для всіх операцій без урахування ресурсних обмежень шляхом проведення аналізу прямого та зворотного проходу по мережі проекту, як показано на рис. 6-18. У даному прикладі найтриваліший шлях включає операції A, C і D, і тому послідовність A-C-D є критичним шляхом. Критичний шлях - це послідовність операцій, що є найдовшим шляхом у розкладі проекту, який визначає найкоротшу можливу тривалість проекту. Отримані дати раннього старту та фінішу не обов'язково є розкладом проекту; вони скоріше вказують періоди часу, у межах яких може бути виконана операція, використовуючи параметри, введені модель розкладу, пов'язані з тривалістю операцій, логічними зв'язками, випередженнями, затримками та іншими відомими обмеженнями. Метод критичного
шляхи використовується для розрахунку ступеня гнучкості розкладу на логічних шляхах у мережі в рамках моделі розкладу.
Метод критичного ланцюга
Метод критичного ланцюга(CCM) – метод розробки розкладу, що дозволяє команді проекту розміщувати буфери на будь-якому шляху у розкладі, щоб врахувати обмеженість ресурсів та невизначеності, пов'язані з проектом. Він розроблений з методу критичного шляху та враховує вплив розподілу, оптимізації, вирівнювання ресурсів, а також
невизначеність щодо тривалості операції на критичному шляху, визначеному методом критичного шляху. Метод критичного ланцюга включає поняття буферів і управління буферами. Метод критичного ланцюга використовує операції, тривалість яких не включає межі безпеки, логічні зв'язки і доступність ресурсів
статистично певними буферами, що включають сумарні межі безпеки операцій у певних точках проекту на шляху розкладу проекту для обліку обмежених ресурсів і невизначеності, пов'язаної з проектом. Критичний шлях із ресурсними обмеженнями відомий як «критичний ланцюг».
7. УПРАВЛІННЯ ВАРТОМ ПРОЕКТУ
Управління вартістю проекту включає процеси, необхідні для планування, оцінки, розробки бюджету, залучення фінансування, фінансування, управління та контролю вартості, що забезпечують виконання проекту в рамках схваленого бюджету.
Управління освоєним обсягом
Управління освоєним обсягом(EVM) - методологія, що поєднує оцінки змісту, розкладу та ресурсів з метою вимірювання прогресу проекту та досягнутої ефективності. Це поширений метод вимірювання виконання проекту. Він об'єднує базовий план за змістом із базовим планом за вартістю, а також з базовим розкладом проекту, формуючи базовий план виконання, який дозволяє команді управління проектом оцінювати та вимірювати виконання проекту та прогрес. Це метод управління проектом, який вимагає формування інтегрованого базового плану щодо якого може вимірюватися виконання протягом проекту. Принципи EVM можуть застосовуватись до
всім проектам у будь-якій галузі. За допомогою EVM розробляють та здійснюють моніторинг наступних трьох ключових показників для кожного пакету робіт та контрольного рахунку:
· Плановий обсяг.Плановий обсяг (ПЗ) - авторизований бюджет, виділений на заплановані роботи. Це авторизований бюджет, виділений до роботи, яку потрібно виконати у межах операції чи компонента ієрархічної структури робіт, крім управлінського резерву. Даний бюджет розподіляється за фазами у життєвому циклі проекту, але у певний момент запланований обсяг визначає фізичну роботу, яка мала бути виконана. Сукупний ПЗ іноді називається базовим планом виконання (performance measurement baseline, PMB). Загальна величина планового обсягу проекту також відома як бюджет після завершення (БПЗ).
· Освоєний обсяг. Освоєний обсяг (ГО) - обсяг виконаних робіт, що у показниках авторизованого бюджету, виділеного на дані роботи. Це бюджет, пов'язаний із авторизованою роботою, яка була виконана. Вимірюваний ГО повинен бути пов'язаний з PMB, і виміряний ГО не може перевищувати авторизований бюджет програмного забезпечення для даного компонента. ГО часто використовується для обчислення відсотка виконання проекту. Для кожного компонента ІСР повинні бути встановлені критерії вимірювання прогресу робіт, що виконуються. Керівники проектів здійснюють моніторинг ГО, як інкрементно визначення поточного статусу, і кумулятивно визначення довгострокових тенденцій виконання.
· Фактична вартість.Фактична вартість (ФС) - фактично понесені витрати виконання робіт у рамках операції за певний період. Це загальні витрати, понесені під час виконання робіт, виміряних ГО. ФС за визначенням має відповідати тому, що було закладено в ПЗ та виміряно ГО (наприклад, лише прямі витрати робочого часу, тільки прямі витрати або всі витрати, включаючи непрямі). У ФС відсутня верхня межа; вимірюється все, що витрачається задля досягнення ГО.
Також здійснюється моніторинг відхилень від схваленого базового плану:
· Відхилення за термінами. Відхилення за термінами (ОСР) – показник виконання розкладу, що виражається як різниця між освоєним обсягом та плановим обсягом. Кількість часу, на який проект відстає від запланованої дати поставки або випереджає її у певний час. Це вимір виконання розкладу проекту. Значення його дорівнює освоєному обсягу (ГО) за вирахуванням планового обсягу (ПЗ). Відхилення за термінами в методі EVM є метрикою, корисною тим, що вона демонструє, коли проект відстає за термінами від свого базового плану або коли він випереджає його. Відхилення за термінами в EVM в кінцевому підсумку дорівнюватиме нулю при завершенні проекту, тому що всі планові обсяги на той час повинні бути освоєні. Відхилення за термінами найкраще використовувати разом із складанням розкладу за методом критичного шляху (CPM) та управління ризиками. Формула: ОСР = ГО – ПЗ
· Відхилення за вартістю. Відхилення за вартістю (ОСТ) - сума дефіциту або надлишку бюджету у певний момент часу, що виражається як різниця між освоєним обсягом та фактичною вартістю. Це вимір ефективності виконання проекту за вартістю. Воно дорівнює освоєному обсягу (ГО) за вирахуванням фактичної вартості (ФС). Відхилення за вартістю наприкінці проекту дорівнюватиме різниці між бюджетом після завершення (БПЗ) та фактично витраченою сумою. ОСТ надзвичайно важливо, оскільки воно демонструє зв'язок між фізичним виконанням та витраченими засобами. Негативне ОСТ часто неможливе для проекту. Формула: ОСТ = ГО – ФС.
Значення ОСР та ОСТ можуть бути перетворені на показники ефективності для відображення виконання вартості та термінів будь-якого проекту в порівнянні з усіма іншими проектами або в рамках портфеля проектів. Відхилення корисні визначення статусу проекту.
· Індекс виконання термінів. Індекс виконання термінів (ІВСР) – показник ефективності розкладу, що виражається як співвідношення освоєного обсягу до планового обсягу. За його допомогою вимірюється, наскільки ефективно команда проекту використовує свій час. Іноді він використовується разом із індексом виконання вартості (ІВСТ) для прогнозування остаточних оцінок завершення проекту. Значення ІВСР менше 1,0 вказує на те, що виконано менше робіт, ніж було заплановано. Значення ІВСР більше 1,0 вказує на те, що виконано більше робіт, ніж було заплановано. Оскільки ІВСР вимірює всі роботи проекту, також необхідно проаналізувати виконання на критичному шляху, щоб визначити, чи буде проект завершено до або після своєї планової дати фінішу. ІВСР дорівнює відношенню ГО до ПЗ. Формула: ІВСР = ГО/ПЗ
· Індекс виконання вартості.Індекс виконання вартості (ІВСТ) – показник ефективності ресурсів, включених до бюджету, за вартістю, що виражається як співвідношення освоєного обсягу до фактичної вартості. Він вважається найважливішою метрикою EVM та вимірює вартісну ефективність виконаної роботи. Значення ІВСТ менше 1,0 вказує на перевитрату коштів для виконаної роботи. Значення ІВСТ більше 1,0 свідчить про недоосвоєння коштів у виконанні конкретну дату. ІВСР дорівнює відношенню ГО до ФС. Індекси корисні визначення статусу проекту, а також надають основу для оцінки підсумкових термінів і вартості проекту. Формула: ІВСТ = ГО/ФС
Три показники планового обсягу, освоєного обсягу та фактичної вартості можуть бути об'єктами моніторингу, і про них можуть складатися періодичні (зазвичай щотижневі чи щомісячні) чи кумулятивні звіти.
Прогнозування
У міру реалізації проекту команда проекту може розробити прогноз після завершення (ППЗ), який може відрізнятися від бюджету після завершення (БПЗ), ґрунтуючись на виконанні проекту. Якщо стає очевидним, що БПЗ більше не є реалістичним, керівник проекту має розглянути ППЗ. Розробка ППЗ включає прогнозування умов і подій, які виникнуть у майбутньому проекту, на підставі інформації про поточне виконання та інших знань, наявних на момент прогнозування. Прогнози формуються, оновлюються та перевидаються заново на основі
даних про виконання робіт, одержуваних у міру виконання проекту. Інформація про виконання робіт охоплює минуле виконання проекту та будь-яку інформацію, яка може вплинути на проект у майбутньому.
ППЗ зазвичай розраховуються як фактична вартість, врахована для завершених робіт, плюс прогноз до завершення (ПДЗ) робіт, що залишилися. На команду проекту покладено обов'язок прогнозувати, з чим вона може зіткнутися під час виконання ПДЗ, на підставі наявного досвіду. Метод EVM добре працює разом із прогнозами необхідного ППЗ, розробленими вручну. Найбільш широко використовуваним підходом прогнозування ППЗ є ручне підсумовування «знизу вгору», яке проводить керівник проекту та команда проекту.
Метод ППЗ «знизу вгору», який використовується керівником проекту, заснований на врахованій фактичній вартості та досвіді, отриманому на виконаних роботах, і вимагає побудови нового прогнозу до завершення щодо робіт проекту, що залишилися. Формула: ППЗ = ФС + ПДЗ «знизу нагору».
ППЗ, розроблений вручну керівником проекту, швидко зіставляється з низкою розрахованих ППЗ, які мають різноманітні сценарії ризиків. При розрахунку значень ППЗ, як правило, використовуються кумулятивні значення ІВСТ та ІВСР. Хоча дані EVM дозволяють швидко отримати безліч статистичних ППЗ, нижче описано лише три найбільш поширені методи:
· ППЗ для робіт ПДЗ, виконаних за закладеними до бюджету ставками. Даний метод ППЗ використовує фактичне виконання проекту на конкретну дату (сприятливе чи несприятливе), подане фактичною вартістю, та передбачає, що всі майбутні роботи ПДЗ будуть виконані за закладеними до бюджету ставками. У тих випадках, коли фактичне виконання несприятливе, припущення, що майбутнє виконання покращиться, має бути прийняте лише в тому випадку, якщо це підтверджується аналізом ризиків проекту. Формула: ППЗ = ФС + (БПЗ - ГО)
· ППЗ для робіт ПДЗ, виконаних з поточним ІВСТ. Цей метод припускає, що проект продовжиться у майбутньому так само, як він протікав до цього моменту. Допускається, що роботи ПДЗ виконуватимуться на тому ж рівні кумулятивного індексу виконання вартості (ІВСТ), якого було досягнуто в проекті на цей момент. Формула: ППЗ = БПЗ/ІВСТ
· ППЗ для робіт ПДЗ з урахуванням обох факторів ІВСР та ІВСТ. У цьому прогнозі роботи ПДЗ виконуватимуться з ефективністю, яка враховує індекси виконання як вартості, і термінів. Цей метод найбільш корисний у разі, коли одним із факторів, що впливають на ПДЗ, є розклад проекту. Варіації даного методу розглядають ІВСТ та ІВСР у різних співвідношеннях (наприклад, 80/20, 50/50 або інших пропорціях), відповідно до думки керівника проекту. Формула: ППЗ = ФС + [(БПЗ - ГО) / (ІВСТ x ІВСР)]
Кожен із цих підходів може бути застосований для будь-якого конкретного проекту та подавати команді управління проектом сигнал «раннього попередження», якщо ППЗ виходять за межі прийнятих допустимих варіацій.
Індекс продуктивності до завершення (ІПДЗ)
Індекс продуктивності до завершення(ІПДЗ) - розрахунковий показник ефективності виконання проекту за вартістю, який необхідно досягти з ресурсами, що залишилися, щоб домогтися встановленого управлінського показника, що виражається у вигляді відношення вартості виконання решти робіт до бюджету, що залишився. ІПДЗ являє собою обчислюваний індекс виконання вартості, який необхідно забезпечити на роботах, що залишилися, для досягнення певної управлінської мети, такої як БПЗ або ППЗ. Якщо стає очевидним, що БПЗ більше не є реалістичним, керівник проекту має розглянути ППЗ. Після схвалення ППЗ може замінити БПЗ під час розрахунку ІПДЗ. Формула для ІПДЗ, заснованого на БПЗ: (БПЗ – ГО)/(БПЗ – ФС). ІПДЗ концептуально представлений малюнку нижче. Формула для ІПДЗ показана в лівому нижньому куті - робота, що залишилася (визначена як БПЗ мінус ГО), поділена на засоби, що залишилися (які можуть розраховуватися або як БПЗ мінус ФС, або як ППЗ мінус ФС).
Якщо кумулятивний ІВСТ нижче базового плану (як показано на малюнку нижче), всі майбутні роботи з проекту негайно повинні виконуватися відповідно до ІПДЗ (БПЗ) (що відображено у верхній лінії на малюнку нижче), щоб залишатися в рамках авторизованого БПЗ. Судження про те, чи цей рівень виконання є досяжним, приймається на основі низки міркувань, включаючи ризики, розклад та технічне виконання. Цей рівень виконання зображено у вигляді лінії ІПДЗ (ППЗ). Формула для ІПДЗ, заснованого на ППЗ: (БПЗ – ГО)/(ППЗ – ФС). Формули EVM представлені у таблиці нижче.
Аналіз виконання
Аналіз виконання передбачає порівняння виконання вартості у поступовій динаміці, операцій розкладу чи пакетів робіт, якими є перевитрата чи недоосвоєння бюджету, і оцінок коштів, необхідні завершення виконуваних робіт. Якщо використовується EVM, то визначається така інформація:
· Аналіз відхилень.Аналіз відхилень при використанні в EVM - це роз'яснення (причина, вплив та коригувальні впливи) відхилень для вартості (ОСТ = ГО – ФС), розкладу (ОСР = ГО – ПЗ) та відхилення після завершення (ОПЗ = БПЗ – ППЗ). Найчастіше аналізуються відхилення за вартістю та за термінами. Для проектів, у яких не застосовується управління освоєним обсягом, може бути виконаний аналогічний аналіз відхилень шляхом порівняння запланованої вартості операції з фактичною вартістю операції визначення відхилень фактичного виконання проекту від базового плану за вартістю. Подальший аналіз може бути виконаний для визначення причини та ступеня відхилення від базового розкладу та необхідних коригувальних впливів або запобіжних дій. Вимірювання виконання вартості використовуються з метою оцінки величини відхилення від початкового базового плану за вартістю. Важливі аспекти управління вартістю проекту включають визначення причини та ступеня відхилення щодо базового плану щодо вартості та прийняття рішень про необхідність коригувальних впливів або запобіжних дій. У міру виконання дедалі більшого обсягу робіт процентний діапазон допустимих відхилень матиме тенденцію до зменшення.
· Аналіз тенденцій.Аналіз тенденцій передбачає вивчення даних виконання проекту з часом визначення того, поліпшується чи погіршується виконання проекту. Методи графічного аналізу цінні для розуміння виконання на конкретну дату та для порівняння з цільовими показниками подальшого виконання у формі БПЗ у порівнянні з ППЗ та у формі дат завершення.
· Виконання освоєного обсягу. Виконання освоєного обсягу передбачає порівняння базового плану виконання із фактичним виконанням термінів та вартості. Якщо EVM не використовується, для порівняння виконання вартості використовується аналіз базового плану за вартістю щодо фактичної вартості виконаних робіт.
8. УПРАВЛІННЯ ЯКОСТІМ ПРОЕКТУ
Управління якістю проекту включає процеси та дії виконуючої організації, які визначають політики, цілі та сфери відповідальності в галузі якості таким чином, щоб проект задовольняв тим потребам, заради яких він був прийнятий. Управління якістю проекту використовує політики та процедури для впровадження системи управління якістю організації в контексті проекту та, за необхідності, підтримує дії щодо постійного вдосконалення процесів, що здійснюються виконавчою організацією. Управління якістю проекту спрямоване на забезпечення відповідності вимогам до проекту, включаючи вимоги до продукту, та підтвердження такої відповідності.
Якість та сорт- Це концептуально різні поняття. Якість як вихід чи результат - це «ступінь відповідності сукупності властивих характеристик вимогам» (ISO 9000) . Сорт як конструктивний задум - це категорія, що присвоюється результатам, що поставляються, мають одне і те ж функціональне призначення, але різні технічні характеристики. Керівник проекту та команда управління проектом відповідають за досягнення компромісних рішень щодо забезпечення необхідних рівнів як якості, так і сорту. Рівень якості, який відповідає вимогам до якості, - це завжди проблема, а низький сорт може бути проблемою.
У контексті досягнення відповідності вимогам ISO сучасні підходи до управління якістю прагнуть мінімізувати відхилення та досягати результатів, що відповідають певним вимогам. Ці підходи визнають важливість таких положень:
· Задоволеність замовника.Розуміння, оцінка, визначення вимог замовника та управління ними таким чином, щоб задовольнити його очікування. Для цього необхідно забезпечити поєднання відповідності вимогам (проект повинен зробити те, заради чого він був вжитий) та придатності до використання (продукт чи послуга повинні задовольняти реальні потреби).
· Запобігання важливішим за інспекції. Якість повинна плануватися, розроблятися і вбудовуватися, а не інспектуватися при управлінні проектом або наданні результатів проекту, що поставляються. Витрати на запобігання помилкам, як правило, значно нижчі за вартість їх виправлення після виявлення в результаті інспекції або в процесі використання.
· Постійне вдосконалення.Цикл «планування-виконання-перевірка-дія» (plan-do-check-act, PDCA) – модель, описана Шухартом та вдосконалена Демінгом, – є основою для покращення якості. Крім того, ініціативи щодо покращення якості, такі як загальне управління якістю (Total Quality Management, TQM), методика «шість сигм» та спільне застосування методики «шості сигм» та ощадливого виробництва (Lean Six Sigma), можуть покращити якість управління проектом, а також якість продукту проекту. Серед моделей вдосконалення процесів можна навести модель якості Малкольма Болдріджа, модель зрілості організаційного управління проектами (Organizational Project Management Maturity Model, OPM3®) та комплексну модель продуктивності та зрілості (Capability Maturity Model Integrated, CMMI®).
· Відповідальність керівництва.Для досягнення успіху потрібна участь усіх членів команди проекту. Проте керівництво зберігає за собою, в рамках відповідальності за якість, відповідну відповідальність за надання відповідних ресурсів у відповідному обсязі.
· Вартість якості(Cost of quality, COQ). Вартість якості - це загальна вартість роботи над відповідністю та роботи над невідповідністю вимогам, яка має бути виконана як компенсаційне зусилля, оскільки при першій спробі виконання цієї роботи існує потенційна можливість, що якась частина необхідного обсягу робіт може бути виконана або була виконана неправильно . Витрати виконання робіт із забезпечення якості можуть бути протягом всього життєвого циклу поставленого результату. Наприклад, рішення, прийняті командою проекту, можуть вплинути на операційні витрати, пов'язані з використанням виконаного результату, що поставляється. Витрати, пов'язані із забезпеченням якості після закриття проекту, можуть виникати внаслідок повернення продуктів, претензій щодо гарантії та кампаній з відкликання продукції. Таким чином, внаслідок тимчасового характеру проекту та потенційної вигоди, яка може бути отримана внаслідок зниження післяпроектної вартості якості, спонсуючі організації можуть ухвалити рішення про інвестування коштів у покращення якості продукту. Дані інвестиції, зазвичай, робляться у сфері роботи з відповідністю вимогам з метою запобігання дефектів чи зниження вартості дефектів шляхом інспекції невідповідних вимогам одиниць продукції. Більше того, питання, пов'язані з постпроектною COQ, повинні вирішуватись у процесі управління програмою та управління портфелем, наприклад офіси управління проектами, програмами та портфелями повинні застосовувати відповідні методи аналізу, шаблони та способи виділення фінансових засобів для цієї мети.
Сім основних інструментів якості
Сім основних інструментів якості, також відомих у галузі як інструменти 7QC, використовуються в контексті циклу PDCA для вирішення проблем, пов'язаних з якістю. Мал. Нижче являє собою концептуальну ілюстрацію семи основних інструментів якості, які включають:
· Діаграми причинно-наслідкових зв'язків, також звані діаграмами «риб'ячий скелет» або діаграмами Ісікави. Опис проблеми, розташоване в голові «рибячого скелета», використовується як відправна точка для відстеження джерела проблеми до першопричини, що вимагає вжиття заходів. Опис проблеми, як правило, є викладом проблеми як недоробки, яку необхідно усунути, або мети, яку необхідно досягти. Пошук причин здійснюється шляхом вивчення опису проблеми та пошуку відповідей на питання «чому» доти, доки не буде ідентифіковано першопричину, яка потребує вжиття заходів, або доти, доки не будуть вичерпані всі обґрунтовані можливості на кожній частині риб'ячого скелета. Діаграми «риб'ячий скелет» часто виявляються корисними під час пошуку зв'язку небажаних ефектів, що розглядаються як особлива варіація, із встановленою причиною, щодо якої команди проекту мають виконати коригувальні впливи для усунення цієї особливої варіації, виявленої на контрольній карті.
· Блок-схеми, також звані картами процесів, так як вони відображають послідовність кроків та можливості розгалуження процесу, що трансформує один або більше входів в один або більше виходів. Блок-схеми відображають операції, точки прийняття рішень, цикли, паралельні шляхи та порядок виконання процесів шляхом подання у вигляді карти операційних деталей процедур, що існують у межах горизонтального ланцюжка створення цінності моделі SIPOC. Блок-схеми можуть бути корисними для розуміння та оцінки вартості якості в рамках процесу. Це досягається шляхом використання логіки розгалуження потоку робіт та пов'язаних з нею відносних частот для оцінки очікуваної грошової вартості роботи над відповідністю та роботи над невідповідністю вимогам, необхідної для надання виходу, що відповідає вимогам.
· Аркуші збору даних,також відомі як листи для підрахунку можуть бути використані як контрольні списки при зборі даних. Аркуші збору даних використовуються для організації фактів таким чином, який сприятиме ефективному збору корисних даних про потенційну проблему з якістю. Вони особливо корисні для збору даних параметрів під час виконання інспекцій з метою виявлення дефектів. Наприклад, дані про частоту виникнення або наслідки дефектів, зібрані за допомогою аркушів збору даних, часто відображаються за допомогою діаграм Парето.
· Діаграми Паретоявляють собою вертикальні стовпчасті діаграми особливої форми і використовуються для визначення декількох найважливіших джерел, що викликають більшість ефектів проблеми. Категорії, показані на горизонтальній осі, є існуючим розподілом ймовірностей, що враховує 100 % можливих спостережень. Значення відповідної частоти виникнення кожної зазначеної причини, показаної на горизонтальній осі, зменшується до досягнення джерела за умовчанням, званого «інше», яке відповідає за невстановлені причини. Як правило, діаграма Парето організована за категоріями, що вимірюють частоту виникнення, або наслідки.
· Гістограми- це особливий вид стовпчастої діаграми, що використовується для опису центру розподілу, дисперсії та форми статистичного розподілу. На відміну від контрольної карти гістограма не враховує впливу часу на варіацію, що існує в межах розподілу.
· Контрольні картивикористовуються визначення того, є процес стабільним чи ні і характеризується він передбачуваним виконанням. Нижні та верхні межі, задані специфікацією, ґрунтуються на вимогах, закріплених в угоді. Вони відображають максимальні та мінімальні допустимі значення. Можуть накладатися штрафи, пов'язані з виходом значень за кордон, визначені специфікацією. Верхня та нижня контрольні межі відрізняються від меж, заданих специфікацією. Контрольні межі встановлюються з використанням стандартних статистичних розрахунків та принципів з метою остаточного визначення природної можливості стабілізації процесу. Керівник проекту та відповідні заінтересовані сторони можуть використовувати статистично розраховані контрольні кордони для визначення точок, в яких будуть вживатися коригувальні впливи з метою запобігання неприродному виконанню. Метою коригуючого впливу, як правило, є збереження природної стійкості стабільного та дієвого процесу. Для процесів, що повторюються, контрольні межі зазвичай складають ± 3 сигми від середнього значення процесу, яке було встановлено на 0. Процес вважається таким, що вийшов з-під контролю в тому випадку, якщо: (1) точка даних знаходиться поза контрольними межами; (2) сім послідовних точок знаходяться вище середньої лінії; або (3) сім послідовних точок знаходяться нижче середньої лінії. Контрольні карти можуть бути використані для контролю різних типів вихідних змінних. Хоча найчастіше контрольні карти використовуються для відстеження операцій, що потрібні для виробництва промислових виробів, вони також можуть використовуватися для контролю відхилень за вартістю та розкладом, обсягу та частоти змін змісту або інших управлінських результатів, що допомагає визначити, чи знаходяться процеси управління проектом під контролем .
· Діаграми розкиду- це нанесені на графік упорядковані пари (X, Y), іноді звані графіками кореляцій, оскільки вони використовуються для пояснення зміни в залежній змінній, Y щодо зміни, що спостерігається в незалежній змінній, X. Напрямок кореляції може бути пропорційним (позитивна кореляція), зворотним (негативна кореляція), чи кореляційної моделі може існувати (нульова кореляція). Якщо кореляція може бути встановлена, можна визначити лінію регресії та використовувати її для оцінки того, як зміна незалежної змінної змінить значення залежної змінної.
Інструменти управління та контролю якості
У процесі забезпечення якості використовуються інструменти та методи процесів планування управління якістю та контролю якості. На додаток до цього, інші доступні інструменти включають:
· Діаграми подібності. Діаграма подібності подібна до методу побудови асоціативних карт, так як вона використовується для генерування ідей, які можуть бути об'єднані з метою формування впорядкованого способу мислення про проблему. У процесі управління проектом створення ІСР може бути покращено шляхом використання діаграми подібності для надання структури декомпозиції змісту.
· Діаграми процесу здійснення програми(Process decision program charts, PDPC). Використовуються для розуміння мети щодо дій, що робляться для досягнення мети. PDPC – корисний метод для планування з урахуванням можливих втрат, тому що він допомагає командам передбачати проміжні кроки, які можуть перешкоджати досягненню мети.
· Орієнтовані графи взаємин.Адаптація діаграм відносин. Орієнтовані графи взаємовідносин є процес творчого вирішення проблем у помірно складних сценаріях, що характеризуються переплетеними логічними зв'язками аж до 50 пов'язаних елементів. Орієнтований графік взаємовідносин може бути побудований на основі даних, отриманих в результаті використання інших інструментів, таких як діаграма подібності, деревоподібна діаграма або діаграма «риб'ячий скелет».
· Деревоподібні діаграми.Також відомі як систематичні діаграми, які можуть бути використані для відображення декомпозиції ієрархій, таких як ІСР, ієрархічна структура ризиків (risk breakdown structure, RBS) та організаційна структура робіт (organizational breakdown structure, OBS). У процесі управління проектом деревоподібні діаграми корисні для візуалізації відносин типу «батько – нащадок» у будь-якій ієрархії декомпозиції, яка використовує систематичний набір правил визначення відносин підпорядкованості. Деревоподібні діаграми можуть бути горизонтальними (наприклад, ієрархічна структура ризику) або вертикальними (наприклад, ієрархія команди або OBS). Оскільки деревоподібні діаграми уможливлюють створення вкладених відгалужень, які закінчуються в одній точці прийняття рішення, вони корисні як дерева рішень для очікуваної цінності обмеженої кількості родинних відносин, систематично представлених у вигляді діаграми.
· Матриці пріоритетів. Використовуються для ідентифікації ключових проблем та відповідних альтернатив, щоб пріоритезувати їх у вигляді набору рішень для впровадження. Критерії пріоритезуються і зважуються перед застосуванням до всіх доступних альтернатив з метою отримання математичної оцінки для ранжування всіх варіантів.
· Діаграми мережі операцій.Раніше відомі як стрілочні діаграми. Вони включають такі формати діаграми мережі, як операції на дугах (activity on arrow, AOA) і найбільш часто використовуваний формат операції у вузлах (activity on node, AON). Діаграми мережі операцій використовуються з методами складання розкладу проекту, такими як метод оцінки та аналізу програм (PERT), метод критичного шляху (CPM) та метод діаграм попередження (PDM).
· Матричні діаграми.Інструмент керування та контролю якості, що використовується для аналізу даних у межах організаційної структури, створеної в матриці. За допомогою матричної діаграми прагнуть показати силу залежностей між факторами, причинами та цілями, відображеними в матриці у вигляді рядів та стовпців.
9. УПРАВЛІННЯ ЛЮДСЬКИМИ РЕСУРСАМИ ПРОЕКТУ
Управління людськими ресурсами проекту включає процеси організації, управління та керівництва командою проекту. Команда проекту складається з людей, яким визначено ролі та сфери відповідальності за виконання проекту. Члени команди проекту можуть мати різні набори навичок, можуть мати повну або часткову зайнятість і можуть бути додані або видалені з команди з виконанням проекту. Членів команди проекту можна назвати персоналом проекту. Незважаючи на те, що членам команди проекту призначено конкретні ролі та сфери відповідальності, участь усіх членів команди у плануванні проекту та прийнятті рішень є цінною для проекту. Залучення членів команди дозволяє використовувати наявний у них досвід при плануванні проекту та зміцнює націленість команди на досягнення результатів проекту.
Організаційні діаграми та посадові інструкції
Існують різні формати документування розподілу ролей та сфер відповідальності членів команди. Більшість форматів належать до одного з трьох типів: ієрархічний, матричний та текстовий. Крім того, деякі призначення за проектом зазначаються у допоміжних планах, наприклад, у планах управління ризиками, якістю або комунікаціями. Незалежно від того, який метод використовується, мета завжди одна – домогтися того, щоб для кожного пакету робіт був призначений однозначний відповідальний за його виконання та щоб кожен член команди чітко розумів свою роль та сферу відповідальності. Наприклад, для представлення ролей високого рівня можна використовувати ієрархічний формат, текстовий формат найкраще підходить для детального документування сфер відповідальності.
План управління людськими ресурсами включає, серед іншого:
· Ролі та сфери відповідальності. При перерахуванні ролей та сфер відповідальності, необхідних для виконання проекту, необхідно враховувати наступне:
o Роль. Функція, прийнята співробітником чи призначена співробітнику проекту. Прикладами ролей у проекті є інженер-будівельник, бізнес-аналітик та координатор тестування. Чіткий опис ролі щодо повноважень, сфер відповідальності та кордонів має бути документально оформлений.
o Повноваження. Право задіяти ресурси проекту, приймати рішення, підписувати схвалення, приймати результати, що постачаються, і впливати на інших членів команди для виконання робіт проекту. Приклади рішень, для прийняття яких потрібні ясні та чіткі повноваження, включають вибір способу виконання операції, приймання якості та порядок реагування на відхилення в проекті. Члени команди здійснюють свою діяльність краще, коли рівень повноважень кожного з них відповідає їхній індивідуальній сфері відповідальності.
o Відповідальність. Наведені обов'язки та робота, яку член команди проекту повинен виконати для завершення операцій проекту.
o Кваліфікація. Навички та здібності, необхідні для виконання призначених операцій у рамках обмежень проекту. Якщо члени команди проекту не мають необхідної кваліфікації, то виконання проекту може опинитися під загрозою. При виявленні таких невідповідностей необхідно вжити запобіжних дій, наприклад, провести навчання, найняти кваліфікованих фахівців або внести до розкладу або змісту проекту відповідні зміни.
· Організаційні діаграми проекту. Організаційна діаграма проекту – це графічне представлення складу команди проекту та відносин підзвітності між її членами. Залежно від вимог проекту вона може бути формальною чи неформальною, докладною чи узагальненою. Наприклад, організаційна діаграма проекту для команди реагування на надзвичайні ситуації, що складається з 3000 осіб, буде значно докладнішою, ніж організаційна діаграма внутрішнього проекту з командою 20 осіб.
· План забезпечення персоналом. План забезпечення персоналом - компонент плану управління людськими ресурсами, що описує, коли і як залучатимуться члени команди проекту і як довго вони потребуватимуть. Він визначає спосіб виконання вимог до людських ресурсів. Залежно від вимог проекту план забезпечення персоналом може бути формальним чи неформальним, докладним чи узагальненим. Для відображення поточних заходів щодо поповнення та розвитку команди проекту цей план під час проекту постійно оновлюється. Інформація, що міститься в плані забезпечення персоналом, різниться в залежності від прикладної області та масштабу проекту, але в будь-якому випадку повинна включати наступні елементи:
o Набір персоналу. При плануванні набору членів команди проекту виникає низка питань. Наприклад, чи будуть задіяні наявні людські ресурси організації, чи вони набиратимуться ззовні на договірній основі; чи будуть члени команди працювати в одному місці, або вони можуть працювати віддалено; яка вартість, що відповідає кожному рівню кваліфікації, необхідної для проекту; і який рівень підтримки команди проекту, яку здатні забезпечити відділ роботи з персоналом організації та функціональні керівники.
o Ресурсні календарі. Календарі, що визначають доступність певного ресурсу у ті чи інші робочі дні та зміни. У плані забезпечення персоналом вказуються терміни залучення членів команди проекту, як індивідуально, і колективно, і навіть терміни, коли мають розпочатися дії з комплектування, такі як найм персоналу. Одним із інструментів для графічного відображення людських ресурсів є гістограма ресурсу, яка використовується командою управління проектом як засіб візуального представлення або розподілу ресурсів для всіх зацікавлених сторін. На цій діаграмі відображається кількість годин, яка особі, відділу або всій команді проекту потрібна щотижня або місяць протягом усього проекту. Діаграма може включати горизонтальну лінію, що відображає максимальну кількість годин, розрахованих для певного ресурсу. Якщо стовпчики діаграми виходять за межі максимальної кількості годин, то в цьому випадку необхідно застосувати стратегію оптимізації ресурсів, наприклад, виділити додаткові ресурси або змінити розклад.
o План вивільнення персоналу. Визначення методу та часу звільнення членів команди від обов'язків у проекті представляє користь як для проекту, так і для членів команди. Коли члени команди звільняються від участі у проекті, то при цьому виключаються виплати співробітникам, які вже виконали свою частку роботи у проекті, і таким чином знижується вартість проекту. Загальний моральний клімат покращується, якщо плавний перехід до нових проектів вже сплановано заздалегідь. План вивільнення персоналу також може скоротити ризики в галузі людських ресурсів, які можуть виникнути в ході реалізації або по закінченні проекту.
o Потреби у навчанні. Якщо є побоювання, що кваліфікація членів команди, призначених для участі у проекті, може виявитися недостатньою, то в рамках плану проекту слід розробити план навчання персоналу. У цьому плані можуть бути передбачені програми навчання членів команди, які призведуть до отримання ними сертифікатів, які сприятимуть успішному виконанню проекту.
o Визнання заслуг та винагорода. Чіткі критерії та спланована система винагороди допомагають стимулювати та підтримувати бажану поведінку людей, зайнятих у проекті. Щоб визнання заслуг та винагорода були результативними, вони повинні ґрунтуватися на діях, а також показниках ефективності та результативності, що знаходяться під контролем цієї особи. Наприклад, члена команди можна винагородити за дотримання певної норми витрат, лише якщо він має достатній рівень повноважень контролю рішень, які впливають розмір витрат. Створення плану із зазначенням часу винагороди гарантує, що про заохочення не забудуть. Визнання заслуг та винагорода є частиною процесу розвитку команди проекту.
o Відповідність нормам. План управління забезпеченням персоналом може включати стратегії, що забезпечують відповідність проекту існуючим державним нормативним актам, умовам договорів з профспілками та іншим встановленим політикам щодо людських ресурсів.
o Безпека. До плану забезпечення персоналом, а також до реєстру ризиків можуть включатися політики та процедури захисту членів команди від нещасних випадків.
Одна з моделей, що використовуються для опису розвитку команди, - це Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), яка включає п'ять стадій розвитку, через які повинні пройти команди. Зазвичай ці стадії наступають по порядку, але нерідко команда може «застрягти» на певній стадії або повернутися на ранню. У проектах, члени команд яких раніше працювали разом, певні стадії можуть бути пропущені.
· Формування. На цій стадії команда збирається разом і дізнається про проект і про свої формальні ролі та сфери відповідальності в ньому. Члени команди на цій фазі, як правило, незалежні один від одного і не дуже відкриті.
· Шторм. Протягом цієї стадії команда починає вивчати роботи з проекту, технічнірішення та підхід до управління проектом. Якщо члени команди не налаштовані на співпрацю і не відкриті різним ідеям та перспективам, ситуація може стати непродуктивною.
· Врегулювання. На стадії врегулювання члени команди починають працювати разом та підлаштовують свої робочі звички та моделі поведінки так, щоб сприяти командній роботі. Члени команди навчаються довіряти один одному.
· Результативність. Команди, які досягли стадії результативності, функціонують як добре організований підрозділ. Вони незалежні та спокійно та результативно вирішують проблеми.
· Завершення. На цій стадії команда завершує роботу та переходить до наступного проекту. Зазвичай це відбувається при вивільненні персоналу з проекту після виконання результатів, що поставляються, або в рамках виконання процесу закриття проекту або фази
Тривалість кожної конкретної стадії залежить від динаміки, чисельного складу та керівництва команди. Керівники проектів повинні добре уявляти динаміку розвитку команди, щоб сприяти результативному проходженню членами команди всіх стадій.
Існує п'ять основних методів, які використовуються для вирішення конфліктів.
Оскільки кожен з них має своє власне призначення та застосування, методи наведені у довільному порядку:
· Ухилення/уникнення.Відступ від фактичної чи потенційної конфліктної ситуації, перенесення вирішення проблеми на пізніший термін, щоб краще підготуватися до її вирішення або передати її вирішення іншим особам.
· Згладжування/пристосовування.Підкреслення точок дотику замість областей протиріч, відмова від своєї позиції на користь інших потреб, щоб зберегти гармонію і взаємини.
· Компроміс/врегулювання.Пошук рішень, які будуть певною мірою задовільними для всіх сторін, щоб тимчасово чи частково вирішити конфлікт.
· Примус/вказівки.Лобування чиєїсь точки зору за рахунок інших, пропонуючи лише рішення «один виграв – усі програли», зазвичай з боку позиції влади, щоб вирішити критичну ситуацію.
· Співпраця/вирішення проблем.Об'єднання безлічі точок зору та поглядів з різних перспектив, необхідність у готовності до співпраці та відкритого діалогу, яка зазвичай призводить до досягнення консенсусу та підтримки рішення всіма сторонами.
Приклади навичок міжособистісного спілкування, які найчастіше використовує керівник проекту, включають:
· Лідерство. Для успіху проекту потрібні розвинені лідерські навички. Лідерство важливе на всіх фазах життєвого циклу проекту. Існує безліч теорій лідерства, що визначають його стилі, які, за потреби, кожна команда має використовувати у відповідній ситуації. Особливо важливо передавати членам команди загальне бачення проекту та надихати їх на досягнення високої ефективності та результативності у роботі.
· Вплив. Оскільки керівники проектів часто мають лише незначні прямі повноваження щодо членів своїх команд у матричних умовах або зовсім не мають таких, їх здатність своєчасно впливати на зацікавлені сторони проекту є критично важливою для успіху проекту. Ключові навички впливу включають:
o здатність переконливо та чітко викладати точку зору та позицію;
o високий рівень навичок активного та результативного вислуховування;
o розуміння та розгляд різних перспектив у будь-якій ситуації;
o збір істотної та критично важливої інформації для вирішення важливих проблем та досягнення угод при збереженні взаємної довіри.
· Результативне ухвалення рішень.Це передбачає здатність проведення переговорів та впливу на організацію та команду управління проектом. Нижче наведено деякі з рекомендацій щодо прийняття рішень:
o необхідно зосередитися на цілях, яких належить досягти;
o необхідно дотримуватись процедури прийняття рішень;
o необхідно вивчати фактори середовища;
o необхідно аналізувати наявну інформацію;
o необхідно розвивати особисті якості членів команди;
o необхідно стимулювати творчий підхід команди до роботи;
o необхідно керувати ризиками.
10. УПРАВЛІННЯ КОМУНІКАЦІЯМИ ПРОЕКТУ
Управління комунікаціями проекту включає процеси, необхідні для забезпечення своєчасного та належного планування, збору, створення, розповсюдження, зберігання, отримання, управління, контролю, моніторингу та в кінцевому рахунку архівування/утилізації проектної інформації. Керівники проектів витрачають більшу частину свого часу на здійснення комунікацій з членами команди та іншими зацікавленими сторонами проекту, незалежно від того, чи є вони внутрішніми (на всіх рівнях організації) чи зовнішніми по відношенню до організації. Ефективні комунікації створюють міст між різними зацікавленими сторонами, які можуть мати різні культурні та організаційні передумови, різні рівні знань, а також різні погляди та інтереси, що впливають або можуть впливати на виконання або результати проекту.
Чинники, які можуть впливати на вибір комунікаційних технологій, включають:
· Терміновість отримання інформації.Необхідно враховувати терміновість, частоту і формат інформації, що подається, так як вони можуть різнитися в різних проектах, а також на різних стадіях одного проекту.
· Доступність технології. Необхідно переконатися, що технологія, яка потрібна для забезпечення комунікації, є сумісною та доступною для всіх зацікавлених сторін протягом усього життєвого циклу проекту.
· Простота використання.Необхідно впевнитись у тому, що обрані комунікаційні технології підходять учасникам проекту та що за потреби заплановані відповідні навчальні заходи.
· Середовище проекту. Необхідно визначити, чи команда зустрічатиметься і діятиме очно чи віртуально; чи будуть члени команди знаходитися в одному або кількох часових поясах; чи використовуватимуть для комунікацій кілька мов; і, зрештою, чи існують інші чинники середовища проекту, такі як культура, які можуть вплинути на комунікації.
· Секретність та конфіденційність інформації.Необхідно визначити, чи є передана інформація секретною чи конфіденційною і чи потрібно вжити додаткових заходів для її захисту. Також необхідно врахувати найбільш вдалий спосіб передачі такої інформації.
Базова комунікаційна модель має таку послідовність кроків:
· Кодування. Перетворення (кодування) думок чи ідей на кодову мову відправником.
· Надсилання повідомлення.Надсилання інформації відправником з використанням інформаційного каналу (середовища передачі інформації). Передача цього повідомлення може перешкодити різні фактори (наприклад, відстань, незнайома технологія, недостатня інфраструктура, культурні відмінності та нестача додаткової інформації). Ці чинники разом називаються шумом.
· Декодування. Повідомлення перекладається одержувачем назад у значні думки та ідеї.
· Підтвердження. Після отримання повідомлення одержувач може надіслати сигнал (підтвердження) про отримання повідомлення, але це не обов'язково означає згоду або розуміння повідомлення.
· Зворотній зв'язок/відповідь. Коли отримане повідомлення декодовано і зрозуміло, одержувач перетворює (кодує) думки та ідеї на повідомлення та передає це повідомлення оригінальному відправнику.
Для поширення інформації між заінтересованими сторонами проекту використовують кілька методів комунікації.
Дані методи можуть бути поділені на такі великі групи:
· Інтерактивні комунікації. Між двома чи більше сторонами, які здійснюють багатосторонній обмін інформацією. Цей метод є найефективнішим для забезпечення загального розуміння певних питань усіма учасниками; він включає у собі наради, телефонні переговори, миттєві повідомлення, відеоконференції тощо.
· Комунікації шляхом інформування без запиту.Інформація надсилається певним одержувачам, які потребують її отримання. Даний метод забезпечує поширення інформації, але не гарантує того, що вона буде фактично отримана чи зрозуміла передбачуваною аудиторією. До комунікацій методом інформування без запиту відносяться листи, нотатки, звіти, повідомлення електронної пошти, факси, голосової пошти, блоги, прес-релізи і т.д.
· Комунікації методом інформування на запит. Використовуються для дуже великих обсягів інформації або для дуже великих аудиторій і вимагають, щоб одержувачі зверталися до змісту, що передається, за своїм власним бажанням. Такі методи включають інтранет-сайти, електронне навчання, бази одержаних уроків, сховища знань і т.д.
Методи та аспекти ефективного управління комунікаціями включають, серед іншого:
· Моделі «відправник-одержувач». Впровадження циклів зворотного зв'язку з метою забезпечення сприятливих можливостей для взаємодії/участі та усунення бар'єрів комунікацій.
· Вибір засобів зв'язку. Вибір того, коли краще спілкуватися усно, а коли письмово, коли краще підготувати неформальні нотатки, а коли формальний звіт, а також коли краще поговорити особисто, а коли написати електронною поштою.
· Стиль написання. Застосування дійсного чи пасивного застави, структура пропозиції, добір слів.
· Методи управління нарадами. Підготовка повістки та робота з конфліктами.
· Методи презентацій. Поінформованість про вплив мови тіла та розробка візуальних засобів.
· Методи організації групової роботи. Досягнення консенсусу та подолання перешкод.
· Методи слухання. Активне слухання (підтвердження, уточнення та перевірка розуміння) та усунення бар'єрів, які можуть спотворити розуміння.
11. УПРАВЛІННЯ РИЗИКАМИ ПРОЕКТУ
Управління ризиками проекту включає процеси, пов'язані зі здійсненням планування управління ризиками, ідентифікацією, аналізом, плануванням реагування, а також з контролем ризиків у проекті. Цілями управління ризиками проекту є підвищення ймовірності виникнення та посилення впливу сприятливих подій та зниження ймовірності виникнення та ослаблення впливу несприятливих подій у ході реалізації проекту.
Ризик проекту- це невизначена подія або умова, настання якої негативно або позитивно позначається на цілях проекту, таких як зміст, розклад, вартість та якість. Ризик може бути викликаний однією або декількома причинами і у разі виникнення може вплинути на один або кілька аспектів.
План управління ризиками- це компонент плану управління проектом, який описує, яким чином дії з управління ризиками структуруватимуться і виконуватимуться. План управління ризиками включає такі елементи:
· Методологія. Визначення підходів, інструментів та джерел даних, які будуть використовуватися для управління ризиками у цьому проекті.
· Ролі та сфери відповідальності.Визначення керівних членів команди, які підтримують членів команди, а також членів команди, які відповідають за управління ризиками, для кожного виду дій, включених до плану управління ризиками, і роз'яснення їх сфер відповідальності.
· Розробка бюджету.Оцінка необхідних коштів з урахуванням виділених ресурсів для включення до базового плану вартості та розробка процедур з використання резерву на можливі втрати та управлінського резерву.
· Визначення термінів.Визначення термінів та частоти виконання процесів управління ризиками протягом життєвого циклу проекту, розробка процедур щодо використання резервів розкладу на можливі втрати, а також визначення операцій з управління ризиками, які будуть включені до розкладу проекту.
· Категорії ризиків.Надають кошти для розподілу потенційних джерел ризику за групами. Можуть бути використані кілька підходів, наприклад, структура, яка ґрунтується на цілях проекту за категоріями. Ієрархічна структура ризиків (RBS) допомагає команді проекту розглянути безліч джерел, з яких можуть виникати ризики проекту під час виконання процедури ідентифікації ризиків. Різним типам проектів відповідають різні структури RBS. Організація може використовувати заздалегідь розроблену схему категоризації ризиків, яка може приймати форму простого списку категорій або оформлятися у вигляді RBS. RBS - це ієрархічне подання ризиків згідно з категоріями ризиків.
· Визначення ймовірності та впливу ризиків. Якісний та достовірний аналіз ризиків передбачає визначення різних рівнів ймовірності та впливу ризиків у контексті проекту. Загальні визначення рівнів ймовірності та рівнів впливу адаптуються до конкретного проекту в процесі планування управління ризиками і використовуються потім в ході подальших процесів. У таблиці нижче наведено приклад визначення негативних впливів, які можуть бути використані при оцінці впливу ризиків, пов'язаних з чотирма цілями проекту (подібні таблиці можуть бути створені і щодо позитивних впливів). Таблиця нижче демонструє як відносні, і числові (у разі, нелінійні) підходи.
· Матриця ймовірності та впливу. Матриця ймовірності та впливу - це таблиця, що відображає ймовірність настання кожного ризику та його вплив на цілі проекту у разі його настання. Пріоритети між ризиками розставляються відповідно до їх ймовірних наслідків, які можуть впливати на цілі проекту. Типовим способом пріоритезації є використання таблиці відповідності або матриці ймовірності та впливу. Зазвичай організація сама встановлює поєднання ймовірності і впливу, виходячи з яких рівень ризику визначається як «високий», «середній» чи «низький».
· Уточнена толерантність зацікавлених сторін.У процесі планування управління ризиками толерантність заінтересованих сторін може коригуватися стосовно конкретного проекту.
· Формати звітності.Формати звітності визначають, яким чином проводитиметься документування, аналіз та обмін інформацією про результати процесу управління ризиками. Формати звітності дають опис змісту та формату реєстру ризиків, а також будь-яких інших необхідних звітів щодо ризиків.
· Відстеження. Відстеження документує порядок реєстрації всіх пов'язаних із ризиками дій для цілей даного проекту, а також у яких випадках і яким чином проводитиметься аудит процесів управління ризиками.
Методи діаграм
До методів діаграм ризиків належать:
· Діаграми причинно-наслідкових зв'язків.Ці діаграми, також відомі як діаграми Ісікави або діаграми «риб'ячий скелет», використовуються для визначення причин виникнення ризиків.
· Блок-схеми процесу чи системи.Цей вид графічного відображення демонструє порядок взаємодії різних елементів системи між собою та їх причинно-наслідкові зв'язки.
· Діаграма впливу.Графічне уявлення ситуацій, що відображає причинно-наслідкові зв'язки, послідовності подій у часі та інші відносини між змінними та результатами.
Аналіз SWOT
Даний метод дозволяє провести аналіз проекту з погляду кожного з аспектів: сильних і слабких сторін, сприятливих можливостей та загроз (strengths, weaknesses, opportunities, threats, SWOT), що робить ідентифікацію ризиків більш повною, враховуючи ризики всередині проекту. При використанні цього методу починають з визначення сильних і слабких сторін організації, приділяючи особливу увагу або проекту, або організації, або бізнесу в цілому. Потім у процесі аналізу SWOT ідентифікують будь-які сприятливі можливості проекту, зумовлені сильними сторонами організації, і навіть будь-які загрози, що виникають внаслідок її слабких сторін. За допомогою цього аналізу також досліджують, наскільки сильні сторони організації компенсують загрози, та ідентифікують сприятливі можливості, які можна використовувати для подолання слабких сторін.
Реєстр ризиків
Основний вихід процесу ідентифікації ризиків – це початковий запис у реєстрі ризиків. Реєстр ризиків – це документ, що містить результати аналізу ризиків та планування реагування на ризики. До реєстру ризиків заносяться результати інших процесів управління ризиками у міру їх здійснення, що з часом призводить до підвищення рівня та різноманітності типів інформації, що міститься в реєстрі ризиків. Підготовка реєстру ризиків починається в процесі ідентифікації ризиків, протягом якого реєстр заповнюється наведеною нижче інформацією. Потім ця інформація стає доступною для інших процесів, що стосуються управління проектом та управління ризиками.
· Список ідентифікованих ризиків. Ідентифіковані ризики описуються з достатньою мірою деталізації. У цьому списку може використовуватися певна структура для опису ризиків, наприклад: може відбутися ПОДІЯ, яка вплине, або якщо існує ПРИЧИНА, то може відбутися ПІДІЯ, яка матиме НАСЛІДКА. Крім того, при побудові списку ідентифікованих ризиків можуть стати очевиднішими причини цих ризиків. Це фундаментальні умови або події, які здатні викликати настання одного або кількох ідентифікованих ризиків. Вони повинні реєструватися та використовуватися для підтримки ідентифікації ризиків у майбутньому в рамках цього та інших проектів.
· Список можливих реагувань. Іноді у процесі ідентифікації ризиків можуть визначатися можливі реагування ними. Такі заходи реагування, якщо вони визначені під час цього процесу, повинні бути входами процесу планування реагування на ризики.
Якісний аналіз ризиків- процес встановлення пріоритетів щодо ризиків для їх подальшого аналізу або дій, що виконується шляхом оцінки та зіставлення їх впливу та ймовірності виникнення. Ключова вигода цього процесу полягає в тому, що він дозволяє керівникам проектів зменшувати рівень невизначеності та фокусуватись на високопріоритетних ризиках.
Кількісний аналіз ризиків- процес чисельного аналізу впливу ідентифікованих ризиків на цілі проекту загалом. Ключова вигода цього процесу полягає в тому, що він надає кількісну інформацію про ризики на підтримку процесу ухвалення рішень з метою зменшення невизначеності проекту.
Методи збору та подання інформації
· Проведення інтерв'ю. Методи проведення інтерв'ю дозволяють отримати досвід та історичні дані для кількісної оцінки ймовірності та впливу ризиків на цілі проекту. Необхідна інформація залежить від типу ймовірнісного розподілу. Наприклад, для деяких найбільш широко використовуваних моделей розподілів необхідно зібрати інформацію про оптимістичний (низька ймовірність), песимістичний (висока ймовірність) і найбільш ймовірний сценарій. Документування обґрунтувань діапазонів ризиків та пов'язаних з ними припущень є важливим елементом інтерв'ю щодо ризиків, оскільки ці документи дозволяють зробити висновок про надійність та достовірність аналізу.
· Розподіл імовірностей.Безперервні розподіли ймовірностей, що широко використовуються в моделюванні та імітації, є невизначеністю значень, наприклад тривалості операцій розкладу та вартості компонентів проекту. Дискретні розподіли можуть використовуватися для представлення невизначених подій, наприклад, результатів тестів або можливих сценаріїв дерева рішень. На рис. Нижче наведено два приклади широко використовуваних безперервних розподілів. Такі розподіли описують фігури, які поєднуються з даними, які зазвичай отримуються в результаті кількісного аналізу ризиків. Рівномірні розподіли можна використовувати у випадках, коли немає очевидного значення, що є більш ймовірним, ніж інші, що знаходяться між зазначеними верхньою та нижньою межами, наприклад, на ранній стадії проектування.
Методи кількісного аналізу та моделювання ризиків
Широко застосовувані методи використовують як подієво-орієнтовані, так і проектно-орієнтовані підходи до аналізу, що включають:
· Аналіз чутливості. Аналіз чутливості допомагає визначити ризики з можливим впливом на проект. Він допомагає зрозуміти, як варіації з метою проекту корелюють з варіаціями у різних невизначеності. З іншого боку, він встановлює, якою мірою невизначеність кожного елемента проекту впливає досліджувану мету, тоді як інші невизначені елементи перебувають у базових значеннях. Одним із типових способів відображення аналізу чутливості є діаграма «торнадо» (рис. нижче), яка корисна при порівнянні відносної важливості та впливу змінних, що володіють високим ступенем невизначеності, з іншими більш стабільними змінними. Діаграма «торнадо» також корисна при аналізі сценаріїв прийняття ризиків, які застосовуються за певних ризиків, кількісний аналіз яких вказує на те, що можливі вигоди більші, ніж відповідні ідентифіковані негативні впливи. Діаграма «торнадо» - особливий вид лінійчастої діаграми, що використовується в аналізі чутливості для порівняння відносної важливості змінних. У діаграмі «торнадо» на осі Y розташовується кожен тип невизначеності в базових значеннях, але в осі X - розкид чи кореляція невизначеності щодо досліджуваного виходу. На цьому малюнку кожна невизначеність містить горизонтальну смугу (лінію), а по вертикалі показані невизначеності з розкидом, що зменшується, від базових значень
· Аналіз очікуваного фінансового значення.Аналіз очікуваного грошового значення (expected monetary value, EMV) - це статистичний метод, з допомогою якого обчислюється середній результат, як у майбутньому є сценарії, які можуть статися чи статися (т. е. аналіз за умов невизначеності). EMV сприятливих можливостей, як правило, виражається у позитивних величинах, а загроз – у негативних. Для EMV потрібно нейтральне по відношенню до ризиків припущення - ні схильне до надмірного ризику, ні, навпаки, його повністю відкидає. Щоб розрахувати EMV для проекту, необхідно помножити значення кожного можливого результату на можливість його наступу, а потім скласти разом отримані значення. Зазвичай цей тип аналізу використовується як аналізу дерева рішень.
· Моделювання та імітація.При імітації проекту використовується модель визначення можливих впливів докладно описаних невизначеностей на мети проекту. Імітації, зазвичай, проводяться з допомогою методу Монте-Карло. При імітації модель проекту розраховується безліч разів (ітеративно), причому для кожної ітерації вхідні значення (наприклад, оцінки вартості чи тривалості операцій) вибираються довільно з розподілу ймовірностей цих змінних. Під час ітерацій розраховується гістограма (наприклад, загальна вартість чи дата завершення). Під час аналізу ризиків вартості методом імітації використовуються оцінки вартості. Під час аналізу ризиків розкладу використовується діаграма мережі розкладу та оцінки тривалості. Вихід з імітації ризиків вартості з використанням моделі за трьома елементами та діапазонами ризиків показаний на рис. нижче. Малюнок демонструє відповідну можливість досягнення певних цілей за вартістю. Подібні криві можуть бути розроблені для інших цілей проекту.
Стратегії реагування на негативні ризики (загрози)
· Ухилення. Ухилення від ризику - стратегія реагування на ризик, коли команда проекту діє з метою усунення загрози чи захисту проекту від її впливу. Як правило, вона має на увазі зміну плану управління проектом таким чином, щоб повністю виключити загрозу. Керівник проекту також може захистити цілі проекту від впливу ризику або змінити мету, яка наражається на небезпеку (наприклад, розширити рамки розкладу, змінити стратегію або скоротити зміст). Найбільш радикальною стратегією ухилення є повне припинення проекту. Від деяких ризиків, що виникають на ранній стадії проекту, можна ухилитися шляхом прояснення вимог, отримання інформації, покращення комунікацій чи придбання експертизи.
· Передача. Передача ризику – стратегія реагування на ризик, за допомогою якої команда проекту перекладає наслідки настання загрози разом із відповідальністю за реагування на третю сторону. У разі передачі ризику відповідальність за управління ним перекладається на інший бік; ризик у своїй не усувається. Передача ризику не означає відмову від відповідальності за нього шляхом передачі його майбутньому проекту або іншій особі, без повідомлення останньої або укладення з нею угоди. Передача ризику практично завжди передбачає виплату премії за ризик стороні, яка приймає він ризик. Передача відповідальності за ризик найрезультативніша щодо фінансових ризиків. Інструменти передачі можуть бути дуже різноманітними і включають, серед іншого: використання страховки, гарантії виконання зобов'язань, гарантійні зобов'язання і т. д. Для передачі відповідальності за певні ризики іншій стороні можуть використовуватися договори або угоди. Наприклад, коли покупець має можливості, які відсутні у продавця, може виявитися розумним за допомогою договору передати частину робіт та їх супутні ризики назад покупцеві. У багатьох випадках у договорі з відшкодуванням витрат вартісний ризик може передаватися покупцю, а договорі з фіксованою ціною ризик може передаватися продавцю.
· Зниження. Зниження ризику - стратегія реагування на ризик, коли команда проекту діє з метою зменшення ймовірності виникнення чи впливу ризику. Вона передбачає зменшення ймовірності та/або впливу несприятливого ризику до прийнятних граничних рівнів. Вжиті ранні дії щодо зменшення ймовірності настання ризику та/або його впливу в ході проекту часто виявляються більш результативними, ніж спроби відшкодування збитків, які здійснюються після настання ризику. Як приклади дій щодо зниження ризиків можна навести впровадження менш складних процесів, проведення більшої кількості тестів чи вибір надійнішого постачальника. Також для зниження може знадобитися розробка прототипу зменшення ризику розростання масштабів процесу чи продукту проти стендовой моделлю. Якщо неможливо зменшити ймовірність, дії зниження ризику повинні бути спрямовані на вплив ризику, а саме на ті зв'язки, які визначають серйозність впливу. Наприклад, проектування резервування системи може зменшити тяжкість наслідків відмови вихідного елемента.
· Прийняття. Прийняття ризику - стратегія реагування на ризик, коли команда проекту вирішує визнати ризик і не робити будь-яких дій до настання ризику. Ця стратегія використовується, якщо будь-який інший спосіб реагування на певний ризик є неможливим або економічно неефективним. Вона вказує на те, що команда проекту вирішила не змінювати план управління проектом для боротьби з ризиком або не здатна визначити будь-яку іншу відповідну стратегію реагування. Ця стратегія може бути пасивною чи активною. Пасивне прийняття не вимагає жодних дій, крім документування стратегії, - команді проекту доведеться мати справу з ризиками в міру їхнього настання і періодично аналізувати загрозу з метою переконатися, що вона значно не змінилася. Найбільш поширеною стратегією активного прийняття є встановлення резерву на можливі втрати, включаючи певні величини часу, грошей або ресурсів, необхідних для управління ризиками.
Стратегії реагування на позитивні ризики (сприятливі можливості)
· Використання. Стратегія використання може бути обрана для реагування на ризики з позитивним впливом, якщо з точки зору організації необхідно, щоб ця сприятлива можливість була гарантовано реалізована. Ця стратегія призначена для усунення невизначеності, пов'язаної з певним позитивним ризиком за допомогою заходів, що забезпечують реалізацію сприятливої можливості. До заходів реагування з прямим використанням відносяться: залучення до участі в проекті найбільш талановитого персоналу організації з метою скоротити час, необхідний для його завершення, або використання нових або модернізованих технологій з метою скоротити вартість і час, необхідні для досягнення цілей проекту.
· Збільшення. Стратегія збільшення використовується для підвищення ймовірності та/або позитивного впливу сприятливої можливості. Ідентифікація та максимізація ключових факторів, що зумовлюють появу даних позитивно впливають на ризик, можуть підвищити ймовірність їх настання. Приклади збільшення сприятливих можливостей включають виділення додаткових ресурсів для операції з метою її раннього завершення.
· Поділ. Поділ позитивного ризику передбачає передачу частини або всієї відповідальності за сприятливу можливість третій стороні, здатній краще за інших скористатися цією сприятливою можливістю на користь проекту. До заходів щодо поділу відносяться: освіта партнерств із спільною відповідальністю за ризики, команд, спеціалізованих компаній або спільних підприємств, які можуть засновуватися з конкретною метою отримання всіма сторонами переваг від сприятливої можливості.
· Прийняття. Прийняття сприятливої можливості - це бажання скористатися перевагою сприятливої можливості у разі її настання без її активного переслідування.
12. УПРАВЛІННЯ ЗАКУПІВЛЯМИ ПРОЕКТУ
Управління закупівлями проекту включає процеси купівлі або придбання необхідних для здійснення проекту продуктів, послуг або результатів поза командою проекту. Організація може бути як покупця, і продавця товарів, послуг чи результатів проекту.
Управління закупівлями проекту включає процеси управління договорами та процеси контролю змін, необхідні для складання та адміністрування договорів або замовлень на купівлю, підготовлених уповноваженими членами команди проекту.
Типи договорів
· Договори із фіксованою ціною.Цей вид договору передбачає загальну фіксовану вартість продукту, послуги, що поставляється, або результату. Договори з фіксованою ціною також можуть передбачати фінансові заохочення за досягнення або поліпшення окремих заданих цілей проекту, наприклад, запланованих дат поставки, технічного виконання та виконання вартості або інших показників, що піддаються кількісному визначенню та подальшому виміру. Відповідно до договорів із фіксованою ціною продавці юридично зобов'язані виконувати такі договори або зазнавати можливих фінансових збитків у разі їх невиконання. Покупці ж, відповідно до положень таких договорів, зобов'язані точно визначати продукт, що купується або послугу. Зміни змісту можуть мати місце, але зазвичай це призводить до збільшення договірної ціни.
o Договори з твердою фіксованою ціною (Firm Fixed Price Contracts, FFP). Найбільш широко використовується типом договорів є FFP. Більшість організацій-покупців воліє саме цей тип договору, оскільки ціна товарів встановлюється на самому початку і не схильна до змін, якщо не змінюється зміст робіт. Будь-яке збільшення вартості, викликане негативним виконанням, є відповідальністю продавця, який має закінчити роботу. Відповідно до FFP покупець зобов'язаний точно визначити продукт або послуги, що купується, а будь-які зміни закупівельної специфікації можуть збільшити витрати покупця.
o Договори з фіксованою ціною та заохочувальною винагородою (Fixed Price Incentive Fee Contracts, FPIF). Ця угода з фіксованою ціною надає покупцю та продавцю певну гнучкість, оскільки допускає відхилення від виконання та передбачає фінансове заохочення за досягнення обумовлених метрик. Як правило, такі фінансові заохочення пов'язані з виконанням вартості, розкладу або технічним виконанням з боку продавця. Цільові значення показників виконання встановлюються на початку, а кінцева ціна договору визначається після завершення всіх робіт залежно від виконання продавцем. У рамках FPIF встановлюється стеля цін, і відповідальність за всі витрати вище стелі цін покладається на продавця, який має завершити роботу.
o Договори з фіксованою ціною та застереженням про можливе коригування ціни (Fixed Price with Economics Price Adjustment Contracts, FP-EPA). Даний тип договору використовується у тому випадку, якщо виконання договору продавцем розтягується на значний період часу, чого зазвичай прагнуть при довгострокових відносинах. Договір з фіксованою ціною, але зі спеціальним положенням, що дозволяє вносити зумовлені остаточні коригування у вартість договору у зв'язку з умовами, що змінилися, такими як інфляція або підвищення (зниження) цін певних товарів. Застереження про коригування ціни має бути прив'язане до достовірного фінансового індексу, який використовується для точного коригування кінцевої ціни. FP-EPA покликаний захищати як покупця, і продавця від зовнішніх умов, які вони можуть контролювати.
· Договори із відшкодуванням витрат.Цей тип договору передбачає оплату (відшкодування) продавцю всіх законних фактичних витрат, понесених внаслідок виконання роботи, плюс винагорода, що становить його прибуток. До договорів із відшкодуванням витрат часто включаються пункти, що передбачають заохочувальні винагороди за перевищення чи покращення запланованих показників проекту (наприклад, вартості, розкладу чи технічного виконання). Три найбільш поширеними типами договорів із відшкодуванням витрат є: договір із відшкодуванням витрат плюс фіксована винагорода (Cost Plus Fixed Fee Contract, CPFF), договір із відшкодуванням витрат плюс заохочувальна винагорода (Cost Plus Incentive Fee Contract, CPIF), договір із відшкодуванням витрат плюс преміум винагорода (Cost Plus Award Fee Contract, CPAF). Договір із відшкодуванням витрат забезпечує гнучкість проекту, дозволяючи змінювати вказівки для продавця в тому випадку, якщо зміст робіт не може бути точно описаний на початку та потребує коригування або існують високі ризики під час виконання робіт.
o Договори з відшкодуванням витрат плюс фіксовану винагороду (CPFF). Продавцю відшкодовуються всі обумовлені витрати на виконання робіт за договором, а також виплачується фіксована винагорода, яка становить певний відсоток від первісної оцінної вартості проекту. Винагорода виплачується лише за завершену роботу та не змінюється залежно від виконання продавця. Суми винагороди не змінюються, якщо не змінюється зміст проекту.
o Договори з відшкодуванням витрат плюс заохочувальна винагорода (CPIF). Продавець отримує відшкодування всіх обумовлених витрат на виконання робіт за договором, а також заздалегідь визначену заохочувальну винагороду за досягнення конкретних показників виконання, обумовлених у договорі. У договорах CPIF зазначається, що якщо кінцеві витрати виявляються більшими або меншими за початкову оцінну вартість, то зекономлені/перевитрачені кошти розподіляються між продавцем і покупцем у заздалегідь обумовленому співвідношенні, наприклад, у співвідношенні 80/20 від різниці між запланованими витратами та фактичним виконанням продавця.
o Договори з відшкодуванням витрат плюс преміальну винагороду (CPAF). Продавцю відшкодовуються всі обґрунтовані витрати, але більшість винагороди виплачується лише з виконання низки широко тлумачених суб'єктивних критеріїв виконання, визначених у договорі. Визначення винагороди ґрунтується виключно на суб'єктивній оцінці покупцем виконання договору продавцем та, як правило, не підлягає оскарженню.
· Договори «час та матеріали»(Time & Material Contracts, T&M). Договори «час та матеріали» є змішаним типом договірних угод, що містять положення як договорів із відшкодуванням витрат, так і договорів із фіксованою ціною. Вони часто використовуються при додатковому наборі персоналу (staff augmentation), залученні експертів та будь-якої сторонньої підтримки в тих випадках, коли неможливо швидко створити точний опис робіт. Дані типи договорів нагадують договори з відшкодуванням витрат тим, що вони допускають виправлення та збільшення вартості для покупця. У момент укладання договору покупець може не вказувати загальну вартість за договором та точну кількість предметів, які потрібно поставити. Таким чином, вартість договорів T&M може збільшуватись, як і в договорах з відшкодуванням витрат. Для запобігання необмеженому зростанню вартості багато організацій вимагають включення до всіх договорів T&M граничних значень ціни та термінів. З іншого боку, договори T&M також можуть нагадувати угоди з фіксованою ціною, коли у договорі зазначаються певні параметри. Ставки оплати робочих годин або вартість матеріалів, у тому числі прибуток продавця, можуть бути заздалегідь встановлені покупцем і продавцем, якщо обидві сторони досягли угоди щодо вартості певних категорій ресурсів, наприклад, певної ставки погодинної оплати праці головних інженерів або певної ціни за одиницю матеріалу.
13. УПРАВЛІННЯ ЗАцікавленими сторонами проекту
Управління зацікавленими сторонами проекту включає процеси, необхідні для виявлення людей, груп і організацій, які можуть надавати або на яких може впливати проект, для аналізу очікувань зацікавлених сторін та їх впливу на проект, а також для розробки відповідних стратегій управління для ефективного залучення зацікавлених сторін у прийняття рішень та виконання проекту. Управління заінтересованими сторонами також зосереджується на постійній комунікації із заінтересованими сторонами з метою розуміння їх потреб та очікувань, на реагуванні на проблеми в міру їх виникнення, на управлінні конфліктуючими інтересами та на сприянні відповідному залученню зацікавлених сторін до прийняття. Задоволеністю зацікавлених сторін слід керувати однією з ключових цілей проекту.
При проведенні аналізу заінтересованих сторін використовуються різні моделі класифікації, такі як:
· матриця влади/інтересів,що групує зацікавлені сторони на основі їхнього рівня повноважень («влада») та рівня зацікавленості («інтерес») щодо результатів проекту;
· матриця влади/впливу, що групує зацікавлені сторони на основі їх рівня повноважень («влада») та активного залучення («вплив») до проекту;
· матриця впливу/дії,що групує зацікавлені сторони на основі їх активного залучення («вплив») до проекту та їх можливості призводити до змін у плануванні або виконанні проекту («вплив»);
· модель особливостей, що описує класи зацікавлених сторін залежно від їх рівня влади (здатності нав'язувати свою волю), терміновості (необхідності у негайних діях) та легітимності (їх залучення доречно).
Рівні залучення зацікавлених сторін можна класифікувати так:
· Необізнаний. Зацікавлена сторона не обізнана про проект та потенційні впливи.
· Опірний. Зацікавлена сторона обізнана про проект та потенційні впливи та пручається змінам.
· Нейтральний. Заінтересована сторона обізнана з проектом, але не підтримує зміни та не пручається їм.
· Підтримуючий. Зацікавлена сторона обізнана про проект, потенційні впливи та підтримує зміни.
· Лідируючий. Зацікавлена сторона обізнана про проект, потенційні впливи та активно залучена до забезпечення успіху проекту.
Головним виходом процесу визначення заінтересованих сторін є реєстр заінтересованих сторін. У ньому містяться всі деталі, пов'язані із заінтересованими сторонами, які були визначені, включаючи, серед іншого:
· Ідентифікаційну інформацію: П.І.Б., посада в організації, місцезнаходження, роль у проекті, контактна інформація.
· Оціночну інформацію: основні вимоги та очікування, потенційний вплив у проекті, найбільш цікава фаза у життєвому циклі проекту.
· Класифікацію зацікавленої сторони: внутрішня/зовнішня, підтримує/нейтральна/опирається тощо.
На додаток до даних із реєстру зацікавлених сторін план управління зацікавленими сторонами часто також містить:
· бажаний та поточний рівень залучення ключових зацікавлених сторін;
· Обсяг та вплив зміни на зацікавлені сторони;
· Виявлені взаємозв'язки та потенційне перетинання зацікавлених сторін;
· Вимоги зацікавлених сторін до комунікацій на поточній фазі проекту;
· відомості про інформацію, що поширюється серед зацікавлених сторін, включаючи мову, формат, зміст і ступінь деталізації;
· Причину поширення даної інформації та очікуваний вплив на рівень залучення зацікавлених сторін;
· Час та періодичність поширення необхідної інформації зацікавленим сторонам;
· Метод оновлення та уточнення плану управління зацікавленими сторонами в міру просування та розвитку проекту.
PMBOK-5 ® Guide репрезентує, як правило, визнаний добре практика в професійному проекті управління.
How to download PMBOK?
The New PMBOK Guide 5th Edition has been published on December 31st 2008.
You will find a link with title Guide to the Project Management Body of Knowledge (PMBOK. Guide), Fifth Edition which will be used to buy ця версія з PMBOK. З тією ж кнопкою цього linku, який буде йти вам, щоб отримати доступ до копії стандарту в вашому магазині. На момент його цін є $65.95 за номери та $49.50 за PMI members. Finally do a checkout та download його PDF version. Наступні процедури необхідні для того, щоб були прийняті при збереженні вашої сторінки PMBOK 5.
Windows Users:
Якщо ви завантажили українську версію до скачування PMBOK ® Guide 5th edition this message will prompt like "The FileOpen system associates your member permissions to the publication" and prompts you to download and install the FileOpen Adobe Reader plug-in.
Цей хід є необхідним для першого часу використання тільки. Клацніть Yes to begin installation of the Adobe Reader plug-in." Then after successfull installing Fileopen plugin, close the window and go back and download but you need to be a PMI member to access.
Mac Users:
Mac використовується Safari, які записують PDFs в браузері. Що не може працювати, якщо функція безпеки та інші функціональні функції є введені в PDF. Що потребує повної версії PDF Reader або Adobe Acrobat installed.
Тут є APPLE support comment on reading PDFs with Safari. Adobe PDFViewer для Mac OS X не буде керувати коректно на системі, що не може йти до наступних потреб.
Завантаження...
