1.3. Управління часом у проекті

Ситуація 1.25. Оцінка тривалості робіт проекту

Одні роботи легше оцінити, ніж інші.

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

Зміна ймовірнісних оцінок вимагає від менеджера проекту і його команди розв”язання наступних задач:

• визначення оптимістичної оцінки – яка пропонується та підкреслює, що все йде за планом;

• визначення найбільш ймовірної оцінки - яку більшість людей рахують реалістичною;

• визначення песимістичної оцінки - яку пропонує гірший випадок;

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

Завдання: Проаналізувати процес оцінки тривалості робіт проекту. Відобразити етапи та схему оцінки тривалості робіт проекту. Виконати аналіз сильних та слабких сторін запропонованої схеми оцінки тривалості робіт проекту. Навести приклади.

Ситуація 1.26. Коректування переліку робіт проекту

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

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

Коректування списку робіт вимагає від менеджера проекту і його команди розв”язання наступних робіт:

• визначення додатків, змін або видалень в початковий список робіт;

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

Завдання: Проаналізувати процес коректування списку робіт проекту. Відобразити етапи та схему коректування списку робіт проекту. Навести приклади.

Теми індивідуальних завдань до підрозділу

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

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

1.4. Управління вартістю проекту

Ситуація 1.27. Оцінка відповідних вартісних архівних даних

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

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

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

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

Оцінка вартісних даних з попередніх проектів вимагає від менеджера проекту і його команди розв”язання п'яти наступних задач:

• визначення аналогічних попередніх проектів і отримання вартісних даних;

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

• нормування вартісних даних по минулих проектах для проведення допустимих порівнянь;

• порівняння вартісних оцінок для поточного проекту і змінених вартісних даних з аналогічних минулих проектів;

• зміна поточних вартісних оцінок.

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

Ситуація 1.28. Розрахунок вартості проекту

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

Наприклад: Вартість використання людських ресурсів =

(середня норма за місяць/ кількість персоналу в місяць) * (# місяців роботи персоналу).

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

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

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

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

• отримання відповідних нормативів по всіх основних категоріях ресурсів (якщо необхідно, то і по підкатегоріям);

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

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

Завдання: Проаналізувати методи оцінки вартості проекту. Відобразити етапи та схему розрахунку вартості проекту. Виконати аналіз сильних та слабких сторін запропонованої схеми розрахунку вартісних даних проекту.Навести приклади.

Ситуація 1.29. Визначення коефіцієнтів вартостей проекту

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

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

Ці проектні коефіцієнти повинні потім бути застосовані, щоб застосовувати нові вартісні оцінки від початку дії цих коефіцієнтів до кінця проекту.

Визначення і облік коефіцієнтів проектних вартостей вимагає від менеджера проекту і його команди розв”язання двох наступних задач:

• визначення зростання/ падіння очікуваних норм по різних ресурсних категоріях;

• застосування цих змін до вартісних оцінок за період часу від очікуваної зміни до кінця проекту.

Завдання: Проаналізувати коефіцієнти вартісної оцінки проекту. Відобразити етапи та схему оцінки коефіцієнтів вартісних даних проекту. Навести приклади.

Ситуація 1.30. Документування допоміжних деталей по вартості проекту

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

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

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

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

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

• визначення будь-яких інших допущень за оцінкою;

• включення розрахунків, які були використані в процесі оцінки;

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

Завдання: Проаналізувати систему документування вартісних оцінок проекту. Відобразити етапи та схему документування оцінки вартісних даних проекту. Навести приклади.

Ситуація 1.31. Створення плану управління вартістю проекту

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

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

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

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

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

Цей етап безпосередньо пов'язаний із двома іншими процесами:

1. Контроль вартості.

2. Контроль над загальними змінами.

Створення плану управління вартістю вимагає від менеджера проекту і його команди розв”язання чотирьох наступних задач:

• визначення декількох рівнів потенційних впливів на вартість;

• визначення того, хто повинен бути залучений на кожному рівні;

• визначення того, як включаються зміни в вартісні документи по проекту;

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

Завдання: Розробити план управління вартістю проекту. Відобразити етапи та схему формування плану управління вартістю проекту. Навести приклади.

Ситуація 1.32. Розрахунок попереднього календарного плану проекту

Підходом, що найчастіше використовується до розрахунку календарного плану, керованого за часом є метод критичного шляху МКШ (CPM).

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

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

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

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

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

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

• визначення робіт на критичному шляху (тобто робіт із нульовим резервом, у яких ранні і пізні дати однакові);

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

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

Ситуація 1.33. Стиснення календарного плану проекту

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

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

У таких випадках команда проекту повинна спробувати пошукати розумні способи розв”язання задач проекту.

Методи зменшення календарного терміну розв”язання проекту включають:

• переміщення кваліфікованих людей від робіт із резервом до робіт на критичному шляху для зменшення тривалості критичного шляху;

• планування понаднормових або додаткових змін;

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

Стиснення календарного плану вимагає від менеджера проекту і його команди розв”язання п'яти наступних задач:

• визначення способів стиснення календарного плану у випадку, якщо планова дата фінішу проекту виявляється пізніше бажаної дати завершення;

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

• відповідна зміна попереднього календарного плану разом з мережевою діаграмою і списком задач.

Завдання: Стиснути календарний план проекту. Відобразити етапи та схему стиснення календарного плану проекту та критичного шляху. Навести приклади.

Ситуація 1.34. Розрахунок календарного плану, вирівняного по ресурсах

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

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

Наприклад, хоч може і не бути технічних бар'єрів для виконання двох робіт паралельно, але вони повинні виконуватися одним і тим же обмеженим ресурсом.

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

У цих випадках роботи повинні бути зсунуті, якщо ресурсні обмеження не можуть бути виконані.

Вирівнювання ресурсів проекту вимагає від менеджера проекту і його команди розв”язання наступних задач:

• забезпечення того, щоб усі роботи мали призначених виконавців;

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

• визначення часу, коли ресурси мають нереалістичне робоче завантаження (звичайно понад 8 годин на день або 40 годин на тиждень);

• творча командна робота для визначення того:

• чи можуть роботи некритичного шляху бути зсунуті на інший час (без того, щоб стати критичними);

• чи може інший менш завантажений ресурс виконати певні задачі;

• чи можуть великі або складні роботи бути розбиті на більш дрібні роботи, щоб їх могло виконувати більше за одну людину; або

• чи можуть певні роботи бути видалені з проекту без недопустимого збільшення проектного ризику;

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

Завдання: Розрахувати календарний план проекту, вирівняний по ресурсах. Відобразити етапи та схему алгоритму формування календарного плану проекту вирівняного по ресурсах. Навести приклади.

Ситуація 1.35. Документування планових допущень

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

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

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

Документування планових допущень вимагає від менеджера проекту і його команди розв”язання трьох наступних задач:

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

• визначення будь-яких інших ключових допущень за календарним планом;

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

Завдання: Проаналізувати систему документування планових допущень проекту. Відобразити етапи та схему документування планових допущень проекту. Навести приклади.

Ситуація 1.36. Створення плану управління календарним графіком проекту

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

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

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

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

Створення плану управління календарним графіком вимагає від менеджера проекту і його команди розв”язання чотирьох наступних задач:

• визначення декількох рівнів потенційних впливів на календарний план;

• визначення того, хто повинен бути залучений на кожному рівні;

• визначення того, як включаються зміни в календарний план;

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

Завдання: Створити систему управління часом на основі календарного плану проекту. Відобразити етапи та схему алгоритму управління часом на основі календарного плану проекту. Навести приклади.

Ситуація 1.37. Коректування ресурсних вимог

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

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

Коректування ресурсних вимог вимагає від менеджера проекту і його команди розв”язання двох наступних задач:

• визначення змін у порівнянні з більш ранніми оцінками ресурсів;

• відображення цих змін у ресурсних вимогах, визначених при ресурсному плануванні.

Завдання: Виконати коректування ресурсних вимог проекту. Відобразити етапи та схему алгоритму коректування ресурсних вимог проекту. Навести приклади.

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

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

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

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

Створення вартісної основи (бюджету), впорядкованої по фазах проекту, вимагає від менеджера проекту і його команди розв”язання двох наступних задач:

• підведення підсумків за вартісними оцінками проекту за певні періоди часу, звичайно щомісячно і поквартально;

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

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

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

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

Однак у випадках перевитрати вартості на ранніх стадіях проекту існує велика ймовірність іще більших проблем по мірі виконання проекту.

Вартісна основа (бюджет) - це інструмент для відстеження вартостей і визначення можливих проблем з вартістю.

Створення вартісної основи (бюджету), впорядкованої за часом, вимагає від менеджера проекту і його команди розв”язання двох наступних задач:

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

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

Завдання: Розрахувати вартісну основу (бюджет) проекту. Відобразити етапи та схему алгоритму формування вартісної основи проекту. Навести приклади.

Ситуація 1.39. Створення плану витрат

Створення плану витрат може зажадати від менеджера проекту рішення двох наступних задач:

• визначення елементів, таких як складових частин або складного обладнання, які повинні бути замовлені для їх фактичного використання в проекті;

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

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

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

Створення плану витрат вимагає від менеджера проекту і його команди розв”язання наступних задач:

• визначення елементів, таких як блоки користувача або складне обладнання, які повинні бути впорядковані для їх фактичного використання або застосування в проекті;

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

Завдання: Розрахувати план витрат проекту. Відобразити етапи та схему алгоритму формування плану витрат основи проекту. Навести приклади.

Ситуація 1.40. Аналіз результатів процесів планування

Менеджери проектів збирають всю планову документацію.

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

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

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

• збір усіх планових документів по проекту і супутній документації;

• аналіз документів на повноту, правильність і цілісність;

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

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

• коректування пов'язаних планових документів

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

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

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

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

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

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

Аналіз результатів інших процесів планування вимагає від менеджера проекту і його команди розв”язання п'яти наступних задач:

• збір всіх планових документів проекту і допоміжної документації;

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

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

• визначення і дозвіл будь-яких важливих проблем з плановими документами;

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

Завдання: Проаналізувати результати системи планування проекту. Відобразити етапи та схему системи планування проекту. Навести приклади.

Ситуація 1.41. Розробка попереднього плану проекту

Для розробки плану проекту менеджер слідує формальним вказівкам, приведеним у документі «Глобальна методологія проектного менеджменту організації».

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

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

• підготовка підготовчого плану проекту і документування супутніх деталей.

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

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

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

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

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

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

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

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

• якщо шаблон плану проекту не існує, створення ескіза, який буде ефективно зв'язувати основні елементи плану проекту;

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

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

Завдання: Розробити попередній план проекту. Відобразити етапи та схему формування попереднього плану проекту та критичного шляху. Навести приклади.

Ситуація 1.42. Проаналізувати план з експертами і зацікавленими особами

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

Перегляд плану проекту з експертами і ключовими зацікавленими особами вимагає від спонсора розв”язання п'яти наступних задач за допомогою команди:

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

• переглянути контрольні точки плану проекту і затвердити контрольні процедури;

• розглянути вхідні впливи і зворотні зв'язки і адекватно відреагувати на ідеї і пропозиції по поліпшенню;

• розглянути зворотні зв'язки з командою проекту і визначити ті зміни, які ймовірно необхідно внести в план внаслідок їх аналізу;

• при необхідності переглянути або скорегувати планові документи.

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

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

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

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

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

Перегляд плану з експертами і ключовими зацікавленими особами вимагає від менеджера проекту і його команди розв”язання п'яти наступних задач:

• проведення неформальної (часто віч-на-віч) наради із зацікавленими особами організації, які мають відповідний досвід;

• перегляд основних елементів плану проекту і процедур контролю за змінами;

• запит на вхідні дані і зворотні зв'язки і відкриту реакцію на ідеї і пропозиції по удосконаленню плану проекту;

• аналіз зворотних зв'язків із командою проекту і визначення того, які зміни необхідно ввести в план внаслідок зворотних зв'язків;

• перегляд або коректування планових документів.

Завдання: Проаналізувати попередній план проекту. Відобразити етапи та схему аналізу попереднього плану проекту та критичного шляху. Навести приклади.

Ситуація 1.43. Представлення плану проекту на затвердження

План проекту представляється клієнту на зовнішній нараді.

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

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

Представлення плану проекту на твердження вимагає від менеджера проекту розв”язання наступних п'яти задач за допомогою команди:

• підкреслення короткою, але ясною презентацією важливих елементів плану проекту;

• аналіз презентації разом з проектною командою для визначення можливих проблем;

• представлення плану спонсору проекту для коментарів і затвердження;

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

• коректування і завершення плану на основі важливих зворотних зв'язків;

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

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

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

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

Звичайно перед зустріччю менеджер проекту повинен провести презентацію перед командою проекту.

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

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

Представлення плану проекту для затвердження вимагає від менеджера проекту і його команди розв”язання наступних семи задач:

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

• проведення презентації з командою проекту для визначення потенційних проблем, міркувань і зауважень;

• представлення плану спонсору проекту на уявлення і твердження;

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

• коректування і завершення плану на основі важливих зворотних зв'язків;

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

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

Завдання: Розробити схему представлення план проекту на затвердження. Відобразити етапи затвердження плану проекту. Навести приклади.

Теми індивідуальних завдань до підрозділу

1. Техніка побудови календарного плану проекту.

2. Техніка затвердження плану проекту, заданого викладачем.

3. Техніка та технологія експертизи проекту.

4. Побудова вартісної основи (бюджету) проекту.