Розробка календарного плану

План

План

6.1. Загальна характеристика управління змістом проекту

6.2. Ініціалізація

6.3. Планування змісту

6.4. Визначення змісту

6.5. Перевірка змісту.

6.6. Контроль за змінами змісту.

6.1. Загальна характеристика управління змістом проекту

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

1. Ініціалізація - рішення організації про те, щоб розпочати чергову фазу проекту.

2. Планування змісту - розробка (письмово) документа про зміст проекту як основи для майбутніх проектних рішень.

3. Визначення змісту - поділ основного компоненту проекту на дрібніші, більш керовані компоненти.

4. Перевірка змісту - формалізація приймання змісту проекту.

5. Контроль за змінами змісту - контроль змін у змісті проекту.

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

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

Термін «зміст» відносно проекту може означати:

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

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

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

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

Завершення розробки змісту продукту встановлюють порівнянням показників виконання змісту проекту з планом. Обидва типи управління змістом мають переплітатися для гарантування того, що завершення проекту приведе до появи конкретного продукту.

6.2. Ініціалізація

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

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

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

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

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

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

6.2.1. Вхідні дані для ініціалізації

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

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

2. Стратегічний план. Усі проекти мають відповідати стратегічним цілям організації - стратегічний план виконавчої організації повинен розглядатися як один з чинників при виборі рішень по проекту.

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

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

6.2.2. Методи та засоби для ініціалізації

1. Методи вибору проекту. Методи вибору проекту звичайно попадають в одну з двох широких категорій:

• Методи вимірювання прибутку - порівняльні підходи, виграшні моделі, вклад прибутку або економічні моделі.

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

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

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

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

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

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

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

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

6.2.3. Результати ініціалізації

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

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

• Опис продукту.

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

2. Призначення менеджера проекту. Менеджер проекту має бути призначений якомога раніше. Зокрема, перед початком виконання плану проекту, а найкраще перед тим, як буде завершене планування проекту.

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

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

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

6.3. Планування змісту

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

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

6.3.1. Вхідні дані для планування змісту

1. Опися продукту.

2 Статут проекту.

3. Обмеження.

4. Допущення.

6.3.2. Методи та засоби для планування змісту

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

інжиніринг цінності, аналіз цінності, функціональний аналіз і розгортку функцій якості.

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

3. Визначення альтернатив. Цей термін застосовується для будь-якого методу, що використовується при виробленні різних підходів до проекту. Існує безліч різноманітних загальних методів управління, що часто використовуються тут, найбільш відомими з них є мозковий штурм і «бічне» мислення.

4.Висновок експерта.

6.3.3. Результати планування змісту

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

• Обгрунтування проекту - описання комерційної необхідності виконання проекту. Обгрунтування проекту є основою для оцінки майбутнього виконання. Продукт проекту - коротке підсумкове описання продукту.

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

• Цілі проекту - кількісні критерії, які мають бути задоволені, для того щоб проект вважався успішно завершеним. Цілі проекту повинні як мінімум включати кількісні вимоги до вартості, календарного плану й якості проекту. Цілі проекту повинні мати параметр (наприклад, вартість), одиницю вимірювання (наприклад, долари США), а також абсолютні чи відносні значення (наприклад, менше, ніж 1.5 мільйона). Цілі, які не можна оцінити кількісно (наприклад, «задоволення споживача») містять більш високий ризик.

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

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

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

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

6.4. Визначення змісту

Визначення змісту - це поділ основних робіт проекту (визначених при описанні змісту) на дрібніші, більш керовані компоненти з метою:

• удосконалення точності оцінок вартості, часу та ресурсів;

• визначення основи для контролю виконання;

• удосконалення розподілення відповідальності.

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

6.4.1. Вхідні дані для визначення змісту

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

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

3. Допущення.

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

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

6.4.2 Методи та засоби визначення змісту

1. Шаблони ієрархічної структури робіт. Ієрархічна структура робіт (WBS) з попереднього проекту часто може використовуватися як шаблон для нового проекту.

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

Багато які прикладні сфери мають стандартні або частково стандартні WBS-структури, що можуть використовуватися як шаблони. Наприклад, Міністерство оборони США визначило стандартні WBS-структури по міністерству. Частина одного з таких шаблонів показана на рис.19.

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

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

• Фази життєвого циклу проекту можуть використовуватися на першому рівні декомпозиції, а роботи проекту - на другому, як це показано на рис.20.

• Принцип упорядкування по кожній гілці WBS може бути різним, як це показано на рис.21.

2. Прийняття рішення про те, чи можуть бути розроблені адекватні оцінки вартості і тривалості з даного рівня деталізації по кожному елементу. Значення поняття «адекватний» може змінюватися в ході виконання проекту - декомпозиція робіт, яку отримують на пізніх етапах проекту, спочатку може бути неможливою. По кожному елементу перейдіть до кроку 4, якщо адекватна деталізація вже досягнута, і до кроку 3 у противному разі - це означатиме, що різні елементи можуть мати різну міру декомпозиції.

3. Визначення складових елементів робіт. Складові елементи мають бути описані як матеріальні результати, що перевіряються, для удосконалення оцінки виконання. Так само, як і основні, складові елементи мають бути визначені по відношенню до фактичного завершення роботи над проектом. Матеріальні результати, що перевіряються, можуть включати як продукти, так і послуги (наприклад, складання звіту про стан також може бути описано як тижневі звіти про стан; для виробничого елемента складові елементи можуть включати кілька індивідуальних компонентів, а також заключне складання). Повторіть крок 2 для кожного складового елемента.

4. Перевірка правильності декомпозиції:

• Чи є низькорівневі елементи необхідними І достатніми для завершення декомпозиції по даному елементу? Якщо ні, то складові елементи мають бути змінені (додані, видалені або перевизначені).

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

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

Рис.19 Приклад ієрархічної структури робіт для проектів Міністерства оборони США

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

Рис. 20 Зразок ієрархічної структури робіт, організованої за фазами

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

6.4.3. Результати визначення змісту

1. Ієрархічна структура робіт. Ієрархічна структура робіт - це групування елементів проекту, орієнтоване на роботи, яке упорядковує і визначає підсумковий зміст проекту: робота, що не має відношення до WBS, стоїть за межами змісту проекту. Подібно до описання змісту, WBS часто використовується для вироблення або підтвердження загального розуміння змісту проекту. Кожний нижній рівень являє собою все більш детальне описання елементів проекту. У даній темі описується найбільш загальний підхід до розробки WBS. Останній звичайно подається у вигляді графіка, як це показано на рис.19-21. Проте, WBS не слід плутати з методом подання проекту - зображення неструктурованого переліку робіт у графічній формі не є WBS.

Кожному елементу WBS звичайно призначається унікальний ідентифікатор; такі ідентифікатори часто мають загальну назву - коди обліку. Елементи на найнижчому рівні WBS часто називають пакетами робіт. Останні можуть бути надалі поділені.

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

Рис.21 Зразок ієрархічної структури робіт для заводу з водної переробки відходів

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

WBS не слід плутати з іншими видами «декомпозиційних» структур, що звичайно використовуються в деяких прикладних сферах і використовуються для подання проектної інформації:

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

• Організаційна структура поділу (ОВS), що використовується для відображення того, які елементи робіт призначаються відповідним організаційним одиницям.

• Ресурсна структура поділу (RBS) є модифікацією ОВS і найчастіше використовується, коли елементи робіт призначаються окремим особам. Відомість матеріалів (ВОМ), що являє собою ієрархічне подання фізичного складання, складання окремих частин і компонентів, необхідних для отримання промислового продукту.

• Структура поділу проекту (РВS) загалом є тим самим, що і правильно розроблена WBS. Термін «РВS» широко використовується в тих прикладних сферах, в яких термін «WBS» неправильно використовується замість «ВОМ».

6.5. Перевірка змісту

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

6.5.1. Вхідні дані для перевірки змісту

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

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

6.5.2. Методи та засоби перевірки змісту

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

6.5.3. Результати перевірки змісту

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

6.6. Контроль за змінами змісту

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

6.6.1. Вхідні дані для контролю за змінами змісту

1. Ієрархічна структура робіт WBS. Вона визначає основу змісту проекту.

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

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

• Зовнішньої події (наприклад, зміна урядових норм).

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

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

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

4. План управління змістом проекту.

6.6.2. Методи та засоби контролю за змінами змісту

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

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

3. Додаткове планування. Мало проектів виконується відповідно до плану. Потенціальні зміни змісту можуть зажадати внесення змін у WBS -структуру або аналізу альтернативних підходів.

6.6.3.Результати контролю за змінами змісту

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

Зміна змісту проекту є зворотним зв'язком у процесі планування, поновлення технічної та планової документації та затвердження змін у керівництва.

2. Коригуючі дії. Коригування дій дозволяє спланувати очікуване майбутнє виконання проекту та порівняти його з планом.

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

Тема 7. УПРАВЛІННЯ ЧАСОМ У ПРОЕКТІ

7.1. Загальна характеристика управління часом у проекті.

7.2. Визначення діяльності

7.3. Задання послідовності робіт.

7.4. Оцінка тривалості робіт.

Дата добавления: 2014-01-07