Тайм-менеджмент руководителя проектов: пять мощных инструментов

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

1. Возьмите себе администратора проектов

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

• Подготовка документов (бюрократии в проектах немало, и полезной, и не очень), ведение архива документов в сетевой папке проекта.
• Планирование активностей.
• Отслеживание статусов, подготовка отчетности.
• Планирование и проведение рабочих групп и других периодических совещаний в рамках проектов, подготовка протоколов.
• Осуществление различных коммуникаций с участниками проектов.

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

Есть, конечно, и минусы этого подхода, главные из которых:

• Возможное снижение качества управления проектом.
• Дополнительные расходы на ФОТ.

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

Сделать это достаточно просто. Подойдем к задаче математически: пусть стоимость руководителя проекта составляет 100 рублей в месяц при условии 40-часовой рабочей недели. Возьмем один проект, объем которого требует работы на фултайм (то есть с полной загрузкой 40 часов в неделю). Итого, для заказчика стоимость управления данным проектом будет 100 рублей в месяц.

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

Теперь, даже если руководитель проекта делегирует администратору около 60% своих работ, он сможет одновременно вести два подобных проекта с той же эффективностью (конечно, зависимость нелинейная – необходимо учесть время на переключение между проектами). Считаем: (100 + 30) / 2 = 65 рублей в месяц – стоимость управления проектом для заказчика значительно снизилась даже при предположении, что руководитель проекта сможет вести два проекта вместо одного.

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

2. Запланируйте периодические совещания на все время проекта

Разумеется, если вы выполнили первый пункт, поручите это вашему администратору! Редко когда у руководителя проектов в управлении всего один проект – обычно их больше. Одному project-менеджеру рекомендуется вести не больше пяти проектов одновременно (встречаются, конечно, смешные случаи, когда мне так называемый «руководитель проектов» заявлял, что прямо сейчас ведет «примерно 150-200 проектов», но мы понимаем, что данные активности не могут являться проектами). Человек достаточно много времени тратит на переключения между различными задачами – и руководитель проектов точно так же неэффективно расходует время, переключаясь между различными проектами, даже если они одной направленности. Даже в практически идентичных с предметной точки зрения проектах может быть разная команда – а коммуникации занимают значительную часть управления любым проектом.

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

И приучите команды всех проектов к этому расписанию. Проще всего это сделать созданием периодических рабочих групп и других совещаний в рамках проектов, запланировав в календаре периодическую встречу на время всего проекта. Старайтесь не переносить отчетные совещания, и команда быстро привыкнет к такому распорядку. Разумеется, не следует доводить эту схему до абсурда, прогоняя явившегося в среду архитектора проекта с важным запросом на изменение со словами: «Что пришел? Твой день – понедельник!».

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

3. Вовремя эскалируйте возникшие проблемы в соответствии со схемой эскалации

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

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

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

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

4. Используйте процесс управления изменениями

Немалое количество времени в любом проекте отнимают изменения. Казалось бы, спланировал все работы на год вперед – ан нет, то у заказчика возникают новые «хотелки», то эксперты придумывают какие-то невероятные решения, которые требуют значительных изменений. И времени иногда на работу (или борьбу) с изменениями уходит просто невероятное количество.

С самими изменениями бороться не нужно – это нормальный и в общем-то неизбежный процесс. А вот как работать с этими изменениями – решать вам.

Чем хорош утвержденный процесс работы с изменениями с помощью «запросов на изменение» (в PMBOK CR – Change Request)? Всем! Во-первых, значительное количество «пожеланий» от экспертов и исполнителей проекта отваливается на самой ранней стадии. Узнав, что для внесения изменения необходимо заполнить «Запрос на изменение» (документ формата А4 на одной стороне), 90% изменений внезапно оказываются не так и нужны. Разумеется, действительно нужные изменения (оставшиеся 10%) вы должны оформить и даже заполнить за члена команды проекта этот CR. Но, как показывает практика, обычно таких предложений «снизу» не так много.

Другое дело – изменения, приходящие «сверху», от заказчика! Поток пожеланий от заказчика во время всего проекта может быть достаточно обильным, даже на стадии завершения проекта. Однако способ работы с этими изменениями – точно такой же. На любую «хотелку» необходимо оформить CR. Конечно, сам заказчик никакие запросы оформлять не будет – вы с удовольствием возьмете эту работу на себя. Почему «с удовольствием»? По той причине, что изложенные в формате «Запроса на изменение» большая часть пожеланий заказчика им же самим будет решительно отвергнута, и вы сэкономите время, не проводя данное изменение в рамках проекта.

Поясню, как это работает, на примере. Заказчик пожелал, чтобы забор был выкрашен зеленой краской вместо серой. Смело вносите в CR работу: «Покрасить забор объекта зеленой краской вместо серой». Однако на этом заполнение «Запроса на изменение» не заканчивается! Вам необходимо указать, что повлечет за собой данное изменение. Объем проекта изменится незначительно – всего-то краска другого цвета. Однако, как вы успели уточнить, зеленая краска чуть дороже серой (собственно, поэтому серую и выбирали на старте проекта, чтобы уложиться в бюджет), поэтому данное изменение влечет увеличение бюджета проекта на 100 тыс. руб. И это еще не все! Краска итальянская, срок поставки три месяца на условиях предоплаты. Поэтому, во-первых, серую уже заказали и оплатили, что влечет за собой потери еще 400 тыс. руб., во-вторых, срок завершения проекта сдвинется на два месяца, так как поставка краски находится в план-графике на критическом пути. Кроме того, придется заново согласовывать фасад, это еще сдвинет начало работ по покраске, а потом наступит зима и покраску придется отложить до весны...

И вот уже из «Запроса на изменение» очевидно, что изменение цвета краски выливается в несколько миллионов рублей превышения бюджета и на полгода увеличивает срок проекта. В момент, когда вы приносите заказчику на подпись такой CR, заказчик задумчиво произносит: «Не думал, что все так сложно...», и мудро ставит на CR резолюцию «Изменение не согласовано». Таким образом, вы в любом случае оказываетесь в плюсе: если заказчик не согласовал свое же изменение, вы не потратите дополнительное время на реализацию этого изменения, если же оно было одобрено – вы получаете дополнительные ресурсы, указанные в CR, для его реализации.

5. Избавьтесь от перфекционизма

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

Если руководитель проекта возьмет на вооружение эти простые инструменты, эффективность управления временем в рамках управления проектами значительно повысится.