Джимшер ЧелидзеПроектное управление. Часть 3: управление рисками
Обновлено: 17 сент.
Проектное управление. Часть 1: введение и классические подходы
Проектное управление. Часть 2: гибкие методологии промежуточные итоги
Как думаете, в чем разница между новичками в управлении проектами и опытными руководителями?
В их акцентах.
Новички фокусируются на соблюдении формальных инструментов, а опытные руководители на рисках: пытаются выявить их как можно раньше и либо предотвратить негативные последствия, либо минимизировать стоимость устранения. Как мы писали в прошлой статье, наш фокус в управлении коммуникациями и раннем выявлении рисков от людей-экспертов в своей области.
А знаете почему опытные руководители так внимательно смотрят на риски?
Для ответа на этот вопрос надо изучить статистику и понять, как часто изменения или реализованный проект завершены невовремя, с превышением бюджетов или не достигли поставленных критериев успеха, каково среднее отклонение при реализации проектов?
Ну а затем необходимо разобраться, а какие есть инструменты для выявления рисков, как минимизировать эти риски, в том числе с помощью цифровых инструментов?
Также в качестве предисловия добавим, что большинство цифр ниже актуальны для ИТ и цифровых проектов, но они более чем подходят и для проектов в "классическом производстве", кардинальной разницы нет.
Содержание
Введение
И так, для начала давайте разберемся, а насколько глубока проблема? Какая доля проектов имеет проблемы или провальны?
Краткая версия доступна по видео, а полная далее в статье
Сначала предлагаем вспомнить нашу статью и на чем строится "проектный треугольник"
Если же обратиться к исследованиям Standish Group то мы получим, что успешны в среднем 30% проектов, а 70% проектов проблемные или провальные: имеют превышение сроков, бюджетов, не достигаются критерии успешности или вовсе закрываются до завершения.
Так, по ее исследованиям 1994 года (ссылка 1 и ссылка 2) доля успешных проектов была лишь 16,2%, а 2018 году таковых было около 29%. При этом примерно с 2000 года доля успешных проектов перестала увеличиваться, а после 2015 годов наоборот, появляется тренд на снижение.
Предлагаем ознакомиться с несколькими цифрами из исследований и презентаций:
1. Выступление Алексея Полковникова - председателя правления Российской Ассоциации Управления проектами СОВНЕТ, управляющий партнер группы компаний «Проектная ПРАКТИКА» (основан на отчете Standish Group)
2. Ну и отчет Standish Group 2018 года.
Также немного статистики из отчета по отраслям
При этом наиболее "проблемные" проекты самые дорогие и большие (если убрать из внимания продуктовые оценки)
И это логично, ведь если обратиться к той же модели Киневин, то чем крупнее проект, тем более неочевидные связи в нем, там банально больше "узких" мест и гораздо сложнее учесть все факторы, то есть чем больше проект, тем более гибким необходимо быть и больше прорабатывать вопросы рисков. И это подтверждается статистикой Standish Group.
Самые внимательные читатели тут могут задать вопрос: "Эй, тут противоречие с исследованием о статистике продуктового управления. Ведь менеджеры по продуктам как раз часто используют Agile практики. И в итоге продуктовые инициативы проваливаются чаще, а тут наоборот".
И он будет совершенно прав в своем возражении.
Но давайте вспомним, чем же отличаются проекты от продуктов? Об этом мы говорили в статье про управление продуктами. Кратко различие продемонстрировано ниже
В итоге менеджеры по продуктам работают с большей степенью неопределенности и на большем горизонте. И с одной стороны проекты внутри продуктовой инициативы могут быть успешными, но из-за глобальных ошибок продукт будет провальным или проблемным: неверные функциональные приоритеты, ошибки с маркетингом и позиционированием продукта, в общем причин множество.
Подтверждение тому тоже статистика Standish Group. Если мы говорим про ИТ-проекты и разработку программного обеспечения, то в итоге из всего перечня заложенных функций лишь 20% востребованы и используются часто, 30% - редко, а почти 50% - никогда. Отсюда рождается и еще более печальная статистика о успешности продуктов
А если копнуть в статистику стартапов и молодых компаний, то статистика еще печальнее - 90% закрываются в течение 3-х лет, а около 99% в течение 5-ти лет. Тут накладываются еще проблемы работы с инвесторами, формирования команды, выстраивания системной работы. О том, что такое системный подход в нашем понимании тоже инфографика ниже.
Так почему же, если говорить в рамках проектного управления, проекты по Agile более успешны? Причин множество, но не в последнюю очередь из-за подхода к планированию. В гибких методологиях мы отталкиваемся от доступных ресурсов - времени и бюджета. Мы рассматривали этот вопрос в нашей статье ранее.
Теперь же приведем разбор, а каковы последствия всех этих проблем? В среднем, согласно исследованиям того же Standish Group, ИТ-проекты имеют следующие отклонения:
превышают первоначальный бюджет в среднем на 50-60%
среднее превышение времени в проблемных проектах на 80-85% от плана
Все эти цифры сходятся и с нашими наблюдениями. Ну и относительно того, когда надо вносить изменения и почему опытные руководители стараются выявить риски как можно раньше - ответ на визуализации ниже
Теперь понятно, почему опытные руководители проектов делают упор на стадии инициации и планирования и могут отдать этим стадиям до 30-40% времени проекта.
И еще немного о факторах успеха проекта
А теперь просто подумайте, сколько из этих критериев можно закрыть работой с рисками, будь то на стадии планирования или реализации, проведения ревью по итогам проекта и обучением на собственных ошибках.
При этом, как показало недавнее исследование "Проектного управления в России 2022", проведенное руководителем проектного офиса СберМаркет Дмитрием Ирешевым, руководители проектов повсеместно используют инструменты планирования и всевозможные таск-трекеры. При этом из личных наблюдений можно сделать вывод, что культура постоянного совершенствования процессов планирования пока распространена не широко. Получается руководители проектов любят планировать, а вот учиться на своих ошибках, структурировать полученный опыт и повышать качество планирования - нет.
Основные виды рисков
Приведенная ниже классификация очень условная, но тем не менее позволяет понять, а "куда" смотреть, когда Вы занимаетесь самой сложной задачей - выявлением рисков.
Глобальные или системные риски:
Политические — изменение политической ситуации в стране и мире.
Природные риски. К ним относятся экологические катастрофы или стихийные бедствия.
Юридические — сюда входит как несовершенство существующих законов, так и риск появления новых, способных создать дополнительные проблемы для бизнеса.
Экономические — изменения в налоговой системе, санкции против государства, потери из-за нестабильности курсов валют и т. п.
Частные, или локальные риски:
Производственные - производственные и управленческие ошибки и ограничения, в том числе невыполнение плана продаж, сокращение объёмов производства.
Финансовые - недополучение прибыли от проекта, неликвидности продукции
Рыночные - нестабильность ситуации на рынке, например спрос, ценовая политика компании, конкурентная борьба
Немного более подробная классификация представлена ниже.
Общий алгоритм работы с рисками
Какие же есть основные документы, на которые можно опираться в работе с рисками?
Ключевым документом является ГОСТ Р ИСО 31000-2010
Вот главные схемы из него
Если же совсем упростить, то механизм работы с рисками внутри проекта на схеме ниже.
Основные типы рисков по областям управления проектами
Контрольный список общих проектных рисков:
Расписание проекта
Бюджет/финансирование
Кадровые вопросы (отсутствие руководителя и недостаточное количество сотрудников в группе)
Качество (несоответствие стандартам качества)
Взаимное согласие основных заинтересованных лиц (конфликты)
Изменения содержания проекта
Проектные планы (их согласованность и проработанность)
Методология управления проектом
Деловой риск
Управленческий риск (реорганизация, приводящая к изменению состава проектной команды)
Риски со стороны поставщика (задержка или отмена поставок)
Юридические вопросы - увеличение стоимости, отрицательный имидж
Политические риски - отрицательный имидж
Экологический риск
Погодные и природные катаклизмы
Технологические риски (нет в наличии необходимых составляющих).
Сложность проекта и квалификация персонала(недостаток компетенций у проектной команды и руководителя)
Как Вы уже наверно догадались, самое сложное в данном направлении - выявление перечня рисков и их оценка.
Возможные стратегии работы с рисками
Мы погрузились с Вами в тему, понимаем последствия и общий алгоритм, но какая может быть стратегия работы с рисками?
Исключение
Стратегия исключения предполагает полное исключение риска из проекта. То есть необходимо на "верхнем" уровне придумать действие, которое исключит саму вероятность реализации риска. Эта стратегия очень сложна и дорога для применения, а порой невозможна, так как может заставить отказаться от части ключевых работ или от всего проекта целиком.
Например, Вы работаете в сфере логистики и Вам необходимо исключить возможные простои груза. В итоге исключение этого риска может стоить настолько дорого, что доставка груза теряет всякий смысл.
Тоже самое и с разработкой и внедрением ПО. Вы можете исключить риски изменения запросов Заказчика жесткой фиксацией требований в контракте. Но вот гарантирует ли это успех проекта в целом, а главное согласен ли клиент будет на такие условия?
Минимизация
Это наиболее распространенная стратегия. Её задача - заранее проработать риск и минимизировать вероятность его наступления и/или тяжести последствий.
Давайте снова разберем на примере логистики. Можно ли снизить до нуля риск поломки машины в пути? Конечно нет, но что можно сделать для минимизации этой вероятности? Например организовать своевременное техническое обслуживание, оформить топливные карты с сетевыми заправками, чтобы водитель не заливал некачественное топливо, ориентируясь на низкую цену.
И второй пример еще раз разработка ПО?
Возможно ли полностью исключить ситуацию, когда клиент изменит пожелания? Тоже нет. Но что, если мы на ранней стадии проведем обследование, расскажем клиенту о том, как мы видим решение задачи с учетом нашего опыта, опишем возможные альтернативы и совместно с Клиентом выберем оптимальный вариант до начала работ. В итоге мы не исключили риск полностью, но мы минимизировали вероятность его наступления и возможные последствия, ведь Вам теперь вряд ли придется все переделывать, а лишь скорректировать некоторые детали.
Да, это сложный вариант, не все Клиенты готовы думать и слушать, но и вступать в заранее опасные проекты может оказаться слишком рискованным мероприятием. Стратегия "продай любой ценой" в итоге всегда проигрышна.
Принятие
Здесь все просто - до наступления риска предполагается «ничего не делать». Однако совсем ничего не делать – это не управление рисками. Тут есть 2 варианта – активное и пассивное принятие.
Активное – формируется резерв времени и денег на устранение последствий материализации риска. Так, самое распространенное правило для более менее понятных проектов - заложи резерв 30-35% на различные форс-мажоры и непредвиденные расходы. Но здесь 2 ограничения:
все равно необходим опыт руководителя, чтобы он заранее мог корректно оценить сроки и стоимость, количество пропущенных условий и их потенциальное влияние;
необходимо вести переговоры с Клиентом, ведь чем больше запас у Вас, тем лучше Вам, но хуже ему.
Пассивное – наличие плана Б (устранения последствий проблемы) на случай, если риск материализуется, в котором руководство проекта и его команда будут решать проблемы из-за этого риска собственными силами по мере их поступления.
Это хорошая стратегия для использования при очень небольших рисках, которые не окажут большого влияния на проект, если они произойдут. При этом разработка альтернативной стратегии управления рисками и проработка дополнительных может оказаться чрезмерно долгой и дорогой, что может поставить под угрозу весь проект.
Делегирование
Эта стратегия перекладывает последствия материализации риска и ответственность за реагирование на 3-ю сторону, при этом сам риск не устраняется. Эта стратегия практически всегда предполагает финансовые затраты на передачу и получение финансовой компенсации в случае материализации риска.
Типичный пример - страхование. Мы перекладываем свои риски на страховую компанию. Которая, если риск, например повреждение груза во время шторма, выплатит Вам все неустойки. Но за это все она берет премию.
Ну или, если на примере разработки ПО, можно заключить договор с консалтинговым агентством, чтобы они изначально провели обследование клиента и подготовили все требования. А если в процессе требования изменятся, то они оплатят все переработки Ваших людей и все судебные претензии клиента. Но это из области фантастики, вряд ли кто-то согласится на такие условия, или цена контракта с консультантами станет такой, что уже Ваш клиент откажется от проекта.
Выявление / идентификации и оценка рисков
Выявлять, или идентифицировать риски можно через несколько ключевых подходов:
ретроспективный анализ
анализ текущего проекта
анализ возможных событий
Далее мы чуть подробнее рассмотрим основные инструменты в рамках данной классификации Если Вам будет интересно погрузиться в какой-либо глубже, то будут полезные ссылки на подробные статьи
Ретроспективный анализ прошлых проектов
Здесь Вы можете анализировать прошлые проекты компании, ну если у Вас есть такой архив, где есть планы и история реализации, и, если повезет, ретроспектива проектов, с историей сработавших рисков и предпринятых мер.
А если ведется системная работа (правда мы такого практически не встречали) в компании могут быть контрольные листы рисков.
Ну и финальное в этом блоке - анализ лучших практик. Если Ваш проект не является запутанным, с неочевидными связями, то можно изучить лучшие практики реализации аналогичных проектов или использовать чек листы
Анализ текущего проекта
Тут изучаем входную информацию о текущем проекте и качество проектной документации:
насколько проработано техническое задание и критерии успешности, продукт проекта, границы. Есть ли у этих атрибутов измеримые показатели;
проработаны ли допущения, оценена ли техническая возможность реализации проекта и необходимость в доработках типового решения, имеются ли в команде проекта все необходимые специфичные / технические компетенции;
есть ли карта стейкхолдеров, оценено ли их влияние и план работы с ними
есть ли поддержка от первых лиц
насколько проработаны планы реализации и их согласованность, определена потребность во внешних поставщиках и есть ли опыт работы с ними.
В общем все, что должно быть проработано на стадиях инициации и планирования. Тут все доступно в том же PMBoK.
Анализ возможных событий
Это самое сложное направление, где применяются сложные математические и экспертные подходы: SWOT, мозговые штурмы, метод сценариев, интервью, диаграммы Ишикавы и влияния, деревья отказов и перечни подсказки (PESTLE, SPECTRUM, TECOP), а также всевозможные методы моделирования.
SWOT-анализ
SWOT-анализ — метод стратегического планирования, для оценки внутренних и внешних факторов, которые влияют на развитие компании. SWOT-анализ нужен, чтобы оценить сильные и слабые стороны компании и определить перспективы развития и угрозы извне.
S – Strengths (сильные стороны),
W — Weaknesses (слабые стороны),
O — Opportunities (возможности),
T — Threats (угрозы).
Плюсы
универсальность
применим в самых разнообразных сферах экономики и управления. Его можно адаптировать к объекту исследования любого уровня (продукт, предприятие, регион, страна), использоваться и для оперативного, и для тактического, и для стратегического планирования.