Сбой и сожжение: почему крупные ИТ-проекты так часто терпят неудачу?
Крупные ИТ-проекты по-прежнему терпят неудачу, часто с катастрофическими последствиями для вовлеченных в них организаций. Самым последним примером этого, который привлек мое внимание, является судебная тяжба между Hertz и Accenture по поводу поставки новой мобильной цифровой платформы, которая обеспечит возможности обработки бизнес-данных и электронной коммерции для предоставления более качественных услуг клиентам Hertz по всему миру. Хотя влияние этой ситуации на две вовлеченные компании еще предстоит выяснить, в отчете, опубликованном McKinsey Digital в 2012 году, говорится, что «17 процентов ИТ-проектов идут настолько плохо, что могут угрожать самому существованию компании».
Почему подобные вещи продолжают происходить? Действительно ли ИТ-специалисты не знают, как сделать то, на что они кажутся способными? Или неудачи больше связаны с другими областями, такими как управление проектами или корпоративная политика? Я часто обсуждал эти вопросы со своим кругом контактов в сфере ИТ, а также с полумиллионным сообществом подписчиков нашего популярного еженедельного информационного бюллетеня WServerNews, и я подумал, что это может быть полезно для тех из вас, кто участвует в доставке - масштабным ИТ-проектам, чтобы поделиться мнением некоторых моих коллег по этой проблеме. Итак, без лишних слов, вот пять причин, по которым крупные ИТ-проекты часто терпят неудачу, представленные в произвольном порядке и во многом основанные на личном опыте участников. Если у вас есть какие-либо дополнительные идеи, которые вы можете добавить из своего личного опыта неудачных ИТ-проектов, не стесняйтесь добавлять их, используя функцию комментариев внизу этой статьи.
Слишком большой, чтобы обанкротиться? Нет — недостаточно большой!
«Проекты должны быть достаточно большими, чтобы действительно достигать своих целей», — говорит Энтони, сетевой инженер, работающий в высшем учебном заведении. Я спорил с ним, что, возможно, крупные ИТ-проекты следует разбивать на ряд более мелких проектов, которые реализуются независимо друг от друга, не как вехи в более крупном проекте, а как самостоятельные объекты. Энтони ответил, сказав: «Разбить определенные проекты на более мелкие часто буквально невозможно. Глубокая инфраструктура, такая как службы аутентификации (Kerberos, Active Directory и т. д.), может легко потребовать «дней флага», когда вся организация должна делать что-то одновременно, часто с ограниченными возможностями для отказа».
Знание того, какие настройки потребуются клиенту
У Энтони также были некоторые мысли по поводу настройки программных систем под конкретные нужды заказчика. «Для многих проектов фактические сложные детали находятся не в базовой системе, а в том, как она есть и должна быть настроена для локального использования. SAP и другое программное обеспечение часто не предназначены для использования в необработанном виде. Программное обеспечение для составления бюджета и бухгалтерского учета часто имеет требования соблюдения законодательства за пределами фактического проекта программного обеспечения. Обнаружение на полпути проекта того, что основные предположения о том, как используется система, неверны, — это проблема». Ясно, что персонализация, основанная на требованиях к локализации, — это то, что участники ИТ-проектов должны рассмотреть на раннем этапе, прежде чем будут произведены какие-либо закупки или развертывание.
Знайте, что на самом деле представляет собой конечный продукт, который вы должны предоставить
Иногда вина за провал ИТ-проектов полностью ложится на тех, кто разрабатывает систему или код, который они обещают предоставить. «Главная причина, по которой любой проект терпит неудачу, — это ложное представление о перспективах», — говорит Крейг, руководитель консалтинговой компании в области ИТ в Австралии. «Я помню, как во времена моей службы в ВВС каждое подразделение считало, что это причина существования ВВС. У меня даже был один радиотехник, который сказал, что единственная причина, по которой у ВВС есть самолеты, это чтобы они могли запускать радио в воздух. Он, конечно, шутил, но мне это запомнилось, потому что подчеркивает приоритеты. Каждый думает, что то, что он делает, является самым важным. Таким образом, в ИТ-проектах (любого размера) основное внимание уделяется предоставлению программного обеспечения, которое делает то, что указано в техническом задании, не дает сбоев и является простым в использовании. Он зародился как усовершенствование бизнес-процесса, но к тому времени, когда код был урезан, об этом давно забыли», — говорит Крейг.
«Программисты рассматривают свой код как конечный продукт, — говорит Крейг, — тогда как на самом деле это бизнес-процесс. Слишком часто бизнес-процессы должны изменяться, чтобы соответствовать требованиям компьютерных систем. Конечно, часто это включает в себя улучшения, но так же часто это излишне увеличивает бюрократизм». Когда я спросил Крейга, что, по его мнению, является решением этой проблемы, он ответил: «Мое решение? Имейте план с постоянным путем совершенствования и четко определенными бизнес-процессами. Но все происходит небольшими управляемыми порциями».
Сосредоточьтесь на желаниях и потребностях клиента, но не слишком сильно
«Большинство крупных ИТ-проектов терпят неудачу по ряду причин, — говорит другой коллега по имени Том. Одной из причин может быть отсутствие концентрации внимания на клиенте во время работы над проектом. «Отсутствие обратной связи от целевых конечных пользователей», — говорит Том. «Меня просто поражает, как часто конечный пользователь остается в стороне. Самый лучший код в мире бесполезен, если никто не хочет его использовать. Не обязательно сделать проект идеальным, но он станет намного ближе, если в нем будет участвовать конечный пользователь».
Том также предлагает вам «создавать то, что нужно пользователю, а не обязательно то, что, по их словам, им нужно. Я слушал и читал отличные спецификации для проекта. А программисты снимают сборку, что им скажут. Но что требуется и чего обычно не хватает, так это способность понимать, что требуется, и переводить это в реальный код. Умения переводить так не хватает в IT, да и в большинстве проектов любого рода. Существует мнение, что проекты можно механизировать. А ведь многое из программирования или разработки может быть. Но творческая способность понять, чего хотят, а не просто констатировать факт желаемого». Я согласен с Томом в том, что предоставление ИТ — это не просто наука; это еще и творческая деятельность — искусство.
На самом деле нет такого понятия, как ИТ-проект!
Наконец, этим интересным наблюдением со мной поделился Дейв, менеджер проектов на пенсии, имеющий сертификат специалиста по управлению проектами (PMP). «По моему скромному мнению, прозвище «ИТ-проект» является частью проблемы. Он имеет тенденцию накладывать шоры на то, чтобы сосредоточиться только на ИТ-решении, не продолжая отслеживать влияние на остальную часть бизнеса. Это, как правило, тем более распространено, чем больше ИТ-проект».
«Проекты должны быть связаны с бизнес-стратегией, — говорит Дэйв. «Технологии могут и часто являются частью решения бизнес-проблемы. Проекты, обычно называемые ИТ-проектами, следует называть бизнес-проектами, в которых технология является частью решения. Это изменение точки зрения, как правило, поддерживает участие всех заинтересованных сторон. Кроме того, основное внимание уделяется общему решению, а не только технологической части (аппаратному/программному обеспечению)».
Хм, интересный момент. Так что, возможно, нам следует перестать думать о себе как о ИТ-специалистах и просто считать себя профессионалами. Если мы перенесем наше мышление с технической стороны в сторону бизнеса, то, возможно, мы тоже начнем как профессионалы, а не как типичные айтишники!