Все что вы перечислили — это прежде всего инструменты реализации задачи, т.е. внутрикомандные.

Я же говорю о работе с заказчиком (т.е. постановке задачи). Составление документа, согласно которого заказчик будет принимать и оплачивать выполненные работы. ТЗ — это фактически детальный счет к оплате, как в ресторане.

А внутри команды, для разработчиков вы уже разбиваете его на задачи, этапы, сроки, исполнителей и т.п. Еще лучше — предварительно делаете отдельное внутреннее ТЗ для разработчиков.

Даже Google Docs для многих заказчиков это проблема. Для половины заказчиков наиболее удобный вариант общения — по телефону. Если вы им покажете Trello, они вас пошлют матюками.

Я как раз говорю о том, что ТЗ — не «вордовский файлик с тысячью правками» — и чтобы этого не было, все пожелания клиента пишутся в новый документ.

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

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

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

P.S. И гонять вордовский файлик с клиентом не нужно — есть прекрасный Google Drive с совместной работой над документами и даже комментариями для любого абзаца или слова. Странно что вы до сих пор об этом не знаете :)

P.P.S.Причем ТЗ пишете вы, а клиент может только читать и комментировать. И тогда везде порядок и все довольны.

В утвержденном ТЗ ни одна строчка не меняется. Иначе потом не найдешь концов — кто прав, а кто виноват.

Если нужны изменения в ТЗ — а такое происходит в любом проекте — составляется дополнение к ТЗ. Фактически ТЗ на дополнительные задачи. Оно же и оценивается дополнительно.

сайт на WP, где будет лежать несложный контент

Несложный сайт на полном готовых решений Wordpress — за 2-3 месяца.
Это кричит о том, что методика оценки категорически ошибочная. Либо неверно построены процессы.

300-450 часов по $20 за час = $6000 — $9000 за сайт

Поделитесь, где вы находите заказчиков, готовых платить такие деньги за такой простой сайт? :)
Вы можете в методику впихивать сколько угодно параметров, но есть объективная реальность — рынок — заплатит ли кто-то за вашу работу со всем учитанным и просчитанным про запас.

Типичный разговор разработчика с 80 процентами ИТ-рекрутеров:

Вариант 1.
Рекрутер: Здравствуйте, мы нашли ваше резюме, у нас открыта для вас вакансия, приезжайте к нам на собеседование.
Разработчик: А что за вакансия, какие условия?
Рекрутер: На эти вопросы ответит наш ИТ-директор, приезжайте на собеседование и мы все расскажем.

Вариант 2.
Рекрутер: Здравствуйте, мы нашли ваше резюме, мы ищем специалиста по XXX, NNN, SSS и ZZZ технологиям. Вам подходит наше предложение?
Разработчик: Да, я специалист по XXX, NNN, SSS и ZZZ. А в чем ваше предложение?
Рекрутер: Мы предлагаем вам работу по XXX, NNN, SSS и ZZZ.
Разработчик: у меня есть работа по XXX, NNN, SSS и ZZZ. Что вы предлагаете по финансам?
Рекрутер: А что вы хотите?
Разработчик: Если у вас есть предложение, так предлагайте, вы же со мной связались.

Чаще всего рекрутеры не могут вообще выразить предложение как таковое, а уж тем более выразить в чем интерес их предложения для разработчика.
То есть подход чисто номинальный, для отчета — у меня есть план связаться с 20 разработчиками сегодня. И все.