Управление разнообразием
Автор
Аркадий Пасерба
Сложный инструментарий управления рисками дает аналитику возможность взглянуть на план будущего проекта как бы через зеркало заднего вида.
Управлять надо не рисками — а источниками их возникновения!
В. И. Либерзон
Управление рисками в проектах — тема неохватная. В этой статье мне хотелось бы поделиться некоторыми методологическими наблюдениями, основанными на личном опыте проектного управления и ведения тематически близких курсов в ряде московских бизнес-школ.
«...Потому что надо было заранее...» — кому не знаком этот рефрен всех провальных проектов? Но за какое еще «ранее»? Куда же раньше — и так уже на этапе предынвестиционного анализа в первые документы проекта (ТЭО, бизнес-план, Устав) почти всегда включен раздел «Риски». Конечно, хорошо бы иметь некую предвидящую машину, формирующую всю понятийную структуру и оптимальную концепцию проекта задолго до того, как будет принято первое необратимое решение по нему. Увы... глядя на диаграмму влияния стейкхолдеров на проект и стоимость изменений в нем, понимаешь, что это «заранее», якобы предотвращающее все и любые риски, фактически переносит фокус внимания проджект-менеджера влево, нередко за границу подписания контракта, в область так называемого пресейла.
Рис. 1. Влияние переменной, основанной на сроках проекта, на его стоимость и риски с учетом сравнительной длительности этапов предпродажной подготовки и реализации проекта (1)
Авторитетный Р.Арчибальд замечает: «На фазе формирования концепции или фазе подготовки предложения методы формального управления проектами можно не применять ко всем проектам просто потому, что многие из них «не доживают» до фазы выполнения. Однако применение принципов управления проектами на этих ранних фазах — хорошее вложение времени и денег, особенно в проектах с высокой степенью риска, которые с большой вероятностью будут авторизованы к исполнению. На указанных этапах особую важность приобретают анализ рисков и методы управления рисками» (курсив мой. — А. П.). (2)
Но какие же чисто практические рекомендации можно вывести из вышесказанного? Вчитаемся в PMBOK.
«Основные выходы процесса идентификации рисков — это начальные записи в реестре рисков. В конечном счете, в реестр рисков заносятся результаты других процессов управления рисками по мере их осуществления, что со временем приводит к повышению уровня и разнообразия типов информации, содержащейся в реестре рисков» (курсив мой. — А. П.) .(3)
В дополнение к списку идентифицированных рисков PMBOK для большей наглядности рекомендует указывать их первопричины. Недостаточно «навесить» на ваши тревожные ожидания более-менее подходящие к ним ярлычки — в идеале надо точно определить источники их появления, порождающие факторы, четко понять, кто является субъектом конкретных действий, вызывающих идентифицируемую неопределенность. Жаль, что в этой рекомендации авторам стандарта не хватает настойчивости. Руководитель известной ИТ-компании, первой в России достигшей успехов в разработке сайтов и корпоративных порталов, рассказывал на бизнес-форуме Microsoft, что при составлении первого клиентского контракта его специалисты вписали в раздел «Риски» (ввиду отсутствия опыта в создании портальных решений) около пятнадцати форс-мажорных событий, первыми пришедших им в голову. Туда вошли и «нечеткое составление технического задания», и «задержки платежей», и «смена представителя заказчика на проекте» и т. п. – в таком же, как бы бессубъектном духе. А когда проект был успешно завершен, оказалось, что все идентифицированные ими риски действительно имели место. «Мы искренне радовались, что нашей фантазии в начале проекта не хватило на большее!..» — со смехом заключил рассказчик. Не правда ли, довольно типичная ситуация?
Требование четкой и недвусмысленной идентификации рисков как объектов для последующего анализа близко по своей сути к общей философии объектно-ориентированного программирования. Если, как пишет в сборнике «Информационные технологии в бизнесе» Ш. Ванг, «идентификация объектов в большой степени зависит от образа мышления специалиста (-ов) по системному анализу», то и обратное ведь тоже верно. Не только образ мышления аналитика проекта, но и вся последующая логика действий проджект-менеджера во многом будут обусловлены содержанием и качеством тех самых «начальных записей в реестре рисков», о которых говорят авторы PMBOK. Более вдумчивый подход к предварительному именованию всех проектных рисков может снизить специфический риск их так называемой ad hok (то есть случайной, кустарной) идентификации (4) . Такой подход выявляет в полном объеме сам объект управления рисками, открывая глаза проджект-менеджеру и развязывая ему руки для предвосхищения и преодоления будущих трудностей.
Объективное, субъективное и метод Дельфи как способ их сближения
Зачастую даже опытные и сертифицированные руководители проектов относятся к самому понятию «риск» как к тривиальному проектному фактору, вполне сходному с такими куда более приземленными сущностями, как бюджет, сроки или содержание проекта. Однако на всем протяжении проекта важно понимать, что риск — это абстракция более высокого порядка, так сказать, «отрицание отрицания». Сложный инструментарий управления рисками дает аналитику возможность взглянуть на план будущего проекта как бы через зеркало заднего вида, отвергающее изначальную способность проджект-менеджера управлять скоротечными событиями в полном объеме и со стопроцентной вероятностью.
На своих тренингах по управлению проектами я ввожу слушателей в тему управления рисками с помощью такого шутливого теста:
«Прочитайте список рисков, действию которых вы (теоретически) можете подвергнуться в ходе повседневной жизни и профессиональной деятельности. Определите сравнительную степень объективности/субъективности каждого риска, составьте соответствующий рейтинг:
1. Риск стать жертвой землетрясения
2. Риск застрелиться при игре в русскую рулетку
3. Риск получить инвалидность от падения на голову куска штукатурки
4. Риск быть уволенным с работы за неоднократные прогулы
5. Риск быть съеденным космическими пришельцами
6. Риск заболеть гриппом
7. Риск провалить проект, которым вы руководите, из-за собственной некомпетентности
8. Риск утратить специальную квалификацию (по диплому о высшем образовании)
9. Риск сгореть на работе
10. Риск подвергнуться сглазу, действию заговора или интриги»
К сожалению, в стандарте PMBOK понятия объективного и субъективного риска отсутствуют. Однако многие эксперты охотно их используют. Под объективным риском в страховании, например, принято понимать «такую опасность, которая исходит непосредственно от застрахованного объекта или его окружения». (5)Субъективные риски, напротив, обычно связаны с личными особенностями, а также спонтанной управленческой активностью самих субъектов управления — причем как с принимаемыми ими решениями, так и с ошибками в исполнительских действиях их подчиненных, нарушениями правил эксплуатации и т. п. (6)
Интересно, что без применения понятий объективного и субъективного рисков едва ли может быть выполнено такое требование PMBOK: «Формат описания рисков должен быть последовательным для обеспечения возможности сравнивать относительное воздействие на проект наступления одного риска с соответствующими воздействиями других рисков» (курсив мой. — А. П.). Например, в реестре рисков проекта внедрения ERP-системы присутствовали одновременно (и рядом!) следующие риски:
1. Риск нарушения субподрядчиком сроков поставки компьютерной техники
2. Риск недостаточного опыта управления ИТ-проектами у руководителя проекта
3. Риск изменения заказчиком функциональных требований к системе
4. Риск возрастания стоимости проекта из-за последствий глобального финансового кризиса
5. Риск низкой мотивации членов проектной команды.
Очевидно, что с точки зрения набора использованных в этом описании сущностей и их атрибутов — масштаба, субъектно-объектной и пространственно-временной отнесенности — данные риски несопоставимы. Следовательно, и в дальнейшем они не будут корректно ранжированы и существенно нивелированы с помощью стандартного методологического инструментария PMBOK, включающего качественный и количественный анализ рисков, а также выбор стратегий реагирования на них.
Но отдадим должное авторам PMBOK: не вводя самих дефиниций для объективных и субъективных рисков, они предусмотрели вполне пригодную методику их содержательного сближения, и что характерно — еще на этапе идентификации. «Метод Дельфи — это способ достижения консенсуса между экспертами... Эксперты принимают в нем участие анонимно. С помощью опросного листа ведущий собирает идеи о важных рисках проекта... Резюме ответов потом возвращаются экспертам для дальнейших комментариев... Метод Дельфи помогает преодолеть необъективность в оценке данных и устраняет избыточное влияние отдельных лиц на результат работы» (курсив мой. — А. П.). (7)
А теперь ответьте себе на вопрос: сколько раз (и когда в последний) вы реально использовали на своих проектах хорошо знакомый вам метод Дельфи?..
Специфика ИТ-проектов и закон необходимого разнообразия
Каковы же специфические особенности рисков в ИТ-проектах? Всякий раз, когда речь идет об информационных технологиях и системах, подразумевается решение с их помощью управленческих проблем: в первую очередь проблем коммуникаций и принятия решений. При этом ИТ-проектам тоже свойственны элементарные ошибки и халатность исполнителей, неполнота проектных документов, нарушение членами проектных команд уставных регламентов, неконструктивное вмешательство стейкхолдеров и т. п. Однако — и это следует помнить даже начинающему руководителю — все эти банальные недочеты проектного управления чреваты особенно драматическими последствиями именно в ИТ-проектах.
«Высшая власть — это власть над собой», и если деятельность, призванная улучшить качество управления некими предметными областями и объектами, сама вместо этого демонстрирует высокую степень хаотичности, нестабильности, неопределенности, то негативный эффект от нее превысит, скорее всего, любые позитивные результаты от получения заказчиком целевого продукта.
Вспомним знакомый из кибернетики закон необходимого разнообразия У.Эшби: «При создании проблеморазрешающей системы необходимо, чтобы эта система имела большее разнообразие, чем разнообразие решаемой проблемы, или была способна создать такое разнообразие. Иначе говоря, система должна обладать возможностью изменять свое состояние в ответ на возможное возмущение; разнообразие возмущений требует соответствующего ему разнообразия возможных состояний. В противном случае такая система не сможет отвечать задачам управления, выдвигаемым внешней средой, и будет малоэффективной». (8)
Риски же ИТ-проектов, с учетом сказанного, стоят по отношению к предметной области автоматизации как бы уже на следующем уровне абстракции. Характерный кейс имел место в консалтинговой компании, выполнявшей внедрение системы BPM-класса. Призванная не только построить систему стратегического и оперативного управления в организации заказчика, но и по ходу проекта расширить понимание его топ-менеджерами таких концепций как реинжиниринг бизнес-процессов, исполнение стратегии, управление проектами/программами компания-интегратор в лице собственных специалистов-методологов фактически запуталась в их хитросплетениях. Вдобавок к этому еще на этапе предварительного обследования члены проектной команды исполнителя проявили такое неуважение к составленному ими же расписанию проекта, регулярно опаздывая с подготовкой отчетов и проведением статус-митингов, что клиенту ничего не оставалось делать, кроме как в спешном порядке закрыть проект. «Пусть теперь каждый из нас самостоятельно борется со своей энтропией!» — таковы были последние слова координатора проекта со стороны заказчика, сказанные им на прощание руководителю проекта.
Именно необходимость управляемого разнообразия в разрабатываемой ИТ-системе и создающей ее проектной команде, или, иначе говоря, уникальные требования к степени их собственной сложности и изменчивости — вот, на мой взгляд, определяющие факторы специфических рисков ИТ-проектов.
(1) А. Пасерба. Управление presale-проектом: продажа высокотехнологичных услуг в свете методологии PMBOK. Журнал «Управление продажами», № 4, 2012.
(2) Арчибальд Р. Управление высокотехнологичными программами и проектами – М.: LVR Пресс, 2002.
(3) Руководство к своду знаний по управлению проектами (Руководство PMBOK) – PMI, Inc.
(4) Информационные технологии в бизнесе / Под ред. М. Желены. – Спб: Питер, 2002.
(5) Страховое дело: Учебник. В 2 т. (пер. с нем. О. И. Крюгер и Т. А. Федоровой). – т.1: Основы страхования / под ред. О. И. Крюгер. – М.: Экономистъ, 2004
(6) Ильин Е. П. Психология риска – Спб: Питер, 2012.
(7) Руководство к своду знаний по управлению проектами (Руководство PMBOK) – PMI, Inc.
(8) Википедия http://ru.wikipedia.org/wiki
Опубликовано 05.11.2013