Семь наиболее вероятных рисков в project-менеджменте

Год тому назад я занимался внедрением с нуля проектного управления в небольшой строительной компании.

Целью было (как зафиксировано в Уставе проекта) «Повышение эффективности реализации проектов компании за счет внедрения методов и инструментов профессионального управления проектами, в том числе инструментов отслеживания выполнения проектов, на основе лучших бизнес-практик и накопленного опыта с помощью создания в структуре компании проектного отдела». Возможно, длинновато, зато оказалось понятно и приемлемо для заказчика, следовательно, имеет право на существование.

Я переосмыслил имеющийся опыт управления рисками в прошлых проектах и разработал новый шаблон «Плана управления рисками», включающий в себя несколько этапов.

Этап 1: Провести начальную встречу по идентификации рисков с участием ключевых экспертов и исполнителей

Руководитель проекта выступает модератором встречи. Проводится «мозговой штурм» по генерации идей – какие риски могут возникнуть в процессе работы. Запрещается обсуждать и комментировать высказанные идеи. Все высказанные предположения фиксируются модератором. На этом этапе был сформирован список из более чем 40 рисков, которые были зафиксированы в протоколе.

Этап 2: Вторая часть мозгового штурма – обсуждение идей

Сначала оценивается актуальность каждого риска для данного проекта. Если нет актуальности, далее он не обсуждается. Для актуальных рисков экспертно оцениваются вероятность, влияние на сроки и бюджет, управляемость – категориями «высокая – средняя – низкая». Такое упрощение было сделано намеренно, как показывает практика – чем проще инструмент, тем выше вероятность его длительного и правильного применения.

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

Итогом второго этапа стала заполненная таблица, содержащая название риска, его актуальность, вероятность, управляемость, его влияние на сроки и бюджет проекта, а также указан владелец для каждого риска.

Этап 3: Необходимо выбрать риски, которыми будем управлять

Это может сделать РП самостоятельно либо вместе с рабочей группой. Следует выбрать риски, которые имеют наибольшую управляемость и влияние на проект. Завершение третьего этапа – подписанный План управления рисками.

Таким образом, по итогам третьего этапа был составлен следующий список рисков для управления в рамках проекта (через слеш перечислены мероприятия по минимизации):

1. Высокая загрузка руководителя проекта операционной деятельностью, что может привести к срыву сроков / Выделение администратора, выделение дополнительного IТ-эксперта, снятие части задач по операционной деятельности, планирование работ с учетом возможной загрузки.

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

3. Высокая сопротивляемость изменениям и внедрению проектного управления со стороны РП и участников команды / Заручиться поддержкой руководства компании, чаще коммуницировать с топ-менеджерами, предложить им выгоды от внедрения проектного управления.

4. Высокая загруженность топ-менеджмента и руководства компании, длительное время реакции на запросы / Поддержка руководства, создание SLA по реакции на запросы, качественное планирование работ с учетом необходимого времени на согласование документов.

5. Технические проблемы / Длительность выполнения работы, связанных с закупкой, установкой и настройкой проектного сервера / Тестирование сервера, отдельный IТ-специалист, закладывание буфера времени при планировании установки проектного сервера, проведение обучения по настройке проектного сервера, запараллеливание работ.

6. Резкое расширение зоны ответственности ПО (Проектного офиса), что приведет к недостатку ресурсов внутри ПО / Разработать комплекс мероприятий для быстрой подготовки и привлечения необходимых ресурсов, ограничить объем работ с помощью Устава.

7. Загрузка операционной деятельностью, не относящейся к проектной работе сотрудников ПО / Четкие договоренности с руководством, расширение штата при необходимости, разработка и утверждение Положения о подразделении.

После третьего этапа работа по рискам переходит в периодическую деятельность, необходимые мероприятия включаются в план-график проекта. Актуализация Плана управления рисками (ПУР) проводится ежемесячно, перед проведением Управляющего Комитета по проекту.

Для актуализации ПУР необходимо скопировать в файле вкладку «ПУР базовый» и назвать новую вкладку «месяц_год». Таким образом, в одном файле будут находиться базовый ПУР и все актуальные планы управления рисками по состоянию на каждый из прошедших месяцев.

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

По итогам завершения данного проекта сработали следующие риски:

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

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

2. Высокий процент процессников среди существующих и назначаемых РП.

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

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

3. Высокая сопротивляемость к изменениям и введению проектного управления со стороны РП и участников команд.

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

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

4. Технические проблемы / длительность выполнения работы, связанных с закупкой, установкой и настройкой проектного сервера.

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

К увеличению бюджета и задержки по срокам это не привело, однако длительность задачи в целом увеличилась на 18 недель (!).

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

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

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Консультант, Томск

Статью следовало назвать: 7 наиболее вероятных рисков в проекте ''таком-то''. В каждом проекте свои наиболее вероятные риски.

Вице-президент, зам. гендиректора, Москва

Очень интересный опыт. Хотелось бы и по-подробнее...

Руководитель, Москва

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

Консультант, Нижний Новгород

Опираясь на собственный успешный (и нет) опыт построения корпоративной системы /стандарта, регламента/ управления проектами и создание офиса считаю забытым главный риск - существующая система управления и экономика бизнеса:

руководству и собственникам компании профессиональное управление проектами
- не нужно т.к. прибыль /деньги/ зарабатываются не за счет роста эффективности
- мешает т.к. вменяет открытые обязанности высшему руководству, а не только сотрудникам

вредно руководителям среднего звена т.к. выявляет их навык затуманивать ситуацию

Косвенно, мою позицию подтверждает рухнувший профессионализм ...

Руководитель, Москва
Андрей Ткачев пишет: Опираясь на собственный успешный (и нет) опыт построения корпоративной системы /стандарта, регламента/ управления проектами и создание офиса считаю забытым главный риск - существующая система управления и экономика бизнеса: руководству и собственникам компании профессиональное управление проектами - не нужно т.к. прибыль /деньги/ зарабатываются не за счет роста эффективности - мешает т.к. вменяет открытые обязанности высшему руководству, а не только сотрудникам вредно руководителям среднего звена т.к. выявляет их навык затуманивать ситуацию Косвенно, мою позицию подтверждает рухнувший профессионализм ...
Согласен с данным риском, он частично учтен у меня в риске №3 '' Высокая сопротивляемость к изменениям и введению проектного управления со стороны РП и участников команд'', а также я с данным риском всегда старался работать ДО начала работы в подобных проектах. То есть прежде чем браться за проект внедрения проектного управления, выяснял мотивацию Руководства/Собственника, и только если их позиции были прочны и незыблемы :), брался за проект. Сразу после описанного в статье проекта мне предложили ''повторить проект построения Проектного офиса'' в другой компании холдинга, но изучив текущую ситуацию в компании, процессы, проекты, корпоративную культуру и позицию руководства - я от данного проекта отказался. Тем самым применив один из способов управления рисками - избежание риска.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
Цифры и факты
«Спасибо» за убытки

Банк дня: Герман Греф признался в том, что программа «Спасибо» приносит банку большой убыток.

Проект Неом под угрозой

Проект дня: Строительство футуристического города в Саудовской Аравии оказалось под угрозой.

inDriver стал междугородным такси

Факт дня: Российский такси-сервис запустил междугородние поездки.

​Revolut пришел в Европу

Стартап дня: Финтех-стартап выходцев из России получил европейскую банковскую лицензию.