Всё правильно.
Люди поговорили на начале проекта с кем-то из бизнеса. Поняли по-своему и пришли с этими идеями в разработку. А разработка не смогла уточнить и верифицировать требования, т.к. между заказчиком и разработкой был слой, блокирующий коммуникацию.  
Через 9 месяцев стало понятно, что поняли они не так, как задумал заказчик.

обязательно. процессы про бизнес, системы про обеспечение, 100% покрытие мало где встречается.

Спрошу в лоб, может совсем ерунду пишу, раз игнорите . С чего взяли, что сделали фигню, а вы описываете обыденность и мы также работаем. Если заказчик сначала хотел одно, потом посмотрел результат и сказал про другое, то это не проблема разработки , а проблема именно слабой формулировки от заказчика и несвоевременного оповещения о необходимых изменениях. Вот  с таким вот работали больше 5 лет. И помогает именно функциональный подход. Как раз для малых его частых инкрементов. Тогда и сверху смогут увидеть, что хотят и вам меньше хлопот по перестройке будет раз в целом общий вид есть, а нужны частности.

Это не кросс-процесс. Оунер там должен быть.

тогда как такое вышло то. Процесс не кросс, а оунера нет? Идеально самоорганизующаяся структура?

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

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

1. Идея не менялась.
2. Ещё в Вигерсе была описана вилка ожиданий, которую я очень люблю. Но в данном случае вилка ожиданий согласовывалась не с заказчиком, а с промежуточным слоем.

Кто такой промежуточный слой в вашей ситуации?

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

В моём случае это БА и ПМ. Возможно в случае БА это ПМ. Иначе бы БА (в теории) выявили бы несоответствие целей проекта ожиданиям заказчика.

Был бы оунер - было бы чётко обозначенное ответственное лицо, которое бы не пропустило лажу.

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

Это как раз случай для GAP-анализа. Разрыв между процессами и оунерами. Поиск процессов у которых нет владельца.

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

Я не могу ответить на этот вопрос, т.к. не прошёл проверку навыка управления (видимо). xD

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

Я хорошо понимаю характер топа и понимаю, что здесь был момент missconnect, а не изменения мнения или цели.

Даже если заказ упал на ПМа, хороший аналитик обязан уточнить цели и требования. Как говориться "Посмотреть в глаза" заказчику.

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