Общие сведения о ресурсном планировании

Термины и определения

Менеджер проекта — сотрудник, ответственный за проект.

Ресурсный менеджер — сотрудник, ответственный за выделение ресурсов на проект и их рациональное распределение между проектами. Часто эту роль выполняет линейный руководитель.

План задач — структура задач проекта. Используется для фиксирования состава работ, сроков, исполнителей и предварительной оценки трудозатрат.

Ресурсный план — сведения о планировании ресурсов на конкретные проекты, с указанием плановых часов по временным периодам (дням, неделям или месяцам). Детализация до задачи. Находится в карточке проекта.

Календарь бронирования — сведения о распределении ресурсов на проекты. Детализация до проекта. 

Назначение компонент

Назначение ресурсного плана:

  • Планирование потребности проекта в ресурсах.
  • Формирования затратной части бюджета проекта по статье «Себестоимость труда».
  • Последующий план-фактный анализ трудозатрат.

Назначение календаря бронирования:

  • Оптимизация распределения ресурсов между проектами для повышения утилизации.
  • Распределение ресурсов для избегания конфликтов совместного использования.
  • Долгосрочная оценка потребности в ресурсах.

Ресурсный план и календарь бронирование – не связаны между собой. Ресурс вполне может быть забронирован на проект, но не запланирован и наоборот. В идеальном случае запланированная емкость ресурса равна забронированной емкости, но это требует усилий.

Децентрализованное бронирование ресурсов

Общие сведения

В децентрализованной схеме Менеджеры проектов (PM) самостоятельно бронируют емкость на свои проекты:

Такой подход самый гибкий и быстрый, но требует тесного взаимодействия в команде. Главный риск – овербукинг ресурса и возникновение конфликтов за ресурсы. 

Как это работает

Общая логика процесса:

  • Менеджер проекта создает проект.
  • Менеджер проекта формирует команду сразу из сотрудников.
  • Менеджер проекта создает план задач — структуру работ, сроки, исполнителей.
  • Менеджер проекта создает ресурсный план — разносит плановые часы по исполнителям задач и временным периодам.
  • Менеджер проекта бронирует ресурсы в соответствии с потребностью ресурсного плана.
  • Ресурсный менеджер совместно с менеджерами проектов на регулярной основе контролируют недопущения овербукинга и недостаточной загрузки ресурсов.

В целом менеджер проекта может вначале забронировать ресурсы под свой проект, а затем уже планировать работы. Жестких правил в последовательности планирования нет.

Пример использования

Рассмотрим пример компании 15–50 человек или аналогичного размеру отдельного продуктового подразделения компании (например, в компании есть отделы «Внедрение SAP», «Заказная разработка», «Управленческий консалтинг»). 

Такая компания представляет собой единый ресурсный пул – все ресурсы, необходимые для выполнения проектов, включая менеджеров проектов, работают в команде и находятся под управлением одного ресурсного менеджера. 

В такой структуре все знают своих коллег по проектам «в лицо» и им нужен инструмент для планирования, но не контроля. 

Обычная практика – менеджеры проектов, бронируя ресурсы под свои проекты, не особо смотрят на овербукинг. Раз в неделю руководитель отдела и менеджеры проектов собираются командой и смотрят план на следующую неделю. Если по какому-то ресурсу есть овербукинг – оперативно договариваются, какому проекту сейчас важнее отдать приоритет. Равно как если кто-то не загружен на 100% – решают, на каком проекте можно задействовать сотрудника, чтобы не снижать утилизацию. После актуализации бронирования менеджеры проектов самостоятельно корректируют свои ресурсные планы. 

Это рекомендуемый и самый эффективный подход.

Централизованное бронирование ресурсов

Общие сведения

В централизованной схеме бронирования ресурсов есть центральное звено — ресурсный менеджер (RM). Когда и если менеджеру проекта (PM) требуется забронировать ресурс на свой проект— он обращается к ресурсному менеджеру:

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

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

В централизованной схеме менеджеры проектов наполняют команду универсальными ресурсами, планируют проект, а далее запрашивают ресурсы у ресурсного менеджера. 

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

Как это работает

Общая логика процесса:

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

Важно понимать, что в процессе планирования есть две составляющие – выделение ресурса на проект и бронирование/актуализация емкости под проект. В централизованной схеме ресурсный менеджер однозначно определяет какой ресурс будет назначен на проект. Что касается актуализации брони есть два подхода – разрешить менеджерам проектом самостоятельно актуализовать календарь бронирования или разрешить эту операцию исключительно ресурсному менеджеру (жестко централизовать весь процесс). 

Жесткая централизация не рекомендуется, но если она все же требуется, то актуализация брони должна происходить через взаимодействие ресурсного менеджера и менеджера проекта (вне системы). Актуализация через запросы не рекомендуется в виду вариативности вариантов бронирования (редко когда удается забронировать ресурс ровно так, как просит менеджер проекта), простыми словами – проще созвонится и быстро решить, как актуализировать бронь, чем долго обмениваться запросами бронирования с разными вариантами.

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

Пример использования

Рассмотрим пример компании функциональной структурой отделов (например, «Консультанты», «Разработчики», «Проектный офис»).Каждый такой отдел – это отдельный ресурсный пул, со своим ресурсным менеджером. 

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

Далее происходит изменение плана проекта – например, с клиентом подписывается соглашение на расширение рамок проекта. 

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

Если у менеджера проекта нет прав на самостоятельно бронирование – он каким-любо образом обращается к ресурсному менеджеру и просит изменить бронь. В данном случае для упрощения взаимодействия лучше бронировать на больших масштабах, например «Требуется Иван Агафонов на 100 часов на август». А уже в рамках предоставленной емкости (которая может быть неравномерно распределена по месяцу) подстраивать ресурсный план проекта.