Выступал в на осеннем ISDEF с докладом «управление рисками ИТ-компании», но это чересчур общее и не совсем точное название. Получилось рассказать про две вещи: почему об управлении рисками стоит задуматься; мой менеджерский опыт организации процесса управление рисками в проектах автоматизации и системной интеграции с крупными корпоративными заказчиками (то есть взгляд на проектные риски со стороны Исполнителя).

Введение

Вечером пятницы мы собираемся на дачу. Ближе к полуночи, а неделя выдалась непростой — командировки, мало сна. C дочкой загружаемся в машину. Я вовсю представляю картину успеха: на даче у камина потягиваю винчик. Камин выдумал, но остальное — часик и вполне материализуется. Дочка тормозит меня: папа, а ты же не выспавшийся и уставший. Она четко идентифицирует существенный риск: послушай, а не случится ли так, что ты уснешь за рулем и мы попадем в ДТП? И умело предлагает предупреждающие меры: Может не поедем? Или может тебе взять кофе?

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

В 2018 году на Байкальском риск-форуме услышал, что «главный риск-менеджер — первое лицо компании». Хьюстон, похоже у нас проблемы: оказалось мне есть чему поучиться в части управления рисками даже у моей 8-ми летней дочки. С этого тезиса начал пятничный доклад на осенней конференции ISDEF. Несовершеннолетних туда не пускали, поэтому доклад пришлось рассказывать не дочке, а мне.

Когда управление рисками стало на самом деле актуальным

В большинстве книжек об управлении проектами есть глава о рисках. Демарко в «Дедлайне» пишет: «чтобы управлять проектами, достаточно управлять его рисками». Опытные авторы в свои книги включают перечни ТОП-рисков. Я эти книги всегда рекомендовал, когда работал по найму и управлял отдельными проектами. Пройдя много проектов автоматизации и системной интеграции, имея за плечами годы опыта в ИТ — управление проектами в этой сфере не выглядело сложным. Как грамотный руководитель проекта (РП) я всегда мог объяснить Заказчику, почему что-то пошло не так, работы задерживаются (не по вине Исполнителя). Я обозначал актуальный план действий и давал обоснованный прогноз. Перед своим руководством, которое часто было недовольно срывом сроков больше внешнего Заказчика, я также всегда мог объяснить, что сыграли те самые фатальные риски из ТОП-а, от которых никто не застрахован.

Что общего у рисков в этих ТОП-ах? Они настолько глобальные, что воспринимаются как данность — это описание среды и окружающей нас действительности, в которой мы реализуем проекты. «Идентификация» таких рисков позволяет РП переложить ответственность на внешние факторы. Но реальная ответственность выпадает на того, кто расплачивается за последствия. Если РП и потеряет часть проектной премии (а не у всех компаний-подрядчиков премиальная система по проектам есть или увязана со сроками проекта), то все равно получает ЗП. Поэтому в конечном счете за срыв сроков платит собственник бизнеса (компании-исполнителя) из своего кармана, потому что недополученная прибыль именно у него. И когда такой собственник слышит об управлении рисками и смотрит на этот ТОП рисков — он как Фрай из Футурамы хватается за голову: «а мне-то что со всем этим делать?»

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

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

В проектах с внешними клиентами у нас было много факапов — сыгравших рисков. Страшные примеры:

• Сервера, выделенные под наш корп.софт, к которым клиент дал удаленный доступ, оказались зашифрованными вирусом. Благо вирус не проник в сеть клиента. Клиент обвинил нас; проведя свой аудит мы считали себя невиновными. Проект сильно съехал по срокам и нам пришлось нести ряд дополнительных расходов, чтобы все исправить и возместить «моральный ущерб».
• Наш консультант в кафе обсуждал детали намечающегося с клиентом контракта. Случайно оказавшийся в том же кафе конкурент всё услышал и в итоге контракт достался ему, мы потеряли проект.
• По нашей неточной рекомендации клиент закупил неверный системный софт, который в итоге не удалось вернуть. Формально мы за поставку не отвечали, но «осадок остался», пришлось доп. плюшками компенсировать «ущерб».

Много страшных вещей может произойти, последствия которых будут для нас ощутимы, существенны или даже фатальны. Для отдельного проекта. Для всей компании.

Так вот наступление этих событий мы планируем! Планируем — значит управляем. Суть управления рисками продумывания корректирующих действий прежде, чем возникнет проблема, пока она еще остается всего лишь абстракцией» (Том ДеМарко, Тимоти Листер, «Вальсируя с Медведями. Управление  рисками в проектах по разработке программного обеспечения», 2005). Подстелить соломку в тех местах, куда можем упасть.

Управление рисками — постоянно выполняющийся процесс. А задача главного риск-менеджера — ГД или собственника, если он вовлечен в непосредственное управление компанией, как я — привить культуру управления рисками. Чтобы каждый сотрудник как моя 8-ми летняя дочь наперед думал: что же может пойти не так, что помешает прийти к светлому результату и достичь прекрасных поставленных целей.

Отступление: Вопрос от слушателей: не помешает ли управление рисками совершению прорывов и достижению амбициозных целей? Не будет ли привитый коллективу образ мышления, сфокусированный на «риски» (проблемы), «тормозить» команду от вхождения в рискованные проекты? Не окажется ли, что «бойцы», которым нужно творить и «фигачить», будут дрожать и складывать лапки, пугаясь рисков проекта? Ответ обдумал пока писал статью: многие великие дела и фантастические результаты достигаются под девизом «слабоумие и отвага», (с) чип и дейл; но невероятно большее их число по этой же причине терпит неудачу. Успешные примеры людей и компаний, игнорировавших риски, это скорее «ошибка выжившего». К тому же управление рисками это не только про риски как проблемы, но и про возможности.

Сложности внедрения классического процесса управления рисками

Читаешь в книжках вроде PMBoK от PMI – все просто и понятно. Нужно выстроить несложный PDCA-процесс. На Хабре 10 лет назад написали просто и доступно о процессе управления рисками.

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

Когда заниматься управлением рисками

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

Вывод. Лучше встраивать риск-сессию как пункт повестки в те совещания, что уже есть в привычном расписании: общая планерка по компании/отделу, статус-совещания по проекту.

Как управляться с большим реестром рисков

В первый подход к управлению рисками собрали большой (70 штук) реестр проектных «рисков». Для проектов длительностью 3-6 месяцев с календарным план-графиком из 30 работ это прилично — все с энтузиазмом покреативили, придумывая выявляя риски. Риски записывали в формате «причина-риск-эффект», но в итоге получили неоднозначные записи — что риск в одной строке, причина или эффект в другой. Довести до понятного формулировками, однозначного реестра сходу не получалось, стали терять интерес.

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

Как выделить главные риски

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

Всё так, но дьявол как всегда в деталях:

• Что использовать для оценки? Числовые шкалы. Их не нужно делать сложными: не то что 100, но даже 10 это много. Потому что не очевидно, чем 8 отличается от 9. Шкалы от 1 до 5 достаточно, при этом смысл каждого значения шкалы нужно четко охарактеризовать. Чтобы всем было понятно, что такое 5 и что такое 1.
• Степень влияния рисков на что мы оцениваем? Расходы, прибыль, сроки, репутация, безопасность, ресурсы, качество. Единым знаменателем в конечном счете являются деньги. Решили оценивать влияние риска на денежный показатель — прибыль (проекта). Изменения сроков, трудозатрат в конечном счете влияют именно на прибыль.

Для каждого риска по данным шкалам оцениваем вероятность и влияние, сортируем реестр рисков по произведению этих оценок.

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

Кто оценивает риски

Оценку рисков не имеет смысл выполнять единолично руководителю или «выделенному человеку», нужно обязательно подключать команду. Зарисовка из жизни. Часто упоминаемый в статьях риск — «руководство затягивает принятие решений» — я изначально оценил как крайне маловероятный (вероятность — 2). Руководство это я, а я никогда не затягиваю принятие решений: напиши мне поздно вечером в мессенджере вопрос — отвечу, обратись за советом — всегда готов подсказать решение. Но пообщавшись с коллегами, оказалось, что они другого мнения. Я часто не согласовываю документы в срок, беру паузу на «подумать», откладываю решение и т.д. Причины такого поведения разные, но большинство сотрудников подтвердило факт: я не всегда быстро принимаю решения, часто затягиваю. Только коллективная оценка помогла понять, что это на самом деле высоко вероятный риск. См. видео на тему ловушек мышления в оценке рисков + набор карточек для запоминания.

Другая сторона медали оценки рисков — участвует весь коллектив, но при этом каждый оценивает самостоятельно. «Взакрытую», примерно как в planning pocker в scrum. Для того, что бы люди не привязывались к оценкам ранее проголосовавших (см. ту же подборку по ментальным ловушкам). Это добавляет сложности к организации процесса, так как через простой гугл-док с общим доступом оценки не соберешь. Можно попробовать в формате интерактивного опроса или гугло-форм, но если рисков много — создать каждый такой опрос будет трудоемко. Техническое решений удобства сбора оценок пока еще не придумали.

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

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

Резюме

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

Наша специфика

Если посмотреть на формулировку рисков из нашего ТОП-а, мы увидим практически такие же абстрактные штуки, с которыми «Фрай» еще в начале статьи не понимал, что делать. Риски по своей сути «причинны». То есть для того, чтобы управлять риском, нужно разбираться с его причинами. Причин у каждого риска может быть несколько. Значит по одному риску нужно выработать различные меры, нацеленные на разные причины.

Отступление: Выяснили, что основная причина одного из рисков ТОПе — я сам. У риска «нечеткая граница проектов» 2 из 3 причин — результат моих решений как руководителя.

Для каждой из причин стоит попробовать докопаться до «первопричины». На этом тезисе всем вспоминается техника «5 почему» и диаграмма «скелет рыбы», но на самом деле для анализа отдельного риска удобнее использовать диаграмму «галстук-бабочка» (bow-tie diagram): в центре — рисковое событие, слева иерархия причин, справа иерархия последствий. Можно отразить взаимосвязи внутри иерархий.

Напомню суть: заранее продумываем меры, предупреждающие возникновение риска меры и средства для снижения последствий. Что будем делать сейчас (для снижения вероятности или последствий) и что будем делать в случае наступления риска.

Итого, на такой диаграмме можно комплексно взглянуть на риск со всеми его причинами и последствиями. Определить не 1 предупреждающую меру, но продумать разностороннюю защиту. Сформулировать как будем справляться с каждым из последствий — как действовать в случае наступления риска (когда он уже превратился в проблему), чтобы уменьшиться последствия.

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

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

Отступление: Почему заказчик не любит внедрять SAP? Потому что SAP, пройдя за годы тысячи клиентов, заранее предусматривает огромное количество рисков — еще на уровне КП от интегратора начинается перенос риски с исполнителя на заказчика. КП от SAP что мне доводилось видеть идет в виде презентации, в конце которой 8 слайдов мелким шрифтом с заголовком «Допущения и ограничения».

С чем еще предстоит разбираться

1. Как прививать культуру управления рисками
2. Как использовать управление рисками в бизнес-планировании
3. Не только минимизируем риски-проблемы, но думаем и о возможностях