В шапке
Причины провала ИТ-проектов

Причины провала ИТ-проектов

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

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

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

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

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

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

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

Превышение бюджета % проектов
Менее 20% 15,5%
21 - 50% 31,5%
51 - 100% 29,6%
101 - 200% 10,2%
201 - 400% 8,8%
Свыше 400% 4,4%

 

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

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

Превышение срока % проектов
До 20% 13,9%
21 - 50% 18,3%
51 - 100% 20,0%
101 - 200% 35,5%
201 - 400% 11,2%
Свыше 400% 1,1%

 

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

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

% реализованных функций % проектов
Менее чем 25% 4,6%
25 - 49% 27,2%
50 - 74% 21,8%
75 - 99% 39,1%
100% 7,3%

 

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

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

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

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

  • Эмоциональная зрелость - совокупность основных характеристик поведения людей при совместной работе. 
  • Использование Agile процесса – обозначает то, что команда и владелец продукта умеют работать по одному из Agile подходов.

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

Самое интересно при изучении статистики проектов, на мой взгляд, - это понимание причин того, почему проект не стал успешным. По мнению респондентов отчета список этих причин для спорных проектов следующий:

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

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

  1. Нечеткие цели ИТ-проектов.

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

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

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

  1. Отсутствие со стороны компании-заказчика проекта команды проекта

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

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

  1. Неполные требования к программному продукту.

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

  1. Нереальные плановые сроки

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

  1. Изменение требований.

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

  1. Отсутствие поддержки высшего руководства компании-заказчика

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

  1. Команда заказчика и команда исполнителя не работают как одна команда.

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

  1. Нехватка ресурсов

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

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

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

Тут я вспоминаю один из пунктов манифеста Agile:

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

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

Комментарии (0)
Войти как