Прежде чем отправиться в плавание, научитесь обходить водовороты, которые могут затопить весь проект
Фиаско, которое в марте потерпела информационная система Федеральной налоговой службы (IRS - Internal Revenue Service), пожалуй, можно назвать худшим из всех провалов. Хотя в течение 20 лет у организации была возможность отойти от изначально порочного и постоянно “уходящего из-под контроля” проекта, руководящие чиновники IRS спрятали головы в песок и позволили долларам постепенно уплывать. В результате по меньшей мере 4 млрд. долл. из карманов налогоплательщиков выброшены на ветер.
По большому счету причина неудачи IRS в том, что было нарушено (или проигнорировано) главное правило эффективного проектного менеджмента - определение управляемых, реальных сроков исполнения. Эта проблема хорошо знакома менеджеру по информатизации компании Hilton Hotels Corp. Джо дю Роше. Ему пришлось собирать осколки автоматизированной системы бронирования Confirm стоимостью 125 млн. долл., которая не смогла сдвинуться с мертвой точки. Поскольку с самого начала проект не был подвергнут квалифицированной оценке, впоследствии выяснилось, что разработка системы “с нуля” оказалась неподъемной.
И хотя дю Роше не был причастен к неудаче с системой Confirm, он извлек из этого случая бесценный урок: он понял, что каждый проект должен быть разделен на управляемые фрагменты. “Не нужно браться за проект, который завтра будет отвечать сегодняшним требованиям. Если вам не удается уложить его выполнение в один-полтора года, лучше его вообще не начинать”, - говорит он. Сейчас компания Hilton намерена приобрести систему бронирования, похожую на неудавшуюся систему Confirm. Но на этот раз она пошла по пути покупки, а не создания.
Разбить на Части
К счастью, большинству служащих отделов информационных технологий (ИТ) не приходится ежедневно переживать неудачи таких трагических размеров, как в случае с IRS или системой Confirm. Но они могут воспользоваться бесценным опытом, чтобы обезопасить свои собственные проекты. Наверное, не менее важно научиться замечать “предупреждающие знаки”. Это поможет им сократить потери на вышедшем из-под контроля проекте до того, как он подкосит работу группы ИТ или, еще хуже, станет угрожать благосостоянию всей фирмы.
Эксперты по проектному менеджменту утверждают, что система IRS, отягощенная слишком широким охватом, отсутствием собственных экспертов и неудачным выбором технологии, с самого начала проявляла все признаки несостоятельности. Как отмечалось в газете The New York Times, проект прошел сквозь многочисленные попытки реанимации, прежде чем агентство смирилось с банкротством.
“Одной из их главных ошибок было желание "вскипятить океан", - сказал Малькольм Франк, вице-президент Cambridge Technology Partners, консультационной фирмы в г. Кеймбридже, шт. Массачусетс. - Значение имеет время, отведенное на разработку. Мы становимся свидетелями того, что бизнес-процессы меняются быстрее, чем способны сменяться технологии. Если вы планируете потратить на создание системы два года, она уже не будет актуальна к моменту готовности”.
Как уже поняло руководство Hilton, жизненным вопросом любого проекта является разбиение его на несколько осуществимых (например, за 4 - 6 месяцев) управляемых частей. Это мнение Гопала Капура, президента Center for Project Management (Сан-Рамон, шт. Калифорния).
Но хотя разбиение на части - практически универсальное правило проектного менеджмента, ошибки при анализе на начальных этапах обычно приводят к невозможности осмысленного разбиения или определения границ проекта. Так считает Крис Моффит, директор и основатель Diamond Technologies Partners (Чикаго). “Кажется, служба IRS не проанализировала в достаточной степени возможность разбиения проекта на сотни более мелких частей, - говорит Крис. - Они, видимо, подходили к вопросу по принципу "все сразу". Щелкаете выключателем, и во всей стране гаснет свет. Так просто это не бывает”.
Измерения, измерения и еще раз измерения
По мнению Капура, другой немаловажной частью работы является определение единиц измерения для оценки развития проекта, причем это нужно сделать еще на стадии подготовки проекта. А когда проект заработает, скорее всего ответственные менеджеры не в силах будут его остановить.
“Существует очень немного организаций, которым удается сократить потери. Почему люди, сбившиеся с пути, не спрашивают дорогу в течение долгих часов? Конечно, в энтузиастах, целиком отдающих себя своим проектам и уверенных, что они могут заставить их работать, что-то есть”, - считает Капур. Но там, где четко определены единицы измерения (например, предельно допустимая сумма затрат - 1,5 млн. долл.), легко остановить проект прежде, чем он раздуется до размеров краха IRS.
“Вопрос "при каких обстоятельствах вы распрощаетесь с проектом?" является составной частью определения единиц измерения”, - говорит Капур. Возможно, подобная перспектива обрадует немногих, но с этим неминуемо придется столкнуться исполнителям проекта, даже если они считают, что в начале разработки нет времени на выбор соответствующих единиц.
У дю Роше из компании Hilton нет теплых слов в адрес администраторов отделов ИТ, утверждающих, что они слишком заняты и не могут следить за каждым шагом проекта: “Необходимо личное участие в осуществлении проекта. Вы не должны просто заседать в офисе, изучая отчеты. Только тогда вы сможете быстро отслеживать сбои и принимать соответствующие меры”.
Капур отмечает, что спонсорам проекта недостаточно просто “открыть двери” проектным менеджерам. “Меня не волнует политика открытых дверей. Мне нужно знать, будут ли мне уделять внимание в течение восьми часов в месяц или столько, сколько потребует проект, - говорит он. - Тут-то мы и скажем спонсору: вы эксперт по вопросам стратегии. Если у вас нет времени, произойдет разрыв между спонсором и проектными менеджерами”.
“Этот разрыв и может проявиться в коммуникационном развале, - считает дю Роше, который неоднократно был свидетелем подобных развалов в течение своей 33-летней практики работы с отделами ИТ. - Обычно люди привыкают к безопасному общению. Они перестают общаться и начинают замалчивать факты, чувствуя приближение развала. Вскоре проблемы начинают проявляться в срыве отведенных сроков и выходе за границы бюджета, но к тому моменту бывает уже слишком поздно”.
Дю Роше рассказал, что его сотрудники тоже пытаются совладать с плотно подогнанными поджимающими бизнес-циклами: “В какой-то момент исполнители не могут ничего сделать по существу, потому что в игре так быстро меняются правила, что реагировать просто некогда”.
Расставить все по местам
Возможно, это покажется очевидным, но есть еще один способ удержать проект “в колее” - формулирование бизнес-пакета на стадии разработки проекта. Это не простая задача. “Администраторы отделов ИТ, прежде чем начать развитие проекта, обычно не прибегают к анализу бизнес-пакета, а если и прибегают, то не пользуются им, когда начинается внедрение проекта”, - говорит Моффитт. Исполнители должны в качестве отправной точки четко определять стоимость каждого проекта для того, чтобы расставить приоритеты среди его компонентов. Даже там, где доход будет невелик (например, развитие Web-узла), нужно дать спонсорам представление о стоимости проекта.
“Одно распространенное заблуждение по отношению к проектному менеджменту заключается в том, что главной причиной всех бед считается раздувание бюджета”, - продолжает он. На самом же деле изменение сроков исполнения проекта подобно смерти. Худшее из того, что вы можете предпринять, это изменить сроки. Тем самым вы воздействуете на дух и настрой команды, что совершенно необходимо для успеха. Но вы можете манипулировать бюджетом и размерами проекта, не боясь повлиять на дух исполнителей”.
Порой, однако, даже лучшие из ваших начинаний оказываются неудачными, и тогда нужно смириться с провалом. И если так случилось, сделайте глубокий вдох и уйдите под воду. И поблагодарите небеса, что вы не работаете в IRS.
Лорен Гиббонс Пол
Семь “смертных грехов”, ведущих к провалу проекта
Менеджеры не способствуют успеху
проекта, если...
1 ...принимают наполовину продуманные
идеи за жизнеспособные проекты
2 ...диктуют нереальные сроки исполнения проекта
3 ...назначают недостаточно квалифицированных проектных менеджеров для работы с очень сложными проектами
4 ...не подкрепляют проект прочным бизнес-спонсорством
5 ...не способны разбить проект на части
6 ...не умеют определить твердую схему развития проекта
7 ...не создают обстоятельного проектного пакета
