ЗАКАЗЧИК ВЫДАЕТ НЕАДЕКВАТНЫЕ ТРЕБОВАНИЯ – ЧТО ДЕЛАТЬ РУКОВОДИТЕЛЮ ПРОЕКТА?

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

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

Так что же делать, если Заказчик и прочие стейкхолдеры выдают некорректные на ваш взгляд требования и требуют в рамках проекта создавать результат, который в дальнейшем не принесет никому никакой пользы?

Читайте об этом в новой статье Директора практики PM Excellence Романа Черемисина, PMP, PME, MCTS далее:

""Я люблю клубнику. Но если я собираюсь ловить рыбу и стану кормить ее клубникой, то не поймаю ни одной рыбешки."

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

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

Посмотрим, что на эту тему нам говорит теория управления проектами.

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

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

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

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

Вернусь к вопросу, вынесенному в заголовок. Так что же делать, если Заказчик и прочие стейкхолдеры выдают некорректные на ваш взгляд требования и требуют в рамках проекта создавать результат, который в дальнейшем не принесет никому никакой пользы? Исходя из лучших международных практик управления проектами и логики здравого смысла возникает три варианта действий.1. Переубедить стейкхолдеров. Работа в роли руководителя проекта подразумевает проактивную позицию, наличие собственного мнения и готовность его отстаивать, а не только исполнительность и готовность механически выполнять любые поручения и задачи. Поэтому если вы считаете, что требования к результатам проекта некорректны или не оптимальны, попробуйте донести это свое мнение до стейкхолдеров и убедить их поменять требования. Это в ваших интересах. Объясните в чем предлагаемый вами вариант будет лучше для них. Стейкхолдеры на самом деле часто сами плохо понимают чего хотят. 2. Делать то, что вам говорят.Если переубедить попробовали, но не получилось – вспомните о том, что руководитель проекта не определяет требования к результату проекта, он их исполняет. Если продукт проекта окажется бесполезным ввиду того, что требования к нему были сформулированы некорректно, это в первую очередь ответственность заказчика и это не вина руководителя проекта.

Конечно, при этом сценарии у Вас есть риск по окончании проекта услышать фразу: «Так вы же специалист, почему вы нам сразу не сказали, что требования некорректны?». Причем услышать вы ее можете даже в случае, если многократно предлагали требования поменять. Для того минимизировать подобный риск (именно минимизировать, потому что полностью исключить его невозможно), в подобных ситуациях крайне рекомендую «оставлять следы», то есть формально фиксировать Ваши предложения, хотя бы в формате письма по электронной почте. 3. Уйти из проекта.

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

Вот такая проза жизни.

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

Такие варианты действий лучшими международными практиками управления проектами не предусматриваются."