В первых двух статьях данного цикла, посвященного причинам провала ИТ-проектов, мы обсудили вопросы, связанные с предварительной оценкой их эффективности и с распределением ответственности за их выполнение. Теперь поговорим о проблемах планирования и реализации планов. Как оценивают ситуацию зарубежные исследователи и привлеченные нами российские эксперты?
Детальные планы
Долгосрочное планирование само по себе является риском, считают зарубежные исследователи. Планы по реализации проекта, рассчитанные больше, чем на 90 дней, обладают такой же точностью, как телевизионные прогнозы погоды, поскольку на таком длительном промежутке времени условия ведения бизнеса изменяются быстрее, чем сам проект. И это — одна из самых распространенных причин, почему бизнес-пользователи отказываются от внедрения той или иной технологии.
Здесь наши респонденты продемонстрировали различие подходов. Так, по мнению Вячеслава Суханова, директора службы профессионального сервиса компании “АйТи”, описанная проблема — это частный случай, относящийся исключительно к длительным проектам: “Далеко не всегда условия ведения бизнеса более динамичны, чем исполнение ИТ-проекта. Грамотный исполнитель должен учитывать возможные изменения и предусматривать необходимый уровень адаптивности своего решения к вероятным изменениям бизнеса”. Более того, как отметил г-н Суханов, само по себе наличие детальных планов никак не может являться причиной провала проекта. Скорее наоборот, отсутствие детализации в планах исполнения проекта или низкокачественная их проработка, упущение существенных этапов, нереалистичные сроки, не включенные необходимые ресурсы, несвоевременная актуализация изначальных планов — всё это может привести к неудаче.
Его поддерживает Павел Алферов, заместитель генерального директора по управлению проектами и информационным сервисам в научно-исследовательской производственной компании “Электрон”, подчеркивая, что зарубежные исследователи смешивают два абсолютно разных понятия — длительность проекта и наличие детального плана его осуществления. Продолжительная реализация действительно является бичом современных ИТ, сложные и дорогие системы внедряются месяцами. Но, по словам г-на Алферова, ответ на это в последнее время нашли в виде SaaS и других аналогичных технологий, а что касается детальности планов, то ответ найден еще раньше — он называется “планирование методом набегающей волны”.
Со своей стороны Антон Левиков, ИТ-директор группы компаний “Новард”, высказал уверенность в том, что для успеха проекту нужно определенное постоянство внешней среды, поскольку её существенные изменения радикально влияют на проект. А бизнесу, где всё меняется за девяносто дней, проекты просто не нужны, здесь нужно умение выживать и приспосабливаться, и это совершенно другая тактика. В целом же г-н Левиков рассматривает изменения в бизнес-процессах как самый большой риск ИТ-проекта, хотя айтишники научились с этим бороться и применять “нарезку” проектов кусками, двигаясь путём маленьких побед. И главное — к плану должен еще прилагаться руководитель проекта, способный вносить изменения как в план, так и в сам проект.
В основном поддерживая вывод зарубежных исследователей, Андрей Педоренко, директор ИТ-департамента группы компаний “АльфаСтрахование”, указал на то, что сегодня данный риск становится всё актуальнее и постепенно выходит на передний план. Поэтому большую популярность начинают приобретать технологии BPM, позволяющие, с одной стороны, перейти от автоматизации функций к автоматизации процессов, а с другой — резко сократить время выпуска изменений.
Схожее мнение разделяет и председатель Комитета по стандартам Российского союза ИТ-директоров Марина Аншина: “Планирование ИТ-проектов — дело тонкое, это скорее искусство, чем наука. Многие сложные ИТ-проекты гибнут из-за слишком детального долговременного планирования”. Она пришла к выводу, что необходим концептуальный высокоуровневый план проекта, привязанный к организационным и другим изменениям компании, а также детальные планы на ближайший краткосрочный период. Причем следует помнить, что планы не догма и они должны меняться при изменении окружающей среды, стратегии и тактики компании.
А вот Сергей Колчин, заместитель директора ТЦ по проектному управлению компании “Инфосистемы Джет”, не вполне согласен с данным тезисом. С его точки зрения, промежуток в девяносто дней назвать длительным довольно сложно и существенные изменения за такое время могут произойти только в малом бизнесе. Если же ситуация и вправду такова, значит, нужно перейти на другие методологии ведения проектов, а может быть, и вообще отказаться от планов в классическом их понимании.
Проблемы коммуникаций
Как отмечается в зарубежных исследованиях, данные проблемы зачастую связаны с плохо организованной системой управления, неправильной приоритизацией усилий или медленным принятием решений при выполнении проектов. Случается, например, что бизнес-спонсор, который по ходу проектных работ должен консультироваться со своими коллегами или партнерами из других подразделений компании, не хочет это делать, или не может, или просто не умеет вести сложные переговоры. В результате решение затягивается и реализация проекта тормозится. К числу других проблем коммуникаций можно отнести отсутствие лидера, который был бы драйвером проведения изменений, или влиятельных руководителей, способных объединить интересы разных подразделений компании.
По мнению наших респондентов, данную оценку вряд ли можно считать корректной. Марина Аншина полагает, что в этом тезисе смешаны две проблемы: коммуникаций и ответственности за принятие решений. По ее словам, проблема коммуникаций существует в большинстве российских компаний, и это тем удивительнее, что сейчас есть масса технических возможностей. Однако многие компании еще не осознали, что им это дает. Но вот если в компании есть проблема в принятии решений, то руководству несомненно стоит задуматься об экстренных мерах, поскольку такая проблема существенно тормозит развитие бизнеса, а зачастую делает его просто невозможным. Еще существует довольно распространенный тип руководителя, который принимает все решения сам и не делегирует подчиненным даже их малую толику. Поэтому интересы разных руководителей в области ИТ должен объединять CIO, считает г-жа Аншина. И если он с этим не справляется, то стоит либо научиться этому, либо поискать себе работу поспокойнее и попроще.
Ее поддерживает Антон Левиков, по словам которого все коммуникации в проекте должны быть направлены на достижение результата. На практике же они имеют свойство скатываться к “дележке”, кто должен решать вновь возникающие мелкие или более крупные незапланированные задачи, а дальше — к обсуждению вопроса, кто виноват в том, что их вовремя не решили. Вообще у ИТ-проекта мало общего с кавалерийской атакой, скорее он наполнен методичной и однообразной разработкой функционала, нудным выявлением и устранением ошибок, многократным обучением и переобучением пользователей. А еще — нежеланием этих последних работать иначе, чем они привыкли. Идеально, если в ИТ-проекте есть бизнес-спонсор с возможностями “почти как” у первого лица, имеет место настрой и готовность организационными методами бороться с отторжением изменений. Но на практике именно ИТ-директор должен вытягивать проект при отсутствии спонсоров, неприятии изменений и конфликте интересов подразделений.
Медленное принятие решений — единственная проблема, с которой можно согласиться без всяких оговорок, считает Павел Алферов. “Задумчивость бизнеса” действительно является бичом множества проектов, как и отсутствие бизнес-лидеров, четко понимающих, зачем им нужна эта система.
Вячеслав Суханов рассматривает данный вывод зарубежных исследователей не как проблему коммуникаций, а как проблему организации работы проектной команды со стороны заказчика и недостаточной вовлеченности спонсора в ИТ-проект. Более того, если у исполнителя нет оперативной обратной связи в ходе работ, если разные представители заказчика по одному вопросу выдают прямо противоположные заключения, а у заказчика нет “третейского судьи”, который должен разрешить такую коллизию и принять окончательное решение, то это очень серьезная проблема и явный шанс на провал проекта.
Сергей Колчин высказал полное согласие с тем, что плохие коммуникации могут разрушить любой проект. И здесь многое зависит от менеджера проекта — сможет ли он выявить всех заинтересованных лиц, установить с ними контакты и пользоваться этими связями для решения возникающих проблем. “Стандарты PMI прямо указывают на необходимость подготовки матрицы коммуникаций и постоянного их контроля, и не надо этим пренебрегать”, — подчеркнул он.
