А теперь IT-менеджер Джек. Он покупает билет на 8:40 в пятницу. Поймав такси в городе в 7:05, попадает в пробку и гневно жалуется на это шоферу всю дорогу до аэропорта. Тупой водитель никак не уразумеет, как важно Джеку не опоздать на этот рейс. Pегистрируясь в аэропорту, он с нажимом объясняет клерку, что самолет должен взлететь и приземлиться точно по расписанию и никаких оправданий он не примет. Он говорит, что будет «весьма и весьма разочарован» в случае любого опоздания. Когда объявляют о задержке рейса, Джек вскакивает и громко ругается. Когда объявляется измененное время отправки рейса, он роется в своих управленческих инструментах и выкапывает оттуда ультиматум: «Если меня не доставят вовремя на совещание в Сан-Франциско, ПОЛЕТЯТ ГОЛОВЫ!»
В проектах, где критичен срок сдачи, реальным ослаблением риска является раннее начало. Это, пожалуй, единственный эффективный способ сдерживания риска опоздания для большинства проектов. Да, мы знаем, что уже слишком поздно, чтобы начать наш проект рано, он начался, когда начался, и вы уже влипли. И вы читаете эту книгу не для того, чтобы узнать, как вы могли бы так не влипнуть. Вы хотите найти выход из этого положения. Все это правда. Но выбор раннего старта все равно для вас полезен, как будет показано ниже.
Отважное и робкое руководство
Во-первых, следует разобраться с одним деловым поверьем, которое иначе будет мешаться у нас на дороге: представление о том, что начинать проект без малейшего запаса времени – признак по-настоящему отважного стиля руководства, а противоположное является признаком трусости.
Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:
Сейчас в экономике некоторый спад, но в ближайшие пару кварталов дело должно выправиться. Начиная сейчас создавать новую версию нашего продукта, мы опередим своих конкурентов, когда рынок оживет, следовательно, нам нужно браться за осуществление этого проекта. Но что будет, если рынок не восстановится в ожидаемые нами сроки? Может, лучше подождать, пока это произойдет на самом деле. Если спрос возрастет в начале следующего года, тогда мы и начнем этот проект. А если спячка продержится до лета, мы сможем до той поры легко обойтись без затрат на этот проект.
Это – робкое руководство в худшем своем проявлении.
С другой стороны, дерзкое руководство стремится идти на возможное увеличение рисков, если это окупится. Всегда требуется мужество, чтобы начинать проекты достаточно рано. Это всегда требует от кого-то решения, которое еще не оправдано рынком. Это означает трату денег на что-то не вполне надежное.
Ирония состоит в том, что множество проектов оказываются под угрозой срыва сроков поставки из-за того, что руководители ушли от другого риска, куда более важного, связанного с ранним стартом.
Почему важна возможность раннего старта, даже если вы не можете ее реализовать
Проекты, которые завершаются с опозданием – это почти всегда те проекты, которые слишком поздно начаты. А слишком поздно начатые проекты – признак нехватки видения и мужества у высшего руководства. Если вам грозят снести голову за недостаточно быстрое завершение работы, вы быстро понимаете, что проект был начат недостаточно рано. Это – заклинание, которое многим организациям следовало бы принять на вооружение.
ТДМ: В начале 1996 года одна из моих клиенток была менеджером крупного проекта по разработке встроенного программного обеспечения. Ее задача состояла в создании системного программного обеспечения новой линейки товаров, которую отдел маркетинга рвался срочно запустить на рынок. Главным заказчиком для нее был руководитель службы маркетинга Ганс, который выдвинул этот проект и получил на него финансирование. Ганс рассердился, когда команда моей клиентки назначила сроком сдачи четвертый квартал 1997 года. Он настаивал на сдаче 31 марта 1997 года. Он заклеймил ее расчеты на публичном совещании, объявив их недостаточно напористыми, и завершил свою речь словами (к несчастью для него): «Я берусь доказать, что каждый месяц после марта компания будет терять в виде упущенной прибыли 110000 долларов, если не будет готова отгружать эти товары».
Я уточнил у него по поводу этого заявления: «Ганс, а эта цифра относится к сроку завершения до 31 марта? Если бы мы завершили к концу февраля, например, получили бы мы дополнительно 110000 долларов прибыли, сверх запланированного вами дохода?»
«Да, – сказал он. – Наверняка».
«А если бы закончили к концу января? – настаивал я. – Дало бы это еще 110000 долларов прибыли?»
«Да», – ответил он.
«А если бы мы могли вручить вам готовый продукт сегодня (это было в феврале 1996 года, когда только было открыто финансирование проекта) вы бы получали дополнительно по 110000 долларов ежемесячно до конца года?»
«Да», – ответил он, теперь несколько потеряв былую самоуверенность.
«Ну тогда, Ганс, очевидно, что вы слишком поздно начали этот проект. Если бы вы дали старт 18 месяцев назад, мы бы могли уже отгружать этот продукт и получать все эти месяцы по 110000 долларов дополнительной прибыли…» Я предоставил ему самостоятельно понять, что подразумевалось.
• Сколько риска можно себе позволить?
• Как ценность компенсирует риски?
• Как можно реалистично оценить ценность (выгоду) нового проекта?
• Как можно убедиться, что ожидаемая выгода реально получена?
• Как обращаться с выгодой, которая представляет собой неопределенную величину?
• Какой смысл в обосновании выгод и затрат, которое пытается сравнить неопределенные затраты с неопределенной выгодой?
Глава 18
Количественная оценка ценности
Вначале, на заре IT-индустрии, обоснование для создания новых продуктов было очень простым. Системы, которые тогда устанавливали, обычно заменяли ручной труд клерков. Экономия трудозатрат и была мерилом выгоды, а затраты на разработку системы – издержками. Анализ выгод и затрат и вывел простые соотношения типа:
Прибыль на инвестиции =(Ценность – Затраты) / Затраты
Для демонстрации своего почтения к стоимости денег во времени, мы выражали различные потоки затрат и сбережений в терминах чистой приведенной стоимости (NPV). Мы могли бы и проще выразить это в формулировке типа «решение запустить проект сейчас равноценно добавлению сегодня в денежный сундук корпорации чистой приведенной стоимости в размере 1,3 млн долларов».
Порой обоснование принимало слегка иную форму:
ТДМ: Одной из первых моих обязанностей менеджера было управление проектом по установке программы централизованного биллинга для French National Merchandise Marte La Villette (Париж). Планировалась замена старой системы, находившейся в филиале в Les Halles. В La Villette вся биллинговая информация передавалась в цифровой форме. Ручная система для исполнения той же функции в Les Halles использовала сеть пневматических труб для отсылки квитанций и счетов, которые под давлением воздуха носились со свистом по всему этажу. Сеть пневматических труб была установлена в Les Halles во времена Всемирной выставки в 1897 году. В 1897 году еще почти не было резиновых изделий, чтобы обеспечить герметичность, поэтому трубы были целиком сделаны из свинца. Когда строили Les Halles, цена свинца составляла всего несколько сантимов за килограмм. Когда мы их демонтировали, цена свинца составляла более семи франков за килограмм. А там было очень много свинца. Денег, вырученных при сдаче свинца в утиль, хватило для оплаты всего проекта, включая аппаратное оборудование и программное обеспечение.
Что изменилось сегодня?
Времена изменились. Большая часть обеспечивающих прямую экономию систем построена давным-давно. Сегодня вместо создания систем, компенсирующих затраты, чаще осуществляют проекты, направленные на улучшение позиции компании на рынке. Такие системы расширения рынка гораздо труднее обосновать. Мы как отрасль взяли себе за правило давать менее строгие обоснования. Новые системы часто обосновывают фразами типа: «Нам это необходимо» или «Эта система нам нужна, чтобы сохранить конкурентоспособность».
В то время как обоснование выгоды в анализе выгод и затрат и становилось все более слабым, требования к строгости и точности затрат возрастали. Поэтому стало привычным видеть обоснования нового проекта такого типа:
Затраты = $6235812,55
Выгоды = «Нам это необходимо»
Когда стоимость проекта строго ограничена, а выгода обозначена самым туманным образом, с разработчиков требуют ответственности за затраты, а за выгоду не отвечает никто. Тогда проект волей-неволей сокращает функциональность ради того, чтобы отвечать заданным рамкам по стоимости. Поскольку никто не побеспокоился сформулировать, в чем состоит главная выгода, нет надежного критерия для отбрасывания одной функции, а не другой. Чаше всего происходит плохая реализация выгоды и тыканье пальцем наугад.
