Как определить Цель продукта

Долго время я делал ИТ проекты/продукты, и все это время мне не было никакого дела до Цели (с большой буквы). Ну как не было - цель всегда была. Она указывается в пункте 2.4 в каждом ТЗ и ЧТЗ, и мы всегда свободно вписывали туда все что считали нужным. Часто путали что такое "цель" и что такое "назначение" - не знаю смогу ли я сейчас это правильно определить.

Далее был Agile и Scrum. Члены настоящей Agile-команды должны понимать куда идет продукт/видеть цель. И это не проблема. Часто рассказываешь Что и Зачем - они вроде кивают, понимают.

Потом пришел Гойко Аджич (опять он) и сломал мне все мироощущение со своим Impact mapping.

Оказалось что все это время в проектах не было Цели - вернее Цель была ложной. И по моей текущей модели это корень зла всех проблем:

1. Большинство Fail-ов в разработке software 
2. Бесполезные ИТ-системы, которые никто не использует (особенно государственные системы)
3. Бесконечные списки замечаний от Заказчика, когда ты приходишь к нему в конце проекта с восклицанием "Подписывай акты, Чувак! Все круто получилось!" 

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

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

"Нет метрики - нет цели" (с) Т.Д.

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

Но вернемся к Impact mapping.
Представим что есть Заказчик, у него есть проблема. Мы собрались вместе подумать что и как мы будем делать. И первый вопрос - "Какая наша цель, и какая метрика на ее достижения?"
Варианты:

Вариант А. 
Исполнитель подсказывает самый популярный и естественный вариант. "Цель проекте - это создание системы А. Метрика цели - система работает." Далее, если желание создавать Impact map не пропало, то рисуется какая-то хрень, состав которой следует из ТЗ. Разбежались. 2-10 месяцев и имеем результат, который описан в самом начале.

Вариант В.
Так как Impact map рисует Исполнитель, то через пару минут появляется такая мысль. Цель - заработать денег. Метрика - 15 млн. руб. Здесь всегда интересно следующее. Цель должна быть прозрачна, то есть с ней должен согласится Заказчик. Как происходит тот диалог, на котором Исполнитель сообщает Заказчику, что конечная цель всего мероприятия в том, что Исполнителю нужно заработать 15 млн. И как на это должен согласится Заказчик. С такой целью весь Impact mapping хочется закопать поглубже и забыть.

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

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

Вариант С.
Спасибо, Виктор. Цель - создание системы по автоматизации процесса управления инвестиционными проектами. Метрика - процесс управления стал быстрее. Беда в том, что метрика и цель совсем никак не связаны, вернее притянуты за уши. Мы боимся признать, что процесс создания системы это никак не цель, это лишь одно (но видимо ГЛАВНОЕ) наше предположение для достижения цели. Мы боимся так как процесс достижения цели не полностью зависит от нас, и значит любые проблемы по достижению это цели - будут нашими проблемами. Проще не брать эти проблемы на себя - проще просто сделать систему по "нашему" же ТЗ, которое бедный Заказчик имел неосторожность подписать.

И последний вариант.
Например, Цель - сделать процесс согласования инвестиционных проектов быстрее.
Метрика
1) Название - время согласования инвестиционных проектов
2) Способ - Время от инициации проекта до получения статуса "Согласовано"
3) Текущие значение - 60 дней
4) Минимально допустимое - 20 дней
5) Целевое - 5 дней

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

А вы понимаете Цель своего текущего проекта?