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

Коригуванням ситуації (risk control) є процес виконання прийнятих відносно ризиків планів і контролю за ходом їх виконання. Цей процес також включає ініціацію змін всього проекту (project change control requests), якщо зміни в стані ризиків або у відповідних планах впливають на прогнозований об'єм роботи, необхідні ресурси або терміни.

Отримання уроків (risk learning) формалізує процес засвоєння накопиченого за час роботи над проектом досвіду у формі, доступній для використання як усередині проектної групи, так і на рівні всього підприємства.

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

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

Етап 1. Виявлення ризиків

Введення

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

Цілі

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

Початкові дані

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

87

ризиків, такі як таксономія ризиків SEI, проектні чек-лісти (checklists), звідні звіти про попередні проекти і інші опубліковані джерела і галузеве керівництво.

Кроки по виявленню ризиків

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

88

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

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

Структурований підхід

Скрізь, де тільки це можливо, MSF рекомендує використовувати в процесі управління ризиками структурований підхід. У проектах по розробці і впровадженню програмного забезпечення використання класифікацій ризиків на етапі виявлення надає ясно визначений, відтворний і такий, що піддається оцінці підхід. Класифікація ризиків дає основу для стандартизації термінології, необхідної для моніторингу і звітності, і є незамінної для створення бази знань про ризики на рівні підприємства або всієї індустрії. Класифікації ризиків допомагають проектній групі мислити всесторонньо, надаючи готову систематизацію всіх складових проекту, що вимагають уваги при виявленні ризиків. Така систематизація може бути отримана на підставі досвіду схожих проектів, здійснених раніше, або ж на підставі досвідчених знань індустрії в цілому. Формулювання ризиків (risk statement formulation) є основною методикою, вживаною в рамках MSF для оцінки проектів, побудови пріоритезацій ризиків і планування пов'язаної з ризиками діяльності.

Класифікація ризиків

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

Люди

Замовники (customers)

Кінцеві споживачі (кінцеві користувачі, end users)

Спонсори

Зацікавлені сторони

Персонал

Організація

Професійна кваліфікація

Політика

Мораль

Процеси

Цілі і завдання

89

Ухвалення рішень

Характеристики проекту

Бюджет, витрати, терміни

Вимоги (requirements)

Проектування (design)

Реалізація (building)

Тестування (testing)

Технології

Безпека

Середовище розробки і тестування

Інструментарій

Впровадження

Супровід

Операційне середовище

Доступність

Зовнішні умови

Законодавство

Індустріальні стандарти

Конкуренція

Економічні умови

Технологія

Бізнес-умови

Існує безліч класифікацій загальних ризиків проектів по розробці програмного забезпечення. Добре відомі і часто цитуються Barry Boehm, Caper Jones, і SEI Software Risk Taxonomy, що описують джерела таких ризиків.

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

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

Інші джерела інформації про ризики проектів включають бази даних ризиків індустріальних проектів, такі як Software Engineering Information Repository (SEIR), і

внутрішні корпоративні бази знань про ризики.

90