какая может быть роль в проекте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

Пример формирования команды проекта внедрения корпоративного хранилища данных. Проектные роли

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

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

Вхождение в команду проекта ключевых специалистов и TOP-менеджеров Заказчика является одним из условий успешного достижения целей проекта.

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

Пример формирование команды проекта внедрения
корпоративного хранилища данных

Ниже приведено описание проектных ролей команды проекта со стороны Исполнителя.

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

Для участия в проекте со стороны Заказчика могут привлекаться следующие сотрудники.

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Роли в проектном управлении. Курс по управлению проектами, часть 3

В проектном управлении выделяют несколько ключевых ролей:

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

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

Суть: снабжает ресурсами проект и принимает судьбоносные решения.

Определение: лицо(или группа лиц), предоставляющее ресурсы и поддержку для проекта, программы или портфеля и ответственное за достижение успеха.

Отношения с ПМ (менеджером проекта): он решает то, что не во власти ПМ.

Количество:один или много.

Итак, спонсор снабжает проект ресурсами. В нашем случае кто выделяет ресурсы? Директор! Ведь клиент, по сути, заплатил миллион долларов компании, но эти деньги до проекта еще не дошли. До проекта может быть дойдет 10 тысяч долларов, остальное – налоги, какие-то платежи, сборы. Поэтому тот, кто дал деньги на проект, тот и спонсор. В IT у менеджеров зачастую вообще нет денег. В этой сфере в качестве ресурсов выделяют на проект людей – 5 программистов, 2 тестировщика, аналитик на год. И все – делайте проект. Кто им зарплату платит? Директор! Он вас обеспечил ресурсами – людьми, поэтому он спонсор.

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

Суть: те, кто будет утверждать/использовать результаты проекта.

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

Отношения с ПМ: их интересы обслуживает ПМ.

Количество: как правило, много.

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

Следующая роль в проекте отводится команде. Кого назвать командой? Это все люди, которые будут выполнять работы на проекте. Важно понять, что это не рабочая группа, куда обычно включают разных сотрудников, а именно те люди, которые работают в проекте: рисуют эскизы, таскают кирпичи…

Суть: те, кто будет выполнять работы.

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

Отношения с ПМ: трудно переоценить.

Количество: всегда много.

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

Менеджер (или руководитель) проекта – это человек, который управляет командой, чтобы достичь цели проекта и попасть в треугольник (подробнее про треугольник см. статью “Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера”). И формально он входит в команду.

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

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

Количество: один, но может формировать целую «команду управления проектом»

Суть: все, чьи интересы затрагиваются реализацией проекта.

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

Отношения с ПМ: зависят от вида и влияния заинтересованного лица.

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

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

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

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

Если вас интересует тема «Управления проектами» и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина «Подготовка к экзамену РМР»

Источник