Как проконтролировать процессы внутри 300+ проектов, которые идут параллельно, и вовремя реагировать на проблемы? Возникает необходимость контроля на всех уровнях: от топ-менеджмента до проектного менеджера. Мы, Денис Торопов и Михаил Салуев, расскажем о своем опыте внедрения системы управления рисками. Поделимся методологией, которая помогла проектному офису внедрить процесс централизованно — сразу во всех подразделениях, которые ведут проекты.

Отталкиваемся от теории: наши ориентиры в проектном управлении

В своей работе мы опираемся на стандарты, разработанные Институтом проектного управления (Project Management Institute, PMI). Во-первых, сфера управления рисками подробно рассматривается в своде знаний PMBOK (Project Management Body of Knowledge). Во-вторых, стандарт по управлению рисками в портфелях, программах и проектах, пожалуй, один из самых всеобъемлющих трудов в этой области. В-третьих, сертификация PMP от Института долгое время высоко ценилась среди руководителей проектов в России. На практике многие компании и специалисты при внедрении систем управления рисками ориентировались именно на данные стандарты.

Следующие семь принципов из стандарта управления рисками PMI имеют непосредственную практическую пользу:

1. Стремиться к совершенству в практике управления рисками.

2. Согласовывать управление рисками со стратегией и практиками организации.

3. Уделять основное внимание рискам с наибольшим масштабом воздействия.

4. Обеспечивать баланс между реализацией ценности и совокупными рисками.

5. Способствовать формированию культуры управления рисками.

6. Ориентироваться в сложных условиях с помощью управления рисками, обеспечивая успешные результаты.

7. Постоянно совершенствовать компетенции в сфере управления рисками/

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

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

Создаем реестр рисков

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

С самого начала работы мы держали в фокусе принцип «Уделять основное внимание рискам с наибольшим масштабом воздействия». Сначала провели классификацию проектов: около 10% причислили к классу А как самые важные для компании. Остальные проекты отнесли к классам В и С.

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

На самом деле еще на старте можно сформировать первичный реестр рисков, провести  по нему анализ и подготовить превентивные меры реагирования. Далее по мере продвижения проекта по своему жизненному циклу важно отслеживать и управлять процессом, особенно в части своевременной проработки мер реагирования на непредвиденные ситуации. Возьмем распространенный риск, когда  объем работ по проекту превысил запланированную емкость. Степень критичности риска для конкретного проекта может отличаться. Когда риск двигается по шкале вверх в рейтинге, менеджер с командой готовит превентивные меры реагирования и меры на случай его наступления.

Другие примеры рисков из топ-категорий: низкая вовлеченность или нарушение коммуникации с заказчиком, высокая техническая сложность проекта (новый технологический стек, новая предметная область), дефицит ресурсов и другие. Опытный менеджер в отрасли или в компании может провести качественный анализ по данным рискам и подготовить меры реагирования.

В помощь руководителям проектов в ИСУП была сделана настройка: при создании проекта реестр рисков автоматически предзаполнялся типовым для отрасли и компании перечнем, который необходимо было проанализировать и оценить. Далее мы настроили в ИСУП раздел для качественной оценки по каждому риску, т.е. матрицу Вероятность / Влияние. Таким образом, получилось сделать разрез в двух плоскостях: первая показывает наиболее приоритетные проекты, вторая наличие критичных рисков. Количественную оценку на данном этапе внедрения посчитали избыточной, но возможно ещё вернемся к ней.

Все эти действия запустили в компании процесс формирования культуры управления рисками, что соответствует пятому принципу от PMI. Нам удалось подготовить почву для заведения рисков и их последующего анализа, создать доступ для сотрудников к информации, которая хранится и актуализируется в ИСУП. В результате заработала система мониторинга рисков в разрезе всех бизнес-юнитов, направлений, проектов.

Меры реагирования

Следующий шаг фреймворка — выработка превентивных и реагирующих мер для актуальных рисков проекта. Это касается в первую очередь критичных рисков в самых приоритетных проектах компании.

Проектный офис проводил с менеджерами проектов выборочные риск-сессии по приоритетным проектам, в которых были обнаружены критичные риски, чтобы сделать эту работу более эффективной и осмысленной.

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

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

Зачем мы ввели еще и разбор проблем на проекте

Предположим: система работает в том виде, в котором я описал выше. Что может пойти не так? Идентификация рисков — это по сути прогностическая работа менеджера проектов. ИТ-проект по составу команды — это, как правило, менеджер и технические специалисты: аналитики, разработчики, тестировщики, администраторы и другие. Остальные сотрудники смежных отделов и служб подключаются к проекту по мере необходимости и при наступлении конкретных событий в проекте. Например, юридическая служба — когда нужно согласовать договор или изменения к нему, бухгалтерская — при сверке расчетов, реквизитов и т.п. В остальное время из административного или управленческого персонала в первую очередь руководитель проекта погружен в операционную картину проекта и ведет его по намеченному плану к результату. Это большой объем ежедневных задач и коммуникаций, кроме работы по идентификации и анализу рисков. Все ли риски можно предугадать заранее, внести в реестр, оценить критичность и запланировать меры реагирования? Оставлю пока этот вопрос открытым.

А теперь представим ситуацию: на одном из проектов заказчик закрыл доступ к серверам с продуктивной версией системы. Это приведет к тому, что будет заблокирован переход к следующему этапу работ — обновлению продуктива, а также последующий ввод в промышленную эксплуатацию. Другой пример: ведущий технический специалист резко отходит от проекта на неопределенный срок (переезд, больничный, увольнение). Причины могут быть разными, но этих рисков в реестре не было, а реагировать нужно срочно. Значит ли это, что система управления рисками работает плохо или дает сбой? Или такой подход к работе с рисками — это работа впустую, она для статистики? Мы уверены, что нет. Скорее считаем, что в системе не хватало процесса идентификации и реагирования на незапланированные негативные события.

Для технической области проекта этот процесс можно было бы назвать «управление инцидентами», но поскольку ИТ-проект — это совокупность кроссфункциональных задач, то мы расширили это понятие до термина «проблема». Проблема — непредвиденное негативное событие, порождающее момент неопределенности в проекте и влияющее на его приоритет.

Любой проект с отклонением от базового плана в 5 рабочих дней и более рассматривали и обсуждали с руководителем проекта и привлекали проектный офис в контексте наличия в нем наступивших рисков или проблем. Таким образом, факт возникновения отклонений проекта от утвержденного плана служил одним из триггеров для запуска мероприятий по анализу и решению проблем либо наступивших рисков.

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

В рисках смотрели на их критичность, состояние (наступил или нет), наличие превентивных и реагирующих мер и их актуальность. В проблемах смотрели на описание (т.е. суть проблемы) и конкретные шаги по решению проблемы. 

В результате внедренных изменений любое совещание руководителя проекта с проектным офисом стало более содержательным и предметным. В ИСУП при этом, по итогам каждого митинга, были зафиксированы результаты, о которых я написал выше, в том числе в динамике. Также более эффективным стал отчет проектного офиса по статусу проектов и аналитика по проектам, которую мы реализовали в нашей BI-системе.

Что дальше?

На внедрение изменений, о которых мы рассказали, для компании из почти 3 000 сотрудников, 300+ активных проектов и 100+ руководителей проектов у нас ушло чуть более 3 месяцев работы. Еще за 3 месяца система встала на рельсы и показала свои первые результаты. Пока ещё рано говорить о полноценных целевых метриках, таких как процент проектов закрытых в срок и в соответствии с запланированными показателями качества, повышение удовлетворенности стейкхолдеров (уменьшение кол-ва жалоб и повышение кол-ва положительных отзывов), повышение маржинальности проектов и других.

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

Какие еще возможности дает выбранный нами подход к управлению рисками:

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

2. Совершенствование процессов управления проектами, прежде всего во взаимодействии с внешними службами, возможность оперативной эскалации и решения рисков и проблем.

3. Создание целостной системы и культуры управления проектами, и, как следствие — повышение зрелости проектного управления на уровне компании.

Верим, что в будущем это приведет к повышению эффективности реализации стратегии компании и повышению ее привлекательности, как для сотрудников, так и для клиентов и партнеров. Действуем дальше.

Спасибо, что дочитали статью до конца. Рассказываем об ИТ-трендах и наших продуктах и в Telegram-канале. «БАРС Груп» — российский разработчик цифровых решений для государства, бизнеса и людей. Мы создаем ИТ-продукты для импортозамещения программного обеспечения: 88 решений компании зарегистрировано в реестре российского ПО.