ГЛАВА 16

Пентабазис. КТО и ЧЕМ? Руководители и исполнители

Все хозяйственные операции можно в конечном счете свести к обозначению тремя словами: ЛЮДИ, ПРОДУКТЫ, ПРИБЫЛЬ. На первом месте стоят люди. Если у вас нет надежной команды, то из остальных факторов мало что удастся сделать.

Ли Якокка

Когда нам понятны заинтересованные стороны, можно поговорить и о ролях. Ведь на роли назначаются те, кто как-то в проекте заинтересован. И именно эти люди «правильно думают» о проекте.

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

Проектная роль — сочетание задач, полномочий и ответственности (ЗПО): что человек в этой роли делает (какие его функции), какие права у него есть и за что он отвечает в проекте.

ГОСТ говорит, что в оргструктуре проекта обязательны четыре роли.

• Куратор — лицо, ответственное за обеспечение проекта ресурсами и осуществляющее административную, финан­со­вую и иную поддержку. Эту роль еще называют Спонсор проекта.
• Заказчик — физическое или юридическое лицо, владелец результата проекта, соответственно, формулирующий требования к нему.
• Руководитель проекта — лицо, осуществляющее управление проектом и ответственное за результаты. Эту роль еще называют Лидером проекта.
• Команда проекта — совокупность лиц, групп и организаций, объединенных во вре́менную организационную структуру для выполнения работ по проекту.

Давайте сначала разберемся с ролями Заказчика и Куратора.

Проще всего с Заказчиком. Эта роль в первую очередь сосредоточена вокруг продукта проекта (ЧТО мы делаем) — он определяет требования к продукту, приоритеты требований; принимает созданный командой продукт и пускает его в жизнь дальше по цепочке решения проблемы. Важно не путать проектную и юридическую роли Заказчика (или Заказчика по договору). Последний — не обязательно Заказчик с точки зрения проектной роли. Он может быть и Куратором, и вообще формальным лицом, подписывающим договор. Заказчиком в проекте должен быть именно тот, кто формулирует требования к продукту!

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

Сложна роль Куратора (рис. 16.1). Ее часто недооценивают, а то и просто исключают из оргструктуры проекта. Это огромная ошибка!

Все исследования (и примыкающая к ним практика) показывают одно: без хорошего Куратора шансы на успех проекта минимальны. Особенно для российской действительности с авторитарным стилем управления. Именно поэтому мы с коллегами разработали специальную российскую модель компетенций для Куратора проекта.

Согласно определению, в этой модели Куратор проекта (Спонсор проекта, Project Sponsor) — определяемый на уровне организации руководитель высшего звена, который несет ответственность за успех с учетом интересов и выгод организации, обеспечивает необходимые условия и поддержку реализации проекта. Руководитель проекта часто не имеет достаточно широкого понимания ситуации в организации. Кроме того, его полномочия ограничены рамками проекта, он не может посмотреть на картину «с высоты», например для какой-то конкретной проблемы (рис. 16.2).

Куратор же понимает важность проекта для реализации стратегии организации в целом. Он видит всю цепочку решения проблемы.

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

Ключевые функции Куратора вокруг главных вопросов Пентабазиса таковы:

1. Целеполагание проекта. Именно Куратор определяет правильность ответов на вопросы, ЗАЧЕМ и ДЛЯ КОГО нужен проект, ЧТО мы хотим видеть в итоге. Детально на вопрос «ЧТО» отвечает Заказчик. Но высокоуровневое определение результатов и метрик — ответственность Куратора.

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

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

4. Обеспечение проекта ресурсами. Именно Куратор определяет, КТО будет руководителем проекта (главным управленческим ресурсом). Куратор на уровне организации договаривается, ЧЕМ нужно обеспечить проект.

5. Обеспечение системного управления проектом (project governance). Задача Куратора — помочь руководителю проекта создать эффективную систему управления; определить ее обязательные элементы с учетом предметной области, рисков, сложности проекта и требований внешних сторон. Мы поговорим об этом в отдельной главе. В целом чем слабее система управления проектом, чем меньше полномочий у его руководителя, тем чаще приходится подключаться Куратору (вплоть до перехода на «ручное управление»).

Однако важно понимать, что Куратор не должен подменять руководителя проекта и брать на себя его функции. В классическом подходе главная роль именно в управлении проектом — роль его руководителя. Он — мозговой центр проекта. К нему сходятся все нити управления. Он должен быть мотивирован достичь целей. Почему-то. Сложно сказать почему, но должен. Только тогда он сможет протолкнуть проект. Я люблю говорить, что у проекта есть одно большое ЗАЧЕМ и много маленьких «зачемчиков». У каждого стейкхолдера должен быть свой «зачемчик» на участие в проекте. А у руководителя (лидера) — особенно большой. Серьезный такой «зачемчик».

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

К сожалению, часто в крупных иерархических организациях не получается наделить руководителя проекта необходимыми полномочиями. Среда сопротивляется, не дает рулить. А у Куратора нет времени, чтобы погружаться в проект. Тогда вводят специальную роль — Единое ответственное лицо (ЕОЛ), или Директор проекта. Человек, который в рамках иерархии компании отвечает за то, чтобы результаты были получены, и управляет проектом (рис. 16.4).

Чаще всего он не может выделить достаточно времени, и для работ по оперативному управлению (планированию, организации и контролю деятельности проектной команды, подготовке документов, отчетов и так далее) на проект назначается руководитель. Фактически он становится заместителем ЕОЛ и осуществляет оперативное, ежедневное руководство. При этом на ЕОЛ остается ответственность за получение финальных результатов. Когда отдельный сотрудник на роль руководителя проекта не выделяется, эта роль выполняется ЕОЛ.

Если проект затрагивает несколько подразделений организации, то создаются специальные органы:

• на стратегическом уровне — орган, включающий топ-менеджеров (Управляющий комитет или Управляющий совет);
• на оперативном уровне — орган, включающий мидл-менеджеров (Оперативный совет).

Роли, которые мы разобрали выше, часто называют ЛПР (лица, принимающие решения). Но кроме них, есть и команда. Это люди, которые работу работают, те, кто непосредственно выполняет работы по проекту. И в команде часто также вводятся дополнительные роли: например, главный инженер проекта, архитектор, планировщик, риск-менеджер, координатор и так далее.

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

Бывают роли очень интересные. В казахской компании BI Group, которая занимается строительством жилых комплексов, есть очень занятная роль — «менеджер счастья». Отдел продаж оформляет продажу жилья клиенту, отдел по работе с клиентами производит передачу ключей. Между двумя этими этапами остается промежуток времени, когда клиент не знает, к кому обратиться по важным вопросам. В этот-то момент и приходит на помощь менеджер счастья — информирует, отвечает на вопросы по деталям проекта, срокам сдачи, изменениям, стадиям строительства. В общем, курирует аспект «взаимодействие с покупателем квартиры».

Вообще, в команде очень важно правильное распределение ответственности. В идеальном мире происходит так.

1. Вы спланировали работу.
2. Детально прописали каждому члену команды, что и как он делает.
3. Все пошли работать свою работу.

В реальности план часто бывает недостаточно подробный: не охватывает все аспекты и меняется. А еще на старте так много неопределенности, что детально планировать невозможно. Поэтому часто руководитель проекта поступает проще: назначает кого-то ответственным за определенный аспект, направление или блок работ. Здесь главное, чтобы всем было понятно, кто за что отвечает, и не осталось мест в плане, за которые не отвечает никто.

Для проекта открытия филиала «Кварка» я бы выстроил следующую структуру управления.

• Куратор — генеральный директор.
• Заказчик — административный директор.
• РП — разумеется, Вы.
• Учитывая, что компания в первый раз делает такой проект и возможны конфликты, вам может не хватать полномочий. Так что очень стоит создать Операционный совет проекта, включающий мидл-менеджмент вовлеченных подразделений. Стоит ввести роль эксперта и пригласить на нее советника директора, у которого есть опыт реализации таких проектов и который сможет помогать на сложных заседаниях Операционного совета.
• Члены команды — сотрудники, назначенные приказом по компании из различных подразделений.

 

Команда — это человеческие ресурсы. Причем не все люди будут прямо входить в команду проекта. Например, привлекаемые на отдельные задачи внешние эксперты будут считаться трудовыми ресурсами, но в команду не войдут. Аналогично — сотрудники по договору или волонтеры. Для проектов по организации мероприятий волонтеров привлекают очень часто. Это могут быть как школьники / студенты для навигации на площадке, формирования пакета документов, внесения данных или привлечения к простым задачам, так и «серьезные» люди с «серьезными» задачами. Например, как на Олимпиаде или чемпионате мира по футболу — привлечение к организации благотворительных акций и так далее.

И чтобы это как-то разделять, часто выделяют основную команду проекта (core team) и расширенную команду, или рабочую группу (extended team). С основной командой проекта надо много и плотно работать. Вообще, если команда становится больше 7–9 человек (дальше мы будем разбирать «магическое» число 7 ± 2), то надо разбивать ее на подкоманды, назначая руководителей команд (в IT их называют тимлидерами или тимлидами).

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

Вообще, вся специфика трудовых ресурсов хорошо передается калькой с английского — человеческие ресурсы (human resources). Фишка в том, что они, с одной стороны, ресурсы, а с другой — люди-человеки. И, управляя ими как ресурсами, необходимо не забывать, что они люди. А с другой стороны — взаимодействуя с ними как с людьми, нельзя забывать, что они проектные ресурсы. В общем, все сложно…

Кроме человеческих ресурсов, есть и другие. Базово выделяют следующие виды ресурсов:

• трудовые (необходимые члены команды, сотрудники других подразделений, физические и юридические лица, волонтеры);
• материальные (помещение, оснащение, транспорт и так далее), технические (IT-решения), коммунальные (электричество / водоснабжение) и так далее;
• информационные (собственные информационные ресурсы, базы знаний, IT-системы);
• финансовые (инвестиции, деньги, пожертвования и так далее);
• также к ресурсам относятся и социальные: контакты, связи, полномочия. Есть даже такое вполне установившееся понятие «административный ресурс».

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

Для оценки необходимого объема ресурсов целесообразно привлекать экспертов. Для наглядности приведу бытовой пример — мини-проект «Пикник в лесу»: золотая осень, солнце, компания друзей, дикая природа, долго шли в безлюдное место, все в предвкушении шашлыка, а зажигалки нет, и все ЗОЖ — никто не курит. Но вы команда оптимистов — есть бутылка виноградного сока! Однако и здесь все плохо — штопора тоже нет… В ход, конечно, идет креатив, но результаты часто вызывают грусть. Так что «эксперт по пикникам» легко бы вас предостерег от подобных ресурсных ошибок.

Если объем привлекаемых ресурсов в проекте невелик, то можно обойтись просто списком, подготовленным вместе с экспертом. Если же ресурсов требуется много и в разные периоды, то придется готовить план, в котором будут отражены виды ресурсов, источники, загрузка в проекте. Подготовка такого документа начинается с разработки иерархической структуры ресурсов (Resource Breakdown Structure). Это дерево всех ресурсов, доступных для использования в проекте, с указанием их типа. Потом по каждому виду ресурсов проводится оценка через привлечение экспертов, анализ рынков и сравнение поставщиков. Проработка основных ресурсов позволит собрать необходимые данные для формирования максимально приближенного к реальности бюджета расходов по проекту с учетом всех резервов и альтернатив. Ресурсы — это обычно то, что больше всего влияет на бюджет.

В целом в РИМ-III. Миниморум, который предназначен для небольших проектов, я исхожу из того, что ресурсы будут выделены в начале проекта и сложного планирования по ним не понадобится. Если же это не так, то при выполнении проекта это нужно будет выделить как отдельный аспект (см. ).

Отправить