В главе 1 отмечалось, что управление рисками — это процесс систематической идентификации, анализа и реагирования на риски, связанные с проектом. Ключевым словом здесь является систематический, поскольку многие руководители проектов пытаются работать с рисками без соблюдения соответствующих норм и формальностей, не уделяя планированию этой работы достаточно внимания, а то и вовсе игнорируя его. Это верный способ призвать на свою голову неудачу, если не катастрофу. Нормальный комплексный план по рискам проекта позволяет руководителю занимать активную позицию, если что-то пойдет не так. Без этого плана ему придется реагировать на те или иные сбои в проекте по ходу дела, а это самый дорогой из возможных сценариев. Системность придает работе порядок и эффективность. В конце уже были сжато изложены важнейшие пункты работы по противодействию рискам проекта. Здесь эта тема раскрыта более подробно.
Управление рисками проекта начинается на самом раннем этапе его жизненного цикла. Должно быть выработано ясное понимание возможных рисков. Источники рисков практически бесчисленны, что только подчеркивает необходимость хорошо продуманного и детального плана работы с ними. Типичные примеры — уход из команды ключевого участника, погодные катаклизмы, сбои в работе техники и плохое обеспечение ресурсами.
Многие руководители проектов затягивают с оценкой рисков и откладывают разработку плана их управления, полагая, что многих деталей проекта они еще не знают и в нем много неизвестных факторов. Это известная западня, которой следует остерегаться. Еще на фазе инициации жизненного цикла проекта необходимо осуществить общую первичную оценку рисков. Руководитель проекта и члены команды должны со стратегической точки зрения ответить на вопрос «Что может пойти не так?» и заложить основу детального плана соответствующих действий. Без такого основания проекты часто подвергаются негативному воздействию рисков, которые неожиданно становятся реальностью, хотя их можно было предотвратить или вообще устранить, имея планы на случай непредвиденных ситуаций. Такой подход характеризуется как реактивно-пассивный, то есть лишь реагирующий на возникший раздражитель, тогда как успешный руководитель проекта должен занимать проактивную, наступательно-опережающую позицию. Иногда в ходе проекта возникают и потенциальные возможности — «позитивные риски», которые руководитель проекта должен использовать для достижения целей проекта.
В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) управление рисками проекта определяется в качестве одной из областей знаний. PMBOK описывает управление рисками проекта как «процессы, связанные с планированием управления рисками, идентификацией, анализом, планированием реагирования, а также с мониторингом и контролем рисков в проекте» (PMBOK, 555). Таким образом, эти процессы нужно понимать как строящиеся по заданным правилам и контролируемые мероприятия, не допускающие вариаций или допускающие их в минимальной степени. Применительно к процессам проекта вариации обычно равнозначны неэффективности. Важно управлять рисками правильно, хотя с учетом реальностей и переменных в типичной среде проекта какая-то степень гибкости, конечно, возможна. По мере накопления опыта в управлении рисками у вас начнет развиваться интуитивное ощущение возможных пределов этой гибкости в зависимости от типа, продолжительности, объема, глубины и широты проекта.
«Процесс в шесть шагов» — это распространенный практический метод разработки плана управления рисками проекта. Он не должен осуществляться в вакууме, обычно опирается на аналитическую работу и требует тесного взаимодействия всей команды проекта.
Мозговой штурм. Составление списка потенциальных рисков проекта не должно носить характер аналитической разработки; нужен настоящий мозговой штурм, когда подхватываются на лету все идеи. Шаги 2 и 3 позволяют подробно рассмотреть их. В идентификацию потенциальных угроз и того, что может пойти не так, важно вовлечь всю команду. Некоторые руководители проектов пытаются проделать эту работу самостоятельно, чтобы дать членам коллектива возможность выполнить другие задачи. Это близорукий и вредный подход. Начальный шаг должен осуществляться в атмосфере тесного сотрудничества и включать в себя всех членов команды, являющихся специалистами в своих сферах и отвечающих за свои части проекта. Максимально задействуйте интеллектуальный капитал всей команды. Если за пределами такого мозгового штурма окажется хотя бы один член коллектива, весьма вероятно, что часть рисков останется неидентифицированной и успех проекта будет под угрозой. Помните, что нужно вовлекать всех: специалисты по закупкам (снабженцы) не помогут определить возможные проблемы разработки программного обеспечения, а программисты — проблемы с закупками.
Работая с широкой неформальной командой, нужно понимать, что, прежде чем двигаться вперед, многое придется дополнительно выяснять самому по телефону, имейлу, видеосвязи, при личном общении. Для получения нужной информации хороши любые методы. Диалог о том, что в проекте может пойти не так, лучше начинать с формально не сформированной группой участников и членов команды проекта. Обычно при этом выявляются полезные лица, контакт с которыми может пригодиться. Особенно важны менеджеры функциональных подразделений, которые назовут своих сотрудников, способных помочь вам.
В любом случае при составлении списка возможных рисков следует проявить как можно более широкий подход, поскольку должно быть идентифицировано максимальное число рисков и возможное противодействие им.
Я объединяю шаги 2 и 3, поскольку они оба связаны с классификацией рисков по приоритетности. Они помогают расставить риски в порядке очередности и определить, сколько времени, усилий, человеческих ресурсов и денег следует направить на предотвращение каждой из идентифицированных угроз или на смягчение ее негативных последствий. Это также следует осуществлять с полным участием членов команды и привлеченных экспертов по предметной области (Subject Matter Experts, SME).
Насколько вероятно, что каждый из идентифицированных рисков станет реальностью? Этот вопрос надо и задавать, и отвечать на него. Часто достаточно использовать шкалу вероятности «Высокая — Средняя — Низкая» и применить соответствующий показатель к выявленному риску. Если вероятность риска высока, его помечают литерой «В»; если вероятность средняя, он получает обозначение «С»; если же низкая — «Н». Эти показатели не должны присваиваться рискам произвольно. Необходимо энергичное сотрудничество всей команды и активная аналитическая и исследовательская работа руководителя проекта для их правильного определения.
Если риск становится реальностью, насколько сильный ущерб проекту он может нанести? Это еще один вопрос, который надо задавать и на который надо отвечать. При оценке ущерба проекту необходимо внимательно оценить все аспекты. Если риск по проекту материализуется, то как он повлияет на бюджет, расписание, распределение ресурсов, содержание работ и т. д.? Результаты шагов 2 и 3 подводятся в схеме потенциальных рисков с соответствующими вероятностями их материализации и уровнем негативного эффекта, оказываемого на проект.
Риск | Вероятность его материализации | Негативный эффект |
А | С | Н |
Б | С | С |
В | Н | Н |
Г | В | В |
Исходя из приведенной в этой таблице оценки рисков в проектах А—Г ясно, что руководителю проекта необходимо сконцентрировать усилия на нейтрализации рисков в проекте Г, меньше внимания уделить рискам по проекту В. Однако помните, что вы можете ошибаться (к сожалению, когда я был молодым управляющим проектом, мне об этом напоминали часто). Если вы оцениваете реальность риска как низкую и так же низко — возможный негативный эффект от него, то это еще не дает никаких гарантий. Продолжайте внимательно отслеживать ситуацию.
Тем, кто предпочитает количественные оценки, можно предложить простую таблицу. Реальность риска и его негативный эффект оценивайте в цифровых показателях. Шкалу вероятности можно установить в пределах от 1 до 10. При этом 1 будет означать самую малую вероятность, а 10 — самую высокую. Негативное воздействие можно оценить по той же шкале или прямым ущербом для бюджета проекта.
Риск | Вероятность | Ущерб, $ | Итого, $ | ||
А | 3 | × | 1000 | — | 3000 |
Б | 7 | × | 1000 | — | 7000 |
В | 2 | × | 14 000 | — | 28 000 |
Г | 5 | × | 3000 | — | 15 000 |
В соответствии с данными таблицы главное внимание команды должно быть направлено на проект В из-за высокой стоимости риска по нему: $28 000. По тому же принципу можно определить негативный эффект для графика или распределения ресурсов.
Одни риски удается предотвратить, последствия других можно только минимизировать. Например, землетрясения или уход в отставку важного заинтересованного лица предупредить нельзя. Но некоторые риски могут и должны быть предотвращены с помощью шага 4. Если вы идентифицировали риск и имеете возможность не допустить его, делайте это. Активность и наступательность — лучшие союзники руководителя проекта. Ликвидируйте риск до того, как он получит возможность роста и развития. Тогда вам не придется иметь с ним дела в дальнейшем.
Например, если проект предусматривает деловые отношения с каким-то поставщиком материалов или других ресурсов, а один из членов вашей команды имеет негативный опыт работы с ним, он сообщит, что тот нарушает сроки и не выполняет свои обязательства качественно. Наверняка данный поставщик не единственный и вы сможете предотвратить риски, найдя альтернативного, с более надежной репутацией.
Необходимо пытаться минимизировать возможный ущерб тех рисков, предотвратить которые нельзя. Если использовать тот же пример с ненадежным поставщиком, нужно стараться заблаговременно активно повлиять на поставки материалов, тем самым снижая возможные риски. Если руководство угрожает понизить приоритетность вашего проекта, можете провести лоббирование, чтобы уменьшить такую вероятность.
Превентивные меры — это действия, которые предпринимаются до того, как риски становятся реальностью. Меры на случай непредвиденных ситуаций — действия, производимые при материализации рисков. Разрабатывая эти меры, вы отвечаете на вопрос «Что делать, если риски станут реальностью?».
Например, если приемочные тесты приложений или информеров от вашего поставщика показали, что существует высокий или средний риск и его виджеты часто дают сбои, меры на случай возникновения непредвиденных ситуаций могут предусматривать техническую поддержку за счет поставщика. Другим решением является переключение на другого заранее подобранного альтернативного поставщика.
Превентивные меры на случай чрезвычайных ситуаций связаны с факторами приоритетности, показанными в шагах 2 и 3. Если риск высок (высока его вероятность и велик возможный негативный эффект), следует предусмотреть ряд альтернативных мер. Поскольку в этом случае высока вероятность материализации риска и нанесения ущерба проекту, вы сможете себя обезопасить. Если риск оценивается вами по шкале-классификатору как средний, нужно иметь в запасе хотя бы одну превентивную меру. Риски, которые располагаются внизу шкалы и относятся к низким, обычно не требуют много внимания. Вам лучше сосредоточиться на чем-то другом. Разрабатывая меры на случай чрезвычайных ситуаций, обращайте внимание на риски, у которых низкая вероятность, но которые потенциально грозят большим ущербом. Их часто недооценивают из-за низкой вероятности материализации, но они способны полностью погубить проект.
Точка пуска нередко является важнейшим элементом плана рисков проекта. Между этой точкой и «запуском» чрезвычайных мер существует прямая связь. Как отражено в самом названии этой точки, она определяет некую границу, за которой риск становится достаточно реальным для того, чтобы руководитель проекта задействовал чрезвычайные меры. Это трудное решение должно обеспечить эффективность заранее продуманных чрезвычайных мер, если они будут осуществлены в оптимальное время. Активируйте «точку пуска» слишком рано — и вы, скорее всего, потратите время, усилия и средства впустую. Определите эту точку слишком поздно — и риск может материализоваться в худшем своем проявлении. При этом план на случай чрезвычайной ситуации уже не сработает. Однако вернемся к нашему примеру.
Если у надежного поставщика возникли проблемы с персоналом и он вынужден был остановить производство из-за забастовки, то, скорее всего, у вас на такой случай предусмотрены альтернативные поставщики Б и В. У каждого имеются на складе нужные вам устройства, и каждый поставил условие, что ему необходимо две недели для поставки. Если устройства нужны к 15 февраля, «точка пуска» даст вам эти две недели плюс-минус несколько дней. Значит, оптимальной «точкой пуска» будет 31 января. Если меры на непредвиденный случай приходятся на особо сложный период исполнения проекта, необходимо предусмотреть возможность прибавить еще несколько дней.
«Точка пуска» должна быть либо определенной точкой, либо согласованным отрезком времени. Большинство руководителей проектов рассматривают «точки пуска» как самый деликатный момент в планировании управления рисками проекта. Однако они стоят затрачиваемых усилий. Как консультант я часто сталкиваюсь с хорошо продуманными планами управления рисками, которые проваливаются из-за несвоевременного применения чрезвычайных мер или отсутствия таковых. «Точка пуска» включения чрезвычайных мер должна стать для руководителей проектов важным элементом, который улучшает эффективность управления рисками в целом.
Самый полный план управления рисками проекта окажется ничтожным, если в нужный момент у вас не найдется времени или средств, чтобы принять необходимые меры. Создание резервов позволит вам использовать полный потенциал вашего плана. Самые хорошо составленные планы часто оказываются недейственными, если в них не предусмотрено достаточно времени и средств для исполнения. Таким образом, любой руководитель проекта должен предусмотреть резервы для чрезвычайных ситуаций и управленческие резервы.
Резервы для чрезвычайных ситуаций — это запас времени и средств, позволяющий реагировать на риски, которые идентифицированы и приняты. Эти резервы создаются для того, чтобы покрывать известные риски. Между резервами для чрезвычайных ситуаций и «процессом в шесть шагов» (или другим подобным подходом) существует прямая связь. Когда процесс из шести шагов завершен, руководитель должен оценить резервы, необходимые для покрытия идентифицированных и признанных рисков.
Так, если команда проекта идентифицировала как высокий (по вероятности и возможному ущербу для проекта) риск утраты ключевого члена команды в связи с его уходом на пенсию, чрезвычайные меры потребуют подбора и принятия на работу его дублера из другой организации. Влияние этого процесса на расписание и стоимость проекта, а также нужное для нового игрока время на адаптацию в команде должно быть оценено и заложено в резерв для чрезвычайных ситуаций.
Управленческие резервы создаются для покрытия неизвестных рисков по проекту. Иногда вы действительно не знаете того, чего не знаете. Например, если ваш текущий проект включает в себя большие объемы научно-исследовательских и опытно-конструкторских разработок (НИОКР), а анализ исполнения подобных предыдущих проектов показывает среднее превышение сметы по ним на 10%, то эти 10% не могут быть отнесены ни к какому рисковому событию. Однако такая информация диктует необходимость увеличить общий бюджет проекта на 10% в качестве управленческого резерва.
Многие, если не большинство, руководителей проектов однажды обнаруживают, что управляют более чем одним проектом. Руководитель нескольких проектов обычно сталкивается со специфическими проблемами, которые не знакомы менеджерам одиночных проектов. В мультипроектной среде один проект часто накладывается на другой или зависит от другого, как это происходит в обычной сетевой схеме (см. и ).
Здесь требуется двусторонний подход. Во-первых, вы должны сконцентрироваться на каждом отдельном проекте и оценить риски каждого из них. Затем нужно оценить весь свой портфель проектов и определить взаимоотношения между всеми его составляющими. Ваш портфель — это совокупность всех проектов под вашим управлением. Отношения между этими проектами могут быть очень разными.
Программа — это обычно ряд связанных между собой проектов, направленных на достижение единого результата. Все проекты должны быть правильно интегрированы для достижения этой единой цели.
В портфеле проектов вы должны четко идентифицировать те сферы, где пересекаются работы по каждому проекту, затем определить, что может пойти не так в тех областях, где проекты «соприкасаются».
Что касается программы проектов, в ней взаимоотношения между проектами определены более точно. Например, в программу легкой атлетики входит эстафета, в которой четыре бегуна должны передать друг другу эстафетную палочку. Самая быстрая команда выигрывает не всегда, потому что в передаче эстафетной палочки бывают ошибки и ее могут даже уронить. Многие проекты в программах имеют отношения типа «предшественник — последователь» (один проект должен быть завершен до того, как начинается новый). Для того чтобы обеспечить плавный переход от одного проекта к другому, необходимо уделять всемерное внимание процессу «передачи эстафетной палочки». План управления мультипроектными рисками как раз концентрируется на таких событиях.
В любом мультипроектном варианте точки соприкосновения проектов называются точками координации. Они должны быть идентифицированы, после чего создается план управления мультипроектными рисками. «Метод шести шагов» в данном случае применяется только по этим сферам соприкосновения. Вы сначала составляете план управления рисками для каждого отдельного проекта, а затем обращаете внимание на точки соприкосновения и повторяете весь процесс вновь, но уже в отношении мультипроектных рисков. План управления рисками портфеля или программы проектов подразумевает дополнение и усиление планов управления рисками отдельных проектов в общей мультипроектной среде.
Действенным инструментом управления рисками является стандартная матрица рисков (рис. 6.1). Она поможет расположить проекты в квадратах в соответствии с вероятностью наступления рисков и их негативным воздействием.
Рис. 6.1. Матрица рисков
Разместив потенциальные угрозы в квадратах матрицы, классифицируйте их по показателям «высокий — средний — низкий». Риски с высокой вероятностью материализации разместятся в верхней правой части матрицы, а с низкой — в нижней левой. Каждому риску в каждом отдельном проекте можно присвоить свой код. Это очень эффективный метод в сложной системе управления портфелями и программами.
Эффективным инструментом управления рисками проектов является также реестр рисков (табл. 6.1).
Таблица 6.1. Реестр рисков
Источник: семинар Американской ассоциации менеджмента «Повышение навыков управления проектами: основа успеха».
Реестр рисков, последний компонент в инструментарии управления рисками проекта, — живой, динамичный механизм, который поможет отслеживать статус рисков, пока ваш проект развивается в своем жизненном цикле. Реестр рисков также позволяет определять ответственных за проведение акций, совершаемых в непредвиденных и чрезвычайных ситуациях, результаты этих акций, а также активные и латентные риски.
Если не сделан тщательный анализ существующих рисков, то и вы как руководитель, и ваша команда окажетесь в атмосфере пассивного реагирования на возникающие угрозы, борясь с пожарами на протяжении жизненного цикла проекта. Такой подход требует наибольших затрат времени, усилий и средств и ставит под угрозу успех любого проекта. С самого начала руководитель должен приложить все усилия к правильной организации этого ключевого элемента всего проекта.
Проводя семинары по проектному менеджменту, я прошу слушателей идентифицировать трудности, с которыми они могут столкнуться при управлении проектами.
Очень часто они называют коммуникации проектов или их отсутствие. Хорошо, что большинство руководителей проектов понимают, насколько важны коммуникации для успеха предприятия. Однако обескураживает тот факт, что мало кто из них принимает конкретные меры для улучшения ситуации.
Начнем с электронной почты. Да, мы до сих пор проводим совещания, звоним заинтересованным сторонам проекта по телефону или лично встречаемся с членами своей команды. Однако сегодня в коммуникациях проектов доминирует электронная почта. Большинство из нас смирилось с этим. Электронная почта прочно вошла в нашу жизнь, позволяя моментально связываться с адресатом на другом конце планеты или в другом конце зала совещаний. Она дает возможность выстраивать наши ответы по их приоритетности, а в случае необходимости — создавать и бумажную «нить» общения. Все это хорошо, но по своему опыту я заметил, что мы еще не полностью освоили все возможности этой технологии и не научились максимально использовать ее потенциал.
Разве вам не приходилось получать электронные сообщения на пяти машинописных страницах с бесчисленными параграфами? Некоторые сообщения напоминают новеллы, посвященные любимым. И наоборот, некоторые имейлы из трех слов оставляют адресата в недоумении по поводу того, что же хотел сказать отправитель. Такую манеру использования электронной почты я называю «коммуникациями Дикого Запада». В ней не существует никаких правил, законов или норм. Электронные коммуникации по проекту зависят от вкусов и привычек отправителей и получателей. Это оставляет впечатление «свободного полета мысли» и никоим образом не сочетается со средой проекта, в котором есть строгие ограничения по содержанию, расписанию и расходам.
Создайте отдельный порядок электронной переписки и следите за тем, кто и с кем поддерживает связь по проекту. Уточняйте, какие электронные сообщения должны поступить конкретной заинтересованной стороне проекта. Разработайте рекомендации сотрудникам по тому, кого ставить в копию сообщений. Разве не приходилось вам вернуться из отпуска и обнаружить в своей электронной почте 500 копий писем, большинство которых не имело отношения ни к вам, ни к вашему проекту? Просматривать их не просто утомительно — они отнимают много времени. Соберите команду и с ее участием создайте порядок электронной переписки по проекту. Этим вы реально повысите эффективность коммуникаций проекта и встретите понимание со стороны членов коллектива.
Несколько рекомендаций руководителям проектов и членам команды по использованию электронной переписки по проекту.
План управления коммуникациями проекта должен включать в себя утвержденный порядок их подготовки и отправки и многое другое. Необходимо отдельно продумать, как повысить эффективность коммуникаций по мере развития и расширения проекта. Относитесь к разработке вопросов коммуникаций по проекту так же серьезно, как к созданию иерархической структуры работ или устава проекта. Руководители проектов обычно работают в напряженных условиях, когда «хорошо» — это еще недостаточно хорошо. Нужно предвидеть, как добиться максимальной эффективности взаимодействия между заинтересованными сторонами проекта по мере его продвижения по жизненному циклу.
Вот некоторые вопросы по плану управления коммуникациями проекта.
Дав ответы на эти вопросы, вы сможете составить план управления коммуникациями проекта (табл. 6.2).
Таблица 6.2. План управления коммуникациями проекта
Некоторые хорошие руководители проектов, с которыми я встречался и работу которых наблюдал, — умные, работоспособные, отлично разбирающиеся в современных компьютерных технологиях — не всегда добиваются успеха, потому что неправильно подходят к разработке и исполнению плана управления коммуникациями проекта. Они его просто не составляют. А вы обязательно разработайте такой план!
Выберите один из своих текущих или прошлых проектов и попрактикуйтесь на нем в «шестишаговом процессе». Составьте список потенциальных рисков, выделите главные, пользуясь показателями «В — С — Н» или просто цифровой шкалой. Выберите три любых риска и разработайте для них:
Достаточно двух-трех таких точек для каждого риска.