Основи проектного менеджменту 4 страница
.3 Контроль за виконанням. Технологія оцінки виконання, така як освоєний обсяг (див. пункт 10.3.2.4), допомагає оцінити, чи вимагають відхилення від плану дії з коригування.
.4 Додаткове планування. Проекти рідко протікають у точній відповідності плану. Потенціальні зміни можуть зажадати нових або скоригованих кошторисів, зміни послідовності робіт, аналізу альтернатив реакції на ризик або інших змін у плані проекту.
.5 Інформаційна система управління проектами. Див. пункт 4.1.2.3.
4.3.3 Результати загального контролю за змінами
.1 Коригування плану проекту. Коригування плану проекту - це будь-які зміни, що вносяться до змісту плану проекту або в додаткові матеріали (див. відповідно пункти 4.1.3.1 та 4.1.3.2). У разі необхідності мають бути сповіщені відповідні зацікавлені особи проекту.
.2 Коригуючі ДІЇ. Див. пункт 4.2.1.4.
.3 Засвоєні уроки. Випадки відхилень, причини вибору дій з коригування та інші типи уроків, засвоєних у результаті загального контролю за змінами, мають бути задокументовані в такий спосіб, щоб стати частиною бази даних як по цьому, так і по всіх інших проектах, що виконуються в цій організації.
5.Управління змістом
Проекту
Управління змістом (внутрішнім середовищем) проекту включає
процеси, необхідні для забезпечення того, щоб проект містив саме
ті роботи, які необхідні для успішного завершення його [1]. В
основному управління змістом проекту зосереджується на
визначенні та контролюванні того, що включати, а що не включати
в проект. На малюнку 5-1представлений огляд головних процесів
управління змістом проекту: *
5.1 Ініціалізація- рішення організації про те, щоб розпочати
чергову фазу проекту.
5.2 Планування змісту- розробка (письмово) документа про
зміст проекту як основи для майбутніх проектних рішень.
5.3 Визначення змісту- поділ основного компоненту проекту
на дрібніші, більш керовані компоненти.
5.4 Перевірка змісту- формалізація приймання змісту проекту.
5.5 Контроль за змінами змісту- контроль змін у змісті
проекту.
Зазначені процеси взаємодіють як між собою, так і з процесами нших галузей застосування знань з проектного менеджменту. Кожний процес може включати зусилля одного чи кількох індивідуумів або груп індивідуумів, спрямовані на задоволення потреб проекту, і виконується, як правило, по одному разу на кожній фазі проекту.
Хоч тут процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб, що докладно тут не описується. Детально обговоренні взаємодії між процесами в розділі 3.
Термін «зміст» відносно проекту може означати:
• Зміст продукту - властивості та функції, що включаються в
продукт або послугу.
• Зміст проекту - роботу, яка має бути виконана для отримання
продукту з певними властивостями та функціями.
У даному розділі розглядаються процеси, методи та засоби, що використовуються для інтеграції процесів управління змістом проектів. Процеси, методи та засоби, що використовуються для управління змістом продукту, сильно варіюються залежно від прикладної сфери і звичайно визначаються як частина життєвого циклу проекту (життєвий цикл проекту описаний в підрозділі 2.1).
До складу проекту входить один продукт, який може включати допоміжні елементи, кожний зі своїм окремим, хоч і взаємозалежним змістом. Наприклад, нова телефонна система звичайно повинна мати чотири допоміжних елементи - апаратне та програмне забезпечення, навчання, реалізацію.
Завершення розробки змісту продукту встановлюють порівнянням показників виконання змісту проекту з планом. Обидва типи управління змістом мають переплітатися для гарантування того, що завершення проекту приведе до появи конкретного продукту.
|
5.1 Ініціалізація
Ініціалізація проекту - це процес формального визнання того, що новий проект існує, або того, що існуючий проект повинен продовжуватися до своєї наступної фази (див. підрозділ 2.1, де детально обговорені питання про фази проекту). Цей формальний запуск проекту зв'язує проект з поточною роботою організації, що виконує проект. У деяких організаціях проект формально не запускається доти, поки не завершена стадія підготовки його техніко-економічного обґрунтування, підготовчий план або деякі інші еквівалентні форми аналізу, що були запущені окремо. Деякі типи проектів, особливо проекти з внутрішнього обслуговування та розробки нового продукту, спочатку запускаються неформально і виконується тільки деякий обмежений обсяг роботи, щоб забезпечити твердження, необхідне для формального запуску. Проекти затверджуються на основі одного чи більше з таких стимулів.
• Ринковий попит (наприклад, нафтова компанія запускає проект створення
нового очисного заводу у відповідь на хронічну нестачу бензину).
• Комерційна потреба (наприклад, навчальна компанія запускає проект
створення нового курсу для збільшення свого прибутку).
• Споживчий запит (наприклад, електростанція запускає проект створення
нової підстанції для обслуговування нового промислового парку).
• Технологічне просування (наприклад, фірма, що спеціалізується на
електроніці, запускає новий проект з розробки відеогри після розробки
нової моделі відеомагнітофона).
• Юридичні вимоги (наприклад, фірма, що займається малярними роботами,
запускає новий проект розробки керівництва по роботі з токсичними
матеріалами).
Ці стимули можуть називатися також проблемами, можливостями або комерційними вимогами. Центральною ідеєю всіх цих понять є те, що загалом служби менеджменту мають приймати рішення по реакції.
5.1.1 Вхідні дані для ініціалізації
.1 Описання продукту. Описання продукту - це документування характеристики продукту чи послуги, яку має надати проект для того, щоб вважатися виконаним. Загалом описання продукту має бути менш детальним на ранніх фазах і більш детальним на пізніх фазах по мірі того як характеристики продукту поступово уточнюються. Описання продукту документує також зв'язок між продуктом чи послугою, що створюється, і комерційною потребою в цьому, або іншими стимулами, які спричинюють запуск проекту (див. перелік вище). Форма і зміст опису продукту змінюватимуться, тому для підтримки пізнішого планування проекту цей опис завжди має бути достатньо детальним.
Багато які проекти включають одну організацію (продавця), що виконує роботу за контрактом з іншою організацією (покупцем). У таких умовах продукт описує на
початковій стадії покупець. Якщо роботою покупця є сам проект, то цей опис називається описанням роботи ( див. пункт 12.1.3.2 ).
.2 Стратегічний план. Усі проекти мають відповідати стратегічним цілям організації - стратегічний план виконавчої організації повинен розглядатися як один з чинників при виборі рішень по проекту.
.3 Критерії вибору проекту. Критерії вибору проекту звичайно задаються в термінах виконання проекту і можуть містити повний набір можливих чинників, які впливають на управління проектами (повернення грошових коштів, ринкова частка, громадська думка і т.ін.).
.4 Інформація 3 архіву. Інформація з архіву про результати вибору рішень в попередніх проектах і виконання їх повинні розглядатися в повному обсязі. Коли запуск проекту включає затвердження для початку наступної фази проекту, інформація про результати на попередніх фазах часто є дуже важливою.
5.1.2 Методи та засоби для ініціалізації
. 1 Методи вибору проекту. Методи вибору проекту звичайно попадають в одну з двох широких категорій [2]:
• Методи вимірювання прибутку - порівняльні підходи, виграшні моделі,
вклад прибутку або економічні моделі.
• Методи оптимізації з обмеженнями - математичні моделі з використанням
лінійного, нелінійного, динамічного, цілочисельного й багато-
критеріального програмування.
Ці методи часто називаються моделями рішення. Моделі рішення включають загальні (дерева рішень, форсований вибір та ін.) та спеціалізовані (процес аналітичної ієрархії, аналіз логічної основи та ін.) методи.
Застосування складних критеріїв вибору проекту у витонченій моделі часто розглядається як окрема фаза проекту.
.2 Висновок експерта. Висновок експерта необхідний для оцінки вхідних даних цього процесу. Така експертиза може бути надана будь-якою групою чи окремою особою із спеціальними знаннями або підготовкою і може бути доступна з багатьох джерел, включаючи:
• інші підрозділи виконавчої організації;
• консультантів;
• професійні та технічні асоціації;
• промислові групи.
5.1.3 Результати ініціалізації
. 1 Статут проекту. Статут проекту - це документ, який формально підтверджує існування проекту. Він повинен включати (безпосередньо або з допомогою посилань на інші документи):
• Комерційну доцільність виконання проекту.
• Описання продукту (див. пункт 5.1.1.1).
Статут проекту складається менеджером, який знаходиться поза проектом відповідно певних потреб проекту. Він надає менеджеру проекту повноваження для використання ресурсів організації в роботах проекту. Коли проект виконується згідно з контрактом, то підписаний контракт загалом служить обгрунтуванням проекту для продавця.
■
.2 Призначення менеджера проекту. Менеджер проекту має бути призначений якомога раніше. Зокрема, перед початком виконання плану проекту (описаного в підрозділі 4.2), а найкраще перед тим, як буде завершене планування проекту (процеси планування проекту описані в пункті 3.3.2).
.3 Обмеження. Обмеження - це чинники, що обмежують варіанти добору команди менеджерів проекту. Наприклад, наперед заданий бюджет є обмеженням, яке з високою ймовірністю підсилює вимоги до вибору команди відносно змісту, персоналу і календарного плану проекту.
Коли проект виконується відповідно до контракту, умови останнього в загальному випадку набувають чинності обмежень.
. 4 Допущення. Допущення - це чинники, які для цілей планування розглядаються як істинні, реальні або визначені. Наприклад, якщо дата початку, яку має встановити керівник, ще не визначена, команда може призначити її сама. Звичайно, такі й будь-які інші допущення привносять певну міру ризику. Допущення можуть бути визначені на цьому етапі, або вони можуть бути результатом ідентифікації ризику (описаної в підрозділі 11.1).
5.2 Планування змісту
Планування змісту - це процес розробки (письмово) документа про зміст як основи майбутніх проектних рішень, включаючи, зокрема, критерії, що використовуються для визначення того, чи завершився проект або фаза успішно. Письмове описання змісту необхідне як для проектів, так і для підпроектів. Наприклад, інженерна фірма, яка взяла підряд на проектування заводу з переробки нафти, повинна мати описання змісту, де визначені межі роботи з підпроекту розробки. Описання змісту формує основу угоди між командою проекту і споживачем проекту з метою визначення як задач проекту, так і основних робіт проекту.
Якщо всі елементи описання змісту вже доступні (наприклад, запит пропозиції може визначити основні роботи, в обгрунтуванні проекту, які можуть скласти завдання проекту), то цей процес може включати дещо більше, ніж просто створення такого письмового документа.
5.2.1 Вхідні дані для планування змісту
. І Описання продукту. Див. пункт 5.1.1.1. .2 Статут проекту. Див. пункт 5.1.3.1. .З Обмеження. Див. пункт 5.1.3.3. А Допущення. Див. пункт 5.1.3.4.
5.2.2 Методи та засоби для планування змісту
.1 Аналіз продукту. Аналіз продукту передбачає вироблення кращого розуміння продукту проекту. Він охоплює такі методи, як системний інжиніринг,
інжиніринг цінності, аналіз цінності, функціональний аналіз і розгортку функцій якості.
.2 Аналіз прибутків/витрат. Аналіз прибутків/витрат включає оцінку матеріальних і нематеріальних витрат і прибутків по різних варіантах проекту, а потім використовує такі фінансові показники, як повернення інвестицій або період відшкодування для оцінки відносної вигоди певних альтернатив.
.3 Визначення альтернатив. Цей термін застосовується для будь-якого методу, що використовується при виробленні різних підходів до проекту. Існує безліч різноманітних загальних методів управління, що часто використовуються тут, найбільш відомими з них є мозковий штурм і «бічне» мислення.
А ВИСНОВОК експерта. Див. пункт 5.1.2.2.
5.2.3 Результати планування змісту
.1 Описання ЗМІСТУ проекту. Описання змісту проекту являє собою документальну основу для прийняття проектних рішень і підтвердження або вироблення загального розуміння відносно змісту проекту між зацікавленими особами. По мірі виконання проекту, документ про зміст може бути скоригований або вдосконалений для відображення змін у змісті проекту. Описання змісту має включати (безпосередньо чи з допомогою посилань на інші документи):
• Обгрунтування проекту - описання комерційної необхідності виконання
проекту. Обгрунтування проекту є основою для оцінки майбутнього
виконання. Продукт проекту - коротке підсумкове описання продукту (див.
пункт 5.1.1.1).
• Результат проекту - перелік підсумкових підпродуктів по рівнях проекту,
чиє повне і адекватне виконання означатиме завершення проекту.
Наприклад, основним результатом в проекті з розробки програмного
забезпечення можуть бути діюча прикладна програма, керівництво
користувача та інтерактивний навчальний посібник. Мають бути визначені
вилучення, якщо вони є, і все, що явно не включається, за умовчанням має
бути вилучене.
• Цілі проекту - кількісні критерії, які мають бути задоволені, для того щоб
проект вважався успішно завершеним. Цілі проекту повинні як мінімум
включати кількісні вимоги до вартості, календарного плану й якості
проекту. Цілі проекту повинні мати параметр (наприклад, вартість),
одиницю вимірювання (наприклад, долари США), а також абсолютні чи
відносні значення (наприклад, менше, ніж 1.5 мільйона). Цілі, які не можна
оцінити кількісно (наприклад, «задоволення споживача») містять більш
високий ризик.
У деяких прикладних сферах роботи проекту визначаються цілями проекту, а цілі проекту - критичними чинниками успіху.
.2 ДОПОМІЖНІ деталі. Допоміжні деталі для описання змісту мають бути адекватно задокументовані і впорядковані для удосконалення їх використання в інших процесах управління проектами. Допоміжні деталі завжди повинні включати документування всіх визначуваних допущень і обмежень. Кількість допоміжних деталей варіюється залежно від прикладної сфери.
.З План управління ЗМІСТОМ проекту - це документ, де описується, як управляти змістом проекту і як зміни змісту відбиватимуться в проекті. Він також повинен включати оцінку очікуваної стабільності змісту проекту (наприклад, того, наскільки ймовірне його змінювання, як часто і в якій мірі він може змінюватися). План управління змістом повинен також мати чітке описання того, як визначатиметься і класифікуватиметься зміна змісту (це особливо складно і тому безумовно важливо робити тоді, коли властивості продукту тільки уточнюються).
План управління змістом може бути формальний або неформальний, надто детальний або широко окреслений, заснований на потребах проекту. Він є допоміжним елементом загального плану проекту (описаного в пункті 4.1.3.1).
5.3 Визначення змісту
Визначення змісту - це поділ основних робіт проекту (визначених при описанні змісту) на дрібніші, більш керовані компоненти з метою:
• удосконалення точності оцінок вартості, часу та ресурсів;
• визначення основи для контролю виконання;
• удосконалення розподілення відповідальності.
Правильне визначення змісту є найбільш важливим для успішного завершення проекту. «Якщо визначення змісту незадовільне, то заключна вартість проекту скоріше за все буде вищою, оскільки відбудуться неминучі зміни проекту, які зіб'ють його ритм, спричинять переробки, подовжать час виконання, знизять продуктивність і трудову дисципліну робочої сили» [3].
5.3.1 Вхідні дані для визначення змісту
. 1 Описання змісту проекту. Див. пункт 5.2.3.1.
.2 Обмеження. Див. пункт 5.1.3.3. Коли проект виконується відповідно до контракту, умови останнього в загальному випадку набувають чинності обмежень.
.3 Допущення. Див. пункт 5.1.3.4.
А Результати ІНШИХ процесів планування. Результати процесів в інших прикладних сферах мають бути проаналізовані з метою з'ясування їх можливого впливу на визначення змісту проекту.
.5 Інформація 3 архіву. Інформація з архіву про попередні проекти також має враховуватися при визначенні змісту. Інформація про похибки та пропуски в попередніх проектах буде особливо корисною.
5.3.2 Методи та засоби визначеннязмісту
.1 Шаблони Ієрархічної структури робіт. Ієрархічна структура робіт (WBS, описана в пункті 5.3.3.1) з попереднього проекту часто може використовуватися як шаблон для нового проекту.
Хоч кожний проект є унікальним, але WBS-структури часто можуть використовуватися повторно, оскільки більшість проектів деякою мірою схожі. Наприклад, більшість проектів в одній організації матимуть подібні або дуже схожі життєві цикли, й отже, матимуть подібні або дуже схожі роботи по кожній фазі.
Багато які прикладні сфери мають стандартні або частково стандартні WBS-структури, що можуть використовуватися як шаблони. Наприклад, Міністерство оборони США визначило стандартні WBS-структури по міністерству. Частина одного з таких шаблонів показана на малюнку 5—2.
.2 ДЄКОМПОЗИЦІЯ. Декомпозиція включає поділ основних робіт проекту на дрібніші, більш керовані компоненти, поки роботи не будуть визначені достатньо детально для підтримки майбутніх робіт проекту (планування, виконання, контроль, закриття). Декомпозиція включає такі основні етапи:
(1) Визначення основних елементів проекту. Загалом основними елементами
будуть роботи проекту і управління проектом. Проте, основні елементи завжди
мають бути визначені залежно від фактичної процедури управління проектом:
• Фази життєвого циклу проекту можуть використовуватися на першому
рівні декомпозиції, а роботи проекту - на другому, як це показано на
малюнку 5—3.
• Принцип упорядкування по кожній гілці WBS може бути різним, як це
показано на малюнку 5—4.
(2)Прийняття рішення про те, чи можуть бути розроблені адекватні оцінки
вартості і тривалості з даного рівня деталізації по кожному елементу. Значення
поняття «адекватний» може змінюватися в ході виконання проекту -
декомпозиція робіт, яку отримують на пізніх етапах проекту, спочатку може
бути неможливою. По кожному елементу перейдіть до кроку 4, якщо адекватна
деталізація вже досягнута, і до кроку 3 у противному разі - це означатиме, що
різні елементи можуть мати різну міру декомпозиції.
(3) Визначення складових елементів робіт. Складові елементи мають бути
описані як матеріальні результати, що перевіряються, для удосконалення оцінки
виконання. Так само, як і основні, складові елементи мають бути визначені по
відношенню до фактичного завершення роботи над проектом. Матеріальні
результати, що перевіряються, можуть включати як продукти, так і послуги
(наприклад, складання звіту про стан також може бути описано як тижневі
звіти про стан; для виробничого елемента складові елементи можуть включати
кілька індивідуальних компонентів, а також заключне складання). Повторіть крок
2 для кожного складового елемента.
(4) Перевірка правильності декомпозиції:
• Чи є низькорівневі елементи необхідними і достатніми для завершення
декомпозиції по даному елементу? Якщо ні, то складові елементи мають
бути змінелі (додані, видалені або перевизначені).
• Чи чітко й повно визначений кожний елемент? Якщо ні, то описання мають
бути скориговані чи розширені.
• Чи може кожний елемент бути відповідним чином спланований? Чи може
для нього бути виділений бюджет? Чи може він бути приставлений до певної
організаційної одиниці (наприклад, до підрозділу, команди або окремої
особи), яка відповідатиме за успішне його завершення? Якщо ні, то
необхідне коригування для надання адекватного контролю за управлінням.
5.3.3 Результати визначення змісту
.1 Ієрархічна структураробіт. Ієрархічна структура робіт - це групування елементів проекту, орієнтоване на роботи, яке упорядковує і визначає підсумковий зміст проекту: робота, що не має відношення до WBS, стоїть за межами змісту проекту. Подібно до описання змісту, WBS часто використовується для вироблення або підтвердження загального розуміння змісту проекту. Кожний нижній рівень являє собою все більш детальне описання елементів проекту. У пункті 5.3.2.2 описується найбільш загальний підхід до розробки WBS. Останній звичайно подається у вигляді графіка, як це показано на малюнках 5—2- 5—4.Проте, WBS не слід плутати з методом подання проекту - зображення неструктурованого переліку робіт у графічній формі не є WBS.
Кожному елементу WBS звичайно призначається унікальний ідентифікатор; такі ідентифікатори часто мають загальну назву - коди обліку. Елементи на найнижчому рівні WBS часто називають пакетами робіт. Останні можуть бути надалі поділені, як це описано в підрозділі 6.1.
Описання елементів роботи часто називаються словником WBS. Словник WBS звичайно включає описання пакетів робіт, а також іншу планову інформацію, таку як планові дати, бюджетні вартості, призначення персоналу.
WBS не слід плутати з іншими видами «декомпозиційних» структур, що звичайно використовуються в деяких прикладних сферах і використовуються для подання проектної інформації:
• Контрактні WBS (CWBS), що використовуються для визначення рівня звітності, які продавець надає покупцеві. CWBS, як правило, включають менше деталей, ніж WBS, і використовуються продавцем для управління своєю роботою.
• Організаційна структура поділу (OBS), що використовується для
відображення того, які елементи робіт призначаються відповідним
організаційним одиницям.
• Ресурсна структура поділу (RBS) є модифікацією OBS і найчастіше
використовується, коли елементи робіт призначаються окремим
особам.
• Відомість матеріалів (ВОМ), що являє собою ієрархічне подання
фізичного складання, складання окремих частин і компонентів,
необхідних для отримання промислового продукту.
• Структура поділу проекту (PBS) загалом є тим самим, що і правильно
розроблена WBS. Термін «PBS» широко використовується в тих
прикладних сферах, в яких термін «WBS» неправильно
використовується замість «ВОМ».
5.4 Перевірка змісту
Перевірка змісту - це процес формалізації приймання змісту проекту зацікавленими особами (спонсором, клієнтом, споживачем і т.д.). Вона вимагає аналізу продуктів і результатів роботи й необхідна для того, щоб переконатися, що все виконане правильно і задовільно. Якщо проект рано завершився, то в процесі перевірки змісту мають бути описані та задокументовані рівень і ступінь завершення. Перевірка змісту відрізняється від контролю якості (див. підрозділ 8.3) тим, що вона в основному зосереджується на прийманні результатів роботи, тоді як процес контролю якості в основному зосереджується на правильності результатів роботи.
5.4.1 Вхідні дані для перевірки змісту
.1 Результати роботи. Результати роботи - це результати виконання плану проекту (що обговорюється в підрозділі 4.2), тобто які роботи здійснені повністю, які частково, які грошові кошти витрачені або заощаджені і т.ін.
.2 Документація ПО продукту. Документи, розроблені з метою описання продуктів проекту, мають бути доступні для аналізу. Терміни, що використовуються для описання в документації (планах, специфікаціях,
технічній документації, кресленнях і т.ін.) змінюються залежно від прикладної сфери.
5.4.2 Методи та засоби перевірки змісту
.1 Інспекція. Інспекція включає роботи, такі як вимірювання, перевірку та тестування, здійснювані для визначення того, чи задовольняють результати проекту вимогам, що ставляться до нього. Інспекції в деяких прикладних сферах ще називають переглядами продукту, аудитами або критичним аналізом. Кожний з цих термінів має своє вужче або більш загальне значення.
5.4.3 Результати перевірки змісту
.1 Формальне приймання. Має бути підготовлена й поширена
документація, за якою клієнт або інвестор прийматимепродукт проекту чи проектної фази. Таке приймання може бути й умовним, особливо наприкінці фази.
5.5 Контроль за змінами змісту
Контроль за змінами змісту зв'язаний з (а) впливом чинників, які спричинюють зміни змісту, для того щоб гарантувати, що ці зміни будуть позитивними, (Ь) визначенням того, що сталася зміна змісту, і (с) управлінням фактичними змінами, коли вони сталися. Контроль за змінами змісту має бути ретельно інтегрований в інші процеси контролю (контроль часу, контроль вартості, контроль якості й інші типи контролю, як це обговорюється в підрозділі 4.3).
5.5.1 Вхідні дані для контролю за змінами змісту
.1 Ієрархічна структура робіт. WBS описана в пункті 5.3.3.1. Вона визначає основу змісту проекту.
.2 Звіти про виконання. Звіти про виконання, що обговорюються в пункті 10.3.3.1, несуть інформацію про виконання проекту, які проміжні продукти проекту були завершені, а які ні. Звіти про виконання також можуть підказати команді управління проектом «вузькі місця» проекту, що можуть спричинити проблеми в майбутньому.
. З Запити на ЗМІНИ. Запити на зміни можуть бути подані у багатьох формах -усній чи письмовій, прямій чи непрямій, такі, що викликаються зовні чи зсередини, обов'язкові чи необов'язкові. Зміни можуть зажадати розширення змісту чи його скорочення. Більшість запитів на зміни є результатом:
• Зовнішньої події (наприклад, зміна урядових норм).
• Похибки або пропуску у визначенні змісту продукту (наприклад,
похибка, зв'язана з тим, що необхідна характеристика не була
включена у проект телекомунікаційної системи).
• Похибки або пропуску у визначенні змісту проекту (наприклад,
використання відомості матеріалів замість ієрархічної структури
робіт).
• Зміни значення величини (наприклад, у проекті з охорони
навколишнього середовища можна дещо зменшити вартість,
використовуючи технології, які були недоступні на той час, коли
складали зміст проекту).
А План управління змістом проекту. Див. пункт 5.2.3.3.
І
5.5.2 Методи та засоби контролю за змінами змісту
.1 Система КОНТРОЛЮ за змінами ЗМІСТУ проекту. Система контролю за змінами змісту проекту задає процедури, за якими зміст проекту може бути змінений. Вона включає роботу з документами, системи відстежування й рівні повноважень, необхідні для затвердження змін. Система контролю за змінами змісту має бути вбудована в загальну систему контролю за змінами, описану в підрозділі 4.3 і, зокрема, в будь-яку систему або системи для контролю змісту продукту. Коли продукт виконаний згідно з контрактом, система контролю за змінами змісту також має бути сумісною з усіма відповідними контрактними вимогами.
.2 Контроль за виконанням. Технологія контролю за виконанням, що описана в пункті 10.3.2, допомагає оцінити величини будь-яких виникаючих відхилень. Важливим моментом контролю за змінами змісту є визначення того, що спричинило це відхилення, а також рішення того, чи вимагає дане відхилення певного коригування.
.З Додаткове планування. Мало проектів виконується відповідно до плану. Потенціальні зміни змісту можуть зажадати внесення змін у WBS-структуру або аналізу альтернативних підходів.