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

По статистике, 70% всех ИТ-проектов оказываются в той или иной мере неудачными, то есть не удовлетворяют своих создателей, инвесторов и/или клиентов. Почему так происходит? Изначально неудачная идея, неправильное управление проектом, неверный расчет рынка, неумелые исполнители, хронические срывы дедлайнов вошедшие в привычку, или какие-то внешние причины, в итоге некачественный продукт, разочаровавший всех интересантов. В большинстве случаев оказывается, однако, что с идеями все было более-менее, с рынком тоже, а главная причина — ошибки в управлении проектом; все другие причины — капризы рынка, растраты бюджета, неумелая и недисциплинированная команда — лишь в конце списка причин.

Плохое планирование

Бенджамин Франклин говорил, что если не умеешь планировать, то провал как бы уже запланирован. Плохое планирование — одна из главнейших причин неудачных проектов. Успех всякого проекта зависит от уточнения и детального описания проекта, роли каждого участника, и таймлайнов. Небрежное, излишне идеалистичное планирование ставит проект под угрозу. Потеря времени неминуема, если проджект-менеджер лихорадочно пытается понять как решить кризисную ситуацию в проекте, не имея даже плана «А» в приемлемом виде.

Решение: если план проекта тщательно прописан, и он реалистичен, риски значительно снижены.

Синдром кухонной раковины

Представим, что проект стартовал, он растет и крепнет, и цели в проекте обновляются по мере его продвижения. Если не учитывать растущий масштаб, не приспосабливаться к изменяющимся требованиям, и не учитывать ограничения, то задачи и ответственность увеличатся так, что команда не сможет с этим справиться вовремя. Эта ситуация называется scope creep, или «синдром кухонной раковины». Это «нагромождение задач» может выглядеть просто как большой список незакрытых запросов и невыполненных задач. Накопление никогда не происходит резко, так же как гора посуды не появляется в раковине одномоментно; проблемы и задачи просто накапливаются, если их не решают. А потом они обрушивают проект.

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

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

Решение: согласовать масштаб проекта и довести исполнителям, и в дальнейшем контролировать.

Некомпетентность в выделении ресурсов

Планирование это не только таймлайны, митинги и корректировки. Человеческие, финансовые, аппаратные ресурсы важны также. Если эти факторы некорректно распределены в начале, это подрывает проект.

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

Решение: подготовить план управления ресурсами и придерживаться плана, что позволит существенно снизить риски.

Изначально нереалистичные дедлайны

Если под сложные задачи выделены явно недостаточные дедлайны. Важно тщательно проверять все нюансы проекта, и реалистично оценивать, сколько времени требуется.

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

Непрозрачность

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

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

Плохая коммуникация

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

Решение: хороший проджект-менеджер одобряет и стимулирует активную коммуникацию между командой и стейкхолдерами.

Нереалистичные ожидания от команды

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

Решение: смотреть на команду критично, не перегружать задачами, превышающими уровень ее компетентности.

Плохой мониторинг

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

Решение: Возможно, окажется полезной методика мониторинга проектов по принципу Earned Value. Эта изначально «бухгалтерская» методика на практике представляет собой постоянное сопоставление плана проекта и выполненных задач, с учетом потраченных ресурсов и созданной при этом добавленной стоимости. Также оценивается, какой объем средств понадобится для завершения проекта. 

Хороший мониторинг предполагает личное присутствие проджект-менеджера в офисных помещениях, где создается продукт, и (душевные) разговоры с участниками команды.

Плохой риск-менеджмент

Вообще без рисков не бывает. А если в проекте нет контроля рисков и даже «плана Б»?

Решение: внедрить управление рисками (риск-менеджмент) уже в начале проекта. Определить и приоритизировать риски = ограничить или вообще устранить их, превентивно.

Не налаженные отношения со стейкхолдерами

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

Решение: проджект-менеджер должен качественно коммуницировать со стейкхолдерами и делать это вовремя. Взаимопонимание с ними обеспечит их поддержку.

***

ИТ-проект будет успешен, если соблюдаются простые правила:

  • Создать хороший план
  • Поставить реалистичные цели
  • Грамотно управлять рисками
  • Разумно распределять ресурсы
  • Найти качественные инструменты управления проектами
  • Автоматизация рутинных задач
  • Мониторить ход проекта
  • Эффективная коммуникация

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас