IT ManagerИТ в бизнесеУправление

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

Павел Потеев, Глеб Горюнов | 26.02.2014

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

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


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

«Как есть» и «как есть на самом деле»

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

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

С одной стороны, они объективно помогают реализовывать проекты быстрее, с большей вероятностью соблюдения бюджета и лучшим контролем рисков. Например, в настоящее время системы управления ресурсами предприятия требуют для внедрения в два-три раза меньше времени, чем пятнадцать лет назад. И это во многом благодаря развитию методологий. 
Казалось бы, есть все, чтобы управление проектами стало ординарной административной деятельностью. Однако управленческая литература, выступления на конференциях и просто разговоры в профессиональных кругах полны историй о срывах, задержках, провалах, многократных превышениях бюджета в ходе выполнения проектов самого различного назначения.

И еще одно. Квалификационные требования к руководителю сложных проектов и программ включают, помимо административных, ряд совершенно иных навыков. Попробуем перечислить некоторые из них:
  • Управление конфликтами.
  • Управление рисками и кризисами, способностью быстро подстраивать планы и вырабатывать сценарии решения проблемных ситуаций.
  • Навыки управленческой коммуникации и убеждения.
  • Устойчивость к стрессам.
Такова реальность, и другого глобуса у нас, похоже, пока нет. В управлении проектами, помимо методологий, востребованы и необходимы как специальные навыки, так и качества личности руководителя. О них и пойдет речь.

Оптимист с мрачными мыслями

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

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

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

Поэтому если у руководителя проекта уверенный взгляд, а на лице улыбка, то внутри четкое понимание: все, что может пойти не так, как предполагается, обязательно пойдет не так. А что, казалось бы, на 100% должно пойти как надо — тоже не разочарует и принесет по ходу проекта несколько малоприятных сюрпризов.

Итак, вы знаете, что на вашем проекте есть серьезные риски и осложнения, а еще больше рисков ждет вас впереди. Поздравляем, добро пожаловать в клуб! А теперь улыбайтесь увереннее, не добавляйте к списку проблем еще одну.

Oldies but goldies: матрица управления рисками

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

Типичная матрица рисков позволяет как видеть список рисков, так и ранжировать их по степени вероятности и потенциальной угрозе целям проекта. Перемножение этих показателей определяет значимость для проекта. Риск, малой вероятный, но способный оказать серьезное негативное влияние на проект, должен оказаться в зоне особого внимания руководства проектом.
img
Рис.1 Матрица рисков.

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

Представим себе процесс обнаружения рисков как работу противовоздушной обороны, чья задача — контролировать защищаемый периметр на 360 градусов. Для этого небо разбивается на секторы, которые контролируются «в несколько пар глаз». На крупном проекте или программе имеет смысл сделать то же самое. Под управлением руководителя проекта всегда будут несколько, отвечающих за различные области опытных специалистов. Их обязательно следует ориентировать на мониторинг и уже выявленных рисков, и тех, что пока находятся «за горизонтом». Так, при разворачивании ERP-системы контроль рисков будет по-настоящему действенным, если разные люди «присмотрят» за выполнением задач в направлениях конфигурации системы, подготовки данных, ИТ-инфраструктуры, организационных и процессных изменений, обучении персонала работе с новыми процессами и системой.

У руководителя проекта есть еще один ценный ресурс, необходимый для работы с рисками, — управляющий комитет, заказчики проекта. Да, руководитель проекта подчинен управляющему комитету, но тот же комитет — его рабочий ресурс, причем очень ценный. Опыт, знания и связи в организации позволят  представителям управляющего комитета (в состав когорого, как правило, входят высшие руководители предприятия) увидеть часть рисков, плохо заметных «изнутри» проекта. А статус и полномочия помогут эффективно ликвидировать риски, особенно те, для которых необходима тяжелая управленческая артиллерия.

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

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

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

Troubleshooter: должность невидимая, но нужная

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

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

Разумеется, в такой работе находят применение и общие навыки управления. Отсутствует понимание того, что происходит с задачей, — устанавливаем численные показатели, характеризующие ее выполнение. Исполнение задачи затянулось во времени — увеличиваем частоту контрольных мероприятий. Смотрим, возможно ли разбить выполнение задачи на параллельные потоки, чтобы ускорить ее выполнение. Появилось ощущение того, что вам врут, — привлекаем стороннюю независимую экспертизу. Не стесняемся, помним, что сорванная задача вполне может привести к задержке, удорожанию, срыву проекта в целом.

Цели, люди, результат

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

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

По ходу исполнения проекта будут появляться риски, и часть из них превратится в проблемы. И в команде понадобятся люди, способные как обнаруживать риски, так и тушить уже вполне разгоревшиеся пожары и разрешать кризисы. Как их подобрать?

У консультантов в ходу фраза: «На первом проекте ты делаешь все неправильно, на втором понимаешь, как правильно, на третьем — делаешь правильно».

Оттолкнувшись от этой фразы, можно построить принцип набора ядра проектной команды. Пусть у вас будет несколько сотрудников, уже видевших многочисленные риски и кризисы, битых, даже когда-то пропустивших их. Расставленные на ключевых ролях организационной структуры проекта, они принесут не только экспертные знания, но и опыт противодействия рискам. И если проект окажется в достаточной степени «прикрыт» такими людьми, надеемся, что после его завершения у вас появится возможность сказать: "We went live. And we are alive".

img
Павел Потеев, ИТ-эксперт

img
Глеб Горюнов, директор службы поддержки персонала MC-Bauchemie

Ключевые слова: управление проектами

Журнал IT-Manager № 02/2014    [ PDF ]    [ Подписка на журнал ]

Об авторах

Павел Потеев

Павел Потеев

Постоянный автор журнала. С 1992 г. его карьера развивается в сферах программ трансформации, корпоративного управления, информационных технологий, управления изменениями, консультирования. После получения высшего инженерного образования в Санкт-Петербургском Техническом Университете ИТМО Павел начал карьеру в ИТ, был консультантом и руководителем проектов внедрения бизнес-систем, работал в программах стратегического и организационного развития. Опыт Павла основан на работе в международных компаниях различных направлений деятельности, таких, как добыча природных ресурсов, химическая промышленность, горнодобывающая индустрия, консалтинг, строительство, производство, профессиональные услуги. В дополнение к роли ИТ-руководителя, получил глубокое понимание работы подразделений финансов, продаж, операций, а также опыт постановки процессов CRM и HR, внедрения SAP, управления проектами организационного развития, слияний и поглощений. Будучи экспертом международного уровня, Павел реализовывал проекты в публичных и частных компаниях, расположенных в более чем десяти странах Центральной, Северной и Восточной Европы и Центральной Азии. До недавнего времени работал директором департамента управления изменениями Eurasian Resources Group (ERG) Business and Technology Services руководил направлениями обучения и развития, внедрением новых процессов управления.
Член Санкт-Петербургского клуба ИТ-директоров SPB CIO CLUB

Глеб Горюнов

Глеб Горюнов

Директор службы поддержки персонала MC-Bauchemie

Мероприятия

23.09.2018 — 25.09.2018
XII Конгресс "Подмосковные вечера"

Москва, Атлас Парк Отель. Домодедово, Судаково, 92,

26.09.2018
Loginom Day 2018: продвинутая аналитика, легкая в приготовлении

Москва, event-холл «Инфопространство»

02.10.2018 — 03.10.2018
Открытая конференция для бизнеса и ИТ «ACCELERATE»

Москва, Краснопресненская набережная, 14 Экспоцентр

02.10.2018
Практики построения современного трейдинга

Москва, Арарат Парк Хаятт, зал Саргсян

04.10.2018 — 05.10.2018
БИТ Санкт-Петербург 2018

Санкт-Петербург, проспект Медиков, дом 3, Конгресс-центр «ЛПМ»