Сколько нужно PM на проекте?

Junior PM сам на проекте обучаться не может. Почему-то когда добавляют в команду Junior разработчика, никто не рассчитывает, что он будет создавать production-ready код, и ему не нужен старший товарищ, который будет делать code review, помогать с постоянными вопросами / проблемами и направлять. В случае с Junior PM почему-то ожидания сразу другие, но нет: управление проектом - это отдельная самостоятельная сложная дисциплина, которой тоже нужно обучаться сравнимо с обучением любой другой IT профессии. Да, многое зависит от человека, и кто-то быстро разберется сам, будет изучать дополнительные материалы по профессии и т. д., но тем не менее помощь более опытного коллеги просто необходима (особенно, на первых проектах). Даже если у человека громадный опыт в IT в другой роли (разработчик, аналитик, даже Team Lead), но он только начинает свой путь в совсем новой для себя роли руководителя проекта.

Совмещение роли PM с BA, Архитектором, и т. д. Ещё один распространенный подход к формированию команды - совмещение роли PM с ролью аналитика, архитектора, или, например, QA Lead. По опыту это может работать, особенно, если условный Senior BA сам хочет развиваться в сторону PM и решили, чтобы он попробовал себя в этой роли (тут, правда, помним п.1, что без присмотра такого PM оставлять нельзя).
Но тут нужно быть очень аккуратным, человеку свойственно с большим желанием заниматься тем, чем ему больше нравится. И если ему больше хочется развиваться в PM, значит другая зона ответственности будет страдать (или же наоборот, если ему не нравится пиэмить, а его попросили - не ждите тут хорошего результата).
Ещё один минус такого подхода заключается в том, что PM должен оставаться "нейтральным", чтобы объективно интегрировать членов команды (решать возникающие споры) и контролировать качество их работы (вычитывать требования, проверять версию продукта перед демо клиенту и т. д.). Когда PM выполняет производственную роль эта нейтральная объективность теряется.

Более двух проектов одному PM. Бывает, что параллельно идет несколько очень маленьких проектов, где даже на 2 часа в день ставить PM - слишком много. И в итоге получается, что у человека пара проектов завершается, 2-3 небольших проекта в активной стадии, а где-то ещё помогает с коммерческим предложением. В итоге происходит расфокусировка сотрудника, и даже если он вывозит, это приведет к его скорому выгоранию и последующим фейлам. Хотя сотрудник ответственный, перспективный. В добавок, в подобном сценарии PM начинает просто выполнять рутинные задачи по несложных проектах, что в итоге не позволяет раскрыть его потенциал.
Обычно более двух проектов у одного PM - это плохо. Если видите, что объективно у сотрудника есть свободное время - лучше занять его на задачах по обучению, развитию, PMO активностях и т. д.

Все проекты разные. Обычно делается классный WBS на задачи разработки, иногда добавляются отдельные задачи на аналитику и тестирование, но трудозатраты PM обычно просто добавляются как некий % от трудозатрат на проект. При этом забывается, что все проекты разные и нельзя загрузку PM планировать для всех проектов одинаково, есть как минимум следующие особенности, которые существенно влияют на трудозатраты PM:

• Команда. Очевидно, команда из 5 человек будет требовать существенно меньше времени, чем команда из 15 человек. Сюда ещё стоит добавить сложность команды, её самостоятельность и слаженность.
• Техническая сложность проекта. Если в проекте много технических рисков, их "разруливание" будет на плечах PM. Тут будут и длительные обсуждения с лидами, и коммуникации с клиентом, и актуализация артефактов, если что-то идет не по изначальному плану, и т. д.
• Требовательность заказчика. Бывает, что проект вроде не сложный и не требует полного набора артефактов и процессов, и SLA не требуется очень высокий, но, если это не проговорить с заказчиком на старте - у него могут быть совсем другие ожидания. Иногда случается, что оплачивая 2 часа PM на проекте в день заказчик ожидает, что PM будет ему отвечать в течение часа (встречал, когда даже чаще), предоставлял ежедневно отчеты о работе команды, устраивал еженедельные встречи-демо и т. д. Важно на берегу синхронизироваться с заказчиком по тем активностям, которые будет выполнять PM (помимо обязательных), чтобы запланировать его время на проекте соответственно.
• Процессы компании. В разных компаниях для разных проектов применяются разные процессы, что существенно влияет на объем трудозатрат PM. Где-то работают по чистому Scrum без каких-либо доп. артефактов с двухнедельными итерациями, графиком сгорания и общим roadmap проекта, а где-то требуется вести детальный план проекта в MS Project, регулярно актуализировать реестр рисков, карту стейкхолдеров и вот это всё. Попробуйте составить список всех активностей, которые PM должен выполнять на вашем проекте и честно оценить их.
• Уровень планируемого PM. Более опытные PM быстрее ориентируются, у них уже набита рука в инструментах, которые используются для управления проектами и вообще выполняют типовые задачи они быстрее и более системно. Но нельзя сказать, что вовлечение более опытного PM позволит сэкономить x2 трудозатрат. Вне зависимости от уровня PM, 1:1 с членами команды, дейли, встречи с клиентом всё равно будут требовать время.

М - Мотивация. Недостаток управления возможен не только из-за ошибок в планировании загрузки PM по часам, или когда ставим слишком неопытного PM. Легко может получиться так, что очень опытному PM даем достаточно простой проект, и тот его успешно..... фейлит. А всё потому, что считает его слишком простым для себя, скучным, не интересным и начинает забивать на какие-то важные моменты. М - Мотивация. Ставя на проект конкретного PM важно понимать, что его будет драйвить в этом проекте. Возможно, это сложный проект и тут есть для него вызов, возможно, тут он учится под чьим-то началом, а, возможно, это возможность PM проявить себя в роли наставника для менее опытного коллеги-PM. Мотивация - это отдельная и сложная тема, но обязательно помните о ней, когда назначаете PM на свой проект.