Как управлять форс-мажорами в менеджменте проектов? Снижаем влияние рисков

Казалось бы, в заголовок вынесен оксюморон. Невозможно управлять форс-мажорами, это как «горячий снег». Форс-мажор — это что-то непредсказуемое, на что человек или компания повлиять не могут. Это фактор риска, который невозможно предсказать, и которым невозможно управлять.

На самом деле, это не так. Стивен Кови в своей книге «7 навыков высокоэффективных людей» ввел очень интересную схему «управления неуправляемым». Он предложил разделять все внешние факторы на круг забот и круг влияния.

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

В этой статье я бы хотел подробнее рассказать о риск-менеджменте в управлении IT-проектами.

Риски, с которыми менеджеры проектов сталкиваются чаще всего, можно свести к трем пунктам:

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

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

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

Например:

Фактор

Как избежать

Как снизить влияние

Сотрудник может уволиться

Прописать в соглашениях с сотрудниками санкции за увольнение по ходу проекта

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

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

На этом риск-менеджмент тоже не стоит останавливать. За эффективностью принятых мер тоже нужно следить, корректировать методы борьбы с рисками и внедрять новые решения.

Если это возможно, разработку нужно перевести на ограниченное количество технологий, и набирать специалистов только с конкретным профилем. Например, если говорить о web, то можно ограничиться разработкой на CMS для простых проектов, PHP для сложных. Этого будет достаточно для реализации абсолютного большинства задач, но такой узкий профиль добавит команде гибкости и взаимозаменяемости. Даже если с одним программистом что-то случится, его в короткие сроки может заменить другой.

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

Это документ, в котором специалист собирает все свои регулярные задачи, указывает их периодичность, описывает порядок и особенности выполнения каждой задачи. Даже если сотрудник перестанет выходить на связь, другой член команды сможет его заменить, следуя составленному «бизнес-процессу».

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

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

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

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

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

Давайте с себя тоже ответственность не снимать. Менеджер проекта тоже может стать источником форс-мажоров. Особенно это касается низкого качества проектной документации.

Бывает такое, что при составлении проекта была включена и утверждена функция, которая не может быть реализована. Или «конфликтует с другим функционалом», или сильно влияет на быстродействие продукта. Проблем может быть много. Сложно на этапе планирования предусмотреть все мелочи и нюансы.

К чему это приводит?

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

Риски есть в любом бизнесе. И IT — не исключение. Пренебрегая риск-менеджментом руководители постоянно будут наступать на «грабли» одних и тех же проблем. Оценка рисков и регламентация мер по их сокращению — одна из ключевых задач менеджера проектов.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России