Результати роботи з командою

. 1 Удосконалення виконання проекту. Основним результатом роботи з командою є удосконалення виконання проекту. Удосконалення можна чекати з різних джерел і вони можуть вплинути на багато які показники виконання проекту, наприклад:

• Удосконалення індивідуальних навичок може примусити
конкретну особу виконувати доручені їй роботи з більшою
ефективнісю.

• Удосконалення в поведінці команди (наприклад, згладжування
і вирішення конфлікту) може примусити членів команди
проекту докласти більших зусиль на виконання технічних
робіт.

• Удосконалення індивідуальних навичок або можливостей
команди може сприяти визначенню та розробці кращих шляхів
виконання робіт у рамках проекту.

.2 Вхідні дані для ОЦІНКИ виконання. Вхідні дані для оцінки виконання повинен надати персонал проекту. У загальному випадку ці оцінки стосуються всіх членів команди проекту, які істотно впливають на проект.

10.Управління інформаційним
зв'язком у проекті

Управління інформаційним зв'язком, або комунікаціями, в проектах включає

дії, необхідні для забезпечення своєчасного отримання, збору, поширення,

зберігання і кінцевого розміщення проектної інформації. Воно забезпечує

дуже важливі зв'язки між людьми для обміну ідеями та різного роду
інформацією, що в кінцевому підсумку необхідно для успішного завершення

проекту. Будь-яка особа, залучена до роботи в рамках проекту, повинна бути

готовою до пересилання та прийому інформації на «мові» проекту по

встановлених каналах, повинна розуміти, як ці комунікації впливають на
проект в цілому. Малюнок 10-1містить огляд таких основних процесів:

10.1Планування інформаційного зв'язку- визначення інформаційних і
комунікаційних потреб зацікавлених осіб: хто в якій інформації має
потребу, коли вона їм знадобиться і як вона до них надходитиме.

10.2Поширення інформації- своєчасне надання необхідної інформації
зацікавленим особам проекту.

10.3 Звітування про виконання проекту- збір і поширення інформації

про виконання. Цей процес включає складання звітів про стан,

контроль виконання та прогнозування.

10.4 Адміністративне закриття проекту - отримання, збір і поширення інформації для документально оформленого завершення всього проекту або однієї з його фаз.

Зазначені процеси взаємодіють як між собою, так і з процесами інших галузей застосування знань з проектного менеджменту. Кожний процес може включати спрямовані на задоволення потреб проекту зусилля одного чи кількох індивідуумів або груп індивідуумів, і виконується, як правило, по одному разу на кожній фазі проекту.

Хоч тут процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб, що докладно тут не описується. Детально обговорені взаємодії між процесами в розділі 3.

Загальна управлінська навичка відносно комунікації (обговорюється в пункті 2.4.2) співвідносна, але не аналогічна управлінню комунікаціями в проекті. Інформаційний зв'язок у проекті є більш широким поняттям і включає обширні знання, що не відносяться до напряму проектного оточення. Наприклад:

• Моделі «відправник-одержувач» — цикли зворотного зв'язку,
комунікаційні бар'єри і т. ін.

• Вибір засобів комунікації - коли інформувати необхідно в письмовій
формі, а коли в усній, коли можна написати неформальну записку, а
коли треба скласти офіційний звіт і т. ін.

• Стиль написання - активний або пасивний, побудова речення, добір слів
іт. ін.

• Засоби комунікації - в основному мова, проектування візуальних засобів
подання інформації і т. ін.

• Техніки управління нарадами - підготовка порядку денного, розгляд
конфліктів і т. ін.

10.1 Планування інформаційного зв'язку

Планування інформаційного зв'язку включає визначення інформаційних і комунікаційних потреб зацікавлених осіб: хто в якій інформації має потребу, коли вона їм знадобиться і як вона до них надходитиме. Усі проекти потребують передачі проектної інформації, але інформаційні потреби і методи поширення широко варіюються. Визначення потреб зацікавлених осіб в інформації і відповідних способів задоволення їх є важливим чинником успішного виконання проекту.

У більшості проектів значна частина планування комунікацій виконується в самих ранніх фазах проекту. Проте, результати цього процесу повинні регулярно переглядатися і коригуватися в разі необхідності, щоб гарантувати безперервне їх застосування.

Планування інформаційного зв'язку часто тісно зв'язане з організаційним плануванням (описаним у підрозділі 9.1), оскільки організаційна структура проекту значно впливає на комунікаційні вимоги проекту.

10.1.1 Вхідні дані для планування інформаційного зв'язку

.1 Вимоги ДО комунікацій. Вимоги до комунікацій - це загальна кількість інформаційних потреб зацікавлених осіб проекту. Вимоги визначаються типом і обсягом необхідної інформації в поєднанні з її цінністю. Ресурси проекту повинні витрачатися на передачу тільки такої інформації, яка сприятиме успіху, а відсутність останньої може призвести до невдачі. Для визначення проектних вимог до комунікацій необхідна інформація з таких питань:

• Проектна організація та взаємні обов'язки зацікавлених осіб.

• Напрямки діяльності, відділи та спеціальності, що включені до
проекту.

• Логічне рішення про те, який штат необхідний для виконання
проекту і його розстановка.

• Зовнішні інформаційні зв'язки (наприклад, із засобами масової
інформації).

.2 Технологія передачі Інформації. Прийоми та способи, що використовуються для інформаційного зв'язку між елементами проекту, можуть істотно варіюватися: від коротких звітів до розширених засідань, від простих документів до швидко доступних календарних планів і баз даних. Чинники технології передачі інформації, які можуть впливати на виконання проекту:

• Невідкладна потреба в інформації - успіх виконання проекту
залежить від того, наскільки часто виправлена інформація
доступна на момент запиту. Чи задовільні звіти, що їх
регулярно пишуть?

• Доступність технології - чи вистачає систем, які вже діють,
або може будуть потрібними якісь зміни?

• Очікуваний персонал - чи відповідають пропоновані
комунікаційні системи досвіду і знанням учасників проекту,
або може буде потрібним подальше навчання останніх?

• Тривалість проекту - чи необхідно міняти діючу технологію на
новітню перед завершенням проекту?

.3 Обмеження. Обмеження - це чинники, що обмежуватимуть вибір команди менеджерів проекту. Наприклад, якщо закуповуватимуться важливі ресурси для проекту, то можна буде ретельніше розглянути відстежування проектної інформації за контрактом.

Якщо проект виконується за контрактом, існують певні контрактні умови, які впливають на планування комунікацій.

А Допущення. Допущення - це чинники, що для цілей планування розглядаються як істинні, реальні або визначені. Допущення звичайно привносять певну міру ризику. Вони можуть бути визначені тут або можуть бути результатом ідентифікації ризику (описаної в підрозділі 11.1).

10.1.2 Методи та засоби для планування
інформаційного зв'язку

.1 Аналіз потреб зацікавлених осіб. Потреби в інформації різних зацікавлених осіб мають бути проаналізовані, для того щоб розробити методичний і логічний огляд потреб в інформації і джерел для задоволення останніх (зацікавлені особи проекту, див. підрозділи 2.2 і 5.1). Аналіз передбачає також розгляд придатних для даного проекту методів і технологій, завдяки яким надходитиме необхідна інформація. Слід уникати зайвих витрат на некорисну інформацію чи невідповідну технологію.

10.1.3 Результати планування інформаційного
зв'язку

.1 План управління комунікаціями. План управління комунікаціями -це документ, в якому відображені:

• Структура збору і зберігання - детальне описання того, які
методи використовуватимуться для збору і зберігання
різних типів інформації. Процедури повинні також
передбачати збір і поширення вже відкоригованого
попереднього матеріалу.

• Структура поширення - детальне описання того, кому
адресована інформація (звіти про стани, дані, календарний
план, технічна документація тощо) і які методи при цьому
будуть використані (письмові звіти, наради і т.ін.). Ця
структура має поєднуватися з відповідальністю і звітністю,
описаною в організаційному графіку проекту.

• Описання поширюваної інформації, включаючи обсяг, зміст,
рівень деталізації та використовувані угоди-визначення.

• Виробничі календарні плани, в яких інформується, коли який
зв'язок здійснюватгиметься.

• Методи доступу ,до інформації, що йтиме запланованими
каналами.

• Метод коригування й удосконалення плану управління
інформаційним зв'язком на тлі просування та розвитку
проекту.

План управління комунікаціями може бути формальний і неформальний, детальний і широко окреслений, але завжди заснований на потребах проекту. Він є додатковим елементом загального плану проекту (описаного в підрозділі 4.1).

10.2 Поширення інформації

Поширення інформації - своєчасне надання необхідної інформації зацікавленим особам проекту - передбачає реалізацію плану управління інформаційним зв'язком, а також реагування на несподівані запити інформації.

10.2.1 Вхідні дані для поширення інформації

.1 Результати роботи. Див. пункт 4.2.3.1.

.2 План управління комунікаціями. Див. пункт 10.1.3.1.

.З План проекту. Див. пункт 4.1.3.1.

10.2.2 Методи та засоби поширення інформації

.1 Навички В комунікаційній Сфері. Навички в комунікаційній сфері необхідні для обміну інформацією. Відправник відповідає за те, щоб інформація була чіткою, однозначною і повною, щоб одержувач міг отримати її правильною для гарантії того, що вона буде правильно сприйнята. Одержувач відповідає за перевірку того, що отримана інформація повна і неспотворена. Інформаційний зв'язок може бути:

• письмовий та усний (слухаючи й кажучи);

• внутрішній (в межах проекту) і зовнішній (із замовником,
засобами масової інформації, громадськістю і т.ін.);

• формальний (звіти, брифінги тощо) і неформальний
(нотатки на пам'ять, кулуарні бесіди і т.ін.);

• вертикальний (вверх і вниз за ієрархією) і горизонтальний (з
рівними за станом).

.2 Системи відновлення Інформації. Інформація може використовуватися всіма членами команди завдяки різноманітним

системам її відновлення: ручні системи зберігання, електронні текстові бази даних, комп'ютерні системи управління проектами, системи, що дозволяють мати доступ до технічної документації, такої як інженерні креслення.

.З Системи поширення Інформації. Проектна інформація може бути поширена різними способами, наприклад, наради по проекту, розподіл документів у вигляді «твердих копій», спільний доступ до сітьових електронних баз даних, факси, електронна пошта, усна передача інформації і відеоконференції.

10.2.3 Результати процесу поширення інформації

.1 Записи ПО проекту. Записи по проекту можуть бути у вигляді листування, нотаток на пам'ять, звітів і документів, що описують проект. Така інформація в тій мірі, в якій це необхідно і можливо, повинна організовано підтримуватися. Члени команди проекту можуть також робити персональні записи у спеціальному зошиті по проекту.

10.3 Звітування про виконання проекту

Звітування про виконання включає збір і поширення інформації про те, як використовуються ресурси для досягнення цілей проекту, з метою забезпечення нею зацікавлених осіб. Цей процес включає:

• Складання звіту про стан - описання, в якій фазі на даний час
перебуває проект.

• Звіти відносно просування - описання того, чого досягла
команда проекту.

• Прогноз - завбачення майбутнього стану проекту та його
розвитку.

Звіти про виконання в цілому повинні надавати інформацію стосовно змісту календарного плану, вартості та якості. Багато які проекти також вимагають інформації щодо ризику та закупівель. Звіти можуть бути всесторонніми або зорієнтованими на виключну ситуацію.

10.3.1 Вхідні дані для звітування про виконання проекту

.1 План проекту. План проекту (описується в пункті 4.1.3.1) містить різні вхідні дані, які можна використовувати для оцінки виконання проекту.

■

.2 Результати роботи. Результати роботи - які роботи виконані повністю, а які частково, які грошові кошти були витрачені, а які заощаджені і т.ін. - є результатом виконання плану проекту (що обговорюється в пункті 4.2.3.1). Результати роботи мають бути відображені у звіті відповідно до плану управління інформаційним зв'язком. Точна, уніфікована інформація про результати роботи необхідна для складання звітів з виконання, що знадоблятся у майбутньому.

.З ІНШІ записи ПО проекту. Записи по проекту обговорюються в пункті 10.2.3.1. Крім плану проекту та результатів роботи в рамках проекту інші документи також часто містять інформацію, яка стосується змісту проекту і яка має бути врахована при оцінці виконання проекту.

10.3.2 Методи та засоби для звітування про виконання проекту

.1 РОЗГЛЯД виконання проекту. Розгляд виконання проекту здійснюється на спеціальних нарадах; як правило, такі розгляди базуються на звітах про виконання, технології складання яких наведені далі.

.2 Аналіз відхилень. Аналіз відхилень передбачає порівняння фактичних результатів проекту з плановими або очікуваними. Найчастіше аналізу піддають ціни та графіки, але відхилення від плану, змісту, якості та ризиків виявляються часто так само важливими, якщо не більше.

.З Аналіз тенденцій. Аналіз тенденцій включає дослідження через певні відтинки часу результатів проекту з метою визначення того, чи поліпшується або погіршується виконання.

.4 Аналіз ОСВОЄНОГО обсягу. Аналіз освоєного обсягу в різних формах є щонайбільш часто використовуваним методом контролю виконання. Він полягає у контролі показників змісту, вартості та календарного плану й допомагає команді менеджерів проекту оцінити виконання проекту.

Аналіз освоєного обсягу включає контроль таких трьох основних показників по кожній роботі:

• Бюджет, або бюджетна вартість запланованих робіт (BCWS), -
частина затвердженого кошторису, що планується бути
витраченою за певний період часу.

• Фактична вартість виконаних робіт (ACWP) - сума прямих і
непрямих грошових витрат на виконання робіт за певний період
часу.

• Освоєний обсяг, або бюджетна вартість виконаних робіт
(BCWP), - відсоток загального бюджету, що дорівнює відсотку
фактично виконаної роботи в рамках проекту. Багато які
реалізації методу освоєного обсягу використовують тільки
декілька процентних значень (наприклад, 30 процентів, 70, 90,
100 процентів) для спрощення збору даних. Деякі реалізації

методу освоєного обсягу використовують тільки 0 процентів або 100 процентів (виконано або не виконано) для того, щоб допомогти добитися об'єктивності в оцінці виконання. Ці три показники використовують в поєднанні, щоб визначити, чи буде робота завершена так, як планувалося, чи ні. Щонайчастіше використовують вартісне (CV = BCWP - ACWP) та планове (SV = BCWP - BCWS) відхилення, а також показник вартісного виконання (СРІ = BCWP : ACWP). Нагромаджений СРІ (сума всіх окремих BCWP, поділена на суму всіх окремих ACWP) широко використовують для прогнозування вартості проекту по завершенні. У деяких галузях застосування знань з проектного менеджменту використовують показник планового виконання (SPI = BCWP : BCWS) для прогнозування дати завершення проекту.

.5 Методи та засоби поширення Інформації'. Звіти про виконання поширюються з використанням методів і засобів, описаних у пункті 10.1.3.1.

10.3.3 Результати звітування про виконання проекту

.1 Звіти про виконання проекту. Звіти про виконання проекту групують, підсумовують зібрану інформацію і подають результати аналізу. У звітах надані види інформації та рівень деталізації, необхідний для різних зацікавлених осіб, мають бути такими, як це задокументовано в плані управління інформаційним зв'язком.

Звичайні форми звітів про виконання проекту включають лінійні графіки (графіки Гантта), S-криві, гістограми та таблиці. На малюнку 10—2 показано використання S-кривих для зображення накопичених даних з аналізу освоєного обсягу, а малюнок 10—3 ілюструє подання різних даних, зв'язаних з освоєним обсягом, у табличній формі.

.2 Запити на зміну. Аналіз виконання проекту часто генерує запит на зміну деяких аспектів проекту. Цими запитами на зміну управляють у такий спосіб, як це описано в різних процесах контролю за змінами (наприклад, управління зміною змісту, контроль календарного плану і т.ін.).

10.4 Адміністративне закриття проекту

Проект чи фаза, після якої або проект досягає своїх цілей, або уривається з якихось причин, вимагає закриття. Адміністративне закриття складається з перевірки і документування результатів проекту з метою формалізації приймання продукту проекту інвестором, клієнтом або споживачем. Адміністративне закриття включає багато записів проекту, що відображають фінальне описання проекту, аналіз успішності й ефективності проекту, а також архівацію цієї інформації для майбутнього використання.

Роботи з адміністративного закриття не повинні тривати до завершення проекту. Кожна фаза проекту має бути вчасно і правильно закрита, для того щоб переконатися, що важливу й корисну інформацію не загублено.

10.4.1 Вхідні дані для адміністративного закриттяпроекту

.1 Документація З КОНТРОЛЮ виконання. Уся розроблена документація стосовно зберігання й аналізу результатів виконання проекту, включаючи планові документи, які створюють основу для контролю виконання, має бути доступною для перегляду під час адміністративного закриття.

.2 Документація на продукт проекту. Документи, розроблені для описання продукту проекту (плани, специфікації, технічна документація, креслення, електронні файли і т. ін. - термінологія змінюється залежно від прикладної сфери), також мають бути доступними для перегляду під час адміністративного закриття.

.3 ІНШІ Записи ПО проекту. Див. пункт 10.2.3.1.

10.4.2 Методи та засоби адміністративного
закриття проекту

.1 Методи та засоби для складання звітів про виконання.

пункті 10.3.2.

10.4.3 Результати адміністративного закриття

.1 Архів проекту. Вся безліч індексованих записів по проекту має бути підготовлена для передачі до архіву відповідними особами. Будь-які проектно-орієнтовані або програмно-залежні бази даних мають бути скориговані. Якщо проекти виконуються за контрактом або включають значні закупівлі, особлива увага має бути приділена зберіганню записів стосовно фінансів.

.2 Формальне приймання. Має бути підготовлена документація, за якою клієнт або спонсор прийматиме продукт по проекту (чи фази проекту).

.3 Засвоєні уроки. Див. пункт 4.3.3.3.

11.Управління ризиком у проекті

Управління ризиком у проекті включає процеси, зв'язані з

ідентифікацією, аналізом і розвиненням реакції на ризик у проекті.

Воно передбачає також максимізацію переваг від позитивних подій у
проекті та мінімізацію наслідків негативних подій. Малюнок 11-1

містить огляд таких основних процесів:

11.1 Ідентифікація ризику- визначення того, які ризики можуть
впливати на проект, і документування їх характеристик.

11.2 Кількісна оцінка ризику- оцінка ризику та ризикованих

взаємодій для визначення діапазону можливих наслідків для

проекту.

11.3 Розвинення реакції на ризик- визначення кроків для
підсилення сприятливих можливостей і реакцій на загрози.

11.4 Контроль за реакцією на ризик- реагування на зміни ризику

в ході виконання проекту.

Зазначені процеси взаємодіють як між собою, так і з процесами

інших галузей використання знань з проектного менеджменту. Кожний

процес може включати зусилля одного чи кількох індивідуумів або

груп індивідуумів, спрямовані на задоволення потреб продукту,

і виконується, як правило, по одному разу в кожній фазі проекту.

Хоч тут процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб, що тут докладно не описується. Детально обговорені взаємодії між процесами в розділі 3.

Різні прикладні сфери часто використовують різні найменування зазначених процесів. Наприклад:

• Ідентифікація ризику та кількісна оцінка ризику іноді
розглядають як один процес. Ця комбінація дістала назву «аналіз
ризику», або «оцінка ризику».

• Розвинення реакції на ризик іноді називають плануванням
зменшення ризику.

Розвинення реакції на ризик і контроль за реакцією на ризик іноді об'єднують в єдиний процес під назвою «управління ризиком».

11.1 Ідентифікація ризику

Ідентифікація ризику полягає у визначенні того, які ризики можуть впливати на проект, і документуванні характеристик кожного з них. Ідентифікація ризику не є однократною подією; вона має здійснюватися на постійній основі протягом усього процесу виконання робіт у рамках проекту.

Ідентифікація ризику повинна враховувати як внутрішні, так і зовнішні ризики. Внутрішні ризики - це події, які команда проекту може контролювати або на які може впливати (наприклад, призначення персоналу і затвердження кошторису). Зовнішні ризики - це події, які перебувають поза контролем або поза впливом команди проекту (наприклад, зміни на ринку або якісь урядові дії").

Суворо кажучи, ризик охоплює тільки можливість втрат або збитку. Проте, в контексті проекту ідентифікація ризику зв'язана із сприятливими можливостями (позитивні результати) та із загрозами (негативні результати). Ризик можна ідентифікувати шляхом визначення причини-наслідку (що може статися і що виникне) або наслідку-причини (яких результатів слід уникати, а яких і в який спосіб домагатися).

11.1.1 Вхідні дані для ідентифікації ризику

.1 Описання продукту. На ризики, що визначаються, основний вплив чинить, як правило, природа продукту проекту. Продукти, які включатимуть перевірені технології, будуть схильні до меншого ризику порівняно з продуктами, від яких вимагатиметься інновація чи винаходи. Ризики, зв'язані з продуктом проекту, часто описують у вартісному та плановому уявленні. Розділ 5.1.1.1 містить додаткову інформацію про описання продукту.

.2 Результати інших процесів планування. Для визначення можливих ризиків рекомендується розглядати результати процесів в інших галузях застосування знань з проектного менеджменту, наприклад такі, як:

• Ієрархічна структура робіт - нетрадиційні підходи до
детального результату можуть містити сприятливі можливості,
які не можна виявити на більш високих рівнях при описанні

. змісту проекту.

• Оцінки вартості та тривалості робіт - оптимістичні оцінки або
оцінки, прийняті в умовах обмеженого обсягу інформації,
містять більше ризику.

• Штатний розклад - деякі члени команди можуть мати
унікальні навички і їм може бути важко знайти заміну або,
навпаки, вони можуть мати такі обов'язки, які зроблять їх
внесок незначним.

• План управління закупівлями - такі умови ринку, як інертна
внутрішня економіка, можуть надати можливість зменшити
контрактні ціни.

.З Інформація 3 архіву. Інформація з архіву про те, що відбувалося в попередніх проектах, може бути особливо корисною при визначенні можливих ризиків. Інформація з архіву про результати часто може бути доступною з таких джерел:

• Проектні файли - одна або кілька організацій, що беруть участь у проекті, можуть зберігати записи результатів попередніх проектів, достатньо детальних, щоб допомогти у визначенні ризику. У деяких прикладних сферах такі записи можуть зберігати також окремі члени команди.

• Комерційні бази даних - інформація з архіву комерційно
доступна в багатьох прикладних сферах.

• Інформованість команди проекту - окремі члени команди
проекту можуть пам'ятати попередні випадки або прийняті
рішення. Така інформація може бути корисною, але в той
самий час вона в основному менш достовірна, ніж
документовані результати.

11.1.2 Методи та засоби для ідентифікації ризику

1. Контрольні переліки. Контрольні переліки звичайно впорядковані по джерелах ризику. Останні включають середовище проекту (див. розділ 2), результати інших процесів планування (див. пункт 11.1.1.2), продукт проекту або результати використання технологій, такі внутрішні джерела, як навички окремих членів команди або відсутність таких. У деяких прикладних сферах широко використовуються схеми класифікації джерел ризику.

.2 Побудова графіка потоків. Графік потоків (описаний у пункті 8.1.2.3) може допомогти команді проекту краще зрозуміти причини та наслідки ризиків.

.3 Інтерв'ювання. Інтерв'ю, спрямовані на виявлення ризиків, з різними зацікавленими особами можуть допомогти визначити ризики, не визначені під час звичайного планування робіт. Записи попередніх інтерв'ю (наприклад, ті, що провадилися на стадії ТЕО) можуть також бути корисними.

11.1.3 Результати ідентифікації ризику

.1 Джерела ризику. Джерела ризику є категоріями можливих ризикованих подій (наприклад, дії зацікавленої особи, ненадійні оцінки, зміна команди), які можуть позитивно чи негативно впливати на проект. Перелік джерел має бути вичерпним, тобто він повинен включати всі визначені елементи, незважаючи на частоту, ймовірність випадків або величину прибутку чи втрати. Загальні джерела ризику включають:

• Зміни у вимогах.

• Похибки при проектуванні, упущення та непорозуміння.

• Невдалий розподіл обов язків і розстановка кадрів.

• Погані оцінки.

• Недостатня кваліфікація персоналу.

Описання джерел ризику повинні, як правило, включати оцінки (а) ймовірності того, що ризикована подія від конкретного джерела станеться, (Ь) діапазону можливих результатів, (с) очікуваного часу та (d) частоти випадків ризику від цього джерела.

І ймовірності, і результати можуть бути визначені як неперервні (оцінна вартість між $100000 і $150000) або як дискретні (патент або буде отриманий, або ні) функції. Крім того, оцінки ймовірностей і результатів, зроблені в ранніх фазах проекту, повинні мати більш широкий діапазон порівняно з тими, що

зроблені пізніше.

■

.2 Події потенціального ризику. Події потенціального ризику є дискретними, такі як, наприклад, стихійне лихо, катастрофа або звільнення певного члена команди, і вони можуть впливати на проект. Події потенціального ризику мають бути визначені в доповнення до джерел ризику, коли ймовірність події або величина витрат є відносно великою (поняття «відносно велика» в проекті варіюється). У той час, як події потенціального ризику рідко зустрічаються в деяких прикладних сферах, перелік подій загального ризику є звичайним. Наприклад:

• Розробка нових технологій, яка усуне потребу в даному
проекті, є звичайною ситуацією в електроніці, але рідкісною в
проектах з нерухомості.

• Втрати через стихійне лихо є звичайними в будівництві, але
рідкісними в бютехнолопі.

Описання подій потенціального ризику повинні, звичайно, включати оцінки (а) ймовірності того, що ця ризикована подія станеться, (Ь) альтернативних можливих результатів, (с) очікуваного часу події та (d) частоти (тобто ця ризикована подія може статися більше одного разу).

.3 Симптоми ризику. Симптоми ризику є непрямими виявами подій реального ризику. Наприклад, низька мораль може бути раннім сигналом застереження майбутніх затримок календарного плану, перевищення кошторису на перших роботах проекту можуть бути відображенням недосконалої оцінки.

4 Вхідні дані для інших процесів планування. Процес ідентифікації ризику може визначати необхідність подальшої роботи в іншій галузі. Наприклад, ієрархічна структура робіт може бути недостатньо детальною, щоб адекватно ідентифікувати ризики. Ризики часто вводять в інші процеси як обмеження чи допущення.

*<■■■ -а,.-■:■. v .■ ■ фмх ■•.•:,.:••■■.■ ■.;:.-> ' ..м ■

11.2 Кількісна оцінка ризику

Кількісна оцінка ризику - це оцінка ризику та ризикованих взаємодій для визначення діапазону можливих наслідків для проекту. Кількісна оцінка ризику зв'язана головним чином з визначенням того, які ризиковані події вимагають реакції-відповіді. Ця оцінка ускладнюється множиною чинників, серед яких:

• Сприятливі можливості і загрози, які можуть взаємодіяти в
непередбаченому напрямку (наприклад, планові затримки
можуть форсувати розгляд нової стратегії, яка скоротить
загальну тривалість проекту).

• Одна ризикована подія, яка може спричинити численні
негативні наслідки. Так, пізнє постачання основного
компонента стає причиною перевищення, затримок
календарного плану робіт, штрафних платежів і зниження
якості продукту.

• Сприятливі можливості для однієї зацікавленої особи
(зниження вартості) можуть бути загрозою для іншої
(зменшення прибутку).

• Використовувані математичні методи, які можуть створювати
помилкове враження точності та надійності.

11.2.1 Вхідні дані для кількісної оцінки ризику

.1 Допущення, що стосуються ризику зацікавлених осіб. Різні організації і приватні особи мають різні допущення по ризиках. Наприклад:

• Високоприбуткова компанія готова витратити $500000, щоб
внести пропозицію про контракт в $1 мільярд, у той час як
інша компанія цього зробити не може.

• Одна організація сприймає кошторис, який має 15-відсоткову
ймовірність перевитрати як високий ризик, у той час як інша
сприймає це як низький ризик.

Допущення, що стосуються ризику зацікавлених осіб, складають основу для вхідних даних і результатів при кількісній оцінці ризику.

.2 Джерела ризику. Див. в розділі 11.1.3.1.

.3 Події потенціального ризику. Див. пункт 11.1.3.2.

4 Кошториси. Див. пункт 7.2.3.1.

.5 Оцінки тривалості робіт. Див. пункт 6.3.3.1.

11.2.2 Методи та засоби для кількісної оцінки
ризику

.1 Очікуване грошове значення. Очікуване грошове значення як інструмент кількісної оцінки ризику є продуктом двох показників:

• Імовірності ризикованої події - оцінки ймовірності того, що
дана ризикована подія станеться.

• Величини ризикованої події - оцінки прибутку (втрати), що
очікується, якщо ризикована подія станеться.

При підбитті підсумків з розподілу ймовірностей враховувати таке:

• Якщо, як в цьому прикладі, значення розподілу зсунуті вліво, то математичне сподівання проекту завжди
буде значно вищим, ніж сума найбільш імовірних оцінок.

• Розподіли можуть змішуватися і збігатися. Для спрощення в цьому прикладі використовується один і той
самий розподіл для всіх робіт.

Для підбиття підсумків по розподілу ймовірностей обчисліть:

• Математичне сподівання, середньоквадратичне (стандартне) відхилення та дисперсію для кожної окремої
роботи, взявши за основу закони розподілу (наприклад, бета, трикутний, нормальний і т.д.).

• Математичне сподівання проекту є сумою математичних сподівань окремих робіт.

• Дисперсія проекту є сумою дисперсій по окремих роботах.

• Середньоквадратичне (стандартне) відхилення проекту дорівнює кореню квадратному з дисперсії проекту.

Величина ризикованої події повинна відбивати як відчутні, так і невідчутні впливи. Наприклад, проект А і проект Б визначають рівну ймовірність відчутної втрати в $100000 як результат нереальної цінової пропозиції. Якщо проект А передбачає невідчутні наслідки, а

проект Б передбачає, що така втрата веде до припинення роботи виконавчої організації, то ці два ризики не є еквівалентними.

Подібно до цього відсутність невідчутних впливів у цих обчисленнях може дещо спотворити результат через зрівняння маленької втрати з високою ймовірністю і великої втрати з маленькою ймовірністю.

Очікувані грошові значення звичайно використовуються як вхідні дані для подальшого аналізу (наприклад, у дереві рішення), оскільки ризиковані події можуть відбуватися індивідуально і групою, паралельно і послідовно.

.2 Статистичні суми. Статистичні суми можуть бути використані для визначення діапазону загальних проектних вартостей по кошторисах для окремих елементів роботи. (Визначення діапазону ймовірних дат завершення проекту за оцінками тривалості робіт вимагає моделювання (описаного в пункті 11.2.2.3)). Діапазон загальних' проектних вартостей може бути використаний для кількісної оцінки відносного ризику альтернативних бюджетів проекту або цін пропозицій. На малюнку 11—2 показане використання методу моментів для обчислення діапазону проектних оцінок.

. З Моделювання. Моделювання використовує зображення, або модель, системи для аналізу поведінки (дії) системи. Найбільш загальною формою моделювання в проекті є моделювання календарного плану з використанням сітьової моделі проекту. Більшість процесів моделювання календарного плану базується на деяких формах методу «Монте-Карло». При використанні цього методу, адаптованого до звичайного управління, виконання проекту до того, щоб забезпечити статистичний розподіл обчислюваних результатів, як показано на малюнку 11—3, затягується на досить довгий час.

Результати моделювання календарного плану можуть бути використані для кількісної оцінки ризику різних альтернатив календарного плану, різних проектних стратегій, різних шляхів сітьової моделі або індивідуальних робіт.

Моделювання календарного плану необхідно використовувати для будь-яких великих або складних проектів, оскільки за традиційними математичними методами аналізу, такими як метод критичного шляху і метод оцінки та перегляду програми (PERT), не можна обчислити конвергенцію (збіжність) шляху (див. малюнок 11—4), тобто вказані методи ведуть до недооцінки тривалості проекту.

Метод «Монте-Карло» та інші форми моделювання можуть також використовуватися для оцінки діапазону можливих вартісних

результатів.

.4 Дерево рішень. Дерево рішень - це діаграма, на які зображено.

ключові взаємодії серед рішень і зв’язаних з ними випадкових подій,

як їх розуміють ті, хто приймає рішення. Гілки дерева - це рішення (в прямокутниках) або випадкові події (в колах). Приклад дерева рішень показаний на малюнку 11—5.

.5 ВИСНОВОК експерта. Висновок експерта часто застосовують замість математичних методів, описаних вище, або як доповнення до них. Наприклад, ризиковані події можуть бути описані як такі, що мають (1) високу, середню чи низьку ймовірність того, що вони можуть статися, і (2) сильний, помірний або обмежений вплив.

11.2.3 Результати кількісної оцінки ризику

.1 Використання сприятливих можливостей, реакція на загрози. Головним результатом кількісної оцінки ризику є перелік можливостей, які повинні бути використані, і загроз, на які необхідно звернути увагу.

.2 Ігнорування сприятливих можливостей, прийняття загроз. У процесі кількісної оцінки ризику необхідно документувати (а) ті джерела ризику і ризиковані події, які команда менеджерів проекту свідомо вирішила прийняти або ігнорувати, і (Ь) хто прийняв таке рішення.

11.3 Розвинення реакції на ризик

Розвинення реакції на ризик полягає у визначенні кроків для підсилення сприятливих можливостей і реакцій на загрози. Реакції на загрози звичайно належать до однієї з трьох таких категорій:

• Уникнення - усунення певної загрози, звичайно, шляхом
ліквідації причини. Команда управління проектом ніколи не
може позбутися всіх ризиків, але часто може усунути певні
ризиковані події.

• Пом'якшення - зменшення очікуваного грошового значення
ризикованої події зниженням імовірності випадку
(наприклад, використання перевірених технологій для
зменшення імовірності того, що продукт проекту не
працюватиме) та величини ризикованої події (наприклад,
страхування).

здійснюватимуться плани з невизначеності і як розподілятимуться резерви.

План управління ризиком може бути формальний і неформальний, дуже детальний і широко окреслений, але завжди заснований на потребах проекту. Він є додатковим елементом загального проектного плану (описаного в підрозділі 4.1).

.2 ВХІДНІ дані для ІНШИХ процесів. Усі вибрані чи запропоновані альтернативні стратегії, плани з невизначеностей, очікувані закупівлі та інші результати, що стосуються ризиків, повинні мати зворотний зв'язок з відповідними процесами в інших галузях застосування знань з проектного менеджменту.

■

.З Плани З невизначеності. Плани з невизначеності - це перелік певних дійових кроків, які мають бути здійснені, якщо станеться певна ризикована подія. Плани з невизначеності звичайно є частиною плану управління ризиком, але вони також можуть бути об'єднані в інші частини загального плану проекту (наприклад, як частина плану управління змістом проекту або плану управління якістю).

4 Резерви. Резерв - це можливість у проектному плані зменшити ризик по вартості й (або) ризик за календарним планом. Цей термін часто використовується з уточненнями (наприклад, управлінський резерв, резерв невизначеності, резерв календарного плану), для того щоб забезпечити подальший детальний розгляд тих типів ризику, які необхідно пом'якшити (зменшити). Значення уточнюючих термінів часто варіюються залежно від прикладних сфер. Крім того, використання резерву і визначення того, що може бути включено до нього, також є залежним від прикладної сфери.

■.5 Контрактні угоди. Контрактні угоди можуть вводитися по

страхуванню, послугах та інших елементах, для того щоб уникнути загроз або зменшити їх. Контрактні строки та умови матимуть значний вплив на ступінь зменшення ризику.

11.4 Контроль за реакцією на ризик

Контроль за реакцією на ризик включає виконання плану управління ризиками, для того щоб реагувати на ризиковані події в ході виконання проекту. Коли відбуваються зміни, то повторюється основний цикл з ідентифікації, кількісної оцінки та реакції на ризик. Важливо розуміти, що навіть ретельний і всебічний аналіз не зможе правильно визначити всі ризики та ймовірності; тому необхідні контроль і покрокові дії.

11.4.1 Вхідні дані для контролю за реакцією на
ризик

. 1 План управління ризиком. Див. пункт 11.3.3.1.

.2 Фактичні ризиковані ПОДІЇ. Деякі з ідентифікованих ризикованих подій відбуваються, деякі - ні. Ризиковані події, що відбуваються, називають фактичними ризикованими подіями, або джерелами ризику, і команда управління проектом повинна усвідомити, що ризикована подія сталася і має бути реалізованою розроблена на ризик реакція.

.З Ідентифікація додаткового ризику. По мірі здійснення контролю і складання звітів з виконання проекту (описаних в підрозділі 10.3) можуть бути визначені потенціальні ризиковані події, або джерела ризику, які заздалегідь не були визначені.

11.4.2 Методи та засоби для контролю за
реакцією на ризик

.1 Понаднормові роботи. Понаднормові роботи - це позапланова реакція на негативні ризиковані впливи. Понаднормові роботи не плануються тільки тоді, коли у разі виникнення конкретної ризикованої події реакція не визначена.

.2 Додаткові реакції на ризик. Якщо ризикована подія не передбачається або ефект від неї більший, ніж очікувався, то планова реакція може бути не адекватною, і тоді необхідно повторити процес розвинення реакції на ризик, а може і процес кількісної оцінки ризику.

11.4.3 Результати контролю за реакцією на ризик

.1 Коригуючі ДІЇ. Коригуючі дії насамперед містять планову реакцію на ризик (наприклад, реалізацію планів з невизначеностей або понаднормові роботи).

2. Коригування плану управління ризиком. Очікувані ризиковані події виникають або не виникають, і оскільки вплив фактичних ризикованих подій можна оцінити, то оцінки ймовірностей і значень ризиків, а також інших аспектів плану управління ризиками мають бути скориговані.

12.Управління закупівлями
в проекті

Управління закупівлями в проекті включає процеси, необхідні для

придбання товарів і послуг за межами виконавчої організації. Далі для

простоти товари та послуги, незалежно від кількості, називатимуться
«продукт». Малюнок 12—1містить огляд таких основних процесів:

12.1 Планування закупівель- визначення того, що і коли
необхідно придбати.

12.2 Планування клопотань- документальне оформлення вимог
до продукту та визначення потенціальних джерел його
отримання.

12.3 Клопотання- отримання тендерної документації, тендерних
пропозицій або інших слушних пропозицій.

12.4 Вибір джерела- вибір серед потенціальних продавців.

12.5 Адміністрування контракту— управління зв'язком з
продавцем.

12.6 Закриття контракту- завершення і врегулювання виконання

завдань контракту, включаючи вирішення відкритих питань.

Зазначені процеси взаємодіють як між собою, так і з процесами

інших галузей застосування знань з проектного менеджменту

Кожний процес може включати зусилля одного чи кількох індивідуумів або

груп індивідуумів, спрямовані на задоволення потреб проекту, і

виконується, як правило, по одному разу на кожній фазі проекту.

Управління закупівлями в проекті обговорюється з позиції покупця у відношенні «покупець-продавець». Відношення «покупець-прода-вець» може існувати на багатьох рівнях одного проекту. Залежно від прикладної сфери продавець може бути названий підрядчиком або постачальником.

Продавець звичайно управляє своєю роботою у проекті. В таких випадках:

• Покупець стає споживачем або основною зацікавленою особою по
відношенню до продавця.

• Команда менеджерів проекту продавця повинна зосередитися на
всіх процесах управління проектом, а не тільки на тому, який
належить до їх галузі знання.

• Строки та умови контракту стають основними вхідними даними
для багатьох процесів продавця. Контракт може фактично містити
вхідні дані (наприклад, основний результат, ключові віхи, вартісні
задачі) або він може бути обмежений рішеннями команди проекту
(наприклад, під час проектування часто буває необхідним
затвердження рішень з питань персоналу з боку покупця).

У даному розділі передбачається, що продавець є особою із зовні відносно організації, що виконує проект. Проте, більшість міркувань також застосовна і тоді, коли формальна угода укладається з якимось підрозділом організації, що виконує проект. У випадку неформальних угод краще застосовувати процеси, описані в розділах 9, 10.

12.1 Планування закупівель

Планування закупівель - це процес визначення проектних потреб, які можуть задовольнятися найкращим чином з допомогою закупівлі товарів і послуг за межами виконавчої організації. Він включає обговорення того, чи варто закуповувати, як, що, скільки і коли це

робити.
_ ......

Якщо проект отримує товари та послуги від зовнішніх організацш-

постачальників, мають бути виконані процеси, починаючи від планування клопотання (підрозділ 12) й до закриття контракту (підрозділ 12.6), принаймні один раз для кожного товару чи послуги. У разі необхідності команда управління проектом може звернутися за підтримкою до фахівців у галузі контрактів і закупівель.

Якщо проект не отримує товари та послуги від виконавчої організації, процеси, починаючи від планування клопотання (підрозділ 12.2) й до закриття контракту (підрозділ 12.6), не можуть бути виконані. Це часто трапляється в проектах дослідження і розвитку, коли виконавча організація неохоче використовує проектну технологію, й набагато рідше у внутрішніх проектах, коли вартість пошуку і управління зовнішніми ресурсами може перевищити потенціальні заощадження.

До планування закупівель має також увійти розгляд можливих субпідрядів, особливо, якщо покупець бажає деякою мірою впливати на субпідрядні рішення або здійснювати контроль над ними.

12.1.1 Вхідні дані для планування закупівель

.1 Описання змісту проекту. Описання змісту проекту (див. пункт 5.2.3.1) включає описання поточних проектних меж, надає важливу інформацію про потреби та стратегії проекту, які мають бути розглянуті в процесі планування закупівель.

.2 Описання продукту. Описання продукту проекту (пункт 5.1.1.1) містить важливу інформацію про будь-які технічні рішення або проблеми, які необхідно розглянути в процесі планування закупівель.

Описання продукту проекту, який характеризує кінцевий продукт проекту, звичайно ширший від описання (що обговорюється в пункті 12.1.3.2), де характеризується частина цього продукту, надана

продавцем проекту. Проте, якщо виконавча організація закуповує весь продукт, відмінність між двома термінами стає незначною.

.3 Ресурси закупівлі. Якщо виконавча організація не має офіційної групи по роботі з контрактами, то члени команди проекту повинні набути знань і досвіду для підтримки проектних робіт по закупівлі.

4 Умови ринку. При плануванні закупівель мають бути враховані асортимент товарів і послуг на ринку, товаровиробника, а також строки й умови.

.5 Результати інших процесів планування. Плануючи закупки, необхідно розглядати, наскільки доступні для врахування результати інших процесів, таких як попередня оцінка вартості й календарного плану, плани управління якістю, прогнози руху грошових коштів, ієрархічна структура робіт, ідентифіковані ризики, планування штатного розкладу.

.6 Обмеження. Обмеження - це чинники, що обмежують права покупця. Одним з найбільш поширених обмежень для багатьох проектів є наявність грошових коштів.

.7 Допущення. Допущення - це чинники, які для цілей планування розглядатимуться як істинні, дійсні або визначені.

12.1.2 Методи та засоби планування закупівель

.1 Аналіз «зробити або купити». Цей аналіз є звичайним методом управління, який можна використовувати для визначення того, чи спроможна виконавча організація виробити окремий продукт ефективно з точки зору витрат. Обидві сторони аналізу включають прямі та непрямі витрати. Наприклад, сторона «купити» має включати як поточні позикові кошти для закупівлі продукту, так і непрямі витрати на управління процесом закупівлі.

Аналіз «зробити або купити» повинен відображати як точку зору виконавчої організації, так і безпосередні потреби проекту. Наприклад, закупівля важливого елемента (від будівельного крана до персонального комп'ютера), а не його оренда, рідко буває ефективною. Проте, якщо виконавча організація має часту потребу в цьому елементі, то частина вартості покупки, що виділяється для проекту, може бути меншою від вартості оренди.

.2 ВИСНОВОК експерта. Висновок експерта необхідний для оцінки вхідних даних цього процесу. Така експертиза може бути надана будь-якою групою чи окремою особою із спеціальними знаннями або підготовкою і може бути доступна для багатьох джерел, включаючи:

• інші підрозділи виконавчої організації;

• консультантів;

• професійні та технічні асоціації;

• промислові групи.

.З Вибір типу контракту. Різні типи контрактів більшою чи меншою мірою відповідають різним типам закупівлі. Контракти звичайно належать до однієї з трьох таких великих категорій:

• Контракти з твердою ціною або з фіксованою вартістю - ця
категорія контракту включає загальну тверду ціну для
конкретного продукту. Якщо продукт чітко не визначений, то і
покупець, і продавець ризикують: покупець може не отримати
бажаного продукту, а продавець може понести додаткові
витрати, для того щоб надати такий продукт. Контракти з
твердою ціною можуть також включати стимули для
проведення зайвих нарад або перевиконання визначених цілей

проекту, наприклад цільового календарного плану. ....

• Контракти з відшкодуванням витрат - ця категорія контракту

звичайно включає оплату (відшкодування) продавцеві його фактичних витрат. Витрати бувають прямі та непрямі. Прямими називають витрати, що мають відношення до чистого прибутку проекту (наприклад, оклади персоналу, зайнятого повний робочий день). Непрямі витрати, або накладні видатки - це такі витрати на проект, як витрати на ведення бізнесу (наприклад, оклади корпоративних посадових осіб). Непрямі витрати звичайно обчислюють у відсотках прямих витрат. Контракти з відшкодуванням витрат часто включають стимули для проведення зайвих нарад або перевиконання визначених цілей проекту, наприклад цільового календарного плану або підсумкової вартості.

• Контракти з ціною за одиницю - продавцю сплачується
заздалегідь встановлена ціна за одиницю послуги (наприклад,
$70 за годину професійних послуг або $1.08 за куб. ярд виритої
землі). Загальна сума контракту - це функція величин,
необхідних для завершення роботи.

12.1.3 Результати планування закупівель

.1 План управління Закупівлями. План управління закупівлями має розкривати, як управлятимуть рештою процесів закупівель (починаючи від планування клопотань до закриття контракту). Наприклад:

• Які типи контрактів використовуватимуться?

• Чи потрібні як критерії незалежні оцінки, хто і коли їх
готуватиме?

• Якщо у виконавчої організації є відділ закупівлі, то які дії
може вживати команда управління проектом у ньому?

• Якщо нормативні документи стосовно закупівлі необхідні, то
де їх брати?

• Як управляти численними постачальниками?

• Як закупівля координуватиметься з іншими проектними
аспектами, такими як планування і складання звітів про
виконання?

План управління закупівлею може бути формальний і неформальний, дуже детальний і широко окреслений, але завжди заснований на потребах проекту. Він є додатковим елементом загального плану проекту (описаного в підрозділі 4.1).

.2 Описання роботи. Описання роботи (SOW) визначає процес закупівлі досить детально, щоб дати можливість продавцям вирішити, чи здатні вони забезпечити даний елемент. Термін «досить детально» може варіюватися залежно від сутності елемента, потреб покупця або передбачуваних контрактних форм.

Деякі прикладні сфери визнають різні типи SOW. Наприклад, у деяких державних установах термін «SOW» застосовують для елемента закупівлі, в якому чітко визначений товар або послуга; термін «опис вимог» (SOR) використовують для елемента закупівлі, що являє собою проблему, яку необхідно вирішити.

Описання робіт може бути переглянуте і поліпшене протягом процесу закупівель. Наприклад, передбачуваний продавець може запропонувати більш ефективний підхід або більш дешевий продукт порівняно з визначеними спочатку. Кожний окремий елемент закупівлі вимагає окремого описання робіт. Проте, численні товари чи послуги можуть бути згруповані в один елемент закупівлі з єдиним SOW.

Описання робіт має бути ясним, повним і чітким настільки, наскільки це можливо. Воно повинно включати описання необхідних додаткових послуг, таких як складання звітів про виконання або постпроектна оперативна підтримка для елемента, що закуповується. Для деяких прикладних сфер сформульовані визначення змісту та формальні вимоги відносно SOW.

Планування клопотань

Планування клопотань включає підготовку документів, необхідних для підтримки клопотань (процес підготовки клопотань описаний в підрозділі 12.3).

12.2.1 Вхідні дані для планування
клопотань

. 1 План управління закупівлями. Див. пункт 12.1.3.1.

.2 Описання роботи. Див. пункт 12.1.3.2.

.3 Результати інших процесів планування. Результати інших процесів планування, що розглядалися як частина планування закупівлі (див. пункт 12.1.1.5), могли змінитися, тому вони мають бути переглянуті знов, але вже як частина клопотання. Особливо ретельно план клопотань повинен бути узгоджений з календарним планом проекту.

12.2.2 Методи та засоби для планування
клопотань

.1 Стандартні форми. Стандартні форми можуть включати стандартні контракти, стандартні описання елементів закупівлі, стандартизовані версії всіх або частини необхідних документів по торгах (див. пункт

12.2.3.1). Організації, в яких здійснюється значна закупівля, повинні мати більшу частину цих документів.

.2 ВИСНОВОК експерта. Див. пункт 12.1.2.2.

L2.2.3 Результати планування клопотань

.1 Документи ПО закупівлі. Документи по закупівлі використовують для пропозицій-клопотань від передбачуваних продавців. Терміни "торг" і «котирування» звичайно використовують, коли джерело вибраного рішення керуватиметься вартістю (придбання комерційних елементів), тоді як термін «пропозиція» звичайно використовують, коли розглядувані невартісні чинники, такі як технічні навички або підходи, є переважаючими (придбання професійних послуг). Проте, ці терміни часто використовують як рівнозначні і тоді можна особливо не стежити за відмінністю у використанні їх.

Загальні назви для різних типів документів по закупівлі: «Запрошення для участі в торгах» (IFB), «Запит на пропозицію» (RFP), «Запит на котирування цін» (RFQ), «Запрошення на переговори», «Первинне сповіщення підрядчика».

Документи по закупівлі мають бути структуровані, щоб сприяти точним і повним відповідям від передбачуваних продавців. До їх складу обов'язково мають бути включені описання роботи, що стосуються справи, необхідні форми для відповіді і дещо з умов контракту (наприклад, копія моделі контракту або про нерозголошування умов). Деяка частина або весь зміст і структура документів по закупівлі, особливо тих, що підготовлені державними органами, можуть визначатися відповідними нормами на них.

Документи по закупівлі мають бути не тільки досить точними, щоб гарантувати порівнянні, погоджені відповіді, а й досить гнучкими, щоб якнайкраще забезпечити розгляд пропозицій продавця для задоволення вимог.

.2 Критерії ОЦІНКИ. Критерії оцінки використовують для ранжування або нормування пропозицій. Вони можуть бути об'єктивними (наприклад, передбачуваний менеджер проекту має бути «сертифікованим» професіоналом в галузі управління проектами) або суб'єктивними (наприклад, передбачуваний менеджер проекту повинен мати документально підтверджений досвід роботи в схожих проектах). Критерії оцінки часто включають в документи по закупівлі.

Критерії оцінки можуть бути обмеженими для закупівельної ціни, якщо відомо, що елемент закупівлі легко доступний з числа прийнятних джерел (термін закупівельна ціна в цьому контексті включає і вартість елемента, і додаткові витрати на постачання). Коли це не має значення, то повинні бути визначені та задокументовані інші критерії для підтримки повної оцінки. Наприклад:

• Розуміння потреб - як воно продемонстровано пропозицією
продавця.

• Загальна вартість, або вартість життєвого циклу, - чи буде
вибраний продавець надавати найнижчу підсумкову вартість
(закупівельна вартість плюс поточні витрати)?

• Технічні можливості - чи має продавець необхідні технічні
навички і знання або чи впевнений він, що зможе їх надбати?

• Підхід до управління - чи є в арсеналі продавця процедури і

процеси управління, щоб гарантувати успішне завершення проекту, а чи впевнений він у тому, що зможе їх розробити? • Фінансові можливості - чи має продавець необхідні фінансові ресурси або чи впевнений він у тому, що зможе їх отримати?

.З Коригування описання робіт. Описання роботи розглянуто в пункті 12.1.3.2. Модифікації до одного або більше описань роботи можуть визначатися в процесі планування клопотань.

Клопотання

Процес клопотання включає отримання тендерної документації і тендерних пропозицій від потенційних покупців про те, як можуть бути задоволені проектні потреби. Більша частина витрат у цьому процесі лягає на потенційних продавців і тому ці витрати не входять у витрати по проекту.

12.3.1 Вхідні дані для процесу клопотання

. 1 Документи по закупівлі. Див. пункт 12.2.3.1.

.2 Кваліфікаційні списки продавців. Деякі організації мають списки або файли з інформацією про потенційних продавців. В основному ці списки містять інформацію про досвід та інші характеристики потенційних продавців.

Якщо такі списки відсутні, команда проекту повинна підготувати їх своїми силами. Загальна інформація широко доступна через каталоги бібліотек, відповідні місцеві асоціації, торгові каталоги і т.ін. Детальна інформація про конкретні джерела може зажадати значніших зусиль, таких, наприклад, як відвідування місць роботи продавців або контакти з попередніми споживачами.

Закупівельні документи можуть бути надіслані деяким або всім потенційним продавцям.