Статья только в электронной версии журнала
Крушение проекта не означает конца карьеры руководителей отделов ИТ: они смогут выжить, если будут следовать лучшим методикам менеджмента
Эйлин Кроули
В прошлом году Брайан Гаравузо почувствовал, что надвигается буря. В ее эпицентре был проект учета ресурсов, на безуспешные попытки внедрения которого его команда специалистов по ИТ ухлопала большую часть предыдущих шести месяцев. Сроки завершения отодвигались все дальше и дальше, интерес со стороны бизнес-подразделений падал, и Гаравузо понял - пришло время “утопить” проект, пока он не потянул на дно и его собственную репутацию, и репутацию всего отдела ИТ.
Ясно, что гордиться здесь нечем, но Гаравузо, вице-президент по ИТ компании South Seas Resorts (Форт-Майерс, шт. Флорида), хорошо понимает - такова жизнь. Всякому руководителю ИТ либо уже приходилось, либо еще придется участвовать в проекте, который не смог удержаться на плаву. По оценке организации The Center for Project Management (Сан-Рамон, шт. Калифорния), 30% из числа начатых ИТ-проектов не доживают до стадии завершения. Однако крушение проекта необязательно должно означать конец карьеры его участников. Разумно мыслящие ИТ-менеджеры, которые, подобно Гаравузо, следуют лучшим из основных методик управления проектами и знают, когда нужно закрыть финансирование, чтобы избежать более серьезных убытков, умеют успешно плавать в этих бурных водах, сохраняя и свои рабочие места, и репутацию отделов ИТ.
Отставание от графика
Зачастую проект ложится в дрейф по вине непредсказуемых обстоятельств, типа текучести кадров или изменения бизнес-требований. Но многих других факторов, способных помешать успеху проекта, - например, недооценки масштабов работы или неудачи в формировании заинтересованности деловых пользователей, - можно избежать, а иногда даже обратить их на пользу отделу ИТ, правда, ИТ-менеджеру для этого придется хорошенько побегать.
Один из приемов - это установка контрольных точек, отклонение от которых служит для ИТ-менеджеров тревожным предупреждением о том, что проект сбился с курса. Подготовка планов действий на случай непредвиденных обстоятельств также может сыграть важную роль в случае изменения требований при выполнении отдельных работ. И наконец, регулярный пересмотр бизнес-целей в ходе разработки не только подкрепляет способность ИТ-организации реализовывать серьезные проекты, но и может помочь заместителю директора по информатизации и другим высшим менеджерам пережить угрожающие их карьерам штормы, частенько разражающиеся после того, как технологические проекты уходят на свалку.
“Остановка проекта вовсе не означает неудачу, - утверждает Чип Глидман, аналитик из фирмы Giga Information Group (Санта-Клара, шт. Калифорния). - Это, в сущности, демонстрация того факта, что ИТ-руководители хорошо знакомы с меняющимися потребностями бизнеса и не хотят тратить ресурсы на то, что не принесет реальной пользы для дела”.
Спасательной шлюпкой, на которой Гаравузо из South Seas выплыл во время катастрофы прошлогоднего проекта, было регулярное и откровенное общение с высшим руководством компании. Исходной целью приостановленного в декабре прошлого года проекта было помочь менеджерам курортных гостиниц автоматизировать сбор и организацию данных о девяти земельных участках, составляющих владения South Seas.
Во время проходившего в начале 1997 г. совещания по этому вопросу, в котором участвовали исполнительный директор компании и другие ее руководители, перед Гаравузо и его сотрудниками была поставлена задача найти оптимальную технологию реализации проекта. “Проект был поддержан на всех уровнях, вплоть до исполнительного директора, и рассматривался как приоритетная задача”, - вспоминает Гаравузо.
В основе проекта лежали два ключевых требования: во-первых, избавить сотрудников, контролирующих каждый курорт, от ежедневного ввода в электронные таблицы Lotus 1-2-3 корпорации Lotus Development данных о занятости мест и продажах, а во-вторых, сформировать трехмерную БД, позволяющую менеджерам осуществлять углубленный анализ данных. Группа Гаравузо выбрала пакет OLAP (онлайновая аналитическая обработка) под названием Decisions производства фирмы Datavision Technologies (Стамфорд, шт. Коннектикут).
Гаравузо и исполнительный директор South Seas отчетливо понимали, какие преимущества в конкурентной борьбе дают подобного рода приложения - это, например, возможность прогнозирования периодов низкого спроса на места в гостиницах или более эффективного выявления регулярных посетителей курортов, - но они не учли того, что в использовании таких приложений должны быть заинтересованы контролеры и менеджеры курортов. “Движущей силой инициативы была только группа ИТ, и это должно было послужить для нас предупреждающим сигналом еще в самом начале проекта”, - признает Гаравузо.
Только резкий прирост продаж мог бы привлечь внимание контролеров и менеджеров курортов к преимуществам новой системы перед ручными способами формирования отчетов. Так что, когда дело дошло до участия контролеров в тестировании - на определенном его этапе от них требовалось сравнить достоверность данных, полученных с помощью новой системы, с привычными ежедневными балансами - они просто-напросто не рассматривали это как приоритетную задачу.
“Мы не смогли дать пользователям почувствовать, что система станет их помощником в работе. Все это воспринималось как навязываемая сверху дополнительная нагрузка”, - рассказывает Гаравузо.
Основной план предусматривал наполнение расположенной в центральном офисе OLAP-БД и предоставление менеджерам на каждом из курортов возможности получать ежедневные отчеты, а также запрашивать данные по мере надобности.
Следующей фазой внедрения была разработка интерфейса, позволяющего системе Decisions напрямую подключаться к центральной СУБД-системе управления курортами SMSHost, функционирующей на IBM RS/6000 фирмы Springer-Miller Systems. Это избавило бы контролеров от необходимости ручного ввода данных и позволило бы менеджерам напрямую запрашивать данные, хранящиеся в системе SMSHost.
Избежав ошибки в выборе технологии, руководители проекта допустили другую - они недостаточно заинтересовали бизнес-подразделения, и это ускорило кончину проекта. Например, на предусмотренном планом внедрения этапе тестирования контролеры должны были проверить достоверность данных, полученных с помощью новой системы, и сообщить результаты этой проверки в течение 4 - 5 рабочих дней. Но поскольку контролерам не сообщили об этом предельном сроке, они и не собирались в него укладываться.
“Контрольные сроки начали ползти, - с горечью говорит Гаравузо. - Мы рассчитывали наверстать упущенное, но отсрочки продолжались”.
Погоня за сроками - это распространенная западня, часто свидетельствующая о катастрофе ИТ-проектов. Как только контрольные точки не достигаются, а сроки откладываются, становится невозможно наверстать отставание в дальнейшей работе над проектом. Менеджеры, думающие, что они могут разрешить сдвигать предельные сроки, занимаются самообманом - так считает Гопал Капур, президент компании Center for Project Management.
Для того чтобы все участники проекта были честны перед собой и четко осведомлены о реально выполненных работах, Капур рекомендует назначать контрольные точки - например, связанные с завершением реализации определенных функций или достижением некоторого объема кода, реализованного в рамках проекта, - и планировать даты их прохождения каждые десять дней. При таком подходе, как только возникнут проблемы и контрольные сроки будут нарушены, проект можно пересмотреть для определения его жизнеспособности.
Политические шквалы
Назначение проекту специально выделенного куратора, сотрудника из сферы бизнеса, - вот еще один способ не дать работам сбиться с курса и избежать политической возни вокруг них, считает ветеран управления проектами Джед Уильямс, бывший главный менеджер по информатизации одной из крупных компаний - производителей потребительских товаров. Когда в феврале прошлого года Уильямс покинул этот пост, у него был один “политически наэлектризованный” проект, споры вокруг которого группы ИТ и маркетинга вели аж с начала предыдущей осени. Этот проект, в рамках которого разрабатывалась система управления базой знаний, способная предоставить всем сотрудникам службы маркетинга доступ к ретроспективной информации о рынках и продажах, в том числе к данным о конкурентах, лег в дрейф, по мнению Уильямса, именно из-за отсутствия якоря - конкретного бизнес-куратора.
“Я считал этот проект отличной идеей и вел с вице-президентом по маркетингу беседы с глазу на глаз, во время которых мы обсуждали способы использования его результатов, но брать поддержку проекта только на себя я не собирался”, - рассказывает Уильямс.
Уильямс отказывался подписывать документ о запуске проекта до тех пор, пока не будет получено его официальное одобрение партнерами по бизнесу. Хотя вице-президент по маркетингу высказывался в пользу построения системы, он не соглашался специально выделить одного из своих высших менеджеров для работы с группой ИТ.
“Это яркий пример того, почему заинтересованность бизнес-подразделений обязательна для ИТ-проекта, - сказал Уильямс. - Каждый менеджер трактует понятие управления базой знаний по-своему, а если бизнес-подразделения не могут четко определить, что это такое и чего они хотят, то как же вы собираетесь его для них реализовать?”
Уильямс считает, что запуск проекта лишь после того, как его поддержат бизнес-подразделения, является одним из лучших способов избежать в дальнейшем прекращения начатых работ. “В этом случае мне никогда не придется "обесточивать" проект, поскольку его просто "не включат в розетку" с самого начала”, - говорит он.
Отсутствие бизнес-куратора и четко определенного графика выдачи результатов реализации проекта может породить еще один смертельный для проектов фактор - “указывание пальцами” в попытках переложить ответственность или найти виноватых. Поддаться этому искушению, особенно когда в проект вовлечены сторонние консультанты, - это то, чего надо избежать во что бы то ни стало, - так считает пожелавший остаться неназванным руководитель ИТ одной из крупных финансовых фирм, привлекавшийся к оценке жизнеспособности проекта, который разрабатывался 18 месяцев и имел через шесть месяцев после того, как прошел запланированный срок достижения первых конкретных результатов, по-прежнему нулевой выход. “Когда начинают показывать пальцами друг на друга - это признак того, что проект терпит бедствие”, - сказал этот менеджер.
Проект, о котором он рассказал, представлял собой попытку создания системы работы со счетами в интрасети на базе Java, и угроза нависла над ним почти с самого начала, ибо менеджеры проекта в этой финансовой компании не слишком хорошо представляли себе суть прикладных проблем, которые они собирались решать.
Потеря сосредоточенности на исходных прикладных задачах, реализуемых проектом, и углубление вместо этого в технологические вопросы могут быть не менее губительны, считает Хантли Бейкич, вице-президент по электронной коммерции из компании Sun America (Лос-Анджелес), являющейся поставщиком финансовых услуг. Поскольку ИТ-группа, естественно, должна доказывать возможности новой технологии решать прикладные проблемы, ее члены иногда начинают излишне “оберегать” проект от его же пользователей или желают дорабатывать его слишком долго. В такой области, как электронная коммерция, где шансы обойти конкурентов предоставляются редко и ненадолго, подобная привязанность разработчиков к проекту является излишней роскошью.
“С одной стороны, это хорошо, что они считают проект своей собственностью, но с другой - это мешает им (отпускать( его в эксплуатацию”, - утверждает Бейкич.
Помощь терпящим бедствие
Бейкич полагает, что одним из способов избежать ощущения катастрофы при прекращении проекта является разработка резервного плана спасения хотя бы некоторых его частей. Это особенно важно в таких динамичных областях, как электронная коммерция. “Потребности бизнеса могут меняться столь быстро, что приходится быть всегда готовым к тому, чтобы сменить курс в середине работы или даже "выдернуть шнур", но продолжать движение вперед”, - считает он.
Бейкичу пришлось претворить эту философию в жизнь при работе с системой онлайновой торговли, как раз и изменившей направление в ходе реализации проекта. Прекращение этого проекта не привело к значительным убыткам, так как группа Бейкича сумела применить в новых условиях значительную часть как разработанного программного кода, так и аппаратуры, в том числе сервер среднего уровня, используемый для обработки транзакций.
Бейкич утверждает, что в его службе подобное аварийное планирование ведется всегда. Например, при построении клиентской части для транзакционной БД команда Бейкича разработала модульный код, позволяющий применить это же клиентское ПО для работы с другой БД. “Предположим, разработка первой версии клиентского ПО стоит $100 000 - тогда в следующий раз при реализации сходного проекта мы затратим только $20 000, поскольку сможем повторно использовать существенную часть предыдущих разработок”, - поделился он своим опытом.
Другие способы, которыми могут воспользоваться ИТ-руководители, чтобы не затонуть вместе с судном, - это оснащение проекта серьезными обоснованиями с точки зрения бизнеса, регулярная переоценка достигнутого результата и постоянное общение с коллегами по поводу текущих работ. Так, например, Гаравузо из South Seas не пытался скрыть от высшего руководства состояние идущего ко дну проекта учета ресурсов.
Именно такая открытость в общении, считает Гаравузо, позволила ему избежать опасности потерять работу, когда он принял решение о закрытии проекта. “Это было оптимальным решением - продолжение работ все равно не решило бы никаких проблем”, - утверждает он.
Для того чтобы уменьшить потери средств, затраченных на ПО Decisions, Гаравузо попытался спасти часть результатов проекта. Эта программа сейчас используется в корпоративном офисе South Seas для формирования отчетов с прогнозами и информации о бюджете.
Что же касается учетной системы, то South Seas решила начать с самого начала. Группа Гаравузо сейчас разрабатывает с помощью Microsoft Visual FoxPro новую реляционную БД, которая в конце концов будет доступна всем менеджерам и контролерам. В этой системе не будет той простоты использования или изощренных возможностей генерации отчетов, которые предоставляет клиентское ПО Decisions, но зато она будет поддерживать функции сравнения ежедневных данных о продажах, отсутствующие в отчетах Lotus 1-2-3.
“Это решение не столь красиво, но оно покрывает примерно 50% наших потребностей”, - рассказывает он.
Кроме того, сейчас ИТ-группа South Seas более тесно работает с контролерами и менеджерами отелей, собирая их предложения и пожелания по механизмам обратной связи, которые они хотели бы видеть в будущих системах.
“Как только система заработает и пользователи почувствуют ее преимущества, мы получим возможность начать расширение проекта”, - утверждает Гаравузо.
Так что теперь Гаравузо стал настоящим морским волком, и он рассчитывает установить с бизнес-подразделениями такие отношения, которые гарантируют спокойное плавание.
Когда нужно прекращать проект
Прежде чем ИТ-проект потерпит неудачу, всегда проявляются ранние предупреждающие признаки. Умение распознавать эти сигналы и эффективно работать с ними - важный фактор профессионализма ИТ-руководителя. Как только вы увидели какой-нибудь из этих красных флажков, начинайте пересмотр проекта:
Отсутствие заслуживающего доверия бизнес-плана. Несмотря на то, что это кажется наиболее очевидной частью крупного проекта, данным этапом часто пренебрегают. Отсутствие такого плана должно останавливать проект еще в самом начале.
Размер проекта. Когда проект слишком масштабен, увеличивается вероятность неудачи. Реорганизуйте работы в рамках нескольких более компактных проектов с отдельными лидерами и одним менеджером большого проекта, наблюдающим за контрольными сроками. Это позволит лучше организовать взаимодействие и повысить управляемость проекта.
Текучесть кадров. Если текучесть кадров значительна - скажем, более 10% за две недели, - проект должен быть пересмотрен или приостановлен до тех пор, пока новые сотрудники полностью не включатся в работу. Попытка продолжать работы параллельно с обучением новых работников приведет к срыву контрольных сроков и потенциальному провалу проекта.
Перерасход средств. Если проект выходит за рамки бюджета, убедитесь, что его бизнес-куратор согласен с новой сметой.
Потеря бизнес-куратора. Если главный менеджер проекта со стороны бизнес-подразделений покидает компанию или получает новое назначение, дальнейший ход работ ставится под угрозу. Убедитесь, что назначен новый куратор и добейтесь полной поддержки проекта с его стороны.
Незаметное разрастание масштабов работы. Если бизнес-кураторы постоянно дополняют проект новыми требованиями, считайте это предупредительным сигналом. Пересмотрите бизнес-цели и, если необходимы изменения, добейтесь одобрения бизнес-куратором новых видов промежуточных результатов, контрольных сроков и уточненной сметы расходов.
Несоблюдение контрольных сроков. Разрешение на перенос контрольных сроков - предупредительный знак, которым пренебрегают чаще всего, хотя он, вероятно, является самым опасным. Срыв сроков означает, что исходные оценки трудоемкости проекта сделаны недостаточно точно, и это порождает целую цепочку сорванных контрольных точек и промежуточных результатов.
Источник: данные PC Week.
Подробнее о некоторых неудачах
Когда провал проекта получает публичную огласку, результаты могут быть обескураживающими. Приводим здесь краткую сводку о двух из числа наиболее известных катастроф ИТ-проектов.
Организация: международный аэропорт г. Денвера.
Проект: автоматизированная система обработки багажа.
Предыстория: в 1989 г. был одобрен и запланирован к вводу в эксплуатацию в конце 1993 г. проект системы обработки багажа в аэропорту. Система предусматривала наличие 4000 автоматических тележек, транспортирующих багаж по дорожке длиной в 21 милю и управляемых лазерными сканерами, считывающими штрих-коды с багажных бирок. В результате из-за недоработок в системе четырежды откладывалась дата открытия всего аэропорта.
Потери: запуск системы был запланирован на конец 1993 г., но бесчисленные технические неполадки привели к сдвигу этой даты на февраль 1995 г. В итоге стоимость багажной системы превысила первоначальную смету на 85 млн. долл.
Организация: фирма Oxford Health Plans.
Проект: создание внутренней системы обработки претензий.
Предыстория: в 1993 г. было принято решение о замене СУБД-системы на базе ПО фирмы Pick Systems на систему с СУБД корпорации Oracle. Когда в сентябре 1996 г. система начала работать в онлайновом режиме, она моментально переполнилась потоком учетных данных о 1,5 млн. клиентов организаций здравоохранения и десятках тысяч врачей. В результате образовался затор в системе обработке претензий. Однажды пришлось даже приостановить рассылку ежемесячных сводок по счетам для тысяч своих клиентов.
Потери: проблемы, возникшие при внедрении новой системы стоимостью 100 млн. долл. стали одной из причин понесенных организациями здравоохранения убытков в размере 78,2 млн. долл. в III квартале 1997 г. и снижения доходов на 45,3 млн. долл. в I квартале этого года.
