какие роли есть в проектной деятельности

Команда проекта и роли ее участников

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

Чем больше масштаб проекта, тем большее количество организаций (заинтересованных сторон) участвует в его реализации. У каждой роли в проекте свои функции, степень участия и мера ответственности. Главная задача руководителя проекта — собрать профессионалов и организовать их правильное взаимодействие.

Как говорил Уолт Дисней: «Из всего, что я делал в жизни, самым важным я считаю управление талантливыми людьми, которые работали на нас, направление их к нужной цели».

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

Роли в команде проекта

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

Состав команды зависит от вида проекта и его организационной структуры. Например, IT проект предполагает обязательное наличие проектировщика и тестировщика, а культурный проект — дизайнера-консультанта.

Организационные структуры проектных команд

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

Функциональное подчинение участников проектной команды представлено на рисунке.

Организационная структура команды проекта

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

Условия эффективной работы команды проекта

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

«Никто не может в одиночку сыграть симфонию. Для этого нужен целый оркестр» —H.E. Luccock, профессор теологии

Таким образом, основная задача руководителя на этапе формирования команды — не только найти хороших экспертов и объединить их, но и создать вышеперечисленные условия их работы, обеспечивающие эффективную реализацию проекта.

Источник

Участники проектов

Участники проекта – физические и\или юридические лица, которые непосредственно вовлечены в реализацию проекта, либо чьи интересы могут быть затронуты при осуществлении проекта.

По степени вовлеченности в проект можно выделить три группы участников:

Как правило, основными участниками проекта являются:

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

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

Спонсор проекта назначает менеджера проекта и обеспечивает ему необходимую поддержку.

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

Руководитель проекта обеспечивает ежедневное управление проектом, командой проекта, в разрезе всех основных управленческих функций (управление по срокам, затратам, рискам и др.). В зависимости от размера проекта, менеджер проекта может получать поддержку со стороны администратора проекта, или команды поддержки (офиса проекта).

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

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

Субконтрактор – вступает в договорные отношения с контрактором или субконтрактором более высокого уровня. Несет ответственность за выполнение работ и услуг в соответствии с контрактом.

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

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

Менеджер проекта – ключевая фигура в управлении проектом

Ответственность и состав полномочий менеджера проекта определяется контрактом с Заказчиком и/или уставом проекта (для внутренних проектов).

Руководитель проекта обычно выполняет следующие функции:

Менеджер проекта должен понимать и уметь анализировать интересы ключевых участников и особенности окружения проекта.

Команда проекта и команда управления проектом

Для достижения целей проекта менеджер создает специальные организационные структуры: команду проекта и команду управления проектом. Успех всего проекта во многом зависит от эффективности функционирования данных организационных структур.

Команда проекта – временная организационная структура, объединяющая отдельных специалистов, группы и/или организации, привлеченные к выполнению работ проекта и ответственные перед руководителем проекта за их выполнение.

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

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

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

Необходимо, чтобы каждый сотрудник, работающий на проекте, имел четко определенные:

Проектный офис

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

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

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

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

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

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

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

так и непосредственно реализовывать управленческие функции, включая:

Источник

Роли на типовом проекте

Разбирая проектные роли, надо четко отделять их от самого человека: сотрудник может выступать сразу в нескольких ипостасях, а также участвовать в одной разработке в роли А, а в другой — в роли Б. Совершая любое действие в работе, надо понимать от чьего имени это происходит.

Список ролей

Менеджер проекта, PM

Создает и поддерживает план проекта, отвечает за его выполнение.

KPI — маржинальность проекта.

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

Отвечает за написание и поддержание в актуальном состоянии требований.

Носитель эзотерических знаний и главный коммуникатор между командой и клиентом в части сути проекта.

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

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

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

KPI — соответствие системы нефункциональным (нагрузочным) требованиям, легкость ее расширения и развития, отсутствие проблем при интеграции.

Ведущий разработчик, Тимлид

На малом проекте (нет выделенного архитектора) ведущий разработчик отвечает за все задачи по разработке.

Собственно разрабатывает код проекта.

KPI — нулевое количество ошибок в коде.

Планирует работы по тестированию.

KPI — нулевое количество репортов об ошибках от клиента.

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

Системный администратор / сотрудник DevOps

Должен быть способен без программистов развернуть систему.

KPI — попадание в план по задачам разворачивания системы.

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

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

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

KPI аккаунта — рост оборота контрактов по его клиенту и общая маржинальность. В силу этого аккаунт может принимать решения о перебалансировке объема работ между несколькими проектами для одного клиента.

Начальник отдела разработки/аналитики

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

Директор, Генеральный директор, Директор группы компаний, Президент и Заместитель Бога на Земле.

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

Типовые совмещения ролей

Компания Digital Zone разработала и произвела опытные образцы системы «Умный дом». …

Источник

Роли в проекте

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

Начнем с того, что в различных методологиях управления проектами описываются немного отличающиеся друг от друга модели ролей в проекте. Отличия кроются как в составе ролей, так и в выстраивании ответственности за параметры проекта.

Рассмотрим ролевую модель, которая описана в самом популярном в мире (если верить исследованиям PWC) подходе к управлению проектами – PMBOK.

Утверждение требований к продуктам проекта
Приемка продуктов проекта

Утверждение целей проекта, сроков и бюджета
Выделение ресурсов для проекта

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

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

Давайте рассмотрим проект по автоматизации процессов взаимоотношений с клиентами (CRM) в небольшой частной компании. Кто из сотрудников компании, внедряющей у себя CRM, может стать заказчиком такого проекта?

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

Чтобы принять решение о назначении заказчика в проекте CRM, предлагаю последовательно ответить на следующие вопросы:

Если продолжительность проекта составляет примерно полгода, то 48 часов как раз распределятся на 24 недели по 2 часа в неделю. Однако заказчик будет тратить время не только на принятие важных решений. Ему нужно читать и согласовывать документы по требованиям к CRM, участвовать в приемке промежуточных результатов проекта, изучать отчеты руководителя проекта о ходе проекта. На эту работу, с моей точки зрения, уйдет не меньше времени, чем на принятие решений. Отсюда и появляется расчет, что на данный проект заказчику нужно планировать от двух до четырех часов в неделю. Конечно, это очень приблизительный расчет и в каких-то аналогичных проектах у заказчика может уходить намного больше времени на проект.

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

В своей практике я встречал ситуации, когда никто из потенциальных кандидатов не хотел брать на себя роль заказчика проекта. Причина такого поведения, скорее всего, в том, что они опасались брать на себя дополнительную ответственность. Во-первых, на работу в проекте нужно время, а если оперативные задачи могут отнимать все рабочее время, то проектные придется решать в нерабочее время. Во-вторых, если проект окажется провальным, то за него, как минимум, не похвалят. Вот и скажите, кому захочется брать на себя роль заказчика проекта при таком раскладе? Бывает, что у кого-то из руководителей подразделений появилось понимание, что без решения стоящей перед проектом задачи в дальнейшем решать оперативные задачи будет все сложнее. В таком случае у него все-таки есть мотивация стать заказчиком.

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

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

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

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

Так кого назначить руководителем проекта в нашем кейсе?

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

Предположим, что было принято решение отдать ИТ-компании проект CRM «под ключ», и вопрос с назначением руководителя проекта решен – им станет профессиональный руководитель проекта со стороны ИТ-компании, которую еще предстоит выбрать.

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

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

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

Делать какие-то обобщения на примере рассмотренного кейса не стоит. Проекты бывают очень разными как по своему масштабу, так и по предметной области. В некоторых случаях рассмотренная модель ролей может оказаться слишком простой и неэффективной. Например, в методологии управления проектами Prince 2 рассмотрена куда более сложная модель ролей, чем в PMBOK.

Несмотря на это, надеюсь, читателем стала понятна точка зрения на ролевую модель в проекте, описанная в подходе PMBOK.

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

Как мне кажется, лучше потратить время до старта проекта на определение необходимых ролей и назначение на эти роли конкретных лиц, чем по ходу разбираться с вопросами «кто виноват?» и «что делать?».

Успехов вам в определении ролей в проектах!

Источник

Определение ролей участников проектной команды

По результатам множества опросов менеджеров проектов в России и зарубежом, до 80% успеха при реализации проектов обусловлены слаженной работой проектной команды, которая, в свою очередь, обеспечивается верным распределением ролей среди участников. Многие менеджеры проектов сосредотачиваются на “технических” ролях, таких как проектировщики баз данных, специалисты по сетям, эксперты по пользовательскому интерфейсу и т.д. Все они важны, но нужно подумать и о ролях “психологического” плана, которые могут играть один или более участников команды. В данной статье рассматриваются некоторые наиболее известные подходы в этой области.

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

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

Роли, ориентированные на выполнение задач команды

Определяет проблемы: определение общих задач группы.

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

Предоставляет информацию: предлагает информацию для использования в решении задач, разъясняет предложения.

Ищет мнения:запрашивает мненияотносительно обсуждаемого вопроса.

Высказывает мнения: делает утверждения по обсуждаемым вопросам.

Проверяет целесообразность: сопоставляет предлагаемые решения с реальным положением дел.

Роли, ориентированные на создание/ поддержание работы команды

Координирует: поясняет утверждения и показывает их связь с другими утверждениями, анализирует предлагаемые варианты.

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

Ориентирует: помогает группе придерживаться плана, обнаруживает отклонения, предлагает процедуры для повышения эффективности работы группы.

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

Сопровождает: последовательно продвигается по всем этапам вместе с командой, принимает чужие идеи, выражает согласие.

Индивидуальные роли (нефункциональные)

Блокирует:мешает работе группы, вызывая споры, оказывая неаргументированное сопротивление и несогласие. Позже возвращается к забытым вопросам.

Уклоняется от работы: дремлет, занимается посторонними делами, переговаривается с другими и т.д.

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

Классический подход к распределению ролей между участниками проектной команды был предложен доктором Р.М. Белбином (R. Meredith Belbin). В каждой проектной команде, которая стремится эффективно организовать свою работу, независимо от ее численного состава, должны выполняться следующие 8 ролей:

Интересный подход был предложен Риком Баррерой (Rick Barrera), членом PMI, специалистом в области управления проектами. Он выделяет 4 основные категории участников, различных по типу поведения. Это руководители (directors), “всеобщие друзья” (socializers), “личные друзья” (relaters) и мыслители (thinkers).

Руководители отличаются высокой работоспособностью и нацелены на успех выполнения проекта. Они вряд ли согласятся заниматься какими-то другими делами, пока осталась невыполненная работа. “Всеобщие друзья” занимаются сбором информации, общением с коллегами. Только после этого они приступают к выполнению работы. “Личные друзья”, также как и “всеобщие друзья”, общаются с другими членами команды, но делают это с глазу на глаз. Мыслители предпочитают делать всю работу в одиночку, анализируя и осмысливая информацию, объявляя о результатах только после завершения всей работы.

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

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

Чтобы обеспечить эффективную командную работу, менеджер проекта должен выявить все категории участников с тем, чтобы подобрать точные роли для каждого члена команды и сделать условия его работы максимально комфортными. Ведь, например, если запретить “всеобщим друзьям” общаться с другими членами команды, они не смогут представить никаких результатов работы. В обратном случае, работа такого члена команды может оказаться очень продуктивной. Добившись этого, менеджер может рассчитывать на большую эффективность работы своей команды. При этом он сам должен обладать качествами каждой группы, понимать мотивацию своих сотрудников и иметь перспективное видение развития проектной команды.

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

В завершение статьи приводим сравнительный анализ рассмотренных подходов к распределению ролей в команды.

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

Авторы: О.Ильина, Е.Песоцкая

Источник