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

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

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

Почему крупные ИТ-проекты прекращают свое существование?

Почему крупные ИТ-проекты прекращают свое существование?

По мнению исследователей из Said Business School при Оксфордском Университете, у крупных ИТ-проектов в 20 раз больше шансов на провал, чем у крупных проектов в других областях (к примеру, в строительстве). В среднем крупные ИТ-проекты, попавшие в это исследование, на 27% превышают запланированный бюджет и требуют на 55% больше времени для завершения, чем заявлялось вначале. Хотя отдельной статистики по российским проектам нет, наши крупные ИТ-начинания придерживаются той же, если не менее перспективной практики.

По факту, большие проекты — это задачи, не поддающиеся разбиению на небольшие составляющие, полезные сами по себе. Есть множество причин, почему такие проекты не укладываются в обозначенные деньги и время. Большая часть из них отнюдь не техническая, а скорее управленческая.

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

Даже если бюджет в самом начале учитывает все неожиданности, для утверждения у спонсоров проекта, часто приходится урезать расходы настолько, насколько это вообще возможно. В результате одобренный бюджет не имеет в себе никакого «люфта» на подстраховку от законов Мерфи. Малейшая ошибка — и проект будет тянуть деньги сверх заложенного бюджета.

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

Вторая проблема — это постоянно меняющаяся внешняя среда и необходимость реагирования на эти изменения.

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

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

Третья проблема — неправильные административные решения, как в начале проекта, так и в рамках реагирования на изменяющиеся атрибуты проекта.

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

Четвертая проблема — «сбитый прицел» у проектной команды. Больше внимания уделяется процессу, чем результату.

Часто крупные проекты начинаются в среде, где с самого начала не оговорены жесткие бизнес-требования к решению. Менеджеры проекта могут и не представлять, зачем разрабатываемый инструмент нужен конечному пользователю, и как он будет его использовать. Проект, рожденный в подобных туманных условиях, либо обрастает нереалистичными требованиями к срокам и бюджетам, либо начинает страдать от административного бремени: управление проектом будет съедать гораздо больше ресурсов, чем его развитие.

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

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

Над крупными проектами работают люди, обладающие всеми человеческими слабостями. Часто чем хуже реальная ситуация на проекте, тем оптимистичнее доклады о том, как идут дела.

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

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

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