Второй кейс будет про риски проекта, как собрать, в какие документы оформить, примеры рисков.

Условие кейса

Корпоративный заказчик хочет заключить с вашей компанией контракт на разработку среднего проекта (10к часов), с большим количеством интеграций со сторонними системами и большой распределенной командой. Он просит вас, как ПМа написать ему список потенциальных рисков, связанных с этим проектом. Что бы вы указали и как выглядел бы такой документ?

Решение

Чтобы управлять рисками проекта нам понадобится:

  1. План управления рисками (Risk management plan), является частью общего Плана управления проектом (Project management plan), но может быть отдельным документом, если проект достаточно большой. В данном случае нам нужен отдельный документ.
  2. Реестр рисков (Risk register)
  3. Отчет о рисках (Risk report) — опционально, как оформление результата Идентификации рисков (процесс 11.2 Identify Risks в PMBOK® Guide – 6е издание)

Разберем каждый из документов подробнее и обсудим как их заполнять

1. План управления рисками

Включает в себя следующую информацию:

  • Стратегия работы с рисками — общий подход к тому, как мы будем работать с рисками на проекте
  • Методология — какие инструменты и практики мы будем использовать для работы с рисками
  • Роли и ответственные
  • Бюджет на риски — а нашем кейсе допустим что его нет
  • Частота и время действий по рискам
  • Определение уровней вероятности наступления риска. Пример для кейса приведен ниже.
  • Определение уровня влияния риска на какой либо из параметров проекта (бюджет, качество, сроки, объем работ)
    Пример для кейса приведен ниже.
  • Матрица верояности и влияния — все комбинации вероятности и степени влияния риска для количественного определения риска. То есть из этой матрицы мы получим цифру для риска, по которой мы отсортируем список всех рисков. Можно добавить дополнительный коэффициент на «срочность» для риска, который может осуществиться в ближайшее время. Пример для кейса приведен ниже.

План управления рисками по примеру из кейса:

Стратегия работы с рисками
Риски отображаются в Реестре рисков, ПМ отслеживает наступление риска и осуществляет регулярный пересмотр и обновление рисков в реестре.

Методология
Проводим количественный и качественный анализ рисков, пересматриваем Реестр рисков минимум 1 раз в месяц. Вся команда участвует в анализе и мониторинге реестра рисков.

Роли и ответственные за риски
ПМ отвечает за мониторинг наступления рисков из Реестра рисков и за назначение регулярных встреч команды для обновления и пересмотра Реестра рисков. Архитектор и тимлид отвечают за мониторинг наступления технических рисков и немедленно информируют об этом ПМа

Частота и время действий по рискам
Первый понедельник каждого месяца — встреча всей команды для пересмотра и обновления Реестра рисков.
Каждый понедельник — мониторинг ПМом состояния рисков в Реестре.
Обновление реестра при наступлении события, описанного в Реестре — по необходимости

Определение уровней вероятности наступления риска
очень высокий — вероятность выше 80%
высокий — вероятность 60-80%
средний — вероятность 40-60%
низкий — вероятность 20-40%
очень низкая — вероятность менее 20%

Определение уровня влияния риска на какой либо из параметров проекта (бюджет, качество, сроки, объем работ)
для бюджета:
очень высокий — превышение бюджета более чем на 20%
высокий — превышение бюджета на 15-20%
средний — превышение бюджета на 10-15%
низкий — превышение бюджета на 5-10%
очень низкий — превышение бюджета менее чем на 5%

Матрица вероятности и влияния риска:

2. Реестр рисков

В форме таблицы, где для каждого риска заполняются колонки:

  • Идентификатор риска (обычно порядковый номер риска)
  • Утверждение риска в формате «{событие} может произойти, что приведет к {влияние}» или «Если {условие} будет верно, то может произойти {событие}, что приведет к {влияние}»
    например: «Если заказчик будет иметь нереалистичные ожидания, то это приведет к закрытию проекта»
    «Неполная документация по интеграции со сторонним сервисом приведет к задержкам поставки проекта»
  • Категория риска — к какой части проекта относится или к какому из аттрибутов.
    Например, бюджет, сроки, технология, архитектура, клиент, регулятор, пользователь и так далее)
  • Владелец риска — ответственный за определение и мониторинг наступления события риска
  • Вероятность наступления риска
  • Влияние риска на проект — с точки зрения его основных частей, то есть влияние на сроки, бюджет, объем работ, качество
  • Количественная оценка риска — процедура описана выше в Плане управления рисками проекта.
  • Стратегия реагирования на риск. Варианты — уклонение/избегание, снижение, делегирование, принятие.
    При уклонении мы отказываемся от той части проекта, которая порождает этот риск. Например, мы совсем не будем использовать неизвестную нам библиотеку или сторонний сервис.
    При снижении мы предпринимаем меры по снижению вероятности риска. Например, мы делаем небольшой тест, чтобы проверить, что сторонний сервис действительно предоставляет те данные, чтоб мы ожидаем.
    Делегирование происходит, когда мы работаем с подрядчиками и можем отдать риск на сторону. Например, если мы думаем что наш девопс не сможет настроить подходящее окружение для высоконагруженного проекта, то мы можем заключить контракт с компанией, которая оказывает такие услуги и, соответственно, взять с них гарантию (закрыться штрафами и т.д) о том, что все будет так, как нам нужно.
    Принятие по сути означает что мы принимаем то, что событие риска может произойти, но не считаем целесообразным тратить ресурсы проекта на другую стратегию в отношении этого риска
  • Оценка риска в денежном выражении — там, где её есть возможность посчитать. Чаще это делается для положительных рисков, то есть риска заработать.
  • Описание действий, согласно выбранной стратегии реагирования на риск. Примеры приведены выше.
  • Статус риска.Например,неактивен — не произошел, вероятность не меняетсяувеличивается — не произошел, но вероятность увеличиваетсяактивен — произошел, оказывает влияние на проектзакончился — более не актуален, потому что его вероятность снизилась до 0
  • Дополнительная информация, комментарии

Пример реестра рисков из реального проекта:

Страница пояснений к значениям столбцов в реестре:

После количественного или качественного анализа несущественные риски не отслеживаются, чтобы не отнимать на это ресурсы проекта.
Реестр рисков обновляется в течении проекта. Частота зависит от масштаба проекта и величины команды — чем больше, тем чаще проводится пересмотр списка рисков, их количественный и качественный анализ (обычно реестр пересматривается каждые 2 недели).

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

Какие риски будут в реестре в нашем кейсе:

  вероятность влияние количественная оценка стратегия действия
Неверные изначальные оценки трудоемкости работ проекта средняя средняя 0.2 снижение дополнительные проверки оценок со стороны технического архитектора и ПМа
Неверное толкование требований командой разработки средняя средняя 0.15 снижение все требования утверждены между бизнес-аналитиком, ПМом и тех 
Разработчики не имеют достаточных компетенций низкая средняя 0.05 избегание нанимать только разработчиков среднего и высокого уровня опыта
Критичная часть инфраструктуры может сломаться (сервер может упасть, блокируя разработку или работу продуктового окружения) низкая средняя 0.05 принятие окружение выстроено стабильно в облаке, любые возникающие проблемы решаются девопс в течении одного дня
Используемые сторонние библиотеки содержат баги и проблемы с безопасностью средняя средняя 0.08 снижение предварительное тестирование библиотек на наличие багов, использование только тех библиотек, которые имеют хорошую активность коммьюнити и активно поддерживаются создателем
Мы не сможем интегрироваться с одной из сторонних систем средняя высокая 0.15 снижение документация по интеграции доступна как можно раньше и успешно сделаны тестовые модули, имитирующие требуемые запросы  от интегрируемой системы
Требования проекта противоречат требованиям законов или сертификаций и могут не дать успешно пройти необходимый аудит средняя высокая 0.15 снижение ПМ и Бизнес-аналитик консультируются с юристами по поводу собранных требований и их влияния на сертификацию или аудит
Клиент затягивает принятие решений и это влияет на сроки работ по проекту средняя средняя 0.12 снижение максимальное время на ответ от клиента и принятие решения прописано в контракте. Клиент уведомлен о последствиях затягивания ответов и решений и письменно подтверждает свое согласие с ними
Клиент навязывает методологию ведения проекта, излишнюю отчетность и коммуникацию, что влияет на ход проекта низкая низкая 0.04 принятие прозрачная коммуникация с клиентом о недостатках и слабых местах выбранной методологии и открытое обсуждение её влияния на проект
Ошибки управления проектом — неправильное планирование, пренебрегание лучшими практиками, замалчивание проблем и т.д низкая средняя 0.1 снижение регулярный контроль хода проекта, привлечение внутреннего ресурса вышестоящего менеджмента для регулярного аудита подхода к ведению проекта
Внесение клиентом правок в ходе проекта, которые влияют на архитектуру проекта и требуют её изменения низкая средняя 0.1 избегание Архитектура имеет запас гибкости. Архитектура утверждается между заказчиком, ПМом, Бизнес-аналитиком и Архитектором до начала работ

3. Отчет о рисках

Это сводный отчет о рисках проекта по результатам активностей по их идентификации и анализу. Позволяет быстро понять уровень основных рисков проекта, их вероятность и потенциальное влияние на исход проекта.
В небольших и средних проектах отчет о рисках является одним из разделов отчета о текущем статусе проекта.
Какая информация входит в такой отчет: 

  • Общее описание текущего уровня рисков проекта
  • Тренды изменения рисков проекта и описание основных причин возникновения
  • Статистическая информация о рисках: общее количество, количество активных, новые, наиболее критичные и «срочные», по категориям и т.д
  • Предложения и рекомендации по стратегии влияния на общий уровень рисков проекта
  • Графики количественного анализа рисков, если проект достаточно большой и достаточно информации, чтобы их построить
  • Состояние бюджетного буфера на риски и рекомендации по его достаточности

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

Дополнительное чтение по теме

  1. PMBOK® Guide – 6е издание, Глава 11 — Управление рисками проекта
  2. Cynthia Snyder — «A Project Manager’s Book of Forms : A Companion to the PMBOK Guide».  —  https://www.bookdepository.com/Project-Managers-Book-Forms-Cynthia-Snyder/9781119393986
  3. «Управление рисками на ИТ-проектах: что поменялось за последние годы» —  https://habr.com/ru/company/technoserv/blog/374671/
  4. «УПРАВЛЕНИЕ РИСКАМИ ИТ-ПРОЕКТОВ НА ОСНОВЕ КОМПОНЕНТНОЙ СТРУКТУРЫ РАЗРАБАТЫВАЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» — https://cyberleninka.ru/article/v/upravlenie-riskami-it-proektov-na-osnove-komponentnoy-struktury-razrabatyvaemogo-programmnogo-obespecheniya
Спасибо Белковец Александр. Оригинал статьи тут
прочли: 310

Получай сообщения о новых видео, статьях, документах и событиях раз в неделю!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

LAMPOVOE IT: сообщество не программистов will use the information you provide on this form to be in touch with you and to provide updates and marketing.