Новым является только использование результатов этого процесса, как входных данных в процессе управления рисками:
Ладно, мы перечислили риски, и что теперь с ними делать?
В то мгновение, как вы добавляете какой-то риск в свой перечень, возникнет нажим, чтобы его убрали. Риск — это беспокойство, а когда беспокойство упорно сохраняется от одного статусного совещания к другому, вы неизбежно замечаете, что некоторые представители высшего руководства компании выражают признаки раздражения. Они явно чувствовали бы себя значительно лучше, если бы вы просто вычеркнули эту глупость из своего списка и сказали: «Об этом можно больше не беспокоиться, босс, уже приняты нужные меры». Чем более вызывающим тревогу оказался риск, тем сильнее нажим, чтобы заставить его исчезнуть из списка. По нашему опыту, достаточно раздраженный высший руководитель мало стремится понять, почему данный риск исчез, если он наконец исчезнет.
К счастью, некоторые риски исчезают в ходе проекта. Возможно, вас беспокоило, поставит ли необходимый компонент один из ваших субподрядчиков, риск невыполнения им своих обязательств исчезает, когда компонент получен и прошел тестовые испытания. К концу проекта исчезают все риски, которые не материализовались.
Руководители, оказывающие нажим, чтобы с перечисленными рисками что-то было сделано (другими словами, чтобы заставить убрать их) не склонны удовольствоваться ожиданием их естественного исчезновения. Они хотят, чтобы что-то было сделано сейчас. Так что же вы могли бы для этого сделать? Мы определили четыре возможности, которые вам доступны в отношении риска;
• Вы можете его избежать.
• Вы можете его сдерживать.
• Вы можете его ослабить.
• Вам удастся от него увернуться.
Вы избегаете риска, когда не осуществляете проект или часть проекта, вызывающие этот риск. Естественным следствием избежания риска является упущенная выгода, которую могла принести область, связанная с этим риском. Например, Merrill Lynch избежала рисков, связанных с электронной торговлей в начале 1990-х годов. Сделав это, компания упустила выгоду от роста продаж и развития брэндов.
Вы сдерживаете риск, когда заложили в бюджет достаточно времени и денег, чтобы заплатить за него, если он наступит. На практике обычно не имеет особого смысла сдерживать какой-то отдельный риск, обычно сдерживают весь набор рисков. Одни из них наступят, другие — нет. Стратегия сдерживания предполагает закладывание средств в бюджет, чтобы противостоять рискам, наступление которых наиболее вероятно. Подробнее о том, как это сделать, будет сказано в одном из следующих разделов.
Вы ослабляете риск, когда до его наступления принимаете меры по снижению возможных затрат на сдерживание. Эти меры нужно принимать заранее, чтобы избранная вами политика сдерживания была готова к моменту наступления риска.
Вам удается увернуться от риска, когда не делаете ничего из перечисленного выше, но риск просто случайно минует вас. Он не наступает. Когда вы планируете такой маневр, обычно дело сводится к скрещиванию пальцев в надежде на удачу.
Первые три способа стоят денег: избежание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. Только когда вам удается увернуться от риска, это дается бесплатно.
Если вы такой везунчик, что способны увернутся от пули, то это вам и впрямь дается даром. Например, вы опасались, что ключевые исполнители могут покинуть проект, но они этого не сделали; вы опасались, что поставщик запоздает, а он все сдал в срок; вы опасались, что пользователи отвергнут ваш примитивный интерфейс, но они, с трудом сглотнув, согласились. Вас все это беспокоило, но вы ничего не предпринимали по этому поводу. Несмотря на счастливый конец, вы на самом деле не осуществляли никакого управления риском, поскольку есть важный момент:
Управление рисками и опасения за свой проект — это не одно и то же.
Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.
Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75%.
Об этом стоит напомнить, поскольку некоторые компании имеют почти патологическую склонность превращать увертывание от рисков в цель деятельности. В таких компаниях управление рисками является тщетным, все усилия по управлению рисками выглядят не более чем новыми затратами, которые нужно сократить.
Чужой риск
ТРЛ: Мой клиент, соблазненный презентационными слайдами вендора, будто песней сирен, согласился купить последнюю версию пакета программного обеспечения. Честно говоря, эта версия еще не была выведена на рынок, но покупатель получил заверения, что все уже готово. Покупатель согласился нанять авторизованного вендором подрядчика для осуществления проекта по установке нового приложения в течение ближайших месяцев, к концу мая.
Подрядчик принял кое-какие меры по управлению рисками. Его представитель составил перечень рисков из двенадцати пунктов. Все они касались возможных нарушений соглашения со стороны покупателя (покупатель мог задержать проект слишком медленным принятием решений, покупатель мог не обеспечить подходящее рабочее пространство для подрядчика и т.п.).
На этом этапе чтения вы уже, видимо, предугадали дальнейшее развитие событий: риск, который на деле погубил проект (программное обеспечение не было вовремя получено от вендора, что сделало нереальной сдачу в мае), не был даже упомянут в перечне рисков. Никто ни разу не назвал этот риск, пока дело не дошло до того, что он перестал быть риском, а превратился в реальную проблему. Положение усугублялось тем, что программное обеспечение было на критическом пути. Первая работоспособная версия программного продукта появилась значительно позднее, чем проект был прерван, и за дело взялись юристы.
Эта история привлекает внимание к сложным проблемам управления рисками в контрактованных проектах разработки. Главная опасность в этих ситуациях кроется в недоразумениях относительно того, кто какими рисками должен управлять. Клиент имеет право указать определенные риски как сферу ответственности подрядчика, и наоборот. Если вы клиент, самая безопасная позиция для вас состоит в признании того, что только риски, конкретно относящиеся к подрядчику, будут его рисками, а остальные — вашими. Поощрения и штрафные санкции в договоре распределяют риски между сторонами.
Риски подрядчика состоят из тех, что ставят под угрозу успешное завершение договора или уменьшают для него ценность завершения. Все остальное подрядчик считает чужими рисками, и потому он исключает их из собственного управления рисками.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ладно, мы перечислили риски, и что теперь с ними делать?
В то мгновение, как вы добавляете какой-то риск в свой перечень, возникнет нажим, чтобы его убрали. Риск — это беспокойство, а когда беспокойство упорно сохраняется от одного статусного совещания к другому, вы неизбежно замечаете, что некоторые представители высшего руководства компании выражают признаки раздражения. Они явно чувствовали бы себя значительно лучше, если бы вы просто вычеркнули эту глупость из своего списка и сказали: «Об этом можно больше не беспокоиться, босс, уже приняты нужные меры». Чем более вызывающим тревогу оказался риск, тем сильнее нажим, чтобы заставить его исчезнуть из списка. По нашему опыту, достаточно раздраженный высший руководитель мало стремится понять, почему данный риск исчез, если он наконец исчезнет.
К счастью, некоторые риски исчезают в ходе проекта. Возможно, вас беспокоило, поставит ли необходимый компонент один из ваших субподрядчиков, риск невыполнения им своих обязательств исчезает, когда компонент получен и прошел тестовые испытания. К концу проекта исчезают все риски, которые не материализовались.
Руководители, оказывающие нажим, чтобы с перечисленными рисками что-то было сделано (другими словами, чтобы заставить убрать их) не склонны удовольствоваться ожиданием их естественного исчезновения. Они хотят, чтобы что-то было сделано сейчас. Так что же вы могли бы для этого сделать? Мы определили четыре возможности, которые вам доступны в отношении риска;
• Вы можете его избежать.
• Вы можете его сдерживать.
• Вы можете его ослабить.
• Вам удастся от него увернуться.
Вы избегаете риска, когда не осуществляете проект или часть проекта, вызывающие этот риск. Естественным следствием избежания риска является упущенная выгода, которую могла принести область, связанная с этим риском. Например, Merrill Lynch избежала рисков, связанных с электронной торговлей в начале 1990-х годов. Сделав это, компания упустила выгоду от роста продаж и развития брэндов.
Вы сдерживаете риск, когда заложили в бюджет достаточно времени и денег, чтобы заплатить за него, если он наступит. На практике обычно не имеет особого смысла сдерживать какой-то отдельный риск, обычно сдерживают весь набор рисков. Одни из них наступят, другие — нет. Стратегия сдерживания предполагает закладывание средств в бюджет, чтобы противостоять рискам, наступление которых наиболее вероятно. Подробнее о том, как это сделать, будет сказано в одном из следующих разделов.
Вы ослабляете риск, когда до его наступления принимаете меры по снижению возможных затрат на сдерживание. Эти меры нужно принимать заранее, чтобы избранная вами политика сдерживания была готова к моменту наступления риска.
Вам удается увернуться от риска, когда не делаете ничего из перечисленного выше, но риск просто случайно минует вас. Он не наступает. Когда вы планируете такой маневр, обычно дело сводится к скрещиванию пальцев в надежде на удачу.
Первые три способа стоят денег: избежание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. Только когда вам удается увернуться от риска, это дается бесплатно.
Если вы такой везунчик, что способны увернутся от пули, то это вам и впрямь дается даром. Например, вы опасались, что ключевые исполнители могут покинуть проект, но они этого не сделали; вы опасались, что поставщик запоздает, а он все сдал в срок; вы опасались, что пользователи отвергнут ваш примитивный интерфейс, но они, с трудом сглотнув, согласились. Вас все это беспокоило, но вы ничего не предпринимали по этому поводу. Несмотря на счастливый конец, вы на самом деле не осуществляли никакого управления риском, поскольку есть важный момент:
Управление рисками и опасения за свой проект — это не одно и то же.
Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.
Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75%.
Об этом стоит напомнить, поскольку некоторые компании имеют почти патологическую склонность превращать увертывание от рисков в цель деятельности. В таких компаниях управление рисками является тщетным, все усилия по управлению рисками выглядят не более чем новыми затратами, которые нужно сократить.
Чужой риск
ТРЛ: Мой клиент, соблазненный презентационными слайдами вендора, будто песней сирен, согласился купить последнюю версию пакета программного обеспечения. Честно говоря, эта версия еще не была выведена на рынок, но покупатель получил заверения, что все уже готово. Покупатель согласился нанять авторизованного вендором подрядчика для осуществления проекта по установке нового приложения в течение ближайших месяцев, к концу мая.
Подрядчик принял кое-какие меры по управлению рисками. Его представитель составил перечень рисков из двенадцати пунктов. Все они касались возможных нарушений соглашения со стороны покупателя (покупатель мог задержать проект слишком медленным принятием решений, покупатель мог не обеспечить подходящее рабочее пространство для подрядчика и т.п.).
На этом этапе чтения вы уже, видимо, предугадали дальнейшее развитие событий: риск, который на деле погубил проект (программное обеспечение не было вовремя получено от вендора, что сделало нереальной сдачу в мае), не был даже упомянут в перечне рисков. Никто ни разу не назвал этот риск, пока дело не дошло до того, что он перестал быть риском, а превратился в реальную проблему. Положение усугублялось тем, что программное обеспечение было на критическом пути. Первая работоспособная версия программного продукта появилась значительно позднее, чем проект был прерван, и за дело взялись юристы.
Эта история привлекает внимание к сложным проблемам управления рисками в контрактованных проектах разработки. Главная опасность в этих ситуациях кроется в недоразумениях относительно того, кто какими рисками должен управлять. Клиент имеет право указать определенные риски как сферу ответственности подрядчика, и наоборот. Если вы клиент, самая безопасная позиция для вас состоит в признании того, что только риски, конкретно относящиеся к подрядчику, будут его рисками, а остальные — вашими. Поощрения и штрафные санкции в договоре распределяют риски между сторонами.
Риски подрядчика состоят из тех, что ставят под угрозу успешное завершение договора или уменьшают для него ценность завершения. Все остальное подрядчик считает чужими рисками, и потому он исключает их из собственного управления рисками.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21