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

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

И часто ПиЭмы сводят на нет всю идею собственной позиции, воспринимая себя как человеков, созданных для того, чтобы давать таски и спрашивать "как продвигается".

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

1. ПиЭмы - это зона бизнес-требований, бизнес-процессов, взаимодействия с клиентом. Эти требования и видение должны быть изложены так хорошо, чтобы все остальные участники проекта имели представление о том, чего нужно добиться в ходе работы над продуктом, а так же были поставлены в известность о рисках проекта. Исходя из этих данных строится весь процесс разработки продукта.
2. Разработчики - это зона архитектуры приложения, концепции, разработки прототипов, разработки и поддержки продукта.
3. Тестировщики - именно их (а не ПиЭмов) зона ответственности состоит в том, чтобы сказать "продукт готов".
   Неправильно воспринимать тестировщика как человека, работа которого заключается в том, чтобы проверить "кнопка кликнул - бага нету". Тестировщик, в числе прочего, ответственен за проверку того, насколько тестируемый продукт или фича соответствует духу тех требований, которые (через ПиЭма) были получены от кастомера. Тестировщик - это некий "эмулятор" кастомера, он может (и должен) возражать не только против возникающих исключений, но и против нелогичного содержания форм, против неинтуитивного интерфейса, неполного покрытия нужд клиента. Даже если формально все требования выполнены и все фичи реализованы, тестировщик в праве сказать, что в реальной работе программа должна вести себя иначе.

То, насколько именно тестировщиком (и всей командой) понята концепция этой самой "реальной работы" - вот одна из задач ПиЭма.

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

Всякие там методологии - они как закон. Они - одно для всех, и для ПиЭмов, и для КьюЭйев, и для разработчиков. "Начальник камчатки", рулящий "а сейчас левая нога делает шаг впереееед... тааак, правая пока на месте, а щас пошлаааааа, пошлааааа" не нужен вовсе.

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

То есть, вместо идеологически неверного "сделал - отчитался ПиЭму, он напряжет кого-то другого" все три "отрасли" находятся во взаимодействии, стараются идти по определенному ими же общему плану в рамках принятого цикла.
Простой пример: разработчики заканчивают подсистему в срок и сдают ее тестерам (а не отчитываются ПиЭму "сделал, забирайте").  Согласно графика получить фидбек от тестировщиков они должны через N дней (а не от ПиЭма в виде "тестеры говорят, что там что-то не так, разберитесь"). Так, и те и другие заинтересованы в сдаче своего участка в срок, то начинается нормальное рабочее взаимодействие их между собой. Не нужен никакой посредник в виде "начальника камчатки".

Словом, я хочу лишь сказать (в том числе и как человек, работающий, словами Михаила, в большой компании, ориентированной на IT), что часто встречающаяся практика восприятия ПиЭмов (в том числе и ими самими) в качестве непрозрачного прокси между клиентом и разработчиками (слушаю первого, пинаю вторых) - порочна.
То есть так:

делать неправильно ;) К сожалению, это очень часто встречается...