Каталог решений - Риск — благородное дело!.. Часть вторая

Совет №2. Предсказывайте риски до того, как пациент умрет, а не после — Продолжение разговора… 

В комментариях к первой части статьи про риски меня попросили раскрыть "Совет №2" подробнее. Попробую это сделать здесь.
Почему я искренне люблю технику "PreMortem" и стараюсь ее применять в начале любого проекта или какой-либо другой инициативы?… Дело в том, что она помогает справляться с прекрасно известной многим менеджерам болезнью "Избирательная близорукость".
Как рассказывают Том ДеМарко и Тимоти Листер в книге "Вальсируя с медведями” (кстати, активно рекомендую эту книгу всем, кто хочет проработать свои навыки управления рисками) в разделе с говорящим заголовком  "А, вы имеете в виду этот приближающийся поезд!": 

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

Очень часто "избирательная близорукость" проявляется и усиливается в ситуации, когда уровень взаимопонимания и доверия между руководителями и командой проекта недостаточен… Отсюда стратегии поведения, подобные описанным в той же книге действиям, предшествующим провалу:

Я сразу понял, что если у него нет плана предотвращения риска, он такой риск просто игнорирует. 

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

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

Развитием техники “PreMortem” можно считать “Стратегию творчества Уолта Диснея”, которая является, по сути, сочетанием техники PreMortem и мозгового штурма.

В ходе этой техники участникам предлагается по-очереди примерить три разные “шляпы”:

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

Во время ролевой игры участники могут циклически изменять свои роли и продолжать обсуждение проблемы до тех пор, пока решение не будет найдено.
Рекомендуется, чтобы разные роли размещались на разных местах в пространстве — то есть команда физически перемещалась от “стола мечтателей” к “столу реалистов”, к “столу критиков” и обратно. Как нетрудно догадаться, основное место формирования “позитивного настроя” — это “стол мечтателей”. А основное место выявления рисков — это “стол критиков”, помогающий наиболее надежно спуститься “с небес на землю”.  

Совет №4. Управление рисками должно идти планомерно от начала и до конца проекта

А если быть точным, то начинаться еще ДО того, как мы приняли решение ввязываться в тот или иной проект. И заканчиваться ПОСЛЕ завершения проекта передачей информации.
На своих вебинарах и в статьях я неоднократно рассуждала о сочетании умений “быть” (то есть реально делать работу) и “казаться” (то есть пускать пыль в глаза и производить нужное впечатление). Так вот, также как и во многих других сферах, когда управлением рисками занимаются в первую очередь с целью “казаться”, толку с этого, как правило, нет практически никакого. Что я имею в виду?…
В первую очередь, ситуации, когда реестр рисков составляется “для галочки”. Честно скажу, в моей практике были ситуации, когда меня просили, например, “пришлите примеры рисков для подачи документов на 1С:Руководитель проектов”. В чем будет ценность этого списка рисков для руководства реальным проектом? Да ни в чем практически. Здесь единственная цель — произведение впечатления.  А на самом деле, все внедрения очень разные, и все риски индивидуальны, и в разных ситуациях они различаются в первую очередь степенью влияния и вероятностью.

Вот, в частности, примеры нескольких внедрений из моего опыта, когда ключевыми рисками были совсем разные:

• Разгильдяйство ведущего руководителя
• Некомпетентность компании внедренца
• Недостаточная включенность и непонятный статус лица принимающего решения (по сути, было два владельца продукта: номинальный и фактический)
• Недостаточно качественное проведение предварительного исследования
• Неполное выявление требований
• Досрочное прекращение финансирования в связи с утерей интереса к проекту
• (Можете продолжить список по своему опыту и усмотрению)

Совет №5. Закладывайте резервы в бюджет и расписание

Типичный план проекта строится исходя из оптимального развития событий. А ведь на самом деле, давно известно, что ни один план сражения не выдерживает столкновения с противником (это утверждение приписывается фельдмаршалу Хельмуту фон Мольтке, одному из основателей Германской империи). И основной практический смысл управления рисками, по моему опыту, состоит как раз в том, что по итогам обсуждения рисков в «красивый» график добавляются временные, денежные и кадровые резервы на случай, что что-нибудь пойдет не так.
В бытность мою руководителем проектного офиса на НПК, мне приходилось корректировать производственные планы. Смотрю я на стройный план-график, и вижу, что согласно нему предполагается изготавливать каждый новый опытный образец за 4 месяца. Нет, действительно, если посмотреть на технологический процесс – то как раз работа должна занять ровно 4 месяца, если не меньше. Но, как вы уже, наверное, помните, проблемы прошлых проектов – это входные данные в процессы управления рисками проектов будущих. И суровая действительность показывает, что в экспериментальном производстве обязательно что-нибудь, да пойдет не так – либо с качеством оптики возникнут проблемы, либо с герметичностью, либо со стыковкой компонентов… Ну, в-общем, средний срок — около полугода, если все достаточно гладко пройдет. Интересуюсь у автора плана: "А были ли случаи в вашей практике, когда опытный образец действительно был готов за 4 месяца?" На что мне следует сакраментальный ответ "Пока нет. Но мы будем стараться!".

В чем назначение такого плана? Произвести впечатление на начальство. Подготовить план "для галочки". Скорее "казаться", чем действительно "быть". Никто из участников не верит в осуществимость этого плана, и реальная его ценность, увы, невелика…
А как правильно, спросите вы?
В инструкциях и стандартах по управлению рисками, как правило, пишут красивые слова – мол, интегрируйте планирование управления рисками с другими процессами планирования.  Что из этого следует на практике? Вот составили вы предварительный план работ, прикинули график, бюджет, требуемые ресурсы. Потом сели инициативной группой и стали обсуждать, какие у вас есть риски – положив перед собой как раз вышеупомянутые графики и планы. И по итогам этого обсуждения исчеркали красным маркером все ваши планы. В список работ добавили работы, направленные на превентивное предупреждение выявленных рисков, в график заложили дополнительное время на случай, если что-то пойдет не так, в бюджет – аналогично, добавили резервы, в список ресурсов – тоже добавили изменения, чтобы какое-никакое, но дублирование у вас было… По моему опыту, основной смысл работы по выявлению рисков как раз в том и состоит, чтобы вы ваши первоначальные планы скорректировались. И если этого не произошло — посидели, поговорили о рисках, разошлись — то смысла в таком планировании не было. 

Возникает хитрый практический вопрос у тех, кто реализует внешние проекты — а как объяснить риски заказчику, ему ведь дела нет до сложностей проектной команды? Непростой вопрос. Ну, во-первых, чем выше уровень доверия, взаимопонимания и включенности заказчика, тем в большей степени он прислушается к тому, что риски есть и они неизбежны. И вообще, открытая и честная коммуникация — наше всё (по тем вопросам, по которым она целесообразна). Во-вторых, внутренние риски, которые заказчика совсем не касаются и обсуждать их с ними не стоит категорически ("а вдруг наш ведущий программист опять уйдет в запой") можно компенсировать за счет разницы между ставкой специалиста для клиента и внутренней ставкой. В-третьих, желательно не оказываться перед необходимостью делать проекты в условиях жесткого демпинга — на деле это оказывается себе дороже. 

Что почитать на тему рисков не отходя далеко от Инфостарта?

• Базовую книжку я уже рекомендовала: Тимоти Листер, Том ДеМарко. Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения.

Теперь на Инфостарте.  

• Первую половину статьи про риски я тоже уже упоминала
• Иван Селиховкин публикует на Инфостарте видеокурс по управлению проектами. В том числе рассказывает про управление рисками. На мой взгляд общие принципы даны достаточно толково – хотя, возможно, курс чересчур уклоняется в теорию, и мало затрагивает практику.
  Но инструменты – как-то реестр рисков, светофорная матрица и т.п. – разбирает довольно подробно. Можно по указанному Иваном алгоритму смело идти – и всё получится!..
• В рамках курса «Управление ИТ-проектами» мы разбираем тему рисков – особенно подробно во втором модуле, по классическим подходам – там целая тема (видеолекция+вебинар+наглядные материалы) будет посвящена рискам. Ну, а в третьем модуле мы поговорим про управление рисками по Agile (да и вообще, весь Agile это, по сути, способ снизить риски больших проектов, дробя их на маленькие кусочки). Присоединяйтесь!

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах