Про неуспешные проекты и что делать, чтобы в них не вляпаться

Сегодня будет про неуспешные проекты

Про успешные проекты я уже писал вот тут (Что такое Успешный проект), а теперь пришло время поговорить про плохое: основные факапы в проектах, причины, их порождающие, и что можно сделать, чтобы неуспешных проектов у вас, как менеджера (или как менеджера менеджеров) было меньше.

Tldr: статья на статистике доказывает, что самое важное – софтскиллы у РП, а с этим на рынке ИТ проектов сейчас проблемы.

Статья состоит из 2 частей:

– статистика по мировому и (немного) российскому рынку;

– мои выводы из этой статистики.

Это – очередная статья, посвященная тому, чему менеджеров не учат на курсах – софтскиллам. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» , а также читайте другие статьи здесь, на Хабре

Часть 1 статистика

Для чего нужна статистика: самые хорошие инсайты приходят мне в голову, когда я вылезаю из своего домика (личного опыта) и смотрю на проблемы других людей, сравнивая со своими. Мой обзор рынка – как раз такой способ поднять голову и поглядеть «а как там у них?»

Статистика приводится на основании открытых данных от трех мировых китов: Gartner, PMI, и Standish Group. Это открытые данные по ИТ проектам за последние 3 года, если у вас есть более актуальная статистика – пишите в комментариях.

Сперва поглядим сколько успешных, а сколько неуспешных проектов по миру:

2023 (Standish Group CHAOS Report): 

• 31% ИТ проектов завершены вовремя и в бюджет;

• 52% столкнулись с проблемами (превышение времени/бюджета, сокращение объема работ);

• 17% полностью провалены. 

2022 (PMI Pulse of the Profession): 

• 43% проектов попали в оригинальные сроки и бюджет; 

• 62% достигли поставленных целей с корректировками.

• Главные проблемы: расползание объема (35%), ресурсные ограничения (30%). 

2021 (Gartner/Geneca Survey): 

• 50-60% ИТ проектов выполнены вовремя и в бюджет, но с сокращением объема. 

По российскому рынку:

• Единого источника не нашел, по разным данным объем проектов, завершаемых с нарушениями, от 35% до 70% , где 35% – коммерческий сектор, а 70% – госсектор (цифры «от и до», то есть это пиковые значения на основании различных источников).

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

Если у вас есть статистика по вашим собственным проектам – можете сравнить. Если у вас меньше – вы скорее круты, чем нет, если больше – у вас все также, как у других

Теперь перейдем к источникам проблем

Standish Group (CHAOS Report 2023) топ 5 причин по перерасходу или провалу: 

1. Нечеткие требования (37% проектов): слабо определенные цели, объем или критерии приемки.

2. Недостаточное вовлечение пользователей (32%): стейкхолдеры не вовлекались в ходе работ по проекту.

3. Слишком оптимистичные сроки (29%): Нереалистичные сроки без запаса на риски. 

4. Неадекватное управление рисками (25%): Неучтенные операционные или технические риски. 

5. Смена приоритетов (22%): Смена потребностей в ходе проекта. 

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

PMI (Pulse of the Profession 2023) топ 5 причин по перерасходу или провалу

1. Расползание объема работ (35%).

2. Ошибки при сборе требований (38%): несогласованность между заинтересованными сторонами и командами.

3. Нехватка ресурсов (30%): нехватка квалифицированного персонала или инструментов.

4. Слабая коммуникация (27%): недопонимание между командами и руководством.

5. Неадекватное управление (24%): слабый надзор за проектами и принятие решений.

Вывод в отчете: те, кто управляет рисками, факапят на 50% меньше. Управляйте рисками, дорогие менеджеры. Прочтите для начала вот эту мою статью про риски (этого вам хватит до Senior уровня и крупных проектов).

Gartner (IT Project Benchmark 2022–2023) топ 5 причин перерасходов.

1. Расползание объема работ (47% проектов): часто связано с плохо управляемым переходом на agile.

2. Технический долг (33%): время на легаси/работу с легаси или на устранение костылей.

3. Несоответствие бизнес-целям (28%): ИТ-команды делают не то, что от них ждут.

4. Недостаток знаний (25%): нехватка навыков в области облачных технологий, искусственного интеллекта или кибербезопасности.

5. «Культура героев» (20%): выгорание от команд, компенсирующих пробелы в процессах.

Вывод в отчете: неинтересный, AI/ML проекты неуспешны в 45% из-за проблем с качеством или завышенных ожиданий (и то, и то – две стороны одной медали, если задуматься).

Российская специфика задержек проектов.

Здесь нет процентов, потому что нет соотвествующих исследований. Зато нашлись основные проблемы и это:

1. Административные барьеры (особенно в госсекторе): длительные согласования, частые изменения ТЗ (любопытно, как это коррелирует с 44-ФЗ и 223-ФЗ, по которым изменений в ТЗ быть как раз не может).

2. Дефицит квалифицированных кадров: рост спроса после ковида, утечка после 22 года и рост потребности из-за импортозамещения; 

3. Импортозамещение:  переход на российское ПО увеличивает сроки внедрения на 20-30% (данные CNews, для меня этот показатель дутый прежде всего в том, что российское ПО в массе пока что не способно заменить промышленные образцы массового ПО вообще: от MS Word до какого-нибудь Enterprise решения вроде IBM Tivoli).

4. Санкции: проблемы с поставкой оборудования и лицензий.

Немного дополнительных рисков на текущее/будущее:

• Удаленка: увеличение накладных расходов на коммуникации на 15–20 % (Gartner).

• Сложные технологические стеки: миграция в облако и интеграция ИИ добавляют 10–30 % незапланированных усилий (PMI).

• Риски кибербезопасности: непредвиденные доработки по требованиям безопасности приводят к 18 % перерасхода бюджета (Standish).

И рекомендации по решению проблем от уважаемых коллег (которые я дополню во второй части статьи):

1. Больше воркшопов по сбору требований. Уменьшайте неоднозначность на ранних этапах (PMI).

2. Применяйте гибридные методики там, где только возможно: это дает хороший баланс структуры и гибкости (Gartner).

3. Используйте аналитику проектов на основе ИИ: прогнозируйте риски и дефицит ресурсов (Standish). Замечание от меня: совет классный, но в большинстве российских компаний нет приемлемой статистики, чтобы ИИ мог хоть что-то предсказать

4. Управляйте заинтересованными сторонами и не забывайте про процесс управления изменениями.

На этом с обобщенной статистикой заканчиваю и перехожу к простому выводу ниже.

Часть 2 Софтскиллы – это наше все

Если поглядеть на список проблем неуспешных проектов выше, то получается, что порядка 80% — это про софтскиллы Руководителя проектов:

1. Нечеткие требования (37% проектов): слабо определенные цели, объем или критерии приемки – это про умение общаться с заказчиком, выявлять ответственных и согласовывать требования так, чтобы потом не было мучительно больно.

2. Недостаточное вовлечение пользователей (32%): Стейкхолдеры не вовлекались в ходе работ по проекту. Тут даже добавить нечего. Прямая обязанность РП – это обсуждать все и со всеми по многу раз. Просто потому, что если вы этого не будете делать, может сработать вот этот риск.

3. Слишком оптимистичные сроки (29%): Нереалистичные сроки без запаса на риски.  Это история про то, что РП вписывается в проект с нереалистичными сроками и не может сказать «Нет» сразу. Все думают, что РП вытащит (мало ли, он маг), а он не маг, он просто боится сказать «Нет». Здесь читаем мою статью Как говорить «Нет», если все хотят от вас услышать «Да».

4. Неадекватное управление рисками (25%): Неучтенные операционные или технические риски.  Для меня это проблема на стыке управления ожиданиями, коммуникаций с командами и бизнесом и классической работы с рисками – два в одном.

5. Смена приоритетов (22%): Смена потребностей в ходе проекта.  От таких вещей не застрахован никто, но, общаясь с заинтересованными сторонами, РП может узнать о проблемах раньше и раньше отреагировать. И, к примеру, помочь своему заказчику не отказываться от проекта, а переформулировать состав работ так, чтобы это отвечало изменившимся целям. И это тоже софтскиллы РП.

6. Ошибки при сборе требований (38%): несогласованность между заинтересованными сторонами и командами. См п.1 выше, тут тоже самое.

7. Слабая коммуникация (27%): недопонимание между командами и руководством. Коммуникации – обязанность РП. Поговорить с командой, поговорить с шефом, поговорить с заказчиком, поговорить с исполнителями на стороне заказчика. Это и есть каждодневная и незаметная работа РП: вроде болтает непрерывно, а проект сам собой отлично едет у него. Нет бы делом занялся. Но нет, он и занят делом. Там, где у РП отличные отношения с клиентом, с бизнесом, там больше вероятность успешного проекта. Там есть доверие и взаимопонимание. Коммуникации — это критически важно.

8. Неадекватное управление (24%): слабый надзор за проектами и принятие решений. Надзор и мониторинг не выражается в том, что РП расставил колбаски в Проджекте и таски в трекере и ждет, когда будет сделано. Мониторинг – это искусство собирать статус, не привлекая внимания санитаров, не отвлекая при этом команду. Здесь уже важны процессы, а не только навыки РП. Скажу так: РП может вытащить эту часть и без инструментов, но с хорошим процессом и парой-тройкой систем, он сможет сделать 2, а то и 3 таких же проекта в одно лицо (Вот, кстати, и обоснование выгоды систем управления ИТ задачами и командами )

9. Несоответствие бизнес-целям (28%): ИТ-команды делают не то, что от них ждут. Классика жанра, когда требования собрали, а сделали не то. Опять вопросы к РП, который плохо коммуницировал цели проекта и отвечает за слабый бизнес-анализ.

Итого

Причиной подавляющего большинства проблем в проектах являются софтскиллы Руководителей проектов.

Это же (внезапно) и есть одна из самых больших проблем ИТ рынка РФ прямо сейчас. Наткнулся на такую удивительную статистику:

Обратите внимание на количество РП-джунов. Я не проверял методику, по которой коллеги собрали такие данные, но мое личное ощущение от рынка примерно тоже самое: очень много новичков среди РП, уровень управления просел относительно того, что было даже лет 10 тому назад.

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

Софтскиллы – самая критичная часть набора знаний Руководителя проектов в ИТ, которой почти никто не учит. Есть сертификация по PMBoK, есть PMI и Agile Coach-и, но нет сертифицированных специалистов по софтскиллам. И каждый раз, собеседуя менеджера, ты выбираешь кота в мешке, независимо от его сертификатов.

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

Мораль 1: ключевым фактором успеха проекта является личность РП и уровень его опыта и софтскиллов.

Мораль 2: второе по важности – владение базовыми инструментами проектного управления.

Ну и напоследок скажу, что все мои статьи и посвящены этим вопросам, так что если не хотите получить проблемы выше на своих проектах – читайте мои предыдущие статьи на Хабре (скоро из них уже учебник получится), и подписывайтесь на ТГ канал, где мы обсуждаем все те же самые проблемы.

Как говорится, make project management great again