Я часто вижу ситуацию, когда менеджмент во всем винит руководителей проектов. Уволили одного, поставили другого, «более опытного». А он тоже почему-то не справился. Опять накормил завтраками, обещая, что вот-вот и все будет. Тем временем, проект, на который постоянно назначают новых РП, уже в настолько глубокой Ж, что… все, включая заказчика, хотят его закрыть. Списать десятки миллионов в убытки и снова всех уволить. Нанять нормальных, ответственных людей!

Сегодня поделюсь своим кейсом, как много лет назад я видел похожую ситуацию при реализации проекта по запуску системы в крупном банке. Менеджмент сменил уже ТРЕХ руководителей проекта, но «завтраки» продолжались. Сроки и бюджет росли каждый день как на дрожжах.

Веры в то, что изменить ситуацию возможно, не было ни у кого. Менеджмент винил сотрудников, которые «наврали» о реалистичности сроков. Однако я понимал, что проблема тут не в них. 

В этой статье на примере этого кейса объясняю, почему проджекты не виноваты в провалах проектов. А также вкратце поделюсь, что именно я сделал, чтобы вытащить конкретно этот проект из Ж все-таки запустить банковскую систему за 4 месяца, вместо 2 лет.

Ситуация критическая

Я работал руководителем проектного офиса в банке. Один из проектов (по внедрению системы Эдельвейс для учета и расчетов по корпоративным банковским продуктам) конкретно застрял. А точнее – его изначальные сроки сдвинулись более, чем на год, а бюджет вырос не менее, чем на 50%. Сменилось уже три руководителя проекта – первый ушел сам, а второго… вежливо попросили.

И вот, на очередном управляющем комитете вновь назначенный (пару месяцев назад) и третий по счету руководитель проекта отчитывается перед руководством банка. Включая членов правления, ИТ-директора и заказчиков. Рассказывает о том, какие проблемы мешают двигаться и когда планируется запуск. Критичных багов на тот момент было штук 10, и их решение тянулось месяцами. На прямой вопрос ИТ-директора: «Когда вы запуститесь?» руководитель проекта сообщает: «Как по плану, до конца года». При этом всем присутствующим очевидно, что до code freeze остается две недели, и это обещание –  нереалистично. Тем более, что на дворе уже декабрь.

Так и произошло – проект снова не запустился в обещанный срок. Заказчик был готов его закрыть, так как терпение уже кончилось. 

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

Я убедил его, что дело не в менеджере, а в менеджменте. Что можно сменить еще хоть 10 руководителей, но это не поможет проекту. 

В итоге он согласился, и я получил полномочия «наставника» руководителя проекта, помогающего вывести проект из кризиса. Благо сам руководитель проекта понимал всю плачевность ситуации, а потому не сопротивлялся и шел на контакт. У нас с ним было совсем немного времени, так как заказчик пообещал закрыть проект, если в ближайшие пару месяцев проект не станет предсказуемо двигаться, а обещанное исполняться.

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

• полная и объективная картина прогресса и проблем

• регулярный менеджмент

• честные коммуникации с заказчиком

Мы приступили к работе в январе.

Главная сложность, с которой я столкнулся, чтобы все-таки вытащить «бегемота из болота», это НЕДОВЕРИЕ. Заказчик не доверял, потому что его больше года кормили «завтраками» и просили больше бюджета. Команда не доверяла, потому что проблемы месяцами висели без решения. Руководитель проекта, хоть и шел на контакт, но тоже без особого оптимизма относился к моим решениям – а это точно поможет? Топ-менеджмент и вовсе в открытую проявлял скепсис – да разве тут можно исправить ситуацию?

Недоверие порождало отсутствие поддержки и вовлечения. А именно: нежелание выделять дополнительные ресурсы, скепсис по поводу участия во встречах, изобретению новых процедур и форм отчетности…

Мне понадобилось чуть больше 4 месяцев, чтобы изменить мнение каждого участника по поводу будущего этого проекта.

Как мы пришли к успеху?

✅ Содержание проекта разбили на элементы – по продуктам и их характеристикам

✅ Выявили и описали блокирующие баги

✅ Проанализировали влияние блокеров на возможность запустить отдельные продукты

✅ Приоритезировали все продукты, автоматизируемые в рамках проекта, с учетом их влияния на PnL и возможности решения блокеров

✅ Сформировали план проекта с учетом текущей скорости и всех зависимостей и спрогнозировали реалистичный срок завершения – апрель

✅ Наладили сбор статистики по багам и прогрессу:

➖скорость тестирования  

➖скорость выявления новых багов  

➖скорость устранения критичных багов

✅ Наладили еженедельную структурированную отчетность по метрикам и готовности продуктов к запуску

✅ Наладили регулярные планерки (еженедельно) и управляющие комитеты (раз в 2 недели) с анализом прогресса

✅ Наладили регулярные встречи с заказчиком (еженедельно)

✅ Перешли от отчета по факту и обещания конечной даты к обоснованному прогнозу на базе трендов по скорости тестирования и закрытия критичных багов

✅ Ну и, естественно, методично и последовательно снимали один за одним баг, проблему или открытый вопрос

Спустя 4 месяца нам удалось запустить систему с 30% ключевых продуктов, обеспечивающих 50+% автоматизируемого бизнеса. 4 месяца вместо двух лет.

Главные выводы: если на ваших проектах постоянно возникают проблемы, сроки и бюджет увеличиваются, эффекты не достигаются, виноваты не проджекты. Виноват менеджмент. Ваши сотрудники не должны выстраивать систему управления, это задача руководства. 

Если хотите больше знать о том, как создать такую систему управления, при которой сотрудники действуют автономно без постоянного микроменеджмента со стороны руководства, подписывайтесь на мой Телеграм канал «Андрей Малахов | От проектов к изменениям». Там я делюсь своим опытом, кейсами, личными наработками за 20+ в управлении проектами и изменениями, а также своими авторскими статьями и гайдами, которые помогают делать результаты проектов предсказуемыми.