Что ж, дал время желающим подумать над ответом на вопрос ⬆️ и пишу свой ответ.

Описанная ситуация говорит о том, что это - токсичный проект.
Профессиональный РП должен уметь работать в токсичных проектах, хотя бы потому, что часто у него нет возможности просто отказаться от такого проекта без потерь в карьере и в репутации.
Что в такой ситуации может помочь?

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

Цель такого режима для РП: на любой вопрос любого из заказчиков можно будет достать протокол или иной артефакт, подтверждающий правомерность решения РП.
Если при хороших и доверительных отношениях между Заказчиком и РП стороны могут идти друг другу на встречу в интересах конечного клиента или проектного результата, то в токсичном проекте это - противопоказано, т.к. это становится точкой уязвимости для РП в случае если что-то пойдет не по плану.

2. Запрос поддержки 🙋‍♂️
После определения, что проект - токсичный, РП должен поставить в известность об этом своего руководителя, того, кому может прилететь со стороны Заказчика эскалация, чтобы заручиться поддержкой.
С высокой вероятностью руководитель предложит то, что описано в п.1, а по значимым перепискам попросит держать себя в копии. Это предупредит руководителя, даст возможность оказать помощь при необходимости и морально подготовит к возможной эскалации, которая в этом случае всяко пройдет мягче, чем в случае, когда случится полнейшей неожиданностью для руководителя

3. Нахождение над схваткой ⚖️
При наличии двух не дружественных друг к другу заказчиков, самая правильная линия поведения РП - быть над схваткой.
Кто-то просит новое требование без согласования второго?
- ОК. Спасибо. Фиксируем требование в нашем реестре. Можем ли мы обсудить это до регулярного статуса или озвучим на нем?
...
- Нет, я не могу взять без обсуждения, это требование займет ресурсы команды разработки и может повлиять на конечные сроки.
Даже оценка требования займет время и отвлечение ресурсов команды. Мы готовы это сделать, но прозрачно для всех участников проекта

4. Минимизация негативных эмоций за счет ощущения контроля. 🗂
РП в данном случае не может управлять заказчиками, но он может управлять своими эмоциями. Косвенный плюс гипертрофированного формального ведения проекта как раз в том, что он не позволяет развиваться негативным эмоциям внутри себя.

😡 Заказчик эмоционально предъявил?
-Ок, поблагодарили за обратную связь, спросили причины недовольства, посмотрели отраженное на портале события, спокойно предъявили, пообещали сделать все возможное, чтобы помочь.
⌛️Разработчики отстают по срокам?
- Ок, обсуждаем на рабочей группе статус и причины, включая последние изменения.
📜Запросили объяснительную?
- Посмотрели на портал достали фактуру, включили в ответ


Дополню, что для сеньорного РП разногласия между заказчиком - не драма, а возможность:
- появляется способ маскировать ошибки планирования или локальные отклонения по срокам на стороне ИТ за противоречиями между заказчиками.
- появляется возможность манипулировать позицией заказчиков, предоставляя необходимую информацию в нужном ключе, например, выводя из под огня себя или свою команду.