Варианты решения проблемы с выделением ресурсов на проект

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

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

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

Допустим, уже при обсуждении рамок проекта его руководитель заметил потенциальную проблему, связанную с выделением времени сотрудников на проект, и сформулировал ее в виде риска:

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

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

Напомню, что формулировать риск надо в виде конструкции: «Условие возникновения риска ведет к негативному последствию».

Обратим внимание на условие возникновения описанного риска: «В случае частичной занятости сотрудников в проекте и одновременной их занятости в регулярной деятельности…».

Как решить проблему в лоб? Почти уверен, вы уже догадались: нужно выделять сотрудников на работу в проекте не на часть их рабочего времени, а на полный рабочий день. То есть сотрудник на время выполнения своих работ в проекте должен заниматься только задачами проекта. Этот вариант хорош для проектов, в которых можно составить расписание работы для отдельного сотрудника так, что на некоторый период времени у него есть задачи, требующие загрузки по 8 часов в день. Выделять сотрудников на full-time (100% загрузка на задачах проекта) есть смысл далеко не всегда, т.к. модель проекта может быть построена так, что в какие-то периоды времени сотрудник будет простаивать или его загрузка составит менее 100%.

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

Именно у него наблюдается картина, когда одна задача тут же сменяется другой. Но сам руководитель проекта, будучи HR-директором компании, понимает, что не сможет на 2 месяца делегировать кому-то решение всех регулярных задач его подразделения. Поэтому уже при планировании сроков проекта он закладывал себе загрузку не более 50% от рабочего времени (т.е. 4 часа в день на проектные задачи). У юриста всего одна задача в проекте, но и его загрузку в проекте планировали с учетом того, что ему надо будет в течение выделенной на задачу недели решать параллельно оперативные задачи, выделив только 25% времени на проектную задачу. Про директора компании и говорить нечего – не сможет он заниматься только задачами проекта, разве только это будет единственный и самый важный проект для компании. И то вряд ли. Итак, в нашем случае ни один сотрудник не может работать со 100% загрузкой и фокусироваться только на задачах проекта.

Однако кроме наличия возможности уделять проекту 100% времени для организации такого режима работы (100% загрузка без простоев) в проекте должно выполняться еще как минимум одно условие.

Сформулирую это условие в виде гипотезы: для того, чтобы какой-то ресурс был загружен на 100% в определенный период времени, план проекта должен быть выстроен под его ритм работы. Но при этом организовать работы всех остальных ресурсов со 100% загрузкой становится очень непросто. И такой подход требует серьезного моделирования ресурсов, что может быть неоправданно дорого для некоторых проектов.

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

Давайте еще раз внимательно изучим условие возникновения риска. В формулировке риска есть еще одна часть, которую нам стоит проработать: «…приоритет, скорее всего, будет отдаваться регулярной работе».

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

Для того чтобы эта система выделения ресурсов заработала, нужно:

1. Иметь работающую систему приоритетов по проектам и регулярным задачам. Грубо говоря, каждый ресурсный руководитель должен в он-лайн режиме видеть, как меняются приоритеты по задачам его подразделения. Кроме того, он должен иметь возможность моделировать загрузку всех своих сотрудников и в случае возникновения перегрузки, предлагать варианты переноса сроков по отдельным задачам.
2. У ресурсного менеджера должна быть мотивация на выполнение наибольшего количества задач в срок – и проектных и регулярных. По сути, ему должно быть все равно – это задача из проекта или из регулярной деятельности, важно, что по ней есть приоритет, определен срок и нужно выполнить ее в плановый срок. Эффективность его работы измеряется таким показателем как «доля задач, выполненных его подразделением в плановый срок».
3. Описав требования к системе выделения ресурсов, я заметил, что описал часть требований к системе Управления портфелем проектов компании.

Итак, второй вариант решения проблемы – это выстраивание системы Управления портфелями проектов (о том, что это такое я уже писал здесь). Одна из ключевых целей этой системы – это распределение ограниченных ресурсов компании между всеми стратегическими инициативами. Для внедрения Управления портфелями проектов компании надо:

1. Спроектировать процессы управления портфелями.
2. Доработать организационную структуру так, чтобы в ней появились ответственные за портфель. Наделить их властью и полномочиями.
3. Автоматизировать управление портфелями проектов.
4. Внедрить стандарты управления проектами и автоматизировать управление отдельным проектом.
5. Внедрить роли ресурсных менеджеров.

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

Итак, поработав с условием возникновения риска, я придумал 2 варианта снижения вероятности материализации этого условия. Оба рассмотренных варианта показались мне слишком трудоемкими и дорогими. Нужно еще поработать с последствием возникновения риска, которое мы сформулировали так: «а это приведет к необходимости постоянно переносить сроки реализации проекта».

Одна из стратегий работы с рисками (а именно активное принятие) предполагает закладывание резерва времени в проект на случай материализации риска. Для того чтобы из-за переноса сроков отдельных задач не переносить срок всего проекта, нужно заложить резерв времени в проект. С точки зрения руководителя проекта, чем больше резерв времени в расписании, тем выше вероятность того, что резерва хватит на выполнение проекта в срок.

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

Напомним, что дата проведения мероприятия установлена на 18 апреля, и расписание составлено так, что стартовать проект надо 10 февраля, и никакого резерва времени в проект добавить при текущем расписании невозможно. Добавление резерва к этому расписанию приведет к тому, что сместится плановая дата старта проекта, а это означает, что стартовать проект надо было раньше – до 10 февраля. Знакомая ситуация, не так ли? Когда в проекте начинаются проблемы со сроками, начинаешь думать, почему так поздно стартовали.

Итак, добавить резерв времени на снижение последствий материализации риска – это хороший вариант для рассмотренного кейса. Но в нашем кейсе сделать это не просто: расписание составлено так, что некуда добавить резерв времени.

Остается еще один вариант – изменить расписание так, чтобы сократить сроки реализации задач на критическом пути и сжать расписание. Это можно сделать, в частности, увеличив объем использования ресурсов. В начале статьи я писал о том, что руководитель проекта планировал свои задачи исходя из предположения, что он может на них тратить максимум 50% от имеющегося рабочего времени (то есть 4 часа в день при 8-часовом рабочем дне). А при планировании задачи, за которую в проекте отвечает юрист, предполагалось, что он будет работать 25% времени над задачей проекта.

Если руководителю проекта удастся согласовать с директором компании увеличение собственной загрузки и загрузки юриста на задачах проекта хотя бы до 60%, то после изменения плановой загрузки и пересчета сроков реализации задач мы увидим следующую картину по расписанию проекта:

Как видим, добавление ресурсов привело к сокращению сроков по большинству задач (веха «Подготовка мероприятия завершена» наступает 01.04, а не 17.04, как было первоначально), и это создало возможность ввести буфер времени в 13 рабочих дней.

Что изменилось в проекте? Сотрудникам выделили большую долю рабочего дня, чем было, на работу в проекте (трудозатраты задач при этом не изменились), и появился резерв времени для всего проекта. Для того чтобы сотрудники не попали в ловушку «студенческого синдрома», когда задача делается в последний момент времени перед ее дедлайном, о резерве времени в расписании лучше им не сообщать.

Создав буфер времени для проекта, мы не устранили саму проблему – сотрудники иногда будут выделять время на проектные задачи не так, как планировалось, и это приведет к нарушению сроков по их задачам. Но нарушение сроков будет компенсироваться заложенным резервом времени до тех пор, когда буфер времени не будет исчерпан.

Если говорить о решении проблемы выделения ресурсов в контексте нашего кейса, то мы нашли самое простое, но не системное решение проблемы – создать резерв времени по срокам. Этим приемом пользуются руководители проектов достаточно давно. Но если решать эту проблему на системном уровне, то руководству компании, во-первых, стоит продумать классификацию проектов, для которых лучше выделять сотрудников на 100% времени в проект, а во-вторых, стоит подумать о внедрении Системы управления портфелями проектов. На сегодняшний день внедрение Системы управления портфелями доступно только большим компаниям, в силу высокой стоимости решения, но через несколько лет с большой вероятностью появятся и методологии, и программные продукты для управления портфелями, которые станут доступны среднему и малому бизнесу.

Следите за трендами в управлении портфелями проектов!

И успехов вам в ваших проектах по улучшению бизнеса!

• Добавить комментарий

Войти как