Может быть, мы не так уж плохо оцениваем

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

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

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

Вчерашняя проблема

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

В основе этого подхода лежит следующий принцип:

Вчерашняя проблема – это сегодняшний риск.

В каждом из нас найдется какая-то струна, которую заденет эта формулировка. Мы захотим «подправить» ее на что-то вроде «Сегодняшняя проблема – это вчерашний риск» или «Сегодняшний риск – это завтрашняя проблема». От таких переформулировок проку мало. Именно уравнивание прошлых проблем и нынешнего риска (другими словами, признание повторяющегося характера проблем проекта) помогает вам на практике управлять риском. Если вы обнаруживаете, что с недавно завершенным вами проектом возникли трудности, когда несколько ключевых работников ушли из компании, тогда потери персонала автоматически входят в ваш перечень рисков по новому проекту. Слово «автоматически» стоит здесь подчеркнуть: потеря работников, в особенности ключевых, настолько серьезная угроза, что управление в стиле «будет сделано» может отказываться рассматривать ее. Никогда не вздумайте недооценивать соблазнительный комфорт фразы: «Брррр, я просто не хочу об этом думать».

Итак, один из способов расширить перечень рисков – по крайней мере первоначально – состоит в методичном использовании анализа результатов после окончания проектов. Это предполагает, что ваша компания уже является достаточно просвещенной для проведения «разбора полетов» после завершения каждого успешного и неуспешного проекта, чтобы выявить, что произошло. Если вы этого не делаете, то, возможно, вам захочется взглянуть на ссылки в конце книги, где можно найти две рекомендации по анализу результатов законченных проектов.

Едва ли разбор предыдущих проектов является новинкой. Новым является только использование результатов этого процесса, как входных данных в процессе управления рисками:

Ладно, мы перечислили риски, и что теперь с ними делать?

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

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

Руководители, оказывающие нажим, чтобы с перечисленными рисками что-то было сделано (другими словами, чтобы заставить убрать их) не склонны удовольствоваться ожиданием их естественного исчезновения. Они хотят, чтобы что-то было сделано сейчас. Так что же вы могли бы для этого сделать? Мы определили четыре возможности, которые вам доступны в отношении риска;

• Вы можете его избежать.

• Вы можете его сдерживать.

• Вы можете его ослабить.

• Вам удастся от него увернуться.

Вы избегаете риска, когда не осуществляете проект или часть проекта, вызывающие этот риск. Естественным следствием избежания риска является упущенная выгода, которую могла принести область, связанная с этим риском. Например, Merrill Lynch избежала рисков, связанных с электронной торговлей в начале 1990-х годов. Сделав это, компания упустила выгоду от роста продаж и развития брэндов.

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

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

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

Первые три способа стоят денег: избежание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. Только когда вам удается увернуться от риска, это дается бесплатно.

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

Управление рисками и опасения за свой проект – это не одно и то же.

Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.

Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75%[18].

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

Чужой риск

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

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

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

Эта история привлекает внимание к сложным проблемам управления рисками в контрактованных проектах разработки. Главная опасность в этих ситуациях кроется в недоразумениях относительно того, кто какими рисками должен управлять. Клиент имеет право указать определенные риски как сферу ответственности подрядчика, и наоборот. Если вы клиент, самая безопасная позиция для вас состоит в признании того, что только риски, конкретно относящиеся к подрядчику, будут его рисками, а остальные – вашими. Поощрения и штрафные санкции в договоре распределяют риски между сторонами.

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

Часто судебные тяжбы возникают из-за того, что клиента поражает выпадение из поля зрения подрядчика некоторых важных рисков. Как правило, вся проблема – в самом договоре, где не прописана ответственность за эти риски. Обычно не бывает договоров, которые успешно возлагают всю ответственность на одну из сторон. Если вы клиент или подрядчик, рассчитывайте на то, что вам придется взять на себя какую-то долю управления рисками.

Не нашли, что искали? Воспользуйтесь поиском: