Время чтения статьи: 5467.2 мин.
1189
Любой, кто управлял крупным проектом, знает: бюджет — это не твердая цифра, а живой организм. Он растет, меняется, требует постоянного внимания. Но редко кто задумывается, что значительная часть перерасхода заложена не в ошибках оценки, а в том, как устроено управление.
Масштаб этой проблемы подтверждают цифры. По данным McKinsey и Оксфорда, 45% проектов уходят в перерасход, а их полезность оказывается на 56% ниже плана. Исследователи связывают это с плохой реализацией проектов: управленческими решениями, принятыми без актуальных данных, и временем, потраченным на координацию вместо создания ценности.
Цена решений, принятых без актуальных данных
Каждое управленческое решение имеет цену. Правильное — приносит прибыль. Ошибочное — обходится дорого. Дороже всего обходятся решения, принятые на основе устаревших данных.
Но кто виноват в том, что данные устаревают? Ответ: ручное управление. При котором:
-
Статусы проектов собираются по электронной почте и сводятся вручную в Excel.
-
Загрузка сотрудников хранится в головах у тимлидов и обновляется «по ощущениям».
-
Отчеты для руководства готовятся к пятнице, а в понедельник они уже неактуальны.
-
Решения о приоритетах принимаются на совещаниях, где каждый менеджер громче кричит о своем проекте.
-
Блокеры фиксируются в чатах и теряются среди тысячи сообщений.
Цена ошибки
Давайте рассмотрим 2 ситуации, которые могут произойти в компании с ручным управление проектами
Ситуация 1. Найм подрядчиков по бюджету, который уже неактуален
У руководителя есть отчет трехдневной давности: бюджет 10 млн, освоено 7 млн, остаток 3 млн. На основе этих цифр он согласовывает найм двух внешних разработчиков на 1 млн, чтобы ускорить релиз.
Логика понятна: остаток позволяет. Но за эти три дня пришел счет от субподрядчика на 2,5 млн. Работы были закрыты на прошлой неделе, счет выставили только сейчас.
Значит фактический остаток бюджета: 3 - 2,5 = 0,5 млн. Руководитель тратит 1 млн на фрилансеров. В итоге компания уходит в минус по проекту на 500 тыс. рублей.
Почему так происходит?
Потому что в компании с ручным управлением проектная часть (задачи, сроки) и финансовая часть (бюджет, счета) существуют отдельно. Бухгалтерия видит счет, а проектный менеджер узнает о нем только из пятничного отчета.
В правильно настроенной системе управление проектами (PM-системе) этот счет был бы автоматически привязан к проекту. Остаток бюджета уменьшился бы в момент регистрации счета. А руководитель увидел бы не 3 млн, а 0,5 млн и не согласовал бы найм.
Ситуация 2. Сдвиг сроков без учета зависимостей
Руководитель согласовывает перенос финальной вехи по проекту «Х» на две недели. Проект внутренний, кажется не критичным и он видит только статус этого проекта.
Но проект «Х» — поставщик данных для трех других проектов: «Y», «Z» и «W». Это зафиксировано в архитектурной документации, но не в системе управления проектами. На совещании никто не поднимает этот вопрос — документацию никто не открывает.
Как только веха сдвигается, все три зависимых проекта автоматически срывают сроки. Каждый из них — с внешним заказчиком и штрафами за задержку.
Цена:
-
Штраф по проекту «Y» — 1 млн ₽
-
Штраф по проекту «Z» — 1,5 млн ₽
-
Штраф по проекту «W» — 1 млн ₽
-
Потеря контракта с заказчиком «Y» (клиент ушел к конкуренту) — 4 млн ₽
Итого: 7,5 млн ₽.
Почему так происходит?
Потому что в ручной системе зависимости между проектами существуют только в документации, а не в управленческом инструменте. Когда руководитель смотрит на проект «Х», он видит только его сроки.
В правильно настроенной системе управления зависимости между проектами видны в том же окне, где принимается решение. Руководитель видит не просто «сдвиг вехи», а «сдвиг вехи, который тянет за собой еще три проекта». И принимает решение с полной картиной.
Что в сухом остатке?
Наем подрядчиков по устаревшему бюджету: 500 тыс. рублей прямого перерасхода.
Сдвиг сроков без учета зависимостей: 7,5 млн рублей штрафов и потерянных контрактов.
Общая цена 8 млн рублей. И это только на двух решениях принятых без актуальных данных.