Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?»

Как распределить роли, ответственность и полномочия в проекте и почему на это нужно потратить время на старте, рассказывает наш эксперт Максим Якубович.

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

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

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

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

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

Заказчик проекта

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

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

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

По данным Standish Group, на каждую $1000 стоимости времени людей в ИТ-проекте приходится принимать 1,5 решения. Проект внедрения CRM-системы оценен в $50 000, из них цена лицензий на необходимое ПО – $10 000. Оставшиеся $40 000 – стоимость времени людей.

Получается, в проекте будет около 60 важных решений, причем заказчик должен принять участие в 20% из них. Предположим, что в среднем на решение одного вопроса он тратит 4 часа. Получается, на 12 важных решений ему надо 48 часов. Если продолжительность проекта составляет примерно полгода, время распределятся на 24 недели – по 2 часа на каждую.

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

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

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

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

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

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

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

Итак, возможны следующие варианты:

1. Кто-то из кандидатов сам вызовется стать заказчиком проекта. Бывает, что у кого-то из руководителей подразделения появляется понимание, что проект поможет в дальнейшем решать оперативные задачи.

2. Заказчика выберет директор компании.

3. Старт проекта будет отложен, т.к. пока никому еще результаты проекта не нужны.

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

Спонсор и руководитель проекта

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

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

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

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

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

Команда проекта

В проекте CRM будет 2 команды.

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

Команда ИТ-компании будет дорабатывать продукт в соответствии с требованиями и готовить его к промышленной эксплуатации.

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

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

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

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

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