Вальсируя с медведями

Управление рисками позволяет осуществлять агрессивное принятие рисков

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

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

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

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

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

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

Но вообразите вместо этого, что руководитель проекта по разработке программного обеспечения приходит к вам и честно показывает ожидаемые неопределенности в предполагаемом проекте: «Смотрите, неизвестно, что нам ждать там-то и там-то. Вот мы составили перечень из 11 пунктов». (Тут он показывает вам свой список рисков). «Вместе взятые, эти неизвестные дают очень большой разброс срока завершения. Некоторые из дат в этом диапазоне, возможно, будут для вас неприемлемыми. Но вот наш продуманный план того, как мы будем сдерживать и минимизировать различные риски, а вот описание того, как вы узнаете в любой точке проекта, как мы продвигаемся».

Если в дополнение к сказанному он покажет вам записи о прежних проектах, демонстрирующие, как реальные результаты соответствовали оценкам неопределенности, то вы можете начать верить тому, что услышали.

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

Управление рисками реабилитирует риск

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

Управление рисками делает приемлемой определенную дозу мышления типа «невозможно сделать». Когда установлена структура управления рисками, людям разрешено мыслить и негативно, по крайней мере, часть времени. Компании, делающие это, понимают, что негативное мышление – единственный путь избежать неожиданных ударов со стороны неучтенных рисков во время осуществления проекта[13].

Управление рисками подготавливает успех проектов

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

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

Частенько встречаются «неудавшиеся» проекты, где есть все основания полагать, что для выполнения заданной работы у руководства есть необходимые способности и их команды достаточно квалифицированы. Если бы это было не так, им бы давно указали на дверь. Когда один проект за другим объявляют неудавшимся, это просто доказывает, что негодными были установочные условия этих проектов. Управление рисками – способ разрушить этот мрачный цикл, обеспечив набор выполнимых целей и графиков и породив успешные проекты, которые выглядят и ощущаются как успешные с начала и до конца.

Управление рисками ограничивает неопределенность

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

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

Ограниченная неопределенность может страшить (жутко подойти вплотную к осознанию того, как мало есть вещей, в которых можно быть уверенным), но без нее мы имеем дело с тем, что гораздо хуже – безграничной неопределенностью. Безграничная неопределенность либо отвращает людей от риска, либо приводит к безрассудной отваге. Обе эти крайности катастрофичны.

Управление рисками обеспечивает самую дешевую защиту от непредвиденных неприятностей

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

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

Управление рисками защищает от незаметных переносов ответственности

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

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

Управление рисками может сберечь часть результатов при неудаче

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

Часть II

Почему бы и нет?

Какова оборотная сторона управления рисками?

Находится ли управление рисками в противоречии с принципом «управление ради успеха»?

Есть ли основания верить, что управление рисками окажется совместимым с нашей корпоративной культурой?

Чем плох расчет на несколько счастливых случаев при составлении графика проекта?

Как отличить риски, которыми необходимо управлять, от тех, которыми можно спокойно пренебречь?

Глава 5

Доводы против управления рисками

Управление рисками часто показывает вам больше реальности, чем вам хочется.

Майк Эванс (MikeEvans), первый вице-президент корпорации АSC[14]

Следует признать, что есть несколько причин не прибегать к управлению рисками. Мы не стали бы писать эту книгу, если бы считали эти причины достаточными, чтобы лишить привлекательности управление рисками в целом. Тем не менее, вам следует знать о минусах, равно как и о плюсах.

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

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

1. Наши акционеры не являются достаточно зрелыми, чтобы смотреть риску в лицо.

«Если бы мы сказали правду, наши акционеры слишком испугались бы и отказались от проекта, поэтому мы вынуждены им лгать».

В этой ситуации ложь представляют истинным общественным служением.

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

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

Однако сегодняшние участники проектов – совсем иные. Они, как правило, более могущественны, чем их IТ-партнеры, и они уже больше разбираются в предмете. Они соображают в вопросах автоматизации. Более того, у них отличная память.

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

2. Уровень неопределенности слишком велик.

«Я готов указать диапазон, в котором будет дата завершения, но не такой большой».

Многие руководители проектов по созданию программного обеспечения теоретически готовы бороться с неопределенностью в своих проектах, но их ошеломляет размер этих неопределенностей. Если бы они могли использовать методы управления рисками, чтобы показать дату поставки плюс-минус 2% или 5%, они были бы в восторге. Но неопределенность в нашей области значительно больше. Тщательная оценка возможных причин задержки обяжет признать что-то в таком роде: «Поставку можно ожидать между 18-м и 29-м такого-то месяца, причем с 85% достоверностью можно назвать 24-е число».

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

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

3. Заданный в явном виде диапазон неопределенности оправдывает плохую работу.

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

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

4. Подход «управление ради успеха» лучше.

«Смотрите, мы не занимаемся управлением рисками, но следим за рисками и делаем все, чтобы они не происходили».

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

5. Не хватает данных для эффективного управления рисками.

«Мы недостаточно знаем про риски, которые повлияют на этот проект».

Многие риски, грозящие данному проекту, являются уникальными для этого проекта. Уникальные риски происходят от самого продукта, а также от культурной и политической среды проекта. Данных относительно некоторых из этих рисков немного или нет вовсе. Однако главные риски, с которыми сталкивается большинство проектов, являются общими для всех IТ-проектов. Если вы располагаете данными по общим рискам, у вас есть необходимые средства, чтобы сдерживать большинство рисков.

6. Опасно управлять рисками в изоляции.

«Я не осмелюсь быть единственным, кто честно осуществляет управление рисками».

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

Если вы работаете в организации, где управление рисками не практикуется достаточно широко, вы все же можете использовать в своем проекте некоторые его инструменты и методы, но не стоит афишировать свои открытия. Говорить правду в обстановке, где нормой является оптимизм (ложь) – значит оказаться в крайне невыгодном положении. Если вы утверждаете, что есть лишь 10%-ная вероятность сдать проект в желательный клиенту срок, вы предоставляете возможность коллеге-конкуренту сказать: «Босс, поручите это мне, и я все сделаю вовремя, гарантирую вам».

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

Глава 6

Бремя ответственности за неопределенность

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

Ошибаться – нормально, но неопределенность – не приветствуется.

Если это правило описывает вашу компанию, вы пропали.

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

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

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

«А, вы имеете в виду этот приближающийся поезд!»

Симптомы очевидны. Люди тщательно заботятся о том, чтобы не споткнуться о шпалу, но никто не видит приближающегося поезда. Риски определены, перечень рисков опубликован, риски указаны в важных отчетах и одобрены стратегии по их снижению. Риски отслеживают, за ними ведется наблюдение. Если кто-то только просмотрит перечни и описания рисков, покажется, что уровень риска у проекта низок. Все перечисленные риски относятся к несущественным деталям и мелким неудобствам. Отслеживание риска идет без отклонений, пока проект внезапно не гибнет, часто с последующими яростными судебными претензиями к трупу. Вот несколько примеров:

• Клинический случай 1. Подрядчик строит для клиента систему «под ключ». Все вроде бы находится под контролем. Есть некоторые проблемы, но все они перечислены в списке рисков, и нет ни малейшего намека на возможность провала. Затем завершенная система поставляется клиенту, но наотрез им отвергается. В договоре указано, что спецификация новой системы должна быть одобрена обеими сторонами. Но спецификации не получили одобрения. Ни разу за всю историю проекта никому не пришло в голову добавить в список риск «у нас нет формального согласования по поводу того, что мы строим».

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

Вариации на тему

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

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

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

К счастью, существует вакцина

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

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

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

Глава 7

Удача

ТРЛ: Удачи вашему следующему проекту… но не рассчитывайте на нее.

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

«Мы рискнем в таком случае»

Можете ли вы вообразить реальный риск (нечто плохое, что вполне может произойти и непременно повлечь ужасные последствия), которым нет смысла управлять? Такой, что его даже и в перечень вносить не стоит?

Например, часто рассматриваемый на наших семинарах по управлению рисками «астероид, уничтожающий компанию». Каковы характеристики астероидного риска, делающие его совсем не стоящим управленческих попыток? Мы называем две:

1. Вероятность материализации риска достаточно мала, чтобы ее можно было игнорировать.

2. При материализации риска делается ненужным усилие, являющееся объектом управления (создаваемый вами программный продукт).

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

Две указанных выше причины позволяют вам проигнорировать астероидный риск. А вот еще две резонные причины отказаться от попыток управлять риском:

1. У риска незначительные последствия, и потому он не требует ослабления.

2. Это – чужой риск.

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

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

Почему в каких-то случаях вы не управляете реальными и значимыми рисками, угрожающими вашему проекту, а вместо этого рассчитываете на удачу, надеясь, что она им воспрепятствует? Например, положим, что проект попал к вам в форме личного вызова такого типа: «Я знаю, апрель – это трудный срок, потому-то я и поручаю эту работу вам!»