Роман Павленко, руководитель проекта в «BDO»
В жизни нет гарантий,
существуют одни вероятности.
Т. Клэнси
Управление рисками и управление инцидентами – два столпа в используемом менеджером инструментарии. Упрощенно всю работу менеджера проекта можно свести к управлению рисками и инцидентами.
Неконтролируемые или плохо управляемые риски приводят к возникновению инцидентов. Инциденты приводят к возникновению новых проектных рисков. Устранение инцидентов без выяснения причин их возникновения и дальнейшего контролирования рисков возникновения подобных инцидентов приводит к неконтролируемому появлению новых инцидентов.
В свою очередь, качественно управлять рисками без устранения текущих инцидентов практически невозможно. Кроме того, к инцидентам применим закон перехода количества в качество, рождая новые риски в результате неконтролируемого накопления инцидентов (например: появление риска дефицита ресурсов и качества оказываемой поддержки конечных пользователей из-за «переключения» консультантов на «латание дыр» в процессе устранения инцидентов; или риски неустойчивой и некорректной работы системы из-за несоблюдения процедур тестирования в процессе несистемного создания «заплаток» без качественного анализа причин возникновения инцидентов). Неконтролируемый поток инцидентов порождает цепную реакцию.
Итак, что же такое риски и инциденты и как оптимально построить проектную работу, избегая возникновения неконтролируемых или массовых проблем?
Риск – это комбинация вероятности события и его последствий. Приведенное определение - одно из множества, можно сказать, базовых определений понятия «риск». В свое время, будучи студентом, я писал курсовую работу на тему психологических аспектов понятия «риск» (к счастью, тогда еще не было Интернета и приходилось посещать библиотеку). По большому счету, в практике внедрения ERP-проектов я не столкнулся ни с чем новым, за исключением конкретного набора базовых проектных рисков и проектного инструментария управления рисками. Но, как говорится, есть один нюанс…
В психологии риск – это ситуационная характеристика выбора между возможностью получения определенных «дивидендов» и наступлением определенных негативных последствий выполняемых действий (принимаемых решений). Оценивая риск, разумный человек определяет, насколько возможность получения «бонуса» перевешивает тот «негатив», который он может получить в результате течения событий по неблагоприятному сценарию.
Если человек не очень разумен, чересчур самоуверен или не имеет четкого представления о возможных негативных последствиях, то он может принять невзвешенное решение (по сути, игнорируя возможные риски). В проектной практике подобное игнорирование негативных последствий идентифицированных рисков зачастую происходит из-за недостаточности опыта, недостатка мотивации или недостаточной ответственности менеджеров.
Управление рисками = Управление угрозами достижению целей проекта?! PMBOK® классифицирует риск как «неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта».
Откровенно говоря, в моей практике управления ERP-проектами отношение к рискам сводилось к управлению негативными ожиданиями от наступления рисков. Другими словами, риск воспринимался не как ситуация выбора, а как вероятное наступление негативного события, которое необходимо предотвратить или минимизировать его вероятные последствия.
По сути, управление рисками заключалось в исключении или минимизации возникновения инцидентов, вызванных идентифицируемыми проектными угрозами. Другими словами, управление проектными рисками равно управлению вероятностью возникновения идентифицируемых проектных угроз. И мне кажется, что при внедрении ERP-системы классического проектного процесса управления рисками и быть не может.
- Менеджер не рискует, принимая решения (ну разве что когда ввязывается в проект).
- Менеджер не выбирает между возможными выгодами и потерями.
- Менеджер классифицирует угрозы, которые могут повлиять на достижение проектных целей, и разрабатывает мероприятия по предотвращению данных угроз или минимизации последствий наступления негативных событий.
Если вы знаете проект, в котором велось классическое проектное, не формальное, управление рисками (например, как в финансовом секторе или стратегическом менеджменте), поделитесь опытом. Уж очень интересно на это «посмотреть».
Учитывая мою практику и практику моих товарищей в области внедрения ERP-систем, можно говорить об управлении проектными угрозами. А «управление рисками» - это исторически сложившийся термин! Да простят меня ортодоксы.
Проектный инцидент – это возникновение события, негативно сказывающегося на достижении целей проекта. Зачастую инцидент – это последствие неуправляемого, плохо управляемого или не идентифицированного риска (угрозы достижения целей проекта).
Что же первично? Курица или… т. е. риски (угрозы) или инциденты? Поскольку в данной статье в первую очередь речь идет о «безнадежных проектах», т. е. о проектах, сопряженных с большим количеством плохо управляемых рисков или уже случившихся инцидентов (ставящих под вопрос достижение проектных целей), то и управление рисками и инцидентами рассматривается не в разрезе, присущем нормальному течению проекта.
В «безнадежных» проектах деятельность менеджера сводится не к организации нормального течения работ, а к приведению проекта к уровню «нормального». Задача спасения «безнадежных» проектов зачастую ложится на плечи менеджеров, которые приходят в проект, в котором уже полным ходом идут работы, но не лучшим образом.
Кризис-менеджеры включаются в работу в тот момент, когда накоплена масса инцидентов и большое количество рисков неуправляемо. В такой ситуации работа менеджера начинается с управления инцидентами. Производится идентификация инцидентов, актуализируются планы, проект выводится на уровень своевременного выполнения оперативных планов. И когда проект выведен на нормальный режим работы, управление инцидентами перестает быть первоочередной задачей и необходимо в полной мере переходить к процедуре управления рисками.
Подобный сценарий – не редкость в период реанимации проектов, но совершенно не подходит для нормальной подготовки и запуска проекта с нуля.
Другими словами, на вопрос о том, что приоритетно – курица или яйцо, можно ответить так: для проектов, уже успевших стать «безнадежными», управление инцидентами приоритетно (чтобы перейти к нормальной практике управления рисками), для «нормальных» проектов приоритетно управление рисками (с целью исключить или минимизировать появление инцидентов).
По сути, процесс управления рисками ERP-проекта должен носить итерационный характер и продолжаться в течение всего проекта. Каждая проектная фаза должна начинаться с процедуры идентификации проектных рисков. В рамках фаз должны регулярно проводиться мероприятия по корректировке планов управления рисками. Регулярность проведения данных мероприятий должна зависеть от степени потенциального влияния рисков на проект.
Также необходимо проведение внеплановых мероприятий по актуализации перечня идентифицированных рисков и мероприятий по их минимизации. В том числе в результате наступления событий, существенно влияющих на ход выполнения проекта.
Идентификация рисков
Как правило, любая консалтинговая практика имеет шаблонный реестр проектных рисков. Подобный шаблон упрощает задачу менеджера, но не исключает необходимости глубокого анализа проектных угроз, реализация которых может повлиять на достижение целей проекта.
Задача менеджера – выделить угрозы, реализация которых вероятна в данном проекте. С одной стороны, все просто. Просматривается реестр шаблонных рисков, выделяется то, что характерно для данного проекта, и реестр рисков проекта готов. Но в реальности задача несколько сложнее. Выделить то, что действительно представляет угрозу проекту, и тем более дополнить реестр новыми рисками, возможно только понимая взаимосвязь процессов и их влияние на множество проектных работ.
Другими словами, подготовить действительно актуальный реестр рисков может только менеджер, обладающий достаточным проектным опытом. К сожалению, очень часто отношение к управлению рисками формально. И чем более бурная деятельность по документированию процессов, призванных управлять рисками, разворачивается в начале проекта, тем более формальное отношение к процедуре в дальнейшем. «Мы сделаем все грамотно – мы читали PMBOK®» - так можно выразить подобные стремления. Проблема только в том, что грамотное следование стандартам не заменяет понимания взаимосвязи проектных и околопроектных процессов. Понимание, которое приходит только с опытом. Как говорил классик: «…и опыт, сын ошибок трудных…».
Метафизика риска или теория двойного ноля в управлении рисками
Проект внедрения ERP-системы сродни самой жизни. Ты планируешь, ставишь цели, управляешь рисками… Но, как говорится, «хочешь рассмешить Бога, расскажи ему о своих планах». Всегда остается место для форс-мажора. Опыт позволяет управлять большей частью угроз и рисков, но предвидеть все невозможно.
Когда перед продуктивным стартом один из «гениев» рушит продуктивную систему или заказчик вдруг обнаруживает, что изначально предъявлял ошибочные требования, влияющие на достижение важной проектной цели, начинаешь активно верить в куклы вуду.
Жизнь течет. Все меняется. Вы можете приложить максимум усилий и старательности. Проектная команда может работать год по 18 часов в сутки. И когда вы будете в шаге от результата, заказчик вам скажет, что из-за реорганизации бизнеса проект больше не нужен. Обида. Злость. Вселенская несправедливость. Какие еще чувства можно испытывать, добегая до финиша первым и узнавая, что соревнования отменили? C’est la vie.
Конечно, это не значит, что не нужно «бежать» или не нужно стараться. Мы растем, пока «бежим», а не когда пересекаем финишную черту. Финишная черта лишь психологический барьер. Факт свершившегося преодоления.
Так к чему же было это лирическое отступление? Лишь для того, чтобы подвести к следующей мысли – можно и нужно управлять рисками, но сложный и длительный проект невозможно завершить успешно, без определенной доли везения. Всегда остается некая «темная» зона. Зона реальности, неподвластная нашему пониманию и управлению.
Студент, орущий в открытое окно: «Халява, приди!», ничем не отличается от менеджера, молящегося за успех проекта или жующего «псилоцибы» на лесной поляне, пытаясь постичь сакральный смысл успеха. За свою практику я насмотрелся на массу удивительных вариаций «призыва» проектной удачи. Иногда люди буквально сходят с ума. И многие с такой поразительной фантазией! Уверен: чтобы не «сорвало башню» при первой серьезной неудаче, сходите с ума планово и заранее (как бы странно это ни звучало).
Я не призываю водить в голом виде хороводы вокруг лесного костра под полной луной (хотя для кого-то, наверное, это хороший вариант). Считаю необходимым иметь каску или на худой конец кастрюлю, чтобы быть готовым к приему камня из-за пазухи вашей судьбы.
«Не бывает атеистов в окопах под огнем». Так не ждите удара от судьбы. Обретите религию, заведите талисман. Мысли материальны, и лишними ваши попытки управлять удачей уж точно не будут. Главное – без фанатизма (если вы понимаете, о чем я).
Орфография и пунктуация в данном тексте сохранены в том виде, в котором они были предложены автором.
