Даже самый хорошо спланированный ИТ-проект может столкнуться с препятствиями из-за фатальных ошибок в управлении. Дмитрий Мазеин, генеральный директор ГК Advanta, рассказывает о самых распространенных из них и о том, как их избегать.
Красный флаг: когда ИТ-проект может обернуться провалом
- По данным Standish Group, лишь 31% ИТ-проектов можно назвать успешными, а масштабные инициативы успешны менее чем в 10% случаев.
- Одновременно исследование McKinsey показало, что 17% крупных ИТ-проектов движутся настолько плохо, что угрожают самому существованию бизнеса.
У каждой компании есть хотя бы одна история о том, как внедрение ИТ-решения заняло больше времени, чем планировалось, или вышло за рамки бюджета.
Почему же ИТ-проекты, даже самые перспективные, терпят неудачу?
Чаще всего проблема кроется в недооценке проектного управления. По результатам исследования Project Management Institute, всего 46% компаний уделяет этому вопросу достаточное внимание.
Для большинства руководителей управление проектом равно отслеживание задач. Но такой подход ведет к фатальным ошибкам, которые становятся причиной провала. Вот наиболее распространенные из них.
Ошибка 1. Поверхностные договоренности «на берегу»
Проект, в котором бизнес-заказчик и команда исполнителей не понимают и не слышат друг друга, обречен с самого начала. Поэтому любая ИТ-инициатива должна начинаться с диалога.
Узнайте, как запустить свой акселератор по ссылке
- Важно еще на этапе планирования обсудить ожидания заказчика, определить масштабы проекта, необходимые ресурсы и время реализации.
- Важно мыслить реалистично и закрепить все условия в виде соглашения, даже если проект внутренний — устные договоренности могут не выполняться и грозить затягиванием сроков, увеличением бюджетов и другими рисками.
Залог хорошего старта для ИТ-проекта — техническое задание, подготовленное заказчиком и согласованное исполнителем.
ТЗ обычно включает:
- цели,
- задачи,
- сроки проекта,
- требования и ограничения,
- а также подробное описание будущего scope, то есть содержания проекта (например, планируемой функциональности итогового продукта).
При этом оно не должно включать раздутый список ненужных спецификаций «на перспективу». Только реалистичные условия и сроки.
В подготовке такого технического задания должны принимать участие как технические специалисты, так и будущие бизнес-пользователи — так оно будет наиболее точным.
Ошибка 2. Планирование спустя рукава
Большинство проектов терпит неудачу еще на этапе планирования. Успешные проекты требуют полной прозрачности и строго определенной последовательности действий.
50% результата определяется тем, насколько участники одинаково понимают цели проекта и то, какие задачи и в какие сроки должны быть выполнены для их достижения.
- Крайне важно, чтобы эта информация была непротиворечива и доступна всем участникам процесса.
- Необходимо донести до каждого из них цели проекта и составить строгий график работ.
- Под каждую задачу должны быть назначены сроки регулярного мониторинга и ответственные лица. Благодаря этому удастся избежать растягивания времени и размывания ответственности — проблем, которыми так часто страдают ИТ-команды.
- В идеале в графике должны быть указаны и приоритеты — ключевые направления и задачи проекта.
Так, мы в своей практике управляем проектами по контрольным точкам. Лишь после достижения той или иной контрольной точки мы можем заняться доработкой решения или расширением контура проекта.
Такой подход позволяет нашей ИТ-команде не «закапываться» в усовершенствованиях и не отклоняться от заданного курса.
Читать по теме: Бизнес как море: 5 советов по управлению командой, чтобы не потопить проект
Ошибка 3. Бесконечный круговорот правок в проекте
Чаще всего в ходе проекта заказчик требует правок или масштабирования. Важно подготовиться к этому:
- предусмотреть в графике работ время на внесение правок;
- подготовить план, как приспособиться к этим изменениям, не нарушая общих приоритетов проекта;
- предварительно проговорить с клиентом его ожидания, то, какие типы доработок разумны, а также уточнить предельно допустимое количество итераций правок.
Наконец, стоит отдавать себе отчет: необходимость вносить изменения в проект может всплыть в любой момент.
Успешно справляться с этим позволяет доступ к максимально точной и достоверной информации о каждом этапе проекта, ответственных, ходе работ.
Данные должны быть актуальны и доступны в режиме реального времени. Только так удастся грамотно координировать ресурсы и мгновенно реагировать на изменения в содержании и границах проекта.
Ошибка 4. Игнорирование ошибок
Некоторые руководители склонны игнорировать мелкие ошибки на проекте, если в целом его результаты положительные.
Это в корне неверный подход. Проблемы не решатся сами собой. Они продолжат множиться, и если не устранять их на ранней стадии — окажут существенное влияние на сроки и бюджет проекта.
Ошибки должны сразу же исправляться!
Чтобы выявлять их, можно, к примеру, организовать еженедельные встречи с командой с целью брейншторма и разбора полетов. Главное, чтобы они проходили на позитивной ноте и не занимали много времени.
Ошибка 5. Размытие ответственности
Многие проектные команды становятся жертвами принципа Парето: 20% их членов на самом деле выполняют 80% работы. Это катастрофа и для производительности, и для сплоченности команды.
Если пустить такую ситуацию на самотек, со временем участники проекта начнут все больше расслабляться, процессы — стопориться, и в конечном счете команда станет совершенно дисфункциональной.
При этом спрашивать в таких командах обычно не с кого — все перекладывают ответственность. Это особенно актуально для крупных ИТ-проектов с большим числом вовлеченных специалистов и значительной бюрократией.
Для проекта это прямой путь в никуда. Поэтому любой сотрудник должен очень четко осознавать, за что он отвечает, и что негативное лично для него стоит ожидать, если нужный результат не будет достигнут.
Читать по теме: Модель взаимоотношений бизнеса и ИТ-разработчиков: старые ошибки и новые рецепты
Ошибка 6. Снятие ответственности с заказчика
Нередко заказчик перекладывает всю ответственность на исполнителей. Это тоже неверно — именно сотрудникам заказчика предстоит работать с ИТ-продуктом. Они должны быть вовлечены в процесс.
В идеале стоит определить спонсоров или кураторов проекта — ответственных со стороны заказчика, которые заинтересованы в цифровизации.
Нередко это функциональные заказчики, первые пользователи продукта или руководство компании. Внутренние спонсоры понимают ценность происходящих изменений и могут донести ее своим коллегам.
Таким образом они стимулируют процесс изнутри. А при необходимости могут надавить авторитетом, чтобы проект сдвинулся с мертвой точки.
Так можно ли предотвратить провал ИТ-проекта?
Ошибки в управлении ИТ-проектами обходятся бизнесу в сотни тысяч, а нередко и в миллионы рублей.
Они влияют на производительность, вызывают задержки проектов, а в некоторых случаях приводят к серьезным сбоям в работе итогового продукта.
В случае внедрения бизнес-критичных систем это может привести к необратимым последствиям для компании. Но их можно избегать.
Главное — «знать врага в лицо» и предпринимать меры противодействия:
- точно планировать все процессы и действия;
- обговаривать детали «на берегу»;
- гибко управлять изменениями;
- непрерывно общаться с командой и обеспечивать ее точными, непротиворечивым сведениями;
- сразу же исправлять даже минорные неточности;
- работать в тесном взаимодействии с заказчиком.
Только в таком случае ИТ-проект с высокой долей вероятности будет успешен.
Читать по теме: 5 типичных ошибок при создании hardware-стартапа: как сделать по-настоящему нужный продукт
Фото на обложке: Unsplash
Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!
Источник: rb.ru
