Привіт! Вітаємо тебе у другому уроці з проєктного менеджменту в ІТ.

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

Проєктний чартер та його складові

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

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

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

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

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

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

• Вступ — опис та визначення проєкту, зокрема його мети, об'єктивів та очікуваних результатів.
• Обґрунтування проєкту — пояснення, чому проєкт важливий для компанії та як він стосується стратегії компанії.
• Обмеження та ризики — опис можливих обмежень та ризиків, що впливатимуть на успіх проєкту та стратегії управління ними.
• Обсяг проєкту — опис важливих етапів та завдань проєкту та їхніх результатів, яких потрібно досягти.
• Зацікавлені сторони (стейкхолдери) — перелік усіх осіб, що мають певний інтерес до проєкту та їхні ролі і зони відповідальності.
• Бюджет — приблизний бюджет проєкту, включно з орієнтовними витратами (наприклад, на робочі години та матеріали).
• Графік проєкту — орієнтовний розклад, що містить етапи та терміни виконання робіт.
• Стандарти якості — опис вимог до якості результатів проєкту та стратегій для їх досягнення.
• Підтвердження та схвалення — перелік осіб, які затверджують проєкт та підписують проєктний чартер.

Гаразд, тепер коли ми знаємо про складові цього документа, розгляньмо його структуру на прикладі шаблону від Project management institute (PMI).

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

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

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

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

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

Чартер проєкту починається з шапки.

Шапка чартеру зазвичай містить:

• Назву проєкту;
• Спонсора проєкту;
• Менеджера проєкту;
• Дату заповнення документа; 
• Замовника проєкту; 
• Кінцевого споживача проєкту (опційно).

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

Приклади назв проєкту: 

• Fitway
• Healthwatcher
• YourMeal 

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

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

Роль спонсора проєкту передбачає такі функції:

• Фінансування проєкту та забезпечення необхідних ресурсів;
• Визначення мети та цілей проєкту;
• Забезпечення підтримки та залучення стейкхолдерів;
• Управління ризиками та контроль над проєктними витратами;
• Забезпечення ресурсів для виконання проєкту;
• Забезпечення комунікації та співпраці між учасниками проєкту.

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

‍Менеджер проєкту — це в цьому випадку ти. Твоє ім’я має бути записане в чартері проєкту — і це наділяє тебе повноваженнями для керування ресурсами проєкту.

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

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

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

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

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

Після шапки проєкту маємо загальний опис проєкту.

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

Опис проєкту повинен:

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

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

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

Далі вказуємо мету проєкту

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

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

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

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

‍Межі проєкту (Project Boundaries), також відомі як обсяг проєкту, визначають кордони проєкту та що в нього входить, а що ні. Межі проєкту можна розділити на дві категорії: у межах (in scope) і поза межами (out of scope).

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

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

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

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

Ось декілька прикладів меж проєкту:

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

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

Або ось приклад більш детального опису:

В межах проєкту:

• Дизайн та розробка мобільного додатка для платформ iOS та Android;
• Інтеграція з популярними фітнес-носіями та пристроями, як-от Fitbit і Apple Watch;
• Відстеження та моніторинг показників фітнесу та харчування, як-от пройдені кроки, спалені калорії та споживання води;
• Надання персоналізованих рекомендацій і відгуків на основі даних користувачів;
• Автентифікація користувача та функції безпеки: вхід, скидання пароля та шифрування даних;
• Зберігання та отримання даних із хмарної бази даних;
• Тестування та відлагодження мобільного додатка для забезпечення високоякісного досвіду користувача;
• Розгортання програми в App Store і Google Play Store.

Виходить за межі проєкту:

• Розробка будь-яких маркетингових чи рекламних матеріалів, окрім описів у магазинах додатків;
• Аналіз даних і звітність за межами персоналізованих рекомендацій, наданих у програмі;
• Інтеграція зі сторонніми додатками чи службами, окрім популярних фітнес-носіїв та пристроїв;
• Підтримка клієнтів, окрім вбудованих довідкових функцій програми;
• Локалізація програми для неангломовних ринків;
• Зміни функцій або функцій програми за межі початкового обсягу без офіційного запиту на зміну та процесу затвердження.

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

Перейдемо до ризиків проєкту

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

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

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

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

Наступний крок — вказати ключові результати проєкту

‍Ключові результати (Key Deliverables) — це осяжні та вимірювані результати проєкту, які мають бути створені та виконані протягом визначеного періоду часу та в межах бюджету, щоб задовольнити цілі проєкту та виправдати очікування зацікавлених сторін. Ключові результати — це результати проєктної роботи, які дозволяють команді досягти цілей проєкту: продукти, послуги, звіти, документи, плани, прототипи (зразки продукту, що ще не повністю розроблений, але має елементи чи функції, які можна протестувати на ранній стадії розробки)*, системи або будь-який інший тип матеріального чи нематеріального результату. Ключові результати зазвичай визначаються та документуються в проєктному чартері і вони слугують основою для моніторингу та контролю прогресу та успіху проєкту.

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

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

• Функціонал (або модуль) реєстрації пацієнтів;
• Функціонал (або модуль) електронних медичних записів (ЕМЗ);
• Функціонал (або модуль) планування зустрічей;
• Функціонал (або модуль) виставлення рахунків та оплати;
• Функціонал (або модуль) управління аптекою;
• Функціонал (або модуль) управління запасами;
• Портал пацієнтів для доступу до медичної інформації та запису на прийом;
• Функціонал (або модуль) звітності та аналітики;
• Інтеграція з медичним обладнанням і приладами;
• Функції безпеки та конфіденційності для захисту інформації про пацієнта.

Або ж приклад результатів для CRM-системи (Customer Relationship Management):

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

Останній крок на сьогодні — вказати цілі та критерії успіїу проєкту

Визначення цілей проєкту і критеріїв успіху за цими цілями є важливою складовою проєктного чартеру. Як ми вже дізналися, проєкт має три найважливіші складові: обсяг проєкту, час його завершення і випуску та бюджет, за який ми маємо його виконати. Тож і цілі проєкту доречно прив'язувати до цих трьох основних сутностей. Однак ти можеш не обмежуватися лише цими трьома складовими і скласти список цілей, які стосуються не лише до трьох основних складових проєкту (залізного трикутника). Ти можеш додавати інші цілі, що відображають бізнес-вимоги і дають змогу краще розуміти кінцевий результат проєкту. Наприклад, “отримати PR видимість через публікацію на 10 ІТ-сайтах” не належить до обсягів, бюджету чи термінів, але може бути однією з ключових цілей проєкту.

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

Для того, щоб сформулювати цілі проєкту в проєктному чартері, можна скористатися методикою SMART:

• Конкретні (Specific) — цілі мають бути чітко сформульовані та орієнтовані на результат, який проєкт повинен досягти.
• Вимірювані (Measurable) — цілі мають бути вимірювані та містити параметри, за якими можна визначити, чи були вони досягнуті.
• Досяжні (Achievable) — цілі мають бути реалістичними та досяжними з наявними ресурсами та технологіями.
• Релевантні (Relevant) — цілі мають бути пов'язані з метою організації та допомагати досягти її.
• Обмежені в часі (Time-bound) — цілі мають бути прив'язані до конкретних строків та містити чітко визначений термін досягнення.

Наприклад, цілі проєкту можуть бути сформульовані так:

1. Запустити новий вебсайт компанії до кінця року, який матиме мінімум 5000 унікальних відвідувачів на місяць.
2. Розробити нову лінійку продуктів та випустити на ринок до початку наступного року, щоб збільшити обсяг продажів на 20% протягом першого кварталу після випуску.
3. Організувати курси навчання для персоналу з метою підвищення продуктивності на 15%.
4. Збільшити час фізичної активності на 30 хвилин щодня, записуючи кількість часу на виконання фізичних вправ щоденно впродовж 30 днів, щоб покращити своє здоров'я та знизити ризик розвитку серцево-судинних захворювань."

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

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

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

• Збільшення продажів компанії на 20% до кінця наступного фінансового року;
• Введення нового мобільного додатка в експлуатацію до певної дати;
• Забезпечення належного функціонування додатка без помилок;
• Задоволення вимог та очікувань користувачів (оцінка в магазинах додатків) щодо функціональності додатка.

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

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

‍

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

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

1. Скопіюй шаблон проєктного чартеру на свій Google Drive.

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

          • бізнес-кейс
          • лист від замовника

    3. Згідно з листом та бізнес-кейсом, заповни ці частини проєктного чартеру:
          • шапку;
          • опис проєкту: 3-5 речень;
          • мету проєкту;
          • межі проєкту: щонайменше 2-3 задачі в межах проєкту та 2 поза межами проєкту;
          • загальні ризики проєкту: щонайменше 3;
          • головні результати (deliverables), які маємо отримати в кінці проєкту: 3 позиції;
          • щонайменше 4 цілі проєкту: для обсягу, часу і бюджету — та ще одну з категорії “інше”; а також 1-2 критерії успіху для кожної з цілей. 

А ось виконання цього завдання від автора курсу із озвучкою від нашої чарівної редакторки Ніки:

‍

В цьому домашньому завданні ти:

• Познайомишся з поняттями менеджменту ризиків, матрицею ймовірності та рівня впливу ризиків, а також шляхами пом’якшення рівня впливу ризику;
• Прорахуєш ймовірність та рівень впливу наявних ризиків на твоєму проєкті (що ти описува_ла в проєктному чартері);
• Обереш стратегії пом’якшення рівня впливу ризиків;
• Дізнаєшся про реєстр ризиків і заповниш його.

Почнімо з теорії

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

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

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

Процес менеджменту ризиків допомагає зрозуміти: 

• що може піти не так у проєкті;
• наскільки це важливо та наскільки сильно вплине на результати проєкту;
• як можна зменшити потенційні впливи ризиків.

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

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

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

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

Ця матриця має дві складові:

1. Рівень впливу ризику — це рівень проблем, які може спричинити ризик, якщо він трапиться. Вплив визначається за такою шкалою: високий / середній / низький рівень. Високий рівень означає, що якщо ризик трапиться, то він суттєво вплине на проєкт. Наприклад, критично зміняться терміни виконання або бюджет проєкту. Низький означає, що ризик матиме незначний вплив і не призведе до зриву проєкту.
2. Ймовірність ризику — це вірогідність того, що ризик відбудеться. Вона визначається також за шкалою високої, середньої та низької ймовірності. У цьому випадку високий рівень означає, що скоріше за все цей ризик трапиться; а низький рівень — що він може відбутись, але навряд чи. 
   

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

Отже, тепер ми розуміємо, які бувають ризики та які з них найсерйозніші. Тепер починається найцікавіше — а що з ними власне робити? Для цього використовують стратегії пом’якшення рівня впливу ризиків. Простіше кажучи, це 4 типи стратегій (в деяких джерелах ти можеш знайти 5 стратегій замість 4), які ти та команда можете обрати щодо ризику. Вони бувають такими:

• Стратегія уникнення: Ця стратегія спрямована на те, щоб обійти (уникнути) ситуацію в цілому. Наприклад, ти дізна_лась, що певний підрядник з випуску чашок, з яким ви планували працювати над проєктом, має погану репутацію щодо дотримання термінів. Ти можеш уникнути цього ризику, знайшовши іншого підрядника.
• Стратегія мінімізації: Мінімізація ризику передбачає намагання звести до мінімуму наслідки, які він може мати для проєкту. Часто про цю стратегію говорять в розрізі пошуку обхідних шляхів. Наприклад, в тебе є улюблений постачальник, але він не може забезпечити всі потреби проєкту (треба 5000 чашок, а ця компанія може виготовити лише 4000). Використання цієї стратегії буде означати не повністю відмовитись від постачальника, а просто знайти ще одного, хто зможе довипустити частину забраклої продукції (останню 1000 чашок). 
• Стратегія передачі: Це коли ми перекладаємо відповідальність за управління ризиком на когось іншого. Наприклад, ти планува_ла виготовляти чашки на власному заводі, але знайшовся хтось, хто може зробити це значно дешевше за твій завод. Таким чином ти передаєш відповідальність за виготовлення чашок на когось іншого. 
• Стратегія прийняття: Наприклад, твій постачальник чашок повідомляє тобі, що 500 чашок бурякового кольору були розбиті в транспортуванні та обіцяє надіслати таку ж партію з перенесенням дедлайну на 3 дні. Звісно, можна знайти іншого постачальника, але навіщо, якщо час змінився всього на 3 дні, а проєкт дозволяє таку затримку? Ця стратегія про прийняття змін і підлаштування під них.
  

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

Що ж, тепер наш реєстр ризиків готовий! Нагадаємо, що цей документ не створюється раз і назавжди. Ти маєш повертатися до нього з командою та стейкхолдерами час від часу (це залежить від того, як компанія ставиться до ризиків і наскільки готова залучатись у планування їх аналізу та вирішення) та проходити знову весь шлях менеджменту ризиків. Звучить складно, але лише так ми забезпечимо успіх проєкту і не дамо йому “зійти з рейок”.

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

1. Зроби шаблон реєстру ризиків в окремому Google Docs/Word файл (три колонки: "назва ризику", "загальний вплив ризику", "що робитимемо з ризиком";

2. Впиши всі ризики зі свого чартеру в розділ “Назва ризику”;

3. Користуючись матрицею ймовірності та рівня впливу ризиків (приклад трошки вище) вкажи для кожного ризику загальний рівень впливу;

4. Обери стратегію пом’якшення ризиків для кожного з ризиків та запиши їх в розділ “що робитимемо з ризиком”;

5. Опиши детальніше, що робитимеш з ризиком відповідно до обраної стратегії.

А ось виконання цього завдання від автора курсу із озвучкою від нашої чарівної редакторки Ніки:

Першу частину проєктного чартеру заповнено! Сміливо переходь до наступного уроку, де ми разом його завершимо.

‍