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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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