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

11. Последовало ли руководство ДМА этому совету? Поскольку время для такого обширного тестирования и отладки не было запланировано, предпочли обойтись без этого.

12. Делала ли команда проекта достаточно внятные предупреждения об угрожающем запаздывании? Прежде всего, невидимая рука рынка сделала важный жест прямо в самом начале. Когда Совет управляющих ДМА первый раз объявил тендер на выполнение этой системы программного обеспечения, никто не хотел подавать заявку при указанной дате поставки готового продукта. Все подрядчики считали, что начинать проект при таком расписании было надежным способом навлечь на себя неизбежные неприятности.

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

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

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

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

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

В данном случае все издержки в конечном счете падали на головное агентство «Denver Airport System», которое было частью городского управления. Таким образом, городские власти Денвера несли ответственность за управление финансовыми рисками, к чему они не приложили ни малейших усилий.

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

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

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

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

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

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

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

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

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