Зачастую у заказчика стоит проблема, сформированная ВЫШЕ инфраструктурного уровня (на стыке приложения и ИТ-инфраструктуры): недостатки прикладного пакета или недостаточный уровень оптимизации ИТ-инфраструктуры вызывает полную разруху в проекте целиком. В итоге все потраченные ресурсы деньги, время, люди) оказываются напрасными тратами, отягощенными эмоциональными последствиями "разборок" (и в итоге - неплатежей за уже выполненную работу или "работу").

Вообще, лучше система с известными недостатками (или даже багами) чем система,
недостатки которой исправляли "поверх" ТЗ... так как она вообще непредсказуемой может стать.

Я как закачик ;) буду не "слезно просить уложиться в бюджет", а требовать, так как Вы меня "пидманули" - дали неработоспособную небезотказную систему, сволочи акаянные! А ведь знали, что не заработает... а что за "бамажку" Заказчик "просит" - в смысле допу или доплицензии и почему вообще они в конвертике?

Не факт... это смотря что написано в ТЗ. Может быть такое (но работоспособное, как ни странно) Заказчику вообще не нужно :).

Не... со мной такой номер не пройдет - ТЗ то уже утверждено и подписано ;)
Допа - дополнительное соглашение
Лицензии по программе корпоративного лицензирования приходят в запечатанном конверте с указанием номера лицензиара и его реквизитами. Ключей нет :)

Просто никто не захотел судиться. Узбекистан на востоке, а восток дело тонкое. Я бы не церемонился и судился бы и выбивал все деньги обратно до последнего пенни обратно, в любом случае проект завалится. Нужно большее, чем утвержденное вами в том числе ТЗ. Тут проблемы не связаны с изготовлением, а с проектированием, а проектировали ВЫ. Пусть проектировалось со мной вместе, но я не специалист и им быть с учетом договора подряда не обязан, иначе зачем мне были б нужны ВЫ :) Суд аргументы скорее примет, а Вас назовет аферистом. Конечно все это только ИМХО, но жить может :).

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

Полностью с Вами согласен. Можно делать один проект всю жизнь и так и не закончить его.:)
Говоря о разработке заказной информационной системы в этот список необходимо добавить требования, по которым в будущем очень часто возникают споры между заказчиком и исполнителем: Детальные требования к функциям, выполняемым ИС; Требования к модели данных и атрибутам информационных объектов; Требования к стандартам пользовательского интерфейса и т.д.
Если на все время разработки “заморозить” техническим заданием вышеуказанные требования (а они являются неотъемлемой часть ТЗ), то в случае неточного изложения требований или их изменения в процессе разработки, заказчик получит систему, не удовлетворяющую его потребностям. Очень трудно заказчику, не являющемуся специалистом в разработке АС, при разработке ТЗ предусмотреть все точно и сразу, видя прототип системы только на бумаге в виде диаграмм, описаний и т.д. И это не повод разработчикам выкручивать руки заказчику и требовать дополнительных вознаграждений не вовремя процесса разработки, а после сдачи в опытную эксплуатацию.
Процесс реализации проекта по созданию АС не может четко уложится в рассматриваемую жесткую схему на 1, 2, 3 (и только на 3, получив основные деньги, выделенные на проект, мы готовы вернуться на шаг 1 за дополнительное вознаграждение). В процессе будет постоянно возникать необходимость возврата к предыдущим этапам и в уточнении и (или) пересмотре ранее принятых решений, если мы хотим, чтобы проект имел реальный успех.
Поэтому на этапе техно-рабочего проекта (разработки) применяется итеративный метод, когда заказчик может видеть прототип работающей системы, анализировать прототипы автоматизируемых функций на соответствии потребностям его бизнеса и при необходимости вносить изменения и дополнения в техническое задание по договоренности с исполнителем. Естественно, исполнитель в случае трудоемкости предложенных изменений или дополнений вправе потребовать дополнительные суммы.
Другими словами, согласование результатов выполненных работ с заказчиком должно производится не в конкретной точке – сдача в опытную эксплуатацию, а в течении всего техно-рабочего проекта (процесса разработки). Оставляя ему (а также и себе) возможность на исправление допущенных ошибок в описании требований к системе в утвержденном техническом задании. После сдачи в опытную эксплуатацию никакого разговора о внесении каких-либо изменений или дополнений уже быть не может.