Место команды в проектной организации
Содержание
Сущность проектов предполагает коллективную работу над его реализацией. Группа людей объединяется во временной структуре, каждый член которой принимает на себя ответственность за конкретные результаты. Но не каждое объединение ответственных ресурсов задач становится командой. И далеко не все участники проекта входят в ее состав. Что же представляет собой по составу и численности команда проекта, как она связана с другими субъектами управления?
Динамика развития проектных событий
Следует понимать, почему не все участники проекта действуют как сплоченная команда проекта, объединяя усилия в групповом решении задачи. Несмотря на единство интересов в команде, важно, чтобы ни один исполнитель не растерял индивидуальной ответственности за вверенный участок работ. В интересах проекта есть потребность в независимости отдельных участников от других. Часто в том, чтобы включать определенные роли и функции в циклы коллегиальных взаимодействий, нет необходимости. Одновременно с этим, команда – это достаточно эффективная и компактная проектная группа.
Ранее мы рассматривали упрощенную модель взаимоотношений стейкхолдеров проекта от зарождения идеи до непосредственной реализации уникальной задачи развития. Модель демонстрирует, какие проектные группы возникают на этапах инициации и планирования. Допустим, в предпроектной фазе уже кое-что выполнено. Идея принята, бизнес-план или бизнес-кейс рассмотрен, заказчик проекта установлен. Решение, что реализация необходима, принято.
Определено, кто будет отвечать за результат, хотя команда проекта еще не сформирована. Назначен куратор и выбран кандидат на PМ. Данный дуэт, реализуя свои функции, приступает к действиям. Между ними устанавливается особый формат взаимоотношений. Роли в проекте к настоящему моменту удается поделить, и общее понимание как-то начинает обозначаться, в том числе благодаря совместной работе над уставом проекта.
На представленной ниже схеме поступательно изображены шесть этапов схемы стартовых взаимодействий. На ней представлены все возможные участники проекта. Куратор для себя и кандидата на PM уточняет цели проекта. Кроме того, менеджер к моменту окончания шестого шага должен уяснить три непростых момента: содержание, ограничения и риски решения рассматриваемой задачи. Еще он должен осознать, каковы его мотивация и полномочия. В данный момент можно считать, что постановочная фаза задачи развития бизнеса завершена.
Наступает время, когда будущий руководитель проекта достаточно приближен к тому, чтобы принять ответственность за конечный результат на себя. Но готов пока не полностью. Предположим, что черновой вариант устава выполнен как некий аналог договора между куратором или, вернее, заказчиком, и менеджером. Тем не менее, еще нет видения этапов проекта хотя бы на уровне вех. Далеко не все участники проекта определены. Тут-то и начинаются все метаморфозы коллективной подготовки к стадии реализации. Последовательно в выполнение своих миссий вступают специальные группы участников.
Вырастание команды из проектных групп
Вернемся к модели взаимодействия в проектной деятельности и разберем ее локальную часть после описанных выше стартовых шагов. Проектная задача считается принятой PM тогда, когда основные разделы устава проработаны, и он подписан сторонами. Этим самым менеджер принимает на себя ответственность, после чего она начинает его беспокоить. Подписанную ответственность ему необходимо разбить и каким-то образом перенести, распределить. Должна появиться команда проекта.
Команда проекта состоит из исполнителей, а ее возглавляет PM. Эта проектная группа работает на протяжении всей проектной реализации. Исполнители должны понимать только свои задачи, общую картину им видеть необязательно. Исполнители делятся на внешних и на внутренних. Внешние производители работ привлекаются по договору подряда, и с ними работать проще в силу большей формальности отношений. В любом случае, каждому исполнителю нужно правильно поставить задачу. А такое сделать невозможно, пока не будет детально разработанного плана.
В данный момент PM попадает в неудобную ситуацию с силу того, что у него не хватает компетентности в некоторых работах, которые нужно будет выполнять. Знать буквально все характеристики, все технические, технологические аспекты, процедурные моменты достижения требуемых решений не входит в его функции. Другими словами, менеджер не готов взять на себя ответственность за оценку отдельных работ (например, в сфере программирования).
Получается, что PM нужно найти экспертов в узких областях, которые способны оказать содействие на этапе планирования, а потом будут помогать на этапе реализации. Сначала руководитель проекта собирает так называемую «рабочую группу». Эта проектная группа помимо него состоит из группы экспертов, специалистов, на которых PM может положиться, и без которых он не способен грамотно спланировать проект.
Потенциально в роли экспертов могут выступить и непосредственно исполнители. В данном случае менеджеру следует быть осторожным, потому что они могут предоставить не совсем корректную и достоверную информацию. На уровне ТЗ коллеги или подрядчики способны предложить не то, что нужно, а то, что выгодней продать исполнителям (внешним или внутренним). Важен вопрос доверия, существенны характеристики исполнителей.
Затем рабочая группа трансформируется в команду управления проектом. К наступившему моменту уже несколько иная проектная группа по существу представляет собой ядро команды, которому PM доверяет и на них полагается. Она состоит из специалистов в конкретных отраслевых, управленческих областях. Поэтому такая группа называется командой управления проектом (КУП), состоящей из непосредственных помощников менеджера. С ними он советуется, на них он возлагает какую-то ответственность и передает определенные полномочия.
Названные выше группы являются основанием для формирования команды проекта. Получается, что команда включает более широкое окружение, чем КУП. Кроме доверенного ядра в эту группу входят еще и исполнители. С исполнителями РМ, как правило, выстраивает более простые взаимоотношения. То есть с ними обычно менеджер не советуется, нужно эту работу делать или не нужно. Руководитель с ними обсуждает вопрос о принятии ответственности за локальные задачи. Его интересует, на каких условиях последние готовы «взяться». Алгоритм прост: обсудить, договориться, заключить соглашение (договор), выполнить, сдать, принять. Таковы основные аспекты взаимоотношений с ответственными ресурсами по локальным результатам.
Учет характеристик и функций исполнителей
Проектная группа, ставшая командой, определяет силу реализации задачи развития компании. Данный коллективный элемент системы управления опирается на личностную силу и ответственность каждого участника-исполнителя. Когда проектная команда собрана воедино, прошло первое рабочее совещание, можно с уверенностью говорить, что состав участников проекта сформирован полностью.
Руководителю проекта нужно быть точным с выбором в члены команды в каждом из случаев рассмотрения кандидатов. Для этого в момент определения состава команды ему важно учесть основные характеристики подбираемых людей, исходя из диагностических установок. Вашему вниманию предлагается один из примеров таких вопросов-установок.
- Однозначны ли формулировки задач, которые следует предложить потенциальным исполнителям?
- Какие роли потребуется установить в команде, чтобы все задачи и мероприятия получили по ответственному ресурсу?
- Какими навыками и опытом должен владеть участник-претендент?
- Какие функции и задачи допустимо предложить претенденту при включении в команду?
- Какие основные черты характера, психотип и ценностные ориентации исполнителей являются предпочтительными?
- Какую загруженность и бюджет времени можно предположить для участия исполнителя?
- Достаточно ли число кандидатов на исполнение задач для обеспечения минимального уровня конкурентной среды между потенциальными участниками группы?
Представленные характеристики отталкиваются от специальной методический позиции. В ней предполагается, что дефицит ответственных ресурсов под декомпозированные задачи проекта является заблуждением. Человеческие ресурсы, способные стать участниками команды, потенциально всегда есть как внутри компании, так и за ее пределами. Поэтому, соблюдая задачную и проектную методологию, PM всегда имеет возможность созвать оптимальные по составу группы участников для успешной работы.
Помимо задач, каждому из участников команды придаются функции, обязательные к исполнению в периоды коллективных действий. Например, проектные совещания, регулярно проводимые для отчетно-аналитической работы, выработки оперативных решений требуют исполнения ряда административных действий. Секретарские операции являются обязанностью любого члена команды, назначенного РМ. Планирование и отчетность по проекту также является функциональной обязанностью каждого участника. Учет действительных функциональных навыков кандидатов в команду является прерогативой менеджера в момент ее созыва.
В настоящей статье мы рассмотрели багаж результатов, наработанных куратором и PM при работе над уставом. Последовательно возникают: проектные группы в форме рабочей группы, команды управления проектом и команды проекта. Задачный контекст ответственности PM обременяет обязанностью передать ее на плечи исполнителей, что является мощным управленческим навыком. Менеджер проекта, осознавший важность и освоивший на практике такую способность, несомненно, становится успешным руководителем.