методологическую поддержку ПМО оказать не может, ибо формально все требования зафиксированы и оценены на этапе инициации

итогом будет - требования есть, сроки не двигаются, предлагайте средства митигации рисков

собственно про эти средства в виде нормализации управления требованиями и коммуникациями я и спрашива

проект внутренний

со внешним исполнением

Ну условный scrum как Фреймворк как раз для таких случаев и создан. Не готовы жить по scrum на всех этапах продуктового цикла, применяйте его на этапе product discovery.

И вы так и не дали подробностей что за индустрия, что за продукт, для кого он делается. С другой стороны, это не для обсуждения в открытом чате.

Как говорится, «вам- совет или консультацию? Совет - бесплатно».

в моем понимании решение:
1) разделение потока требований на области и закрепление за каждой конкретного представителя из пользователей результата.
2) выделение на проекте 2 взаимозаменямых человека, ответственных за ведение и учет требований, их мержинг и приоритизацию
3) все коммуникации по скоупу между внешним исполнителем и внутренней командой вести только через этих 2х человек

соответственно хочу бесплатный совет - можно ли что-то сделать еще, достаточно ли озвученного и какие инструменты можно использовать

Общайтесь с пользователями не на языке требований, а на языке прототипов. Сначала бумажных, потом кликабельных, потом MVP.

И несмотря на нежелание играть в «problem solving» очень советую разобраться с пользователями - почему у разных пользователей разное видение продукта? Может нужны разные продукты? Или вы (а может и сами пользователи) не до конца понимают контекст своих действий и потребностей? Тогда вперёд - используйте персоны,  гемба, этнографические наблюдения и прочий shadowing. Потом рисуйте CJM (кстати для разных групп пользователей он может быть совсем разным) проходите его вместе с пользователем «мысленно» или с прототипом.

Судя по всему у вас провалена работа по проектированию продукта, тот самый product discovery.

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

Формально, еще кастдев забыли посоветовать 😁

проект закрывает лигал задачу. времени на кастев :D нет. задача не сделать лучше, задача не сделать хуже

Ой, не туда, не туда. Вы,судя по всему, видите решение в железной дисциплине, усиления контроля и «поставить пользователя на место, фигли он не знает что хочет».  Можете попробовать. Но скорее всего станет еще хуже. Вот в похожих кейсах, с которыми сталкивался я - после таких мер все было именно что хуже. Но опять же, вселенная многообразна. Может быть «все такие, а я не такой» (с). И именно у вас подход «выбить всю дурь у пользователей и заставить их ходить строем» сработает )

ситуация действительно из разряда - пациент уже не дышит, надо реанимировать. а почему он в такое состояние пришел, пил ли и курил - вопрос на этап рефлексии уже

какие меры принимали вы и помогло ли?

Мне видится, что на текущем этапе нужно признать результ не достигнутым и инициировать перезапуск. Слишком большая энтропия неупорядоченных действий.
Способов перезапуска много. Можно например выбрать одного якорного Заказчика, требования которого будут иметь бОльший вес на фоне других потребителей, а с другими вести проект исходя из ситуации конфликтуют ли требования других потребителей с требованиями основного Заказчика. Далее аккуратно докидывать в релиз задачи, реализация которых не сильно затронет ключевые фичи якорного Заказчика и начать выводить функционал интервалами. Нужен солюшен архитектор, что бы ловить такие пересечения и вовремя блокировать реализацию требований, выполнение которых может навредить ключевому Заказчику. Так есть шанс, что один Заказчик будет более-менее доволен, а остальные нет, но что про них помнят. Дальше можно выработать привычку очередности.

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

но вопрос встанет на этапе имплментации всего это в жизнь, так как требует согласования этих центров сил, что будет сложно ибо реально убого получается. А хочется все по красоте, в чем все по факту и заинтересованы

хочется, но не можется

привычка очередности - это когда сейчас сделаем тебе хорошо, потом кому-то еще и третьему, а тебе еще раз хорошо сделаем через 10 спринтов?