Провал проекта редко бывает следствием одной ошибки. Обычно это цепочка мелких решений, каждое из которых по отдельности выглядит оправданным: сдвинутый срок, еще одно изменение требований, отложенное согласование.
Внутри одного проекта такие решения и правда выглядят как рабочий компромисс – иначе их бы не принимали. Но если смотреть не на один проект, а на все сразу, становятся видны сигналы, которые по отдельности не заметны.
Сигналы: что видно только на уровне портфеля
Эти два сигнала устроены похоже: внутри проекта каждый выглядит безобидно, а при сравнении проектов между собой складываются в картину.
1. Сроки сдвигаются в нескольких проектах одновременно
Каждый менеджер объясняет сдвиг по-своему: у одного затянулось согласование, у другого подрядчик не успел, у третьего заболел аналитик. Но даты совпадают, и это важнее объяснений: за ними может стоять одна и та же причина – один подрядчик, один этап согласования, одна нехватка людей.
По отдельности три сдвинутых срока – три разные истории. Вместе – похоже на сбой на уровне управления.
2. Одни и те же фамилии стоят в планах нескольких проектов
В каждом отдельном плане загрузка сотрудника выглядит нормально: 30% в одном проекте, 40% в другом, 20% в третьем, ещё 30% в четвертом. Проблема видна, когда складываешь эти доли по одному человеку: в сумме выходит больше, чем у него есть времени. А значит, вероятен срыв сроков или потеря качества.
Сигналы, для которых сравнения проектов недостаточно
Эти два сигнала устроены иначе. Их не видно при сравнении проектов между собой, но они проявляются, когда смотришь на один проект во времени или на связи между проектами. Пропускать их всё равно не стоит: природа другая, а риск тот же.
1. Бюджет пересматривают чаще, чем меняется объем работ
Сначала выросли лицензии, потом добавились доработки, потом понадобилась интеграция, которую не закладывали. Каждое такое изменение – законный повод пересмотреть бюджет, и по отдельности эти пересмотры оправданны. Но если они идут один за другим, а объем работ растет несоразмерно – скажем, на 10% при пяти пересмотрах, – проблема, скорее всего, не в изменениях, а в первоначальной оценке.
2. О проблеме узнают от смежного проекта, а не из своего мониторинга
Классика: интеграция встала, потому что в другом проекте поменяли API – и никто не предупредил. Или срок сорвался, потому что тот же подрядчик в это время был занят на другом проекте. Один такой случай ещё ничего не значит. Но если новости о проблемах регулярно приходят извне, зависимости между проектами, скорее всего, никто не держит в поле зрения.
При этом ни один из этих четырех сигналов выше не является доказательством провала: у каждого может быть невинное объяснение. Поэтому смотреть на них надо в совокупности: насколько они повторяются, связаны ли между собой и влияют ли на общие цели компании. А чтобы отслеживать это системно, нужны метрики.
Метрики, которые не дадут пропустить сигнал
1. Отклонение прогнозных сроков от базового плана
Считаем: разницу между текущей прогнозной датой финиша и датой в базовом плане, в рабочих днях, ежемесячно по каждому активному проекту.
Сигнал: отклонение растет три месяца подряд или дата финиша пересматривалась трижды за квартал.
2. Рост ожидаемой стоимости проекта
Считаем: отклонение текущей прогнозной стоимости (EAC) от первоначальной сметы (BAC), в деньгах и в процентах от сметы, ежемесячно.
Сигнал: прогноз растёт несколько периодов подряд, а объем работ при этом почти не меняется.
3. Суммарная загрузка ключевых специалистов
Считаем: сумму долей сотрудника во всех активных проектах, в процентах от доступного времени, ежемесячно на горизонте 1-3 месяцев.
Сигнал: больше 100% хотя бы у одного сотрудника из списка ключевых.
4. Частота изменений требований
Считаем: число принятых изменений требований за период, ежемесячно.
Сигнал: больше пяти изменений за месяц, при этом базовый план и смета не пересматриваются.
5. Задержки на межпроектных зависимостях
Считаем: число задач, заблокированных из-за невыданного результата смежного проекта, и суммарные дни таких блокировок, еженедельно.
Сигнал: задержки повторяются у одной и той же пары проектов два месяца подряд или суммарно превышают оговоренный лимит дней за месяц.
Ориентиры выше – не универсальные константы: многое зависит от масштаба, отрасли и типа работ. Но у каждой метрики должен быть свой порог и человек, который на его отслеживает. Иначе вы получите ещё один отчёт, который ни на что не влияет.
Изображение: Diasoft
Как отслеживать сигналы: два подхода
Есть два подхода к отслеживанию сигналов: ручной портфельный обзор и через PPM-систему. Первый требует собирать данные каждый раз заново, второй делает это автоматически.
Ручной портфельный обзор
Раз в месяц PMO или руководитель портфеля сводит данные по проектам и проходит по пяти пунктам.
- Сопоставляет планы проектов между собой. Сроки, бюджеты и загрузку сводит в одну картину, чтобы увидеть, где отклонения совпадают по времени или по людям.
- Считает общую загрузку ключевых специалистов. Не по отдельным планам, а суммарно: если один человек стоит в трех-четырех проектах, это повод перераспределить задачи до того, как он выйдет из строя.
- Пересчитывает прогнозные затраты с учетом накопленных изменений. Не «сколько потрачено», а «сколько ещё предстоит потратить, если динамика сохранится».
- Сверяет зависимости между проектами. Общие подрядчики, общие API, общие ресурсы. Если проект зависит от чего-то вне своей зоны контроля, это нужно видеть заранее, а не узнавать от смежного проекта.
- Проверяет актуальность данных. Если планы по какому-то проекту не обновлялись дольше месяца, выводы обзора по нему ненадежны – это отдельный повод разобраться.
У этого подхода есть предел: таблицу нужно собирать заново каждый раз, совпадения ищутся глазами, а актуальность данных зависит от дисциплины людей.
Отслеживание через PPM-систему
PPM-система делает проверку постоянной. Например, в Digital Q.PM – российской платформе для управления проектами, программами и портфелями – это выглядит так:
- Сопоставление планов. Проекты группируются в портфели, а зависимости между ними выстраиваются на уровне вех, этапов или конечных задач – искать их вручную не нужно.
- Загрузка специалистов. Ресурсное планирование показывает суммарную занятость сотрудника по всем проектам, а оптимизатор ресурсов подсвечивает перегрузки и конфликты с учетом отпусков, календарей и фактической доступности.
- Прогноз затрат. Бюджеты ведутся по портфелю, программе и отдельному проекту: целевой, прогнозный и фактический – с автоматическим расчётом показателей и графиком платежей.
- Зависимости. Внешние предшественники и связи проекта видны в общей модели, а не собираются из переписки и памяти менеджеров.
- Актуальность данных. Дашборды показывают статус проекта и портфеля в реальном времени – данные обновляются по мере работы, а не раз в квартал.
Какой подход выбрать?
Ручной обзор дает картину на момент проверки. Этого может быть достаточно, если портфель проектов небольшой. Система нужна тогда, когда проектов становится столько, что ручная сверка перестает успевать за изменениями. Она делает мониторинг постоянным: данные обновляются автоматически, и отклонения видны сразу, а не тогда, когда у кого-то нашлось время свести таблицу.
Можно ли предсказать провал?
Строго говоря, провал как гарантированное событие предсказать нельзя. Но можно увидеть условия, которые ведут к провалу. Этого достаточно, чтобы вмешаться вовремя и не допустить его.
Изображение на обложке: Diasoft
Комментарии