По данным исследования PwC, проанализировавшего более 10 000 проектов по всему миру, лишь 2,5% компаний доводят проекты до 100% прибыли одновременно по всем исходным параметрам — срокам, бюджету и качеству. Это означает, что ошибка в той или иной форме — статистическая норма, а не привязка, и эффективность менеджера исследований не исключает проблем, а возможность их предотвращать или быстро корректировать. Ежегодный отчёт PMI Pulse of the Profession определяет причины: изменение приоритетов внутри организации становится причиной сбоя в 40% случаев, ограниченность ресурсов — в 20%. Более раннее, но методологически подробное исследование PMI за 2017 год разбивает картину ещё точнее: нечёткие цели и размытые критерии успеха вызывают 37% провалов, плохо выстроенные коммуникации — 19%, недостаточное участие и поддержка — 18%. Сложив эти данные, можно увидеть закономерность: подавляющее большинство сбоев, связанных не с техническими ошибками в расчетах, а с управленческими и коммуникационными сбоями на старте проекта.

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

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

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

Современные проекты требуют большей гибкости, чем потребовалось десятилетие назад. Организации, системно применяющие Agile-подход, показывают на 37% быстрее и показывают на 30% более высокую прибыль по сравнению с технологиями, не использующими гибкие методологии — при этом лишь треть предприятий передают данные о частом и системном использовании Agile-принципов на практике. Это означает, что даже полностью составленный план, зафиксированный один раз в начале проекта и никогда не пересматриваемый по ходу работы, сам по себе становится фактором риска — реальность меняется быстрее, чем формулируется устаревать бумажный план.

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