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


Привет! Меня зовут Игорь, я отвечаю за развитие Naumen Project Ruler. Много общаюсь с заказчиками, изучаю их задачи и практики проектного управления и вместе с командой определяю, куда продукт будет двигаться дальше.

Игорь
Руководитель развития продукта Naumen Project Ruler
Когда при реализации портфеля проектов выявляется дефицит ресурса исполнителей (на языке специалистов, «переподписка»), чаще всего говорят о некачественном планировании. По моему убеждению, в большинстве случаев дело не в этом. Руководители проектов прекрасно ориентируются в оценке того, сколько ресурсов потребуется для достижение целей. Так что, портфель с заведомым дефицитом согласовывается «с открытыми глазами». Причины — в человеческом и организационных факторах. Объясню подробнее, почему так происходит.
Переподписка в проектах как перестраховка
Часть утвержденных инициатив не стартует в срок, и это данность. Так происходит по множеству причин, которые сложно предусмотреть: сокращение бюджета, смена руководства с последующим пересмотром приоритетов, изменение стратегии, новые факторы на рынке, уход бизнес‑заказчика из проекта.
Допустим, произошло подобное событие, а проекты уже утверждены. И вот, некоторые из них не запускаются, а ресурсы под них зарезервированы. Получаем простой дорогостоящих специалистов. Казалось бы, можно просто «отменить бронь». Но если инициативы хоть и с опозданием, но удастся запустить, то не факт, что у специалистов на тот момент по‑прежнему окажется свободный ресурс. Поэтому то, что уже зарезервировано, хочется удержать.
Сценарий вполне распространенный в проектной практике. Именно его держат в голове участники портфельного комитета, утверждая для портфеля проекты, которые требует заведомо больше ресурсов, чем предусмотрено. Объем работы планируется про запас как некая перестраховка.
Вместе с тем переподписка имеет смысл, когда она контролируемая. Это значит, что ее размер (коэффициент переподписки) четко определен и не превышается. Здесь сразу важно обозначить проекты из зоны риска: которые могут не запуститься, а также инициативы, на которые будут перенаправлены ресурсы, если это понадобится. Еще нужно предусмотреть ситуацию, при которой ничто не помешало старту утвержденных проектов, и портфель оказался с дефицитом ресурсов. Какие инициативы будут в приоритете в этом случае?
Простой и быстрый тест на контроль переподписки — на портфельном комитете задать вопрос: «Какие три проекта мы приостановим первыми, если не будет хватать людей?». Если звучат конкретные названия, имена заказчиков, руководителей проектов и сроки, то процесс управляемый. Если же ответ: «Будем решать по ситуации», это уже отсутствие планирования и действия на «на удачу».
Переподписка предполагает дефицит ресурса, тогда как планирование даже просто 100% приводит к сбоям в сроках. Еще в 1961 году британский математик Джон Кингман выявил закономерность в теории массового обслуживания. Суть в следующем: если в процессах присутствует хотя бы малейшая вариативность (она же — изменчивость), то время ожидания в очереди растет нелинейно и резко увеличивается по мере приближения загрузки системы к 100%. Формула Кингмана выглядит так:
Где:
Wq — время ожидания задач в очереди;
Ca и Cs — показатели вариативности процессов;
Т — среднее время выполнения задачи;
ρ — загрузка специалистов.
Переложим идею на проектную деятельность. Если распределены все 100% ресурсов исполнителей, то сроки работ неизбежно будут нарушаться.
Команда проекта — не роботы. Специалисты не могут работать каждую минуту с одинаково высокой продуктивностью. В итоге на одну задачу времени уйдет больше, чем запланировано, на другую меньше. И это не означает, что одно покроется другим. По этим же причинам проекты никогда не идут четко по плану. Возникают форс-мажоры, срочные работы, исправления багов — все то, что не предусмотрено планом. Эти факторы и составляют изменчивость в проектной деятельности. В формуле это показатель Cs — вариативность времени выполнения.
Но мы видим в ней и Ca. Это вариативность поступления задач. В проектах всегда задействованы смежные подразделения, подрядчики, партнеры, которые ставят задачи, верифицируют их, согласовывают, принимают результат. На этих этапах также могут возникать задержки. А потом задачи разом возвращаются к исполнителям с правками и комментариями, ломая все планы.
Принцип Кингмана доказывает: как только вы распределили задачи так, что загрузили людей под 100%, любое случайное отклонение (заболел сотрудник, затянулось обсуждение, изменились требования) пускает сроки портфеля под откос. Очередь из задач становится неуправляемой. Поэтому при планировании загрузки специалистов распределять время следует не более чем на 85%. Полученный «буфер» в 15% поглощает неизбежный хаос и позволяет проектам двигаться последовательно и прогрессировать, в целом оставаясь в сроках.
Почему сложно сказать смелое «нет, не берем» на портфельном комитете
Портфельный комитет — всегда набор участников с явным или скрытым конфликтом интересов. Этот фактор нельзя недооценивать. И здесь интересные «ножницы». Что честнее или даже выгоднее по последствиям? Сразу при утверждении сказать автору инициативы: «Нет, в портфель проектов не включаем. Вижу такие риски…». Либо промолчать, и на этапе реализации услышать уже ожидаемое от команды: «Мы не успеваем».
Суровая практика проектных будней показывает, что в аспекте человеческого фактора «не успели» в процессе реализации оказывается предпочтительнее, чем «нет» до старта.
Что будет, если сказать: | |
«Нет, не берем» | «Не успеваем» |
Публичное противостояние конкретного человека автору инициативы | Размытая ответственность |
Часто в ответ возникает адресная негативная реакция | Никто не виноват, так как задержки по объективным причинам |
Возможный аналогичный ответ при запуске уже других инициатив | За последствия расплачивается компания, а не конкретная команда |
В статье Hollister R., Watkins M. Too Many Projects (Harvard Business Review, 2018) указываются частые причины, по которым люди предпочитают не высказываться против чужих проектов и тем самым изначально способствуют перегрузке портфеля.
Political logrolling — поддержка чужой инициативы в обмен на поддержку своей.
Никто и не пытается объективно проанализировать и оценить проект. Одобрение происходит из «политической вежливости» и для личной выгоды. В ожидании того, что впоследствии коллеги ответят тем же. В портфель попадает все подряд, и ресурсы команды заканчиваются очень быстро.
Impact blindness — отсутствие оценки совокупного эффекта.
Проекты рассматриваются изолированно, а не в комплексе, не учитывается, что уже реализуется, какие ресурсы запланированы и сколько доступно. В итоге одобряется несколько «хороших и важных» проектов, а когда начинают распределять специалистов, оказывается, что их недостаточно.
Unfunded mandates — задачи без выделения ресурсов.
Руководство обозначает новую цель, и при этом не останавливает уже действующие проекты и не добавляет ресурсы на новые. От команды ждут, что она немедленно возьмется за только что появившиеся задачи «в рамках рабочего времени». Это уничтожает «буфер» Кингмана и ведет к срыву сроков.
Сost myopia — некорректное определение затрат.
Учитываются только очевидные, прямые затраты. Например, в ИТ‑проектах внедрения ПО это будет стоимость лицензий. А скрытые и отложенные (интеграция, обучение сотрудников, поддержка, исправление багов) игнорируются. Так портфель получает необъективную оценку. А когда начинается реальная работа, трудозатраты оказываются в разы больше, чем предполагалось и мультиплицируются на все проектные инициативы.
Organizational Inertia — организационная инерция.
Явление, при котором компания не тормозит и не закрывает проекты, которые потеряли актуальность или убыточны. На них продолжают тратить ресурсы, потому что жаль того, что в них уже вложили. В итоге запускаются новые инициативы, но одновременно старые и неэффективные продолжают существовать. Портфель разрастается, а ресурсы не увеличиваются.
Что должно измениться, чтобы сделать ваше «нет, не берем» возможным
Такой сценарий становится реальным, если ввести ряд правил при утверждении состава портфеля проектов.
Анонимность оценки и голосов. Рассматриваемые инициативы представляются без авторства. Озвучиваются только фактические результаты голосования, без деталей: кто именно и как высказался. Это минимизирует влияние личных взаимоотношений.
Понятное замещение. Новый проект добавляется в портфель только при четком понимании, какой другой проект останавливается. Если такой информации нет, отказ в пополнении портфеля уже обоснован.
Установка коэффициента переподписки. Определяется заранее вместе с приоритизацией. Если потенциальный состав портфеля не укладывается в определенные рамки переподписки, это также основание для аргументированного «нет».
Общая ответственность за пропускную способность портфеля. За сроки и трудозатраты отвечают не только руководителя проектов, а весь портфельный комитет, так как изначально ресурсы распределял он.
Как повысить точность планирования проектов на практике
Для полноценного внедрения правил — так, чтобы они реально работали, — необходима комплексная картина по всем ключевым составляющим портфеля проектов с учетом приоритетов. Обеспечить такую возможность поможет решение для автоматизации управления проектами (ИСУП). Например, у Naumen это продукт Project Ruler (NPR).
Если данные по каждому портфелю «живут» в разных файлах, системах и у разных РП, работать с ними в общем контексте портфеля не получится. При сборе данных в один источник, что‑то потеряется, что‑то исказится при передаче. В итоге пострадает достоверность, а значит, и оценка состава проекта будет некорректной.
Например, в NPR данные на уровне портфеля проектов компании автоматически собираются и обновляются на основе сведений по отдельным проектам. Таким образом можно отслеживать как сводную информацию по ключевым параметрам портфеля (бюджету, ресурсам, рискам), так и в разрезе каждой реализуемой инициативы. Эти данные можно вывести на дашборд. Так будет удобнее сравнивать и анализировать.

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

Например, определить дефицит ресурсов важно не просто суммарно по ролям: «Не хватает трех аналитиков в третьем квартале». Так не работает, потому что непонятно, каким именно проектам это может навредить.
Здесь будет работать другое: если запустить инициативу N, то проекты A и B сдвинутся на столько‑то. Автоматизация даст необходимые сведения и превратит абстрактное «мы не справимся» в предметный разговор.
Также решение становится единым источником проектных инициатив для всех заинтересованных сторон. Допустим, в портфеле сдвигаются сроки. Встанет вопрос, что было известно в момент утверждения и почему так получилось. Если ответа нет, обсуждение превратится в поиск виноватого и попытки переложить ответственность друг на друга. Зафиксированная в момент принятия решения стартовая картина по проекту позволит этого избежать.
Что в итоге
Лишь качественным планированием проблему дефицита ресурсов не решить. Слишком много переменных в любом проекте. Автоматизация поможет точнее оценивать стартовые вводные в опоре на весь контекст уже запущенных проектных инициатив. Но, к сожалению, не сможет до конца исключить человеческий фактор. Разбирать конфликт интересов стейкхолдеров, бизнес‑заказчиков, разных проектных команд и говорить «нет» человеку напротив по‑прежнему нужно руководителю проекта.
И здесь интересен ваш опыт. Насколько часто в вашей проектной практике инициативу исключали из портфеля только на основании дефицита ресурсов? Не по бюджету, не по бизнес‑эффекту, а именно потому, что не хватает людей. Если таких случаев много, значит, моя позиция слабее, чем предполагаю. И это будет полезно для корректировки тезиса «запускаем проект, с ресурсами разберемся по ходу».
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.