Найти информацию об успешно внедренных проектах можно без труда – интернет пестрит историями успеха. Куда сложнее найти информацию о провалах и неудачах. И если успешные ИТ-проекты в моей практике достаточно сильно отличаются, то недоведенные до конца проекты имеют общие черты, о которых мне сегодня хотелось бы написать, основываясь на одном внедрение системы корпоративного уровня, где я выступал руководителем проекта со стороны заказчика, а основное управление проектом было на внешнем подрядчике.
Ниже краткое описание основных проблем, которые у нас возникли с момента старта проекта, до его отмены.
Управление проектом было полностью на стороне подрядчика, поэтому мы не имели доступа к его внутренней кухне и указанные ниже проблемы выяснялись далеко не сразу, а в рамках определения причин переносов сроков в проекте. Что существенно замедляло принятие реанимационных мер.
Мы не понимали, что проектная команда будет делать завтра, через неделю, через месяц. Первые полгода у нас не было ни плана на ближайшие 1-2 недели план работ, ни плана на 2-3 месяца, ни стратегического плана до момента внедрения. После первых изменений сроков, у нас появился план из нескольких тысяч задач с микромэнеджментом, что выглядело как на рисунке ниже, в последствии план опять исчез под прикрытием модного слова Agile. В обоих случаях руководитель проекта не мог внятно ответить на вопросы по срокам и ресурсам.
Доводы, что план должен быть и руководитель проекта должен в нем блестяще ориентироваться, не регулярной работе следить за его обновлением, видеть критический путь, оперировать обоснованным изменением сроков – не находили понимания на стороне подрядчика. Основные моменты, которые у нас в проекте отсутствовали: не было планирования и управления внедрением, не было четкой и понятной постановки задач, не была составлена последовательность задач как в детальном плане на несколько недель вперед, так и в работах до момента запуска.
Как следствие, когда не было понимания, что происходит с проектом и главное, что должно было произойти в будущем для его успешной реализации, начали происходить неожиданные переносы сроков. В описываемом проекте сроки три раза переносились за два месяца до планируемого старта. До этого момента руководитель проекта утверждал, что у них все под контролем, что это далеко не первый проект с такой ситуацией и т.д. Потом были грустные лица, иногда обвинения заказчика, один раз проявление внутренней силы и констатация, что не смогли. Результат одинаковый: проект сдвигался, называлась новая дата удобная для запуска (длительные выходные, планируемые простои предприятия), а не реально определенный срок завершения проекта. И так до следующего раза.
Если бы у нас был связанный план проекта и управление ресурсами, если бы руководитель проекта понимал последовательность выполнения задач друг за другом, факт изменения сроков проявился бы значительно раньше. Корректировочные действия можно было начать выполнять в момент появления проблемы, когда можно было бы исправить ситуацию или хотя бы минимизировать ее влияние.
Последняя каплей, приведшей к закрытию проекта, стала некорректно выстроенная последовательность выполнения задач. Подрядчик принял решение проектировать интеграцию с существующими системами в самом конце этапа разработки. В результате, в середине проектирования интеграции поняли, что заложенная архитектура не позволит реализовать прозрачное взаимодействие между системами. Огромный объем проектирования и разработки насмарку. Сыграла страсть неопытного руководителя переносить сложные задачи на самый конец в ожидании чуда. Чуда не произошло и проект был отменен
Сильный и опытный руководитель проекта на стороне внешнего подрядчика – большая удача, даже если вы являетесь крупным и серьезным предприятием. В описываемом проекте нам не повезло. А поменять руководителя проекта оказалось очень не просто – подрядчик не соглашался на данную замену, его сотрудники то же должны расти и развиваться, да и ошибки свои признавать большинство людей не любит. Поздние две смены руководителя проекта не привела к успеху, так как массив неправильных решений уже свалил проект в пике.
Плавно переходим от внешнего руководителя к проблемам на стороне Заказчика. Понятно, что если внутренняя ИТ-команда способна выполнить проект своими силами и имеет достаточный кредит доверия от руководства, то нанимать внешнюю команду никто не будет. В нашем случае локальное ИТ была неготова к новой системе. Большинство ошибок можно было бы предотвратить, если бы на тот момент у меня был достаточный опыт работы с внешними компаниями при внедрении, и я бы знал основные моменты, на которые необходимо обращать внимание. Следует отметить, что к моменту запуска мы себя планировали и сумели модернизировали и усилить. На нашей стороны было четкое понимание, если локальная ИТ не готова будет поддерживать и развивать внедренную систему, то либо через непродолжительное время компания выполнит возврат к существующей системе, либо придется платить за каждое изменение бизнеса деньги внешним подрядчикам. Если для вспомогательных систем это приемлемо, то для стратегической системы предприятия это было бы слишком дорого и содержало высокие риски зависимости работы предприятия от внешней компании. Указанный отмененный проект мы смогли запустить через 1,5 года своими силами с минимальным привлечением внешних подрядчиков (бюджет нового внедрения составил 2% от бюджета первоначального проекта).
И последняя причина провала проекта важная, но с моей точки зрения не критическая – неготовность рядовых сотрудников и руководителей низшего уровня к новой системе. Почему некритическая?: если руководство хочет, ИТ-команда умеет и может, внешний подрядчик адекватный – то внедрение, хоть и болезненное, но будет. И такие внедрения на практике у меня были. На что здесь следует обратить внимание: если рядовой бизнес не верит в запуск системы, то большая часть требований будет забыта, тестирование будет выполнено формально и реальную картину работы вы поймете только после запуска. Если локальная ИТ команда готова существенно увеличить свой рабочий день и обладает силой, авторитетом и компетенций, ТОП-менеджмент поддерживает проект, то за 2-3 месяца основные проблемы будут решены, и система полноценно заработает.
Ниже я консолидировал шесть основных причин и признаков почему, с моей точки зрения, описываемый здесь проект не «взлетел». Признаки я постарался расположить в порядке убывания по значимости:
- Слабый руководитель проекта со стороны подрядчика, что вылилось:
- Отсутствие внятного плана проекта
- Необоснованные переносы сроков
- Некорректная последовательность выполнения задач
- Отсутствие опыта на стороне ИТ аналогичных внедрений
- Неготовность бизнеса к внедрению новой системы
В заключение, хочется сделать следующий вывод: цифровые технологии играют всю большую роль в успешной работе предприятия и выводить ключевую функцию внедрения и развития информационных систем и сервисов на внешних подрядчиков – очень высокий риск для организации. Последние 5-6 лет серьезные предприятия консолидируют ИТ компетенции и экспертизу у себя, используя внешних подрядчиков как руки, оставляя функцию мозга за собой. И перед большим внедрением начинать нужно с создания сильной ИТ-команды у себя и только после этого запускать проекты внедрения. Вначале понять с КЕМ идти, и только потом КУДА.
Даже если принято решение о старте проекта с внешним подрядчиком, тут же необходимо начинать собирать собственную ИТ команду. В случае успешного запуска, уже через 3-4 месяца система будет поддерживаться и развиваться собственными силами.
Более развернута тема по невзлетевшим проектам освещена в моей видео: