Почему проваливаются проекты — выводы Максима Якубовича

Наш эксперт по управлению проектами, директор компании «АйТи уит» Максим Якубович, задался вопросом: насколько велика вероятность того, что ИТ-проекты будут внедрены в срок и уложатся в бюджет, а также почему они проваливаются. Вот его комментарии и выводы.

— Около 10 лет назад от одного из успешных бизнесменов, в компании которого я руководил проектом внедрения КСУП, я услышал такую фразу: «Бизнес сидит на игле у ИТ». Я попросил объяснить, что он имеет в виду. Вот что примерно он сказал: «Мы не можем не автоматизировать наш бизнес, потому как конкуренты это сделают ранее нас и станут эффективнее нас. С другой стороны, мы боимся это делать, т.к. вероятность успеха ИТ-проекта крайне низка».

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

Отчет, который в 2014 году выпустила компания The Standish Group, предоставляет нам следующие данные для анализа:

• Из 8380 проектов по разработке и внедрению программных продуктов успеха добились лишь 16,2%
• В категорию «спорные» проекты попало 52,7%
• В категории провальных проектов (от реализации которых отказались) оказалось 31,1%

Для исследования все ИТ-проекты в этом отчете были разделены на три группы:

1. «Успешные проекты» — проект завершен в срок, в бюджет, реализованы все возможности и функции, которые первоначально были запланированы.

2. «Спорные проекты» — проект завершен и работает, но плановый бюджет или срок был превышен, либо реализованы не все функции, которые первоначально были запланированы.

3. «Провальные проекты» — проект был отменен или так и не дошел до финиша.

Как часто превышается бюджет ИТ-проекта и на сколько % от планового значения? На этот вопрос отчет дает следующий ответ:

Как видим, почти в четверти проектов из тех, что попали в группу спорных или провальных, бюджет был превышен более чем в 2 раза (свыше 100% от планового).

А теперь посмотрим, как сильно отклоняются от планового срока ИТ-проекты:

А вот по срокам ситуация куда более серьезная:

Почти в половине проектов (47,8%), попавших в группу спорных или в группу провальных, сроки были сорваны более чем на 100% от плановых.

Теперь узнаем, какая доля от запланированного функционала программного продукта была реализована в проекте. Эта цифра имеет смысл только для категории спорных проектов, т.к неудачные проекты так и не дошли до логического завершения:

В группе спорных проектов более четверти из них были завершены с получением лишь 25% – 49% от первоначально запланированных функций программного продукта. В отчете также есть данные о том, что в среднем был реализован 61% от первоначально запланированных функций для данной категории проектов.

В чем причины провалов проектов

Мне интересно было узнать мнение руководителей ИТ-проектов относительно причин успеха их проектов. Ниже перечислены факторы успеха и доля респондентов, участвовавших в этом опросе The Standish Group:

Вовлечение пользователей — 15,9%
Поддержка высшего руководства — 13,9%
Ясное изложение требований — 13,0%
Правильное планирование — 9,6%
Реалистичные ожидания — 8,2%
Небольшие этапы проекта — 7,7%
Компетентный персонал — 7,2%
Ownership — 5,3%
Ясное видение и цели — 2,9%
Трудолюбивый, сфокусированный персонал — 2,4%
Другое — 13,9%

В аналогичном отчете The Standish Group за 2015 год в списке появились новые факторы успеха ИТ-проекта, которых не было в списке за 2014 год, например:

Эмоциональная зрелость — совокупность основных характеристик поведения людей при совместной работе.

Использование Agile-процесса — обозначает то, что команда и владелец продукта умеют работать по одному из Agile подходов.

Как видим, в 2015 году респонденты в явном виде указали на то, что использование Agile-подхода для ИТ-проекта стало одним из факторов его успеха.

Самое интересное при изучении статистики проектов, на мой взгляд, — это понимание причин того, почему проект не стал успешным.

По мнению респондентов отчета список этих причин для спорных проектов следующий:

Отсутствие вовлечения пользователей — 12,8%
Неполные требования и спецификации — 12.3%
Изменение требований — 11,8%
Отсутствие поддержки высшего руководства — 7,5%
Технологическая некомпетентность — 7,0%
Нехватка ресурсов — 6,4%
Нереальные ожидания — 5,9%
Нечеткие цели — 5,3%
Нереальные плановые сроки — 4,3%
Появление новой технологии — 3,7%
Другое — 23,0%

Понятное дело, что в исследовании The Standish Group не участвовали ИТ-проекты компаний-заказчиков из Беларуси. Но я, имея опыт руководства проектами автоматизации бизнеса белорусских компаний, могу отметить, что ключевые факторы провала таких проектов в нашей стране во многом совпадают с приведенным выше списком.

Я сформулировал собственный список причин провала проектов автоматизации бизнеса (без претензии на его истинность):

1. Нечеткие цели ИТ-проектов. Это проявляется на уровне самих формулировок целей проекта, к примеру, целью ИТ-проекта объявляют такую: «Внедрить ERP-систему». У меня много вопросов к этой формулировке цели:

• Что мы понимаем под ERP?
• Как мы поймем, что мы внедрили эту систему?
• Какова бизнес-выгода от внедрения?
• За какой период будем измерять бизнес-выгоду?

Следующий уровень, который скорее всего будет не проработан при старте проекта – это описание ожидаемых результатов проекта. Ну и совсем слабой в большинстве проектов будет проработка требований к результатам проекта.

2. Отсутствие со стороны компании-заказчика проекта команды проекта. Я имею в виду команду, которая имеет полномочия и ответственность принимать решения по содержанию проекта.

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

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

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

5. Изменение требований. Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал. А потом потихоньку дорабатывать «бантики». По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда.

6. Отсутствие поддержки высшего руководства компании-заказчика. Я встречал ситуации, когда при внедрении ERP-систем высшие руководители компании-заказчика даже не были представлены команде исполнителя. О каком вовлечении в проект или поддержке проекта руководством со стороны заказчика может идти речь?

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

8. Нехватка ресурсов. Сотрудники заказчика не принимают важные решения по проекту максимально быстро, а работают в комфортном для них темпе. В результате в проекте возникают потери времени, и команда исполнителя начинает терять интерес к проекту и ищет на время простоя, на какие проекты можно было бы переключиться

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

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

Тут я хочу вспомнить один из пунктов манифеста Agile: «Люди и взаимодействие важнее процессов и инструментов», который я трактую так: «Хорошая команда проекта определит, какие процессы и инструменты ей надо использовать, чтобы достигнуть целей проекта».

Agile – это про хорошие команды. Может, поэтому в списке причин успеха ИТ-проектов в отчете компании The Standish Group за 2015 год появилась новая причина успеха — использование Agile-процесса?

Остались вопросы? Пишите в комментариях.

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект». Опыт преподавания — с 2005 года (прошли обучение около 2300 студентов). Ведущий блога по управлению проектами.