Изменение требований в ИТ-проектах: взгляд со стороны заказчика и исполнителя

Прошлая тема породила много дискуссий на тему "изменений требований". Эта тема что-то сродни перманентного Бородинского сражения для ит-менеджеров.
Долгое время я была в "стане" исполнителей и не могла понять, отчего же клиенты такие дебилы? )) Почему они не могут сформулировать свои требования к проекту, зачем они их меняют по ходу работ бесконечное число раз и откуда берутся все эти мириады доработок уже почти готового продукта.
Когда я стала заказчиком, многое просветлилось.

Какие же причины мешают клиенту написать четкие требования и ожидания от информационной системы, сайта, п/о? Казалось бы, когда заказываешь костюм, то выбери ткань, стиль, портного и вперед! В жизни же, обычно по-другому.
У заказчика появилась идея, которая может быть реализована с помошью п/о. Идея — это как живое существо. Сначала она маленькая и неопределенная. Она может умереть во младенчестве, а может потихоньку набираться сил и крепнуть в подсознании. Когда она оформиться достаточно для изложения ее в виде бизнесплана, начинается проект разработки. Идею обмеряют со всех сторон, пишут технические требования, спецификации, выбирают материал и начинают шить "костюм" — создавать программное обеспечение реализующее идею.
С точки зрения исполнителя, который производит замеры и шьет сам "костюмчик" идея выглядит как нечно фиксированное — набор требований и ожиданий, список проблем клиента, которые нужно решить. Самые талантливые исполнители пытаются проникнуть глубже: куда вы собираетесь это носить? в какую погоду? делать ли внутренний карман? И это уже хорошо.
Однако заказчик вынужден иметь дело с совсем другими вопросами. Если идея все еще сильная и живая (а только такая и заслуживает реализации), она продолжает расти и развиваться. Как здорового ребенка нельзя остановить в росте одеждой, так и идею не удержать рамками технического задания. Когда будет проходить первая "примерка" окажется что в груди жмет, а штанишки коротковаты. Исполнитель будет возмущен: "Но вот же, вы сами писали в требованиях к проекту "рост — метр пятнадцать", теперь вы хотите для роста метр тридцать пять!". И он конечно, прав. Но у клиента действительно изменились условия, идея стала совершеннее, придумались новые возможности, открылись новые горизонты. И эту "детку" уже не укоротить обратно.

Здесь есть два стандартных пути:
1) записываем все новые пожелания в следующий этап и заканчиваем систему как она была описана в самом начале. В результате клиент получит красивое п/о, которое, в лучшем случае, сможет использовать частично.
2) менять работу по ходу изменения требований. Минусы очевидны: выход за пределы изначального бюджета денег и времени, с возможностью не закончить проект никогда.
Логично напрашивается третий вариант: шить на вырост. Но на практике, я нигде с таким не встречалась.

При всех недостатках второго подхода, мне как заказчику наиболее симпатичен именно он — можно получать хотя бы части системы, которые отвечают последним требованиям. Для исполнителя, особенно при более-менее фиксированных бюджетах, это может стать катастрофой (если вовремя не ввести почасовую оплату, но на это мало кто из заказчиков пойдет).

Upd: Поняла что мысль и вопросы сформулированы недостаточно четко. Формулирую:
Проблема изменяющихся требований в том, что бизнес, идея клиента — это развивающийся процесс, постоянное движение, улучшение. Исполнитель, который берется писать п/о всегда (по моему опыту) относится к делу статически: вот сейчас мы соберем все требования и пожелания, зафиксируем их, и напишем им систему.
Для заказчика новые требования — это доработка системы под изменившиеся реалии, новые горизонты. Иначе, система устаревает еще не пройдя финальное тестирование. Для исполнителя, это выглядит как: "постоянно изменяющимися требованиями".

Как соединить эти несовместимые задачи?
Как предусмотреть устаревание п/о до сдачи проекта?