• Главная
•  > 
• Статьи
•  > 
• Управление разнообразием

Управление разнообразием

Аркадий Пасерба

Управлять надо не рисками — а источниками их возникновения!
В. И. Либерзон

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

Кустарная идентификация рисков — самый большой риск

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

Рис. 1. Влияние переменной, основанной на сроках проекта, на его стоимость и риски с учетом сравнительной длительности этапов предпродажной подготовки и реализации проекта¹.

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

Но какие же чисто практические рекомендации можно вывести из вышесказанного? Вчитаемся в PMBOK.

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

В дополнение к списку идентифицированных рисков PMBOK для большей наглядности рекомендует указывать их первопричины. Недостаточно «навесить» на ваши тревожные ожидания более-менее подходящие к ним ярлычки — в идеале надо точно определить источники их появления, порождающие факторы, четко понять, кто является субъектом конкретных действий, вызывающих идентифицируемую неопределенность. Жаль, что в этой рекомендации авторам стандарта не хватает настойчивости. Руководитель известной ИТ-компании, первой в России достигшей успехов в разработке сайтов и корпоративных порталов, рассказывал на бизнес-форуме Microsoft, что при составлении первого клиентского контракта его специалисты вписали в раздел «Риски» (ввиду отсутствия опыта в создании портальных решений) около пятнадцати форс-мажорных событий, первыми пришедших им в голову. Туда вошли и «нечеткое составление технического задания», и «задержки платежей», и «смена представителя заказчика на проекте» и т. п. – в таком же, как бы бессубъектном духе. А когда проект был успешно завершен, оказалось, что все идентифицированные ими риски действительно имели место. «Мы искренне радовались, что нашей фантазии в начале проекта не хватило на большее!» — со смехом заключил рассказчик. Не правда ли, довольно типичная ситуация?

Требование четкой и недвусмысленной идентификации рисков как объектов для последующего анализа близко по своей сути к общей философии объектно-ориентированного программирования. Если, как пишет в сборнике «Информационные технологии в бизнесе» Ш. Ванг, «идентификация объектов в большой степени зависит от образа мышления специалиста(-ов) по системному анализу», то и обратное ведь тоже верно. Не только образ мышления аналитика проекта, но и вся последующая логика действий проджект-менеджера во многом будут обусловлены содержанием и качеством тех самых «начальных записей в реестре рисков», о которых говорят авторы PMBOK. Более вдумчивый подход к предварительному именованию всех проектных рисков может снизить специфический риск их так называемой ad hok (то есть случайной, кустарной) идентификации⁴. Такой подход выявляет в полном объеме сам объект управления рисками, открывая глаза проджект-менеджеру и развязывая ему руки для предвосхищения и преодоления будущих трудностей.

Объективное, субъективное и метод Дельфи как способ их сближения

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

На своих тренингах по управлению проектами я ввожу слушателей в тему управления рисками с помощью такого шутливого теста:

К сожалению, в стандарте PMBOK понятия объективного и субъективного риска отсутствуют. Однако многие эксперты охотно их используют. Под объективным риском в страховании, например, принято понимать «такую опасность, которая исходит непосредственно от застрахованного объекта или его окружения»⁵. Субъективные риски, напротив, обычно связаны с личными особенностями, а также спонтанной управленческой активностью самих субъектов управления — причем как с принимаемыми ими решениями, так и с ошибками в исполнительских действиях их подчиненных, нарушениями правил эксплуатации и т. п.⁶.

Интересно, что без применения понятий объективного и субъективного рисков едва ли может быть выполнено такое требование PMBOK: «Формат описания рисков должен быть последовательным для обеспечения возможности сравнивать относительное воздействие на проект наступления одного риска с соответствующими воздействиями других рисков» (курсив мой. — А. П.). Например, в реестре рисков проекта внедрения ERP-системы присутствовали одновременно (и рядом!) следующие риски:

1. Риск нарушения субподрядчиком сроков поставки компьютерной техники
2. Риск недостаточного опыта управления ИТ-проектами у руководителя проекта
3. Риск изменения заказчиком функциональных требований к системе
4. Риск возрастания стоимости проекта из-за последствий глобального финансового кризиса
5. Риск низкой мотивации членов проектной команды.

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

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

А теперь ответьте себе на вопрос: сколько раз (и когда в последний) вы реально использовали на своих проектах хорошо знакомый вам метод Дельфи?

Опубликовано в журнале «IT-Manager»

1.  ↑ Пасерба А. Управление presale-проектом: продажа высокотехнологичных услуг в свете методологии PMBOK // Управление продажами. № 4. 2012.
2.  ↑ Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: LVR Пресс, 2002.
3.  ↑ Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: LVR Пресс, 2002.
4.  ↑ Информационные технологии в бизнесе / Под ред. М. Желены. Спб: Питер, 2002.
5.  ↑ Страховое дело: Учебник. В 2 т. (пер. с нем. О. И. Крюгер и Т. А. Федоровой). Т.1. Основы страхования / под ред. О. И. Крюгер. М.: Экономистъ, 2004.
6.  ↑ Ильин Е. П. Психология риска. Спб: Питер, 2012.
7.  ↑ Руководство к своду знаний по управлению проектами (Руководство PMBOK). PMI, Inc.

• Управление проектами на основе PMI PMBOK GUIDE®-5-2013 и ГОСТ Р54869-2011 с использованием Microsoft Project-2013
• Управление проектами: стандарты, методики, алгоритмы