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

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

- Около 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 студентов). Ведущий блога по управлению проектами.