Про роли в управлении проекта

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

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

1️⃣ PM Исполнителя <-> PM Заказчика. Это уровень исполнения проекта. И да, у Заказчика должен быть руководитель проекта. Тот человек, который будет тратить уйму времени для координации встреч, подготовки необходимой для реализации проекта информации, приемки промежуточных результатов и т.д.

2️⃣ Куратор проекта от Исполнителя <-> Куратор проекта от Заказчика. Если мы вернемся к гостовой схеме из предыдущего поста, то увидим, что задачей этой роли в отношении проекта является обеспечение ресурсами. Это справедливо как на стороне Исполнителя (чаще всего это руководитель проектного офиса), так и на стороне Заказчика (это может быть CEO, директор по развитию, либо представитель иной должности, обладающий соответствующими полномочиями - назначать PM и выделять ресурсы для реализации проекта).

3️⃣ Уровень ЛПР. Со стороны Исполнителя, как правило, это владелец компании или CEO, а от Заказчика - всегда ключевой собственник. Это самый верхний уровень координации, где обсуждаются стратегические вопросы взаимодействия. Это взаимодействие выходит за рамки проекта. А в проекте этот уровень является уровнем принятия ключевых решений и крайним уровнем эскалации проблем.

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

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