1.2. Розробка моделі проекту

Ситуація 1.8. Розробка опису змісту проекту

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

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

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

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

Опис змісту повинен включати:

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

• продукт проекту - тобто стислий підсумок опису продукту;

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

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

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

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

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

• написання і узгодження опису суті проекту;

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

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

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

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

Ситуація 1.9. Затвердження опису змісту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ситуація 1.11. Ухвалення рішення по формуванню структури робіт проекту

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

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

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

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

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

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

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

• прив'язка всього певного низькорівневого елементу, Рівня 2 і нижче, до пов'язаних з ними елементами Рівня 1.

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

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

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

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

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

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

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

2.0 Навчання

2.1 Навчання використанню обладнання

2.2 Навчання умінням

2.3 Навчання послугам

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

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

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

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

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

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

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

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

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

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

Для перевірки правильності декомпозиції команда проект повинна задати наступні питання:

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

Чи всі компоненти відповідають опису змісту проекту?

Чи згоден споживач отримати ці і тільки ці компоненти результату?

Чи може будь-якій компонент бути чітко призначена окремій особі або організації?

Чи всі компоненти описані ясним і недвозначним способом?

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

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

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

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

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

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

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

• при необхідності внесення коректувань в WBS- структуру;

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

• перегляд WBS зі спонсором проекту і отримання її формального твердження.

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

Ситуація 1.14. Коригування WBS проекту

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

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

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

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

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

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

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

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

Ситуація 1.15. Визначити вимоги до знань і умінь

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

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

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

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

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

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

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

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

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

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

• оцінка кількості людей, необхідних для виконання роботи;

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

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

Ситуація 1.16. Визначення вимог до обладнання і матеріальних ресурсів

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

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

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

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

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

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

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

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

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

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

Ситуація 1.17. Опис переліку ресурсів

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

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

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

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

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

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

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

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

Ситуація 1.18. Визначити ресурсні альтернативи і технологічні зміни

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

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

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

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

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

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

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

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

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

Ситуація 1.19. Визначити відносини передування

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

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

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

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

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

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

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

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

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

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

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

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

Ситуація 1.20. Побудова сітьової діаграми проекту

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

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

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

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

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

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

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

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

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

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

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

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

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

• з'єднання останніх робіт із вузлом фінішу стрілками.

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

Ситуація 1.21. Перегляд і затвердження сітьової діаграми проекту

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

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

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

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

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

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

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

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

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

Ситуація 1.22. Коректування сітьової діаграми та переліку робіт проекту

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

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

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

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

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

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

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

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

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

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

Тривалість - це кількість часу, яку займає робота з урахуванням інших обов'язків виконавців ресурсів.

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

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

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

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

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

Це забезпечує досягнення двох важливих цілей:

1. це гарантує, що власники проекту будуть відповідальні за свої оцінки,

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

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

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

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

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

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

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

• запис допущень, що лежать в основі оцінки.

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

Ситуація 1.24. Порівняння поточного проекту та минулого досвіду

Архівні дані і попередній досвід по аналогічних проектах може допомогти підвищити точність попередніх оцінок.

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

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

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

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

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

Всі проекти різні і всі обставини навколо проекту впливають на тривалість його робіт.

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

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

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

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

• перегляд даних по аналогічним постачанню і роботам;

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

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

• зміна оцінок тривалості.

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

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

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

2. Техніка формування відношень передування між роботами моделі проекту.

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

4. Підготовка переліку ресурсів проекту.