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