Причины провальных проектов

Статистика неумолима: только 29% организаций завершают проекты в установленные сроки, меньше половины (43%) способны укладываться в бюджет и лишь 35% довольны текущим уровнем зрелости проектного управления¹. В результате примерно 11,4% всех ресурсов тратится впустую², и почти каждый пятый руководитель проектов признается, что мечтает оставить проектное управление³ и уйти в закат. Почему же так происходит?

Какие проекты не стоит запускать?

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

Представьте, что кто-то предлагает внедрить CRM-систему в компании, которая долгое время без неё обходилась: «Все уже живут с CRM, а мы нет». Или: «Как же так! Все заводы переходят на собственную генерацию, давайте и мы у себя газовую электростанцию поставим!» Идея звучит неплохо, и проект запускается. В худшем случае он затянется, превратится в долгострой, в него будут продолжать вкладывать ресурсы, здоровье и нервы, а потом формально закроют. Такой проект не приносит радости, а главное – никаких выгод и никаких эффектов для компании.

Поэтому проекты, которые запускаются в работу, должны соотноситься с бизнес-задачами и стратегией компании в целом. Чтобы потом не вышло так, что эффекты никто не описал или описал вместо них такую неземную красоту, которая никогда не будет соответствовать реальности. Возвращаясь к первому примеру: можно внедрить CRM для того, чтобы не упускать клиентов и повысить продажи на 10%. Только вот может оказаться, что система не влияет на продажи.

Какие проекты нужно запускать?

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

Кто несет ответственность за достижение эффекта от проектов?

Проблема в том, что на этом этапе просто забывают друг другу задать вопрос: «А с кого мы спросим за достижение эффекта?» Так как есть руководитель проекта, который несет ответственность за то, чтобы проект дошел до успешного завершения, то должен быть кто-то ответственный, кто скажет: «Я этот результат принял, и я с ним дальше работаю по достижению эффекта». Это роль заказчика проекта. Из этого следует, что роль заказчика обладает достаточной загрузкой. Он не может появиться на старте и сказать: «Вот что я хочу…», а потом заявить в конце: «Нет, мне это не нравится!»

Понимая свою ответственность за достижение эффекта в будущем, заказчик должен сформулировать свои хотелки максимально четко:

Это и есть четкое разделение ответственности. И если есть техническое задание, то руководитель проекта может просто сказать заказчику: «Я выполнил ТЗ по всем пунктам, поэтому это твоя ответственность как заказчика, что ты с помощью такого результата можешь или не можешь достичь своего эффекта». Самый плохой случай, когда говорят: «Если нет ТЗ, то и результат ХЗ». Имеется в виду, что заказчик что-то хочет от руководителя проектов, но не представляет, как он будет достигать эффект.

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

Как выстроить взаимодействие в проекте, чтобы в будущем достичь целевых эффектов?

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

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

Спустя несколько десятилетий во время «холодной войны» началась гонка за освоение космоса. У СССР было преимущество в виде системы государственного планирования и Сергея Королева, способного многое удержать в своей светлой голове. США повезло меньше: американцы не могли полагаться на чей-то гениальный ум и сделали ставку на сложную кооперацию большого количества коммерческих организаций.

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

Процедуры проверки требований включают в себя:

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

График работ, план и требования – основа коммуникации для команды. Впрочем, о ценности графика мы поговорим в следующей статье.

¹Annual report. The state of project management 2020. Published by Wellingtone.

²Ahead of the Curve: Forging a Future-Focused Culture. PMI Pulse of the Profession Report 2020.

³Harrin, Elizabeth. The 2021 Project Management Report // Rebel's Guide to Project Management. 6 January, 2022.