Заказчик выдает неадекватные требования – что делать руководителю проекта?
"Я люблю клубнику. Но если я собираюсь ловить рыбу и стану кормить ее клубникой, то не поймаю ни одной рыбешки."
В одном из моих первых проектов, где я работал тогда еще молодым специалистом по календарно-сетевому планированию, возникла достаточно обидная ситуация. Я занимался задачей по формированию стоимостной модели, которая обеспечивает автоматический пересчет бюджета при сдвиге сроков работ в календарно-сетевом графике.
В этой задаче мной двигал в первую очередь «спортивный интерес», никаких особых материальных бонусов за решение задачи не предусматривалось, просто мне очень хотелось, чтобы разработка «взлетела». Работа шла тяжело, пришлось потратить сверхурочно несколько выходных, а итоговую презентацию перед показом заказчику я заканчивал делать в районе 3 часов ночи. В итоге мой отчет о работе заказчик разнес в пух и прах, потому что... презентация о стоимостной модели была оформлена не по корпоративному шаблону заказчика. Стоимостную модель, по сути, никто и не смотрел.
Кто виноват, и как избежать таких ситуаций?
Посмотрим, что на эту тему нам говорит теория управления проектами.
По определению из классического подхода к управлению проектами, Руководитель проекта – лицо, назначенное возглавить команду и отвечающее за достижение целей и результатов проекта. Заказчик, по определению, - лицо или группа лиц, которые будут пользоваться результатами проекта. Важно не путать роль Заказчика в методологии управления проектами и роль Заказчика в юридическом контексте договорных отношений. Например, в строительном проекте роль Заказчика принадлежит тем, кто в будущем будет эксплуатировать построенное здание. А в проекте внедрения ИТ-системы Заказчиками являются будущие пользователи этой системы или их представители. У Заказчика в проекте есть ответственность - в начале проекта он должен утвердить будущие результаты проекта, а по окончании проекта принять полученные результаты.
Как в классическом, так и в адаптивном подходе к управлению проектами одним из первых шагов руководителя проекта является сбор требований. Требования при этом может выдавать не только Заказчик, а более широкий круг лиц, именуемый стейкхолдеры (заинтересованные стороны). По определению, стейкхолдеры - лица или организации, которые могут позитивно или негативно повлиять на исполнение или завершение проекта. Пример стейкхолдера – государственные надзорные органы в строительных проектах. Они не будут пользоваться результатами проекта, но их требования являются определяющими.
Также в любом из подходов к управлению проектами так или иначе говорится о том, что одним из критериев успешности проекта является удовлетворенность стейкхолдеров.
Из всего вышесказанного следует однозначный логический вывод, что руководитель проекта не формирует требования к результатам проекта – он их исполняет.
Вернусь к вопросу, вынесенному в заголовок. Так что же делать, если Заказчик и прочие стейкхолдеры выдают некорректные на ваш взгляд требования и требуют в рамках проекта создавать результат, который в дальнейшем не принесет никому никакой пользы? Исходя из лучших международных практик управления проектами и логики здравого смысла возникает три варианта действий.
1. Переубедить стейкхолдеров.
Работа в роли руководителя проекта подразумевает проактивную позицию, наличие собственного мнения и готовность его отстаивать, а не только исполнительность и готовность механически выполнять любые поручения и задачи. Поэтому если вы считаете, что требования к результатам проекта некорректны или не оптимальны, попробуйте донести это свое мнение до стейкхолдеров и убедить их поменять требования. Это в ваших интересах. Объясните в чем предлагаемый вами вариант будет лучше для них. Стейкхолдеры на самом деле часто сами плохо понимают чего хотят.
2. Делать то, что вам говорят.
Если переубедить попробовали, но не получилось – вспомните о том, что руководитель проекта не определяет требования к результату проекта, он их исполняет. Если продукт проекта окажется бесполезным ввиду того, что требования к нему были сформулированы некорректно, это в первую очередь ответственность заказчика и это не вина руководителя проекта.
Конечно, при этом сценарии у Вас есть риск по окончании проекта услышать фразу: «Так вы же специалист, почему вы нам сразу не сказали, что требования некорректны?». Причем услышать вы ее можете даже в случае, если многократно предлагали требования поменять. Для того минимизировать подобный риск (именно минимизировать, потому что полностью исключить его невозможно), в подобных ситуациях крайне рекомендую «оставлять следы», то есть формально фиксировать Ваши предложения, хотя бы в формате письма по электронной почте.
3. Уйти из проекта.
На этих двух вариантах можно было бы и закончить, если бы не морально-этическая сторона вопроса. Порядочный врач не станет проводить манипуляции, которые принесут вред пациенту, даже если от него этого требует начальство или сам пациент. Кроме того, важной составной частью мотивации в проектной работе является понимание ценности того продукта, который ты создаешь. Поэтому если от вас требуют делать то, что противоречит ваших принципам и моральным убеждениям или просто неинтересно, а переубедить стейкхолдеров поменять требования невозможно, то честным и корректным решением будет выход из проекта.
Вот такая проза жизни.
Отдельно остановлюсь на вариантах «плохой практики» действий в рассматриваемой ситуации. Практика плохая, но, к сожалению, встречается достаточно часто - когда руководитель проекта занимает одну из двух приведенных ниже позиций:
- Заказчик дал некорректные требования, поэтому я делаю так, как я считаю правильным, а не так, как требует заказчик.
- Сижу в роли «обиженного», работаю спустя рукава и делаю халтуру, потому что мои идеи и предложения здесь не ценят.
Такие варианты действий лучшими международными практиками управления проектами не предусматриваются.