Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Почему у ИТ-проектов в 20 раз больше шансов на провал, чем у других бизнес-проектов?

Почему у ИТ-проектов в 20 раз больше шансов на провал, чем у других бизнес-проектов?

Исследование, проведенное в Оксфордском университете, показало, что ИТ-проекты в 20 раз более подвержены риску потерпеть неудачу, другие бизнес-проектов. Каждый шестой ИТ-проект завершается с перерасходом средств по меньшей мере на 200%. Ситуация абсолютно одинакова и в государственном и в частном секторе. Компании разоряются из-за неудавшихся ИТ-проектов. Но почему же дела обстоят так плохо именно с ИТ-проектами?

Анализ 105 европейских государственных ИТ-проектов, общей стоимостью 50 млрд. долларов, выявил перерасход средств по 60 проектам, составивший в сумме почти 15 млрд. долларов. Кроме того, 35 контрактов были отложены, а 31 контракт расторгнут. Масштабы ИТ-провалов меньше, чем в программе «Электронная Москва», но тоже весьма существенны.

Анализ перерасходов средств по ИТ-проектам показывает, что в среднем перерасход составляет 27%, и эта цифра не такая уж пугающая. Однако, по меньшей мере по одному из шести проектов перерасход составляет около 200%, а отклонение по срокам — почти 70%. Истинная проблема ИТ не в среднем перерасходе средств в ИТ-проектах, а в том, что многие ИТ-проекты — «черные лебеди» — термин, предложенный Насимом Талебом, который описывает редкие труднопредсказуемые события с огромным эффектом воздействия.

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

Пара показательных примеров. Компания Auto Windscreens была второй по величине британской компанией, выпускающей автомобильные стекла. В 2006 году компания перевела управление заказами с Oracle на Metrix и приступила к внедрению ERP системы. В IV квартале 2010 г. падение продаж, проблемы в управлении оборотными фондами в сочетании с расходами на  ИТ привели к банкротству компании.

В настоящее время ПО является неотъемлемой частью множества продуктов, но инженеры и менеджеры, отвечающие за разработку продукта, зачастую слабо представляют, как реализуется технологическая составляющая. Так аэробус A380 был задуман по последнему слову техники: его оригинальный дизайн включал 500 км проводов, 98.000 кабелей и 40.000 разъемов. Когда в рамках международного проекта уже была выполнена часть работ, стало известно, что немецкие и испанские разработчики используют ПО более старой версии, чем их британские и французские коллеги. Последовали неизбежные проблемы с конфигурацией. В 2005 г. было объявлено о шестимесячной задержке выпуска аэробуса, а в следующем году — еще о шести месяцах. В результате  акции компании потеряли 26% стоимости, последовало несколько громких отставок, а отставание от производственных планов не ликвидировано до сих пор.

Однако технологии — не единственная проблема. Руководители могут стать жертвой «проектификации», рассматривая свою деятельность как совокупность нескольких временных проектов. Не достаточно просто хорошо управлять отдельными проектами, менеджеры должны выбирать правильные проекты, использовать взаимодействие между ними и закрывать ненужные. И хотя основные правила управления проектами довольно просты, большинство компаний не следуют им. Так

  • 67% компаний не могут закрыть неудачные проекты;
  • 61% менеджеров сообщают о конфликтах между проектами и линейной организацией;
  • 34% компаний реализуют проекты, несогласованные с корпоративной стратегией;
  • 32% компаний делают лишнюю работу из-за несогласованности проектов.

Любая компания, которая планирует реализовать крупный ИТ-проект, должна оценить свою готовность. Руководители должны задать себе два ключевых вопроса: Во-первых, достаточно ли сильна компания, чтобы выдержать удар, если стоимость самого большого проекта превысить его бюджет на 400% и более, и если будет получено менее половины прогнозируемой прибыли? Во-вторых, сможет ли компания удержаться на ногах, если 15% средних проектов (не тех, которым уделяется должное внимание, а вторичных, которые часто упускают из виду) превысят смету расходов на 200%? Эти цифры могут показаться завышенными, но, как показали исследования Оксфордского университета, именно с ними приходится, сталкиваются на практике.

Даже если компания прошла стресс-тест, мудрый ИТ-директор должен предпринять и другие меры, чтобы проект не стал «черным лебедем»: Крупный ИТ-проект разбивается на несколько подпроектов меньшего объема, сложности и времени исполнения; определяются неизбежные риски и разрабатываются планы работы с ними. Здесь полезно воспользоваться лучшими методами прогнозирования, например, проанализировать  результаты аналогичных проектов в других компаниях («reference class forecasting»).

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

По материалам computerweekly.com

Дополнительные материалы

Комментарии (16)

  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 29 августа 2011, 13:01

    0
    > Исследование, проведенное в Оксфордском университете, показало, что ИТ-проекты в 20 раз более подвержены риску потерпеть неудачу, другие бизнес-проектов

    Потому что ИТ-проекты не стандартизированы чаще всего. И работать в них приходится с людьми больше, чем гайки прикручивать. Вот например, был у меня случай. Рядом с офисом начали строить 15-ти этажное огромное здание. И в этот же момент начался проект внедрнения ИС в одну компанию. Когда здание построили, проект ещё даже не вошел в фазу опытной эксплуатации (справедливости ради -- построили коробку и завершили внешнюю отделку, в эксплуатацию здание не сдали на тот момент). В такие моменты, конечно, осознаешь никчемность своей работы. Но!

    Что считать началом проекта -- до начала строительства дома был этап согласований, проектирования и т.д. (здание не имело стандартную конструкцию, индивидуальный проект, так сказать). Само строительство коробки -- это, можно сказать, уже финальный этап. Да и работать при строительстве здания нужно не с людьми (точнее, тут не нужно думать, как мотивировать рабочих, какие в коллективе могут быть "потайные" игры, которые внедрение системы может порушить и т.д.).
    • Аватар

      Владимиров Дмитрий [DmVladimirov], 29 августа 2011, 13:56

      0
      В ИТ все тоже самое что и н астройке, и игры такие же подковерные. Удалось поработать и на стройке и в ит, ВЕЗДЕ одно и тоже - некомпетентный подрядчик -> влияние третьих сторон на клиента -> клиенту как правило проект не нужен, старт проекта хороший пресейл -> некомпетентность на рабочих местах - отсутствие понимания как работает бизнес - мимолетное веяние - поиск халявы ... можно долго продолжать список все сводится к одному - ЗАИНТЕРЕСОВАННОСТЬ причем как для всех, так и личная (необязательно откаты)

      А данные исследования подтверждают что менеджеры по продажам все еще лучше работают чем айтишники.
  • Аватар

    Солопов Павел [PaSol], 29 августа 2011, 16:37

    0

    Пара показательных примеров

    А строительство аэробуса тоже к ИТ-проектам отнесли? Тогда не мудрено, что ИТ-проекты в 20 раз чаще терпят неудачу, я вообще удивлён, что остались какие-то не ИТ проекты.

  • Аватар

    Peshkov Alexander [PA], 29 августа 2011, 17:23

    0

    Могу сказать без всяких натяжек. По моему опыту, есть и все то, о чем написано выше, НО. Товарищи айтишники, почему вы так юмористически настроены к фразам "проектирование системы / процессов" или "написание ТЗ"? Я на каждом проекте с превышением сроков и бюждета наблюдаю ухмыляющегося при необходимости писать ТЗ "умника" и того же самого умника, который бегает как ужаленый, когда приходит время сдавать результаты проекта, которые, увы, не описаны.

    • Аватар

      Котельников Илья [iluha], 30 августа 2011, 09:50

      0
      Тут 2 проблемы:
      1. ТЗ нужно уметь писать, так, чтобы его можно было использовать.
      2. За ТЗ нужно платить, столько же, как и за сами работы.

      Первая проблема - это проблема подрядчика, вторая - заказчика. По обоюдному согласию они отказываются от ТЗ.
      :)
      • Аватар

        Солопов Павел [PaSol], 30 августа 2011, 10:53

        0

        Проект проекту рознь, одно дело, когда вы выполняетет разработку системы, другое, когда вы внедряете некий серийный софт, разработанный какой-то другой компанией.

        В первом случае с ТЗ попроще, нужно правильно сформулировать требования.

        А во во втором случае начинаются сложности. Во первых, что писать в ТЗ? Одну строчку: "Внедрим такой-то софт..." - вроде как безсмысленно. Перечислять все стандартные функции, которые в ПО заложены? В чём смысл? Это не мы их туда заложили (а вендор), за их состав и качество исполнения мы отвечать не сможем. Документ получится глубоко формальным.

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

        • Аватар

          Peshkov Alexander [PA], 30 августа 2011, 14:52

          0

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

          • Аватар

            Солопов Павел [PaSol], 31 августа 2011, 11:08

            0

            Чем они отличаются, я, хоть и в кратце, но изложил.

            Чем они не отличаются, конкретно из вашего поста я не вижу.

        • Аватар

          Котельников Илья [iluha], 30 августа 2011, 14:58

          0
          Согласен со всем сказанным.
          Только, по-моему, и в разработке и во внедрении проблема общая: Написать ТЗ - это значит заведомо с достаточной для оперативного планирования точностью определить результат. Это бывает сложно, дорого, сложно и дорого или вообще невозможно.
          Отсюда и проблемы...
          Кстати, если говорить про собственный опыт, то на внедрении 1С всегда лучше составлять ТЗ. Чем детальнее - тем лучше. А если взять разработку сервиса smartnut.ru, то у нас ТЗ в стандартном понимании нет (и не может быть, ведь вместо 1 заказчика у нас есть только усредненный портрет). Спасаемся через Agile :)
      • Аватар

        Peshkov Alexander [PA], 30 августа 2011, 14:45

        0

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

  • Аватар

    Павел [revolt08], 30 августа 2011, 11:42

    0
    на мой взгляд потому что нет стандартов. раньше как было? приходит заказчик, плывет в терминах, кое-как на пальцах чего-то объясняет. исполнитель мало что понял, но делает. два раза "не то", один раз "ты не компетентен", одна угроза разрыва договора, завершение и все довольны.
    а сейчас? приходит заказчик, сыплет терминами, айтилами, процессами. уверенно так объясняет. исполнитель мало что понял, но делает. два раза "не то", один раз "ты не компетентен", одна угроза разрыва договора, завершение и все довольны.
    • Аватар

      Савинова Светлана [zvetka], 29 марта 2013, 12:31

      0
      уже год пытаюсь представить себе стандартизированное управление ИТ холдинга кроме положения о корпоративной комп.сети и ДИ ничего не сделано, не так то это просто, даже сыпать терминами, когда не знаю что есть этот термин на конкретном примере в практике конкр.организации
  • Аватар

    Гончаров Олег [OLeg_Goncharov], 05 сентября 2011, 08:01

    0

    Не нашел источник этой статистики, приведённой в посте... Не подскажите - откуда?

    • 67% компаний не могут закрыть неудачные проекты;
    • 61% менеджеров сообщают о конфликтах между проектами и линейной организацией;
    • 34% компаний реализуют проекты, несогласованные с корпоративной стратегией;
    • 32% компаний делают лишнюю работу из-за несогласованности проектов.