Одна история не взлетевшего проекта внедрения корпоративной ИТ-системы

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

Ниже — краткое описание основных проблем, которые у нас возникли с момента старта проекта до его отмены.

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

Мы не понимали, что проектная команда будет делать завтра, через неделю, через месяц. Первые полгода у нас не было ни плана работ на ближайшие 1-2 недели, ни плана на 2-3 месяца, ни стратегического плана до момента внедрения. После первых изменений сроков у нас появился план из нескольких тысяч задач с микроменеджментом, что выглядело как на рисунке ниже, впоследствии план опять исчез под прикрытием модного слова Agile. В обоих случаях руководитель проекта не мог внятно ответить на вопросы по срокам и ресурсам.

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

Как следствие, когда не было понимания, что происходит с проектом и, главное, что должно было произойти в будущем для его успешной реализации, начали происходить неожиданные переносы сроков. В описываемом проекте сроки три раза переносились за два месяца до планируемого старта. До этого момента руководитель проекта утверждал, что у них все под контролем, что это далеко не первый проект с такой ситуацией и т.д. Потом были грустные лица, иногда обвинения заказчика, один раз проявление внутренней силы и констатация, что не смогли. Результат одинаковый: проект сдвигался, называлась новая дата, удобная для запуска (длительные выходные, планируемые простои предприятия), а не реально определенный срок завершения проекта. И так до следующего раза.

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

Последняя каплей, приведшей к закрытию проекта, стала некорректно выстроенная последовательность выполнения задач. Подрядчик принял решение проектировать интеграцию с существующими системами в самом конце этапа разработки. В результате, в середине проектирования интеграции поняли, что заложенная архитектура не позволит реализовать прозрачное взаимодействие между системами. Огромный объем проектирования и разработки — насмарку. Сыграла страсть неопытного руководителя переносить сложные задачи на самый конец в ожидании чуда. Чуда не произошло, и проект был отменен

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

Плавно переходим от внешнего руководителя к проблемам на стороне Заказчика. Понятно, что если внутренняя ИТ-команда способна выполнить проект своими силами и имеет достаточный кредит доверия от руководства, то нанимать внешнюю команду никто не будет. В нашем случае локальное ИТ было не готово к новой системе. Большинство ошибок можно было бы предотвратить, если бы на тот момент у меня был достаточный опыт работы с внешними компаниями при внедрении, и я бы знал основные моменты, на которые необходимо обращать внимание. Следует отметить, что к моменту запуска мы себя планировали и сумели модернизировали и усилить. На нашей стороны было четкое понимание, если локальная ИТ не готова будет поддерживать и развивать внедренную систему, то либо через непродолжительное время компания выполнит возврат к существующей системе, либо придется платить за каждое изменение бизнеса деньги внешним подрядчикам. Если для вспомогательных систем это приемлемо, то для стратегической системы предприятия это было бы слишком дорого и содержало высокие риски зависимости работы предприятия от внешней компании. Указанный отмененный проект мы смогли запустить через 1,5 года своими силами с минимальным привлечением внешних подрядчиков (бюджет нового внедрения составил 2% от бюджета первоначального проекта).

И последняя причина провала проекта важная, но, с моей точки зрения, не критическая — неготовность рядовых сотрудников и руководителей низшего уровня к новой системе. Почему некритическая? — если руководство хочет, ИТ-команда умеет и может, внешний подрядчик  адекватный — то внедрение, хоть и болезненное, но будет. И такие внедрения на практике у меня были. На что здесь следует обратить внимание: если рядовой бизнес не верит в запуск системы, то большая часть требований будет забыта, тестирование будет выполнено формально и реальную картину работы вы поймете только после запуска. Если локальная ИТ команда готова существенно увеличить свой рабочий день и обладает силой, авторитетом и компетенций, ТОП-менеджмент поддерживает проект, то за 2-3 месяца основные проблемы будут решены и система полноценно заработает.

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

1. Слабый руководитель проекта со стороны подрядчика, что вылилось в:
     a. Отсутствие внятного плана проекта
     b. Необоснованные переносы сроков
     c. Некорректную последовательность выполнения задач
2. Отсутствие опыта на стороне ИТ аналогичных внедрений
3. Неготовность бизнеса к внедрению новой системы.

В заключение хочется сделать следующий вывод: цифровые технологии играют всю большую роль в успешной работе предприятия и выводить ключевую функцию внедрения и развития информационных систем и сервисов на внешних подрядчиков – очень высокий риск для организации. Последние 5-6 лет серьезные предприятия консолидируют ИТ компетенции и экспертизу у себя, используя внешних подрядчиков как руки, оставляя функцию мозга за собой. И перед большим внедрением начинать нужно с создания сильной ИТ-команды у себя и только после этого запускать проекты внедрения. Вначале понять с КЕМ идти, и только потом — КУДА.

Даже если принято решение о старте проекта с внешним подрядчиком, тут же необходимо начинать собирать собственную ИТ команду. В случае успешного запуска уже через 3-4 месяца система будет поддерживаться и развиваться собственными силами.

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