В шапке
Роли в проекте

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

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

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

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

Название роли Ответственность Полномочия
Руководитель проекта Достижение всех целей проекта в срок и в бюджет Зависят от организационной структуры
Заказчик проекта

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

Изменение приоритетов в реализации требований к продуктам проекта
Спонсор проекта

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

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

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

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

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

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

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

  1. Сотрудники каких подразделений компании будут использовать программный продукт, автоматизирующий CRM?
  2. Кто из руководителей этих подразделений больше всего заинтересован в том, чтобы CRM помогла ему решать его задачи?
  3. Может ли потенциальный заказчик проекта CRM тратить на него 2-4 часа в неделю?

По данным Standish Group, на каждую $ 1000 стоимости времени людей в ИТ-проекте приходится принимать 1,5 решения. Предположим, проект внедрения CRM-системы оценен в 50 000$, из них стоимость лицензий – 10 000$, а оставшиеся 40000$ - стоимость времени людей. По статистике Standish Group получается, что в этом проекте нужно будет принять около 60 важных решений, причем заказчик должен принять участие в 20% из этих решений. Предположим, что в среднем на решение одного вопроса заказчик тратит 4 часа. 12 важных решений по 4 часа на каждое – получается 48 часов.

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

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

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

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

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

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

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

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

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

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

Ну и четвертая роль - команда проекта.

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

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

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

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

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

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

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

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

Комментарии (0)
Войти как