В прошлой статье я на примере кейса описал, какая проблема возникает в проекте для компании с функциональной организационной структурой при выделении ресурсов на внутренний проект.
В принципе, эта проблема характерна и для компаний с матричной структурой, но, возможно, не так ярко выражена. Компании с матричной структурой обычно уже имеют некоторые процедуры управления проектом, среди которых могут быть и те, которые описывают правила выделения времени сотрудников на проект. Но только наличие процедур не решает проблему – нужна система, о которой пойдет речь ниже.
Давайте рассмотрим, как можно снизить вероятность возникновения проблемы выделения ресурсов или уменьшить ее влияние на проект на примере нашего кейса с реализацией проекта подготовки корпоративного праздника.
Допустим, уже при обсуждении рамок проекта его руководитель заметил потенциальную проблему, связанную с выделением времени сотрудников на проект, и сформулировал ее в виде риска:
В случае частичной занятости сотрудников в проекте и одновременной их занятости в регулярной деятельности приоритет, скорее всего, будет отдаваться регулярной работе, а это поставит под угрозу своевременное выделение ресурсов на задачи проекта и приведет к необходимости постоянно переносить сроки реализации проекта.
На данном примере мы можем убедиться в том, что правильная формулировка риска иногда позволяет очень быстро найти решение для устранения причин его возникновения.
Напомню, что формулировать риск надо в виде конструкции: «Условие возникновения риска ведет к негативному последствию».
Обратим внимание на условие возникновения описанного риска: «В случае частичной занятости сотрудников в проекте и одновременной их занятости в регулярной деятельности…».
Как решить проблему в лоб? Почти уверен, вы уже догадались: нужно выделять сотрудников на работу в проекте не на часть их рабочего времени, а на полный рабочий день. То есть сотрудник на время выполнения своих работ в проекте должен заниматься только задачами проекта. Этот вариант хорош для проектов, в которых можно составить расписание работы для отдельного сотрудника так, что на некоторый период времени у него есть задачи, требующие загрузки по 8 часов в день. Выделять сотрудников на full-time (100% загрузка на задачах проекта) есть смысл далеко не всегда, т.к. модель проекта может быть построена так, что в какие-то периоды времени сотрудник будет простаивать или его загрузка составит менее 100%.
Давайте посмотрим, можно ли в нашем проекте по организации праздника кого-то из сотрудников выделить на 100% времени в проект. Обратимся к диаграмме Ганта и заметим, что самым явным кандидатом на 100% загрузку является руководитель проекта.
Именно у него наблюдается картина, когда одна задача тут же сменяется другой. Но сам руководитель проекта, будучи HR-директором компании, понимает, что не сможет на 2 месяца делегировать кому-то решение всех регулярных задач его подразделения. Поэтому уже при планировании сроков проекта он закладывал себе загрузку не более 50% от рабочего времени (т.е. 4 часа в день на проектные задачи). У юриста всего одна задача в проекте, но и его загрузку в проекте планировали с учетом того, что ему надо будет в течение выделенной на задачу недели решать параллельно оперативные задачи, выделив только 25% времени на проектную задачу. Про директора компании и говорить нечего – не сможет он заниматься только задачами проекта, разве только это будет единственный и самый важный проект для компании. И то вряд ли. Итак, в нашем случае ни один сотрудник не может работать со 100% загрузкой и фокусироваться только на задачах проекта.
Однако кроме наличия возможности уделять проекту 100% времени для организации такого режима работы (100% загрузка без простоев) в проекте должно выполняться еще как минимум одно условие.
Сформулирую это условие в виде гипотезы: для того, чтобы какой-то ресурс был загружен на 100% в определенный период времени, план проекта должен быть выстроен под его ритм работы. Но при этом организовать работы всех остальных ресурсов со 100% загрузкой становится очень непросто. И такой подход требует серьезного моделирования ресурсов, что может быть неоправданно дорого для некоторых проектов.
Итак, первый подход к решению проблемы для нашего кейса оказался не подходящим, хотя само решение пришло в голову очень быстро. И надо сказать, для других проектов это решение могло бы оказаться вполне жизнеспособным.
Давайте еще раз внимательно изучим условие возникновения риска. В формулировке риска есть еще одна часть, которую нам стоит проработать: «…приоритет, скорее всего, будет отдаваться регулярной работе».
Как можно изменить ситуацию таким образом, чтобы приоритет в случае конфликта за ресурс времени между проектом и регулярной деятельностью не отдавался автоматически в пользу последней, а определялся по каким-то правилам? Одна из альтернатив – это превращение руководителей подразделений в функциональной структуре в ресурсных менеджеров. Это значит, что задачи и регулярной, и проектной деятельности приходят руководителю подразделения для планирования сроков. Некоторые задачи уже могут иметь дедлайны, по некоторым руководитель подразделения может иметь право сам определить дедлайн, исходя из информации о приоритетах и доступности ресурсов.
Для того чтобы эта система выделения ресурсов заработала, нужно:
- Иметь работающую систему приоритетов по проектам и регулярным задачам. Грубо говоря, каждый ресурсный руководитель должен в он-лайн режиме видеть, как меняются приоритеты по задачам его подразделения. Кроме того, он должен иметь возможность моделировать загрузку всех своих сотрудников и в случае возникновения перегрузки, предлагать варианты переноса сроков по отдельным задачам.
- У ресурсного менеджера должна быть мотивация на выполнение наибольшего количества задач в срок – и проектных и регулярных. По сути, ему должно быть все равно – это задача из проекта или из регулярной деятельности, важно, что по ней есть приоритет, определен срок и нужно выполнить ее в плановый срок. Эффективность его работы измеряется таким показателем как «доля задач, выполненных его подразделением в плановый срок».
- Описав требования к системе выделения ресурсов, я заметил, что описал часть требований к системе Управления портфелем проектов компании.
Итак, второй вариант решения проблемы – это выстраивание системы Управления портфелями проектов (о том, что это такое я уже писал здесь). Одна из ключевых целей этой системы – это распределение ограниченных ресурсов компании между всеми стратегическими инициативами. Для внедрения Управления портфелями проектов компании надо:
- Спроектировать процессы управления портфелями.
- Доработать организационную структуру так, чтобы в ней появились ответственные за портфель. Наделить их властью и полномочиями.
- Автоматизировать управление портфелями проектов.
- Внедрить стандарты управления проектами и автоматизировать управление отдельным проектом.
- Внедрить роли ресурсных менеджеров.
Чтобы внедрить систему Управления портфелями проектов, нужно проделать серьезную работу, стоимость которой для небольшой компании пока еще слишком велика. Значит, и этот вариант решения проблемы выделения ресурсов для рассмотренной в кейсе компании – не лучший.
Итак, поработав с условием возникновения риска, я придумал 2 варианта снижения вероятности материализации этого условия. Оба рассмотренных варианта показались мне слишком трудоемкими и дорогими. Нужно еще поработать с последствием возникновения риска, которое мы сформулировали так: «а это приведет к необходимости постоянно переносить сроки реализации проекта».
Одна из стратегий работы с рисками (а именно активное принятие) предполагает закладывание резерва времени в проект на случай материализации риска. Для того чтобы из-за переноса сроков отдельных задач не переносить срок всего проекта, нужно заложить резерв времени в проект. С точки зрения руководителя проекта, чем больше резерв времени в расписании, тем выше вероятность того, что резерва хватит на выполнение проекта в срок.
Для нашего кейса создание резерва времени будет означать, что нам нужно стартовать проект раньше, чтобы успеть его сделать к установленному дедлайну.
Напомним, что дата проведения мероприятия установлена на 18 апреля, и расписание составлено так, что стартовать проект надо 10 февраля, и никакого резерва времени в проект добавить при текущем расписании невозможно. Добавление резерва к этому расписанию приведет к тому, что сместится плановая дата старта проекта, а это означает, что стартовать проект надо было раньше – до 10 февраля. Знакомая ситуация, не так ли? Когда в проекте начинаются проблемы со сроками, начинаешь думать, почему так поздно стартовали.
Название задачи | Длительность |
Трудо- |
Начало | Окончание |
День рождения компании | 50 дней | 110 ч | Вт 10.02.15 | Сб 18.04.15 |
Подготовка мероприятия | 49 дней | 110 ч | Вт 10.02.15 | Пт 17.04.15 |
Разработка и согласование концепции праздника | 5 дней | 10 ч | Вт 10.02.15 | Пн 16.02.15 |
Разработка и согласование подробной программы мероприятия | 5 дней | 20 ч | Вт 17.02.15 | Пн 23.02.15 |
Сбор информации о количестве участников | 1 нед | 2 ч | Вт 24.02.15 | Пн 02.03.15 |
Выбор подрядчиков | 1 нед | 20 ч | Вт 24.02.15 | Пн 02.03.15 |
Согласование условий с подрядчиками | 1 нед | 10 ч | Вт 03.03.15 | Пн 09.03.15 |
Определение бюджета праздника | 3 дней | 6 ч | Вт 10.03.15 | Чт 12.03.15 |
Заключение договоров с подрядчиками | 1 нед | 10 ч | Пт 13.03.15 | Чт 19.03.15 |
Выбор места проведения | 2 нед | 16 ч | Пт 13.03.15 | Чт 26.03.15 |
Контроль задач, выполняемых подрядчиками | 1 мес | 10 ч | Пт 20.03.15 | Чт 16.04.15 |
Оповещение сотрудников | 1 день | 1 ч | Пт 27.03.15 | Пт 27.03.15 |
Проверка финальной готовности мероприятия | 1 день | 5 ч | Пт 17.04.15 | Пт 17.04.15 |
Подготовка мероприятия завершена | 0 дней | 0 ч | Пт 17.04.15 | Пт 17.04.15 |
Проведение мероприятия | 1 день | 0 ч | Сб 18.04.15 | Сб 18.04.15 |
Итак, добавить резерв времени на снижение последствий материализации риска – это хороший вариант для рассмотренного кейса. Но в нашем кейсе сделать это не просто: расписание составлено так, что некуда добавить резерв времени.
Остается еще один вариант – изменить расписание так, чтобы сократить сроки реализации задач на критическом пути и сжать расписание. Это можно сделать, в частности, увеличив объем использования ресурсов. В начале статьи я писал о том, что руководитель проекта планировал свои задачи исходя из предположения, что он может на них тратить максимум 50% от имеющегося рабочего времени (то есть 4 часа в день при 8-часовом рабочем дне). А при планировании задачи, за которую в проекте отвечает юрист, предполагалось, что он будет работать 25% времени над задачей проекта.
Если руководителю проекта удастся согласовать с директором компании увеличение собственной загрузки и загрузки юриста на задачах проекта хотя бы до 60%, то после изменения плановой загрузки и пересчета сроков реализации задач мы увидим следующую картину по расписанию проекта:
Как видим, добавление ресурсов привело к сокращению сроков по большинству задач (веха «Подготовка мероприятия завершена» наступает 01.04, а не 17.04, как было первоначально), и это создало возможность ввести буфер времени в 13 рабочих дней.
Что изменилось в проекте? Сотрудникам выделили большую долю рабочего дня, чем было, на работу в проекте (трудозатраты задач при этом не изменились), и появился резерв времени для всего проекта. Для того чтобы сотрудники не попали в ловушку «студенческого синдрома», когда задача делается в последний момент времени перед ее дедлайном, о резерве времени в расписании лучше им не сообщать.
Создав буфер времени для проекта, мы не устранили саму проблему – сотрудники иногда будут выделять время на проектные задачи не так, как планировалось, и это приведет к нарушению сроков по их задачам. Но нарушение сроков будет компенсироваться заложенным резервом времени до тех пор, когда буфер времени не будет исчерпан.
Если говорить о решении проблемы выделения ресурсов в контексте нашего кейса, то мы нашли самое простое, но не системное решение проблемы – создать резерв времени по срокам. Этим приемом пользуются руководители проектов достаточно давно. Но если решать эту проблему на системном уровне, то руководству компании, во-первых, стоит продумать классификацию проектов, для которых лучше выделять сотрудников на 100% времени в проект, а во-вторых, стоит подумать о внедрении Системы управления портфелями проектов. На сегодняшний день внедрение Системы управления портфелями доступно только большим компаниям, в силу высокой стоимости решения, но через несколько лет с большой вероятностью появятся и методологии, и программные продукты для управления портфелями, которые станут доступны среднему и малому бизнесу.
Следите за трендами в управлении портфелями проектов!
И успехов вам в ваших проектах по улучшению бизнеса!