3.6. Управління ризиками

Ситуація 3.33. Реалізація плану управління ризиками для фактичних ризикових подій

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

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

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

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

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

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

• здійснити дію по реакції на невизначеність і відстежити результати.

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

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

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

Превентивні дії повертаються в план проекту і в календарний план як додаткові роботи.

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

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

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

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

• здійснити дію по реакції на невизначеність і відстежити результати.

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

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

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

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

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

3. Планування превентивних протиризикових дій у проекті.

4. Система здійснення превентивних протиризикових дій у проекті.

5. Система документування та коректування планів у зв"язку з ризиковими подіями проекту

3.7. Завершення проекту і перевірка змісту

Ситуація 3.34. Оцінка виконання контракту продавцем

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

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

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

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

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

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

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

• визначення будь-яких нереалізованих результатів і необхідних дій.

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

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

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

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

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

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

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

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

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

• визначення будь-яких нереалізованих результатів і необхідних дій.

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

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

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

Ситуація 3.35. Коректування проектної документації, пов'язане із змістом

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

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

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

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

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

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

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

Коректування проектної документації, пов'язаної із змістом може зажадати від менеджера проекту розв’язання наступної додаткової задачі:

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

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

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

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

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

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

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

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

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

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

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

Ситуація 3.36. Забезпечення заключного приймання контракту

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

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

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

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

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

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

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

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

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

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

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

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

• напрям формального письмового сповіщення про приймання продавцю;

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

• закриття файла контракту.

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

Ситуація 3.37. Формальне приймання результатів проекту

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

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

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

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

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

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

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

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

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

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

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

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

Ситуація 3.38. Завершення і архівація проектної документації

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• передача звіту спонсору проекту, якщо він був відсутній на нараді по перегляду після реалізації.

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

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

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

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

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

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

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

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

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

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

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

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

• передача звіту спонсору проекту, якщо він був відсутній на нараді по перегляду після реалізації.

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

Ситуація 3.40. Документування заключного приймання продукту проекту

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

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

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

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

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

Документування приймання продукту проекту може зажадати від менеджера проекту і його команди розв’язання наступної додаткової задачі:

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

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

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

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

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

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

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

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

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

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

2. Заключне прийняття контрактів проекту

3. Вирішення спорів при закритті проекту

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

5. Документування процесу закриття проекту

6. Архівація проекту

Література

1. ICB Competence Baseline, IPMA, 1999. – 112р.

2. Керівництво з питань проектного менеджменту PMBOK, К.: ВІПОЛ, 1999. -197с.

3. Бушуев С.Д., Гурин Э.А. Инвестиционные инструменты проектного менеджмента. К.: Укр. ИНТЭИ, 1998. – 184с.

4. Бушуев С.Д., Морозов В.В. Управление закупками в проектах. К.: Укр. ИНТЭИ, 1999. Т.1,2– 188с., 195с.

5. Воропаев В.И. Методы и средства управления проектами XXI века.- М.: СОВНЕТ 1997. – 385с.

6. Решке Х., Шелле Х.: Мир управления проектами.- М.: "Аланс", 1993.- 304с.

41