2 Quark:
Собственно, имеем некий внутренний проект внутри организации.
Есть ТЗ, естесственно постоянно расширяющееся и изменяющееся. От первоначального различается как небо и земля).
Проект по внедрению новой технологии.

0. Когда исполняющий орган в единственном лице (генеральный директор или т.п) организации или ответственное лицо в этом проекте решит, что проект достиг своих целей. Цели проекта (они довольно общие) обозначены в "ТЗ на внедрение технологии", плане и в приказе по организации/отделу

2 Jimmy:
>Есть ТЗ, естесственно постоянно расширяющееся и изменяющееся
Никогда.

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


2 Quark:
Хм, цели они как и ТЗ меняются постоянно.

Как уже верно заметил Jimmy : "На каждый этап - свое ТЗ", если под "этапом" понимается как временной интервал, заканчивающий какими-то значимыми изменениями в проекте или выделенная часть разрабатываемой системы или технологии

Если система в развитии, то нужно определить этапность, по принципу:
1. реализация того, что нужно обязательно
2. реализация того, что желательно сделать
3. реализация того, что можно сделать, но что не попадает под 2 первые категории

Для каждого этапа должны быть разработаны критерии готовности, согласно которым он передается в опытную, а затем в промышленную эксплуатацию.

Просто в дополнение: часто слышу такое понятие "критерии готовности", но многие под этим понимают разное, для простоты можно пользоваться (многие ИТ-компании успешно ими пользуются, это есть в UP, RUP, в других процессах и стандартах ISO/IEEE 12207) такими понятиями или моделями в ЖЦ как "приоритезация" и "ранжирование", т.е когда требования (в самом общем смысле, т.е это и варианты использования (use cases)) к технологии имеют приоритет и сначала реализуются требования только определенными с приоритетами, например, высокими. Тогда требования с низким приоритетом могут содержаться в ТЗ (для общего ознакомления и обсуждения), но они не реализуются до тех пор пока из приоритет не будет повышен

Первоначальных целей особенно с позиции руководства он достиг.
(это экономия 30шт баксов на внешних разработчиках, ну и собственно работающее ПО)

Если руководство так решило, то внедрение закончено. Другое дело, что когда заканчивается внедрение, т.е развертывание (deployment) начинается сопровождение/поддержка (maintainance) эксплуатируемой технологии со своими целями. Это и есть стадии или этапы ЖЦ технологии. Пока технология не выйдет из эксплуатации или не умрет что-то будет в нее вноситься, изменяться, убираться из нее. Хотя, конечно, бывают случаи - отдали заказчику систему и забыли, он поэскплуатировал систему без изменений, а затем постепенно перешел на другую. Может именно это имелость в виду? :о)

2 Quark:
Нет, не это).

Я вопрос не там вставил, т.е должно было быть так: "Другое дело, что когда заканчивается внедрение, т.е развертывание (deployment) начинается сопровождение/поддержка (maintainance) эксплуатируемой технологии со своими целями. Может именно это имелость в виду?" - т.е проект по созданию и внедрению закончен, а начался проект по сопровождению со своими задачами и т.д

2 Jimmy:
Возможно, это - нормально для внутренних проектов, но малоприемлемо для коммерческих, т.к. любое изменение ТЗ = изменению ресурсоемкости, т.е. стоимости работ.

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

Поэтому, имеется одно "каноническое" ТЗ, утвержденное при заключении договора с Заказчиком. Все изменения (с согласия Исполнителя!) оформляются допсоглашениями к договору.
А постоянно кроить договор - дело неблагодарное. К тому-же, бюджет проекта не так-то легко изменить.

IMHO в "каноническом" ТЗ и в переделывании самого договора нет необходимости, т.к а) ТЗ является приложением к договору при чем сам договор может не содержать даты окончания работ, т.е только срок начала, а также фразу, например, что "система создается на основании последнего ТЗ (т.е имеющего самую позднюю дату подписания)... Датой окончания работ является дата, указанная в ТЗ в разделе NNN..."; б) на последних страницах договора содержится таблица, например, "Обязательные приложения" (название документа, дата, подписи сторон, м.п.) - тогда при изменении ТЗ, т.е при возникновении нового ТЗ в этой таблице появляется новая строчка с ТЗ и все

2 Jimmy:
Поэтому, наше ТЗ (впрочем, как и сам подход к ведению проектов) - строго формализованный документ, который рассматривает все аспекты Life Cycle проекта.

Нет, я под ТЗ имел в виду, конечно, "ТЗ на создание ИС", т.е то, что относится только к основной разработке и передаче ИС заказчику. Предпроектное обследование, составление ТЭО, получение требований, обучение, поддержка и т.д - это предмет отдельных договоров. Не каждый заказчик захочет заключатб договор сразу на весь ЖЦ. Многие, например, хотят прототип функционального ядра (даже без тестирования), другие - "коробку" (без внедрения), третьи - "от и до" (включая внедрение и обучение). Те ТЗ, о к-рых говорил также содержат все предельно подробно, однозначно и полно (даже избыточно), т.е также формализованы до последнего "пука"

Да, ТЗ является приложением к договору, но не содержит никаких сроков.
Сроки - "План-график" проекта - тоже приложение к договору.

Это правильно, т.к никто в многоэтапном проекте (даже только по созданию ИС) одним сроком не оперирует. Однако план-график на суть моих рассуждений (можно или нет менять ТЗ) не влияет

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

Однако вы меня не убедили, т.е я не вижу припятствий для изменения ТЗ и пересчета стоимости работ (за счет заказчика)! Во-первых, наврядли есть заказчики, заинтересованные в бессрочном проекте, если они оплачивают каждую работу исполнителя или тем более каждый час работников исполнителя. IMHO скорее исполнитель будет заинтересован в такой продолжительной "бессрочности" :о)

Заказчик, если ему позволить, начнет "тромбовать" по полной программе и постарается "отбить" за свои деньги дополнительную работу, т.е. попросту расширяет границы проекта.

Во-вторых, как он может "отбить", т.е работы выполняются строго в рамках подписанных ТЗ (документ, не допускающий неоднозначностей и т.д)? Если я правильно понял, вызывает недоверие, например, следующий момент: было подписано ТЗ №1, исполнителю перечислено NNN средств, исполнителем выполнено XX%, например, функциональности (для простоты), содержащейся в ТЗ. Затем появилось ТЗ №2, содержащее как новую функциональность, так и YY% функциональности из ТЗ №1 при чем XX1% ее уже реализовано.
Вопрос: сколько просить с заказчика за реализацию системы по ТЗ №2? (стоимость реализации нового ТЗ №2) - ((стоимость реализации ТЗ №1) - (стоимость реализации XX% из ТЗ №1)). Даже если в новом ТЗ заказчик откажется от большинства работ, сделанных согласно предыдущему ТЗ, то эти деньги назад он уже не получит, а будет оплачивать все по-новой при чем на законных основаниях

Наш подход и разработанное нами ТЗ не позволит ему это сделать.

Наш подход также не позволяет ему это сделать, но при этом позволяет изменять требования по необходимости, а такая необходимость нередко бывает насущна. Возможно, для очень больших проектов или когда заказчик (например, если государственное предприятие) действует строго ограниченных финансовых рамках, есть определенные трудности (большой проект - лучше вложиться в НИОКР, чем потом переделывать ТЗ и систему) или изменение ТЗ и, как следствие, расходов крайне нежелательно