Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекція 8. Управління ризиками проектів інформатизації
Ризик це завжди ймовірність і наслідки. Наприклад, завжди є ймовірність того, що метеорит впаде на офіс центру програмних розробок, і це матиме катастрофічні наслідки для проекту. Проте ймовірність настання цієї події настільки мала, що ми в більшості проектів приймаємо цей ризик і не намагаємося ним управляти.
Прийнято [3] виділяти дві категорії ризиків:
«Відомі невідомі». Це ті ризики, які можна ідентифікувати і піддати аналізу. Відносно таких ризиків можна спланувати у відповідь дії.
«Невідомі невідомі». Ризики, які неможливо ідентифікувати і, отже, спланувати у відповідь дії.
Невідомі ризики це непередбачені обставини. Єдине, що ми можемо в цьому випадку зробити, це створити управлінський резерв бюджету проекту на випадок незапланованих, але потенційно можливих змін. На витрачання цього резерву менеджер проекту, як правило, зобов'язаний діставати схвалення вищестоящого керівництва. Управлінські резерви на непередбачені обставини не входять в базовий план за вартістю проекту, але включаються до бюджету проекту. Вони не розподіляються за проектом, як бюджет, і тому не враховуються при розрахунку освоєного об'єму.
Цілі управління ризиками проекту – зниження ймовірності виникнення і/або значущості дії несприятливих для проекту подій. Адекватне управління ризиками в компанії – ознака зрілості виробничих процесів.
Планування управління ризиками
Управління ризиками це певна діяльність, яка виконується в проекті від його початку до завершення. Як і будь-яка інша робота в проекті управління ризиками вимагає часу і витрат ресурсів. Тому ця робота обов'язково повинна плануватися. Планування управління ризиками – це процес визначення підходів і планування операцій по управлінню ризиками проекту. Ретельне і докладне планування управління ризиками дозволяє:
Планування управління ризиками має бути завершено на ранній стадії планування проекту, оскільки воно украй важливе для успішного виконання інших процесів.
У відповідність з початковими даними для планування управління ризиками служать:
Відношення до ризику і толерантність до ризику організацій і осіб, що беруть участь в проекті, робить вплив на план управління проектом. Воно має бути зафіксоване у викладі основних принципів і підходів до управління ризиками.
Стандарти організації. Організації можуть мати заздалегідь розроблені підходи до управління ризиками, наприклад категорії ризиків, спільні визначення понять і термінів, стандартні шаблони, схеми розподілу ролей і відповідальності, а також певні рівні повноважень для ухвалення рішень.
Опис вмісту проекту детально описує результати постачання проекту і роботи, необхідні для створення цих результатів постачання.
План управління проектом, формальний документ, в якому вказано, як виконуватиметься проект і як відбуватиметься моніторинг і управління проектом.
План управління ризиками зазвичай включає наступні елементи:
Категорії ризиків. Структура, на підставі якої проводиться систематична і всестороння ідентифікація ризиків з потрібним ступенем деталізації. Таку структуру можна розробити за допомогою складання ієрархічної структури ризиків.
Спільні підходи для визначення рівнів ймовірності, шкали дії ризиків на проект.
Шкала оцінки дії відображає значущість ризиків(Таблиця 2) в разі його виникнення. Шкала оцінки дії може розрізнятися залежно від мети, що потенційно торкнулася ризиком, типа і розміру проекту, прийнятими в організації стратегіями і його фінансовим станом, а також від чутливості організації до конкретного виду дій.
|
Вага |
Значення |
Критерій |
|
3 |
Катастрофічні |
Втрати більш $100K |
|
2 |
Критичні |
Втрати від $10K до $100K |
|
1 |
Помірні |
Втрати менш $10K |
Таблиця 2. Приклад шкали оцінки дії ризиків
Хоча ризик може впливати і на терміни проекту, і на якість отримуваного продукту, але всі ці відхилення можуть бути оцінені в грошовому еквіваленті. Наприклад, наслідки затримка по термінах для замовленої розробки може бути виражена в сумі грошових санкцій, визначених в контракті.
Схожа шкала може бути застосована для оцінки ймовірності настання ризику (Таблиця 3).
|
Вага |
Значення |
Критерій |
|
3 |
Дуже ймовірно |
Шанси настання вельми великі |
|
2 |
Можливо |
Шанси рівні |
|
1 |
Мало ймовірно |
Настання події вельми сумнівно |
Таблиця 3. Приклад шкали оцінки ймовірності здійснення ризику
Ще однією важливою характеристикою ризику є близькість його настання. Природно, що за інших рівних умов ризикам, які можуть здійснитися вже завтра, слід сьогодні приділяти більше уваги, чим тим, які можуть статися не раніше, чим через півроку. Для шкали оцінки близькості ризику може бути застосована, наприклад, наступна градація: дуже скоро, не дуже скоро, дуже нескоро.
Ідентифікація ризиків
Ідентифікація ризиків – це виявлення ризиків, здатних вплинути на проект, і документальне оформлення їх характеристик. Це ітеративний процес, який періодично повторюється на всьому протязі проекту, оскільки в рамках його життєвого циклу можуть виявлятися нові ризики.
Початкові дані для виявлення і опису характеристик ризиків можуть братися з різних джерел.
Насамперед це база знань організації. Інформація про виконання колишніх проектів може бути доступна в архівах попередніх проектів. Слід пам'ятати, що проблеми завершених і виконуваних проектів, це, як правило, ризики в нових проектах.
Іншим джерелом даних про ризики проекту може служити різноманітна інформація з відкритих джерел, наукових робіт, маркетингова аналітика і інші дослідницькі роботи в даній області. Нарешті, багато форумів по програмуванню можуть дати безцінну інформацію про виниклі раніше проблеми в схожих проектах.
Кожен проект замислюється і розробляється на підставі маси гіпотез, сценаріїв і допущень. Як правило, в описі вмісту проекту перераховуються прийняті допущення - чинники, які для цілей планування вважаються за вірні, реальні або визначені без залучення доказів. Невизначеність в допущеннях проекту слідує також обов'язково розглядувати як потенційне джерело виникнення ризиків проекту. Аналіз допущення дозволяє ідентифікувати ризики проекту, що походять від неточності, несумісності або неповноти допущень.
Для збору інформації про ризики можуть застосовуватися різні підходи. Серед цих підходів найбільш поширені:
Опитування експертів
Мозковий штурм
Метод Дельфі
Картки Кроуфорда
Мета опитування експертів – ідентифікувати і оцінити ризики шляхом інтерв'ю відповідних кваліфікованих фахівців. Фахівці висловлюють свої думка про ризики і дають їм оцінку, виходячи зі своїх знань, досвіду і наявної інформації. Цей метод може допомогти уникнути повторного настання на одні і ті ж граблі.
Перед опитуванням експерт повинен отримати всю необхідну ввідну інформацію. Діяльність експертів необхідно направляти, ставлячи питання. Під час опиту вся інформація, що видається експертом, повинна записуватися і зберігатися. При роботі з декількома експертами вихідна інформація узагальнюється і доводиться до зведення всіх задіяних експертів.
До участі в мозковому штурмі притягуються кваліфіковані фахівці, яким дають «домашнє завдання», - підготувати свої думки по певній категорії ризиків. Потім проводяться спільні збори, на яких фахівці по черзі висловлюють свої думки про ризики. Поважно: спори і зауваження не допускаються. Всі ризики записуються, групуються по типах і характеристиках, кожному ризику дається визначення. Мета – скласти первинний перелік можливих ризиків для подальшого відбору і аналізу.
Метод Дельфі багато в чому схожий на метод мозкового штурму. Проте є важливі відзнаки. По-перше, при вживанні цього методу експерти беруть участь в опиті анонімно. Тому результат характеризується меншою суб'єктивністю, меншою упередженістю і меншим впливом окремих експертів. По-друге, опит експертів проводиться у декілька етапів. На кожному етапі модератор розсилає анкети, збирає і обробляє відповіді. Результати опиту розсилаються експертам знову для уточнення їх думок і оцінок. Такий підхід дозволяє досягти якоїсь загальної думки фахівців про ризики.
Для швидкого виявлення ризиків можна скористатися ще однією з методик соціометрії є відомою як "Картки Кроуфорда" [5] .
Суть цієї методики в наступному. Збирається група експертів 7-10 чоловік. Кожному учасникові міні-дослідження лунає по десять карток (для цього цілком підійде звичайний папір для записок). Ведучий ставить питання: "Який ризик є найбільш важливим в цьому проекті?" Всі респонденти повинні записати найбільш, на їх думку, важливий ризик в даному проекті. При цьому ніякого обміну думками не має бути. Ведучий робить невелику паузу, після чого питання повторюється. Учасник не може повторювати відповідає один і той же ризик.
Після того, як питання прозвучить десять разів, у розпорядженні ведучого з'являться від 70 до 100 карток з відповідями. Якщо група підібрана добре (в тому сенсі, що в неї входять люди з різними точками зору), ймовірність того, що учасники експерименту вкажуть більшість значущих для проекту ризиків, вельми висока. Залишається скласти список названих ризиків і роздати його учасникам для внесення змін і доповнень.
Як джерело інформації при виявленні ризиків можуть служити різні доступні контрольні списки ризиків проектів розробки, які слід проаналізувати на застосовність до даного конкретного проекту.
Наприклад, Барії Боем [6] приводить список 10 найбільш поширених ризиків програмного проекту:
1. Дефіцит фахівців.
2. Нереалістичні терміни і бюджет.
3. Реалізація невідповідної функціональності.
4. Розробка неправильного призначеного для користувача інтерфейсу.
5. Золота сервіровка, перфекціонізм, непотрібна оптимізація і відточування деталей.
6. Безперервний потік змін.
7. Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених в інтеграцію.
8. Недоліки в роботах, що виконуються зовнішніми (по відношенню до проекту) ресурсами.
9. Недостатня продуктивність отримуваної системи.
10. Відмінності у кваліфікації фахівців різних галузей знань.
Демарко і Лістер [1] приводять свій список з п'яти найбільш важливих джерел ризиків будь-якого проекту розробки ПЗ:
1. Вади календарного Планування
2. Плинність кадрів
3. Роздмухування вимог
4. Порушення специфікацій
5. Низька продуктивність
Не існує вичерпних контрольних списків ризиків програмного проекту, тому необхідно уважно аналізувати особливості кожного конкретного проекту.
Результатом ідентифікації ризиків повинен стати список ризиків з описом їх основних характеристик: причини, умови, наслідків і збитку.
Якщо повернутися наприклад проекту створення «Автоматизованої системи продажу документації», то список головних виявлених ризиків може виглядати таким чином:
Таблиця 4 Список ризиків проекту створення «Автоматизованої системи продажу документації»
|
Причина |
Умови |
Наслідки |
Збиток |
|
Вимоги не ясні. |
Відсутність опису сценаріїв використання системи. |
Затримка початку розробки прикладного ПЗ. Великий об'єм переробок. |
Затримки в термінах здачі готового продукту і додаткові трудовитрати. |
|
Недолік кваліфікованих кадрів. |
Архітектура і код низької якості. |
Велике число помилок. Великі витрати на їх виправлення. |
Затримки в термінах здачі готового продукту і додаткові трудовитрати. |
|
Плинність кадрів. |
Часта зміна учасників команди. |
Низька продуктивність при введенні нових учасників в проект. |
Затримки в термінах здачі готового продукту і додаткові трудовитрати. |
За процесом ідентифікації ризиків слідує процес їх якісного аналізу.
Якісний аналіз ризиків
Якісний аналіз ризиків включає розставляння рангів для ідентифікованих ризиків. При аналізі ймовірності і впливу передбачається, що ніяких мерів по попередженню ризиків не проводяться.
Якісний аналіз ризиків включає:
Визначення ймовірності реалізації ризиків.
Визначення тягаря наслідків реалізації ризиків.
Визначення рангу ризику по матриці «ймовірність - наслідки».
Визначення близькості настання ризику.
Оцінка якості використаної інформації.
Для якісної оцінки ймовірності реалізації ризику і визначення тягаря наслідків його реалізації застосовується, як правило, загальноприйняті в організації шкали, приклади яких ми наводили раніше.
Для визначення рангу ризику використовується матриця ймовірності і наслідків . Ранг ризику визначається добутком ваги ймовірності і значущості наслідків.
Можуть, звичайно, існувати і складніші шкал для оцінок ймовірності, значущості наслідків і рангу ризиків. Зустрічалися шкали, які містили до 10 градацій. Але, на мій погляд, найбільш прагматичний підхід – це використовувати трирівневе ранжування.
Продовжуючи розгляд прикладу проекту створення «Автоматизованої системи продажу документації», матриця рангів головних виявлених ризиків може виглядати таким чином (Таблиця 5).
Таблиця 5. Матриця рангів головних виявлених ризиків проекту створення «Автоматизованої системи продажу документації»
|
Причина |
Ймовірність |
Дія |
Ранг |
|
Вимоги не ясні |
Дуже ймовірно |
Катастрофічні |
9 |
|
Недолік кваліфікованих кадрів. |
Дуже ймовірно |
Критичні |
6 |
|
Текучість кадрів. |
Можливо |
Критичні |
4 |
Для оцінки ризиків необхідна точна і адекватна інформація. Використання неточної інформації веде до помилок в оцінці. Невірна оцінка ризику також є ризиком.
Критерії оцінки якості використовуваної при аналізі інформації виглядають таким чином:
Ступінь розуміння ризику.
Доступність і повнота інформації про ризик.
Надійність, цілісність і достовірність джерел даних.
Результатом якісного аналізу ризиків є їх докладний опис
Результати якісного аналізу використовуються в ході подальшого кількісного аналізу ризиків і Планування реагування на ризики.
Кількісний аналіз ризиків
Кількісний аналіз проводиться відносно тих ризиків, які в процесі якісного аналізу були кваліфіковані як що мають високий і середній ранг.
Для кількісного аналізу ризиків можуть бути використані наступні методи:
Аналіз чутливості.
Аналіз дерева рішень.
Моделювання і імітація.
Аналіз чутливості допомагає визначити, які ризики володіють найбільшим потенційним впливом на проект. В процесі аналізу встановлюється, в якому ступені невизначеність кожного елементу проекту відбивається на досліджуваній меті проекту, якщо решту невизначених елементів приймають базові значення. Результати представляються, як правило, у вигляді діаграми «торнадо». Аналіз наслідків можливих рішень проводиться на основі вивчення діаграми дерева рішень, яка описує дану ситуацію з врахуванням кожної з наявних можливостей вибору і можливого сценарію. Критерієм для ухвалення рішення служить математичне очікування втрат від його ухвалення.
При моделюванні ризиків проекту використовується модель для визначення наслідків від дії детально описаних невизначеностей на результати проекту в цілому. Моделювання зазвичай проводиться за допомогою методу Монте-Карло.
Цікавий приклад подібної моделі - система Riskology від Демарко і Лістера, який ілюструє вживання методу Монте-Карло для отримання інформації про те, який запас часу буде необхідний для того, щоб здолати вплив всіх некерованих ризиків проекту. Модель дозволяє врахувати п'ять основних і п'ять додаткових ризиків проекту.
|
НАЗВА РИЗИКУ |
ОПИС |
СТАТУС |
|
КАЛЕНДПЛАН |
Вади календарного Планування |
ВКЛ |
|
ТЕКУЧКА |
Текучість кадрів |
ВКЛ |
|
РОЗДМУХУВАННЯ |
Роздмухування вимог |
ВКЛ |
|
СПЕЦИФІКАЦІЇ |
Порушення специфікацій |
ВКЛ |
|
ПРОІЗВОД |
Низька продуктивність |
ВКЛ |
Характеристики зумовлених в системі Riskology ризиків користувач може змінити, задавши значення мінімальною, максимальною і найбільш вірогідної затримки термінів здачі проекту із-за впливу даної ризику. Можна включити в модель додаткові власні ризики.
Планування реагування на ризики
Планування реагування на ризики – це процес розробки шляхів і визначення дій із збільшення можливостей і зниження погроз для цілей проекту. Даний процес зачинається після проведення якісного і кількісного аналізу ризиків.
Заплановані операції по реагуванню на ризики повинні відповідати серйозності ризику, бути економічно ефективними у вирішенні проблеми, своєчасними, реалістичними в контексті проекту і узгодженими зі всіма учасниками.
Згідно [3] можливі чотири методи реагування на ризики:
Ухилення від ризику (risk avoidance).
Передача ризику (risk transference).
Зниження ризиків (risk mitigation).
Ухвалення ризику (risk acceptance).
Ухилення від ризику передбачає зміну плану управління проектом так, щоб виключити загрозу, викликану негативним ризиком, захистити цілі проекту від наслідків ризику або ослабити цілі, що знаходяться під загрозою (наприклад, зменшити вміст проекту). Деякі ризики, що виникають на ранніх стадіях проекту, можна уникнути за допомогою уточнення вимог, отримання додаткової інформації або проведення експертизи. Наприклад, відхилитися від ризику можна, якщо відмовитися від реалізації ризикованої функціональної вимоги або самостійно розробити необхідний програмний компонент, замість очікування постачань продукту від субпідрядника.
Передача ризику має на увазі перекладення негативних наслідків загрози з відповідальністю за реагування на ризик на третю сторону. Передача ризику просто переносить відповідальність за його управління іншій стороні, але ризик при цьому нікуди не дівається. Передача ризику практично завжди передбачає виплату премії за ризик стороні, що переймає на себе ризик. Наприклад, замовлення на стороні розробки ризикованого компоненту за фіксованою ціною. У IT часто доводиться формулювати ризики у вигляді допущень, тим самим передаючи його замовникові. Наприклад, оцінюючи проект впровадження, ми можемо записати допущення про те, що виробник не змінить вартість ліцензій на базове ПЗ.
Зниження ризиків передбачає пониження ймовірності і/або наслідків негативної ризикованої події до прийнятних меж. Вживання попереджувальних заходів по зниженню ймовірності настання ризику або його наслідків часто виявляються ефективнішими, ніж зусилля по усуненню негативних наслідків, події ризику, що робляться після настання. Наприклад, ранній дозвіл архітектурних ризиків знижує втрати при достроковому закритті проекту. Або регулярна ревізія постачань замовником може понизити ймовірність ризику його незадоволення кінцевим результатом. Якщо в проектній команді висока ймовірність звільнення співробітників, то введення на початковій стадії в проект додаткових (надлишкових) людських ресурсів знижує втрати при звільненні членів команди, оскільки не буде витрат на «в'їзд» до проектного контексту нових учасників.
І, нарешті, ухвалення ризику означає, що команда проекту усвідомлено вирішила не змінювати план управління проектом у зв'язку з ризиком або не знайшла відповідної стратегії реагування. Ми вимушені приймати всі «невідомі ризики».
Ухвалення це те, що завжди відбувається, коли ми взагалі не управляємо ризиками. Якщо ж ми управляємо ризиками, то ми можемо страхувати ризики, закладаючи резерв в оцінки терміну завершення і/або трудовитрат. Проактивне відношення до прийнятих ризиків може полягати в розробці план реагування на ризики. Цей план може бути введений в дію тільки за заздалегідь певних умов, якщо є упевненість і достатня кількість ознак того, що даний план буде успішно виконаний.
Поважно пам'ятати про вторинні ризики (Secondary Risks), що виникають в результаті вживання реагування на ризики, які теж мають бути ідентифіковані, проаналізовані і при необхідності включені в список керованих ризиків.
Головні ризики програмних проектів і способи реагування
Мій список з п'яти головних причин провалу програмних проектів - наступний:
Вимоги замовника відсутні / не повні / схильні до частих змін.
Відсутність необхідних ресурсів і досвіду.
Відсутність робочої взаємодії із замовником.
Неповнота Планування. «Забуті роботи».
Помилки в оцінках трудомісткості і термінів робіт.
Це звучить банально, але скільки б разів про це не твердили раніше, як і раніше, доводиться стикатися з програмними проектами, в яких відсутні яка-небудь певна мета і вимоги. Цитата з життя: «Була б розроблена хороша програма, а який процес автоматизувати з її допомогою, ми знайдемо».
Якщо ймовірність змін вимог проекту висока, то можливі наступні підходи для реагування на даний ризик:
Переоцінка проекту кожного разу, коли вимоги додаються / змінюються (ухилення).
Ітераційна розробка. Контракт з компенсацією витрат на основі «Time & Materials» (передача ризику Замовникові).
Облік в оцінках трудомісткості і термінів можливості зростання вимог, наприклад, на 50% (резервування ризику).
І ще, при зборі вимог слід дотримувати принцип мінімалізму Вольтера: «Розповідь закінчена не тоді, коли в нього нічого додати, а тоді, коли з нього нічого більше викинути». Для більшості програмних продуктів застосуємо принцип Парето: 80% цінностей продукту поміщені лише в 20% вимог до нього.
Якщо у нас в проекті недостатньо кваліфікованих фахівців, то ми можемо понизити наслідки цієї ризику, застосувавши наступні дії:
Привабити експертів-консультантів на початкових етапах.
Враховувати в оцінках трудомісткості витрачання на навчання співробітників.
Зменшувати втрати від текучості кадрів, приваблюючи на початковому етапі надлишкове число учасників.
Врахувати в оцінках «час розгону» для нових співробітників.
Для встановлення відкритих і довірчих стосунків із замовником, необхідно робити наступні кроки:
Постійна взаємодія.
Узгодження призначених для користувача інтерфейсів і розробка прототипу продукту.
Періодичні постачання тестових версій кінцевим користувачам для їх оцінки.
При плануванні робіт за проектом часто «забувають»:
Навчання.
Координація робіт.
Уточнення вимог.
Управління конфігураціями.
Розробка і підтримка скриптів автоскладання.
Розробка автотестів.
Створення тестових даних.
Обробка запитів на зміни.
І ще. Не варто сподіватися, що учасники проекту кожного тижня по 40 годин працюватимуть саме над вашим проектом. Є безліч причин, по яких вони не зможуть працювати за проектом 100% свого часу. До списку найбільш поширених причин цього відносяться:
Супровід систем, що діють.
Підвищення кваліфікації.
Участь в підготовці техніко-комерційних пропозицій.
Участь в презентаціях.
Адміністративна робота.
Відпуски, свята, лікарняні.
Рекомендація, планувати, що розробники, які призначені у ваш проект на 100% реально працюватимуть над вашими завданнями в середньому від 24 до 32 годин в тиждень.
Помилкам в оцінках трудомісткості і термінів проекту і походам, які дозволяють їх мінімізувати, буде присвячена наступна лекція.
Управління проектом, направлене на зниження ризиків
На стадії ініціації проекту оцінка його трудомісткості має погрішність від -50% до +100% [4]. Це, якщо оцінка хороша! А якщо погана, то невизначеність, а, отже, і ризики зірвати терміни і перевищити планову трудомісткість, можуть бути в рази більше.
Проектом слід управляти так, щоб ризики невчасної здачі і перевитрати ресурсів постійно знижувалися.
Раніше ми вже говорили про те, що 80% цінностей розробки обумовлена лише 20% вимог до продукту, без реалізації яких продукт для замовника стає просто непотрібним. Решта вимог, як правило, так звана «прикрашення», від частки яких замовник, як правило, може відмовитися, щоб отримати проект в строк. Тому слід насамперед реалізовувати ключові функціональні вимоги.
Але є і ще архітектурні ризики. Відомо, що закон Парето застосовний і до споживання обчислювальних ресурсів: 80% споживань ресурсів (час і пам'ять) доводиться на 20% компонентів. Тому, необхідно реалізовувати архітектурно-значущі вимоги так само насамперед, створюючи «показний» прототип майбутньої системи, який «прострілює» весь стек, вживаних технологій. Прототип дозволить зміряти і оцінити загальносистемні властивості майбутнього продукту: доступність, швидкодія, надійність, масштабованість і інш. Помилка - реалізовувати спочатку легкі вимоги, щоб продемонструвати швидкий прогрес проекту.
Управління, націлене на зниження ризиків, дозволяє істотно понизити невизначеність на ранніх стадіях проекту
Опрацьовування ключових функціональних вимог і детальне Планування їх реалізації дозволяє зменшити розкид початкових оцінок, приблизно, в 2 рази: від -30% до +50%. Детальне проектування і розробка прототипу майбутньої системи дозволить отримати ще точніші оцінки загальної трудомісткості: від -10% до +15%.
Може опинитися так, що за результатами прототипування, уточнені оцінки сумарної трудомісткості виявляться неприйнятними. В цьому випадку проект доведеться закрити достроково, але втрати при цьому, будуть значно менше, ніж у випадку, якщо те ж саме станеться, коли проект вже в 2 рази перевищить первинну оцінку трудомісткості.
Якщо із замовником не удається знайти взаємоприйнятне рішення при первинній оцінці проекту, то розумно спробувати домовитися про виконання проекту в 2 етапи з самостійним фінансуванням:
1. Дослідження. Бізнес-аналіз, уточнення вимог, проектування і прототипування рішення, уточнення сумарних оцінок трудовитрат. Ця робота, як правило, вимагає 10 % спільних трудовитрат і 20% часу всього проекту.
2. Безпосередньо реалізація. Якщо уточнені оцінки трудовитрат виявляться прийнятними для замовника.
Моніторинг і контроль ризиків
Управління ризиками повинне здійснюватися впродовж всього проекту. Не вести моніторинг ризиків в ході проекту – все одно, що не стежити за рівнем палива при поїздці на автомобілі.
Моніторинг і управління ризиками – це процес ідентифікації, аналізу і Планування реагування на нові ризики, відстежування раніше ідентифікованих ризиків, а також перевірки і виконань операцій реагування на ризики і оцінки ефективності цих операцій.
В процесі моніторингу і управління ризиками використовуються різні методики, наприклад, аналіз трендів і відхилень, для виконання яких необхідні кількісні дані про виконання, зібрані в процесі виконання проекту.
Моніторинг і управління ризиками включає наступні завдання:
Перегляд ризиків.
Аудит ризиків.
Аналіз відхилень і трендів.
Перегляд ризиків повинен проводитися регулярно, згідно розкладу. Управління ризиками проекту має бути одним з пунктів порядку денного всіх нарад команди проекту. Непогано зачинати кожен статус мітинг з питання: «Ну і які ще неприємності нас чекають?» Ідентифікація нових ризиків, і перегляд відомих ризиків відбувається з використанням процесів, описаних раніше.
Аудит ризиків передбачає вивчення і надання в документальному вигляді результатів оцінки ефективності заходів щодо реагування на ризики, що відносяться до ідентифікованих ризиків, вивчення основних причин їх виникнення, а також оцінку ефективності процесу управління ризиками.
Тренди в процесі виконання проекту підлягають перевірці з використанням даних про виконання. Для моніторингу виконання всього проекту можуть використовуватися аналіз освоєного об'єму і інші методи аналізу відхилень проекту і трендів (див. Лекція 8. Реалізація проекту). На підставі виходів цих аналізів можна прогнозувати потенційні відхилення проекту на момент його завершення за показниками вартості і розкладу. Відхилення від базового плану можуть указувати на наслідки, викликані як погрозами, так і сприятливими можливостями.